Best practices for merging?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practices for merging?

Geoffrey Mainland
I've been away from GHC for a while, and it's not clear to me what the
best practices for merging are now.

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. This lets me look at the repo history
and easily see where a feature branch landed and get a good idea of what
changes it contains. I have used this approach in the past with GHC,
e.g., SIMD support and typed TH.

For smaller sets of changes, I might skip the merge commit, but I still
break up my changes into discreet bits, which helps anyone reading the
change set to see what's going on.

It seems the current policy is to submit changes via Phab and then,
after approval, squash everything into a single patch and apply it with
arc. At least that is my reading of
https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews.
Is that what I should be doing?

For feature branches, is that also what is advised?

Thanks,
Geoff

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Joachim Breitner-2
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.

Greetings,
Joachim



--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Tuncer Ayaz
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?
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Geoffrey Mainland
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!

Cheers,
Geoff
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Tuncer Ayaz
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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Jan Stolarek
In reply to this post by Geoffrey Mainland
> rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward.
I was under the impression - perhaps incorrect - that it is our policy to avoid merge commits, ie.
do only fast-forward merges. And when I look at git history I see very few merge commits.

> This lets me look at the repo history and easily see where a feature branch landed and get a
> good idea of what changes it contains.
I always considered merge commits to be obscuring history, both making it hard to read and
understand. Two commits instead of one does not sound desirable. And you can always see what
changes were introduced by a patch, with or without merge commit. But perhaps I am missing
something here.

Janek

> This lets me look at the repo history
> and easily see where a feature branch landed and get a good idea of what
> changes it contains. I have used this approach in the past with GHC,
> e.g., SIMD support and typed TH.
>
> For smaller sets of changes, I might skip the merge commit, but I still
> break up my changes into discreet bits, which helps anyone reading the
> change set to see what's going on.
>
> It seems the current policy is to submit changes via Phab and then,
> after approval, squash everything into a single patch and apply it with
> arc. At least that is my reading of
> https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews.
> Is that what I should be doing?
>
> For feature branches, is that also what is advised?
>
> Thanks,
> Geoff
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


---
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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Best practices for merging?

Simon Peyton Jones
In reply to this post by Geoffrey Mainland
I'm no git expert here, but

* Feature branches typically have lots of intermediate fixups.
  We don’t want that sequence in the main history; it's like
  watching sausage being made, and many intermediate points may
  be broken.  Better to have one big, coherent commit.

* If a feature branch really has several independent pieces, then
  yes, it'd be better to make several commits.  Perhaps Phab doesn't
  support this well.  In that case, would it make sense to make
  each into a separate Phab ticket?

* I have no idea what an "empty merge commit" is, or why it might
  be better that "a commit".
 
  After all, a fast-forward commit is no different to cloning, doing
  a very quick job on the feature, and committing.

What am I missing?

Simon

| -----Original Message-----
| From: ghc-devs [mailto:[hidden email]] On Behalf Of Geoffrey
| Mainland
| Sent: 31 January 2016 18:11
| To: [hidden email] Devs <[hidden email]>
| Subject: Best practices for merging?
|
| I've been away from GHC for a while, and it's not clear to me what the
| best practices for merging are now.
|
| 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. This lets me look at the repo history
| and easily see where a feature branch landed and get a good idea of what
| changes it contains. I have used this approach in the past with GHC,
| e.g., SIMD support and typed TH.
|
| For smaller sets of changes, I might skip the merge commit, but I still
| break up my changes into discreet bits, which helps anyone reading the
| change set to see what's going on.
|
| It seems the current policy is to submit changes via Phab and then,
| after approval, squash everything into a single patch and apply it with
| arc. At least that is my reading of
| https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews.
| Is that what I should be doing?
|
| For feature branches, is that also what is advised?
|
| Thanks,
| Geoff
|
| _______________________________________________
| ghc-devs mailing list
| [hidden email]
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0b2671ff9bed4a35ddd108
| d32a69d7a9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XIbsIBRwd3bLRha9OjVxw
| jdyEas6qnTNnciHvjCyC9E%3d
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Best practices for merging?

Ben Gamari-2
Simon Peyton Jones <[hidden email]> writes:

> I'm no git expert here, but
>
> * Feature branches typically have lots of intermediate fixups.
>   We don’t want that sequence in the main history; it's like
>   watching sausage being made, and many intermediate points may
>   be broken.  Better to have one big, coherent commit.
>
> * If a feature branch really has several independent pieces, then
>   yes, it'd be better to make several commits.  Perhaps Phab doesn't
>   support this well.  In that case, would it make sense to make
>   each into a separate Phab ticket?
>
> * I have no idea what an "empty merge commit" is, or why it might
>   be better that "a commit".
>  
>   After all, a fast-forward commit is no different to cloning, doing
>   a very quick job on the feature, and committing.
>
If there are multiple commits then a merge commit can serve to logically
group them. 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Jan Stolarek
> 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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Erik Hesselink
On 1 February 2016 at 15:44, Jan Stolarek <[hidden email]> wrote:
> 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?

Just as a side-note: git log has a --no-merges option to show only
non-merge commits. That might make your experience a little better
when working on such code bases. Alternatively, you can pass --graph
(best combined with something like --oneline) to view a gitk like
graph that shows the merges.

Erik
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Geoffrey Mainland
In reply to this post by Jan Stolarek
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
>


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Ben Gamari-2
In reply to this post by Jan Stolarek
Jan Stolarek <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Richard Eisenberg-2
I have this in effect:

alias gitlog='git log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"'

I didn't come up with the incantation (and I forget the source), but it has obviated entirely my use of gitk. I use this command many times a day.

Richard

On Feb 1, 2016, at 11:04 AM, Ben Gamari <[hidden email]> wrote:

> Jan Stolarek <[hidden email]> 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
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Best practices for merging?

Simon Peyton Jones
In reply to this post by Geoffrey Mainland

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

My personal preference is:

* Always squash the "sausage-being-made" commits of a feature branch.
  The sometimes-torturous history is not of interest to later readers.

* If a feature-branch-author is willing to take the time to break the
  feature into a bunch of related sub-feature, each with its own, documented,
  self-contained commit -- then excellent!

* Avoid non-empty merge commits.

* I'm agnostic about the empty-merge-commit thing, but now I can see the
  logic and am fine with having them.

The guiding principle is: keep information that is valuable in later years;
discard noise that will simply be distracting in later years.


But like Geoff I'm not trying to impose anything, since I regard myself
as a git amateur.

I'd love someone to write down the result of this
conversation in our working conventions.

Simon

|  
|  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
|  >
|  
|  
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c41dd179c03104456
|  6c7608d32b1be29a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y%2buUjGT
|  9llfuw4mmRZA3TdL%2fmAKhx2pL3954UZN6Y5c%3d
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Alexander Berntsen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/02/16 18:11, Simon Peyton Jones wrote:
> 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
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
[hidden email]
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-----
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Brandon Allbery
On Tue, Feb 2, 2016 at 8:54 AM, Alexander Berntsen <[hidden email]> wrote:
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.

Only if it builds and passes tests across all ten commits.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Alexander Berntsen
-----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
[hidden email]
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-----
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Brandon Allbery

On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Richard Eisenberg-2
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 <[hidden email]> wrote:


On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Best practices for merging?

Brandon Allbery
On Tue, Feb 2, 2016 at 9:55 AM, Richard Eisenberg <[hidden email]> wrote:
What if there were an official place to keep dirty histories?

git actually has a place for these, although at a price: when you squash commits or otherwise modify history, the originals are retained in the reflog. By default the reflog gets cleaned periodically, and letting it grow without bound has a performance impact, but in theory it could be used to keep this information.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs