Oh shit, git: Getting myself out of bad situations(ohshitgit.com)

1,209 pointsby adishaporwal9 tahun yang lalu508 comments

Oh shit, git: Getting myself out of bad situations

http://ohshitgit.com/

519 comments

lwansbrough9 tahun yang lalu

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second.

I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Takeaways:

- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)

- I don't remember the last time I made an irreversible change to the repo, or had an "oh shit" moment. And that's despite using some interesting git features.

- Staging individual files, folders, lines of code, or hunks is easy. Makes maintaining multiple trains of though / addressing bugs while working on other code a non-issue.

- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow.

- It's much easier to get an overview of the changes I'm making.

swalsh9 tahun yang lalu

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz.

When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do it. The GUI get's in my way.

dilap9 tahun yang lalu

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model.

The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

dasil0039 tahun yang lalu

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations and occasionally look something up, but I don't consider that a big deal for a core tool I use every day.

euske9 tahun yang lalu

"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully."

Pick the right tool for the right job, man.

Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I think GUI could have a net gain in total. Although I'm not a GUI user in this particular case, I'd advocate to use whatever most intuitive to you when possible.

Disclaimer: I don't think C syntax is that bad.

earenndil9 tahun yang lalu

It seems like the other way around to me. For 99% of simple tasks, the cli is quick and easy. There are a couple of simple commands, I know and remember them. For the once-a-year complex tasks, maybe I need the gui to be able to more easily and quickly accomplish them.

chiefalchemist9 tahun yang lalu

It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.

dasil0039 tahun yang lalu

You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.

chiefalchemist9 tahun yang lalu

Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

geezerjay9 tahun yang lalu

> Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.

chiefalchemist9 tahun yang lalu

Not really. I associate a picture with 1000 words. So if the detailed example/ explanation is an image why isn't the actual process(es) a reflection of that?

Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction.

Pardon me for stating the obvious :)

chris_wot9 tahun yang lalu

The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian:

https://www.atlassian.com/git/tutorials/resetting-checking-o...

Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very useful. And knowing that reset --hard updates both staging and the working directory to the commit was where I suddenly "got it".

chiefalchemist9 tahun yang lalu

Right. And notice all the diagrams. So why use words when pictures better reflect reality?

nothrabannosir9 tahun yang lalu

> Git is fundamentally better than most of the alternatives

No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously.

I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, last I heard), Facebook doesn’t (custom Mercurial, some tasty quotes at [0]). Not a glowing “fundamentally better”, exactly.

[0] https://code.facebook.com/posts/218678814984400/scaling-merc...

dasil0039 tahun yang lalu

That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.

jbergens9 tahun yang lalu

And you can go a whole career without needing the extra staging features that git has and some other systems like mercurial don't. The ui gets a lot easier without that and for many developers that is probably the best trade off.

rhencke9 tahun yang lalu

1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad.

2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB:

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...

piyush_soni9 tahun yang lalu

Microsoft uses Git in single large-scale mono repo form

They had to change git itself to be able to do that. So no, the article itself shows it was not ready for that big a repository.

nothrabannosir9 tahun yang lalu

Git LFS is not part of Git.

That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.

dilap9 tahun yang lalu

I believe MS has most of windows in a git mono-repo now, enabled by a custom git-supporting filesystem they've developed:

https://github.com/Microsoft/GVFS

Pretty cool stuff. Doesn't seem to address the large-files case so much as the many-files case, though. I would love better git support for large files.

u801e9 tahun yang lalu

> The built-in porcelain is stupidly inconsistent and confusing.

That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.

mikedelfino9 tahun yang lalu

One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.

donarb9 tahun yang lalu

I use aliases for the most common commands, gs, gd, gb, gco, ga, gc. You can guess what those do.

geezerjay9 tahun yang lalu

The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.

dasil0039 tahun yang lalu

One way to make yourself feel superior to others is to adopt a level of pedantry that only you yourself can meet your own standard. If you then assume everyone around you is ignorant you are not as smart as you think.

git porcelain is a CLI. I am well aware that it is only a subset of git's CLI.

giancarlostoro9 tahun yang lalu

SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...

murukesh_s9 tahun yang lalu

This is one time when we wish source tree was written in electron!

ythn9 tahun yang lalu

VSCode is the only Git GUI that you need and it's available on Linux

Drdrdrq9 tahun yang lalu

Do you use it? I have it enabled, but when I tried to revert a few lines (which should be the simplest operation ever - NetBeans did it perfectly; may it rest in peace...) I got some horrific message that made me doubt what the operation will do. So I haven't gathered enough courage to try committing anything... With CLI at least I know what I did wrong.

giancarlostoro9 tahun yang lalu

VSCode doesn't consistently use git's language afaik, I could be wrong though.

Groxx9 tahun yang lalu

http://gitup.co/

This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.

benliong789 tahun yang lalu

Thanks for the recommendation. Fantastic looking software that provides a far better visualization of the repo than anything else I have used. Bravo.

I use CLI for almost everything but sometimes it helps to have a visual representation of the repo.

dilap9 tahun yang lalu

It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.

Groxx9 tahun yang lalu

So far I've found:

    it's reasonably fast until I throw it at a huge monorepo :)  but it still works (~2fps)!  even `gitk` errors on this one.
    missing some hotkeys (like prev/next commit buttons in preview)
    freezes on remote-repo actions like fetch/pull/etc.  likely due to our enterprisey ssh setup.
    generally missing a bit of polish.  click targets are small, could use some more config (and only in one location, "search commits" is in its own thing), etc

Aside from the remote repo freeze-up, I'm liking it a lot. Way better control than others I've tried (i.e. it has nearly all the features), undo support, and a much better mental-model for Git in general.

If I can figure out how to fix the remote freeze-up, it might become my daily driver, which would be a first for a Git GUI.

dilap9 tahun yang lalu

Yep, doesn't scale great to huge repos, sadly.

I hadn't thought about the prev/next preview missing hotkeys, but you're right. I realized what I do is go into preview with space, leave preview with space, and then use the arrow keys to select the next commit I'm interested in. So in effect, "space, down, space" is hotkey for next commit.

Bummer about the remote freeze thing. I think the dev is reasonably responsive to bug reports.

I've got a list of things myself I think could be better, but I've been too lazy to attempt any of them. But I do try to proselytize in the hopes it'll pick up a bigger community. :-)

piyush_soni9 tahun yang lalu

I thought it's nice too, and just downloaded it to find out it's Mac only.

dilap9 tahun yang lalu

Yep :(

hyperpallium9 tahun yang lalu

I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple.

A gui with drag-and-drop to rebase a graph also seems like it would work well...

thomasahle9 tahun yang lalu

I was in the cli only camp, but I just looked at GitUp and that actually looks really useful!

aldanor9 tahun yang lalu

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does.

The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal).

If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets VERY tedious very fast; I'd rather do it in several keypresses because why not.

jdc05899 tahun yang lalu

GitExtensions was/is solid too; very little abstraction, it was just built for speed/efficiency. Someone recently told me it runs on Mono too now, but I haven't used it in years and never outside of Windows.

dilap9 tahun yang lalu

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

thomastjeffery9 tahun yang lalu

It's a Graphical User Interface.

I think that the distinction that makes a Commnad Line Interface is the REPL.

I consider anything with a non-linear UI that you can see a GUI.

aldanor9 tahun yang lalu

Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway.

> It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though)

dilap9 tahun yang lalu

interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)

tarsius9 tahun yang lalu

On macOS it helps to use Emacs 26.1 (unreleased but very solid) or to use a build with a backport of the vfork patch. For more information see https://magit.vc/manual/magit/MacOS-Performance.html.

I also plan to make Magit faster across all platforms.

dilap9 tahun yang lalu

very cool to hear that performance is a focus area!

JetSetWilly9 tahun yang lalu

It seems to be incredibly slow on windows, but fine on linux.

It seems like the sort of ui that needs to be near-instant in order to be usable, the premise being you can tap the various shortcuts to assemble a command very rapidly. But on windows this is an exercise in frustration because each command takes at least a second or two at best to execute and often much longer.

tarsius9 tahun yang lalu

I think Magit could be classified as a TUI [1].

But that still doesn't help explain its benefits to someone who hasn't tried it. For the crowdfunding campaign that I ran earlier this year I wrote a few articles. For those unfamiliar with Magit I would recommend [2] and the more visual [3].

[1] https://en.wikipedia.org/wiki/Text-based_user_interface [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://emacsair.me/2017/09/01/magit-walk-through/#start

MonkeyIsNull9 tahun yang lalu

> I'm not 100% sure what's going on under the covers.

This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.

giancarlostoro9 tahun yang lalu

Even GUI based SQL tools show you a log of commands used... Git GUI clients don't even show you beforehand or after what the heck just happened... Sad.

tigershark9 tahun yang lalu

It's definitely not true. I'm not sure what kind of gui did you use but both sourcetree and gitextensions show you the command log.

giancarlostoro9 tahun yang lalu

Guess I was wrong, but I never noticed said log. I use SourceTree.

ninkendo9 tahun yang lalu

GitHub's GUI is the worst. It has a "sync" button.

As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.

mchahn9 tahun yang lalu

GitHub's Atom editor recently added git operations. I use Atom but haven't had the time to try the git wrapping. Has anyone else used it?

emodendroket9 tahun yang lalu

It just pushes the current branch afaik.

dotancohen9 tahun yang lalu

So they should just call it 'push'. The word 'sync' is not in the Git terminology.

aalleavitch9 tahun yang lalu

In its defense, git terminology is stupid. It took me way too long to reason out what the fuck a pull request meant. To your starting developer it seems to indicate the opposite of what it does.

emodendroket9 tahun yang lalu

The GitHub desktop client is very limited and seems mostly geared toward a lone developer or small team who has never used git before. In this context I think it's a reasonable decision to use a more common verb.

craftyguy9 tahun yang lalu

Nope. That does no one any good. Using git verbage would, at the very least, acclimate them to very common terminology used by the rest of the folks they will eventually encounter.

emodendroket9 tahun yang lalu

Well, I disagree, because the alternative for many is probably no source control.

craftyguy9 tahun yang lalu

Folks writing production crap would opt for no source control? Well, fair enough I guess. But I (and probably most competent sw engineering folks) would never hire someone who was completely oblivious to using source control. So hopefully that 'practice' would die through attrition.

emodendroket9 tahun yang lalu

You've got to meet people where they are. Someone who is familiar with how git works is going to find the git GUI client way too limiting to seriously consider using it, whatever verb they use for the push function.

michaelmior9 tahun yang lalu

So it never pulls updates on the remote? That seems like pretty unexpected behaviour.

emodendroket9 tahun yang lalu

It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.

pacoverdi9 tahun yang lalu

CLI and GUI are both user interfaces and magic is in the eye of the beholder: if you know your tools, you can predict what will happen under the hood when you click on a button as much as when you submit a command (it's not magic anymore).

Personally, I use the CLI and often have no idea what I'm doing ;)

WhyNotHugo9 tahun yang lalu

Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either.

A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.

admax88q9 tahun yang lalu

The git CLI is horribly inconsistent.

http://stevelosh.com/blog/2013/04/git-koans/

electricEmu9 tahun yang lalu

I understand git quite well and use a GUI. I was interested in understanding it while using the git.

It's pretty sweet that GitExtensions displays the exact command executed. Actually, it made learning vastly easier for the people I taught after myself.

Some people do better with GUIs; others the CLI.

bseow9 tahun yang lalu

I feel this has become a bit of a standard excuse for git. The reason I use a gui isn't because I don't know how git works (while I do forget that too from time to time), but because I can't remember the default behavior and notation of the git cli. I'd be perfectly happy if the cli was actually made to be "low level", but it to a large degree isn't. So if I'm going to have to remember what some abstraction does, it might as well be on a higher level.

One example of this is the table at the bottom of this page: https://git-scm.com/blog/2011/07/11/reset.html

nerdponx9 tahun yang lalu

You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.

rsp19849 tahun yang lalu

Actually I find Sourcetree one of the worst git GUIs out there. There are just so many bugs and kinks and glitches in it that I avoid it if possible.

I do like the Gitx-dev fork by Rowanj [1]. Clean and simple. Unfortunately just for Mac OS though.

[1] https://rowanj.github.io/gitx/

nerdponx9 tahun yang lalu

I haven't encountered any of these bugs. But I do use it only rarely, the CLI is where I live most of the time. Good to know about alternatives.

sirmarksalot9 tahun yang lalu

I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users are nearing a point of mutiny.

tigershark9 tahun yang lalu

Source tree is the slowest software that I ever used. Git extensions is much much faster and I never had any performance problem with it.

andrepd9 tahun yang lalu

Not available for Linux, which is a damn shame.

Someone9 tahun yang lalu

I dislike SourceTree precisely because it uses git terminology. Git’s terminology is bad enough, but it completely breaks down for me in a GUI, because I expect that GUI’s conventions there. For example, on the Mac (as in English, I think), a command named “Remove” removes an item from a containing item. “Delete” also destroys the item. SourceTree, however, uses “Remove” for “git rm” because Unix thinks “remove” destroys items.

To make matters worse, what in a Mac GUI would be called “Revert” or “Discard Changes” is called “Discard”, something that, to me, feels more destructive than it is.

End effect? We have “Discard” being less destructive than “Remove”, while, to me, it feels the other way around.

(I may remember this wrong, but if I do, I think that’s a sign of the problem of not following platform conventions in your software)

Tarean9 tahun yang lalu

I like fugitive - it feels like cli git without having to leave the editor. GAdd adds the currently file/selected lines, GBlame pulls up git blame information the ability to reblame, GStatus show the status with the ability to jump to/stage/unstage files and so on. Tried Magit for a while but it didn't play nice with evil.

Still hoping for a git repl that just does graph queries/transformations though.

nullterminator9 tahun yang lalu

I use both.

Staging, especially partially staging hunks and lines when doing multiple things at once, is way easier in a GUI when you can scroll around for context and easily undo.

For everything else I prefer the command line, because it's faster and I know exactly what is going to happen. I can do what I need to do, no fighting. If I'm just committing everything, I use the CLI. If it's more complicated I use the GUI to stage and commit, and a CLI to rebase/merge/push.

STRiDEX9 tahun yang lalu

I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.

ccarse9 tahun yang lalu

There's an option in sourcetree, "always show output". This will keep the window that runs the commands open so you can always see what it did and git's output. I always keep this enabled.

dilap9 tahun yang lalu

the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)

Drdrdrq9 tahun yang lalu

True. Inconsistent and unintuitive options, oddly named commands (and this is coming from someone who enjoys using Unix clones).

thelittleone9 tahun yang lalu

How about if someone made a GUI with a console at the bottom that showed the commands being executed along with results?

mikedelfino9 tahun yang lalu

I like typing and I don't think it slows me down too much, so I pass. But it's a good idea.

antoaravinth9 tahun yang lalu

This is exactly the same reason I too use CLI. But a word of caution Git Bash on windows has some serious problem(s). I remember, I lost my commit and in reflog it doesn't show up on CLI, however GIT UI showed the same! Not sure what's the issue, but it occurred for me twice.

donarb9 tahun yang lalu

XCode rolled out a feature that allowed you to do an interactive commit just by click on/off switches. My first use of that feature screwed up the repo by committing the wrong pieces.

No thanks, it’s CLI for me, regardless if the IDE promises git support.

CodeMage9 tahun yang lalu

The problem, as I see it, is not with the GUIs, it's with the CLI. Just look at the `reset` command: it does several different things, depending on what switches you give it. How would you represent that in a GUI?

danmaz749 tahun yang lalu

Some git guis log the git commands they execute. Just look at those.

krapp9 tahun yang lalu

I use either the GUI on Windows or a set of batch files I wrote to automate basic things.

As long as all you're doing is pull, branch, merge and commit, I don't think it matters.

dasil0039 tahun yang lalu

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks.

I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split.

However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don't want to use whatever shitty editor your tool has in it, I want to use vim with syntax highlighting so I can properly format my commit messages. Even something as simple as viewing a full commit is faster in the CLI because you can just pipe it to less or send it to an editor versus whatever tradeoffs a GUI has to make to stay performant, make use of screen space, etc.

One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

reificator9 tahun yang lalu

> committing single lines from hunks that can't be split.

Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before.

Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

theptip9 tahun yang lalu

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line.

E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk".

(Waiting for someone to chime in with how to split a hunk and change my life).

YoyoyoPCP9 tahun yang lalu

You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'

[deleted]9 tahun yang lalu

lfrb9 tahun yang lalu

You can use 's' to split a hunk but it would indeed not work if you want to split two consecutive lines.

You can also use 'e' option to edit the hunk to e.g. remove one of the added line.

Nothing as easy as clicking a line in a GUI though.

deragent9 tahun yang lalu

Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually.

In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.

tigershark9 tahun yang lalu

And how is this faster/better than selecting a line with the mouse and pressing s without opening any other editor?

RandomException9 tahun yang lalu

Do it in Vim (or emacs for those weirdos out there) and you're done before you would've even reached the mouse :)

gknoy9 tahun yang lalu

Sometimes your changes are across multiple files, and it's easier to say, "yes, yes, yes, yes, split, no, no, yes, ..."

dasil0039 tahun yang lalu

Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.

jgtrosh9 tahun yang lalu

As mentioned before, manual edits can be made at that point. However I'll add that for this use case, a tool integrated in your editor will often be more adapted to manual staging. I have Tim Pope's vim-fugitive plugin in mind which is a quite wonderful way of using Git.

u801e9 tahun yang lalu

You can also manually edit the hunk to remove the 2 lines you don't want to stage and use the recountdiff utility to update the hunk header.

klmr9 tahun yang lalu

You can split hunks manually by editing (hit “e” instead of “s” during staging). I end up doing this fairly regularly.

rickycook9 tahun yang lalu

i think that’s his point? there’s a huge amount of useful, but advanced functionality in the git CLI

DigitalJack9 tahun yang lalu

  > Fugitive

That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something.

So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes).

I have desired something as useful in vim, but I didn't think there was anything. I'll take another look at fugitive.

jreybert9 tahun yang lalu

You may want to give a try to vimagit so. https://github.com/jreybert/vimagit/

As soon I started to work with git, I installed fugitive. My learning curve of fugitive has been slow, and I have never be able to stage efficiently with it.

And then, a colleague showed me magit: I waited for a year that something similar comes to vim, trying to push this idea to fugitive https://github.com/tpope/vim-fugitive/issues/569 , without success.

Finally, some first experiments showed that partial hunk stage was feasible, and I created vimagit.

As you will see, it is far from whole magit features. For the moment, it "only" focuses on stage/unstage and commit feature (which is the main use case to me). The current workflow is quite robust: you can easily navigate through all the diffs to review them, stage by file/hunk/line/part of line, write the commit message (or amend the last commit), jump to the diff locations in their files... I continue to use fugitive for Gblame and Gdiff.

Next major features should be git stash (be able to prepare a stash like a commit, by file/hunk/line) and some git log related feature (to easily git commit --fixup a chosen commit in a log for example).

DigitalJack9 tahun yang lalu

Yeah, fugitive seems pointless to me. Might as well just use the git cli...which I do, but when I want something quicker to navigate/visualize, magit is my go to.

dasil0039 tahun yang lalu

See my comment in sibling thread. I am not familiar with Magit, but there's no equivalent on the CLI to Fugitive's flow for rapidly traversing history, it's really really useful, and lets me answer questions that other devs on the team just throw up their hands because a line may have traversed several different files over dozens of commits throughout its history. The reason it can't be done on the CLI is because you need multiple buffers and window management to make it viable.

All that said, I don't really use it for committing, mostly because I have a shell open right next to the editor anyway.

PuffinBlue9 tahun yang lalu

> One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

Sorry if I'm being think, but how do you do that? Are you talking about Gblame?

dasil0039 tahun yang lalu

Yes, Gblame then in the blame pane ‘o’ to open the commit, then in the commit pane navigate to a file name and ‘o’ to open the old file, then rinse and repeat. You can trace line history across files this way.

nlawalker9 tahun yang lalu

I've become a big fan of Git Extensions. I like that it doesn't try to layer its own agenda over the Git workflow, shows all the console input/output it uses, and warns me when I'm about to do something stupid, but overall I like it for the same 3 reasons that I like most GUIs:

- It's a live dashboard. A GUI gives me live, persistent information organized well on the screen. I appreciate the power of the CLI for accomplishing tasks, but I've never understood how people prefer it when it comes to simply viewing and understanding the state of something. I don't see why I'd want to run a bunch of commands to see stuff scroll by in my format-constrained terminal when I can have a live, all-up view of multiple aspects of a repo all at once, with relevant, context-sensitive commands on whatever I click on.

- It's discoverable. Most of what I've learned about git has been through clicking around in Git Extensions.

- The structure and organization of the UI helps me to understand how git operates. When I open the "Pull" dialog, for example, the way the controls in the UI are grouped and the kinds of controls that are used help me logically understand what "Pull" can do.

emeraldd9 tahun yang lalu

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

filereaper9 tahun yang lalu

I'd like to also point out tig. "Tig is an ncurses-based text-mode interface for git"

It doesn't have all the bells and whistles of a GUI, but if you need to look at all the branches, and commits to a repository. tig is an excellent tool. tig doesn't issue any commands though, its only a browser, you'll still need to know the CLI. (essentially a ncurses version of gitk)

I'm normally in a ssh session on a remote box where my compile & run cycles happen. tig is curses based, so no X11 needed, filled in a really nice itch of mine.

[1] https://github.com/jonas/tig

archon8109 tahun yang lalu

+1 for tig. I'm also a big fan.

welly9 tahun yang lalu

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

Ajedi329 tahun yang lalu

Git Kraken isn't FOSS. The site says "Free for non-commercial use", and AFAIK the source isn't available anywhere.

I think maybe the term you're looking for is "freeware"?

welly9 tahun yang lalu

Ah, you're quite right. I was under the impression it was FOSS - I used it a while ago, preferred Tower and so went back to that.

mistersquid9 tahun yang lalu

I second your recommendation of Tower. About a year ago, I made a comment right here on HN singing Tower's praise names. [0]

It's impossible to sing those names loudly enough.

  [0] https://news.ycombinator.com/item?id=12677542

shagie9 tahun yang lalu

Apparently, there is now also a windows version. https://www.git-tower.com/windows

GFischer9 tahun yang lalu

Thanks, I had disregarded Tower until I saw your comment :)

dewey9 tahun yang lalu

I want to second that. Also the integration with diff tools like Kaleidoscope is a nice touch. (Even though Kaleidoscope feels like abandonware at this point)

machiaweliczny9 tahun yang lalu

Gitup is free and probably better.

welly9 tahun yang lalu

Thanks for the tip, I'll have to check it out.

Froyoh9 tahun yang lalu

How is atlassian's Sourcetree?

welly9 tahun yang lalu

We have a bunch of projects that are stored in a mercurial repo so I've been using Sourcetree for that as I've found MacHG pretty unusable. I think it's pretty good, not as good in my opinion (the UI, mainly) as Tower for Mac which I use for Git, but makes Mercurial easy to use for this (somewhat) hardened Git user.

prewett9 tahun yang lalu

I like it a lot, it make git as simple as mercurial. I don't think it is hiding complexity, but the visual arrangement makes sense. The staging area becomes actually useful, and I love that you can stage (or revert) pieces of a file, which is handy when you forgot to commit one thing before moving on to the next.

I've only had to merge a branch once, and here I was completely confused on what was going end. This may be SourceTree's fault or git's fault. Maybe my lack of understanding.

I hate git, I don't understand git, I don't want to have to understand git, and I think the command line interface makes every UI error in the book. But SourceTree has made me like git.

tigershark9 tahun yang lalu

Incredibly slow. I was never annoyed so much when using a software...

Vel0cityX9 tahun yang lalu

I use SmartGit. Way faster and more stable than SourceTree and GitKraken, in my experience.

archon8109 tahun yang lalu

+1 for SmartGit, and SmartSVN if you ever use SVN.

aoeuhtns9 tahun yang lalu

Magit in emacs. Probably one of the killer applications for emacs.

karmajunkie9 tahun yang lalu

+1, along with Tig (console gui).

menacingly9 tahun yang lalu

Thanks for telling me about tig, now I'm justified for having browsed HN today.

It treats my "assume everything works like vim" habit well

alunaryak9 tahun yang lalu

tig is great -- it makes it very easy to stage individual lines of code (using 1) or to reset unstaged changes on a file (using ! in the status view).

karmajunkie9 tahun yang lalu

it covers like 80% of my use-cases (which I use 99% of the time), and weirdly magit gets me the other 20% if I can remember which trail of breadcrumbs I follow through helm to make it happen. For the easier stuff I just drop down into the cli though.

bradyholt9 tahun yang lalu

I love tig!

celeritascelery9 tahun yang lalu

Agreed. Best git interface I have ever used.

monsieurbanana9 tahun yang lalu

I'd hesitate to call Magit a git GUI though.

If we take Ranger for example, who calls itself the "CLI file manager", then Magit is rather a "git CLI".

gumby9 tahun yang lalu

>I'd hesitate to call Magit a git GUI though.

Why? It is designed for git and graphically displays revisions allowing you to pick and chose chunks of file and to revert individual changes.

LiquidFlux9 tahun yang lalu

Not the OP, but I had come from SourceTree to GitKraken and it's a joy to use.

yoodenvranx9 tahun yang lalu

Same for me! I used SourceTree in the past but at the moment I am using the free version of GitKraken for private projects and I am very happy.

nastysquar3d9 tahun yang lalu

I use TortiseGit in my personal and work dev environments. It works works well. That being said, I have had to drop to CLI to fix things that were somewhat more hairy.

Noumenon729 tahun yang lalu

My company uses Mercurial still and TortoiseHg is the best thing about it. I can sling big piles of commits around, patch, graft, and search, it's all so easy. I hope it works as well for Git or Git can catch up.

neves9 tahun yang lalu

Tortoise was great on Subversion, but I don't like it for Git. The UI in thought to work with a centralized version control is isn't well adapted to Git.

slobotron9 tahun yang lalu

Not the OP, but git cola works great for me.

https://git-cola.github.io/

_pmf_9 tahun yang lalu

I recommend SmartGit; it's not cheap, but it's really, really nice.

keithnz9 tahun yang lalu

SmartGit is really nice.

It's also free for hobby / open source

but worth buying for commerical work, but it is pricey, and I think getting the lifelong updates is the way to go.

Achshar9 tahun yang lalu

I use sourcetree and it's pretty great, especially the aforementioned block-level staging.

nwatson9 tahun yang lalu

SourceTree by Atlassian ... free.

gumby9 tahun yang lalu

> What GUI do you recommend?

I really like Magit, which is a git GUI you can use without leaving Emacs. It handles 90% of my git needs and is very tightly integrated into my IDE (Emacs). I still use some shell commands (like git mv) occasionally but those are simply m-! away.

aldanor9 tahun yang lalu

Second that; I'm using Spacemacs just for Magit and nothing else, although it's mainly vim or clion for development. Haven't seen a single git client that would be close to Magit; too sad it needs Emacs, could have potentially been an awesome standalone...

kenoyer1309 tahun yang lalu

The Git GUI that ships with git is very good. It also shows how Git thinks (workspace/staging/commit) that most other gui's struggle with (they try to make it look more like a SVN workflow). For diffs and blame I use TortioseGit. I also extensively use the CLI for most branch actions.

neves9 tahun yang lalu

I tested a bunch of Git GUIs. My requisites:

- Open source (and free) - Multiplataform

The one with the best usability was Git Extensions: https://github.com/gitextensions/gitextensions

It is somewhat old ugly, and open a little too much of dialogs, but the workflow really works. It guides you to make the right thing.

A great plus is that it already comes with Kdiff3, a great open source 3 way diff open source program.

xeromal9 tahun yang lalu

Agreed, Git Extensions taught me Git visually rather than through a tutorial.

[deleted]9 tahun yang lalu

bolololo19 tahun yang lalu

I like GitKraken

ggregoire9 tahun yang lalu

VSCode or Github Desktop (even if the project is on Gitlab).

flatline9 tahun yang lalu

I personally switch between the command line, git gui and gitk. I haven’t yet found a suitable GUI replacement for those two.

mejari9 tahun yang lalu

For any Windows users out there, I use GitExtensions, which has served me very well over the years.

aschampion9 tahun yang lalu

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

loup-vaillant9 tahun yang lalu

A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions.

(Note: I use the CLI almost exclusively.)

cookiecaper9 tahun yang lalu

Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.

The5thElephant9 tahun yang lalu

The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.

neves9 tahun yang lalu

Conflict resolution in a GUI with 3 way merge really beats out a command line.

The5thElephant9 tahun yang lalu

Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well).

Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users.

Sometimes dev obsession with tool purity does more damage than good.

forg0t_username9 tahun yang lalu

You're always one git reflog away of undoing the brainfart. Once you know the CLI well enough, you manipulate the git data model easily. When you're using a code review tool like gerrit, it's impossible to do something you can't undo.

Tobba_9 tahun yang lalu

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

pivo9 tahun yang lalu

I believe GitUp directly links to git library and doesn't use a command line shell.

macrael9 tahun yang lalu

Yes, GitUp actually ships its own git library.

minitech9 tahun yang lalu

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Nah, it’s just a lot easier than you make it out to be. GUIs are fine too, but if you read the documentation and don’t just memorize a fixed set of commands there’s nothing dangerous, slow, or inconvenient in going about a standard workflow using the CLI.

And yes, lots of people don’t have time for this. Totally okay. Don’t generalize to “anyone who uses the CLI is trying too hard”.

lillesvin9 tahun yang lalu

My biggest issue with a GUI is that most that I've seen introduce new terms for various stuff, e.g. "sync" in VS Code, or "revert commit" (in Source Tree maybe?) — there's no Git command called "sync" or "revert", so I'm not immediately sure what they do.

In a CLI I know exactly what's happening.

That's just my opinion though. If people feel comfortable working in a GUI all the more power to them.

autarch9 tahun yang lalu

Git does have a revert command.

lillesvin9 tahun yang lalu

Yeah, my bad. Must've been "reverse" then. I just remember the revert/reverse dichotomy.

lttlrck9 tahun yang lalu

Or perhaps it called revert but it wasn’t doing a git revert, it was doing a git checkout to simulate an SVN revert... I’ve seen this in at least one GUI. That kind of crap just makes it harder to unwind problems when things go wrong and to learn the tool.

bootcampjs9 tahun yang lalu

I work with a lot of people who have no idea how git actually works and it is infuriating. They all use the git desktop program, and almost every time I get called over to help, it’s because they didn’t sync or refresh or whatever the hell it does.

If you don’t have a good mental model for git, you’re gonna have a bad time.

lhabjane9 tahun yang lalu

Second this. I was one of those people that needed help when I was learning git. Went full CLI after that and never looked back.

joonoro9 tahun yang lalu

I like Magit because it doesn't try to hide git while still giving all the advantages GP mentioned https://magit.vc/

Alupis9 tahun yang lalu

> no Git command called ... "revert"

Maybe not in the way Source Tree uses it, but there certainly is[1]! I've had to use it a few times.

> git-revert - Revert some existing commits

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

lillesvin9 tahun yang lalu

My bad, then it was "reverse" in Source Tree (or whatever it was).

Cthulhu_9 tahun yang lalu

I don't trust GUI clients; it's easy to not be able to discern the current status, easy to just commit all changes, some of the clients don't respect the pre-push hook, and I've seen other colleagues who have no clue what they're actually doing end up mixing pull and pull --rebase, somehow managing to make duplicate commits with slightly different contents and not having a clue what's going on.

Don't use clients if you don't even understand the basic git workflows. And those usually don't support the advanced oh shit situations this article is about.

lwansbrough9 tahun yang lalu

> it's easy to not be able to discern the current status

Probably a failure of whatever UI you're using. I manage just fine.

The common statement from CLI types is that "it's just whatever you're better at using" which is true conceptually, but practically, again, CLI users make more mistakes either from fat fingers or lack of understanding of git.

Understanding git conceptually from a UI point of view is easy. You don't even have to have a full understanding of git to be effective at using it, if the UI is good. I'm shit with the git CLI, but I understand what git is doing.

Yes it's easy to do dumb shit in a GUI, the same is true for CLI. In fact, it's less likely that there'd be a button for doing something dumb than it is that a git novice would find some command on StackOverflow and attempt to use it without fully understanding the ramifications of it.

rcxdude9 tahun yang lalu

I've felt a good GUI would make using git far more intuitive, but I've yet to find a good one. They all seem to fail on one front or another (too hard to use, don't expose enough functionality, attempt to enforce one workflow, aren't available on platforms I want, are slow/resource hogs).

Usually I use the included gitk to view the repo, and the CLI to manipulate it.

[deleted]9 tahun yang lalu

rhodysurf9 tahun yang lalu

For the most part using git is like five commands and it is definitely fast to use them from the command line if you have some sort of git understanding

emodendroket9 tahun yang lalu

Which do you use? I'm generally pro-GUI (I love Postman, for instance, and don't use curl much) but my experience with git GUIs has been that they were kind of half-baked and will not do what I expected, leaving me with a difficult-to-understand mess to clean up.

MaulingMonkey9 tahun yang lalu

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

I've suffered a lot of git GUI bugs. The admittedly large repositories I sometimes deal with cause things to hang and stall, breaking my flow. I keep filing bug reports - truncated diffs because new files were "too large" (presumably someone trying to fix the hang and stall issue), a client that only renders the top half of the window consistently when on a portrait 4K monitor, etc.

The git CLI is simply second nature enough to me at this point that waiting for a GUI to load, refresh, etc. is rarely faster. It does happen, but it's not the common case. Getting a good summary of a set of changes is sometimes one of them. Picking individual hunks/lines is sometimes another - although I prefer to commit with such frequency when using git, that it's extremely rare I have changes that belong in different commits.

Then, looking at perforce, I'm finding more and more cases where I'm dropping out of P4V and into command line tools. Any kind of mass move/edit seems easier to do through the command line. Command line diffs were way easier to review than P4V's file based diff interface when I had changes involving 1 or 2 line tweaks spread across dozens to hundreds of files (such as verifying function rename changelists didn't accidentally pick up other changes.)

I think anyone who's swayed by the beauty of a git GUI has much more patience than me.

"Sourcetree (Not Responding)" - I typed this out while waiting for my Visual Rust tab to focus. Euhg.

I could've made a commit from the command line in that amount of time.

madeofpalk9 tahun yang lalu

I've found my sweet spot is using both a GUI (Github app, to be specific) and a CLI.

GUI for partial commits and reviewing my change, and then command line for basically everything else (merge, checkout, branch, etc).

rectangletangle9 tahun yang lalu

I've tried out a few different GIT GUIs, and never really took to any of them. Settled for using the CLI + many BASH aliases. Anything I do frequently gets a concise alias to minimize typing. I have relatively short fingers, and I'm admittedly a pretty poor typist, so I really emphasize the concise part. Pretty much all the aliases are write only code. I do this for pretty much every other complex CLI application too, e.g., Docker, Heroku, AWS. A little abstraction really speeds up using the CLI. Aliases are my favorite feature of BASH, I think they've saved me literally months of typing at this point in my life.

Here's a few handy ones:

  alias currentbranch='git rev-parse --abbrev-ref HEAD'
  alias gpush='git push origin $(currentbranch)'
  alias gsync='git pull origin $(currentbranch)'

  alias ga='git add -A'
  alias gc='git checkout'
  alias gcm='git commit -m'
  alias gca='git commit --amend'

  # and my personal favorite (list recent branches)
  alias gb='git for-each-ref --sort=-committerdate refs/heads/ --format="%(HEAD) %(color:yellow)%(refname:short)%(color:reset)" | head -n 20'

tylerhou9 tahun yang lalu

My version of gsync is `git pull --rebase origin ${currentbranch}`, since I hate having random merge commits.

kendallpark9 tahun yang lalu

I use a git GUI for staging commits, but the CLI + text editor for everything else (and no aliases). The CLI is universal--I can go to another dev's computer and get them out of rebase hell without learning their particular git GUI interface. Knowing the CLI by heart is also useful if you ever have to use git server side through SSH. I have found that the CLI fits into my workflow better than the GUI for everything except staging.

sigi459 tahun yang lalu

I work very well on a cli. I can do partial adds faster than you and don't had any 'oh shit' moments for a few years.

I do not care if someone is using a gui.

My takeaway: - If i can use git on an cli, i can use git on any server with an cli. I do need this for when i use git on my ansible maschine or on my home media server or when doing something with build infrastructure (jenkins -> git -> cli)

marssaxman9 tahun yang lalu

Past experience with GUI frontends and other sorts of simplifying interfaces for version control tools has left me extremely reluctant to use anything more than git's out-of-the-box command line, despite its execrably wretched, unlearnable inconsistency. When things don't make sense with git, I can at least compare notes with coworkers, or search the web and find many discussions where other people have been similarly confused, and received useful advice. If I'm using some custom frontend interface, on the other hand, there are inevitably going to be situations it doesn't handle where I have to fall back to the command line, which I won't remember anything about because I will not have been using it, nobody else on my team is likely to be familiar with the tools I'm using, and discussions on the web are likely to be scarce. Better to just absorb the ongoing pain of git's terrible interface for day-to-day tasks so that I'm not completely hosed when things inevitably go wrong.

Balero9 tahun yang lalu

Additionally you can always use the command line if you need to. I use a GUI for 99% of what I do, then use the CLI for what I need it for.

dlwdlw9 tahun yang lalu

I wouldn't say "anyone" is trying to hard but I have seen a lot of people who immediately disregard guis as soon as they internalize that the cli is more difficult. Reasons include wanting to be "badass" or "smart". Yet many also do not care about how got differs and basically ask "how do I save" and proceed to revolve their entire workflow on a few copy pasted or memorized commands.other they hear how "rebase" is only for "smart" people...

On the opposite side gui users can often be unaware of the actual model and instead be working with imperfect internal models with be GUI being a crutch.

In both cases there is lack of desire to learn but I'm often more sympathetic to the latter where people want just enough information to do their work well as oppossed to the former who often make things harder than they have to be in all areas and have lost touch with true expertise in favor of appearance of expertise.

[deleted]9 tahun yang lalu

chiefalchemist9 tahun yang lalu

Which Git GUI are you using?

The GUI is said to be a major leap forward in human conputer usage, in the context the CLI just strikes me as either (elitist?) jargon, or brogrammer bravado. In either case, not really a step forward but certain macho. I still don't get it.

repsak9 tahun yang lalu

I use https://github.com/jonas/tig for interactive staging and git CLI for everything else. Best of both worlds and I don't have to leave the terminal.

aglionby9 tahun yang lalu

+1, not having to use a mouse is great. I also use zsh's inbuilt git aliases [0] which I can't recommend enough -- I've found using git CLI without them a pain now that I'm used to them. These together have me productive and happy.

[0] https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git

barbs9 tahun yang lalu

Tip for new tig-players: whilst you can use tig perfectly fine with just the keyboard, it does support using the mouse. Just add `set mouse = yes` to `~/.tigrc` :)

dozzie9 tahun yang lalu

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Or just couldn't be bothered with leaving terminal. I refuse to reach for mouse for any repository operation when everything else I do from console.

Pxtl9 tahun yang lalu

I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.

cytzol9 tahun yang lalu

GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.

Pxtl9 tahun yang lalu

We have a naming convention that feature branches are named "feature-[descriptionOfFeature]" here and I wanted to bulk-delete all the merged feature branches that developers had left dangling, without killing the release branches and the like. Grepping helped there.

Like I said, super-rare situation.

pkamb9 tahun yang lalu

In addition to better staging and committing, I love my git GUI for allowing me to easily see and work with every past commit.

Right click on any commit and I can create a new branch there, copy the SHA, do a mixed reset to that location, rebase on it, etc. SO much easier to visualize the actual tree of commits you're working with.

I'm sure some people do do all that from the command line. But every CLI coworker of mine has really only known the basics of branching and committing. The GUI unlocks the repo and all of its branches and commits as something you can play with and explore.

ashelmire9 tahun yang lalu

Git is, imo, way too simple to require a gui. How long is it taking you and your coworkers to make commits? git commit -am "message" (or add the files you want with git add, then commit); git push; git pr -m "message". The longest part of that is coming up with a good commit message. A gui isn't going to stop people from making mistakes because the mistakes aren't from complexity of the command line, they are from committing things you shouldn't, which will happen regardless of whether or not you use a gui.

quicklyfrozen9 tahun yang lalu

For me, using a GUI makes it much less likely I'll commit the wrong changes as I can quickly review each staged file across the entire tree before committing, and also see if there are unstaged changes (including new files which was often the bane of an SVN workflow) which need to be included.

I typically use git gui to commit changes, the cli for other operations, and occasionally source tree to visualize branches and compare with remote repos.

B_6129 tahun yang lalu

The Git UI that comes with intelij can do all the essentials git statements and has a console that logs everything it is doing.

And you can also learn useful things by reading the console sometimes. There is no magic.

outworlder9 tahun yang lalu

"- It's easy to keep files uncommitted for long periods of time intentionally, without slowing down my workflow." "- My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.)"

Do you mean that as "not committed", or "not pushed"?

If you mean not committed, then why is it a good thing? You should be committing often. Then you push after you are satisfied. It is much easier to revert mistakes that way.

inferiorhuman9 tahun yang lalu

Once upon a time I found a git GUI that I liked (SourceTree). Then Atlassian bought it and pushed their cloud nonsense on me so hard that I just gave up and reverted back to the command line. Eventually I bought the O'Reilly book and figured out how to do the neat things that SourceTree would let me do. Only this time the GUI wouldn't get borked while trying to stage individual lines.

I haven't looked back because I haven't found the need.

lambda9 tahun yang lalu

I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs.

It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc.

There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.

sb82449 tahun yang lalu

I'm in such agreement here.

I often see files that clearly shouldn't have been committed. I always bring up using Sourcetree or something else, but everyone seems to think that it's okay the way it is. I can't force it on them and to each their own. It is really frustrating though, because there's this stigma against using a git GUI, but the end results of using one are (in my experience) significantly better.

[deleted]9 tahun yang lalu

CruiseDevice9 tahun yang lalu

I don't know how much difference does it make using gui or cli. When i was interviwed for my first job i was asked questions on git. And they asked if i use gui or cli.I think they wanted to know if i really know how to use git through cli. I never used gui for git, maybe i will use in the future. I think Ohsitgit is a good resource which i was trying to find on internet for so long.

drdrey9 tahun yang lalu

It doesn't have to be an exclusive or. I use the CLI for most things, but a GUI when it makes sense (like you mentioned, staging specific hunks). I find that for the most part, my CLI workflow is so straightforward I rarely get in an "oh shit" moment: git pull, git co -b featurebranch, a series of git ci -av, and a git push to open a pull request.

crescentfresh9 tahun yang lalu

There's a git GUI??

Seriously though, I'm somewhat new to git and any problem I come across (which are many as a new learner) are solved with command line options. I'm not even familiar with the best GUI options out there and have been trying to learn what seemed to be the "standard" way of git'ing.

chis9 tahun yang lalu

I’m a big fan of Gitkraken. Great for doing common actions in one click, and graphically viewing history. It’s crazy how negatively people judge me for using it though. It’s like telling someone I prefer Microsoft Word as my IDE.

chuckdries9 tahun yang lalu

Seconded for a GUI. I've been using gitkraken for almost a year now, never looked back.

(full disclosure: as of last week I actually work for the company behind gitkraken but I started using it far before I realized they were local)

machiaweliczny9 tahun yang lalu

On mac I can recommend Gitup. It's fast and easy. Also vs code has quite nice git integration. I just use it for making commits though. Everything else is faster from CLI.

foobaw9 tahun yang lalu

Android Studio has a git UI built-in so it's really useful.

TomK329 tahun yang lalu

I always do `git add --patch`, it's very precise and I can edit lines before staging them. I really don't see why someone would work without it (or a GUI).

[deleted]9 tahun yang lalu

zxy_xyz9 tahun yang lalu

I use the CLI because I don't currently work on any group projects.

justbaker9 tahun yang lalu

I’ve only seen the opposite effect in practice. My odd look as well.

hyperpallium9 tahun yang lalu

So... which git GUI are you using?

qaq9 tahun yang lalu

Which git GUI are you using?

firemelt9 tahun yang lalu

What git gui? Git kraken?

collinmanderson9 tahun yang lalu

Which GUI do you use?

mmmpop9 tahun yang lalu

> I think anyone who uses the CLI is either trying too hard

Why do you think it's okay to share this opinion?

ksk9 tahun yang lalu

The problem of course is the question - What gives anyone a right to do anything? What gives you the right to police the comments? What gives me the right to question your questioning? Meta-discussions always get sidetracked..

lwansbrough9 tahun yang lalu

Because this is a forum and nothing I say matters.

Angostura9 tahun yang lalu

What makes you think it is not?

Gracana9 tahun yang lalu

Because it's rude and antagonistic and it compels a lot of people to post to defend themselves. It's classic trolling.

mmmpop9 tahun yang lalu

It's not constructive, who cares what you think about CLI users? The fact I'm being downvoted says a lot about the state of this forum.

falsedan9 tahun yang lalu

Your comment was also trolling: I would have avoided the leading question and just commented on the probable negative interpretation the some CLI users might make of the comment.

falcolas9 tahun yang lalu

A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb".

Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (and everyone else's) repo, DON'T DO IT.

rkangel9 tahun yang lalu

This is a place where Mercurial wins out. Hg has the concept of phases that makes it much harder to screw up rewriting history:

https://www.mercurial-scm.org/wiki/Phases

falcolas9 tahun yang lalu

Replacing a table saw with a circular saw (bad analogies abound) doesn't remove the opportunities for losing appendages. Especially for those who don't learn how to use the tools put in front of them.

"It is impossible to make anything foolproof because fools are so ingenious."

Yes, Git is a sharper tool with fewer blade guards than other version control systems, including HG. That sharpness and relative lack of safety mechanisms, however, lets you do things you can't in other systems. The real problem is that folks use these tools without attempting to understand them and cargo-cult onto a workflow which leaves them open to screwing things up.

To continue the "git off my lawn" moment - I've had to use the reflog exactly zero times in the past few years, despite using rebase locally on a fairly frequent basis (and sadly remotely to fix other's bungles as well). This is only because I respect git for its sharp edges, and when it comes time to re-write history with rebase, I work carefully.

azernik9 tahun yang lalu

I use the reflog all the time to fix my own rebase mistakes; it's just on rebasing I've done locally, and where the results haven't made it out to a shared repo.

Groxx9 tahun yang lalu

Rewriting shared history fits the metaphor pretty well.

But you can still chop off your thumb in your local history, and that's safe to fix - you just have to know where the duct tape is.

AlexCoventry9 tahun yang lalu

On the other hand, doing it is the only way you're going to learn. Just do it in a safe environment, with a snapshot of the repository.

jsmthrowaway9 tahun yang lalu

Yep. That is the important tip, right here.

    $ pushd ..
    $ cp -a my-project my-project-before-I-did-git-surgery
    $ popd

Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up?

    $ pushd ..
    $ rm -rf my-project
    $ cp -a my-project-before-I-did-git-surgery my-project
    $ popd

Undo is a great thing, and it's also important to triple check the entire state of the repository before you push, because pushing is basically committing to whatever surgery you've done. If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

xaphod9 tahun yang lalu

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git.

If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

bpchaps9 tahun yang lalu

Sure it's wrong if you know what you're doing. But that's not who the blog post is for.

Sometimes it's okay to take liberties with good practices - especially when learning, or when the world is on fire and a push needs to happen now.

richforrester9 tahun yang lalu

> or when the world is on fire and a push needs to happen now.

The unwanted reality we live in.

jsmthrowaway9 tahun yang lalu

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your choice to spend the next hour typing the right Git commands to get back where you wanted to be, or just back out and try again. I know which one I'd prefer.

xaphod9 tahun yang lalu

I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily)

When you commit in git, that saves the whole project as a "snapshot". If you find yourself lost in some rebase hell or whatever, just reset HEAD back to a previous commit. It's simple as that! (git reset --hard <commit>)

Why I decided to reply to your comment was because this is a very crucial part of learning git. When you realize that you can always go back to what was before, you can start experimenting more freely.

jsmthrowaway9 tahun yang lalu

> git reset --hard <commit>

Unless part of your surgery involves files that do not yet live in the history, or you're working on a detached HEAD in a mid-merge state, or... git reset --hard is a very dangerous operation unless you're 100% sure of the entire state of the repository. That is a very rapid way to lose work if you're not perfectly diligent.

And sure, you shouldn't have to back up .git or your workspace, but sometimes, it's a hell of a lot easier to ripcord out and say "screw it" if you have a complete workspace from before you decided to launch down the rebase hole or whatever.

u801e9 tahun yang lalu

You could run git reset without the --hard parameter to keep unstaged changes in the working directory

minor3rd9 tahun yang lalu

It's only easier to copy the directory if you haven't done the due diligence of learning git properly. It's a tool to avoid doing the ripcord approach -- ever.

iamjaredwalters9 tahun yang lalu

Why not just create a new branch instead of copying your project over to a new dir?

palunon9 tahun yang lalu

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever.

I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared.

Git own "next" branch is actually force pushed to all the time, to remove patches which didn't make the cut for example.

falcolas9 tahun yang lalu

Personal opinion - re-reviewing a pull request when someone has erased all context from your last review of that PR via a rebase and force push is a royal PITA. Especially for changes that span more than a few files. Did they address your concerns? The only way to know is to go back through all of the changes on that feature branch, and hope you don't miss anything.

This, in contrast with just reviewing the latest commit, potentially going back to the rest of the changes with an eye towards the latest commit.

It frankly bugs the piss out of me when people rebase and ask me to review their latest changes - it feels disrespectful of my time.

gwright9 tahun yang lalu

I've taken to making the change as a fixup commit and leaving it in the PR for code review. Then when the changes are approved a quick `git rebase -i --auto-squash` cleans everything up before merging the branch back into `develop`.

jsmthrowaway9 tahun yang lalu

> force pushing to the branch to take into account criticism on commits can be helpful

Hm? Criticism on commits should be additive. The commit was made, response was made, and a new commit addresses the response. Rewriting history breaks a lot of things and removes context. Another approach:

1) Add commit addressing criticism.

2) Squash when merging feature in to master, which is one of the only cases where I think rewriting history is OK.

Much cleaner master history, no rewriting history (which you should never do once another checkout sees your branch, including GitHub), and a number of other benefits. If you're routinely force pushing feature branches, something is broken in your workflow, IMO.

flowardnut9 tahun yang lalu

practicing safe version control is better than abstinence

pretentiousPear9 tahun yang lalu

I see what you did there...

swalsh9 tahun yang lalu

rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.

falcolas9 tahun yang lalu

Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly.

And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especially in the context of re-writing the history of previously shared commits. Yes, it is capable of cleaning up and reducing the number of commits you have to read through when looking at history, but that's such a rare event that optimizing for it (especially by normalizing dangerous commands like `git push -f`) seems, well, premature.

Yokohiii9 tahun yang lalu

Completely agree. Rebase is practically only safe on single developer feature branches which haven't been merged or completely isolated repos that produces patches only. Keeping track of all requirements in the former is hard, especially if the dev doesn't know git pitfalls. No one should default to rebase in a day to day workflow, but it is quite common.

Sir_Cmpwn9 tahun yang lalu

Rebase is mostly useful for cleaning up local commits or feature branches. You can rebase without force pushing master.

Nullabillity9 tahun yang lalu

You already have git-revert, for reverting commits without rewriting history.

swalsh9 tahun yang lalu

You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. When reverting code is easy, and the company has good logging to identify problems, you can deploy more often. It's a good thing.

But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. One commit, as little dependencies as possible. Rebase is the right tool to use for this. The goal is a tidy linear history.

lmm9 tahun yang lalu

> But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible.

How are these concepts related to each other? Merges don't make reverting any harder.

Yokohiii9 tahun yang lalu

That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?

swalsh9 tahun yang lalu

It was actually quite clean, and the environment was extremely stable. The trick is, every commit was "self-contained". Reverting it would go to another previous stable version. Creating a self-contained commit can be done many ways, and rebase is one common tool used to do it. Another is the use of git merge with --squash and a cherry-pick.

drdrey9 tahun yang lalu

git revert is exactly the tool for the situation you are describing

swalsh9 tahun yang lalu

Sorry again, you're not understanding my point. Git revert is of course used... but i'm not worried about the mechanics of the revert itself. I'm worried about each revert being a "self-contained" piece. That the project was stable after the revert. That's the bit that was important. A Linear history of commits is the important bit. Not how to do a revert.

sirmarksalot9 tahun yang lalu

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you.

After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch.

In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.

lmm9 tahun yang lalu

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

falsedan9 tahun yang lalu

It’s a lot of paperwork to avoid a perfectly safe and normal git command.

lmm9 tahun yang lalu

No it isn't. You'd always want to create a feature branch so that you can PR the fix - it's a change going into master, it should go through the normal change-going-into-master review flow. And you'd always have to run some command to indicate that this was the branch where you wanted to undo what you'd done to master. That the command is called "revert" is a little weird, but it's no more paperwork than any other command would be.

sirmarksalot9 tahun yang lalu

To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.

falsedan9 tahun yang lalu

That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream.

When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!

falcolas9 tahun yang lalu

Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you.

If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a year. Now productivity is halted dead until someone goes in and fixes it and makes yet another force push.

The worst part to me is that it makes the repo lossy. The entire purpose of having version control is actively subverted in the name of "clean".

falsedan9 tahun yang lalu

I think this is fine, but then I'm comfortable with what a force-push is (a remote reset) and I know that the commits still exist even when the ref is moved, and how to inspect the history of a bare repo to move the ref back.

I don't understand the business requirement for a non-lossy repo. In my experience, we need to be able to link a release to a specific commit, and we need to show that the changes were reviewed & tested before they were deployed. We use tags for this.

I also think the entire purpose of source control is to be able to answer question like "who changed this? when was it changed? why?".

> Now productivity is halted dead

Because of a bad push to a single repo? I really like the distributed nature of git, which lets me stay productive even when other repos and branches elsewhere are having issues. I would avoid treating git as 'SVN but newer'.

madeofpalk9 tahun yang lalu

driving can be dangerous, but so productive. I think it's important to each new adults how to properly use it.

leggomylibro9 tahun yang lalu

Reminds me of a time I saw a funny Makefile mistake. SRCS contained both .cpp and .c files, and someone copied a recipe that only replaced .c ones.

Then they used the resulting variable in 'make clean'. That was more of an, 'oh shit, git pull' sort of thing though.

sfink9 tahun yang lalu

You could also use an alternative CLI for git. My preferred one is hg-git.

I'm sort of kidding, but not really. By using it, I can operate on a git repo using the mercurial CLI, which I am more comfortable with and have built tooling around.

Once you have the extension installed, it's a matter of prepending 'git+' to the beginning of eg a github url to clone it, and then you can use native mercurial commands.

Obviously, this is an extra layer with all of the problems that involves (eg you're going to be managing git branches through an hg interface. Which works surprisingly well most of the time.) So this makes NO SENSE WHATSOEVER unless (1) you are comfortable with the hg interface, (2) you aren't that comfortable with the git interface, and (3) you don't need to do complex operations that would require thinking through the layers of what is happening.

Honestly, though, if I want to contribute to a github repo, this gives me everything I need 95% of the time. So far, the only time I ran into trouble was when the active branch was renamed in the github repo. Things got very tangled up, and I had to re-clone and import my patch stack. Judging by the number of people talking about making "backups" of git repos in this comment section, it doesn't sound like that's an unexpected operation in git-land. With mercurial's immutable and append-only nature, I very very rarely need to do this, so it felt kind of awful.

(Admittedly, my main hg repo that I work on is 6GB and I'm normally near the limit of my disk space, so my habits don't really match your typical megabyte-sized github repo in some noncompiled language.)

compiler-guy9 tahun yang lalu

The fact web pages like this exist, and are popular, and make it to the top of Hacker News is all you need to know about git's ease-of-use and mental model.

That Perforce and SVN don't get such things should also tell you something.

(Which isn't to hate on git--it's a great tool.)

forrestthewoods9 tahun yang lalu

Threads like this are a nice reminder of how nice it is to use Perforce. There's no such thing as getting yourself into a bad situation. Not even for artists or designers.

Git has eleventy million blog posts trying to explain how simple it is to use. That's a clear sign that it is, in fact, not simple or easy.

accatyyc9 tahun yang lalu

Reminds me of all articles attempting to explain how simple monads are

yes_or_gnome9 tahun yang lalu

The SVN and P4 articles exists (just google for "svn mistakes" and "perforce p4 mistakes"), but either 1. nobody is sharing them to HN or 2. they do and nobody cares to vote them up.

Unrelated topic (falling cats), same logical fallacy: http://www.radiolab.org/story/102525-vertigo/ (Starting around 14:20)

compiler-guy9 tahun yang lalu

“Nobody submits them, or nobody cares to vote them up.”

That should tell you something: these articles don’t resonate with the crowd. That should tell you something.

yes_or_gnome9 tahun yang lalu

I take your original comment as an indictment that git is somehow broken by design. Which sure, you're entitled to an opinion, but to bring up SVN in the same breath is absurd.

That's why I replied.

I can't really address p4 because I haven't used it for any real world use cases. Only to prepare for an interview. With that limited use, I can't come with any reason to think it's superior.

compiler-guy9 tahun yang lalu

You take my original comment incorrectly. I said nothing about how git is designed and how it may be broken. I made no claims about how Perforce may or may not be superior. I made no claim as to how SVN may or may not be superior.

I made exactly one claim:

These git cheatsheets on how to get out of a bad state get a lot of traction on Hacker News. That is a pretty good indicator of something. Let's think about what that is. The fact that you consider it a serious indictment of git should also tell you something.

I'll make another claim now though:

When someone criticizes git, some users sure get defensive about it. That should also tell you something.

yes_or_gnome9 tahun yang lalu

You're a looney.

anotherevan9 tahun yang lalu

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”

— Isaac Wolkerstorfer (@agnoster)

erikb9 tahun yang lalu

I always fight for people really learning git, because that's when it finally starts to get good. And I always tell people that git is not the tool that everybody should use. Most people just need a simple data storage with diff management, like Dropbox or SVN.

But even after nearly 10 years, the pressure from the aint-nobody-got-time-for-that crowd is still there. I really, really hope that the git devs don't feel pushed to simplify and therefore depower git. Thinking turning VIM into the Windows text editor.

wyuenho9 tahun yang lalu

They can certainly provide much better porcelain out of the box. Mercurial is at least as powerful as git, but I always joked that the learning curve between the two is something like, you read the docs for 5 mins and you'll know what the next 50 commands to type into hg. Whereas git, you spend 50 minutes reading the Pro Git book, just so you know what the next 5 commands should be.

ksec9 tahun yang lalu

I am glad hg has both Facebook and Google using it. Otherwise Git would have suck the air out of DVCS.

erikb9 tahun yang lalu

Sorry, but you don't know git if you think Mercurial is even coming close.

That is not trolling btw. It's really possible not to know what you can do with it if you haven't learned it in depth.

The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more. At that point you can even program a simplified git if you want.

agentgt9 tahun yang lalu

> Sorry, but you don't know git if you think Mercurial is even coming close.

And you don't know mercurial if you think that.

Both are great and powerful and both have pros/cons.

> The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more.

The problem with git on this is it is actually often sort of hard to find "the right" way to do things. This is in large part because of the popularity of git. There is so much content and a good deal disparate (e.g. Stack Overflow).

Mercurial on the other hand has far less content and it is maybe a little more consolidated and thus IMO slightly easier to find.

> At that point you can even program a simplified git if you want.

.... are you sure you are not trolling...

wyuenho9 tahun yang lalu

TBH, I've been an hg and git user for about 10 years now, I have only come across simple things that you'd expect to work in git but doesn't. For the longest time, you have to resort to contortions like this[1] so as to not lose commits after reverting a merge and then merge again.

[1]: https://github.com/git/git/blob/master/Documentation/howto/r...

What can't you do in Mercurial that you can in git these days?

BTW, I think we are talking about the same book.

erikb9 tahun yang lalu

I could name a few things, like interactive rebases, but the main thing is not something that can really be explained. Have you ever significantly become strong in some kind of contest, may it be sports, gaming, music or similar? There is this situation where one day you struggle with something and don't see an end, and the next day it finally clicks, and you can do things naturally that one day earlier where not even imaginable.

If you've experienced that once consciously, then you can regonize it and you know when you experience it you've hit someting really good in your life that moves you forward.

Sadly it seems you must take that hurdle in anything until a certain age or you will always believe this is impossible and therefore never invest the energy to reach it.

The thing is that this is not possible to achieve with any random software. For instance no matter how much you learn MS Word, you probably won't experience that. But when learning Vim or Emacs there's a chance you get there. Same is with git. And once you've achieved it once consciously, you will always want to be in that state in everything important you do.

That's why the really good stuff only has a few followers, most simply don't get the appeal because they never would invest the energy to get "there" even if they knew exactly how much it would take. But for those who have achieved it there is no going back. You cannot go back from controlling (almost) any bit of your repository to Mercurial.

But that's also why I think for most users something like Mercurial should be The VCS. Most people don't know the reward they are missing, so they don't feel the pain of missing it, and therefore have no logical reason to go through the pain of really learning git.

Tomis029 tahun yang lalu

Long story short, you're using git because it makes you feel smart. Ironically, you even admit it - "therefore have no logical reason to go through the pain of really learning git". Correct, there is no logical reason to deal with a contorted DVCS when there are better alternatives. Your arguments are fully subjective.

erikb9 tahun yang lalu

If you tell a blind person, he should use the color red more when dressing, it might be a good advise, but for the blind person there is no logical reason to choose red over green.

What I'm saying is that most people are blind when it comes to skill, because they never make it over the hurdle once. But because most people don't have any skill, it is general consensus in our society to declare skills based on interest rather than the ability to solve hard problems or win competitions. I mean if one person is unable to judge if another person is good at solving merge conflicts, how could he criticize that person declaring himself as Git Expert Of The Team. And then again of course most people feel it is inappropriate to tell other people they are unskilled, so posts like this one get hated a lot on. But actually it's just calling out the facts. Sky is blue, grass is green, most people are too unskilled to even recognize what would enhance skills.

Tomis029 tahun yang lalu

Unless I'm mistaken, people are paid to solve engineering/programming problems, not fight with a mess of a DVCS. And if I can use a Mercurial GUI and do in 15 seconds what would take 5+ minutes in the git command line, what's the point of being the Git Expert Of The Team? Is version control not used for saving work progress? A simple thing that 99.99+% of developers should be taking for granted in an ideal world, just like when pressing Ctrl+S in your IDE (hopefully) saves the file without asking what encoding you want to use and what partition you want it written on.

You seem to be under the impression that doing hard things has some intrinsic value, when it's not the case. You could be rolling rocks uphill all day and be the best in the world at it. So what? A keyboard going clicketyclack* for 5 minutes while typing git commands (and possibly stackoverflow queries) is the opposite of work, it's actually a waste of time. Sure, at the end of the day you solved the problem git presented you; you're smart, and feel satisfied with you amazing display of intelligence and skill. However, this ignores the fact that you should not have had to solve that problem to begin with, because your version control system should just magically work (unless you get a bonus for each git commit/merge).

> how could he criticize that person declaring himself as Git Expert Of The Team

I have no problem with someone being a git expert - I actually will even admit that I am not a git expert and that there are people extremely skilled at git. The issue here is that there are some people really skilled at, for example, typing using the backs of their fingers. Potentially impressive, but entirely useless. Saying you're skilled at git is like saying you're skilled at using Jira or editing Wikipedia; good for you, but in all but most extreme cases this doesn't actually generate value and it also doesn't make you a better developer.

> one person is unable to judge if another person is good at solving merge conflicts

Just out of curiosity, is this somehow relevant to git? Shouldn't solving a merge conflict be a simple matter of looking at a diff tool presenting you two inputs and one output screen? Or better yet, wouldn't it be better if you were automatically told you are editing a file someone else is working on, so that it prevents conflicts from happening?

erikb9 tahun yang lalu

feel downvoted.

Cthulhu_9 tahun yang lalu

I don't think git will lose features, and even if they do, git's core and data model is really, really good - if you look closely, most commands are relatively simple operations on the relatively simple data model and tree structure. I'd say they'll continue the current direction, mostly adding missing features and changing the defaults to be more sane (like default push mechanics).

makecheck9 tahun yang lalu

Creating a sane and consistent UI for “git” is not the same as limiting its power.

They could have had every feature they do today without creating weird differences in options and terminology between sub-commands, and they could have set better defaults.

There needs to be an official “git 3” rethinking of options and defaults to solidify the foundation for the years to come and promote widespread adoption. Anything that simply tries to improve “git” as a layer on top will fail due to obscurity.

yxhuvud9 tahun yang lalu

  git checkout name-of-the-correct-branch
  # grab the last commit to master
  git cherry-pick master
  # delete it from master
  git checkout master
  git reset HEAD~ --hard

The two lines in the middle can be

  git cherry-pick -
  git checkout -

, and voila, it suddenly is name insensitive.

sirmarksalot9 tahun yang lalu

The absolute worst situation I've gotten into was just the other day, when my team managed to check in two files with the same name, but different capitalization. The server (Bitbucket) is Linux-based, but all the workstations are Mac or PC, so the names collided on everyone's desktops. This prevented anyone from pulling or checking out a different branch, so even after master was fixed, everyone's environment stayed broken until someone figured out the right magic incantation (git rm --cached).

yes_or_gnome9 tahun yang lalu

Not really an issue with git, but with OSX. In doing some research of git, I wanted to look at the first git repos. Those are torvalds/git.git and torvalds/linux.git. If you clone linux.git on OSX and run `git status`, you'll see this:

    $ git status --short
    ## master...origin/master
    M include/uapi/linux/netfilter/xt_connmark.h
    M include/uapi/linux/netfilter/xt_dscp.h
    M include/uapi/linux/netfilter/xt_mark.h
    M include/uapi/linux/netfilter/xt_rateest.h
    M include/uapi/linux/netfilter/xt_tcpmss.h
    M include/uapi/linux/netfilter_ipv4/ipt_ecn.h
    M include/uapi/linux/netfilter_ipv4/ipt_ttl.h
    M include/uapi/linux/netfilter_ipv6/ip6t_hl.h
    M net/netfilter/xt_dscp.c
    M net/netfilter/xt_hl.c
    M net/netfilter/xt_rateest.c
    M net/netfilter/xt_tcpmss.c

sirmarksalot9 tahun yang lalu

I disagree here. Case-insensitive file systems have existed for decades, and are part of the development landscape. Any tool that works across multiple machines needs to support them. In this case, I blame Bitbucket, for not providing any way to treat this as a merge conflict.

yes_or_gnome9 tahun yang lalu

The tool that doesn't work with case insensitive filenames is OSX.

Edit: To add, how is git supposed to handle two files with the same name -- as is the case -- with a case insensitive file system? You can't have two files with the "same" name.

    git checkout file1

Is entirely different than

    git checkout FILE1

In any other platform ls file1 FILE1 would show two different files, but on OSX, it'll show the same file twice.

jacobsenscott9 tahun yang lalu

Most oh shit git moments are a result of "advanced" git users trying to force people who just want to get shit done to "keep the history clean" with rebases. If you stick with git push, pull, and merge you really can't lose work. And any "advanced" git user knows the right git log incantation to filter out merge commits and such to make the history look clean.

aetherspawn9 tahun yang lalu

For me the big thing was learning to 1/ not work on master unless I’m alone and 2/ commit all my work incrementally

    git pull —-rebase

    git log 
    git rebase -i HEAD~n

So basically I want to make sure my work is pushed to remote as a separate commit before attempting to run any commands except the ones above. But you can do pretty much anything with the set above.

humblebee9 tahun yang lalu

I generally replace `git pull` with a `git fetch $remote` + `git rebase $remote/branch-name`. It provides the added benefit that I can easily diff changes prior to the rebase so that I know what is going into my branch. The use of the `--rebase` flag isn't bad though and I may start doing that when I know I will not be doing any diff prior to a rebase.

I also use `git merge-base` quite a bit so that I do not have to count commits when working with really simple branches.

WhyNotHugo9 tahun yang lalu

Geez, using `git add .` is the worst thing you can do. Never use this. Tutorials: stop suggesting this. It's just a recipe to getting yourself into a mess (plus, you should never work so blindly!).

Add individual files, and, if possible, use `git add -p`, which lets you review each chunk before adding it to the index. Otherwise, diff and add individual files.

ninkendo9 tahun yang lalu

Hell, even if you want to stage every change, what you really want is `git add -A`, which stages deletes too (`git add .` ignores any files you've deleted or renamed, it only stages new files and changes to existing files.)

azernik9 tahun yang lalu

Note that for fixing rebase mistakes, `git reflog` is not super user-friendly; each step in the rebase is included, including the ones that did not involve user intervention.

In those cases, it's better to use `git reflog $BRANCH_NAME`, which has the additional advantage of not including your switching from one branch to another.

kbenson9 tahun yang lalu

I've always found this flowchart[1] wonderful and concise for handling this problem (that is, how do I fix the problem I've made for myself with git)..

1: http://justinhileman.info/article/git-pretty/

k_bx9 tahun yang lalu

> Fuck this noise, I give up.

PLEASE add a note to check if you have anything interesting in stashes/branches before doing the rm -rf, I've lost some work so many times because of the "fuck this noise" approach.

styfle9 tahun yang lalu

My oh shit moment is that `git add .` doesn't stage deleted files. I almost always use `git add -A` because that is typically what I meant, especially for someone coming from another Version Control system.

burgerdev9 tahun yang lalu

In choose your own adventure style: http://sethrobertson.github.io/GitFixUm/fixup.html

crispytx9 tahun yang lalu

I ran into a situation the other day where the instructions for "Fuck this noise, I give up" didn't even work! Glad to hear others have found themselves in similar boats.

magoon9 tahun yang lalu

Pro tip: -p

Interactive staging, eg git add -p or git checkout -p

You’ll be asked, for each change, if you want to stage it. This helps tremendously in preventing commits with stray marks, console logs, etc. Try it!

methodin9 tahun yang lalu

A better tool would be a remote repo clone where you have to resolve messed up situations and only pass if you push a fixed solution :)

aaronsnoswell9 tahun yang lalu

Haha. There should be an entry there for 'Oh shit - I just pushed our private keys to the public github repo'.

yes_or_gnome9 tahun yang lalu

Just as an FYI, those will likely live in Github forever. Run `git ls-remote` where ever you have had this problem. You'll see that there are refs for every PR in the form `refs/pull/NNNN/head` and `refs/pull/NNNN/merge`; where `NNNN` is the PR number, `head` is the latest commit and `merge` is the final commit.

If any of those commits with confidential information is reachable from any of those commits, then they'll never be garbage collected from Github.

ursus_bonum9 tahun yang lalu

I use git in this particular way, and if you do anything different you are WRONG AND BAD or you have IMPURE MOTIVES!

anonymousjunior9 tahun yang lalu

reminds me of https://github.com/blog/2019-how-to-undo-almost-anything-wit...

Vel0cityX9 tahun yang lalu

Pretty basic stuff (and very few of them), I expected more.

mugglelover9 tahun yang lalu

Oh shit I give up could instead be `git clean -fdx`

mugglelover9 tahun yang lalu

“Oh shit I give up” should perhaps instead be `git clean -fdx`

m6PeelVLsQ8QawN9 tahun yang lalu

It happens to everyone :)

I'd like to contribute my list of git booboos: https://github.com/1337/yesterday-i-learned/blob/master/git....

lmm9 tahun yang lalu

> I used git in the terminal and the diffs/patches/merges/pull requests don't turn out right

Your answer there is just doing git pull --rebase by hand. I don't like that style at all, but if you must do it surely use the command that's designed for doing it.

> I pushed stupid things onto the remote server

Worth saying you can branch before fixing - that might be a little less intimidating than "access by commit ID"

> I already made my changes in multiple commits, but the repo owner wants me to rebase it to a single commit

Disagree with "you should do it", though that's probably a political question.

m6PeelVLsQ8QawN9 tahun yang lalu

Thanks for the review! I actually wrote that years ago (in frustration). Will give it a revision when I have time.

I think I would rebase my PR comment history away only if "the repo owner wants me to rebase it to a single commit". In that case, I'm just doing whatever the repo wants the repo to be structured.

greysteil9 tahun yang lalu

Nice. For anyone who hasn't see it, Flight Rules for Git is even more comprehensive: https://github.com/k88hudson/git-flight-rules

james-skemp9 tahun yang lalu

I like this. I was trying to do something similar with my Git cheatsheet - https://gist.github.com/JamesSkemp/15fcf0147cb85bb633bf - but it doesn't have the kind of organization I'd like due to the limitations of using a Gist.

taoistextremist9 tahun yang lalu

I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.

Cthulhu_9 tahun yang lalu

> I'm planning on making a hard push for git on the team I just joined

You mean a force push. `git push --force` is one of my favorite commands. I've aliased `git yolo` to `git push --force --no-verify`.

icebraining9 tahun yang lalu

--force-with-lease is usually the better option; it makes sure nobody pushed anything since the last time you fetched from the remote.

If they have, you can fetch, see if you still want to overwrite that branch, and if so run it again.

taoistextremist9 tahun yang lalu

Maybe I ought to also insist I build git from source and scrub any reference to --force from it.

graywh9 tahun yang lalu

Use Gitlab and you can at least prevent --force push with permissions.

Shank9 tahun yang lalu

GitHub does this too.

nasredin9 tahun yang lalu

>git yolo

I hope you do not work on missiles or on passenger aircrafts!

pc869 tahun yang lalu

I'm genuinely curious how they manage source without any VCS. Is it just a bunch of zip files for old versions?

No judgment, nobody is born knowing this stuff, just that I'm surprised to hear this is still out in the wild.

nobleach9 tahun yang lalu

When I started working for the government (2010) it was .backup, .bak, .new, .newNEW, new-JIM, .20100910... all on one guy's workstation. Luckily Gitorious landed within months. (better than nothing)

taoistextremist9 tahun yang lalu

We SSH onto a server to do work and it seems we just make folders wherever for our individual projects. They do (nightly, I think) backups which is sort of a rudimentary version control. And while I'm told it exists, it seems the "dev" version of their website isn't used, so they just kind of add in their changes live; definitely a risky environment. They've had a small team for a while and most of their applications could run relatively in isolation from others, so they could get away with it, but they're looking to grow so I'm trying to push this stuff.

pc869 tahun yang lalu

Yeah the "right way" to do VCS is definitely a lot of overhead for a team like that, but by the time you need to scale up (and by "up" I mean 3-6 people total who are committing code multiple times daily?) the business is likely so busy it's a HUGE uphill battle to implement something like that, especially since most of the people who let an environment like that happen will likely not be super familiar with Git/hg/TFS/whatever.

rdiddly9 tahun yang lalu

I dunno if I'd agree that it's a lot of overhead, for what you get back. Hell I'm a one-man team right now and I'm using source control. Some of my little experiments go horribly awry. Some of my deletions are a bit too aggressive/arrogant. Sometimes you need to diff shit. Version control frees me to be bold.

minor3rd9 tahun yang lalu

Agree with you here. I use git for literally every coding project, even my quick practice folders. I haven't had an "oh-shit" moment from losing anything in like 5 years, back when I was still learning git.

daemin9 tahun yang lalu

Everybody that is not a programmer (or otherwise IT/technical) doesn't understand version control at all. So as other commentators have said, their idea of version control is to save the file with a different name, a different extension, etc.

I have seen it as files on a shared drive. I have seen it as files on a sharepoint drive. I have seen it as files inside of an SVN repository.

DamonHD9 tahun yang lalu

No, there's a lot of decent project managers, lawyers, etc, who understand something called revision control, which has much the same job in the real world for managing complex pieces of work, specs, etc...

ryandrake9 tahun yang lalu

I remember joining a company where the official build was cut from whatever was on the engineer's PC at the time, since that PC was the only one set up that could build the software. No documentation, no formal bug tracking, no source control, very infrequent backups that were probably never tested. It was basically a "0 on the Joel Test" shop. This software was for embedded aerospace applications too (however not safety-critical where DO-178B would apply, thank god).

woodrowbarlow9 tahun yang lalu

i know that some shops do nightly tape backups of the harddrive on the fileshare and consider that sufficient for version control. the theory is "developers don't have to learn a new tool and we will never lose more than one day's worth of work".

these shops don't understand the benefits version control offers when it comes to code review and maintenance patches on old versions of the software, or vendor-specific streams for your software.

vultour9 tahun yang lalu

My friend works for a small company that doesn't use a VCS. They just make a new folder and copy the project into it every once in a while.

stygiansonic9 tahun yang lalu

If this is a guide for beginners, there should be (more?) warnings not to do history rewriting operations on commits that have already pushed.

icc979 tahun yang lalu

If you read to the bottom:

> Disclaimer: I am not, nor do I even remotely claim to be, an expert at git. This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial. And yes, there are other ways to do these same things with more theoretical purity or whatever, but I've come to these steps through trial and error and lots of swearing and table flipping, and I had this crazy idea to share them with a healthy dose of levity and profanity. Take it or leave it as you will!

schneidmaster9 tahun yang lalu

From the disclaimer at the bottom:

> This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial.

dkarl9 tahun yang lalu

It may not be intended to be a beginner's tutorial, but it is. Someone who needs to be told about `git commit --amend` and `git diff --staged` also needs to be warned about rewriting history that has been shared with others.

mahkoh9 tahun yang lalu

Why is recovering from an upstream rebase considered more problematic than recovering from merge conflicts?

user59944619 tahun yang lalu

Who said anything about recovering. First we'll have to determine if upstream is supposed to be used in a rebase workflow or a merge workflow.

outsidetheparty9 tahun yang lalu

Seems they agree:

> This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial.

[deleted]9 tahun yang lalu

zellyn9 tahun yang lalu

Is it just me or did http://ohshitgit.com/#accidental-commit-master forget to checkout master before calling reset?

throwanem9 tahun yang lalu

Creating a branch doesn't check it out by default. To do both at once, it's either "checkout -b" or "branch -c", I forget which because it's "b c" in Magit.

zellyn9 tahun yang lalu

Ah, I figured I was missing something.

XaspR8d9 tahun yang lalu

It's still on master because `git branch` just creates and doesn't do checkout.

(Which is why I've almost exclusively switched to `git checkout -b <newbranch>` for creating. How often do I want to create but not switch to the branch?)

mkesper9 tahun yang lalu

Git branch is helpful if you just want to make a snapshot before doing something potentially harmful. If you hose up, just checkout that branch again.

[deleted]9 tahun yang lalu

gboudrias9 tahun yang lalu

Apparently the default behavior is for people who just like to know it's there ;)

dkns9 tahun yang lalu

> Oh shit, I accidentally committed to the wrong branch!

I find cherry-picking to be easier in this case. Just checkout the branch and cherry pick commits from 'wrong' branch.

https://git-scm.com/docs/git-cherry-pick

yes_or_gnome9 tahun yang lalu

I don't see how that's easier. There's `git checkout -b my-new-branch` which is even easier than the originally proposed solution. Followed by `git checkout master && git reset --hard @{u}` or, if you don't want to switch between branches, `git branch -f master master@{u}`.

nemetroid9 tahun yang lalu

I agree that the proposed solution is not the best. If you can fix your problem without dirtying the working tree (i.e. by simply moving changesets around), that's almost always a nicer way to do it.

[deleted]9 tahun yang lalu

mtrpcic9 tahun yang lalu

But then those commits are still in the wrong branch. If I accidentally commit something to master instead of a development branch, I can't deploy master until my development branch is merged in, as the one commit isn't ready for live.

mseebach9 tahun yang lalu

If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure that all your teammates pull the fixed branch. If that's a situation you regularly find yourself in, protecting master from direct pushes and only doing PRs is a good solution (GitHub, BitBucket and GitLab all have tooling for this).

dkns9 tahun yang lalu

Maybe it's just me but I feel like if you work with multiple developers you should never, ever force push master. I'm wary of force pushing branches in general, unless that's a branch that only I work on.

mseebach9 tahun yang lalu

It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.

sigjuice9 tahun yang lalu

Why not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.

mseebach9 tahun yang lalu

Because that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits.

Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way.

And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).

Cthulhu_9 tahun yang lalu

That's where tools like github and gitlab come in (or a pre-receive hook on the server), which can deny all commits to master. If that's something you want to prevent of course - and tbf, as soon as there's more than one or two people working on a project, I'd lock master down.

amelius9 tahun yang lalu

> Oh shit, I did something terribly wrong, please tell me git has a magic time machine!?!

Shouldn't it be easy for Git to remove objects created after a given time, and then remove all objects that refer to those objects iteratively?

icebraining9 tahun yang lalu

I think that's exactly what it does; the default is two weeks: https://git-scm.com/docs/git-gc

herogreen9 tahun yang lalu

In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.

anton_gogolev9 tahun yang lalu

If by "designed" you mean "picking a content-addressable DAG as an underlying data structure", then yes, it is really beautiful. If you mean "provide a sane level of abstraction over said data structure", then hell no!

jimktrains29 tahun yang lalu

I think git provides a sane level of abstraction.

I don't think it provides the most consistent UI or helpful help, though. Once you move away from "learning git commands" to "learning how git works" and kind of figuring out which parts the commands refer to has helped also. That's still terrible though.

ivix9 tahun yang lalu

>I don't think it provides the most consistent UI or helpful help, though.

Understatement! Git is one of the most user-hostile tools I've ever seen. And I've used Sendmail.

pqh9 tahun yang lalu

Just read the manual.

https://git-scm.com

lmm9 tahun yang lalu

Most of the abstraction is fine. The staging area model is a total mess though. The way that staging interacts with other commands (e.g. stash) is constantly surprising.

jefurii9 tahun yang lalu

Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?

I had trouble with Git until I discovered "git add -p".

I'll grant that Git could do with a revision of its commands and args.

sirmarksalot9 tahun yang lalu

The issue isn't with the level of abstraction, but with the side-effect based workflow of some of the more common commands. The most visible of these is unstaging a file.

The syntax is "git reset -- <file path>". What does that do? Well, it tells git not to change the head pointer. Of course, it wasn't going to do that anyway, but as a side effect of not doing anything, it makes a decision about what to do with all the staged files. The default resolution is to unstage everything so that everything that happened between the old head and the new head can go in the stage. When you add the "--", you're telling it to only apply that resolution to the specified files.

So what you're actually telling Git is, "don't do anything, but when you don't do anything, move these files out of the stage so that you have room for all the files that you're not going to stage."

And this is why I used Git for an entire year without actually knowing what "git reset" does.

jefurii9 tahun yang lalu

I'll not argue with you that Git's syntax is weird. It's an airplane that was launched as a kite by Linus and then assembled into an airliner while in flight by the passengers. Could definitely do with a revision.

The neat thing is that Git is an expression of that UNIX philosophy in which tools have various layers that are separated. You can have the crazy Git syntax but you can also write another command (or a GUI) that wraps Git and gives you the set of sane commands you wish it had, and which covers 90% of your use-cases, while still keeping the original around in case you need it.

[Disclaimer: I've spent the past couple years doing exactly this (the GUI part) for a digital archives application. And to lmm's point up above my app does hide the staging step from the end-user.]

lmm9 tahun yang lalu

> Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?

But when a carpenter stashes and unstashes their things, they don't suddenly find out they're magically planning to do a lot of things that they weren't previously planning to do.

jefurii9 tahun yang lalu

Ha, that's a great way to put it. There's also "It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg" tho it's not quite as easy as the quote makes it out to be. Wish I knew who said that.

lhuser1239 tahun yang lalu

> I don't think it provides the most consistent UI

That reminded a video where Linus Torvals is been interviewed and he says that if he ever have to make good UI to get out of a desert island, he would die there.

hyperhopper9 tahun yang lalu

http://stevelosh.com/blog/2013/04/git-koans/

revmoo9 tahun yang lalu

tonetheman9 tahun yang lalu

Preach on brother!!!!!

_pmf_9 tahun yang lalu

Beautifully stated.

nvahalik9 tahun yang lalu

I recently had one of those holy-crap-what-did-I-just-do-I-lost-everything moments... But then realized that my scrollback had a list of files and my IDEs (PhpStorm and WebStorm) both kept _local_ revision histories and I was able to restore everything I had done.

maaaats9 tahun yang lalu

I've been saved by the local history in IntelliJ more times than I would like to admit, heh.

Cthulhu_9 tahun yang lalu

I've had a few cases where I accidentally removed a local change before committing it; using Time Machine you can still recover some files then. I wish more editors had built-in support for it, if you're trying to restore a local file, macOS's TextEdit has support for Time Machine.

nsxwolf9 tahun yang lalu

This combined with Time Machine backups means I haven't lost source in years.

jimktrains29 tahun yang lalu

Learning about the reflog just changed everything -- it removes all fear of "loosing" anything but uncommitted work.

In a similar vain to `git checkout`, `git reset --hard` is also an excellent way to loose uncommitted work.

humblebee9 tahun yang lalu

When I know what file I'm missing a commit from, I usually end up using `git log` instead.

    git log -p --all --first-parent --remotes --reflog --author-date-order -- somefile

I accidently screwed up a rebase and dropped a test file. It managed to get merged as a blank file (always review after rebase!), I noticed a few days later when a PR was passing which I swore would of failed some tests I had written. Since then I couldn't exactly remember when I made the commit to the file, so trying to search through reflog became difficult. The above command makes it pretty easy as it will show you every change made to a file.

0xcde4c3db9 tahun yang lalu

I'm a big fan of 'git checkout -p'. Even if you nuke a hunk you actually wanted, it's not actually gone until it falls off your scrollback buffer.

ronnier9 tahun yang lalu

I go all in https://github.com/rroller/dotfiles/blob/master/bin/git-nuke

Yokohiii9 tahun yang lalu

When in doubt either:

* commit to an itermediate branch as storage

* git stash && git stash apply (repeat last to recover stuff)

nathancahill9 tahun yang lalu

git stash pop is often nicer for temporary stuff.

philjohn9 tahun yang lalu

The underlying system is well designed, but a user interface that allows you to get into a point where you can hose a repo is anything but.

runeks9 tahun yang lalu

The user interface should allow you to do anything you want, but warn you properly. In my experience, this is what git does if you’re about to do something dangerous.

How can you blame git for deleting stuff if you blindly pass --force to it?

blibble9 tahun yang lalu

you can always get back to what you had before unless you try really, really hard to destroy data

git reflog is your friend

mamon9 tahun yang lalu

The very existence of such guides tells us a lot about how easy to use Git is :)

rootlocus9 tahun yang lalu

Well, I think it tells how much time some developers are willing to spend learning the tools they are using.

Tomis029 tahun yang lalu

First of all, using git is not really a choice in many companies (except "choose to use git or choose to find another job"). Because, despite being a terrible tool, "git won". So people like me choose to put the minimum of time in getting familiar with a tool that even some git experts/devs admit is confusing to use (after having used it and being intimately familiar with it for years! or maybe you think they were unwilling to spend enough time learning). More importantly, git (or any DVCS) is NOT work. Lots of technical people seem to have forgotten what purpose versioning control serves (saving your progress as you go) and instead seem to relish in solving git problems that make them feel they're working but add in fact no value whatsoever. That is the core issue. Takes about 10 minutes to get familiar with hg (and then just use a GUI), whereas you have to spend days/weeks reading git docs in order to internalize how it actually works. For what? Just to save some files on a server. I'm sorry, but no.

migueh9 tahun yang lalu

Truly right

welly9 tahun yang lalu

By and large, git is easy to use. Most people will do little beyond committing changes and very occasional branching and merging with the likelihood of not needing any of the tips in the site posted.

For these users, git is perfectly useable and easy to use.

Cthulhu_9 tahun yang lalu

Name me any software that doesn't need a guide like this.

like, how do you even exit vim? You need a guide for that. Or to get it closer to git / this guide, how do you undo / redo?

oblio9 tahun yang lalu

You're comparing git to vim in terms of ease of use...

SAI_Peregrinus9 tahun yang lalu

That's actually a rather good comparison. Both have learning cliffs of doom[1]but once you've spent a few months with them they're arguably more powerful than the other options. They're usually fast to use but very hard to learn. I wouldn't say either one is easy though.

[1] https://dementiagaming.files.wordpress.com/2010/08/learning_...

oblio9 tahun yang lalu

That's debatable. I don't think anyone has actually made any study which proves that git is superior to Mercurial or that vim is superior to Notepad++ or Sublime.

[deleted]9 tahun yang lalu

lkrubner9 tahun yang lalu

I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns:

-----------------------

Here are some minor failure modes I’ve seen with Git:

1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood)

2. data is erased for good because someone makes a mistake while using rebase

3. a developer introduces a new bug while trying to resolve a merge conflict

4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged

5. a developer makes a change in the wrong branch because they forgot what branch they were in

6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash

7. developers confused by working in an unattached commit, after a botched attempt to revert

8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve

9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult

10. developers get confused about which branch will be deployed (I see this especially in shops that have lots of repos for lots of small apps, and use different Git workflow strategies for the different repos, often because different programmers or different teams control the different repos)

11. developers push their changes to “origin” but forget to push to “upstream” or vice versa.

But all of that stuff is trivial compared to the major flaw:

Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.

http://www.smashcompany.com/business/business-productivity-h...

rootlocus9 tahun yang lalu

> 2. data is erased for good because someone makes a mistake while using rebase

No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git.

I've been using git for 4 years both at work (with a team of 40+ people) and at home, without ever having any of the problems listed here (except 3 which has nothing to do with git). It takes a few hours, maybe a few days to understand how git works and how to use it. Instead of blaming the tools, you (and your team) should probably learn how to use them.

burstmode9 tahun yang lalu

>If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git.

GIT is the only source control system where you can completly loose commited data by actions (or commands) available the non-admin user. It's funny to see that this is considered a "feature" and not a design failure.

rootlocus9 tahun yang lalu

> completly loose commited data

Except the whole point is that you can't completely lose commited data, even if you tried really hard. And the solution to the problem was `git reflog` which shows the history of the HEAD.

lkrubner9 tahun yang lalu

"Instead of blaming the tools, you (and your team) should probably learn how to use them."

From the essay:

--------------------

And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.

rootlocus9 tahun yang lalu

> He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git.

Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer.

You're telling me a developer was too busy learning "other technologies", and in 6 months he couldn't be bothered (or was too afraid) to spend one or two hours going through a simple course about git? By that argument, he probably couldn't be bothered to learn how separate concerns into classes or how to use refactoring or write tests. What other things didn't he have time for? Unwillingness to learn is not an excuse.

> he never really learned how to use Git, because it was a low priority, for both him and our CEO.

I think it was more of a lower priority for your CEO than Sital. Learning git was something that benefited him more than it benefited the company.

I still have issues with your attitude, because it can be applied to anything useful in software development, but management might take issue with. Writing tests? Who needs them? The CEO doesn't care so they're low priority. Refactoring? Waste of time. Management wants shiny features not code quality. Developers have tried really hard to convince management that some overhead is needed to keep the quality high and maintenance easy. Your attitude is the exact opposite.

lkrubner9 tahun yang lalu

* Your attitude is the exact opposite. *

You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

I did my best to re-create the extent to which decisions were driven by panic and the pressure of time.

Please note, every company in the world has a finite amount of time, and a finite amount of money. You can argue that a company should hire people with more experience, but people with more experience will be more expensive, so you will end up with less people. Or you can argue that a company should hire more people, of less experience, and then train them. Training takes time, so in this case you are trading time for money.

All of these strategies work, but in different circumstances. In the circumstances that I faced in 2015, described in the book, I advocated for the strategy of less people, of a higher skill level. I was, however, outvoted, which is a reality of corporate life.

It is relatively rare that a company follows an ideal strategy. What I see instead is constant course correction, often with a bit of a lag, so that the company ends up having the ideal strategy for dealing with the situation that it faced 6 months ago, which is not necessarily the ideal strategy for what it is facing now.

Business tends to be chaotic. The Platonic Ideal of computer programming needs to be adjust to the real realities that businesses face.

To be clear, Sital's attitude was a major problem, and myself and co-workers advocated that he be fired. But management kept him on, and I was given the responsibility of covering for the gaps in his knowledge. I was not happy about this, but this is a reality of business: we often have to accept that a decision has been made that we strongly disagree with, and then we need to somehow make the best of it.

rootlocus9 tahun yang lalu

Well, I see you're adding more and more constraints to suit your point of view. First you attacked git by pointing out some flaws that were only just about people not knowing how it worked. Then you gave a more specific example, where actually, it was in the company's best interest to hire a novice developer who didn't have time to learn git, because he was pressured into focusing on whatever the CEO wanted. Then you argued that really, companies can't hire good people, or train them, or use good practices and we should just use the path of least resistance. At the end of the argument, it wasn't really about git.

The issue you have with git, is that untrained developers have a hard time using it. Which brings me back to my original comment. It really doesn't take long to train someone to use git. And you can choose whatever flow you want. That's the beauty of it. If the company hires lower skill people, you can just guide choose a branching mode suited for their needs. They don't even need to use branches. Or just teach them to use an UI. But please don't teach them SVN.

lkrubner9 tahun yang lalu

You don't give a reason for this:

But please don't teach them SVN

Why would you say this?

You also say:

If the company hires lower skill people, you can just guide choose a branching mode suited for their needs

If the company has lower skill people, why not go with the technology that requires less skill? This seems like an obvious step.

rootlocus9 tahun yang lalu

Because SVN is painfully slow, bloated and almost nobody uses it anymore. You'd be doing them a disservice by teaching them a technology they most likely won't be able to take with them to their next job.

lkrubner9 tahun yang lalu

This is simply untrue:

"The issue you have with git, is that untrained developers have a hard time using it."

Please re-read my first post, up above, which started this thread. I wrote:

"But all of that stuff is trivial compared to the major flaw:

Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion."

rootlocus9 tahun yang lalu

Ok, I agree, attacked your weakest argument, which you specifically marked as being trivial flaws. So to address your actual issue:

> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.

Why is it hard for them to use git? For simple use cases, git can be as easy as commit & push. No need for branches. There are even UIs which allow you to easily make commits and see the log [1]. If more people work together and conflicts arise, I honestly don't know how SVN is better at solving them.

[1] https://www.gitkraken.com/

lkrubner9 tahun yang lalu

"Why is it hard for them to use git? "

All I can do is quote what you wrote in a different comment:

"If you're an artist, git is not for you."

dennisgorelik9 tahun yang lalu

> Sital's attitude was a major problem

Would it be the best if Sital never committed his changes? That way he would not be able to hurt your project and you would be able to fire Sital sooner.

lkrubner9 tahun yang lalu

My leadership philosophy is "fire fast". I shouldn't have to jump through a bunch of hoops to fire someone, at least not under the rules that hold sway in the USA. Obviously the approach needs to be adjusted to fit with the laws of whatever nation you might be in. But in the USA, the law is lenient towards leadership when leadership wants to fire someone. Therefore, I should have been able to simply fire Sital. Then we would have hired someone good.

lkrubner9 tahun yang lalu

About this:

"No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them."

It is frustrating that you continue to take your advanced skills for granted. It is frustrating that you can not see what should be an obvious fact: that your skills are above average and therefore it is a mathematical fact that most people have less skill than you, and their lack of skill is a real world business situation that needs to be dealt with realistically. And more so, for the rest of your career your skills will continue to develop, so the gap between you and the average will continue to grow, and therefore the damage that you can do will continue to grow, if you fail to recognize that you are above average.

I can assure that I've seen data lost forever because of "git rebase". It doesn't matter that someone with your skills could have saved the situation. You were not there, therefore your skills don't matter! It is very important that you see this, or you will never be able to give accurate advice to business leaders.

If the leadership of a company decided to hire people with a skill level of x, then they should not also use a technology that requires a skill level of x + 1. You can reasonably tell them "For what you are trying to do, you should hire people with a skill level of x + 1." That is exactly what I did in the situation that I describe here:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

But sometimes the business leadership will disagree with you. They may have terrible reasons, but if you can not get them to change their minds, then you need to deal with the consequences of their bad decisions. At which point it makes sense to advocate for a technology that only requires a skill level of x.

[ EDIT TO ADD ]

I'll point out that you are demonstrating a classic case of the Dunning–Kruger effect. In particular:

"the miscalibration of the highly competent stems from an error about others."

That is, you have above average IQ and skill, therefore you perceive things to be easy, which are in fact not easy for the average.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

You are an elite programmer. Try to avoid acting like the kind elite programmer that I criticized in "Business productivity has been undermined by the hubris and power-grabbing of elite computer programmers".

vijucat9 tahun yang lalu

Great list. You'll face a predictable backlash by git fanatics, but the fact remains that git's surface area / complexity is way beyond the needs or wants of non-technical users. This is another good rebuttal to the supposed shortcomings of svn which make git necessary:

https://svnvsgit.com/

You're right about the joy that end users feel when they learn TortoiseSVN and are able to put what they see as "infinite undo" into practice so easily.

There was a sarcastic list of git koans, too, somewhere, which I found funny.

rootlocus9 tahun yang lalu

Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?

lkrubner9 tahun yang lalu

because I actually learned how it works

The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread.

Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.

rootlocus9 tahun yang lalu

> The argument is focused on those who can not learn how it works.

If you're a software developer who uses branches and merges, you absolutely should learn how it works.

If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them.

> Also, it's important to note that everything on that list is something that actually happened.

I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).

lkrubner9 tahun yang lalu

If you're an artist, git is not for you.

Exactly. That is the entire argument. From the essay:

------

I agree, Git is amazing and very powerful. What I’m suggesting is that we should recognize that it has a very high cost. It might empower complex workflows for sophisticated teams of experienced computer programmers, but it exiles the rest of the staff, and this has significant productivity costs.

...Git is very powerful? I’m willing to go along with that line of thought so long as we all understand that using a tool that is more powerful than needed can lead to problems.

http://www.smashcompany.com/business/business-productivity-h...

[ EDIT ]

Also, this bit from the essay might make the argument more clear:

For many years, I had a refrain which I gave as advice to each client I worked with: “Your software developers are expensive, so try to shift work away from them.” Ideally, software developers should only do work that relies on skills that no one else has. If a task can be done by a graphic designer, then it should be done by a graphic designer, because generally graphic designers are paid less than software developers (obviously not in all cases, but most of the time). I co-founded a startup in 2002, and I stayed with it till 2008, and we ran a team of 8 people using this principle: push work to the less skilled people, if they can handle it. Save the tough stuff for the computer programmer. We had great success with this style of work.

teilo9 tahun yang lalu

Most of these have nothing to do with git, but are true of any distributed repository. At that point, your argument becomes: distributed repositories are bad for business.

Then there's this:

> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.

What rubbish. The features of subversion are a subset of git, and the git equivalents are easy to learn. For a svn user, there's literally only a single additional command they need to know: git push.

ryanbrunner9 tahun yang lalu

To be fair, git is the first VCS I've ever used where there was any real learning curve at all for normal, everyday use. I don't recall anyone ever really teaching me subversion, outside of maybe 5 minutes walking through the GUI. With git I feel like it probably took a few months of regular use before I felt comfortable with it.

That doesn't mean that I'd go back to subversion, but I don't think it's fair to say it's as easy to use.

DougBTX9 tahun yang lalu

I remember trying to do merges in SVN years ago, it was so hard my team agreed to just never make new branches. Git it so much easier to use, it seems hard to compare.

ryanbrunner9 tahun yang lalu

For branching / administration you're probably right. Typically though, subversion workflows would involve administrators doing most of the heavy lifting of branching / merging and everyone else working against those - for those users Subversion was absolutely easier.

icebraining9 tahun yang lalu

The features of subversion are a subset of git

Well, except for locking, which I hear is useful for people working with hard-to-merge files.

lkrubner9 tahun yang lalu

distributed repositories are bad for business.

If you read the whole essay, you will see that "distributed repositories are bad for business" is exactly the argument being made.

ryanbrunner9 tahun yang lalu

I'm not necessarily the biggest git fan in the world, but here's some refutations to some of these concerns:

> 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood)

This is more of a workflow question than a VCS question, and would be true of any VCS that allows branching (i.e. anything remotely close to a modern VCS)

> 2. data is erased for good because someone makes a mistake while using rebase

Data isn't permanently removed from rebasing, you can still get at it with the reflog. If you discovered the problem months later, I suppose that could happen. checkout and reset --hard can irrecobably destroy uncomitted data (as can clean, but that's more obvious and has appropriate guardrails)

> 4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged

Overuse of cherry-picking feels like a workflow smell to me, but even still, you shouldn't need to care. Merging the entire branch will work fine if some of the contents have been cherry-picked previously.

> 5. a developer makes a change in the wrong branch because they forgot what branch they were in

True of any VCS with branching.

> 6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash

I'll agree with you here, I think stash is a bit of a footgun and almost never makes sense to use if the stashed contents are going to live for longer than a minute or two. But this is easily addressable with workflow, don't use stash for anything other than an extremely temporary holding place.

> 7. developers confused by working in an unattached commit, after a botched attempt to revert

Git is generally not great about warning you about dangerous operations or things you shouldn't be doing. Running against a detached HEAD is not one of those things, you'd have to be willfully ignoring what it's telling you to not realize that this isn't a safe thing to do.

> 8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve

I will agree that git could make it easier to say "just get me back to origin, i give up"

> 9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult

Blame isn't great, but it sucks in precisely the same way it sucks in any VCS. Just seeing who last committed a line often isn't enough information. It would be cool to see an alternative here, but I don't see many better alternatives around.

It sounds like in general, this is more a concern with dealing with branches and branching, which is totally fair. If simple trunk-based development works for you, branches are an unnecessary addition. But there's no reason you have to use all these git features. You can happily have everyone just work against master and never need to think about branches (in that mode the various Git GUIs will probably be more than adequate as well).

I do agree that git tutorials tend to focus on a more advanced branching / rebase focused workflow, and that simpler resources for less technically minded folks would be handy.

lkrubner9 tahun yang lalu

* there's no reason you have to use all these git features *

If you are not using all of the Git features, then why use Git? Why not use something simple, like Subversion? As I wrote in the linked essay:

-------------------

When I list these complaints for developers, most of them respond “You are complaining about Git’s power. The stuff you list isn’t really a flaw, rather those are all examples of how amazing Git is. It is flexible enough that you can do almost anything with it.”

I agree, Git is amazing and very powerful. What I’m suggesting is that we should recognize that it has a very high cost. It might empower complex workflows for sophisticated teams of experienced computer programmers, but it exiles the rest of the staff, and this has significant productivity costs. And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.

Git is very powerful? I’m willing to go along with that line of thought so long as we all understand that using a tool that is more powerful than needed can lead to problems.

http://www.smashcompany.com/business/business-productivity-h...

rootlocus9 tahun yang lalu

Because git is magnitudes of times faster, and it's the most widespread VCS in the world at the moment.

lkrubner9 tahun yang lalu

Those are weak reasons, if Git is the wrong choice for the team.

0xmohit9 tahun yang lalu

A collection of commonly used git tips and tricks:

https://github.com/git-tips/tips

0xmohit9 tahun yang lalu

Learn git one commit at a time:

http://gitready.com

btbuildem9 tahun yang lalu

In short:

| Oh shit, I do before I think

Cthulhu_9 tahun yang lalu

Yeah that explains a lot of git mishaps - typos, a missed `--`, `master` vs `origin master` vs `origin/master`, `reset` vs `checkout`, that kinda thing. A lot of things that can go wrong with subtle mistakes, and a lot of things that can go wrong thanks to muscle memory.

hitekker9 tahun yang lalu

I like using IDEA, PyCharm's and Webstorm's "local history" feature to compensate for gaps in my git knowledge.

A constant, instant backup of all files, independent of the repo, has been my saving grace for small projects.

vbuwivbiu9 tahun yang lalu

+ it shows you a diff with the ability to revert individual changes in code

nvahalik9 tahun yang lalu

I recently did something like that—I think I did a reset of the repo and lost all of my changes. Was able to piece it back together using local history. Took me another 20 minutes, but at least all of my data was there.

nikanj9 tahun yang lalu

We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear.

I've browsed through a few git guides, but can't seem to find anything that would let me:

1) Do something like "du -s *|sort -n" for the entire Git history

2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in size.

pmjordan9 tahun yang lalu

I think you should be able to do something like this with

  git filter-branch

This won't be a terribly fun exercise, and could be very painful if your history contains a lot of merges. (should be easier with the cactus/rebase development model)

And of course everyone will have to hard-reset to the new branch.

I should mention I'm far from an expert on this. I've only ever used git filter branch on a handful of commits, and only based on examples provided by kind internet people. I certainly haven't done anything nearly as far-reaching as you're about to embark on.

Cthulhu_9 tahun yang lalu

Yeah, filter-branch is the way to go for this. Also to for example extract a folder into a new repository. I've used it in a few cases.

mistersquid9 tahun yang lalu

Early in the history of a repository, I committed some files with sensitive information. The only way to fix this (and similar problems) is to reconstruct the repos starting from the commit just before you committed the unwanted file(s).

I'm a bit of a git naif, there are doubtless better ways to do this. This was mine:

  0. Back up my repo.
  1. Save the entire commit history as patch files.
  2. Use BFG (amazing tool) to scrub all references to the unwanted files [0]
  3. Create new repo from the commit just before unwanted files.
  4. Apply the patches.
  5. Use a custom Perl script to apply the dates in the patch files to the new history. [1]

Technically, your repo will be fully reconstructed at step 4. Also, be advised the patch files themselves may have to be massaged to remove references to the file(s) in question. If the filenames themselves are not unwanted, you can add them to .gitignore for good measure.

Step 5 merely preserves the dates of the original commits. Keep in mind that for this last step, your script will have to work in reverse chronological order as the history will be altered from that point forward.

  [0] https://rtyley.github.io/bfg-repo-cleaner/
  [1] http://eddmann.com/posts/changing-the-timestamp-of-a-previous-git-commit/

EDIT: Swap steps 1 and 2. Add advisement that patch files may require manual alteration. Add hint regarding .gitignore. Title case "Perl".

bulatb9 tahun yang lalu

Have you looked at git-filter-branch?

The BFG program in this guide [0] seems reasonably close to #2. I don't know if you would need to manually trigger garbage collection in the remote repo, or how you'd do that.

https://help.github.com/articles/removing-sensitive-data-fro...

mitchty9 tahun yang lalu

You'll be rewriting history via filter-branch, e.g. everyone would need to do the same for the clone and be sure not to push up the old history: https://help.github.com/articles/removing-files-from-a-repos...

StringyBob9 tahun yang lalu

For part 1 - I used this https://stackoverflow.com/questions/13403069/how-to-find-out...

Which for part 2 then leads to the BFG repo cleaner (which I haven't used)

pierre-renaux9 tahun yang lalu

Git bfg should do the job, it works well for that and to remove files with secrets... or really anything you want to pretend never existed in your repo :)

https://rtyley.github.io/bfg-repo-cleaner/

vulkoingim9 tahun yang lalu

Have you tried this:

https://rtyley.github.io/bfg-repo-cleaner/

I've used it in the past, and it's pretty straightforward and does the job well :)

titanomachy9 tahun yang lalu

https://help.github.com/articles/removing-sensitive-data-fro...

grawprog9 tahun yang lalu

My last git mistake was pretty terrifying. I decided to try and go back to an old commit on a project on my local machine after about a days work. Somehow I ended up making the commit I wanted to revert to a new branch, then somehow tagged that branch with the name of the commit making git get angry and decide that branch wasn't valid. Then continuing in my ignorance I reset to that branch and tried to checkout only to watch my source and resource files vanish one by one. Deciding the commandline had caused enough trouble I returned to a qgit window I had open, all the source files were still there and I could at least save them one by one. Better refresh the qgit window. Oh shit now qgit's mad at me too. Well there goes thousands of lines of code and about 3 months worth of work. Eventually,after reading gits cryptic error messages and a few google searches I figured out how to remove a tag from a branch and properly checkout an old commit. I was really happy when all those source files reappeared.

paultannenbaum9 tahun yang lalu

Glad you figured it out! Having that much work on a single branch is a process smell in itself, ideally you would have found a way to get that code into the repo before it became that large (break down the work into smaller chunks, hide behind feature flags if needed, etc.). Beyond what you just described, reviewing that much work is nearly impossible to do correctly.

At the very least, if you are going to have a long lived branch, make granular commits and push to a remote repo frequently. That will give you a distributed backup strategy.

mynewtb9 tahun yang lalu

Git is not a backup! Had you had one, you could have had your mind at ease.

grawprog9 tahun yang lalu

Ya I realize this now. I usually keep backups. I don't know why I haven't been on this project. I'm using git properly now with proper backups for the project. Though everything's still on the local machine, it's better than the setup I had. I chose to take it as a warning to sort that shit out.

rootlocus9 tahun yang lalu

Pushing to a remote is a backup. Gitlab offers private repositories for free.

dsego9 tahun yang lalu

Until you force push ;)

rootlocus9 tahun yang lalu

And then you still have the commits, but no branch pointing to them. Don't worry, they're still there.

ben-schaaf9 tahun yang lalu

Its just as easy to delete most other backups.

dsego9 tahun yang lalu

Before doing anything with git that you're unsure of and could have dire consequences, just clone the directory beforehand. Then run the git commands to your heart's content.

rootlocus9 tahun yang lalu

Do yourself a favor and learn git properly. It pays of hugely in the long run. The book that clicked for me was Git Internals [1]

[1] https://github.com/pluralsight/git-internals-pdf

donald_knuth9 tahun yang lalu

Nothing about detached heads?

cjsuk9 tahun yang lalu

I admit to using this at least once a week.

teilo9 tahun yang lalu

I stubbornly stuck with Mercurial for a long time because of the complexity of git's UI. But when one moves beyond a few developers, the available tooling and extensive ecosystem for git makes it inevitable.

dhimes9 tahun yang lalu

Still with hg. You've frightened me.

oelmekki9 tahun yang lalu

Maybe it's not worth being in there because of how simple it is, but I guess it would be useful for newcomers:

    # Oh shit, I've changed 200 files and want to revert to the state of this morning
    $ git add . && git commit # often. Very often.
    $ git reset --hard commit_id

lemoncucumber9 tahun yang lalu

I think this is bad advice for git newbies two reasons:

1. ‘git add .’ is dangerous and should be avoided IMO, in case you ever have files around that you don’t want to commit. I frequently do. It’s better to ‘git commit -a’, and to just remember to run ‘git status’ frequently and ‘git add’ any new files.

2. ‘git reset —-hard’ is dangerous as well for newbies, since it’s destructive. Better to ‘git revert’ or to ‘git checkout <sha>; git checkout -b <newbranch>’, such that you can always get back to where you were.

icebraining9 tahun yang lalu

Wait, aren't you committing and immediately orphaning that commit? I think you should create a new branch or tag before the reset, otherwise how are going to get it back?

I guess you could rely on the reflog, but I don't think that's good practice.

oelmekki9 tahun yang lalu

lol, no, it's implicit there are many hours between the first command and the second one :)

It's purely commiting often to easily have checkpoints to revert to, nothing fancy (yet, incredibly useful).

j6059 tahun yang lalu

git reset --hard for what!? If you are a newcomer making mistakes it is fine for the mistake to be in the commits. Just fix the problem and commit again.

randallsquared9 tahun yang lalu

Also useful for panicky moments, with handy workflow: http://sethrobertson.github.io/GitFixUm/fixup.html

I visit this page every few weeks. :)

afshinmeh9 tahun yang lalu

Last one in particular: http://ohshitgit.com/#fuck-this-noise

Waterluvian9 tahun yang lalu

I gave up on rebasing or any form of history rewrite after going through the screw up phase, then watching every dev that came after me do the same at least once.

I realised that treating a git repo like an immutable collection, where existing commits are NEVER mutated makes it far easier to reason about history and nearly impossible to do serious damage.

Devs can do whatever they please with their own local pulls (such as squashing 50 rambling commits during dev), but once a commit is on remote, it never changes.

tnolet9 tahun yang lalu

Good thing HN doesn’t have memes, otherwise I would post one of those bears confessing “I’m a software engineer with 19 years of experience and I still don’t really understand git”.

Silliness aside, I guess Git suffers from the trait that it is very hard for many people to internalize and visualize how it works in their heads. Totally different but related: the Azure CLI is for some reason 10x easier to work with than the AWS CLI, while I’m 10x more experienced with AWS. I guess CLI design is also design.

DonnyV9 tahun yang lalu

This is why UI's were created. No productive person wants to fill there heads with a ton of commands and switches when you could just click a button.

mikestew9 tahun yang lalu

Which button? What happens when I click it? Am I going to have to remember this later?

It’s all “choose your abstraction”, so you’ll be filling your head with something whether it’s which button to push or what git checkout does. GUI or not, no button alt text is going to tell you what rebase means.

aeorgnoieang9 tahun yang lalu

I too felt this way once, and I still have to think (or even lookup) about what the conventions are occasionally, but there really is a point in learning Git at which you realize there really are not many 'oh shit' situations in which you can find yourself and not be able to escape unscathed.

But beyond learning Git itself, you need to develop suitable habits for using Git that are appropriate for your development workflow.

One habit I've consciously developed is to use 'WIP' commits (i.e. a regular commit with "WIP: Rebase me!" on the first line of the commit message) instead of stashing. All too often a stash lives for much longer than you'd naively expect and stashes are much harder to work with than commits. Even if the modifications are applied right away, commits are nearly as easy to 'apply' as a stash anyways.

mFixman9 tahun yang lalu

Honestly, a lot of what's wrong in git is that people seem to mostly memorize or copy-paste a finite amount of commands, and when something goes wrong they are completely lost unless they can find a way to copy-paste a solution.

Instead of saving a 6 command list for some use cases, why not just get used to the simple but kinda unintuitive way of how revisions and branches work? If you know that, you can solve any problem with `commit`, `checkout`, `reset`, `reflog`, and occasionally `cherry-pick`.

CJefferson9 tahun yang lalu

Quick quiz, what does 'git checkout x/y' do? I am aware of users hitting at least 3 interpretations.

Nimitz149 tahun yang lalu

I'd say it changes your code to match that of a branch in your local copy of the repo.

CJefferson9 tahun yang lalu

It resets the file x/y, or checks out branch y of remote x, or checks out local branch x/y. I've had confused users manage to create al of these cases, and git is very unhelpful in explaining the difference between the three cases.

ufo9 tahun yang lalu

I think you already answered your own question. It is very hard to get comfortable with things if they are unintuitive :)

rootlocus9 tahun yang lalu

I think lists like these are part of the problem. You shouldn't rely on tricks to use git, you should understand how it works.

migueh9 tahun yang lalu

*this

isuckatcoding9 tahun yang lalu

A missed opportunity to say gitting instead of getting.

skarap9 tahun yang lalu

One can read any amount of similar articles, but if they don't understand the data model behind all this, git will remain a complex and fragile beast for them. The feature-set is huge to be able to just remember all possible commands for all possible scenarios. If you don't know what index is or what a branch is, this all will look like a bunch of nonsense. On the other hand - your ruby code won't seem too logical either if you don't know the language.

So if git is the tool you use to get your job done - don't hesitate to spend a day or 2 on reading how it works and how you're supposed to use it.

trevor-e9 tahun yang lalu

I think Git would be way more approachable if things were named better. A key part of Git is whether a file is untracked/unstaged/staged, yet the terminology around this is very confusing. Why aren't commands simply `git stage`, `git unstage`, `git add` (to track files), `git remove` (to untrack), `git undo`, etc? Not to mention the overloaded command names like `git checkout`, how is `git checkout -- someFile` intuitive at all?

satish-setty9 tahun yang lalu

This is precisely one reason I like Mercurial over Git. Hg has commands which are more meaningful than those of git.

dhimes9 tahun yang lalu

+1 hg. I see it mentioned so seldom here that I'm actually worried it may go away.

omg_ketchup9 tahun yang lalu

Why not `git track` and `git untrack`?

trevor-e9 tahun yang lalu

TBH I'm not sure why I left add/remove in, track/untrack is simpler and more in line with what I was saying. :)

tzahola9 tahun yang lalu

You mean, gitting yourself out of bad situations? ( ͡° ͜ʖ ͡°)

pascalxus9 tahun yang lalu

This is a great resource, but I wish the name was different. The oh-shit reference is a bit too much.

jimmaswell9 tahun yang lalu

5+ years later and I still sometimes have to do the classic "repull the entire repo into a new folder and manually copy the wanted changes over"

sigmonsays9 tahun yang lalu

Git is easy once you understand it. What are people doing that is so difficult to understand?

migueh9 tahun yang lalu

Use without understand it

baristaGeek9 tahun yang lalu

Thank you so much! These are pretty useful tricks. Just a question: What's the difference between reflog and using git log to later checkout to a given commit?

rootlocus9 tahun yang lalu

You almost never checkout to a commit. You checkout to a branch. A branch is a reference to a commit, and the HEAD is a reference to a branch. The HEAD is where you are right now. When you make the HEAD point to a specific commit, you're in a 'detached head' state.

`git log` tells you all the commits that are part of the branch. More generally, they are the commits who are children of the current commit (the commit your branch points to).

`git reflog` tells you where your HEAD has been. When you change for branch to branch, the HEAD moves around. That history is recorded in the reflog. If you botch a rebase, your HEAD will sit on top of the newly created (and botched) commits. You can still access your previous commit by looking where the HEAD was before moving to the new commits made by the rebase.

legohead9 tahun yang lalu

So I just ran across this one: git diff --staged

I added a file and wanted to diff it, and this command helped! However, I made some changes in the file, and when I tried this command a second time, the changes don't show up :\ Only the original file that was added shows up in the diff. Now what? It's not the end of the world of course, as I can just look at the file in my editor, but I usually use diffs as a personal code-review before I commit.

nerdface9 tahun yang lalu

Yes, this is another one that confuses developers. When you 'git add' a file, it's added to the staging area as it was at that time. If you make subsequent modifications after you've staged it, those are unstaged changes. And you can diff between them. So despite git add'ing a new file, you still have to 'git add' afterwards if you make changes to it.

deathanatos9 tahun yang lalu

There's three "versions" of the code at play, if you will:

* the most recent commit

* the staged files

* the working directory

`git commit`, as you might already know, takes "the staged files" and turns it into a commit, making that the latest commit. `git add` adds a snapshot of a file in your working directory to the staged files. The important bit here is that the copy of the file in the staging area is separate from the file in your working directory. So, if after `git add`ing a file you make more changes, you will need to `git add` those subsequent changes if you wish to commit. `git status` will tell you this:

  » git status
  On branch master
  Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
  
  	modified:   foo.txt
  
  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
  
  	modified:   foo.txt

"Changes to be committed" is the staged files. "Changes not staged" is stuff that has been modified, but not `git add`'d. You can see here that I've changed foo.txt after git adding it; if I want those changes, I need to git add it again.

I can look at the diffs, too:

  # diff between the last commit, and the staged files
  # (i.e., what will be committed)
  git diff --staged
  # diff between the staged files and the working directory
  # (unstaged changes)
  git diff
  # diff of all changes since the last commit:
  # (stage+working dir, essentially)
  git diff HEAD

That should be all the various combinations.

I find that a lot of newcomers find the staging area weird, and usually ask some variant of "why would I not want to commit all of the files I've changed?" The staging area, used effectively, can really help you break out things into logical chunks of changes that can then be adequately described with a message in a commit. This can help others later: if your change is a bug fix, and someone wants to cherry-pick it to production, they might not want your new feature, or your lint fixes: they want a minimally risky fix. To that end, the stage/working dir separation acts as a sieve of sorts, letting the stuff that's "ready to go" get filtered out into a commit.

I want to mention the extremely useful `git add -p`: this command will interactively prompt you, hunk by hunk, for whether or not you want to stage that hunk. It will even let you edit the hunks prior to staging. So, for example, if I run across a spelling error, or a minor bug, I can very quickly add it (and just it) to the stage w/ `git add -p`, and then commit it, even if there are other modifications, even in the same file.

jordigh9 tahun yang lalu

> There's three "versions" of the code at play, if you will:

> * the most recent commit

> * the staged files

> * the working directory

This is weird. The staging area is like a commit but not a commit. They're changes that git is aware of and has a record of but not quite a permanent record.

Why not just make it a commit? You can always keep editing commits, or throw them out, or whatever. That's what I do with Mercurial. I write a commit and I keep adding stuff to it if I think it needs more stuff (or less stuff).

Gregory Szorc has a more extensive analysis of the situation in first subsection here: https://gregoryszorc.com/blog/2017/12/11/high-level-problems...

deathanatos9 tahun yang lalu

My best guess is that the commit metadata (particularly, message) is missing. You could always have it be "(uncommited, staged changes)" though, and that's probably descriptive enough. (I agree with you on the whole: having the staged data be a commit makes things conceptually much simpler.)

My other guess is that the "index" (the other name for the staging area) is also used for conflicts during merges & rebases, and that somehow plays into the problem of making it an actual commit. (But again, this comes across more as an excuse than a reason: I don't any viable reason why the staged changes can't still be an actual commit, and the merge conflict data just stored as a separate structure.)

That, or the person who added it just didn't think of it, or couldn't do it due to backwards compatibility.

Yokohiii9 tahun yang lalu

The site should clearly differ between local changes and pushed changes. Latter usually requires different strategies to recover, depending on repo policies.

Git golden rule: Never push -f if you don't know what you are doing.

gerbilly9 tahun yang lalu

On barrier to learning git is that people are understandably reluctant to try things out because they are working in real repositories.

This site makes a game out of learning git: https://learngitbranching.js.org/

It's a great way to learn without putting your real repository at risk.

degenerate9 tahun yang lalu

Thanks, I am new to git and already made some dumb mistakes with my real repo and had to start over. Now I'm terrified to try anything past pulling and pushing to master. Hopefully this helps me understand branching so I don't feel like I will break it all again.

city419 tahun yang lalu

One thing I do if I'm a little uncertain about my upcoming git actions is just move to a new branch: git checkout -b tryScaryGitStuff. That way if I ruin the commits, the original branch is still around as a back up.