Re: first parent, commit graph layout, and pull merge direction

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

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