Tue, 12 Aug 2008 17:56:52 +0100
Daniel Hokka Zakrisson wrote:
> Adam Majer wrote:
>
>> Herbert Poetzl wrote:
>>
>>> On Mon, Aug 11, 2008 at 11:35:16PM -0500, Adam Majer wrote:
>>>
>>>> Or at least people send patches and commits to it instead of that
>>>> kernel-diff-monster!
>>>>
>>> is that a nickname for me? :)
>>>
>> GIT allows for tracking of changes so you don't need to do much work do
>> view changes to some file between two different versions of the kernel.
>>
>
> IMHO this is harder to do with git than plain old kernel trees...
>
I actually hear what you are saying because I have seen this with a
bunch of new git project forks
I think the trick is to realise that having a cool distributed VCS
system doesn't automatically bring solutions to problems. For example
what I see a lot of is forking a project, then developing like mad in
your master branch and just pulling in commits from upstream and it's
all merged in one bit pot...
Now amazingly enough even though you can merge all this junk together,
due to the way git works it can actually pick it all apart again and you
can ask it questions like: "show me the difference between my working
tree and kernel 2.6.25.2." Or "take my current working tree and roll
back all changes in the kernel from 2.6.26 back to 2.6.24" - which kind
of gets your patch set to be against a previous branch of someone elses code
However, you need to be a bit of a wizard to figure it all out, so I
personally found a better solution was something like:
- Branch following upstream project
- Branch with my custom patches in it
- My development branch, which pulls from both of the above
Then I work in my dev branch (which may or may not be shared upstream)
and regularly pull down from both other branches (usually public) and
when I am happy with a bunch of commits in my dev branch I just use git
log to locate them and "git cherrypick" to commit them into the "custom
patches branch"
The end result is that you can browse the patch branch and immediately
see just the relevant changes to the master tree. Upstream also have a
higher chance of picking out individual bits of it for inclusion (I
claim). You can rinse and repeat this process for example creating a
new branch which squashes bunches of those commits together and perhaps
rewrites some of them, etc, etc. In this way you can keep the branch
fresh and neat
I haven't seen much on "git etiquette", but there are definitely loads
of useless repos around which are hard to figure out where the
development is going and what's changed... I don't think it has to be
this way though
Ed W
Daniel Hokka Zakrisson wrote:
Adam Majer wrote:
Herbert Poetzl wrote:
On Mon, Aug 11, 2008 at 11:35:16PM -0500, Adam Majer wrote:
Or at least people send patches and commits to it instead of that
kernel-diff-monster!
is that a nickname for me? :)
GIT allows for tracking of changes so you don't need to do much work do
view changes to some file between two different versions of the kernel.
IMHO this is harder to do with git than plain old kernel trees...
I actually hear what you are saying because I have seen this with a
bunch of new git project forks
I think the trick is to realise that having a cool distributed VCS
system doesn't automatically bring solutions to problems. For example
what I see a lot of is forking a project, then developing like mad in
your master branch and just pulling in commits from upstream and it's
all merged in one bit pot...
Now amazingly enough even though you can merge all this junk together,
due to the way git works it can actually pick it all apart again and
you can ask it questions like: "show me the difference between my
working tree and kernel 2.6.25.2." Or "take my current working tree
and roll back all changes in the kernel from 2.6.26 back to 2.6.24" -
which kind of gets your patch set to be against a previous branch of
someone elses code
However, you need to be a bit of a wizard to figure it all out, so I
personally found a better solution was something like:
- Branch following upstream project
- Branch with my custom patches in it
- My development branch, which pulls from both of the above
Then I work in my dev branch (which may or may not be shared upstream)
and regularly pull down from both other branches (usually public) and
when I am happy with a bunch of commits in my dev branch I just use git
log to locate them and "git cherrypick" to commit them into the "custom
patches branch"
The end result is that you can browse the patch branch and immediately
see just the relevant changes to the master tree. Upstream also have a
higher chance of picking out individual bits of it for inclusion (I
claim). You can rinse and repeat this process for example creating a
new branch which squashes bunches of those commits together and perhaps
rewrites some of them, etc, etc. In this way you can keep the branch
fresh and neat
I haven't seen much on "git etiquette", but there are definitely loads
of useless repos around which are hard to figure out where the
development is going and what's changed... I don't think it has to be
this way though
Ed W