Is there a way to add a default `--squash` flag for all merges into a head?

Is there a way to add a default `--squash` flag for all merges into a head?

[Dun Peal]

Hi,

Our main Git repository supports a lot of developers working on
multiple branches from master. Whenever the work on a branch is
finished, the branch-owning developer(s) merge it back to master. That
merge is always done with a `--squash` flag to avoid the 50+ levels
deep graph we would end up with if everyone just used a true merge.

There's a configuration feaute `branch.<name>.rebase` for specifying
that all merges into a branch (master in this case) would be done by
rebase, so I was expecting a similar feature for always squashing back
(since some developers may forget to add the flag). Unfortunately, I
couldn't find it. Does it exist?

Thanks, D.

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Andreas Schwab]

Dun Peal <dunpealer@gmail.com> writes:

> There's a configuration feaute `branch.<name>.rebase` for specifying
> that all merges into a branch (master in this case) would be done by
> rebase

That's not what it means.  It means that a "git pull" is implicitly "git
pull --rebase".  But if you do an explict merge it will not look at that
config setting.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Dun Peal]

Sigh. You're right, what a silly man I am!!!

I assume there's no way to do what I want, except maybe encourage
everyone to use an alias for `git merge` that includes the flag.

Thanks, D.

On Mar 7, 3:10 pm, Andreas Schwab <sch...@linux-m68k.org> wrote:
> Dun Peal <dunpea...@gmail.com> writes:
> > There's a configuration feaute `branch.<name>.rebase` for specifying
> > that all merges into a branch (master in this case) would be done by
> > rebase
>
> That's not what it means.  It means that a "git pull" is implicitly "git
> pull --rebase".  But if you do an explict merge it will not look at that
> config setting.
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Jay Soffian]

On Mon, Mar 7, 2011 at 2:28 PM, Dun Peal <dunpealer@gmail.com> wrote:
> There's a configuration feaute `branch.<name>.rebase` for specifying
> that all merges into a branch (master in this case) would be done by
> rebase, so I was expecting a similar feature for always squashing back
> (since some developers may forget to add the flag). Unfortunately, I
> couldn't find it. Does it exist?

Try:

  $ git config branch.<name>.mergeoptions --squash

j.

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Junio C Hamano]

Dun Peal <dunpealer@gmail.com> writes:

> Sigh. You're right, what a silly man I am!!!
>
> I assume there's no way to do what I want, except maybe encourage
> everyone to use an alias for `git merge` that includes the flag.

I have a strong suspicion that it is not really what you want to always
use --squash merge, and everybody forced (or "encouraged") by you to do so
would hate you in the end.

The solution to whatever problem you are trying to solve should not be to
discard one of the most valuable information git keeps track of to avoid
the CVS/(old)SVN mess when performing repeated merges with a branch.

I also suspect that you might be delighted by "log --first-parent -m".

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Dun Peal]

On Mar 8, 1:28pm, Junio C Hamano <gits...@pobox.com> wrote:
> The solution to whatever problem you are trying to solve should not be to
> discard one of the most valuable information git keeps track of to avoid
> the CVS/(old)SVN mess when performing repeated merges with a branch.

Junio, this seems viable precisely because we generally don't perform
repeated merges between the same heads.

All of our branches right now are feature branches of master, whose
short lives end with a single merge back. Thus, merging back as a
single patch implementing that single feature is ideal: the branch was
only created to implement the feature, so by definition all of its
individual commits are intermediary, and once the final feature state
is achieved, the incremental steps leading to it are not interesting
at all - they're just noise!

Why would John care that while implementing feature X, Jill committed
her half-state Y so she can go home, or made and fixed typo Z ?  In
fact, why would Jill care a day, let a lone a couple of months, after
X was completed and merged to master?

The noisy, needless nature of these commits is further emphasized by
the default behavior of commit graph visualizers to display them in
full rather than collapse them. We have over 80 developers working on
all major operating systems, and using a variety of tools on each.
`log --first-parent` is nice, but my developers also use gitk, gitg,
gitx, GitExtensions, and TortoiseGit.

Finally, we are planning to integrate a few key long-lived branches,
for example a 'bleeding_edge' branch that everyone commits to, and
gets periodically merged into master by a technical lead. The
collapsing behavior a-la `--first-parent` may not always be desirable
once we start doing that, but if you turn it off without mandating
squashes, master's history becomes a mess of numerous feature-branch
merges, with all of their non-informative intermediary commits.

Hope that makes sense, .D

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Junio C Hamano]

Dun Peal <dunpealer@gmail.com> writes:

> All of our branches right now are feature branches of master, whose
> short lives end with a single merge back. Thus, merging back as a
> single patch implementing that single feature is ideal: the branch was
> only created to implement the feature, so by definition all of its
> individual commits are intermediary, and once the final feature state
> is achieved, the incremental steps leading to it are not interesting
> at all - they're just noise!

You sounds as if none of your developers make mistakes and your reviewers
are always so perfect that you have absolute confidence that all the
possible bugs are killed in these feature branches before they are merged
to the master.

That does not sound like a real world to me, though.  When a fix or tweak
is needed for codepaths introduced by these feature branches after they
are merged to master, the cleanest thing to do is to queue the fix on top
of the branch that needs that fix or tweak, and merge that to master.

Of course, you can choose to abandon these feature branches that are
potentially buggy and fork a fix branch from the master branch that was
current when the bug happened to be discovered.  But that would make the
backporting bugfixes (or feature tweaks for that matter) to anything older
a lot harder.

> Why would John care that while implementing feature X, Jill committed
> her half-state Y so she can go home, or made and fixed typo Z ?  In
> fact, why would Jill care a day, let a lone a couple of months, after
> X was completed and merged to master?

Who is merging half-state to 'master' or merging 'master' back to the
feature branches?  I don't think any of the above relates to the topic of
'merge --squash' anyway...

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Dun Peal]

On Mar 9, 1:27 pm, Junio C Hamano <gits...@pobox.com> wrote:
> Dun Peal <dunpea...@gmail.com> writes:
> That does not sound like a real world to me, though. When a fix or tweak
> is needed for codepaths introduced by these feature branches after they
> are merged to master, the cleanest thing to do is to queue the fix on top
> of the branch that needs that fix or tweak, and merge that to master.
>
> Of course, you can choose to abandon these feature branches that are
> potentially buggy and fork a fix branch from the master branch that was
> current when the bug happened to be discovered. But that would make the
> backporting bugfixes (or feature tweaks for that matter) to anything older
> a lot harder.

That's a good point if feature branches may eventually get merged into
other branches, e.g. release branches. Our case is simpler: a feature
branch that branched off master will only get merged back to master,
usually in one merge action that ends the branch. Therefore any future
fixes or updates to content that got merged like that can properly be
committed directly to master.

Of course, if we did need to merge the feature independently into
other branches, the squashed branch and any future updates to it would
have to be manually cherry-picked - an error prone process that
forgoes many amenities that Git offers for this procedure. However,
since we do not have such a need, might as well optimize for commit
graph simplicity.

We probably could find ways to deal with a ~50-level-deep commit graph
(composed of 1 master and ~49 feature branches), but if we can instead
deal with a single-level-deep one (or 2-3 levels when we introduce a
couple of long-running branches), why shouldn't we?

> > Why would John care that while implementing feature X, Jill committed
> > her half-state Y so she can go home, or made and fixed typo Z? In
> > fact, why would Jill care a day, let a lone a couple of months, after
> > X was completed and merged to master?
>
> Who is merging half-state to 'master' or merging 'master' back to the
> feature branches?  I don't think any of the above relates to the topic of
> 'merge --squash' anyway...

If Jill merged her branch X back to master with no squashing, half-
state Y which got committed in X gets merged to master as well.

Half-states like Y get committed to feature branches all the time,
since those branches are private, never get deployed in production or
even built by the continuous integration server; the feature branch is
all about developer convenience, and we're only strict about what he
merges back into master.

Of course, Jill can selectively squash with `rebase -i` X to a more
presentable form before merging it back to master. But if she's
already squashing, why not use the ultimate, simplest squash offered
by `rebase --squash`, as it happens to perfectly fit the purpose of
our short-term feature branches?

D.

Re: Is there a way to add a default `--squash` flag for all merges into a head?

[Dun Peal]

On Mar 8, 1:29 am, Jay Soffian <jaysoff...@gmail.com> wrote:
> Try:
>
>   $ git config branch.<name>.mergeoptions --squash

Thanks, that works great and answers our need. Thanks to Junio as well
for the thorough discussion of our workflow.

.D