Nguyen Thai Ngoc Duy <pclo...@gmail.com> writes:
> On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclo...@gmail.com> writes:
>>
>>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>>> <tomas.carne...@gmail.com> wrote:
>>>>> 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.
Hmph. Perhaps you are referring to something different than what I
think "the base commit" with that word.
$ git reflog mz/pick-unborn | tail -n 1
b3cf6f3 mz/pick-unborn@{3}: branch: Created from ko/master
>> 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).
Please do not even think about going back and rewrite to lose
information. If the records have full information, you should be
able to reconstruct what you want from it without rewriting.
Even more importantly, wish to "invalidate" indicates that you know
at a newer point that you have more authoritative information than
the older reflog entries, so you should be able to do the moral
equivalent by writing the event as establishing a new base at that
point (e.g. "checkout -B"), and stopping at that point in the reflog
when reading, without losing the older reflog entries.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
