Re: Triangular workflows and some anecdotes from the trenches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Packham <judge.packham@xxxxxxxxx> writes:

> On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gitster@xxxxxxxxx> 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?

>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]