On Wed, Apr 6, 2016 at 10:24 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Chris Packham <judge.packham@xxxxxxxxx> 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.
Correct and that was when the developer in question realised he had a problem.
> 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.
>
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.
If you do want do want to re-write history you can still do so either
by not setting @{upstream} or setting core.IKnowWhatImDoing = 1.
--
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