www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [1/2] git commit: f92a685 -
Date Wed, 06 Jun 2012 13:26:06 GMT

On Wed, Jun 6, 2012 at 2:45 PM, Brett Porter <brett@apache.org> wrote:
> Sorry, but I don't follow. I excluded work on different branches from this
> (which is what svn:mergeinfo represents).

In Git each clone has it's own set of local branches. Thus the work
you do on your local "master" branch needs to be merged with
concurrent changes in the remote "master" branch before they can be
pushed. The merge commits in Git preserve this information.

Sometimes there isn't much value in keeping such information around,
in which cases using rebase is OK, but often the extra information in
the merge commits can indeed become handy.

> Can you describe a use case where it is useful to retain merge information
> between master and origin/master on a clone?

A common case is if you post your changes up for review (RTC, pull
request, etc.) before pushing them to the shared repository. Consider
what happens if someone else takes your changes before they've been
pushed and makes some followup changes. If you then use rebase before
pushing your changes, you break the version history for that other

Another, more subtle but sometimes quite useful benefit is that a
merge or a rebase may result in subtle bugs if the other, concurrent
commits affect the assumptions on which your changes rely. When
working with patches or with svn there's no way to record such
information, but with Git (unless you use rebase) your original commit
retains information about the base state against which your changes
were made. That extra information makes it possible to later on (when
you no longer remember the details) detect whether a problem was
introduced by the changes you made or by the act of merging them with
other, concurrent changes.

> Are you saying this is something you'd find helpful to you if other people on a
> project did, or that it's a preference you have for the way you work yourself?

I don't feel too strongly about this, but in general I find the extra
information in merge commits worth the added complexity of a
non-linear version history. Other people and projects may well prefer
a different tradeoff. I just want to help prevent cases where such
decisions are made based on insufficient tooling support.


Jukka Zitting

View raw message