Hi all! Can't reply to a previous message since I haven't been subscribed before. Disclaimer: I've used stgit for quite a while but have never looked at the sources before. This particular problem has bugged me for a while though.
> I finally got round to having a closer look at this, and the > problem seems to be that stgit isn't using 'git checkout' > to checkout a commit. When you do 'stg rebase <commit>' > then stgit's git.rebase function calls git.reset, which calls > git.checkout, and git.checkout does: > > 'read-tree', '--reset', '<commithash>' > 'checkout-index', '-q', '-u', '-f', '-a' > > If I understand the git plumbing correctly (not necessarily a > given...) then this is doing the job in two stages: > (1) update the index to whatever the commithash says > (2) set the working tree to what the new index says > > But this means that in the first step we throw away the > information about whether a file in the old working directory > was there because (a) it's in the old index, or (b) it was an > untracked file. So in the second step we can't correctly > delete files in category (a) that aren't in the new index > without also deleting the category (b) files. > > Presumably the right fix for this is to use a single > git command which does both of these steps at once. > However I don't know enough about git internals to be > able to guess what. Can anybody suggest what the right > approach here is? Thanks for your investigation, Peter. Adding '-u' to the read-tree command and skipping checkout-index is tempting. Have you tried anything in this direction? Fwiw, I tried it quickly and it seemed to address the issue and pass the testsuite but I have little domain knowledge about what I'm doing. David _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
