git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Keeping <john@keeping.me.uk>
Cc: Andreas Krey <a.krey@gmx.de>,
	John Szakmeister <john@szakmeister.net>,
	git@vger.kernel.org
Subject: Re: first parent, commit graph layout, and pull merge direction
Date: Thu, 23 May 2013 09:01:15 -0700	[thread overview]
Message-ID: <7vd2shheic.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130523110839.GT27005@serenity.lan> (John Keeping's message of "Thu, 23 May 2013 12:08:39 +0100")

John Keeping <john@keeping.me.uk> writes:

> I've been annoyed by this at $DAYJOB recently.  A lot of people seem to
> blindly "git pull" without much thought about how the history is ending
> up and what they actually want to do.

I think these two are essentially the same thing, and having an
option to flip the heads of a merge only solves a half of the
problem.

A merge that shows everybody else's work merged into your history
means you are the integrator, the keeper of the main history.  And
the first-parent view of the history is useful only when the keeper
of the main history takes good care of the main history.

When you are using a "central shared repository" workflow, if you
had and used an option to flip the heads of a merge to record what
you have done so far as a side branch of what everybody else did to
do the merge, or if you rebased your work on top of what everybody
else did, the first-parent view would make a bit more sense than
what you currently get.  At least, everybody else's work will not
appear as a side branch that does 47 unrelated things, and your work
will appear as a side branch.  That is a big plus.

But the other half of the problem still remains, i.e. "what they
actually want to do".  People tend to do too many "pull" when their
work is not ready, only to "catch up", and that is the real problem.

Instead of having a nice "these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully" history that explains how these commits were
related and these commits are the full solution to a single issue:

      x---x---x---x---x---x
     /                     \
 ---o---o---o---o---o---o---M---o---o---...

they end up with something like this, even with the "flip the heads
of a merge" option, by pulling too often:

      x---x   x---x---x   x
     /     \ /         \ / \
 ---o---o---M---o---o---M---M---o---o---...

The result fragments otherwise a logical and clean "single strand of
pearls to fully address the issue, consisting of 6 commits", into
separate and seemingly unrelated pieces.

Imagine that other people are working the same way, and the commits
marked with 'o' are merges of side branches they add their half-way
work to the main history similar to what happened in the second
illustration above.  You would get this history:

      x---x   x---x---x   x
     /     \ /         \ / \
 ---o---o---M---o---M---M---M---o---o---...
             \     /
              y---y 

Nothing, other than the labels I used in the picture, ties these
'x's together while differentiating them from 'y's, so you lost an
important information.  Unless people stop doing that too many
"pull"s that are used only to "catch up", even with the "flip the
heads of a merge" option, you will not get a history that yields a
good first-parent view.

That gets back to what I said in the second paragraph of this
message.  When you "pull" from the central shared repository, with
the "flip the heads of a merge" option, you are acting as the keeper
of the main history at that point, and you are responsible for
taking good care of it.  If you make a 2+3+1=6 mess as depicted in
the last illustration above, you are failing to do so.

One obvious way to solve it is to use a topic branch workflow (the
first picture above; 'x's are built not on local 'master'), and you
do a "git pull" from the shared repository while you are on your
'master', which is free of your 'x's until that 6-commit series is
complete and ready.  Then you locally merge that topic branch and
push it back for everybody to see, which will give you the first
picture in this message.  Incidentally, this does not need the "flip
the heads" option.

Solving half a problem is better than solving no problem, and
especially because not all changes need to be multi-commit series
but can be done directly, perfectly and fully on the local 'master'
(i.e. 2+3+1=6 split would not happen for such changes).  For these
reasons, I personally am not strongly opposed to a "flip the heads"
option, if implemented cleanly.

But people need to realize that it is not solving the other half, a
more fundamental problem some people have in their workflow.

  reply	other threads:[~2013-05-23 16:01 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 11:50 first parent, commit graph layout, and pull merge direction Andreas Krey
2013-05-22 18:07 ` Junio C Hamano
2013-05-23  9:06   ` Andreas Krey
2013-05-23  9:48     ` John Szakmeister
2013-05-23 10:07       ` Jeremy Rosen
2013-05-23 10:29       ` Andreas Krey
2013-05-23 11:08         ` John Keeping
2013-05-23 16:01           ` Junio C Hamano [this message]
2013-05-23 16:41             ` John Keeping
2013-05-23 21:01               ` Junio C Hamano
2013-05-23 21:55                 ` John Keeping
2013-05-23 21:59                   ` Felipe Contreras
2013-05-23 22:11                   ` Junio C Hamano
2013-05-23 22:46                     ` Felipe Contreras
2013-05-23 22:54                       ` Junio C Hamano
2013-05-23 23:09                         ` Felipe Contreras
2013-05-23 23:26                           ` Junio C Hamano
2013-05-23 23:53                             ` Felipe Contreras
2013-05-24  8:29                               ` John Keeping
2013-05-24  9:38                                 ` John Szakmeister
2013-05-24  0:03                     ` Linus Torvalds
2013-05-24  0:21                       ` Junio C Hamano
2013-05-24  0:24                         ` Linus Torvalds
2013-05-24  0:25                         ` Felipe Contreras
2013-05-24  0:32                           ` Felipe Contreras
2013-05-24 16:26                             ` Junio C Hamano
2013-05-24 20:47                               ` Philip Oakley
2013-06-27 19:48                       ` [PATCH] pull: require choice between rebase/merge on non-fast-forward pull Junio C Hamano
2013-06-27 20:10                         ` W. Trevor King
2013-06-27 21:20                           ` Junio C Hamano
2013-06-28  1:08                             ` W. Trevor King
2013-06-28  6:34                           ` Matthieu Moy
2013-06-28  9:09                             ` W. Trevor King
2013-06-28 11:52                               ` Matthieu Moy
2013-06-28 12:28                                 ` W. Trevor King
2013-06-27 20:11                         ` Fredrik Gustafsson
2013-06-27 20:49                           ` Junio C Hamano
2013-06-27 20:30                         ` W. Trevor King
2013-06-27 20:58                           ` Junio C Hamano
2013-06-27 22:16                         ` Matthieu Moy
2013-06-28  1:19                           ` W. Trevor King
2013-06-28  8:09                         ` John Keeping
2013-06-28 17:22                           ` Junio C Hamano
2013-06-28 17:42                             ` John Keeping
2013-06-28 22:41                               ` Junio C Hamano
2013-07-02 21:18                                 ` John Keeping
2013-07-14 15:03                                 ` [PATCH] fixup! " John Keeping
2013-07-15  4:23                                   ` Junio C Hamano
2013-08-28 23:22                                 ` [PATCH] " Felipe Contreras
2013-07-18 14:30                         ` John Keeping
2013-07-18 17:38                           ` Andreas Schwab
2013-07-18 18:00                             ` Junio C Hamano
2013-07-18 19:35                               ` [PATCH v2] " Junio C Hamano
2013-07-19  0:54                                 ` Eric Sunshine
2013-07-19 16:22                                   ` Junio C Hamano
2013-07-19 20:29                                     ` Eric Sunshine
2013-07-19 22:20                                       ` Junio C Hamano
2013-07-19 22:30                                         ` Eric Sunshine
2013-07-19 22:55                                           ` Junio C Hamano
2014-01-22 19:08                                 ` Flimm
2013-05-24 17:11             ` first parent, commit graph layout, and pull merge direction Andreas Krey
2013-05-24 19:23               ` Junio C Hamano
2013-05-23 19:25     ` Andreas Krey
2013-05-24  9:29       ` Holger Hellmuth (IKS)
2013-05-24 13:42         ` Andreas Krey
2013-05-24 15:05           ` Holger Hellmuth (IKS)
2013-05-24 17:24             ` Andreas Krey
2013-05-23 11:34 ` Felipe Contreras
2013-05-23 12:21   ` Andreas Krey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd2shheic.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=a.krey@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    --cc=john@szakmeister.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).