Proposal for git tree management
I think the git development model is working out pretty well. We've committed around 100 patches to our tree since we switched to using git. Most of those have gone upstream, mostly through Kyle's hard work.
However, figuring out what is left to merge is getting harder. Due to trying to keep Linus' tree clean, the commit that goes into our development tree isn't the same one that ends up in his tree. So it's hard to tell what's been committed and what hasn't. Don't get me wrong, it's still an improvement over using CVS, but I think we could use Git more effectively.
Right now, git-log linus..origin shows all the patches we've ever committed, regardless of whether they've been merged. A graphic would make this easier:
A -> B -> C -> D' -> E
\-> D -------/-> F --\->G
This illustrates Linus' tree at time A. We clone his tree and make change D, and eventually it ends up in Linus' tree as D' (after changes B and C have happened in his tree). At point G, git-log linus..master shows change D, even though it was already merged to the linus tree.
The obvious solution is to rebase the tree. We start a new origin branch from point E and pull commit F onto it as commit F'. But if we delete the former origin branch we lose our history. So I'd like to rename it (probably to something like devel-2006-10-07), and create a new origin. That way we can still go back and find our history, and still keep git-log useful.
I'm concerned we may get an unreasonable number of branches using this scheme. Using a date (rather than a cardinal) helps understand how relevant a branch may be.
Anyway, comments, suggestions, alternatives, abuse?
_______________________________________________
parisc-linux mailing list [email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 4 lines · Matthew Wilcox
I think the git development model is working out pretty well. We've committed around 100 patches to our tree since we switched to using git. Most of those have gone upstream, mostly through Kyle's hard work.
Agreed - many kudos/thanks to kyle!
...
Quoted 3 lines
The obvious solution is to rebase the tree. We start a new origin branch from point E and pull commit F onto it as commit F'. But if we delete the former origin branch we lose our history.
I don't care so much about "our" history. I mostly care about the commit message(s) that end up in linus' tree.
Quoted 3 lines
I'm concerned we may get an unreasonable number of branches using this scheme. Using a date (rather than a cardinal) helps understand how relevant a branch may be.
I think anything is ok if it helps us determine what's missing from linus' tree and ship those patches (when ready) to him. I'll probably end up ignoring the branches anyway.
Please just make it "KISS". I'm only using git a few times per month and it's just not enough to do anything complicated right now. My goal is any git commits I make can (indirectly via kyle) go to linus without the confusion you described.
thanks!
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 7 lines · Grant Grundler
Quoted 4 lines · Matthew Wilcox
I think the git development model is working out pretty well. We've committed around 100 patches to our tree since we switched to using git. Most of those have gone upstream, mostly through Kyle's hard work.
Agreed - many kudos/thanks to kyle!
All hail Kyle indeed :)
Quoted 6 lines
Quoted 3 lines
The obvious solution is to rebase the tree. We start a new origin branch from point E and pull commit F onto it as commit F'. But if we delete the former origin branch we lose our history.
I don't care so much about "our" history. I mostly care about the commit message(s) that end up in linus' tree.
Despite not being terribly active nowadays, I'd like to contrast this view a little bit. "Our" history has proven very useful (at least to me) in a number of cases (comes to mind the development of gscps2 input driver based on evolutions of hp_kbd.c and friends) and I remember quite a few occasion where it was actually interesting to be able to track down who committed any given bit of code (for some reason I remember tracking down prumpf's commits in some well known locking routine, among other things).
On a more "play the devil's advocate" side of things, i believe it's of great importance to be able to track down when any given code was first introduced and who committed it. Copyright issues such as the SCO-induced shite are a good demonstration that being able to quickly assert copyright/genealogy on any given bit is a good thing...
Quoted 4 lines
Quoted 3 lines
I'm concerned we may get an unreasonable number of branches using this scheme. Using a date (rather than a cardinal) helps understand how relevant a branch may be.
Quoted 8 lines
I think anything is ok if it helps us determine what's missing from linus' tree and ship those patches (when ready) to him. I'll probably end up ignoring the branches anyway.
Please just make it "KISS". I'm only using git a few times per month and it's just not enough to do anything complicated right now. My goal is any git commits I make can (indirectly via kyle) go to linus without the confusion you described.
I'd also strongly support a KISS approach. Yet I was under the impression that rebasing the tree would break any subsequent 'git pull' on older trees, is that right?
Along those lines I'm also thinking that assuming we want to revive our kernel autobuilder, we probably want to think of a git tree architecture that will induce minimal man handling of the autobuilder once started...
Just my 2c, well aware that I'm not paying enough attention to our development process lately, and thus I may be full of sh*t ;^)
HTH
T-Bone
Signature · 6 lines
Thibaut VARENE http://www.parisc-linux.org/~varenet/ _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 8 lines · Thibaut VARENE
Quoted 4 lines
Please just make it "KISS". I'm only using git a few times per month and it's just not enough to do anything complicated right now. My goal is any git commits I make can (indirectly via kyle) go to linus without the confusion you described.
I'd also strongly support a KISS approach. Yet I was under the impression that rebasing the tree would break any subsequent 'git pull' on older trees, is that right?
Yes. And no. It depends ;-)
If your refspec looks like this:
$ cat .git/remotes/origin URL: ssh://git.parisc-linux.org/var/git/linux-2.6.git Pull: refs/heads/master:refs/heads/origin Pull: refs/heads/linus:refs/heads/linus
then it's going to whinge about not being able to fast-forward. However, if you add a +, like this:
Pull: +refs/heads/master:refs/heads/origin
then it'll update the ref, even if it's not a fast-forward.
Quoted 4 lines
Along those lines I'm also thinking that assuming we want to revive our kernel autobuilder, we probably want to think of a git tree architecture that will induce minimal man handling of the autobuilder once started...
I agree, though I wouldn't expect rebasing to be a common operation (every 2-3 months), it would suck to inadvertently break the autobuilder.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 3 lines · Matthew Wilcox
I agree, though I wouldn't expect rebasing to be a common operation (every 2-3 months), it would suck to inadvertently break the autobuilder.
if we queue the autobuilder based on tags, even if we rebase, we will never have an issue, since git-prune will only remove unreachable commits. as long as we have a tag for the pre-rebased commits, they'll never be removed, which is the desired behaviour (since the autobuilder will always be able to check them out.)
cheers,
kyle
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux