> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…
> learning git took a lot of trial and error, but now whatever terminal I sit down in front of This insight why git, like other tools, is stupidely designed. The "wrong" defaults and UX is the DEFAULT, and each USER must learn it. Meaning: UX * N Users = Wasted time and money --- If I present you a screenshoot of a (real!) business apps with mis-aligned buttons, some put in weird places that mean different things tha…
I think the tool in question (git) is complete and what you want is an incomplete simplification. Preferring incomplete simplifications to complete toolchains is hobbling and a significant hazard to your project.
Git's problem is 3 fold: * It is too powerful * It is not prescriptive * It has horrifyingly bad UX/semantics Git exposes all of its complexity at installation, which means that you are able to do any amount of damage from minute one. There are no cascading layers of abstraction that map onto the user's comfort level with git. Git also doesn't prescribe workflows. Overtime, people have come up with standard workflows…
I see a lot of criticism but not very much any suggestion that would avoid users having to learn how to rebase on an origin master branch or how to force push when they rewrite history. All the git interfaces, including github's web interface particularly, are fine to fix a typo but not really to iterate and create a perfect history of commits.
Based on my experience with users who did not have a programming background, there is no reason for letting them know about neither rebase nor rewriting history. If you are rewriting history, you are already ahead of the curve and you can use the command line. Commit, push, pull, branch and merge are all 90% of users need, and those last two are already an advanced topic.
For a good example of "user friendly git" I suggest taking a look at mercurial.
You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?
> You really believe that git stores -- in full -- every version of a tracked file? Yes, it does. > Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space Yes, it is. "It's worth repeating that git stores every revision of an object separately in the database, addressed by the SHA checksum of its contents. There is no obvious connection between two ver…
>>> if I want to do something more complex If you want to do something more complex, the reasonable answer is usually to delete the directory and clone again.
https://xkcd.com/1597/
This is because every cloned repo stores local state. Local state is sticky, it collects garbage, and it becomes stale very quickly.
Doing something complex in git with a local repository is usually not the thing you want. What you want is to fix some garbage state you added to a local. Hence, turning it off and turning it back on, instead of pushing garbage state into the central flow.
Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?
git fetch && git rebase origin/master, which is equivalent to git pull --rebase origin master, requires your worktree to be clean, so you must either commit or stash if you have any local changes.
I think you're twisting the problem statement a little here. Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back". The problem is that, regardless of your intent, you've given something to someone and they own it now. You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email). And I want to be clear upfront…
I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not…
VCS exist to make it possible to organize and track changes to project source code. Convenience of the user is a secondary goal to clear organization and code management.
A VCS shouldn't be unnecessarily difficult to use, but the fact that this conversation around Git's UX is endlessly rehashed is proof that version control is a hard problem.
If there was an easy and obvious 10x improvement over Git it would have replaced Git by now. Or to put it differently, when someone makes an easy 10x improvement over Git, it will see widespread adoption.
If you have to pull while your work tree is dirty, it’s best but not easiest to branch & commit (safest and avoids the possibility of conflicts during pull), or commit & pull with rebase (safe but might have conflicts). In case you weren’t aware, stash is not as safe as other git commands, it doesn’t have the same safety net and reflog support as a commit does. It’s relatively easy to drop stashes accidentally and lo…
It's interesting that you mention branching, because that is another workflow where I feel that I constantly have to reach for stashing - when I simply want to move to another branch (either for a quick bugfix or simply to check something). Otherwise yes, I know you can relatively easily lose work with git stash (I actually once lost about 2-4 days of work with a P4 shelve, which is an extremely similar feature), but…
It might be worth really picking apart why you think you need to stash instead of commit, and why stash feels easier. I honestly don’t think committing is any more work than stashing at all, not even more typing. It’s really not more difficult to commit what you have temporarily, go to another branch to work, then come back and continue working, compared to stash. But I don’t doubt that it feels more difficult for some reason. Is it the need to make a commit message that causes the mental friction? Does git reset somehow seem tricker than git stash pop? Think about how you typically rebase when you’re done anyway, so that means when you come back to a branch with a temporary commit, you don’t have to stash pop, you can just add more changes and squash or rebase it all later. With the stash workflow you have to keep the stashes in your head, and manually pop them. They get harder to manage than branches when you have multiple stashes, since they’re disconnected from their context. Personally I think if you examine what it really takes to use commits & branches, and practice using them more, you may find it’s just as easy as the stash workflow, if not easier, and it comes with a wider safety net and is easier to manage when you have a lot of different changes in flight at once. I also think it helps to realize that a branch is nothing more than a named SHA, they are incredibly lightweight, and using them ought to reflect that.
Is has already been mentioned a couple of time in this thread, but it deserves a more prominent mention, because IMHO it's a really interesting project.
The author(s) analysed git UX shortcomings and tried to learn from them. For example, Gitless aims to align well its concepts with user's intentions. There have been written research papers (and a talk is available online) about their methodology and Gitless design: