Nguyen Thai Ngoc Duy [off-list ref] writes:
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
[off-list ref] wrote:
quoted
quoted
Maybe we should store this information. reflog is a perfect place for
this, I think. If this information is reliably available, git rebase
can be told to "rebase my whole branch" instead of my choosing the
base commit for it.
What's the starting point of the branch if I type: git branch foo <commit-ish>?
You start working off <commit-ish> so I think the starting point would
be <commit-ish>.
Yeah, that sounds sensible. Don't we already have it in the reflog,
though?
What is trickier is when you later transplant it to some other base
(perhaps prepare a topic on 'master', realize it should better apply
to 'maint' and move it there). If the user did the transplanting by
hand, reflog would probably not have enough information, e.g. after
$ git checkout maint^0
$ git log --oneline master..topic
$ git cherry-pick $one_of_the_commit_names_you_see_in_the_above
$ git cherry-pick $another_commit_name_you_see_in_the_above
...
$ git branch -f topic
no reflog other than HEAD@{} will tell you that you were at maint^0,
so the reflog of topic wouldn't know it "forked" from there, either.
On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano [off-list ref] wrote:
Nguyen Thai Ngoc Duy [off-list ref] writes:
quoted
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
[off-list ref] wrote:
quoted
quoted
Maybe we should store this information. reflog is a perfect place for
this, I think. If this information is reliably available, git rebase
can be told to "rebase my whole branch" instead of my choosing the
base commit for it.
What's the starting point of the branch if I type: git branch foo <commit-ish>?
You start working off <commit-ish> so I think the starting point would
be <commit-ish>.
Yeah, that sounds sensible. Don't we already have it in the reflog,
though?
I looked briefly at reflog before writing my previous mail and noticed
that when I create a new branch (usually using "git checkout -b branch
ref") it does not record the base commit.
What is trickier is when you later transplant it to some other base
(perhaps prepare a topic on 'master', realize it should better apply
to 'maint' and move it there). If the user did the transplanting by
hand, reflog would probably not have enough information, e.g. after
$ git checkout maint^0
$ git log --oneline master..topic
$ git cherry-pick $one_of_the_commit_names_you_see_in_the_above
$ git cherry-pick $another_commit_name_you_see_in_the_above
...
$ git branch -f topic
no reflog other than HEAD@{} will tell you that you were at maint^0,
so the reflog of topic wouldn't know it "forked" from there, either.
We could at least invalidate the recorded base in reflog and let user
define a new one (I hope).
--
Duy