FredrikNoren
Commit via staging area needs to become default
Teaching newbies to construct commits by adding whole files (or worse, just committing ALL current changes), means they will be taught to create commits that are useless when one has to find the source and reason of existence of a bug, and as such will both make life difficult for other developers and be worse developers themselves.
As such, the default commit mechanism needs to be one of commit construction. Successful UI for this has been demonstrated in core git by way of git gui and should be trivial to implement in terms of hardness of the problems to be solved.
Edit: To clarify, the issue is both that this functionality does not exist at the moment and that when it is implemented it must be the default.
I would disagree. I think staging should be an option (or at least some way to exclude files from commits), but the idea is to make git easier, and requiring staging adds another step in the process. So...
-1
Excluding files from commits is not nearly enough, there needs to be the ability to select with granularity the lines to be commited. As i said, an excellent, successful and very easy GUI for this exists already with git gui. If you make git so easy that someone learning it will go away without crucial knowledge for professional development environments you're only damaging them and the people forced to work with them.
I agree that people should learn how to use staging properly, but I don't think that the interface should make them learn it before they can use git. Rather, they can learn it when they need to use it.
Especially since it's very easy to work without it 90% of the time, you just don't make a ton of changes without committing. Then, you can commit everything. Further control only becomes necessary when you have changes that you don't want to commit.
Especially since it's very easy to work without it 90% of the time, you just don't make a ton of changes without committing.
That only works if you're already a disciplined developer. From less experienced people i constantly see massive blob commits and they are using the command line.
We can perhaps separate out the concerns here.
One requirement is to have a staging area. The second is to make it a default.
I suggest that we track them as two different issues. The reason is that I personally don't care if its default or not, as long as there is a config option turn it on / off.
Since the title of this issue is about the defaultness, and since some discussion has already happened here, I am creating a new issue: #99
I disagree that those are separate concerns, since any reasonable good implementation of such UI (as git gui has done) will make it equally easy to add whole files or single lines or hunks. Seriously, just play around with git gui before commenting on this. (It's also important to note that visually most of the UI for this already exists in ungit.)
@hrj - I agree, these should be separate concerns. I fully support adding a staging area, I just disagree on the default-ness.
Actually the staging SHOULD be default. Not making it the default just works against a very central concept of git. Even if you want to make git easier, the staging area is an important concept to grasp early on. Otherwise, people will just get used to 'git commit -a'. And once they've gotten used to it, it's often too late to change bad habits.
Ok, maybe it should be an encouraged part of the UI, but it shouldn't force the user to stage... can we agree on that?
@slang800 Would you consider it being forced to stage if you could just could click buttons to stage either all new&changed files, or individual files wholesale?
@wchristian that isn't bad at all... I wouldn't use buttons, a list of files that you could select individuals from, or hit ctrl+a to select them all would be better, but so long as there is an easy way to commit, without needing to think about staging, I'm all for it.
@slang800 That is exactly what the existing interface in git gui is like. :)
I totally disagree with the premise of this bug, by the way of the simple fact that I think to learn git effectively, one should learn to use the command line tools. No UI is going to encompass every command that git has, and in that regard, serves only to make git easier to use for experienced developers.
Ungit is not a teaching tool - its a time saver ans state visualization tool for those of us who utilize git on a daily basis. @wchristian keeps citing git gui as a model for unfit, which begs the question, 'what's wrong with just using git gui?' Ungit may not be for everyone.
I support keeping the ui as simple as possible, and this means not adding this as a default feature (although I'm not opposed to the feature being added, just the defaultness of it).
-1
I totally disagree with the premise of this bug, by the way of the simple fact that I think to learn git effectively, one should learn to use the command line tools. No UI is going to encompass every command that git has, and in that regard, serves only to make git easier to use for experienced developers.
Ungit is not a teaching tool - its a time saver ans state visualization tool for those of us who utilize git on a daily basis.
There are also advantages for people who use git professionally, since any experienced git developer will be using composition (git add -p) as their default. I didn't feel the need to make that point since educational side effects are vastly more valuable than increases of daily convenience.
To be honest, as it stands ungit isn't even remotely useful for me, since its functional capabilities are limited, and its visualization is cute, but (to reuse popular internet phrases) "doesn't scale". At the time i last tried it it did't show more than a handful commits on screen, and as such was more suited for newbies than professionals.
The reason i made this ticket is that ungit screamed "newbie tool" very loudly.
(I hope it is clear now why i won't address your digression on git gui.)
I support keeping the ui as simple as possible, and this means not adding this as a default feature (although I'm not opposed to the feature being added, just the defaultness of it).
What exactly is your opposition to adding this as a configurable feature, with compositing being the default? The change would only, when faced with the diff view, have added the ability to also click on it to select/unselect portions of it, thus keeping it almost exactly as simple as it is now. And if you really hate it, switching the default to git add -p would be trivial.
Having git add -p in Ungit would be awesome (and yeah I can't really see how it would be done except by following the staging area model of git closer). In general I try to follow git as close as possible with Ungit (it makes it so much easier for someone to debug their git problems when there's not a completely separate model between them and git). In this case I didn't however, mainly because I couldn't find a good balance for the UI. Iirc the problem was that I couldn't really use checkboxes since a file can have a lot of different states simultaneously in git (it can be staged and changed for instance), and it added an extra step to committing (needing to add all files first). It might be possible to overcome that though with a bit of work.
And as of today, it's actually possible to write plugins for Ungit, so I would urge anyone who want's to give this a go to do just that; write a plugin that replaces the current staging area and try to make it work. The components in Ungit are now written as plugins themselves, so if someone manages to nail this in a plugin it would be a small thing to merge it into Ungit proper.
As for an alternative to the current staging model in Ungit, I'd recommend the model described in the article linked in #395. The idea of treating the staging area as "just another commit" makes a lot of sense IMO.
Every git GUI I've used has a staging area if it allows the user to create commits. I was very surprised not to see one in ungit, which is otherwise a very useful tool. I highly advocate for #99, and I do think it should be the default behavior.
If you think about how the command-line version of git works, ungit is almost implementing git commit -a, which commits all modified files. However, the flag is necessary in the command-line git because it is not the default.
