Community
Participate
Working Groups
when opening a diff in from staging view to compare editor, the panel may show "Index" term while the "Git staging" view shows "staging" term. Using the same term would make usage easier, more clearly emphasizing that partial commits are possible here.
Usage of the terms "index" vs. "staging area", "add to index" vs. "stage" etc. are inconsistent both in command-line git documentation and in the EGit UI. Resolving this properly would be a lot of work for little gain. Just changing bits here and there would not make the UI any more consistent. The User's guide would need to be updated, too. Compare comments on bug 481360.
New Gerrit change created: https://git.eclipse.org/r/142675
New Gerrit change created: https://git.eclipse.org/r/142730
Git CLI talks simply about "Changes to be committed", maybe we could just reuse the same term? What I think it annoying in EGit is the usage of the term "Index" which doesn't surface in Git CLI not most tutorials. IMHO we should deprecate this term in the UI.
(In reply to Mickael Istria from comment #4) > What I think it annoying in EGit is the usage of the term "Index" which > doesn't surface in Git CLI not most tutorials. IMHO we should deprecate this > term in the UI. While I can understand the sentiment, it's either change it consistently throughout the UI or not at all. Otherwise we end up with an even more inconsistent UI. If we do this by bits and pieces I doubt this will ever be finished; experience shows that enthusiasm for doing such menial tasks quickly wanes, and I'm not interested in the least bit in picking up a half-done job in this area. See also comment 1. The official git book https://git-scm.com/book/en/v2 does explain the term "index" and uses it, too. In the chapter "Reset demystified" it's even preferred over "staging area". git diff output has an index line. git stash may report "Saved working directory and index state". git am may tell you "Using index info to reconstruct a base tree..." As the book says very early on, The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well. Personally I have no problems with the term "index".
also see the earlier discussion in bug 481360
(In reply to Thomas Wolf from comment #5) > While I can understand the sentiment, it's either change it consistently > throughout the UI or not at all. I agree. > The official git book https://git-scm.com/book/en/v2 does explain the term > "index" and uses it, too. In the chapter "Reset demystified" it's even > preferred over "staging area". Something 0.1% of Git users have read against the tool 100% of Git users are using ;) I think unless Git itself stated it will adopt "Index" in some future versions, we're making EGit easier by using "Staging area". Are you aware of such an enhancement request in Git backlog? > git diff output has an index line. > git stash may report "Saved working directory and index state". > git am may tell you "Using index info to reconstruct a base tree..." Ok, but those are IMO "occasional" commands compared to `git status`. But that indeed highlights that Git status is inconsistent with other operations and documentation. > Personally I have no problems with the term "index". I'm getting convinced it might be the right term, technically speaking. But still I really saw some users not understanding this term and not realizing when seeing the diff editor what would happen if they edit the Index file, which with something named "staging" or similar, it would have been a bit clearer to them.
I have not yet noticed that users have lesser problems with "staging" than with "index". Then man pages of "git add" and "git status" all use "index" before they mention "stage*". I can live with both of the terms and would like if we would have one term ... but for me it's not clear what term would be better.
So maybe what would be better would be to work on the "Git Staging" view to rename it "Git Commit" view and replace "Unstaged Changes" by "Working Copy", "Staged" by "Index (staged for commit)", so the Index term appears more clearly in this central piece of EGit workflow and further references are better understood by users?
(In reply to Mickael Istria from comment #9) > So maybe what would be better would be to work on the "Git Staging" view to > rename it "Git Commit" view and replace "Unstaged Changes" by "Working > Copy", "Staged" by "Index (staged for commit)", so the Index term appears > more clearly in this central piece of EGit workflow and further references > are better understood by users? If you think the staging view should be renamed I would rename it to "Git Status" view. Instead of "Working Copy" I would use "Working Tree" which is widely used in git online help and documentation. There is also a worktree command [1] which enables using multiple working trees for the same repository instance. There is some work in progress from Andre for adding JGit support for the worktree command [2]. [1] https://git-scm.com/docs/git-worktree [2] https://git.eclipse.org/r/#/c/126454/
(In reply to Matthias Sohn from comment #10) > If you think the staging view should be renamed I would rename it to "Git > Status" view. > > Instead of "Working Copy" I would use "Working Tree" which is widely used in > git online help and documentation. There is also a worktree command [1] > which enables using multiple working trees for the same repository instance. > There is some work in progress from Andre for adding JGit support for the > worktree command [2]. > > [1] https://git-scm.com/docs/git-worktree > [2] https://git.eclipse.org/r/#/c/126454/ All that is good to me, I think it would improve consistency of EGit itself, and of EGit with Git CLI, ultimately leading to easier handling of the features by users.
Whatever... if the titles of the unstaged/staged viewers are changed: * don't make them too long, otherwise it won't work well when the view is shown vertically, and * remember that the two titles have tooltip popups on hover.
I'm marking this one as INVALID as it seems like EGit would better standardize around the term Index whenever possible. So I've made another proposal in bug 548549 that I think would help some users getting a clearer feeling of what's possible when navigating from Git Staging view to compare editor.
