Bugzilla – Full Text Bug Listing
| Summary: | Rework labels for "Git Staging" view | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Mickael Istria <mistria> | ||||
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | loskutov, michael.keppler | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547589 https://git.eclipse.org/r/144734 https://git.eclipse.org/r/c/egit/egit/+/144734 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mickael Istria
Created attachment 279045 [details]
Patch (while Gerrit seems in a bad mood)
Reading the diff I couldn't like the change. "Git Status", "Status view" - what? Another one synonymous to "staging area" and "index", but far less concrete or understandable? "Status" of what? Repository, remote branch, submodule, files, merge, rebase? I feel this "Status" is too generic. I personally don't have problem with staging area or index, and no one in my lab either had any questions to me about the Git UI wording. *If* we want to start rewording EGit contributions, we should not add more confusion as necessary. We had *two* words for same - let not invent third one, but reduce to one - and in my eyes this would be "Index". "Git Index View" is clear and concise name for a view showing ... surprise ... Git index. It's unfortunate I didn't see the other bug earlier on. I'd like to put the focus on another area than just unifying labels: user experience. I do "babysit" a huge amount of developers in our company regarding git usage. Most of them start working with git without any technical git background, just because they "want their files backed up" (myself included, some years ago). For those developers with limited git knowledge the labels "unstaged changes" and "staged changes" are way more easy to understand than "changes in working tree" and "changes in index". Even after some months of working with git, many of them just don't know at all what a "working tree" is, and they only have a fuzzy feeling for what the index is. Therefore I'd rather avoid any implementation terms in those labels and even use something as simple as "Not in commit" and "In commit". This is the typical "different mental models" issue which makes software developers not understand why the users of their software struggle with using it. Ok, so what about * «Git Staging» view -> «Git Commit» * «Unstaged changes» -> «Not in commit» * «Staged changes» -> «To commit» And in compare editor * «Local» -> «Not in commit» * «Index» -> «To commit» New Gerrit change created: https://git.eclipse.org/r/144734 (In reply to Andrey Loskutov from comment #2) > Reading the diff I couldn't like the change. "Git Status", "Status view" - > what? > Another one synonymous to "staging area" and "index", but far less > concrete or understandable? "Status" of what? Repository, remote branch, > submodule, files, merge, rebase? I feel this "Status" is too generic. `git status` is a Git CLI operation anyone who've followed a git tutorial do know about. The CLI is the de-facto standard of wording, EGit should just mimic/adopt it, instead of bringing additional terms that are not in the CLI (ie Git Staging). The "standard" terms currently used by `git status` say * Changes to be committed * Changes not staged for commit * Untracked files (special case of the above) > I personally don't have problem with staging area or index, and no one in my > lab either had any questions to me about the Git UI wording. I think that's the force of habit. Sure, it doesn't take too long for newcomers to get used to EGit wording, but for a newcomer with Git CLI experience, it feels a bit alien. Newcomers would use Git CLI terms, they'll in look in Ctrl+3 for a `git status` not for a `staging view`. Not welcome. Closing. |