Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 1, 2007, 20:18 UTC
Message-ID: <7vfxzpbtxv.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <3550D197-CA8C-4B06-9A95-3C7F18EBEFA7@zib.de>

Steffen Prohaska <prohaska@zib.de> writes:

Show 5 quoted lines

> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>
>> Steffen Prohaska wrote:
>>
>>> You're forced to do the integration immediately.

The context of this "forced" is that you say (in the following paragraph) the user's main objective was to "push", but I do not think "to push" is ever the main objective.

 - If it is to give integrated result for others to work further
   on, then you need to resolve before being able to achieve
   that goal.  There is no escaping from it.

 - On the other hand, if it is to show what you did as early as
   possible in a working shape, and if the updated shared
   repository has changes from somebody else that conflicts you,
   in a CVS/SVN style shared workflow, there is no way for you
   to show what you did in isolation.  If you try to follow that
   model in git and insist pushing to the same branch, then you
   are forced to resolve first.

   But you do not have to.  You could push out to another new
   branch, and say "Here is how you could do it, although this
   is based on an older codebase and conflicts with what
   recently happened to the tip".  You could even ask other
   party whose changes conflict with yours to help with the
   merge by saying "I pushed it out, you are more familiar with
   that area of the code and with your changes near the tip of
   the trunk, so could you merge it and push out the result?"

Show 6 quoted lines

>> Yes, but you get to choose how. Perhaps git-push should list more
>> options than just git-pull, such as the three commands required to
>> rebase the currently checked out branch onto its remote counterpart.
>> That would support more workflows.
>
> I agree. Providing better hints would be good.

I am not so sure about that. If there are three different workflows, should git-push give hints suitable for all of them?

The current hint was added in response to users' requests, and I think it could be generalized. What we would want the end user to realize is:

    What I tried to push out is stale, I do not want to push out
    something that does not contain what the other side has
    done, so I need to integrate my work with what the other
    side have before pushing to that branch at the remote.

    In my workflow, that means doing rebase of the branch I
    tried to push out on top of the remote branch I was trying
    to push to.

The second paragraph depends on the workflow. Do we want to (can we afford the space to) give a laundry list here? Probably not.

Show 8 quoted lines

>>> Your main objective was to push, but the shared workflow forces
>>> you to do the integration _now_ (by using pull). In a pull-only
>>> workflow, you can just push and defer the integration for later.
>>
>> No, you can also fetch + rebase.
>
> Right. My point was than one cannot defer the integration. It
> must be addressed immediately.

See above.

Show 14 quoted lines

>>> Some people claim fetch + rebase is superior to fetch + merge.
>>> The only point I can see is that fetch + rebase gives a linear
>>> history without loops, which is nicer to visualize. I recently
>>> asked on the list if there are any benefits of fetch + rebase
>>> over fetch + merge, besides a nicer visualization.
>>
>>
>> It's easier to bisect...
>> With a mostly linear history, this problem goes away.
>
> This is really an interesting point. I did not start to use
> git bisect regularly. But I certainly plan to do so in the future.
>
> Couldn't bisect learn to better cope with non-linear history?

It copes with it as best as it can.

Another thing to think about is how "everybody fetches, merges and pushes out" would interact with the concept of "mainline". Strictly speaking, the point of distributed development is that there is no mainline, but workflows based on "fetch + rebase" allows --first-parent to give a reasonable approximation of what people would naively expect how the mainline would look like. If everybody fetches, merges and pushes out, there is no "mainline" and --first-parent would give totally useless history.