Re: [git-users] Treat merges as squashed commits in git log/git blame/gitk etc

2015-09-11 Thread Philip Oakley 
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  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.

Re: [git-users] Treat merges as squashed commits in git log/git blame/gitk etc

2015-09-11 Thread Stephen Connolly 
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  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):
>
> 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,
>
>
> <https://lh3.googleusercontent.com/-fFiYb4_neb0/Ve_y_DdvNvI/Ab4/2Ojvccwo2Fg/s1600/Screen%2BShot%2B2015-09-09%2Bat%2B09.50.01.png>
>
> * `gitk --first-parent` has the distraction of showing that the merge
> commits were a merge by having those merge-into lines
>
>
> <https://lh3.googleusercontent.com/-Y7lccFN6Mzg/Ve_zLssSpcI/AcA/0MXSmMCLjc8/s1600/Screen%2BShot%2B2015-09-09%2Bat%2B09.47.53.png>
>
> 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.
>
>
> <https://lh3.googleusercontent.com/-NcIFRSYO_HA/Ve_zbZgs-KI/AcI/1dTKIcZbDYc/s1600/Screen%2BShot%2B2015-09-09%2Bat%2B09.50.21.png>
>
> * `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

Re: [git-users] Treat merges as squashed commits in git log/git blame/gitk etc

2015-09-10 Thread Philip Oakley 
  - 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  
  --
  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 [] [] [] [--] 
");

 

static const char *blame_opt_usage[] = {

blame_usage,

Re: [git-users] Treat merges as squashed commits in git log/git blame/gitk etc

2015-09-10 Thread Philip Oakley 
- 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  
--
Philip
[just another user]

-- 
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.

[git-users] Treat merges as squashed commits in git log/git blame/gitk etc

2015-09-09 Thread Stephen Connolly 
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

-- 
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.