git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Jun 15, 2013, 08:44 UTC
Message-ID
<CALkWK0nDwqqiAq044wwj__1XzAuFDBUG59_0zHRMNzQ6ARsiww@mail.gmail.com>
In-Reply-To
<7v7ghwmi9x.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 10 quoted lines
> 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 to be shown during a stopped "git rebase" is not.
>
> 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? b397ea4 did not add a test for "detached HEAD from", and there is no evidence of what the author wanted in the commit message. What has happened has happened; the question is: what do _you_ want now?

Read the various "HEAD detached from/to" messages in the rebase tests in t/status-help and tell me that they make some sense. It does _not_ show a constant "HEAD detached from $onto", contrary to your assumption (evidenced by your patch in the later email). Look at these hunk added by b397ea4, and tell me that it's not a monkey-patch:

@@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in
edit mode' '
        export FAKE_LINES &&
        test_when_finished "git rebase --abort" &&
        ONTO=$(git rev-parse --short HEAD~2) &&
+       TGT=$(git rev-parse --short two_rebase_i) &&
        git rebase -i HEAD~2 &&
        cat >expected <<-EOF &&
-       # Not currently on any branch.
+       # HEAD detached from $TGT
        # You are currently editing a commit while rebasing branch
'\''rebase_i_edit'\'' on '\''$ONTO'\''.
        #   (use "git commit --amend" to amend the current commit)
        #   (use "git rebase --continue" once you are satisfied with
your changes)
@@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' '
        ONTO=$(git rev-parse --short HEAD~3) &&
        git rebase -i HEAD~3 &&
        git reset HEAD^ &&
+       TGT=$(git rev-parse --short HEAD) &&
        cat >expected <<-EOF &&
-       # Not currently on any branch.
+       # HEAD detached at $TGT
        # You are currently splitting a commit while rebasing branch
'\''split_commit'\'' on '\''$ONTO'\''.
        #   (Once your working directory is clean, run "git rebase --continue")
        #
@@ -243,10 +245,11 @@ test_expect_success 'status after editing the
last commit with --amend during a
        export FAKE_LINES &&
        test_when_finished "git rebase --abort" &&
        ONTO=$(git rev-parse --short HEAD~3) &&
+       TGT=$(git rev-parse --short three_amend) &&
        git rebase -i HEAD~3 &&
        git commit --amend -m "foo" &&
        cat >expected <<-EOF &&
-       # Not currently on any branch.
+       # HEAD detached from $TGT
        # You are currently editing a commit while rebasing branch
'\''amend_last'\'' on '\''$ONTO'\''.
        #   (use "git commit --amend" to amend the current commit)
        #   (use "git rebase --continue" once you are satisfied with
your changes)


> Showing $ONTO certainly
> makes some sense, and from that point of view, the change we are
> discussing _will_ be a regression if it just shows a random thing.

If showing $ONTO were the intent of the patch, this is no way to go
about it.  Reliable information is readily available in
.git/rebase-apply; no parsing is required, and it is ready for
consumption.

Your argument now is: because the patch _incidentally_ shows $ONTO in
many cases (as evidenced by the hunks above), the objective of the
patch _must_ have been to show $ONTO.  Should I laugh or cry?

> If you want to avoid regression, the codepath in wt-status.c should
> compensate for the change to "rebase" so that it checks $dotest/onto
> and show what is recorded in there.

Now you want to achieve the exact same accidental behavior after
patching rebase/checkout.  This is a never-ending nightmare.

> You are misreading me.  I am not defending every bit at all.

I am not misreading anything.  Despite me having repeatedly shown that
b397ea4 is poorly done with far-reaching unintended consequences, you
are unwilling to admit it.  Instead, you are trying to somehow
preserve this accidental behavior.  And you still haven't been able to
show me how to do that.  As a result, checkout-dash is stalled.
Previous: Ramkumar RamachandraNext: Junio C Hamano
Message 31 of 37 in “Fix git checkout - with rebase”
  1. 0/6 Fix git checkout - with rebaseRamkumar Ramachandra, Jun 13, 2013
  2. 1/6 t/checkout-last: checkout - doesn't work after rebaseRamkumar Ramachandra, Jun 13, 2013
  3. Junio C HamanoJun 13, 2013
  4. Ramkumar RamachandraJun 13, 2013
  5. Junio C HamanoJun 13, 2013
  6. 2/6 rebase: prepare to write reflog message for checkoutRamkumar Ramachandra, Jun 13, 2013
  7. Junio C HamanoJun 13, 2013
  8. Ramkumar RamachandraJun 13, 2013
  9. 3/6 rebase -i: prepare to write reflog message for checkoutRamkumar Ramachandra, Jun 13, 2013
  10. Junio C HamanoJun 13, 2013
  11. 4/6 wt-status: remove unused field in grab_1st_switch_cbdataRamkumar Ramachandra, Jun 13, 2013
  12. Junio C HamanoJun 13, 2013
  13. 5/6 status: do not depend on flaky reflog messagesRamkumar Ramachandra, Jun 13, 2013
  14. Junio C HamanoJun 13, 2013
  15. Ramkumar RamachandraJun 13, 2013
  16. Ramkumar RamachandraJun 13, 2013
  17. Junio C HamanoJun 13, 2013
  18. Ramkumar RamachandraJun 14, 2013
  19. Junio C HamanoJun 14, 2013
  20. Ramkumar RamachandraJun 14, 2013
  21. Junio C HamanoJun 14, 2013
  22. Ramkumar RamachandraJun 14, 2013
  23. Junio C HamanoJun 14, 2013
  24. Ramkumar RamachandraJun 14, 2013
  25. Junio C HamanoJun 14, 2013
  26. Junio C HamanoJun 14, 2013
  27. Junio C HamanoJun 14, 2013
  28. Ramkumar RamachandraJun 15, 2013
  29. Junio C HamanoJun 15, 2013
  30. Ramkumar RamachandraJun 15, 2013
  31. Ramkumar RamachandraJun 15, 2013
  32. Junio C HamanoJun 15, 2013
  33. Ramkumar RamachandraJun 15, 2013
  34. Junio C HamanoJun 16, 2013
  35. Ramkumar RamachandraJun 16, 2013
  36. Junio C HamanoJun 15, 2013
  37. 6/6 checkout: respect GIT_REFLOG_ACTIONRamkumar Ramachandra, Jun 13, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.