Reset / Unstage renamed items #770
Conversation
There was a problem hiding this comment.
small request: could you include a comment about what commit "32eab9c" is? Is this the Tip commit of the standard test repo?
There was a problem hiding this comment.
It is at present; but I think that future commits to that repo would make that comment outdated quickly. (The other Reset tests use an older commit which I suspect was tip when they were written.)
There was a problem hiding this comment.
If that were to happen, I imagine this test would need to be updated anyways, as you would be reseting the index to a commit other than HEAD, and it would probably have other staged changes at that point?
Anyway, not a big deal. I do think a comment describing what the intent of why you are using that specific commit might help when looking at this code in the future.
There was a problem hiding this comment.
FWIW there are many tests that depend on the current repo.Head.Tip, including some Reset() tests. No harm in depending on it here too, IMO.
|
👍 Thanks @ethomson! |
|
One thing to point out is that you can reset to prior commits, so adding another commit in that repository, or moving HEAD forward, will not result in these tests failing. (I'm sure that you could create some HEAD that did something evil to one of the files in question. But Anyway. I rebased this. /cc @nulltoken |
And I merged it. A thousand thanks! ✨ |
4 participants
Currently, if you try Repository.Reset() when you have renamed entries, it chokes as
Index.Resetexpects only certain types ofChangeKinds. It's easiest to treat renamed entries exactly like git core does, which is to say to treat them as an add and a delete ingit-resetand allow you to reset each side independently (which then breaks the facade of a rename).