Jason Kim <jasonwkim at google.com> writes:> I believe git has a similar system for maintaining "branches of patches"A pointer/tutorial on how to do this would be most welcome. -Dave
On Sep 12, 2011, at 9:16 AM, David A. Greene wrote:> Jason Kim <jasonwkim at google.com> writes: > >> I believe git has a similar system for maintaining "branches of patches" > > A pointer/tutorial on how to do this would be most welcome.I don't think anything special is required. I just create normal git branches that I regularly rebase against the public mirror. I don't usually have dependent branches, they are all based on trunk, but that too should be possible. I did use stgit at one point, but now that we have a public mirror, I don't think it really offers much that plain git can't do. Like Takumi said, if you are working against the public git mirror, only committing is affected by LLVM's using svn. Everything else is just plain git. /jakob
dag at cray.com (David A. Greene) writes:> Jason Kim <jasonwkim at google.com> writes: > >> I believe git has a similar system for maintaining "branches of patches" > > A pointer/tutorial on how to do this would be most welcome.It depends on the definition of "branches of patches" ;-). I manage my patches with "git rebase -i", which allows me to edit, combine, reorder, discard my local commits relatively easily. See for example: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html Git keeps tracks of what you do locally in a kind of meta-history called the reflog (i.e. when you rewrite history, the resulting history is the clean sequence of commits you want to show to the rest of the world, and the reflog keeps tracks of you mistakes and how you fixed them). See for example: http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html The reflog is a very good complement to "rebase -i" in the sense that it keeps your (dirty) history, so you're safe if you mis-use "rebase -i", but it keeps it local, so you don't disturb others with "oh, I've noticed a flaw in my previous commit, let's fix it before I send the patch"-kind of commits. Other people prefer using some additional layers on top of Git like stgit or topgit, which are probably the closest equivalent to Mercurial's MQ (disclaimer: I've never use any of them). -- Matthieu Moy http://www-verimag.imag.fr/~moy/
Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes:> dag at cray.com (David A. Greene) writes: > >> Jason Kim <jasonwkim at google.com> writes: >> >>> I believe git has a similar system for maintaining "branches of patches" >> >> A pointer/tutorial on how to do this would be most welcome. > > It depends on the definition of "branches of patches" ;-). > > I manage my patches with "git rebase -i", which allows me to edit, > combine, reorder, discard my local commits relatively easily. See for > example:But none of this explains how to prevent false conflicts when updating your git workarea from the svn git mirror. The problem is that dcommit changes the hash from what's in your local repository to something different. When you then update from the git mirror, you get a conflict because two commits with different hashes have the same file contents. -Dave