Chris Packham <judge.pack...@gmail.com> writes:
> On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gits...@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?
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
