Re: Triangular workflows and some anecdotes from the trenches

> Chris Packham <judge.packham@gmail.com> writes:
>
>> We ran into something at $dayjob the other day. The actual problem was
>> a developer ended up amending a commit that had already been pushed.
>> It happens occasionally and is usually recoverable with a simple
>> rebase and is generally a learning experience. In this particular case
>> however things were a bit more complicated.
>
> Developer ending up amending is not an issue per-se, unless the
> result is pushed back to the public.

> However, it would be nicer if "git commit --amend", "git rebase",
> "git branch -f", and "git checkout -B" notices the situation and
> warns about what would happen.
>
>>   git config alias.amend '!git merge-base --is-ancestor HEAD
>> @{upstream} || git commit --amend'
>>
>> I'm just wondering if something more official can be added to git
>> commit --amend (and probably git rebase).
>
> 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.
>