* request for documentation about branch surgery
@ 2009-07-06 23:05 Bruno Haible
2009-07-07 2:30 ` Elijah Newren
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Bruno Haible @ 2009-07-06 23:05 UTC (permalink / raw)
To: git
Hi,
Here are a few things that I would have expected to find in the Git user's
manual, chapter "Rewriting history and maintaining patch series"
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history>
It is meant for a user who does not yet know about "git rebase", "git merge",
"git reset" and the like. Organized by the goal that a user has ("how do I?").
1) After the section "Rewriting a single commit", it may be useful to
have a section "Inserting one or more new commits". This is something that
cannot be done with the "detached head" technique. I found this sequence
of commands useful:
If you want to add a commit in the middle of a branch:
A---C---...---Z master
=>
A---B---C---...---Z master
it is achieved by
$ git checkout A
$ git branch temp
$ git checkout temp
[make changes for B]
$ git commit -a
now:
A---C---...---Z master
\
--B temp
$ git checkout master
$ git rebase temp
$ git branch -d temp
2) About the section "Reordering or selecting from a patch series".
The "git rebase" documentation contains a good example:
Reordering, possibly merging, the last 5 commits:
$ git rebase -i HEAD~5
See "man git-rebase" under "INTERACTIVE MODE".
I find this technique very useful, because it guarantees that no
commit gets lost (unlike "git cherry-pick"). Maybe the section could
be split into two sections
"Reordering a patch series"
and
"Selecting from a patch series"?
3) When do I need "git merge", and when do I need "git rebase", in the
context of branch surgery?
The simple answer, that I would find worth mentioning, is:
- "git merge" copies commits from one branch to another.
- "git rebase" only moves commits around to make history more linear.
4) It would be good to have a section "Cutting branches"
How do I remove the N most recent commits from a branch?
D---E---F---G---H---.........---Y---Z master
=>
D---E master
It goes like this:
$ git checkout master
$ git reset --hard E
5) Then, it would be good to have a section "Replacing branches"
How do I copy the contents of a branch over to another branch, replacing
the recent development on that branch?
If you want to copy a branch into another, while throwing away commits:
F1---F2---F3 released
/
D---E---F---G---H---.........---Y---Z master
=>
F1---F2---F3 released
/
D---E---F1---F2---F3 master
This is achieved by
$ git checkout master
$ git reset --hard E # Cut the branch "master"
$ git merge released # Copy commits from branch "released" to "master"
6) Also, it would be good to have a section "Reconnecting branches after rebase".
If you want to reconnect a branch to a rebased master, here's how to do it:
/--C'--...---P'--Q'--...---Z' new rebased master
A---B---C---...---P---Q---...---Z old master
\
--BA---...---BZ release-branch
=>
A---B---C'--...---P'--Q'--...---Z' new rebased master
\
--BA---...---BZ release-branch
This is achieved by
$ git checkout release-branch
$ git rebase --onto P' P
This might seem exotic, but these use cases all came up while rewriting the
history after a "git cvsimport".
Bruno
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-06 23:05 request for documentation about branch surgery Bruno Haible
@ 2009-07-07 2:30 ` Elijah Newren
2009-07-07 3:45 ` Elijah Newren
2009-07-07 9:51 ` Bruno Haible
2009-07-07 2:50 ` Junio C Hamano
2009-07-07 18:28 ` Daniel Barkalow
2 siblings, 2 replies; 10+ messages in thread
From: Elijah Newren @ 2009-07-07 2:30 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
Hi,
It's been a long time since I read the user manual, so I'm only
comment to point out a few shortcuts (whether or not they're more
logical to present to new users) and clarifications on the usecases
you presented.
On Mon, Jul 6, 2009 at 5:05 PM, Bruno Haible<bruno@clisp•org> wrote:
> 1) After the section "Rewriting a single commit", it may be useful to
> have a section "Inserting one or more new commits". This is something that
> cannot be done with the "detached head" technique. I found this sequence
> of commands useful:
>
> If you want to add a commit in the middle of a branch:
>
> A---C---...---Z master
>
> =>
>
> A---B---C---...---Z master
>
> it is achieved by
>
> $ git checkout A
> $ git branch temp
> $ git checkout temp
> [make changes for B]
> $ git commit -a
>
> now:
>
> A---C---...---Z master
> \
> --B temp
>
> $ git checkout master
> $ git rebase temp
> $ git branch -d temp
Or compress those 8 steps down to 4 using a detached HEAD and
multi-argument rebase:
$ git checkout A
[make changes for B]
$ git commit -a
$ git rebase HEAD master
The last command above means "rebase master against HEAD". I think
the rebase command would be much easier to understand for new users if
it used an "--against" before the first reference(*). For example,
"git rebase --against temp" for rebasing the current branch against
temp (instead of "git rebase temp") or "git rebase --against HEAD
master" (rather than "git rebase HEAD master"); the real git rebase
commands don't parse so well for new users and take a long time to
wrap ones' head around, whereas this simple change seems to make it
much easier.
(*) Except when --onto is specified. Then --since may make more sense
than --against. Also, I'm not yet suggesting we make this change
(since I have no patch handy), but note that if anyone wants to try
this then the "--against" should be optional for backwards
compatibility. It's mostly a documentation change.
<snip case 2>
> 3) When do I need "git merge", and when do I need "git rebase", in the
> context of branch surgery?
>
> The simple answer, that I would find worth mentioning, is:
> - "git merge" copies commits from one branch to another.
git merge does not copy commits at all; unlike cvs/svn, a commit may
(and often is) part of more than one branch in git. A merge simply
creates a new commit which has more than one parent: the previous tip
of the current branch, and the tip of the other branch you are
merging.
> - "git rebase" only moves commits around to make history more linear.
git rebase actually doesn't move around commits; the old commits still
exist with no modifications (which is useful for undoing rebases if
you later decide you don't like them). Instead, git rebase just
re-applies commits, effectively making an extra "copy" of each commit
(I put "copy" in quotes because the "copied" commits will have
different parents, different commit times, and potentially different
contents especially when conflict resolution is necessary, so they're
not quite copies).
> 4) It would be good to have a section "Cutting branches"
>
> How do I remove the N most recent commits from a branch?
>
> D---E---F---G---H---.........---Y---Z master
>
> =>
> D---E master
>
> It goes like this:
>
> $ git checkout master
> $ git reset --hard E
If master is the active branch, you only need the latter command. If
master is not the active branch, then you can achieve the same with
much less cost by
$ git branch -f master E
> 5) Then, it would be good to have a section "Replacing branches"
>
> How do I copy the contents of a branch over to another branch, replacing
> the recent development on that branch?
>
> If you want to copy a branch into another, while throwing away commits:
>
> F1---F2---F3 released
> /
> D---E---F---G---H---.........---Y---Z master
>
> =>
> F1---F2---F3 released
> /
> D---E---F1---F2---F3 master
>
> This is achieved by
>
> $ git checkout master
> $ git reset --hard E # Cut the branch "master"
> $ git merge released # Copy commits from branch "released" to "master"
I'm assuming master isn't checked out. If so, the following is faster:
$ git branch -f master E
(If master is checked out, just 'git reset ---hard released')
> 6) Also, it would be good to have a section "Reconnecting branches after rebase".
> If you want to reconnect a branch to a rebased master, here's how to do it:
>
> /--C'--...---P'--Q'--...---Z' new rebased master
> A---B---C---...---P---Q---...---Z old master
> \
> --BA---...---BZ release-branch
>
> =>
> A---B---C'--...---P'--Q'--...---Z' new rebased master
> \
> --BA---...---BZ release-branch
>
> This is achieved by
>
> $ git checkout release-branch
> $ git rebase --onto P' P
or,
$ git rebase --onto P' P release-branch
> This might seem exotic, but these use cases all came up while rewriting the
> history after a "git cvsimport".
They may seem exotic at first to cvs/svn refugees, but it isn't very
long before lots of users end up doing these kinds of things
routinely.
Amusing story: I spent several months at $dayjob attempting to
convince our group to switch from cvs to git instead of from cvs to
svn. I often mentioned cool features like pulling directly from other
developers, but was often ignored and laughed off for mentioning
exotic cases that nearly no one would care about. And our surveys
showed that most developers didn't care about anything other than
"checkout, update, and commit". I succeeded in the end anyway, and we
found out that developers only cared about simple stuff because cvs
made anything else painful. The very first week after switching to
git, we had multiple requests from people about how to pull changes
directly from other developers (including from people that previously
only cared about "checkout, update, and commit").
When the cost of certain activities changes dramatically (which git
does by making lots new things possible and fast), formerly "exotic"
usecases can become natural and common -- and really helpful.
Anyway, I hope some of my ramblings are useful to you.
Elijah
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-06 23:05 request for documentation about branch surgery Bruno Haible
2009-07-07 2:30 ` Elijah Newren
@ 2009-07-07 2:50 ` Junio C Hamano
2009-07-07 10:13 ` Bruno Haible
2009-07-07 18:28 ` Daniel Barkalow
2 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2009-07-07 2:50 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
Bruno Haible <bruno@clisp•org> writes:
> 1) After the section "Rewriting a single commit", it may be useful to
> have a section "Inserting one or more new commits". This is something that
> cannot be done with the "detached head" technique.
You learn new things every day, and today is such a day ;-)
> If you want to add a commit in the middle of a branch:
>
> A---C---...---Z master
>
> =>
>
> A---B---C---...---Z master
>
> it is achieved by
$ git checkout master~25 ;# detach HEAD at A
$ edit edit edit
$ git commit ;# creates B
which makes
B HEAD (detached)
/
A---C---...---Z master
and then
$ git rebase HEAD master
which reshapes the history into
B---C'--...---Z' master
/
A---C---...---Z master@{1}
and you are done.
> 3) When do I need "git merge", and when do I need "git rebase", in the
> context of branch surgery?
>
> The simple answer, that I would find worth mentioning, is:
> - "git merge" copies commits from one branch to another.
> - "git rebase" only moves commits around to make history more linear.
If you think "git merge" _copies_, you will never understand what "merge"
does.
If you have master and origin branch, merging them together
X---Y---Z origin
/
/
O----A----B master
$ git checkout master
$ git merge origin
will give you this:
X---Y---Z origin
/ \
/ \
O----A----B---M master
^
master@{1}
There is no copying involved anywhere . It only creates a new commit, M,
and that commit allows 'master' (that used to point at B) to reach both
the history leading to B and the history leading to Z.
On the other hand, rebase _copies_. It _does_ make new commits A' and B',
whose _effect_ to the tree mimics those of A and B.
$ git rebase origin master
X---Y---Z---A'---B' master
/ ^origin
/
O----A----B master@{1}
> 4) It would be good to have a section "Cutting branches"
>
> How do I remove the N most recent commits from a branch?
>
> D---E---F---G---H---.........---Y---Z master
>
> =>
> D---E master
And it is not even cutting. It merely makes this:
F---G---H---.........---Y---Z master@{1}
/
D---E
^master
so that a new history can grow at E that is parallel to the
history that leads to Z.
I think your confusion is primarily coming from not understanding what a
branch in git is. A branch in git does not have its own identity per-se,
and a commit does _not_ belong to a branch, in the sense that a commit
object does not record anywhere on which branch it was created on. A
branch is just a pointer into a dag and the pointer can be moved.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 2:30 ` Elijah Newren
@ 2009-07-07 3:45 ` Elijah Newren
2009-07-07 9:51 ` Bruno Haible
1 sibling, 0 replies; 10+ messages in thread
From: Elijah Newren @ 2009-07-07 3:45 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
On Mon, Jul 6, 2009 at 8:30 PM, Elijah Newren<newren@gmail•com> wrote:
>> This is achieved by
>>
>> $ git checkout master
>> $ git reset --hard E # Cut the branch "master"
>> $ git merge released # Copy commits from branch "released" to "master"
>
> I'm assuming master isn't checked out. If so, the following is faster:
> $ git branch -f master E
Sorry, I meant
$ git branch -f master released
because we want to set master to the tip of the released branch, not to E.
> (If master is checked out, just 'git reset ---hard released')
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 2:30 ` Elijah Newren
2009-07-07 3:45 ` Elijah Newren
@ 2009-07-07 9:51 ` Bruno Haible
2009-07-07 10:06 ` Andreas Ericsson
1 sibling, 1 reply; 10+ messages in thread
From: Bruno Haible @ 2009-07-07 9:51 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
Hi Elijah,
> When the cost of certain activities changes dramatically (which git
> does by making lots new things possible and fast), formerly "exotic"
> usecases can become natural and common -- and really helpful.
Yes. With cvs, I would not never have dared to do branch surgery. With
git, I can - assuming some documentation. "git clone", "git checkout",
"git commit" each serves a particular purpose, so one can understand
when to use which command. But for branch surgery, several commands
are available:
- "git reset --hard"
- "git rebase"
- "git rebase --onto"
- "git merge" (simple case, no merge commit)
The mapping from "How do I ..." questions to command is not easy,
therefore a user's manual like
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#rewriting-one-commit>
is needed.
Thanks for correcting me and showing simpler alternatives to what
I said.
Still, can someone please extend the cited chapter of the user's manual,
so that it answers these questions?
- How do I change the last commit in a branch? [DONE]
- How do I change an older commit in a branch? [DONE]
- How do I insert some commits between other commits in a branch?
[TODO]
- How do I reorder commits in a branch? [TODO - mention "git rebase -i"]
- How do I copy selected commits from a branch to another?
[DONE]
- How do I cut a branch? [TODO]
- How do I replace a branch tip with the contents of another branch?
[TODO]
- How do I reconnect a branch to another branch point?
[TODO]
> I think
> the rebase command would be much easier to understand for new users if
> it used an "--against" before the first reference(*).
Don't know, this is just a cosmetic change. The thing that confused me
about "git rebase" is that its thinking is focused on the current branch.
Whereas when I'm doing branch surgery, I'm creating a new branch
bottom-up, so my thinking is "here I have some commits, what can I do
with them". It requires a good user's manual to map this to the right
"git rebase" command.
Bruno
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 9:51 ` Bruno Haible
@ 2009-07-07 10:06 ` Andreas Ericsson
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Ericsson @ 2009-07-07 10:06 UTC (permalink / raw)
To: Bruno Haible; +Cc: Elijah Newren, git
Bruno Haible wrote:
> I said.
>
> Still, can someone please extend the cited chapter of the user's manual,
Presumably you can. I'll jot down some notes for you though ;-)
> so that it answers these questions?
> - How do I insert some commits between other commits in a branch?
> [TODO]
git rebase --interactive (don't do this on published branches).
> - How do I reorder commits in a branch? [TODO - mention "git rebase -i"]
git rebase --interactive
> - How do I cut a branch? [TODO]
Define "cut". Possibly "git branch -d" or it's less forgiving
sibling "git branch -D", in case the branch to be removed isn't
fully merged.
> - How do I replace a branch tip with the contents of another branch?
> [TODO]
Easily understandable:
git checkout branch
git reset --hard otherbranch
The low-level way:
git update-ref [-m <reason>] [--no-deref] <full-ref-name> <newvalue>
There are more options to git-update-ref. The man-page lists them all.
> - How do I reconnect a branch to another branch point?
> [TODO]
I don't quite understand what you mean by "reconnect", but this might
do something along the lines of what you want:
git checkout branch-to-connect-to
git merge branch-to-be-connected
--
Andreas Ericsson andreas.ericsson@op5•se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 2:50 ` Junio C Hamano
@ 2009-07-07 10:13 ` Bruno Haible
2009-07-07 11:03 ` Andreas Ericsson
2009-07-07 15:52 ` Junio C Hamano
0 siblings, 2 replies; 10+ messages in thread
From: Bruno Haible @ 2009-07-07 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
> You learn new things every day, and today is such a day ;-)
>
> > If you want to add a commit in the middle of a branch:
> >
> > A---C---...---Z master
> >
> > =>
> >
> > A---B---C---...---Z master
> >
> > it is achieved by
>
> $ git checkout master~25 ;# detach HEAD at A
> $ edit edit edit
> $ git commit ;# creates B
>
> which makes
>
> B HEAD (detached)
> /
> A---C---...---Z master
>
> and then
>
> $ git rebase HEAD master
>
> which reshapes the history into
>
>
> B---C'--...---Z' master
> /
> A---C---...---Z master@{1}
>
> and you are done.
Cool! I wouldn't have guessed that. Now you wrote it into the mailing list
archives. It would be even better if it were mentioned in the user's manual,
chapter "Rewriting history and maintaining patch series"
> > 3) When do I need "git merge", and when do I need "git rebase", in the
> > context of branch surgery?
> >
> > The simple answer, that I would find worth mentioning, is:
> > - "git merge" copies commits from one branch to another.
> > - "git rebase" only moves commits around to make history more linear.
>
> If you think "git merge" _copies_, you will never understand what "merge"
> does. ... There is no copying involved anywhere . It only creates a new
> commit
There are two cases of "git merge" operation: the one that creates a diamond
commit, and the one that doesn't (the "simple" case of "git merge"). The latter
operation I found useful in achieving this surgery:
C---D---E topic
/
A---B master
=>
C---D---E topic
/
A---B---C---D---E master
How do I do this, if not by using "git merge"? Is there a way to do it with
"git rebase" only?
If I have a certain task at hand, what rule of thumb would you give me,
when can I do it with "git rebase", and when can I do it with the simple case
of "git merge"?
> > 4) It would be good to have a section "Cutting branches"
> >
> > How do I remove the N most recent commits from a branch?
> >
> > D---E---F---G---H---.........---Y---Z master
> >
> > =>
> > D---E master
>
> And it is not even cutting. It merely makes this:
>
> F---G---H---.........---Y---Z master@{1}
> /
> D---E
> ^master
I regularly use "git repack -a -d", so that branches like that
master@{1} get garbage collected. So from the point of view of someone
who considers only the contents of the commits that sit on branches,
it *does* cut the branch.
I know that all commits are still present and reachable by their ID,
as long as they have not been garbage collected. But when doing
branch surgery, only the contents of the labelled branches matters to me.
> I think your confusion is primarily coming from not understanding what a
> branch in git is. A branch in git does not have its own identity per-se,
> and a commit does _not_ belong to a branch, in the sense that a commit
> object does not record anywhere on which branch it was created on. A
> branch is just a pointer into a dag and the pointer can be moved.
Oh, I do and did know all this. There is no confusion about that. My problem
was that
- I had a couple of "how do I ..." questions regarding branch surgery,
- the mapping between such a task and the git command to use is not clear
(combinations of "git checkout", "git branch", "git rebase", "git merge",
"git reset", "git cherry-pick" - enough complicated commands to get
confused),
- the user's manual answered only half of my questions.
Bruno
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 10:13 ` Bruno Haible
@ 2009-07-07 11:03 ` Andreas Ericsson
2009-07-07 15:52 ` Junio C Hamano
1 sibling, 0 replies; 10+ messages in thread
From: Andreas Ericsson @ 2009-07-07 11:03 UTC (permalink / raw)
To: Bruno Haible; +Cc: Junio C Hamano, git
Bruno Haible wrote:
> Hi Junio,
>
>> You learn new things every day, and today is such a day ;-)
>>
>>> If you want to add a commit in the middle of a branch:
>>>
>>> A---C---...---Z master
>>>
>>> =>
>>>
>>> A---B---C---...---Z master
>>>
>>> it is achieved by
>> $ git checkout master~25 ;# detach HEAD at A
>> $ edit edit edit
>> $ git commit ;# creates B
>>
>> which makes
>>
>> B HEAD (detached)
>> /
>> A---C---...---Z master
>>
>> and then
>>
>> $ git rebase HEAD master
>>
>> which reshapes the history into
>>
>>
>> B---C'--...---Z' master
>> /
>> A---C---...---Z master@{1}
>>
>> and you are done.
>
> Cool! I wouldn't have guessed that. Now you wrote it into the mailing list
> archives. It would be even better if it were mentioned in the user's manual,
> chapter "Rewriting history and maintaining patch series"
>
Anyone can submit patches. I find your persistent urging that someone else
do this for you slightly annoying. Now that you've been helped along the
way to understanding, it's your turn to do your bit and write up the info
you've received as a proper patch. This will help ensure that:
a) Other people can find the relevant information quickly
b) We won't have to answer the same questions again
c) You gain an even deeper understanding about how the various features
actually work as your patches are submitted for review and improvements
are suggested for them by the list members
d) We answer your questions again next time you have any
You can ofcourse refrain from submitting patches and just hope that d)
happens anyway. It probably will, but not indefinitely.
Thanks.
--
Andreas Ericsson andreas.ericsson@op5•se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-07 10:13 ` Bruno Haible
2009-07-07 11:03 ` Andreas Ericsson
@ 2009-07-07 15:52 ` Junio C Hamano
1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2009-07-07 15:52 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
Bruno Haible <bruno@clisp•org> writes:
>> If you think "git merge" _copies_, you will never understand what "merge"
>> does. ... There is no copying involved anywhere . It only creates a new
>> commit
>
> There are two cases of "git merge" operation: the one that creates a diamond
> commit, and the one that doesn't (the "simple" case of "git merge"). The latter
> operation I found useful in achieving this surgery:
>
> C---D---E topic
> /
> A---B master
>
> =>
>
> C---D---E topic
> /
> A---B---C---D---E master
If C, D, E on the above two lines are the _same_ commit, i.e. with the
same history and same object IDs, then the picture should instead look
like this:
C---D---E topic
/
A---B master
=>
master
C---D---E topic
/
A---B master@{1}
If that is the case, you drew the picture incorrectly, and it shows the
misunderstanding of your git object model and what a git branch is.
The latter I have already explained to you, but here is a hint.
Do not think of a branch as "the upper line is topic, the lower line
is master". A branch is just a pointer to _a commit_. IOW, in the
picture I drew to correct yours, master and topic point at "E". It
does _not_ point at the line that C, D, and E are on. Similarly,
master@{1} points at the commit "B", not at the line A and B are on.
You claimed that you understand in your response, but judging from the way
you wrote the above picture, I can tell that you don't understand what a
branch in git is. Otherwise you would have drew it like how I did, and
you wouldn't have used the word "copy".
If you instead for some reason _want_ a forked history where C, D and E
are _duplicated_, then you would start from the first picture, fast
forward master to "E", and would force rebase onto B, to end up with
a picture like this.
C---D---E topic
/
A---B---C'--D'--E' master
But there is no reason to do this.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: request for documentation about branch surgery
2009-07-06 23:05 request for documentation about branch surgery Bruno Haible
2009-07-07 2:30 ` Elijah Newren
2009-07-07 2:50 ` Junio C Hamano
@ 2009-07-07 18:28 ` Daniel Barkalow
2 siblings, 0 replies; 10+ messages in thread
From: Daniel Barkalow @ 2009-07-07 18:28 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
On Tue, 7 Jul 2009, Bruno Haible wrote:
> 6) Also, it would be good to have a section "Reconnecting branches after rebase".
> If you want to reconnect a branch to a rebased master, here's how to do it:
>
> /--C'--...---P'--Q'--...---Z' new rebased master
> A---B---C---...---P---Q---...---Z old master
> \
> --BA---...---BZ release-branch
>
> =>
> A---B---C'--...---P'--Q'--...---Z' new rebased master
> \
> --BA---...---BZ release-branch
This is impossible; the parent of BA is P, not P'.
/--C'--...---P'--Q'--...---Z' new rebased master
A---B---C---...---P---Q---...---Z old master
\
--BA---...---BZ release-branch
=>
--BA'--...---BZ' release branch
/
/--C'--...---P'--Q'--...---Z' new rebased master
A---B---C---...---P---Q---...---Z
\
--BA---...---BZ
In order to draw well-formed tree sequences, you can only add items to the
trees, and only use each letter once in the whole thing. When you've got a
complete history following those rules, you can elide parts of the history
that aren't referenced any more, but you still can't reuse their letters.
You're drawing some of your trees as if it were possible to have commits
that are not eq but are equal; in fact, all information about a commit,
including its parentage, is immutable and contributes to the way it is
referenced, so any equal commits are eq (and therefore only appear in one
spot on the graph).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-07-07 18:29 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-06 23:05 request for documentation about branch surgery Bruno Haible
2009-07-07 2:30 ` Elijah Newren
2009-07-07 3:45 ` Elijah Newren
2009-07-07 9:51 ` Bruno Haible
2009-07-07 10:06 ` Andreas Ericsson
2009-07-07 2:50 ` Junio C Hamano
2009-07-07 10:13 ` Bruno Haible
2009-07-07 11:03 ` Andreas Ericsson
2009-07-07 15:52 ` Junio C Hamano
2009-07-07 18:28 ` Daniel Barkalow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox