Re: [PATCH 5/6] status: do not depend on flaky reflog messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:

> To be clear: the problem is not the feature, but rather in the
> _implementation_ of the feature.

OK, but are we discussing the same "feature" (see below)?

>> You were at 1.8.2 but no longer are, so in the following sequence:
>>
>>     $ git checkout v1.8.2
>>     $ git status
>>     $ git reset --hard HEAD^
>>     $ git status
>>
>> the former would say "detached at v1.8.2" while the latter should
>> *not*, because we are no longer at v1.8.2.  "detached from v1.8.2"
>> is too subtle a way to express the state, and is confusing, but I
>> would not be surprised if people find it useful to be able to learn
>> "v1.8.2" even after you strayed away.
>
> What is wrong with git describe?  Is this cheaper, or am I missing something?

I think what you are missing is that the "detached from" is not
about your current HEAD after you flipped it around with many resets
and commits.  It is about what tag or what specific commit you
detached your HEAD at originally.

"You can ask the same to describe" is wrong and is not a valid
argument.  Once you replace the HEAD^ with a distant commit
(e.g. HEAD~400) in the third step in the example, "describe" will
not talk about v1.8.2 at all.

Your argument can be that it is not a useful piece of information,
and as you can probably guess from my "I wouldn't be surprised"
above, I am not sure how useful it would be and in what situation
[*1*].

But the original commit thought it was necessary and that was done
for a reason; we need to be careful here.  With a good justification
why it is not necessary (or misleading to the user), I do not think
we cannot change it.

As various tools that use detached "intermediate" states leave
enough clues for "status" to notice what is going on, I actually
think it is a mistake to focus on what happens when we are in such a
detached "intermediate" status with this codepath.  For example:

	$ git rebase master
        ... replays some but stops
        $ git status

currently uses that "HEAD detached from" codepath, but I think that
is a mistake.  We could not just tell the HEAD is detached, but the
reason _why_ the HEAD is detached (i.e. we are in the middle of a
rebase).  The prompt script can do it, "status" should be able to do
the same, and do a lot more sensible thing than unconditionally
showing that "HEAD detached from" and then say "You are currently
rebasing" on a separate line.  Most likely we do not want to even
say "Not currently on any branch" but just say "You are currently
rebasing branch X on top of Y" (and perhaps "N commits remaining to
be replayed").


[Footnote]

*1* One thing I could think of is to start sightseeing or (more
    realistically) manually bisecting at a given release point,
    reset the detached HEAD around several times, and then want to
    be reminded where the session started from.  I do not think it
    is particularly a very good example, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]