----- 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):
Let's take this line here:
https://github.com/stephenc/jenkins/blame/d331c12bbc2cf863efd39e0b135c584da364937a/core/src/main/java/hudson/model/Computer.java#L1003
Now that line was last changed in 6f343dc7c2f0c32e9eb1a0b5d588a2e7ad6f62ba
and GitHub (as well as `git blame` will correctly show the change as resulting
from that commit)
However the master branch was only modified in
71e684ad900363c48d845f73c1993f90de4417ad
So with the command line option I would like to see you would have `git
blame --squash-merges` report line 1003 as changed in
71e684ad900363c48d845f73c1993f90de4417ad not
6f343dc7c2f0c32e9eb1a0b5d588a2e7ad6f62ba
Similarly, `git log --squash-merges` would show
71e684ad900363c48d845f73c1993f90de4417ad in the log but omit all the commits
merged in with that...
Now how close can I get with the existing options:
* I think that `git log --first-parent` is almost what I want,
* `gitk --first-parent` has the distraction of showing that the merge
commits were a merge by having those merge-into lines
I can probably live with that distraction, but when you get to the commit
line itself drifting... it seems to be distracting me again, e.g.
* `git blame` doesn't have a `--first-parent` option
So I guess my questions:
* Am I correct in my interpretation of --first-parent? Is it doing what I
want or am I just being accidentally lucky for the cases I have inspected
* (assuming that --first-parent is what I want) How do I submit a feature
request for `git blame --first-parent`?
Thanks in advance,
-Stephen
There's been a recent discusion about this on the main git list recently
http://news.gmane.org/gmane.comp.version-control.git.
http://thread.gmane.org/gmane.comp.version-control.git/277536/focus=277539
Merges are not shown by default, but the -m option will show them. The
default is based on historical use rather than the many varied current usage
style.
The --firstparent is the one for triming off the side branches, but without
the -m you don't get the merges!, which misses the critical merge message (you
do write good merge messages don't you ;-)
Don't forget that gitk and git gui are separately coded (tcl) and maintained
from the git.git tool set.
In general I'd say it (both showing merges, and the blame discussion) was
something worth discussing upstream on the git mailing list
g...@vger.kernel.org <g...@vger.kernel.org>
--
Philip
[just another user]
Some extra stuff:
The man page has hidden secrets (as is common)..
In particular the –S option mentions that one can provide a revs file, “instead
of calling git-rev-list(1).”!
If one looks at the source code, and the usage string (git blame –h)
https://github.com/git/git/blob/master/builtin/blame.c#L32
static char blame_usage[] = N_("git blame [<options>] [<rev-opts>] [<rev>] [--]
<file>");
static const char *blame_opt_usage[] = {
blame_usage,
"",
N_("<rev-opts> are documented in git-rev-list(1)"),
NULL
};
You can see that you can use many of the git-rev-list options, which drops you
into a whole new world (take a rope; well secured.. ;-)
Thus you can use --firstparent, etc.
It definitely looks like the man pages could do with some TLC from a real user,
rather than from the devs who already know the answer. (i.e. a contribution to
patch the documentation would be something worth putting forward!)
It may be that your suggested blame options are still required to be added to
git.git.
And then the gitk and git gui can separately be updated to allow their use.
--
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.
