git bisect leaves "should not appear" transactions in undo log #57
Comments
|
Thanks for reporting. I'll look into the bisect workflow later. I'm wondering if it needs to be added here: git-branchless/src/core/eventlog.rs Line 600 in 646185f Or maybe we just shouldn't warn for the case of bisect refs being empty. EDIT: ah, I didn't realize that there are different refs for each good commit. |
|
It looks like stashes would also be affected:
Although ideally, under the branchless workflow, you wouldn't use stashes to begin with. From a UX perspective, it probably makes sense to have different timelines for branches, bisects and stashes, but I'm not sure how we would represent that in the UI. |
Closes #57. Some operations, such as bisecting and stashing, use references in an unconventional way. These are reported as if there is no change to the content of the reference, which might happen e.g. if instead the reflog for that reference was changed, or if it was touched but left unchanged. These uses for references don't really affect the commit graph. Ideally, we would handle them entirely differently. They should have an entirely separate history, and it should be possible to rewind them separately from the commit graph's history. For example, you should be able to unmark a certain commit during a bisect operation without affecting any commits you may have made since starting the bisect. The UI for this would need to be considered thoughtfully. Since this isn't too common of a use-case for now, I'm updating this message to just warn that it may be an unsupported use-case, and deferring it the alternative UI for later.
Closes #57. Some operations, such as bisecting and stashing, use references in an unconventional way. These are reported as if there is no change to the content of the reference, which might happen e.g. if instead the reflog for that reference was changed, or if it was touched but left unchanged. These uses for references don't really affect the commit graph. Ideally, we would handle them entirely differently. They should have an entirely separate history, and it should be possible to rewind them separately from the commit graph's history. For example, you should be able to unmark a certain commit during a bisect operation without affecting any commits you may have made since starting the bisect. The UI for this would need to be considered thoughtfully. Since this isn't too common of a use-case for now, I'm updating this message to just warn that it may be an unsupported use-case, and deferring it the alternative UI for later.
Closes #57. Some operations, such as bisecting and stashing, use references in an unconventional way. These are reported as if there is no change to the content of the reference, which might happen e.g. if instead the reflog for that reference was changed, or if it was touched but left unchanged. These uses for references don't really affect the commit graph. Ideally, we would handle them entirely differently. They should have an entirely separate history, and it should be possible to rewind them separately from the commit graph's history. For example, you should be able to unmark a certain commit during a bisect operation without affecting any commits you may have made since starting the bisect. The UI for this would need to be considered thoughtfully. Since this isn't too common of a use-case for now, I'm updating this message to just warn that it may be an unsupported use-case, and deferring it the alternative UI for later.
Closes #57. Some operations, such as bisecting and stashing, use references in an unconventional way. These are reported as if there is no change to the content of the reference, which might happen e.g. if instead the reflog for that reference was changed, or if it was touched but left unchanged. These uses for references don't really affect the commit graph. Ideally, we would handle them entirely differently. They should have an entirely separate history, and it should be possible to rewind them separately from the commit graph's history. For example, you should be able to unmark a certain commit during a bisect operation without affecting any commits you may have made since starting the bisect. The UI for this would need to be considered thoughtfully. Since this isn't too common of a use-case for now, I'm updating this message to just warn that it may be an unsupported use-case, and deferring it the alternative UI for later.
|
I've closed this for now by changing the bug message to link to this page, and I've added an item to #2 to track the issue of coming up with a better UI for undoing these kinds of events. For future readers: if you're affected by this, you can leave a comment in this thread or post in Discussions. |
|
Besides the issue of |
I did a bisect in my local dev tree yesterday, and noticed various transactions in
git undothat have the following message:This event should not appear. This is a (benign) bug -- please report it.I don't think bisect is a workflow that has been completely worked out for transactions yet?
Roughly looks like this (replacing commit ids and names with
...throughout):at the start of the bisection, and later, after I did the bisection and screwed something up (resulting in a commit that was both good and bad) I did a
git bisect reset, resulting in the following:followed by other transactions that looked like:
or
one for each of the good / bad refs. Finally finishing with:
The text was updated successfully, but these errors were encountered: