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 rebase
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 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 happens
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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.
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 not _care_
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 illustration for
Ramkumar Ramachandra artag...@gmail.com 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;
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 commit you
Ramkumar Ramachandra artag...@gmail.com 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
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
the former would
Ramkumar Ramachandra artag...@gmail.com 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,
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-03-13)
Ramkumar Ramachandra artag...@gmail.com 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
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 exporting
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
Ramkumar Ramachandra artag...@gmail.com 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.
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 tightly,
Ramkumar Ramachandra artag...@gmail.com 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
22 matches
Mail list logo
