John McCall <rjmccall at apple.com> writes:>> git branch --contains <sha1>, on the other hand, will tell you. > > Of course, this doesn't actually help if you've cherry-picked commits > over to your branch (e.g. because it's a release branch).How is that different from SVN? If revision 1234 fixes a bug is some branch, and the last revision in your trunk is 2345, can you tell whether your trunk has this bugfix applied by looking at revision numbers? -- Matthieu Moy http://www-verimag.imag.fr/~moy/
On Jul 22, 2011, at 12:33 AM, Matthieu Moy wrote:> John McCall <rjmccall at apple.com> writes: >>> git branch --contains <sha1>, on the other hand, will tell you. >> >> Of course, this doesn't actually help if you've cherry-picked commits >> over to your branch (e.g. because it's a release branch). > > How is that different from SVN?It isn't, and of course "git cherry-pick -x" does make it very easy to preserve this information. I'm just saying that the use case of release branches formed by extensive cherry-picking is very important to both the LLVM and Apple release processes. John.
John McCall <rjmccall at apple.com> writes:> It isn't, and of course "git cherry-pick -x" does make it very easy to > preserve this information. I'm just saying that the use case of > release branches formed by extensive cherry-picking is very > important to both the LLVM and Apple release processes.I don't know whether it's applicable to LLVM and Apple, but a common practice to solve this is to apply bugfixes to the oldest supported branch having the bug first, and then merge old maintainance branches to newer branches. This way, you have a real merge, not a cherry-pick. -- Matthieu Moy http://www-verimag.imag.fr/~moy/