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.
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.
--
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