* Re: Rebasing published branches?
2012-11-06 20:18 Rebasing published branches? Josef Wolf
@ 2012-11-06 22:53 ` Andrew Ardill
2012-11-06 23:14 ` Antony Male
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Ardill @ 2012-11-06 22:53 UTC (permalink / raw)
To: Josef Wolf, git@vger.kernel.org
Hi Josef,
On 7 November 2012 07:18, Josef Wolf <jw@raven.inka.de> wrote:
>
> Hello,
>
> I know, I should never rebase published branches. But...
>
> I frequently work on different computers and would like to share my private
> branches across them. When done and the feature is in a good shape, I'd like
> to rebase to clean up history before I make it available to other people.
>
> I guess rebasing such branches would be OK as long as I can reliably remember
> to delete those branches on _all_ the clones I ever created.
>
> But waht if I ever make a mistake? How would one recover from such rebase
> disasters? Anybody knows a good description how such a recover would be done?
The only real problem you should encounter is not knowing which
repository holds the 'true' feature branch, that is the one which you
want to publish.
The reason why rebasing public branches (where 'public' means somebody
_else_ is tracking your branch) is bad is that you are rewriting
somebody else's history. This can cause headache and pain for them if
they have based work off what you have already published.
In your situation, you are the only one working on these feature
branches, and you know that you plan to rebase them. There is little
risk of you rewriting someone else's history, and even if you did it
is clear that these branches were always meant to be rebased so you
should surprise anyone.
As a practical note, you'll probably find it easier to keep track of
the current state of your feature if you use one repository as your
own 'blessed' repository. After working on a clone somewhere, always
push to the blessed repository, and sync from it before you start
work. This way you will always have the correct version of your
feature branch.
If worse comes to worse (somehow) remember that rebasing does not
delete the old commits, just recreates them and points the branch at
the recreated versions. The old versions of these commits should be
available in the reflog, at least for a few weeks after the rebase.
Regards,
Andrew Ardill
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Rebasing published branches?
2012-11-06 20:18 Rebasing published branches? Josef Wolf
2012-11-06 22:53 ` Andrew Ardill
@ 2012-11-06 23:14 ` Antony Male
1 sibling, 0 replies; 3+ messages in thread
From: Antony Male @ 2012-11-06 23:14 UTC (permalink / raw)
To: Josef Wolf, git
On 06/11/2012 8:18 pm, Josef Wolf wrote:
> Hello,
>
> I know, I should never rebase published branches. But...
The major trouble with making rewritten branches public is one of merges.
Assume I have two local repos, A and B, sharing a single remote. I
create a branch in A, push it to the remote, then fetch it into B. I
then re-write the branch in A and force-push it, and fetch from B.
As far as B is now concerned, its local history diverges from the
remote's -- a scenario which must be resolved, usually through a merge,
before any work can be pushed. Unfortunately, this merge merges together
the two versions of history -- the old one from B's local history, and
the new one from the remote -- leading to a mess. If B then pushes, this
mess is published.
So "published", in the "don't rewrite published branches" sense, means
"a branch which someone else might regularly pull from, and in doing so
merge together two versions of history".
In general, remembering that you've pushed rewritten history, and to
makes sure that you haven't merged two versions of history after a
merge/pull, is sufficient. After rewriting history on a remote, rebase /
pull --rebase on a local, un-rewritten branch is sufficient to avoid the
merging-two-versions-of-history nightmare.
See "RECOVERING FROM UPSTREAM REBASE" in man git-rebase for a more
in-depth explanation and more discussion of solutions.
> I frequently work on different computers and would like to share my private
> branches across them. When done and the feature is in a good shape, I'd like
> to rebase to clean up history before I make it available to other people.
Rebasing a branch which is about to be deleted (after merging,
presumably) is generally regarded as fine, provided you're not expecting
people to base work on the branch before it's rewritten.
Antony
^ permalink raw reply [flat|nested] 3+ messages in thread