On 31 January 2016 at 19:24, Joachim Breitner wrote:

Hi,

Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland:

...

My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward.

if you want to go through the trouble, you are certainly welcome to do so. The fact that phab squashes commits into one is more an artifact of its VCS-agnosticity rather than a deliberate decision by us.

When I want a git history (or just my nice git commit messages) preserved, I create a phab differetian revision as usual, but then manually amend the git commit to contain the line Differential Revision: https://phabricator.haskell.org/Dnnnn and push, once the DR has been accepted, by normal git means. I just have to remember to indicate in the DR (e.g. in the summary) that I want to do it this way.

FWIW, I agree with Geoffrey, and in addition to the benefits he listed, I appreciate that committing "kernel.org-style" improves bisect'ability. I used to dislike merge commits myself until I realized the usefulness of finding merge points in the history. So, I don't understand how collapsing everything into one big commit can make any sense. Is it really impossible to tell phabricator (or arcanist) to preserve a carefully prepared patch set, and if so, why does it insist on that?

On 31 January 2016 at 22:01, Geoffrey Mainland wrote:

On 01/31/2016 02:47 PM, Tuncer Ayaz wrote:

...

On 31 January 2016 at 19:24, Joachim Breitner wrote:

...

Hi,

Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland:

...

My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward.

if you want to go through the trouble, you are certainly welcome to do so. The fact that phab squashes commits into one is more an artifact of its VCS-agnosticity rather than a deliberate decision by us.

When I want a git history (or just my nice git commit messages) preserved, I create a phab differetian revision as usual, but then manually amend the git commit to contain the line Differential Revision: https://phabricator.haskell.org/Dnnnn and push, once the DR has been accepted, by normal git means. I just have to remember to indicate in the DR (e.g. in the summary) that I want to do it this way.

FWIW, I agree with Geoffrey, and in addition to the benefits he listed, I appreciate that committing "kernel.org-style" improves bisect'ability. I used to dislike merge commits myself until I realized the usefulness of finding merge points in the history. So, I don't understand how collapsing everything into one big commit can make any sense.

Is it really impossible to tell phabricator (or arcanist) to preserve a carefully prepared patch set, and if so, why does it insist on that?

Not that I don't think these things are worth discussing, but to be clear, I was not trying to impose my preferred git workflow on GHC :) I was just looking for clarification, which Joachim provided---thanks!

I'll have to deal a lot more with Phabricator in another project soon, and your question reminded me to figure out why this happens, etc. Open source communication has conditioned me to discuss publicly, so I may have hijacked the thread. Sorry. For anybody who's curious: I actually looked this up and it seems that Facebook decided to default to squash for cleaning up branches that are full of fixup commits and thereby make phab not support branches with a clean history, where each commit gets you a working state (not some in-between broken revision). So it's to support all those devs who do not create patch sets. There are some suggestions like setting history.immutable in .arcconfig or invoking land with --merge. Will try these the next time I use arc.

If there are multiple commits then a merge commit can serve to logically group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit.

I also wonder what is the preferred way of viewing history for most of the people. I either use `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits explicitly visible. The former two just collapse everything into a linear history and is such a setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps people who tend to use gitk are more keen on merge commits? Janek

For instance, in the case of Geoff's recent fix,

$ git log --graph --oneline origin/master * e5a0a89 Suppress substitution assertions to fix tests * a883c1b Missing @since annotations in GHC.Generics * f8e2b7e Minor doc fixes to GHC.Generics * 34519f0 When encountering a duplicate symbol, show source of the first symbol * 669cbef Fix Trac issue #11487.

|\ | * 6544f8d Properly track live registers when saving the CCCS. | * 90f688e Code formatting cleanup. | * 4d0e4fe Add type signatures. |/

* b61f5f7 Put docs in /usr/share/doc/ghc-<version>

Here we see that those three commits were developed on a feature branch, which was then merged into master in 669cbef.

For what it's worth I quite like this practice. That being said, in GHC we rarely have changes broken up into multiple commits like this, in part due to Phab's poor support for fine-grained changes.

Cheers,

- Ben

--- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

On 02/01/2016 09:44 AM, Jan Stolarek wrote:

...

If there are multiple commits then a merge commit can serve to logically group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit.

In a purely linear history, it is not immediately clear how the commits are grouped---there is just a single stream of commits, so in effect, there is only one "group."

I also wonder what is the preferred way of viewing history for most of the people. I either use `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits explicitly visible. The former two just collapse everything into a linear history and is such a setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps people who tend to use gitk are more keen on merge commits?

I use gitk extensively, so perhaps that's why I like using empty merge commits to mark groups of patches. This lets me scroll through the repo history and see when major features landed. For my recent fix, I can see why one might prefer a fast-forward merge. But for feature branches that have 10-15 (or more) commits, especially when multiple people have contributed to a feature branch, an empty merge commit marks (and documents) that this group of patches implements a significant feature. If these 10-15 commits were merged fast-forward, then it would not be immediately obvious that they were all part of the same group, nor would it be obvious from scrolling through the history that they were all part of significant feature X landing. If one doesn't use gitk, I can see why empty merge commits would not be so appealing. In the past, the GHC history has been littered with merge commits, some of them non-empty, often because of a git pull without --rebase. So our history is certainly not merge free---even recently. I would agree that those kinds of merges are not desirable, and non-empty merge commits are especially unpleasant. Squashing large change sets into a single patch is also undesirable---it makes figuring out exactly what changed more difficult and makes bisecting less useful. Again, I'm not trying to impose a workflow---I just wasn't sure if there was a new recommended workflow. Cheers, Geoff

...

For instance, in the case of Geoff's recent fix,

$ git log --graph --oneline origin/master * e5a0a89 Suppress substitution assertions to fix tests * a883c1b Missing @since annotations in GHC.Generics * f8e2b7e Minor doc fixes to GHC.Generics * 34519f0 When encountering a duplicate symbol, show source of the first symbol * 669cbef Fix Trac issue #11487.

|\ | * 6544f8d Properly track live registers when saving the CCCS. | * 90f688e Code formatting cleanup. | * 4d0e4fe Add type signatures. |/

* b61f5f7 Put docs in /usr/share/doc/ghc-<version>

Here we see that those three commits were developed on a feature branch, which was then merged into master in 669cbef.

For what it's worth I quite like this practice. That being said, in GHC we rarely have changes broken up into multiple commits like this, in part due to Phab's poor support for fine-grained changes.

Cheers,

- Ben

The sometimes-torturous history is not of interest to later readers. I would like to add as a big asterisk to this statement that in

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/02/16 18:11, Simon Peyton Jones wrote: practice, big features often break things in subtle ways that are only noticed some time later. It then becomes comparatively trivial to hunt down the error by bisecting ten 25 line commits, when the converse is figuring out a 250+ lines patch. Obligatory "I'm not trying to impose anything". - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWsLUQAAoJENQqWdRUGk8BcN8P/2GVXf9IGjdJGosd/clyGrc/ uqW4+aLmS1jQyhKtbSlHCNA5UaGdB9QvqHLisRZ5itIDM5DqBFurmZwIB48M0csH qGcw9XaT8UuGnaC204+pdROtgW5xo0Ty6P0DvoilDt2NzowYuzpGq8B7CbfCnrhj maxbHG+ZY7YURx8MWeh3pedQC21bcdirppfPcFzjJHs1bwb9GAMgrwqK4LwNWA3B lM0nuoMgujE3tGUTHzAWi88Xe3MFE2seXKlrwSfP7Y0ZrnRmWbGc/Ltc4TfkUyWB dotdaf0NMlcQHyMAybskzrtmpXfMSN6eGrFtjsT220XgTtPG1xG4uHqJETuOh5yJ 9/tTGY8n3YKuCezl26sNjES/W/3jstUfMb8k3p3sqRbvKnJiu5xtGPfboYv6rLN4 B50ZuWIgGCIX2d3b1r09exqlqLvPJp6xGGOwRiCjvcUATNciI1jMXNgeItyeJ33B qm6cvU/1/iQtWfhGEe6HSbOuwO0VFKZ4wG0a1UzGHpBlOoXIhC86ay5Wv2jbutPJ A/4bXKq9w2xDgc75JxIXdM/1DzaZcZ+nHtQ+XNWMUGGbPbxmM2rG+YLfycSAn36q ORpEsRbPCgWmJj+gWftTvYXViDiozqFoMa9cFj0dUjjj8BZ5Qi2egUy4wcTjnhmz FdngEw8YKh9Wq3WF57Bp =sABc -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/02/16 15:20, Brandon Allbery wrote:

Only if it builds and passes tests across all ten commits. Yes, obviously. I have never worked anywhere where breaking commits were allowed, and I did not intend to suggest that breaking commits were a Good Idea or useful. They emphatically aren't.

Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWsLv1AAoJENQqWdRUGk8BlqoQAL++7E0p4saLgBVeH0Fe15VT rzCb5zd8el+nonR+ln+9bebZ8O7zpnjklDQ3OtcgOLQw5FG+CDVKRnlzKUPds9at hm5EWjDOhHTkIGVeQdW/q5kACr2egR+UDJx15sP7A2uRepkI0SB9r2XyquZuAozK Wswh39x1tp4x4W2SK4ikIgPCezqi05AMrxOX6O1qCUg8lMCJ0b/5VLQ3lNEcIdY9 Qs97Eo78WyNb2C/gqD/V8m3E9RO2X9iB665BsDlsO7pqaDgaas1SORqgOfXf+gFm pjmXUIrmKMvG+EZqGAZbEW1jjZBE0ESnv2C1mM502nwpJL4x3V+htOJruBp9zt+u 3wQJnqNhxiVaCJhUMjvuJFDQrdnyXgYolTDO7VmVtJITBcJODAcG6m3X+maqXvOL JfZcbKXoCO1GTUI+sasD7f78Q1oHBmHBctaD+26aHzDjKkyQ+kTfHi/eo09xVst3 T6VK1ht5NgOXQtMFVW3Bf0z51w56O1M0B+UkER4htIZvOOj85IWvtemzmKzWydlx J1WNjqRg0w5+92B9mvvJfqjCKGakaaVJwBdg6VLLHVszgFfbaTnJ8eI1Kf15izrs eQmrpg40d02wksjtjExdeAC5vs/9QvxYKzF9wr2U5kENLoh214Xy23oD+hMmFE7X k7jlHUrJqTNWAZ07J1MZ =fptS -----END PGP SIGNATURE-----

What if there were an official place to keep dirty histories? For example, my TypeInType patch has a very long, very tortuous history. Probably the majority of commits don't compile. (On a development branch meant for private use, I see no good reason to insist that each commit builds.) I would never want that history to join the main repo. But I've made sure that I keep access to it, just in case. It's all publicly available on github. The problem is that only I know where to find it. If we had an official "dump your dirty history here" repo, perhaps that would be helpful when disaster strikes. Richard On Feb 2, 2016, at 9:49 AM, Brandon Allbery wrote:

On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen wrote: On 02/02/16 15:20, Brandon Allbery wrote:

...

Only if it builds and passes tests across all ten commits. Yes, obviously. I have never worked anywhere where breaking commits were allowed, and I did not intend to suggest that breaking commits were a Good Idea or useful. They emphatically aren't.

The point is, this only applies once it's in the ghc repo. Works in progress may well have such commits as long as they are cleaned up on pushing --- which is why you would squash commits together losing intermediate history, which is what started this thread. (This point was actually made earlier in the thread, just not in so many words.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Jan Stolarek writes:

...

If there are multiple commits then a merge commit can serve to logically group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit.

I also wonder what is the preferred way of viewing history for most of the people. I either use `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits explicitly visible. The former two just collapse everything into a linear history and is such a setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps people who tend to use gitk are more keen on merge commits?

Indeed I make quite frequent use of gitk (even git log --graph is pretty usable). Cheers, - Ben