Re: Triangular workflows and some anecdotes from the trenches

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 6, 2016, 17:01 UTC
Message-ID: <xmqqbn5my8m1.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAFOYHZDx1cqwUnR9E=RQKboSfF4gWDjERvEWQA_YePZq64QarQ@mail.gmail.com>

Chris Packham <judge.packham@gmail.com> writes:

Show 6 quoted lines

> On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Developer ending up amending is not an issue per-se, unless the
>> result is pushed back to the public.
>
> Correct and that was when the developer in question realised he had a problem.

But then "push" would have failed and correcting would all be local, no?

Show 22 quoted lines

>> A bigger problem may be how you make sure everybody sets up
>> @{upstream} correctly.  You may fork your own copy of a branch from
>> the target branch, start working on it, further fork other branches
>> on your work to experiment different approaches, with the intention
>> to later use the best one to update your first fork.
>>
>> At which point, the @{upstream} of the secondary branches are your
>> own first branch, not the public one--which is not a problem per-se,
>> because your first branch (whose @{upstream} is the remote one) is
>> not yet public and you should be allowed to freely update it to
>> polish it by rewriting.  But then after you push out your first
>> branch as an interim snapshot to the public, you no longer want to
>> rewrite the commits reachable from it.  So (to put it mildly) it
>> would be quite complex to get all the corner cases right, and the
>> definition of "right" would probably depend on the exact workflow.
>
> I think you could still argue that if @{upstream} exists. Warn about
> (or disallow) re-writing anything anything that is reachable from it.
>
> There is still the possibility of if someone else rewinding
> @{upstream} on you and I think the scenario you've highlighted is just
> a case of doing it to yourself.

But at that point, you are not doing much to help the normal users. I was actually expecting a response with a different approach, e.g. instead of relying on @{upstream} that may or may not serve as a good check anyway, make sure nothing reachable from any of the refs in refs/remotes/* is not updated by amend or rebase.