Hacker News new | comments | ask | show | jobs | submit login
Show HN: I made a tool that made me faster at Git (github.com)
551 points by jesseduffield 6 months ago | hide | past | web | favorite | 229 comments



> are YOU tired of typing every git command directly into the terminal

I'm not. Are there many people that are? Is this not just a matter of learning to use shell keybindings effectively? That and aliases does wonders to avoid repetitive typing. Many times I type `git s` (alias for `git status -s`) out of reflex when I really meant to do `ls`.

When I forget to add `-a` to `git ci -m ...` (`ci` being `commit`) and get an error because the index is empty, I just `<caps>kF-aa<enter>` (<caps> being <esc>) to add it and re-execute. It's muscle memory; I do it before I even realize I did it.


If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit.

Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE.

Vs code with git lens or intellij idea have excellent git integration. Everything is one shortcut away. The git commands that are used are log into a console if you want to check.

At the end of the day both methods work, it's just a matter of preference but it is worth trying a good git UI.

Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help.

That's why there is definitely a space for this kind of git UI as presented in the article. [1]http://stevelosh.com/blog/2013/04/git-koans/


> If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit.

I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Git is only tangentially related to file editing, so it doesn't really make sense for an editor to know anything specifically about it.

> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE.

But I am! The whole OS is my IDE.

Seriously though, I've done fugitive in vim and magit in emacs. After some time of using them almost exclusively, I've decided it's better to use the shell. It's not because I haven't tried more "integrated" ways of programming, but because I find that the flexibility/power that comes with treating every feature of an IDE as a separate program in an OS environment is better.

EDIT: Added more comments.


> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?

Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs should support Git.


> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?

I agree with this. Strongly.


> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically?

That's similar to saying "a smart phone is a smartphone" why not have one device to take calls, and another to store contacts, another to browse the web, another to listen to music. It's ergonomics.

Many things are more efficient when integrated.


In my experience of using git integration features in IntelliJ, they are nice for simple tasks like quickly checking the status of a file or committing all the changes, but as soon as I need to do more complex tasks in git, I find the UIs either get in the way and slow me down or just aren’t fully featured enough to do what I need to do and I end up back on the command line. Hence why I always encourage newcomers to git to learn both if possible.

I do agree that git could certainly do with a more consistent command line interface - but I imagine that won’t even be considered until that next major version of git, if it ever arrives.


Git integration in IntelliJ is terrible IMO. It conflates staging and committing, and unstaging with reverting. I don't use it because it is a PITA, but what is even more annoying are the PR's from team members who do use it, which I have to send immediately back due to random files.


The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history.

I've never used it for anything else git related because the ui is strange.


True, but frankly it is Git’s model that is broken, or at the very least overcomplicated.

I do not care whether files are staged or not up until the point I actually want to commit, so personally the IntelliJ way of doing it is perfect.


> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE.

I have used IDEs but I still prefer the CLI client.

Like with most things in IT, GUIs are great for simple things but the CLI is more expressive and exposes more options. Then once you've spent enough time using the CLI tools it's sometimes more jarring to switch between the GUI and CLI than it is to just use the CLI for simple tasks that could easily be done in the GUI.


I used the ide interaction then moved to the terminal once I realized there are really only a subset of commands you need to know. There are visual things that are still handy that the ide does, but to perform commands, I feel like the terminal is more explicit and you know what subsequent steps you’re taking (relatively, of course).

Same with vim. Too many options. Poor UX. Eg. Why are there two way to scroll down? Just use ctrl-d which helps you retain the context of the code you’re navigating.


I do a git diff after every git status before adding/committing. Do IDEs show diff before committing? Jetbrains IDEs do show diff between subsequent commits. Although they do highlight which files have been modified.


> Do IDEs show diff before committing?

Not as part of the same operation, but the usual workflow is that there's a pane in the somewhere that lists all modified and staged files, and you can click on those to see diffs (or just click "commit" if you don't care).


I only expect my editor to read some information from my git repository. Gutters displaying new/modified hunks and shortcuts to jump to them are pretty much the only things I find useful (for my use; I understand some will find other features helpful).

But any action I want to be made on the repository, I do it myself.

I have some exceptions though, like if I want to revert the hunk I have the cursor on it's nice to be able to revert (or even stage, but I still use `git add --patch` for that) it with one shortcut.


> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE.

I think this statement is much more powerful in reverse. People who prefer the git features of their IDE have probably never seriously tried to leverage the features of git...

I prefer the git command line. It supports every single feature of git, and as an interface it’s completely and totally frictionless.

People trying to create tools and UX around git usually do so under the false impression that git is the source of friction, when really they are.

> Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help.

Are there people who need this kind of help learning, but then go on to do well at it?

I’ve found programming in general is extremely binary. Either you’re the kind of person that can grasp it and has the motivation to track down answers yourself and hack away, or you aren’t.

Being able to pick up a new system or technology and understand it very quickly is what it means to be a programmer, even more so than the act of programming itself in my opinion. I think trying to find shortcuts around that to teach people is a bit of a catch-22.


I turned off everything, autocomplete (the auto drop down menu style), the status bar, line numbers, git gutter, color changes from git in the tree view, live linting. Main thing enabled is auto format on save, and a bunch of 1-2 letter aliases for common commands. My editor is a sea of calm tranquility now.


My IDE is bash. I use almost always use emacs -nw for editing text. While there are git front ends for emacs, I almost never bother with them. I can't remember what I've memorised about the git CLI, but usually I don't find the CLI troublesome. YMMV.


> intellij idea have excellent git integration.

I find all the colors and ques distracting while I am coding.


If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit.

Unless you're on someone else's machine. Then you'll still need the cli.


In that case one should stick to using vanilla git with no aliases, shortcuts, etc.


I'm also not tired of typing git commands. It seems almost natural now. With that said, this individual spent their free time to create something using their skills which they perceived to be an improvement/optimization upon their skill-set and shared it with the world.

IMHO, that's commendable.


It definitely is. I didn't mean to sound dismissive of his work, but I can see how it does. My intent was rather to inform those who haven't realized, OP seemingly included, that the shell can be very efficient to work with. I can't see myself using this tool and being more productive than I already am with the shell, but I can still appreciate the effort and generosity in making it available to the world.


I mean, to be fair, you are essentially saying you are not tired of typing git commands only because you type shorthands you've created. It feels like you're raining on his parade a bit because he didn't do the same thing you did.

I use aliases too but I also use SourceTree (gasp) for bigger commits. It's not even that I don't know how to git add -p, but clicking "add this hunk" is way easier to do.


> I mean, to be fair, you are essentially saying you are not tired of typing git commands only because you type shorthands you've created. It feels like you're raining on his parade a bit because he didn't do the same thing you did.

Well, it's not like I did something unique. The aliases feature of git is precisely to make commonly used commands shorter, so I found it odd that OP would make a whole new git front-end, apparently to solve the same problem. That's why I asked, "Are there many people that are?", because I wanted to know if many others also found the shell insufficiently efficient and maybe discuss that.

I didn't mean to rain on his parade, but I can see that he might not have expected his post's discussion to mostly be about CLI vs GUI or integrating git with editors vs not. I honestly did not expect this much discussion to come out of my comment, either. Then again, how a discussion develops within a community is not really in any individual's control.


I'm not. I use GitHub Desktop for commits (with a subset of changed lines sometimes), pushing, pulling, merging, creating and deleting branches, looking at changes I did since the latest commit. I've used command line for changing executable bit in index once.


If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run.

Version control functions should be available right in your editor (e.g. magit) and you can't really beat one character hotkeys for version control stuff. It doesn't get more convenient than that.


Seconding the in-editor approach. Magit is wonderful (though I often do end up heading to the command-line for certain things out of habit).


I think it's good to keep doing some things via command line, so as not to forget how Git works "under the hood". I also keep my Git alias commands to a minimum for a similar reason.


For me flow is important, so that I don't get distracted when working. The best way to achieve this is having single key shortcuts.

Knowing how GIT works uder the hood is less important than staying in the flow, at least for me as a developer. People responsible for repository maintenance may have other priorities.


> If you status, commit, diff often then you don't want to leave your editor, because every little things (switching to a terminal just to do git stuff) adds up in the long run.

That sounds like limiting the functionality of the whole computer to what the text editor can do. That doesn't make sense. Next, you'll want to browse the web from the editor because you don't want to leave it (just because emacs does it doesn't mean it isn't absurd).

Anyway, I think it's better to configure the system so using multiple programs is as quick and effortless as possible. For your example, I use i3, a tiling window manager, and have the screen split with a terminal window on the left and my editor on the right. If I wanted to check `git status`, I just type `<super+h>git s<enter>`. To go back to the editor, `<super+l>`. There's really not much difference with a single character shortcut.


That's a terrible analogy. I only use git with my IDEs and only use my IDEs with git (except one weird outside project at work where I have to use a partner company's TFS). So integration makes complete sense. Hell, that's true whether you use CLI or GUI. I use my browser for an infinite variety of different activities, only a tiny subset of which relate to my IDE.


> Next, you'll want to browse the web from the editor

Well, you're clearly replying to an emacs user. He/she will not find that statement the least hyperbolic.


I do. I use a separate browser. There are people who want to do everything from their editors. There are people who want to do only editing in the editor.

And there are middle ground people like me who want editor integration when it makes me more efficient (like invoking frequent VC commands right from the editor), but I do mail and browsing and stuff with external tools.


> That sounds like limiting the functionality of the whole computer to what the text editor can do.

Not really. It's about putting the most frequent features into your editor, so they can be accessed effortlessly. If you have to do something which is less frequent and the editor does not support it then you still have the terminal.

> If I wanted to check `git status`, I just type `<super+h>git s<enter>`. To go back to the editor, `<super+l>`. There's really not much difference with a single character shortcut.

It's efficient compared to switching to the terminal with alt-tab or something, though by single shortcut I meant that you can use it right in your editor buffer, so it's really just pressing one or two keys vs. `<super+h>git s<enter>`


Phil Haack has a nice set of aliases that I've grown reliant on: https://haacked.com/archive/2014/07/28/github-flow-aliases/


Learning git by heart has immense value if you've got a team that doesn't grok rebasing and merging or just a cross-functional team with QA's commiting to a monorepo.

I can diagnose and fix issues for people in around 5 minutes leaving them with history that works everywhere and I don't need to jump to my workstation for reference on aliases.

Thankfully, people I work with seem to like git, except for the odd git push --force breaking branches for them.

That reminds me that I'll have to teach one QA to do rebases. His merges break our history graph in funny ways.


Since `git status` is my most common command I've got it aliased to just `s`. Every time I use another machine it throws me off when the command doesn't work :)


This is why I advocate against aliases. History is universal, more powerful and needs zero configuration. ^r and few keys takes me to any command part of my daily repertoire. It really shines as the commands get more and more verbose.

^rstat -> git status

^rcomm -> git commit

^rkout -> git checkout -d foo

^redit -> git commit --amend --no-edit

^rdeco -> git commit --oneline --decorate


I have similar ones set up. 'Pull' and 'push'. Though some days I'm tempted to map all the old SCUMM keyboard shortcuts here.

'y' (yank) = git pull

's' (shove) = git push

'g' (give) = git commit -am x

'o' (open) = git checkout x

'p' (pick up) = git branch x

'l' (look at) = git status


I use `s` to launch a new terminal window in the same directory as the shell that called it. This way, I launch a terminal, go to a project directory, and then type s<enter> a few times to get sufficient terminals in that context.

I know it's popular, but I think I'd find it confusing for completely separate commands to relate like that. It's like cups; I was really surprised to find that the shell command `cancel` was about print jobs. I'd thought it be something more generic. I like it that git keeps all these functions related as subcommands. Makes things more readable. `git status` is not general system status, it's git's status.


You might want to check out tmux. I've changed my terminal to "st -c tmux" and every time I open a terminal window I get access to multiple frames, (nearly) infinite scrolling, window management and more.


I use tmux when I'm connected on a remote computer and want to do a command that takes a long time and that I don't want to kill if I happen to cut the connection for any reason (e.g. I leave the wifi range).

As to infinite scrolling and window management, I prefer to set the scrollback buffer length on my terminal (urxvt) to a ridiculously large number, and use a real window manager (i3 for me). It's kind of weird how so many applications have their own specific window manager inside them, like tmux (windows and tabs) or text editors (vim and emacs windows and tabs) or browsers (firefox and chromium tabs) or file managers (dolphin and pcmanfm tabs) or spreadsheets (sheets). i3 allows me to tile, tab, or stack any windows I want in any arrangement with a single set of keybindings (as opposed to the differing keybindings of each application).

Anyway, another thing that's cool about tmux is copy mode. It's awesome to execute a command, hit a key to be able to move the cursor throughout the whole buffer, and copy some piece of the output any command you've executed there, to then paste in a new command. I found that urxvt has an extension that allows the same thing, and it uses the system clipboard! So, I can not only use what I copy for a new command, I can use it elsewhere like copying a url and pasting it on a web browser using only the keyboard. It's also useful to do searches in the output of commands I've executed. So, if run a command that produces a lot of output and I want to know if it outputted something in particular, but I don't want to rerun it to pipe to less or grep or I know that it's not going to result in the same output, I can just hit a key, type what I want to search and see if it finds it.


I also aliased git to g, so I can type "g l" for git log.

I also had even shorter shell aliases like gl, but abandoned that. I'm switching shells to often and their configs are constantly out of sync which confuses more than it helps.


I bound hstr to CTRL-R (https://github.com/dvorka/hstr) and then just search the history for the keywords I need. Only rarely is a command not already stored in the history.


I use zsh + antigen + oh-my-zsh's git plugin which comes with a lot of aliases. For example, `git status` is `gst`: https://github.com/robbyrussell/oh-my-zsh/blob/b6ca933a02ed7...


What is `<esc>kF-aa<enter>`?


He's referring to the vi command sequence he would type to amend his command, i.e. OP has 'set -o vi' in his shellrc or 'set editing-mode vi' in his inputrc

    # x| = cursor is in insert mode, after char 'x'
    # |x| = cursor is in command mode, on char 'x'
    # (<keys>) = keystrokes entered resulting in prompt on next line

    $ git ci -m "<str>"|    (<CR>)
    $ |                     (<Esc>k)    # puts shell prompt into command mode (<Esc>) and cycles upwards to previous command (k)
    $ git ci -m "<str>|"|   (F-)        # from current position, reverse search (F) and stop on first occurence of '-'
    $ git ci |-|m "<str>"   (aa)        # cursor is on '-' char, append (a) 'a', i.e. transition into insert mode by advancing cursor after current char, then insert 'a' literally
    $ git ci -a|m "<str>"   (<CR>)      # execute command
    $ |


I use TextExpander (I wish there was something comparable on Linux!) and I have aliases defined:

,gcm for git commit -m ""

,ga for git add -p

,gl for git lg

and similar.

That said, I rarely use the terminal for git these days, Magit is just so much better.


Awesome work OP! I’m a big fan of using tools like this to supplement git, especially when it comes to some of the more complex operations.

Personally I use tig, which is basically this but different. I used to use Sourcetree and I loved it but it slowed to a crawl with bigger projects with long histories.

https://github.com/jonas/tig

Best screenshots I can find on google are ironically from the Atlassian blog:

https://www.atlassian.com/blog/git/git-tig


I use tig as well but I am currently experimenting with FZF and some gitconfig aliases.


If you're an emacs user, I can't recommend magit [1] enough. I was a diehard CLI user and had flags and aliases out the wazoo, and it was still a step change in usabilty and power for me. Staging hunks, rebasing, and stashing are all vastly easier. Amending or editing a commit is a breeze, and it's tied in to all of the other emacs tools you already use, e.g. org-mode to boot!

It's easier to see it in action than explain it. If you've two minutes to spare, check out this emacsrocks screencast [2], or Howard Abram's longer presentation from the PDX Emacs Hackers meetup [3].

[1]: https://magit.vc/

[2]: https://www.youtube.com/watch?v=rzQEIRRJ2T0

[3]: https://www.youtube.com/watch?v=vQO7F2Q9DwA


What I like most about magit is browsing the history of a file via its git-blame mode. It shows you the file split into sections indicating what commit was responsible for that section's lines. Doing `C-x g b` on one of those sections visits the file at that commit and does git blame again without needing to `checkout` that commit. I wish I knew how to be as effective doing that with `git blame` on the shell. Is there a way to provide the commit to `git blame` without needing to `checkout`?


You can specify the commit to look back from on the command line for blame. See [1]

> Optionally, start annotating from the given revision.

[1] https://git-scm.com/docs/git-blame


magit is lifechanging -- At this point I open emacs (assuming it isn't already open) just to use magit to manage things.

If you use it daily don't forget to donate to the developer at least once, sprinkle some of that full-time corporate cog money on them.


Seeing a former coworker use Magit in Emacs is what got me to look into the Vim version: https://github.com/jreybert/vimagit

From what I gather it's nowhere near as feature-complete, but it lets me create commits with immense ease and precision.



You may want to try emacs just for magit. That is, using it as a Git GUI while using VIM for everything else (if you don't want to switch).


I was a die-hard vim+tmux user before switching to Spacemacs.

Now I have all the power of vim’s modal editing with Emacs’ vastly superior ecosystem of packages.


> Seeing a former coworker use Magit in Emacs is what got me to look into the Vim version

What you should have done is use magit and looked into the emacs version of vim: https://github.com/emacs-evil/evil


Magit has a PR problem: most people think they need to be already using Emacs to use Magit, but that's far from the case. Indeed most Magit keybindings are single-letter like vim. I wish I could get more people to try Magit without being turned off by the fact that it's an "Emacs plugin". Hmm.. what if there were a standalone version of Magit? Would more people use it?


Based on those videos, lazygit looks like it does the same things as magit, but with a little more "chrome" (boxes around lists). How do the two projects compare? Could they be merged, or do they have fundamentally different philosophies?


The videos touch upon a fraction of magit’s capabilities; if nothing else, it’s a far more mature project.

But the real power is integration with the rest of emacs/being written in elisp. If I want to change or script behaviour, I have easy access to all the internals, and I can integrate it with other parts of my emacs workflow. For example, I can use magit to view the diff of a coworker’s PR, easily capture snippets, including links to their location in our internal BitBucket instance, into an org buffer, and then write up and send an HTML formatted message with my comments, syntax highlighting, etc to my colleagues with my feedback.

Similarly, my TODO list is managed by org, and I can have links to commits or files at a certain commit directly in my agenda or notes and jump to them.

This is all within my editor, with all the text editing, code navigating, and linting capabilities it provides!


Whenever I read a comment or blog post about Emacs I'm like "I should definitely try it out, because that sounds awesome", then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it.

It's the same thing with vim for that matter. A basic-ish text editor setup is trivial in both editors but beyond that things start to fall apart. Plugins/modes rely on being run in *nix environments to work well, and the workarounds for Windows are never 100%. The startup times start to suffer a lot too in vim and Emacs when you pile on a lot of features.

I think that's why VSCode has gained so much traction. For coding it's got easily 90% of the same features as both vim and Emacs (if not more), but it's trivial to set up and with many users being on Windows pretty much everything has first-class Windows support.

So that's what happens every time. I stick to VSCode and keep a lightweight vim setup around for quick text edits since it opens instantly. Perfect for quickly changing a config file or jotting something down if I don't have VSCode open.


>then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it.

The first few times I did it on Windows it was a pain (almost a decade ago). You had to install some dependencies manually. But the last few times I did it it really was a straightforward install, with everything working out of the box (except any commands that rely on GNU tools like grep). I may have been using an unofficial port - sorry but I don't remember the link.

My Windows Emacs is almost identical to my Linux Emacs. You wouldn't know you're not in Linux. That, for me, is the joy of Emacs - it behaves the same on both OS's.


A plain vim or Emacs is trivial to set up and is indistinguishable, simple config changes are also trivial, but once you go deeper into plugins/layers for things like fuzzy file finders it starts to fall apart because they start relying on Linux-only tools or the Windows equivalent tools aren't as good.

Some of it you can get to work after copious amounts of fiddling, but I don't have that kind of time or willpower. While it might not be as powerful the total amount of time I've spent actually making config changes in VSCode is probably about 30 minutes. This is including time waiting for extensions to download! Not to mention that it ships with many features out of the box such as git integration.


How did you get magit to not be slow as hell on Windows?

It’s brutally slow on my windows box and lightning quick on my Mac.


Best setup I've found was to run everything within WSL when developing on Windows and exporting emacs display to Mobaxterm's x-server for a proper emacs experience. Everything is extremely fast and I find myself using my Mac less frequently now since WSL is working very well for me.


>How did you get magit to not be slow as hell on Windows?

By using mercurial :-)

Had no idea magit is slow on Windows. Any idea why?


It’s mainly due to the cost of spinning up subproccesses and certain FS operations on Windows. Magit spins up a bunch of git processes for certain operations and can be quite slow due to it. Look into fscache settings for a speedup


> I think that's why VSCode has gained so much traction. For coding it's got easily 90% of the same features as both vim and Emacs

Is that a joke? How can you possibly know this if you haven't used emacs for a start. Do you really think it has 90% of the features of a 35 year old project?

If emacs is difficult to set up on Windows you should stop using it. The awesome stuff you hear about is mostly the result of using emacs on an OS that is decent for development. But if you insist on staying in your prison then you'll have to put up with what Microsoft lets you have.


I have used vim for god knows who long, and I've tried Emacs several times for a few months at a time before giving up. So I do think that for coding VSCode absolutely has 90% of the features that both vim and emacs offer. Note how I said "for coding"? That's not an accidental or trivial part of my comment. For writing and managing code the feature-sets are on par in all three for sure and if you disagree then I am going to suggest to you that you actually give all three a try and focus only on coding and you'll see what I mean.

I should stop using Windows because a single application is difficult to set up? Throw out my entire OS with the plethora of other applications I use because a single application that has had 35 years to get its shit together simply won't work well? That's a reasonable position for sure!

Developing on Windows works absolutely fine, and if you wan't to talk about prisons and what "Microsoft lets me have" how about we talk about the WSL? They have no reason to include it in Windows but they do. A whole bunch of Linux software became available over night in a native Windows environment because of something Microsoft did. The ones who are digging their heels in at this point are all the *nix developers who refuse to support Windows as a first-class platform, so talk about being in a prison! Your software only works well on a subset of all operating systems.


> a single application that has had 35 years to get its shit together simply won't work well?

It's because the people that like emacs don't like Windows. You would see why if you would try something else. If you want emacs to work well on Windows, do it yourself. Nobody owes you anything.


Nobody owes me, and I'm not asking for anything. I'm just lamenting the fact that things are the way they are.

I use both Windows and Linux, which is precisely why I want to use an editor that's properly cross-platform instead of using separate editors or use one that's configured differently based on platform.

Maybe you should try Windows? It sounds like you could benefit from broadening your horizons a little bit.


I used Windows full time until ten years ago. Like many it was my first introduction to computers. I switched to Linux and never looked back even once. I've had to use Windows at work for the last 9 months and it's been an awful experience the whole time. Nothing has changed.

If there was no option for a free operating system I would stop using computers in an instant. I won't go back. Ever.


I've used emacs on windows in the past for quite a bit. I don't remember it being particularly hard to install, either the cygwin ir the native Windows emacs buid.


Just change your OS?


I think it kind of proves my point when the solution to not being able to set an editor up is to change your entire OS...

(Also: no)


He has a point. Why complain about Emacs when the problem is Windows?

To be fair, I am known to use all three OS's from time to time. I just have conditional guards to prevent loading packages that break on Windows. Mostly everything works the same. In fact, I originally learned Emacs on Windows back when I was a younger and noobier programmer.


The problem isn't Emacs, since the core program works fine on Windows (as does vim). Many packages for both also work just fine.

But then there's that subset of packages that don't work fine. Some can be fixed with fiddling, but then you lose that Emacs thing of installing a package and be on your way (usually a point in favour of Emacs over vim I might add!). And some just can't be fixed, which leaves me either using a different editor for those needs or just not using those packages by using conditional configs.

However then we run into a little peeve of mine: the reason I want to use a tool like vim or Emacs is to have the same tool working the same way everywhere. I don't want to learn and more importantly maintain two setups. I want to sync my one setup across any machine I use and have it work the same way. I also don't want to have the situation that my editor works one way on system A and another on system B.


Your OS becomes irrelevant when emacs itself is your OS!


> are YOU tired of typing every git command directly into the terminal, but you're too stubborn to use Sourcetree because you'll never forgive Atlassian for making Jira? This is the app for you!

lol


this readme really speaks to me


I'm out of the loop. What's the story here? Why are devs sad about Atlassian and Jira?


Jira has some asinine design issues, e.g. the only way you can link a git commit to a ticket is by putting the ticket ID into the commit message, generally has confusing choices for UI, code blocks {code}are annoying to add{code} and don't follow any existing conventions, integration with Confluence sucks, basic functionality is locked away in paid extensions, the list goes on


My biggest complaint is the nonsensical UI. I never know when I click a ticket if I'm going to get a) a split screen view, b) a modal pop up, c) a full screen view, or d) sirens in the distance.

When I click the 'back' button, I never know if I'm a) closing the ticket I have in a split screen, b) going back to the search results, or c) going back to Confluence and losing my search results and wondering how I was in Confluence to begin with.


Things could be worse. Nothing made me miss jira like using Rally.


I spell it Raly, just to make it a four-letter word.


+1

You'd think this would mean there was a healthy market for native client apps using the JIRA API with a more pleasant UI (as there certainly is for Git, e.g.), but strangely not.


MVP Jira just needs to present a list of stuff to do. But now it's used like a panopticon of social control where I work. And I'm thinking I'm not the only one with stuff like Scaled Agile being out there.


Jira doesn't have to be evil. It is intrinsically awful due to that tendency enterprise database products have of growing the flexibility to reimplement various wheels inside of them, poorly. But using it for evil depends on managerial intent.

At my gig, everyone grumbles about Jira, because it sucks; see above. But, we have workflows built primarily around it with various integrations, and it works for coordinating ~200 folks in a starting-to-get-there "Agile" model.

It is actually the worst for the managers - they spend a surprising amount of time noodling around in Jira to feed the workflows. For individual contributors, it works and isn't too much overhead.

From an administration standpoint, it is OK (we run the on-prem version). More stable than some enterprise monstrosities, but the with occasional problem. The plugin-store-thing is annoying - somehow it manages to entice nearly every new business-side user into asking for some random thing, they usually get what they want, and then they sit unused aside from occasionally breaking things.


> More stable than some enterprise monstrosities

It must have gotten a lot of stability improvements since I stopped managing jira clusters a few years ago because, from the ops side of things, JIRA was one of our main "make a cron job that restarts tomcat every night" running jokes at multiple companies over the last decade.

I've also had wonderful (/s) experience with the unicorns in Gitlab but that's another tale.


That's what you get for putting unicorns in a product.


My previous QA manager tried to get the QA/engineering/product management groups to "do agile", heavily because of the agile board functionality added to JIRA. Nobody ever got any training on how to "do agile" but the fact that we were becoming an "agile company" was heavily pushed as the internal narrative, all the way up to execs.

Most of product teams still don't function with any kind of actual agile process. Many try to fake it by endlessly throwing all of their work into the JIRA agile boards, which constantly have sprints rolling over, and are impossible to track any kind of actual velocity with. On our team we just said screw this and went back to getting things done, and tracking things how we wanted to track them.

Don't even get me started on the nightmare that is JIRA TCM, which my company is currently still stuck with for test case management.


In my company they outright refused to pay for a test case management solution, so we are using this free plugin for Jira: https://marketplace.atlassian.com/apps/1214038/qaspace-test-...

It works alright.


> a panopticon of social control

Thanks for putting this into words for me. This is exactly how I feel about Jira. Incompetent middle management automates their micromanaging and enforces bad ideas about how their subordinates should do their jobs.


It's also daaaamn slow. And when you paste formatted content into it (at least from vim on a mac), lol, have fun cleaning up your newly-unformatted content.


> the only way you can link a git commit to a ticket is by putting the ticket ID into the commit message

Is there any other way?


Presumably after the fact by linking them entirely within Jira. You could mention the commit in the ticket, but that wouldn't make a back-link from the commit if someone's browsing from that direction.

That said, I don't really mind mentioning the ticket in the commit. It's relevant to what one is doing when one makes the commit.

But then I use gerrit at my job, so I don't have room to complain about others' systems.


It sucks when you work on public open source code with internal forks.


I think naming the branch and/or the pr title after the jira ticket works too. I think it just needs to contain it, too. My feature branches usually look something like feature/proj-123-short-description. But to be honest, my extended commit descriptions usually contain the ticket number too, so I may be remembering wrong.

Not sure if that's better or worse, though.


What happened to their UX designers?


Jira is Turing-complete.

Let me repeat that.

Your ticketing system is Turing-complete. I don't remember where I heard this first, but someone at my company (at least supposedly) proved it once.

Jira has managed to grow into such a bloated, complex, incredibly pointless piece of software that I've never met someone who likes it. It's like software design by committee, where every manager involved had some pet project that NEEDED to be included for some asinine reason.

Personal anecdote time: I had my interns start on Jira this summer. Three days in, I realized they weren't "getting" it because of how many damn buttons and knobs there are in the Jira UI. So, I switched all their issues to GitHub issues, and they went from having ~20 tickets in the project to over 100, and began adding, grooming, and closing their own without any input or direction from me. Sure, it's lackluster from an automation perspective, but they developed their own tagging system in the span of a few days and maintained their own board all summer.

I loved Atlassian for BitBucket in college, but when I entered the workforce and was forced to use Jira and Hipchat, I lost all love for them.


Can't read this thread without remembering the following nugget:

https://twitter.com/HackerNewsOnion/status/98160924222131814...

It's funny because it's true.

GitHub Issues is just so much more straightforward to use; throw Waffle on it for added functionality and your team is good!


it's really not that complex at all...


From my limited experience, Jira workflow at a company reflects the culture. Maybe jira can be a tool to surface organizational defects and deficiencies...


Honestly, it's just enterprise software. The problems I have with Jira are largely the same problems I have with any software developed exclusively for enterprise customers. Enterprise customers always get what they want, so every piece of enterprise software is a bloated piece of shit that does 900 more things than any sane person should ever want it to do, and nobody gives a shit because the people using the software are rarely the people deciding to buy it.


I think the reality is that the software is not bad. But it is very often customized to fit ridiculous management desire and it then become difficult to use. And it's always simpler to blame the tool than your boss.


Just like Zendesk and other outdated enterprise level software out there


I don't think it's any specific event. Many of us are forced to use Jira for everything at work and it has grown from a simple bug tracker to a confusing one-place-for-everything mess.


My favourite part of interning at Google was learning that tickets for Sev0 globe-spanning outages and "the bathroom tiles are too shiny and let you see into other stalls" lived in the same issue tracker. When all you have is a hammer…


For one thing JIRA tends to lock the UI while it's processing some of the requests.


You know what would make me faster at git?

"git undo" : undo the last git command line, whatever it did. Especially if you don't understand what it did or it overwrote local files.


Gitup has this for many operations. http://gitup.co/


Many operations have an --abort option during the process. In other cases, there's `git reflog`.


Some operations can't be undone. So you would need to wrap them in commands that would make undone possible. That would be interesting...


https://github.com/tj/git-extras provides "git undo" (among others).


It's a pretty useless wrapper over "git reset":

https://github.com/tj/git-extras/blob/master/bin/git-undo

It won't help you if you don't understand what the last command did or when it overwrote local files; it'll just make everything worse.


Nice, but the README suggests it only does commits. I already have a simple alias for that. The parent comment wanted to undo anything.


You could store your git refs in another git repo and take a snapshot of those after each command that changes things.


Not a CLI, but GitKraken does that for most commands.


Hey guys thanks for all the feedback so far! I whipped up a quick tutorial for anybody who wants to know the basics https://www.youtube.com/watch?v=VDXvbHZYeKY


This looks great. For some reason I don't mind using the GUI tools to view history and branches but for commits always use the command line. This should save some time and much typing.


I use TortoiseGit's GUI for everything except features that it doesn't have, like git add -p. It makes life so much easier when you can just right-click and go to "Show Log", search for something you care about, then right-click that one commit in 2017 that messed things up and click "Browse repository" to look at the entire repo & diff arbitrary files without checking out a single file messing up your work tree. Trying to do every single thing with a command line interface just sounds insane to me.


Different mental contexts, I think. I do the same thing.


I'm mostly using plain Git, but there's one thing for which I needed a TUI: line-by-line selective committing.

After trying to find something I liked, I ended up porting crecord extension for Mercurial to Git: https://github.com/andrewshadura/git-crecord


Thank you for this. I've been missing mercurial interactive committing for a while.


git add --interactive?


That doesn't have line-by-line functionality, and it's not interactive.

If you had a look you'd see git add -i is not even close to it ;)


I use VS Code and GitLens lately. VSCode’s diff view and GitLens explorer cover my needs very well.


Gitlens is incredible. I can't believe none of my coworkers I ever mention it to have used it.


The CodeLens feature in VS2017 is really similar, it's the only reason we pay for the pro license instead of just using community edition.


It's hard to believe MS still charges people who are making their platform more worthy and with competition from Jetbrains.


It really is amazing. To be able to mouseover a line of code and see who committed it, link to the commit and see what it was before... It saves so much time


Personally I have been typing all git commands manually into the terminal and never felt a need for GUIs or tools such as this.

There are a number of git shortcuts defined in my zsh aliases [0]. It goes like:

  # Git aliases
  alias g='git'
  alias ga='git add'
  alias ghb='git browse' # hub
  alias ghpr='git pull-request' # hub
  alias gp='git push'
  alias gpoh='git push origin HEAD'
  ...

Using these aliases, we rarely have to type more than 3-4 characters for a git command. Savings and efficiency not only add up over years of using git, but also accelerate as you become more proficient in using your own aliases that fit your special needs.

[0] - https://github.com/sungwoncho/dotfiles/blob/master/zsh/alias...


With Mercurial, I like that all commands can be abbreviated to their shortest unique prefix, plus some built-in aliases. So I type a lot of `hg up`, `hg pus`, `hg ci`, `hg pul`, `hg bo`, and so forth. Most of these are almost the same length as your aliases.

Whenever I have to touch git and `git co` doesn't work, I think, okay, fine, we'll go through the full dress rehearsal; `git checkout` it is.


Plus, actually sane command names, and super powerful functionalities (for example, answering to another comment, you always could "hg blame (annotate)" an arbitrary version of a file without having to check it out first)!


Hard to believe how git doesn't have them by default.


I've been playing around with hub recently, but ended up commenting out the "source hub alias" line because a) since I use aliases, you might as well be explicit, b) I'm tired of having to pipe my aliases to `sed 's/hub/git/g'` when I do `which my_git_alias` to send to other people, and c) I don't want to support github conflating the two when it's not that hard to remember which does what even if you don't use aliases.

Another tip, I only occasionally need git autocompletion withh aliases, but in zsh you can do something like this:

  # Enable zsh git completion for our aliases. 
  # See     https://github.com/mislav/dotfiles/blob/d82e79b8a500891a02ab28171974d68be7a35e12/shrc/git.sh
  if [ -n "$ZSH_VERSION" ]; then
    compdef _git g=git
    compdef _git gc=git-commit
    compdef _git gco=git-checkout
    compdef _git gd=git-diff
    compdef _git gb=git-branch
    compdef _git gst=git-status
    compdef _git gp=git-push
    compdef _git gd=git-diff
  fi
And obviously bash has an equivalent.


If you install bash-completion or use git-aliases [1], you can also get tab completion working for those aliased commands like so [2]. Lets you save some typing even when you need to pass a rarely used (or difficult to remember) flag.

[1]: https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases [2]: https://github.com/nickbarnwell/dotfiles/blob/master/home/.e...


Also simple but very handy:

  [alias]
  	amend = commit --amend --no-edit
  	ls = ls-tree --name-only --full-name HEAD
  	tree = log --graph --decorate --oneline --all
  	commit-date = "!gitcommitdate() { (export GIT_COMMITTER_DATE=\"$1\" && git commit --date=\"‎${GIT_COMMITTER_DATE}\" \"${@:2}\"); } && gitcommitdate"
There's also a whole boatload of commands in git-extras for those interested: https://github.com/tj/git-extras/blob/master/Commands.md


Personally I prefer to alias git to g, then setup my aliases in gitconfig.

https://github.com/GitAlias/gitalias

g f && g rom

git fetch && git rebase origin/master

You could go nuts and make it even shorter with https://github.com/thoughtbot/gitsh

gitsh > f & rom


I personally prefer to use a combination of a foot pedal and eye tracking cameras to enter a Reed-Solomon code of taps and blinks uniquely mapping to git commands.


I think I've met you at a conference. Were you the guy blinking U-S-E-V-I-M on Morse code during conversations


I'm guessing people just ignored it because he was in Insert mode the whole time.


But why? There are so many awesome tools like tig and magit!

- https://github.com/jonas/tig

- https://magit.vc/


Magit is great but it's just so incredibly slow at big repos. For certain things like Instant Fixup magit is still faster than the command line but most of the time I can do it much faster via the command line. Sometimes I'm not even sure whether magit is just slow or my emacs hangs.


Please post your OS and Emacs version.

Magit hasnt been slow for me since I upgraded to Emacs 26. Older versions of Emacs were not optimized for spawning processes on OSX and it was causing a 10x slowdown for some operations.


Perhaps I should revise my statement. It isn't magit itself that's slow, but rather magit is calling out to slow git commands. And while those git commands are taking up 100% of my CPU, Emacs itself is using 0% CPU and totally unresponsive.

Just a few moments ago I had to kill Emacs because magit was executing this command:

    git branch --remote --contains 10a1663bf96f


That particular issue has been fixed a few weeks ago. You should update Magit. Also you should be able to avoid killing Emacs by just pressing C-g a few times if some subprocess takes a long time.


I'm using the latest version of both.

Actually magit is quite fine for small personal projects. It's just that it absolutely chokes on a large monorepo I'm working on.


Thanks for making this, it looks great! I'll be giving it a shot tomorrow.

I've been moving more and more to terminal for all of my development. My dev. stack is now: vim; tmux; lynx; ddgr; zsh; and docker. It is game changing for distraction-free programming, consistency between languages, and the ability to use the exact same setup everywhere -- even on remote machines.


We need CLI to work on repo on remote servers. I was using tig but didn't like it for lack of ability to easily navigating file tree on each commit and this seems better.


I've been using Fork: https://git-fork.com/ because of its 2 primary advantages over SourceTree: • Dark mode • Tabs


I thought SourceTree had a dark mode? Although perhaps this was a somewhat recent addition.


Looks neat but no Linux version again :( There are 2 things I miss the most when developing under Linux and they are Sharex and Sourcetree. Smartgit is alright but not as good as the latter.


OT but considering Jetbrains stuff works on Linux there isn't much to miss except a decent git GUI but do you miss anything else? I just don't find the benefit of using Linux for development.


Ability to use proper shell (and env) for dev tasks and build scripts is the main benefit for me.

Sharex is the other thing I mentioned, its screenshots/screenrecords on steroids, check it out.


Sourcetree has tabs.


I have been using https://github.com/scmbreeze/scm_breeze, and though not as feature-packed, it does make the workflow fast.


I've been using this for probably 6-7 years now and it's become a standard part of my workflow. I've never had problems using git, but scm_breeze makes things faster (shorthand commands for common operations), and adds some nice bells and whistles. It's never caused a problem for me in the entire time I've used it either.


I’ve yet to find a git setup that is more productive (for me at least) than SublimeGit for Sublime Text. The combination of a text based interface with single character shortcuts, and the quick support for staging individual parts of files, means I’m probably twice as fast as the next best thing. It’s the reason I haven’t moved from Sublime to VS Code.

This looks like it could be close, and I’ll definitely give it a try. If I could decouple myself a bit more from Sublime that would be great. The plugin community just isn’t the same as VS Code.


I switched to gitsavvy a few weeks back because it is more complete than sublimegit. I paid for sublimegit years ago and really love it.

But I wanted single line commits so gave gitsavvy a go. I had to redefine a couple of shortcuts (Ctrl-D from Discard to diff) but it’s been excellent. The only thing I can’t get working is gitlab integration.

It’s a worth a shot.


Oh nice, thanks! Sublime Git has everything I need for my git workflow so I'm not feeling like I need anything else, but I will give this a shot to see if it's faster for the bits I do use.


One Git UI that I absolutely love but I rarely see mentioned is GitKraken. It's so nice having a fully cross-platform Git GUI, that's attractive and intuitive.


To be honest, they try to compete with souretree and git tower but they are there is a huge difference in the performance since GitKraken is made on electron and really slow when looking at large diffs.

I am a long time git tower user, and i have given GitKraken more than a few shots. I always go back to a hybrid command line and git tower workflow


'Go' question that came up when I tried to build this: How do you build a Go .EXE on Windows that doesn't have any file paths embedded in it?


    go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH
https://stackoverflow.com/a/45302415


Did you try this yourself? Because I already tried it and it didn't work. Remember I said I'm on Windows.


Yes, we do this for our release builds, including Windows. It does only remove the leading prefix (GOPATH) from panics, not the full file path.

I don't think there's a way to remove the whole file paths other than replacing strings in the compiled binary. In our case GOPATH was the only sensitive part (since function names can't be removed either, for reflection to work).

We also couple it with a defer handler to obfuscate panic traces.


It didn't even remove the leading prefix for me. I tried both forward and backward slashes. (The version in the binary is with forward slashes.) Note that I'm using go1.10.3.windows-amd64.zip.

EDIT: Looking more carefully, it seems like it actually removes the prefix for files in the current module, but nothing from files in its dependencies. This is despite the fact that both of them share a prefix for me, and that's what I'm trying to remove. Any idea why?


This changed from 1.9 -> 1.10, now the asm/gc/ldflags only apply to the module being compiled directly, not other modules.

https://golang.org/doc/go1.10#build

You can resolve this by using "all" as the pattern (-gcflags=all=-trimpath=$GOPATH)


Ahh!! Okay thanks, that works... almost. Now there's still one spot left where the path of the Go installation is embedded... :\


How much time do people spend messing with their source control that extreme tools like this become necessary?

I commit like, once a day. What am I doing wrong?


I commit dozens of times a day, make half a dozen branches, pick commits between them, and generally (ab)use git as a normal part of my workflow. I will generally push one or two of those commits in the end, typically a Frankenstein creation comprised of all that has come before.

There are so many ways to approach a problem in any given codebase, and I rarely know which will be the best without experimenting. Having tools that reduce the burden of experimentation and branching is incredibly powerful.


You should commit waaaay, waaaay more often than once a day. Every small piece of logically fitting together change should go into one commit, so the git history tells a story, it's easy to revert and easy to understand how the code get to the current state and why. you also should write elaborate commit messages to all commit.


I commit dozens of times a day with zero aliases, and it never really gets in my way. If you’re comfortable with git, leveraging it can almost certainly improve your productivity—if you can rebase, splitting a branch into two branches is a fairly trivial task. Even if all you do is commit often, you can do things like aggressively refactor without worrying that merging will be a costly endeavor—just rewind to the last manageable commit if you stick your neck out too far.

On the day to day work, git use is simple; it’s with large major version upgrades, refactors, merging many branches together, and spiking/research where the more advanced features really shine.


To each his own, but I'd say committing once a day. That's unless I'm wrong in thinking that doing so means your commits are quite big and could be broken up into smaller, more manageable changes.

Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.


Maybe I'm one of those low productivity types that interview processes are trying to permanently weed out, but I rarely write more than 40-50 good lines of code per day. Commits any smaller than that would just look like code Hemingway.


Not fixing several tickets a day.


IntelliJ now and forever. We still have some crap on SVN and the version control menus are nearly identical switching between that and git.


This looks super neat. Will try it out. Although I’m a sourcetree user... lately `git add -i` has changed how I use got massively.


got add -p is pretty nice too

then got commit -v to verify the hunks


Dang. So git add -p basically just skips straight to the patch portion and then -v adds a diff to the bottom of the commit message file so you can review it. Nice!


It doesn't seem to pick up new files.


It can, if you first do: git add --intent-to-add <filename>


Try git-crecord, you won't miss git add -p.


it should be clear i was too out of it to not notice s/got/git


Nice idea - I don't like going too far above the git cli, but I usually find myself building a set of terminals watching different git commands such as status, log, diff etc for a more parallel overview...

This tool looks like it does that a bit better with interactivity maintained, and for some reason i'm more comfortable accepting a CLI git UI into my workflow than a GUI.


I don't touch aliases. History search with fzf is much better. Same number of keystrokes, but your actions remain clear and explicit.


Do you type Ctrl-r every time issuing git command?


Normally I'm using vim-fugitive, actually.


raw console magit I see


ps: the https://github.com/jroimartin/gocui ui toolkit used here seems very very nice

if people know an equivalent outside go, please comment


I had the same thought. I'm amazed not to have seen any commentary here on it yet. Looks really, really nice. I looked for something comparable for Elixir but haven't found anything comparable yet.


I use GitHub desktop, it’s pretty solid.


I've always been a fan of Git Town: https://github.com/Originate/git-town

Not a UI but helps with some commands you run in a row quite often


Might be a good opportunity to advertise my git-send bash function / zsh plug-in:

http://github.com/robertzk/send.zsh


While we're at it:

   git_show_blame () {
   	if [ -z "$3" ]
   	then
   		printf "USAGE: git_show_blame filepath start_line_num end_line_num" && return 1
   	else
   		[ ! -z "$4" ] && printf "\\n${LPURP}[git_show_blame]${NC} Warning: extra arguments provided. Ignoring everything after the first 3\\n\\n"
   		git show $(git blame "$1" -L "$2","$3" | awk '{print $1}')
   		return $?
   	fi
   }
Use with recursive search `grep -Rn your_regex .` to track down the original commit that your pesky coworker added two years ago without any corresponding documentation for an alert that's going critical at 2am...(only slightly exaggerating there :P)


Whether or not anyone is tired of typing git commands this is a cool project. I intend to try it out. Great work jesseduffield!


I used to race and coach skiing for many years. Intermediate skiers always used to ask me what skis to buy to make them better at [ice|powder|moguls|steeps|etc] while I and most proficient skiers used the same boards every day in all conditions. This tool reminds me of that.

* I acknowledge that some really great skiers are geeked on their equipment and use a variety of skis. Point still stands.


What exactly is the point, other than you just calling the author insufficiently advanced by way of some creaky analogy? One of the many things that distinguishes programming from skiing is that it's fairly easy for people at all levels of expertise to make their own tools. And that's what this person did.


You are right. Sorry everyone!


Looks nice but I think you need some better documentation before anyone can use it.


I'm a Windows user, and I love Tortoise Git for this kind of stuff.


Nice first project with go. the project made wanna learn go :).


This utility is nice. Let me try out and save some time.


Damn, that's a really nice UI!


[flagged]


> Why do people make a huge fuss over git? Why?

It's unclear to me what you're referring to, but the part I can answer is this:

> How is git hard?

IMHO because it is not intuitively obvious what it means for your "HEAD" to be "detached", or for you to "rebase" onto a "remote branch", or why "checking out" a file reverts your changes, or why "checking out" a branch suddenly clones its files, or why you'd "add" a missing file to remove it, or why you "committing" doesn't actually commit your changes to the central repo, etc.


I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?

Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?

Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it?

With a decent interface, these actions are basically trivial. I've been using git for several years and I have to think way too hard to figure out what to type just to get what I want to happen. All too frequently I just say 'screw it' and make a sad commit because my job is writing software, not wrestling with git commands.


> I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?

Probably something like:

    git --rebase -i --force HEAD~6
...followed by setting the commit in question to "edit"; then once the rebase pauses on that commit, using `commit --amend` to edit the message; and finally `rebase --continue`.

> Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?

Same as above, except you'd make the necessary change before `commit --amend`.

> Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it? With a decent interface, these actions are basically trivial.

You might be able to do this with one of the filter commands, but I haven't used them enough to know. I'd probably just write a shell one-liner for this instead.

> I've been using git for several years and I have to think way too hard to figure out what to type just to get what I want to happen. All too frequently I just say 'screw it' and make a sad commit because my job is writing software, not wrestling with git commands.

Yeah, it's totally understandable. Between myself and the other dev on my team, I am the de facto git fixer. My coworker occasionally digs himself into a hole and becomes frustrated. Then the next day I do that with CSS, and he has to bail me out. I guess the point is most people have things they are motivated to specialize in.


Do you view that as in any way acceptable for a UI? All of these things are ultra-common operations. If Outlook were written this way, you'd have to type

    git inbox --full-conversation -next 
to read an email, and read it in less.


> Do you view that as in any way acceptable for a UI?

The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems.

I think most people would like a simple graphical UI, but no one has been able to create one that has the same power as the textual one.

This is akin to the reason people don't use visual programming languages.


> The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems.

Is this meant to be ironic? Everything is literally the opposite of what you said. The entire reason why people make programs like the one you see here is literally that git sucks as a console program, making tasks that are inherently simple (and demonstrably so with a GUI like TortoiseGit) much harder on the command line.


How do your your intervening submodules additions/removals turn out when you rebase?


> I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?

> Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?

It seems pretty easy to do an interactive rebase for both these.

> Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it?

This would be pretty simple if you know the hashs of the commits you want to bring over, but more troublesome if you don't. But I can't think of a good interface that makes this trivial without having a specific command for just this action. If this is a common action you do it would be pretty simple make a script which would make that specific command.

Additionally, an interactive rebase can hammer this screw too. With an editor that can delete lines that don't match a regex you can simply rebase your bugfix branch on top of master and get rid of all commits that aren't bugfixes.

I would say that git's existing interface solves this as well as you could expect a GUI or CLI frontend like the post to do.


Which interface can do the above trivially with git?


SourceTree's interactive rebase feature is amazing at the first one. You can also just change a dropdown to "Amend" and start changing your most recent commit.

TortoiseHg's search bar was amazing at deciding whether you were searching for commit message, author, or what. You'd just type "bugfix pickme" and you'd get back only the commits you needed. Check out master, right-click the batch, graft. I have five different ways to search my Git repo and all of them combined aren't as good as TortoiseHg's search bar with revsets.


TortoiseHg has the dropdown > Amend feature too.

Guitar ( https://soramimi.github.io/Guitar/ ) is the closest thing i've found to TortoiseHg for git, really promising but not yet fully baked - with a little help that could be a real TortoiseHg successor.

Everything other git GUI i've tried has some problems (git gui + gitk is reliable and featureful, but no grafting & has that Tk UI; git-cola is crashy and the DAG view isn't properly integrated; qgit and gitg can't push to remotes; sourcetree and gitkraken are nonfree; gitextensions and tortoisegit don't run on Linux).

One feature of git gui & gitk that TortoiseHg badly misses, though, is the option to stage lines for commit instead of just hunks.


I think the point was that git is missing an interface that makes these easy, and it badly needs one.


Once you learn how to use `git rebase -i` it makes the above things trivial to do! I didn't know about it for a while, but that's my most often used command to fix up my commits.


I'll agree about the non-intuitiveness.

I like git, I love the idea behind it, I appreciate the benefits it provides me, and I want to get better at it and I strive to adopt all the commonly-endorsed best practices.

However, with all the slightly different means to ultimately the same ends – merges, rebases, patches, fast-forwards, squashes, fixups, messages, descriptions, notes – it makes me wonder if git is not a Frankenstein's monster by now with too much bolted on to it, that needs to revised from the bottom up and consolidated into a more streamlined interface.

It's kinda telling when all the GUI tools for git do each task slightly differently, and none of the GUIs (that I've tried so far) let you do everything from one app, so I prefer to keep a couple different ones open at all times: https://i.imgur.com/itWE4Gs.png


I'm a pro with TortoiseHg so have all the concepts perfectly clear. Git is still hard with tons of command line syntax to look up and alias, no good GUIs, and poor error messages when things go wrong like Excel locking a file or not being able to pull. TortoiseHg lets me treat my commits like little bubbles on a graph and rearrange them at will. Git isn't trying not to be hard.


Yeah, Tortoise makes life so much easier. :-) I just wrote about TortoiseGit here: https://news.ycombinator.com/item?id=17689294


TortoiseGit has a GUI? StackOverflow convinced my coworkers that it was just a Windows Explorer extension for people who were used to SVN.


TortoiseGit is a GUI for Git that integrates with Explorer. You could indeed say it's geared toward people familiar with TortoiseSVN, though I'm not sure that paints an accurate picture of it. Unlike with SVN, I would argue you really do need to know Git on the command-line before you use TortoiseGit, but once you do, it makes life a hell of a lot easier than using Git on the command-line.


congrats, you have discovered darcs.


Why not just use an actual GUI then rather than a shitty TUI?

GitX (Mac only sadly) is the best of the free ones, and Tower is then best of the commercial ones. Try those.


>>but you're too stubborn to use Sourcetree because you'll never forgive Atlassian for making Jira? This is the app for you!

This is the most ridiculous ad ever.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: