changing history once public

John J. Franey· May 30, 2008, 21:24 UTC · lore

I think I understand the issue with changing history on branches that have been made public.

What is the negative of publishing a branch and not being able to apply history changing commands?

If I want to keep this branch current (in public), I would pull from the tracking branch resolve conflicts and push to my public repo. This action leaves my commit as the parent of another commit; it is not longer at HEAD. Does it matter if my commit is no longer HEAD of my branch?

I think the downside of not keeping my branch current is that I'd be handing off to my colleagues the task of resolving merge conflicts. Is that right?

Thanks, John

Jon Loeliger· May 30, 2008, 21:37 UTC · re: John J. Franey · lore

Re: changing history once public

John J. Franey wrote:

Show 5 quoted lines

> I think I understand the issue with changing history on branches that
> have been made public.
> 
> What is the negative of publishing a branch and not being able to apply
> history changing commands?

If there is something in that history you want to "remove", it must be done as an inverse patch, or an additional "removal" patch. You can't just change the history by backing it up and writing it differently.

> If I want to keep this branch current (in public), I would pull from the
> tracking branch resolve conflicts and push to my public repo.

Right.

> This
> action leaves my commit as the parent of another commit; it is not
> longer at HEAD.  Does it matter if my commit is no longer HEAD of my
> branch?

Uh, by definition HEAD is the current-most commit on your active branch, right?

HTH, jdl