On 19 June 2015 at 10:26, Peter Maydell <[email protected]> wrote: > stg rebase seems to mishandle files that exist in the current branch, > but have been deleted in the branch you're trying to rebase onto. > The files don't get deleted from the working tree, which means that > (a) "git status" lists them as untracked files > (b) subsequently trying to checkout a branch where the files still > existed will fail with > "error: The following untracked working tree files would be overwritten > by checkout:".
> In particular, if I do an "stg rebase foo" when the stg patchstack > is completely empty, I ought surely to end up with the same working > tree as if I'd just done a "git checkout foo" ? 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 -- PMM _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
