Subject: Re: [vserver] vserver git server and misc. thoughts
From: Ed W <lists@wildgooses.com>
Date: Tue, 12 Aug 2008 17:56:52 +0100
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