Community
Participate
Working Groups
Build Identifier: M20100909-0800 one important application of the git index is to make a decision on what to commit separately from when the code is modified. egit will automatically stage files for deletion when I delete them from the eclipse GUI, this breaks the workflow of making the decision of what to commit when committing rather than when modifying. Reproducible: Always
Me second affected by that, despite the fact that staging concept itself is a questionable in IDE. BTW same hapens for "rename": both paths (new and old one) appear in index without asking me at all. I think the rule for egit should be: *none* of the operations triggered from team "IMoveDeleteHook" API should add *anything* to index.
This is supposed to be a feature and is what git does with "git rm" and "git mv". The problem with not doing this is that it would probably result in people forgetting to commit new paths (of renamed files) because they would be untracked. Maybe we can provide a preference option for this -> changed to enhancement and adjusted title. If anyone is willing to implement this, the implementation would be in GitMoveDeleteHook.
(In reply to Andrey Loskutov from comment #1) > I think the rule for egit should be: *none* of the operations triggered from > team "IMoveDeleteHook" API should add *anything* to index. -1 This decisions mandates that every Eclipse user is a Git expert and understands the difference between modifying/index/staging/committing. However, quite a lot do not. They come/migrate from a SCM context that just has modify+commit. (In reply to Robin Stocker from comment #2) > Maybe we can provide a preference option for this I think it's a good idea to allow optimizing EGit workflows and user experience for Git experts.
*** Bug 439700 has been marked as a duplicate of this bug. ***
Fixed by https://git.eclipse.org/r/#/c/84522/ and https://git.eclipse.org/r/#/c/84539/ . *** This bug has been marked as a duplicate of bug 507018 ***
