On Mon, Aug 16, 2010 at 12:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update release notes, mainly.
>
> 2010-08-13 12:27 tgl
>
> * src/backend/: catalog/namespace.c, utils/cache/plancache.c
> (REL9_0_STABLE), catalog/namespace.c, utils/cache/plancache.c
> (REL8_3_STABLE), catalog/namespace.c, utils/cache/plancache.c
> (REL8_4_STABLE), catalog/namespace.c, utils/cache/plancache.c:
Yeah... it cant really. You can git log --decorate which will add any
tags or branches a commit is in, but it breaks for merges and only
works if the commit hash is the same (and if its the *current* commit
on the branch I think). Skimming the git mailing list, it seems the
powers that be think the above is stupid pointless and wrong (out of
touch with reality or what?). Basically the argument is if you want
to back patch something you probably need to change it in some way and
touch up the commit message anyway. So just include any relevant info
in the commit message and you can script something to parse and
extract that info if you care. This (long) thread sums it up
http://thread.gmane.org/gmane.comp.version-control.git/95381/focus=95386.
How exactly patches get applied into back branches? Has that been
spelled out somewhere? There are a lot of ways to do it. For
instance git.git seems to apply the patch to the earliest branch first
and then merge it on up so that everything can share the same
commit/hash. That looks like a royal PITA to me, and I assume the
plan is to just cherry-pick commits back. As long as we use git
cherry-pick -x, I agree with Magnus, it should be fairly easy to write
a short script to do it. II'll even volunteer if the above is
basically the only requirement :-).