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
> 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.git svn set-tree
dag at cray.com (David A. Greene) writes:> 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.I guess you have to rebase (pull --rebase or so) your branches. "git rebase" is relatively smart, and will skip patches that you already have in your local branch. I never used a mirror like LLVM's one (my contribution to LLVM boils down to sending two patches that were superbly ignored by the list and wait patiently on the bugtracker ^^), but when contributing a patch to Git itself, one gets a similar effect: the local patches are sent as email, applied by the maintainer, and get a different sha1 when you pull. git rebase works like a charm in this setup (well, no big surprise that Git is adapted to contribute to Git indeed ;-) ). -- Matthieu Moy http://www-verimag.imag.fr/~moy/
FlyLanguage <flylanguage at gmail.com> writes:>> 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. > > git svn set-treeOk. The documentation for set-tree is pretty obtuse. Do you have a layman's version? :) -Dave
On 13 September 2011 15:50, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote:> I guess you have to rebase (pull --rebase or so) your branches. "git > rebase" is relatively smart, and will skip patches that you already have > in your local branch.http://llvm.org/docs/GettingStarted.html#git_mirror "Since the upstream repository is in Subversion, you should use "git pull --rebase" instead of "git pull" to avoid generating a non-linear history in your clone." cheers, --renato