git log for a merged branch

git log for a merged branch

[Stephen Bash]

Hi everyone-

A coworker asked me a Git question yesterday that I can't answer, so I thought I'd pass it along:

Assume I have a release branch with bug fixes that is tagged at the end of the release cycle (let's call the tag tagFoo).  The release branch then gets merged back into mainline development (call the branch mainline), and the release branch is deleted.  If I want to see the commits (bug fixes) performed on the release branch, how do I do it?

I don't think
   git log mainline..tagFoo
works because all the commits of tagFoo are now reachable by mainline thanks to the merge.  Is there a simple way to express this concept?

Obviously in a pinch a simple
   git log tagFoo
will give you everything back to the beginning of time, but I think that's suboptimal...

To complicate things a bit more, in the real world there may be multiple merges from the release branch to mainline during the life of the release branch, so any solution that also deals with that would be outstanding (probably at the cost of additional complexity?)

Thanks,
Stephen

Re: git log for a merged branch

[Tor Arntsen]

On Wed, Sep 8, 2010 at 16:04, Stephen Bash <bash@genarts.com> wrote:
> Hi everyone-
>
> A coworker asked me a Git question yesterday that I can't answer, so I thought I'd pass it along:
>
> Assume I have a release branch with bug fixes that is tagged at the end of the release cycle (let's call the tag tagFoo).  The release branch then gets merged back into mainline development (call the branch mainline), and the release branch is deleted.  If I want to see the commits (bug fixes) performed on the release branch, how do I do it?
[..]

Maybe not exactly what you ask for, but the way I do it is simply to
use a non-ff merge with additional logging, i.e. git merge --no-ff
--log <branchname-with-fixes>
which will give me a merge commit which includes one-liners for each
of those commits merged into mainline. And I include problem report
ID's in the first line of my commits I get a nice list of fixes, in a
commit looking something like this:

commit <sha1>
Author:
Date:
   Merge branch 'fixes'
  * fixes:
     Fix for PR#23
     Fix for PR#1
     Fix for PR#288
..
and so on. Those 'Fix for' are just the git log --oneline of what got merged.
(Obviously what you don't see in the above is the actual sha1 of each
of those commits that got merged, but at least it's easy enough to
figure out what to put in the release notes :-)

Re: git log for a merged branch

[Stephen Bash]

----- Original Message -----
> From: "Tor Arntsen" <tor@spacetec.no>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "Git Mailing List" <git@vger.kernel.org>
> Sent: Wednesday, September 8, 2010 10:23:47 AM
> Subject: Re: git log for a merged branch
> On Wed, Sep 8, 2010 at 16:04, Stephen Bash <bash@genarts.com> wrote:
>
> > If I want to
> > see the commits (bug fixes) performed on the release branch, how do
> > I do it?
> [..]
> 
> Maybe not exactly what you ask for, but the way I do it is simply to
> use a non-ff merge with additional logging, i.e. git merge --no-ff
> --log <branchname-with-fixes>
> which will give me a merge commit which includes one-liners for each
> of those commits merged into mainline.

That's actually a pretty cool trick.  I will file that one for adoption as we move to a git-centric workflow.

I'm still curious if there's an "easy" way to extract the segment of history that was the release branch because I feel like there may be other uses than just git log... (not that I've nailed them down yet)

Thanks!
Stephen

Re: git log for a merged branch

[Michele Ballabio]

On Wednesday 08 September 2010, Stephen Bash wrote:
> Assume I have a release branch with bug fixes that is tagged at the end of
> the release cycle (let's call the tag tagFoo).  The release branch then
> gets merged back into mainline development (call the branch mainline), and
> the release branch is deleted.  If I want to see the commits (bug fixes)
> performed on the release branch, how do I do it?
> 
> I don't think
>    git log mainline..tagFoo
> works because all the commits of tagFoo are now reachable by mainline
> thanks to the merge.  Is there a simple way to express this concept?
> 
> Obviously in a pinch a simple
>    git log tagFoo
> will give you everything back to the beginning of time, but I think that's
> suboptimal...

Let's call the merge commit "mergecmt". The commit where the "release" branch
branched off is

	git merge-base mergecmt^1 mergecmt^2

... where mergecmt^1 is the first parent of the merge (usually on the
"mainline" branch) and mergecmt^2 is the second parent, which usually(*)
refers to the "release" branch (in this case, tagFoo).

So

	git log $(git merge-base mergecmt^1 mergecmt^2)..mergecmt^2

is what you want.

> To complicate things a bit more, in the real world there may be multiple
> merges from the release branch to mainline during the life of the release
> branch, so any solution that also deals with that would be outstanding
> (probably at the cost of additional complexity?)

Maybe something like:

	for i in $(git rev-list --merges last_interesting_tag..mainline)
	do
		git log $(git merge-base $i^1 $i^2)..$i^2
	done

... or maybe using GIT_PAGER='':

	for i in $(git rev-list --merges last_interesting_tag..mainline)
	do
		GIT_PAGER='' git log $(git merge-base $i^1 $i^2)..$i^2
	done

(*) I don't remember the details, but if you do the standard "git pull"
or "git merge" and don't use the plumbing commands in a weird way to badly
reimplement "merge" or "pull", you should be safe. Others may want to
comment on this, though.

Re: git log for a merged branch

[Stephen Bash]

----- Original Message -----
> From: "Michele Ballabio" <barra_cuda@katamail.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "Git Mailing List" <git@vger.kernel.org>
> Sent: Wednesday, September 8, 2010 7:17:05 PM
> Subject: Re: git log for a merged branch
> On Wednesday 08 September 2010, Stephen Bash wrote:
>
> Let's call the merge commit "mergecmt". The commit where the "release"
> branch
> branched off is
> 
> git merge-base mergecmt^1 mergecmt^2
> 
> ... where mergecmt^1 is the first parent of the merge (usually on the
> "mainline" branch) and mergecmt^2 is the second parent, which
> usually(*)
> refers to the "release" branch (in this case, tagFoo).
> 
> So
> 
> git log $(git merge-base mergecmt^1 mergecmt^2)..mergecmt^2
> 
> is what you want.
> 
> > To complicate things a bit more, in the real world there may be
> > multiple
> > merges from the release branch to mainline during the life of the
> > release
> > branch, so any solution that also deals with that would be
> > outstanding
> > (probably at the cost of additional complexity?)
> 
> Maybe something like:
> 
> for i in $(git rev-list --merges last_interesting_tag..mainline)
> do
> git log $(git merge-base $i^1 $i^2)..$i^2
> done

Hm...  Makes sense...  I'll have to play with it a little bit to get a good feel for how it fits our workflow, but it seems like a really good option.

Thanks!

Stephen

Re: git log for a merged branch

[Santi Béjar]

On Mon, Sep 13, 2010 at 3:37 PM, Stephen Bash <bash@genarts.com> wrote:
>
>
> ----- Original Message -----
>> From: "Michele Ballabio" <barra_cuda@katamail.com>
>> To: "Stephen Bash" <bash@genarts.com>
>> Cc: "Git Mailing List" <git@vger.kernel.org>
>> Sent: Wednesday, September 8, 2010 7:17:05 PM
>> Subject: Re: git log for a merged branch
>> On Wednesday 08 September 2010, Stephen Bash wrote:
>>
>> Let's call the merge commit "mergecmt". The commit where the "release"
>> branch
>> branched off is
>>
>> git merge-base mergecmt^1 mergecmt^2
>>
>> ... where mergecmt^1 is the first parent of the merge (usually on the
>> "mainline" branch) and mergecmt^2 is the second parent, which
>> usually(*)
>> refers to the "release" branch (in this case, tagFoo).
>>
>> So
>>
>> git log $(git merge-base mergecmt^1 mergecmt^2)..mergecmt^2
>>
>> is what you want.

If there is more than one merge-base you´ll have to use:

git log mergecmt^2 --not $(git merge-base mergecmt^1 mergecmt^2)

and you may use this shorter form:

git log mergecmt^2 --not $(git merge-base mergecmt^@)

HTH,
Santi

Re: git log for a merged branch

[Stephen Bash]

----- Original Message -----
> From: "Santi Béjar" <santi@agolina.net>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "Michele Ballabio" <barra_cuda@katamail.com>, "Git Mailing List" <git@vger.kernel.org>
> Sent: Monday, September 13, 2010 10:00:18 AM
> Subject: Re: git log for a merged branch
> 
> If there is more than one merge-base you´ll have to use:
> 
> git log mergecmt^2 --not $(git merge-base mergecmt^1 mergecmt^2)
> 
> and you may use this shorter form:
> 
> git log mergecmt^2 --not $(git merge-base mergecmt^@)

That's surprisingly compact...  Impressive.

Slightly changing the topic, we normally tag the release branch, then merge, then delete the branch.  Is there a simple way to determine mergemt from the release tag?

Thanks,
Stephen

Re: git log for a merged branch

[Santi Béjar]

On Mon, Sep 13, 2010 at 4:13 PM, Stephen Bash <bash@genarts.com> wrote:
> ----- Original Message -----
>> From: "Santi Béjar" <santi@agolina.net>
>> To: "Stephen Bash" <bash@genarts.com>
>> Cc: "Michele Ballabio" <barra_cuda@katamail.com>, "Git Mailing List" <git@vger.kernel.org>
>> Sent: Monday, September 13, 2010 10:00:18 AM
>> Subject: Re: git log for a merged branch
>>
>> If there is more than one merge-base you´ll have to use:
>>
>> git log mergecmt^2 --not $(git merge-base mergecmt^1 mergecmt^2)
>>
>> and you may use this shorter form:
>>
>> git log mergecmt^2 --not $(git merge-base mergecmt^@)
>
> That's surprisingly compact...  Impressive.
>
> Slightly changing the topic, we normally tag the release branch, then merge, then delete the branch.  Is there a simple way to determine mergemt from the release tag?

So, in other words, you want the list of descendants of the given
release tag say v1.7.3-rc1, contained in a give branch, say "master":

$ git rev-list --parents v1.7.3-rc1..master | grep $(git rev-parse
v1.7.3-rc1^{})
5418d96ddca8134b5abeb99430f61c062d91f722
3b3a8ed4beadf5d9437597108355b23c7143bc81

But note that it may not be unique and may change over time. In
particular if you have more commits on top of the tag and merge again.

Santi