Junio C Hamano wrote:
> [...]
I have no desire to argue incessantly. I just want a solution to the problem!
> A rerolled series that does:
>
> - Tweak wt-status.c to take information not from reflog, when
>detached during rebase (this may need to tweak existing tests,
>as different "reb
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Two possibilities:
>>
>> (1) Assume that the other thread will produce a more reasonable
>> semantics when finished; perhaps the first line will go away
>> entirely, or maybe it would say something like "# Rebasing;
>> head a
Junio C Hamano wrote:
> The first line from status in the middle of
> a rebase is secondary. End-user initiated "checkout" to detach is
> the primary thing.
>
>> 3. The problem is not unique to rebase at all; yet you have
>> special-cased it. If this isn't a band-aid, what is?
>
> It is an illust
Junio C Hamano wrote:
> Two possibilities:
>
> (1) Assume that the other thread will produce a more reasonable
> semantics when finished; perhaps the first line will go away
> entirely, or maybe it would say something like "# Rebasing;
> head at $commit".
>
> Your topic does no
Ramkumar Ramachandra writes:
>> I have been assuming the "main" thing Duy wanted to do was the last
>> test (and the one below), but was this meant as an improvement for
>> "git status" output during that state?
>
> On what basis are you making that assumption?
List archive helps.
http://threa
Ramkumar Ramachandra writes:
> 2. The following no longer updates status:
>
> # in the middle of a rebase
> $ git reset @~2
>
> The constant "HEAD detached at $onto" message is misleading and Bad.
> Besides, wasn't this the primary usecase you wanted?
See the other message. The first line f
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I am only saying that the last test the commit adds must be kept
>> unbroken. I am also saying that, even though that commit did not
>> add a test for "detached from" case, we should add something like
>> the attached to protect the behavio
Junio C Hamano wrote:
> I am only saying that the last test the commit adds must be kept
> unbroken. I am also saying that, even though that commit did not
> add a test for "detached from" case, we should add something like
> the attached to protect the behaviour. These two are sacred.
>
> What h
Junio C Hamano wrote:
> wt-status.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index bf84a86..403d48d 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)
>
Junio C Hamano writes:
> I have been assuming the "main" thing Duy wanted to do was the last
> test (and the one below), but was this meant as an improvement for
> "git status" output during that state? Showing $ONTO certainly
> makes some sense, and from that point of view, the change we are
>
Ramkumar Ramachandra writes:
> Since you have made it clear that you will defend every bit of b397ea
You are misreading me. I am not defending every bit at all.
We both agree that what b397ea4863a1 (status: show more info than
"currently not on any branch", 2013-03-13) expects from "git status
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If you first update "git checkout" so that it will pay attention to
>> a custom reflog-action exported by Porcelain scripts that may want
>> to internally use it to flip branches (and without a custom one, it
>> will still record "checkout:
Junio C Hamano wrote:
> If you first update "git checkout" so that it will pay attention to
> a custom reflog-action exported by Porcelain scripts that may want
> to internally use it to flip branches (and without a custom one, it
> will still record "checkout: moving from A to B"), without exporti
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> As I said (twice), you can argue that that particular piece of
>> information is not useful (at least to you), but why it is not
>> useful has to be justified, against the justification given by
>> b397ea4863a1 (status: show more info than "
Junio C Hamano wrote:
> As I said (twice), you can argue that that particular piece of
> information is not useful (at least to you), but why it is not
> useful has to be justified, against the justification given by
> b397ea4863a1 (status: show more info than "currently not on any
> branch", 2013-
Ramkumar Ramachandra writes:
> In this example, it is inconsequential whether I run:
>
> $ git checkout v1.8.2^
>
> or:
>
> $ git checkout v1.8.2
> $ git reset --hard @^
>
> as far as describe is concerned. It will give me the same good
> consistent answer in either case.
Yes, "describe H
Junio C Hamano wrote:
> The part you stripped from your quote looked like this:
Apologies for the lack of clarity.
>>> 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
>>
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> 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.
Junio C Hamano wrote:
>> 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 com
Ramkumar Ramachandra 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
>>
Junio C Hamano wrote:
>> At this point, the utility of such a message is in question.
>
> You can question, but I am not convinced the answer is an
> unambiguous "not useful"
I am not arguing for an unambiguous "not useful". I am arguing for a
practical compromise: this patch locks things up too
Junio C Hamano wrote:
> [...]
I'd just like to point out quickly that I first attempted to write 6/6
without this patch. It is absolutely impossible, because the
"detached HEAD from/to" messages no longer make any sense when
checkout starts respecting GIT_REFLOG_ACTION. At that point, I'm was
ju
Ramkumar Ramachandra writes:
> b397ea4 (status: show more info than "currently not on any branch",
> 2013-03-13) made the output of 'git status' richer in the case of a
> detached HEAD. Before this patch, with a detached HEAD:
>
> $ git status
> # Not currently on any branch.
>
> After the p
b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) made the output of 'git status' richer in the case of a
detached HEAD. Before this patch, with a detached HEAD:
$ git status
# Not currently on any branch.
After the patch:
$ git checkout v1.8.2
# HEAD is no
24 matches
Mail list logo
