Re: GIT vs Other: Need argument

Junio C Hamano [off-list ref] writes:

Steven Grimm [off-list ref] writes:

quoted

And in particular -- this being the original topic of the thread --
when an svn user sees me doing that, they do not immediately think of
the fact that merging between immutable revisions may have some
benefits. They see me typing four commands (commit, fetch, rebase,
reset) to do the same thing they can do in one command with svn, and
conclude that git is harder to use.

No arguments there.  While I know I will never use such a
workflow myself, I think it makes sense to _allow_ local
changes to be merged to the new revision if the user chooses to
use such a workflow.

Actually, there is one thing that makes this much easier to do
in SVN.  It is its centralized nature.

If you have this sequence:

	(1) update and sync with the repository
        (2) you work alone, without committing
        (3) while you do (2), other people make commits
        (4) you update from the repository

Because of its central nature, the commits made in (3) are
always proper descendant of the commit you are basing your work
on in (2).  So at point (4), the resolution you would need to
perform is this "merge".

          (2).............M?
         /               . 
	1-----3a-3b-3c-3d

    Notational convention: Solid lines and unparenthesized
    letters are actual commits and ancestry in these pictures.
    Letters in parentheses and dotted lines are locally modified
    states and derivations of these states from commits.

But because there is no "commit" that records the work you did
in (2) alone, you can afford to 3-way merge whatever conflict
you get at M and you do not even record M as a merge.  The
result simply becomes a proper descendant of 3, which is still
uncommitted local change.

                          (2')
                         .
	1-----3a-3b-3c-3d


The patch series I "vaguely recalled" in my previous message
handled this special case where the branch being merged
(i.e. 3d) was a fast-forward of the current commit (i.e. 1).

However, in git, you do not necessarily work that way.  As you
admitted, the ability to commit locally is what's different.


          2a---2b..(2c)...M?
         /               .
	1-----3a-3b-3c-3d

If (4) happened after you've accmulated local commits 2a, and
2b, and you have local changes (your state 2c is different from
your tip, 2b, but is uncommitted, and kept in the working tree
alone), you usually do not want to resolve the mess to make a
commit M, pretend M is a proper descendant of 3d, depending on
the final structure you are trying to achieve (the mess may come
from interactions between 3's and 2a or 2b, or interactions
between 3's and 2c).

There are three possible commit ancestry structures you would
want to eventually reach, and three distinct sets of steps to
reach those structures.

 1. Perfect what you were in the middle of, and then perform a
    merge.  IOW, you don't have to update from remote when you
    are not ready.

          2a---2b---2c----M
         /               / 
	1-----3a-3b-3c-3d

 2. Merge what has already been committed, excluding your
    unproven WIP that is in the working tree, and roll forward
    your local changes on top of it.

          2a---2b---------M..(2c')
         /               / 
	1-----3a-3b-3c-3d

 3. Always serialize by rebasing.  The structure you would want
    to end up with is like this:

                         2a'-2b'.(2c')
                        /
	1-----3a-3b-3c-3d

Among these three workflows, what is most natural in git is the
first one.  The tool natively supports it well.

For the second workflow, you would:

    2-a. first make a tentative commit 2c

	$ git commit

                 --2c
                /
          2a---2b
         /
	1-----3a-3b-3c-3d

    2-b. merge what was ready on your end and the other side:

	$ git checkout HEAD^ && git merge origin

                 --2c
                /
          2a---2b---------M
         /               / 
	1-----3a-3b-3c-3d

    2-c. roll forward the local change you have in 2c:

	$ git rebase --onto HEAD master
        $ git reset HEAD^

          2a---2b---------M...(2c')
         /               / 
	1-----3a-3b-3c-3d


This probably is the next best organization.  But you have to
realize that this requires you to resolve potential conflict
when creating M and then another conflict when rolling forward
your local changes.

    We probably could help automating this, but your "git pull"
    session transcript need to look like this:

	$ git pull origin
        First stashing away of your local changes...
	Resolving conflicts between 2b and 3d.
	Conflicted merge.  Please resolve and commit.
	$ edit ; test
        $ git commit ;# to record M
	Committed the merge result.
        You have stashed local changes further to roll forward.
        $ git unstash local-changes
        Resolving conflicts between M and 2c.
	Local changes conflicted during roll-forward.
        Leaving resulting mess in the working tree for you to sort out.
	$ 


To end up with the third graph, you would:

    3-a. first make a tentative commit 2c

	$ git commit

                 --2c
                /
          2a---2b
         /
	1-----3a-3b-3c-3d

    3-b. rebase

	$ git rebase origin

                          2a'--2b'--2c
                         /
	1-----3a-3b-3c-3d

    3-c. reset

	$ git reset HEAD^

                          2a'--2b'..(2c')
                         /
	1-----3a-3b-3c-3d


and I think that is what you have been doing.  Both the final
structure and the workflow are least "git-like" among these
three.

    If you want to automate this, you can use this four-liner
    shell script:

	#!/bin/sh
        git commit || exit
	git fetch origin || exit
        git rebase origin || exit
	git reset HEAD^

    Store this in $HOME/bin/git-sgpull, if you may, and you can
    even say "git sgpull" to invoke it.

    When 'rebase' does not get conflict, which is the bast case
    you are primarily complaining about, having to type three
    commands, this will run to the end with this single command
    and you will feel happier.

    When 'rebase' gets conflict, however, you would need to
    resolve and have it keep going, but that is something you
    cannot avoid.  You would need to remember that the final
    "reset HEAD^" needs to be issued from your shell, but that
    should be obvious.

Thanks for that detailed writeup. It squares pretty well with my 
understanding.


Junio C Hamano wrote:

          (2).............M?
         /               . 
	1-----3a-3b-3c-3d

[...]
                          (2')
                         .
	1-----3a-3b-3c-3d


The patch series I "vaguely recalled" in my previous message
handled this special case where the branch being merged
(i.e. 3d) was a fast-forward of the current commit (i.e. 1).
  

I think this is actually the case I'd be most concerned about getting 
right for those people who are coming from svn and want to change their 
workflow as little as possible at first. The class of people who would 
exclusively use an "svnish-commit" alias that did "git commit;git push" 
-- that is, who never do local commits -- would always find themselves 
with this setup.

 3. Always serialize by rebasing.  The structure you would want
    to end up with is like this:

                         2a'-2b'.(2c')
                        /
	1-----3a-3b-3c-3d
  

You are correct in pointing out later on that my fetch+rebase workflow 
fits this structure. And for my particular environment it's actually the 
only one I can use a lot of the time, because I'm usually pushing to a 
shared git-svn repository (or working in a git-svn repo of my own), from 
which the changes will get committed back to svn. Eric Wong has warned 
that git-svn doesn't deal well with merges; it expects linear history. 
So for now this is the structure I need to end up with, at least until 
git-svn learns how to deal with nonlinear ancestry, if that's even 
possible at all given svn's inherent limitations.

I look forward to the day when git has built up enough critical mass 
here that we can just switch over to it completely and ditch that kind 
of restriction. With that happy day in mind, I'd still love to see the 
other workflows made as painless as possible, so more comments below.

For the second workflow, you would:

    2-a. first make a tentative commit 2c
    2-b. merge what was ready on your end and the other side:
    2-c. roll forward the local change you have in 2c:

    We probably could help automating this, but your "git pull"
    session transcript need to look like this:

	$ git pull origin
        First stashing away of your local changes...
	Resolving conflicts between 2b and 3d.
	Conflicted merge.  Please resolve and commit.
	$ edit ; test
        $ git commit ;# to record M
	Committed the merge result.
        You have stashed local changes further to roll forward.
        $ git unstash local-changes
        Resolving conflicts between M and 2c.
	Local changes conflicted during roll-forward.
        Leaving resulting mess in the working tree for you to sort out.
  

I wonder if it makes sense to automate that even more and make git pull 
behave a bit statefully like rebase does:

    $ git pull origin
    Stashing local changes.
    Resolving conflicts, pass 1.
    Conflicts! Please resolve.
    $ edit ; test
    $ git pull --continue
    Committing revision M.
    Unstashing your local changes.
    Resolving conflicts, pass 2.
    Local changes conflicted during roll-forward. Sort it out.
    $

When git pull --continue does the commit, it *might* be nice for it to 
do a variant of commit -a: if the user has modified all the conflicting 
files, *and* not done an update-index on any of them manually, then do 
the update-index implicitly. (That "and" part would be to prevent it 
from tripping up experienced git users who want to manually mark the 
conflicting files as resolved by running update-index.) I'm not sure 
that's actually a good idea, though it'd save some commands most of the 
time; the danger, of course, is that you could end up committing a 
half-resolved file by accident. But then I guess there's nothing 
preventing you from doing that with update-index today.

But that's attractive because it's exactly two git commands in the most 
complex case (conflicts in the merge of committed revisions) and only 
one git command in the simplest cases (no conflicts or conflicts only in 
the working copy edits.) In the case of no working copy edits, 
--continue would just do the commit for you.

To make pull and rebase even more consistent, one could also allow git 
pull --abort to roll back the pull during a conflict resolution, whether 
or not it's a working-copy-edits one. People might find that a handy 
shortcut in other workflows too; it would probably just do a hard reset 
back to the pre-merge revision in the no-working-copy-edits case. 
Obviously that wouldn't be new functionality, just an arguably slightly 
more intuitive way to do it than what exists now.

    If you want to automate this, you can use this four-liner
    shell script:

	#!/bin/sh
        git commit || exit
	git fetch origin || exit
        git rebase origin || exit
	git reset HEAD^
  

Actually I think I like the idea of making that a little more robust and 
having it take a --continue option like I described above. No reason it 
can't keep track of its current state. I will spend some time this 
weekend doing that.

-Steve