That looks "good" (aka effective but long).
Good to see your request on the git@gver list.
Jeff is one of the main coders @ github, so it's a worthwhile reply.
regards
----- Original Message -----
From: Stephen Connolly
To: Philip Oakley ; git-users@googlegroups.com
Sent: Friday, September 11, 2015 11:52 AM
Subject: Re: [git-users] Treat merges as squashed commits in git log/git
blame/gitk etc
Well that was interesting, but --first-parent does not do what you'd expect
on git blame.
I was able to construct a command sequence to do what I want though:
git rev-list --first-parent HEAD | awk '{print p " " $0}{p=$0}' >
tmpfile && git blame -b -S tmpfile HEAD -- path && rm tmpfile
On Thu, 10 Sep 2015 at 21:20 Philip Oakley <philipoak...@iee.org> wrote:
----- Original Message -----
From: Philip Oakley
To: git-users@googlegroups.com
Sent: Thursday, September 10, 2015 8:48 AM
Subject: Re: [git-users] Treat merges as squashed commits in git log/git
blame/gitk etc
----- Original Message -----
From: Stephen Connolly
To: Git for human beings
Sent: Wednesday, September 09, 2015 9:56 AM
Subject: [git-users] Treat merges as squashed commits in git log/git
blame/gitk etc
Hi,
At my work and on some of the open source communities that I contribute
to, there is a healthy debate about how to handle merge commits. I can break
this into two camps:
* People who think that when you are merging a change from a pull
request, you should squash all commits immediately prior to the merge as this
means you can see all the changes associated with the merge in the same commit
and simplifies history browsing.
* People who think that when you are merging a change from a pull
request, you should never squash commits and just merge them all so that you
have access to the history of development of that feature.
I tend to lean towards the second camp myself, but I recognise that the
first camp has a point... namely when you are using tooling such as `git log`,
`git blame` and `gitk` I cannot seem to supply an option that says "Hey when
you see a merge commit, treat it as if all commits from the 2nd and subsequent
parents of the merge were squashed"
With such an option, people in the first camp could use that option
choose to see a "linear" history with all merge commits appearing as if they
were squashed commits, git blame could help them identify when the actual
"feature" was merged rather than having to trace back up the history lines from
the commit where the line was touched to find the line.
By way of example (and I could have searched a bit harder for a more
tricky example):
[Snip]
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
