3 ms·
Git's plumbing is simple and intuitive. Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it
by grey-area 6y ago
Git's plumbing is simple and intuitive.
Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it is slowly improving. For example, they've just added a restore command which should make it simpler to undo changes (git restore filename):
https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things
Things I'd also like to see improved:
Undoing things locally should be very simple and intuitive - perhaps restore will help.
Conflict resolution when changes happen on the same line, so that there are fewer clashes on rebase/merge.
Git log should be compact and pretty by default
Git push should push tags as well by default
Deleting tags etc on a remote has a really weird syntax - git push origin :tagname git push --delete origin tagname just feels really odd instead of using the tag command.
There should be a simple way to add all changes and commit - e.g. git add --all && git commit -m "Message" if that could be git commit "Message" that'd be great (probably not possible but at least a flag on commit would be nice). I have an alias set up for this. I like being able to add files separately to a list then commit too, but that is far rarer, most of the time I want to commit all changes.
A blessed workflow - perhaps this isn't possible but having one workflow would make it simpler to move between repos and simpler. Many projects seem to have settled on main=production with short-lived feature branches rebased off main and edit as necessary locally before sharing on main. This works well for us at my workplace.
git start - a guided tour command which steps a user through a typical workflow and shows them the commands they need (probably about 5 commands initially), and tells them the difference between local and shared commits (fine to change vs never try to change).
These are pretty minor gripes though most of which can just be fixed with some aliases for commands - I'm pretty happy with it and much prefer it to what came before.
- etripe 6y agoExcellent ideas! I agree with you on all fronts, exception git add --all && git commit. I don't believe those should be joined at the hip, because staging and committing should be two distinct actions/decisions. Defaulting to including everything would lead to too many human errors and would therefore be dangerous in my opinion. A distinct flag like git commit --all -m "foo" might be OK in my book. Possibly even adding some git config --global commit.all [default|confirm] or something. Then again, who am I?
- grey-area 6y agoYes I don’t think they can change the default now but many many people operate this way (commit everything not ignored), so most of the time don’t need to separate stage and commit (I agree there needs to be a way to do it, but I use it rarely). My preference would be a command like git save, but a flag would be fine I guess. This is a concept that most beginners don’t really want or need. Ideally git should evolve so that beginners can learn say 5 standard commands without args, and that’s enough to get on with their work. Working should be as simple as: git save, git amend, git tag, git push Make everyday use simple and easy.
- etripe 6y agoI'd personally also love a config flag (enabled by default, perhaps) that offers more explanation about what the commands actually do as you run them. In other words, "explain like I'm five" logging or "tutorial mode".