Live data from Hacker News

Oh shit, git (2016)

ohshitgit.com

231–240 of 280 posts

Re: Oh shit, git (2016)

#231
post #215

Earlier quoted context omitted.

It's more streamlined, it's easier to scroll through staged and unstaged changes fast and flip lines/hunks/whatever between the two as you go, and you don't have to fire an external editor upon each hunk because you're already in one - emacs or vim (if using spacemacs). (Also, whether it's good or not, rebasing in all of its forms becomes your second nature because it becomes so easy...)

If you're selecting by hunk, you don't need to fire up the editor. I also find the hunk selection in the terminal to be excellent. It's lightning fast and I can use it blind. Also, firing up the editor for things like editing diffs when doing git add -p or when editing operations when doing git rebase -i, is not that big of a deal if you keep your editor light. Vim, for me, loads in an instant.

Agreed, selecting by hunk is ok in the terminal, I do it too sometimes when sshed someplace distant.

But you noted the two main differences yourself: (1) you don’t have to think in terms of git hunks if you don’t want to, lines or any blocks are as easy to deal with and (2) you don’t have to think about whether it would be quick or not to fire an editor because you don’t have to fire an editor.

This, plus everything’s lightning fast due to shortcuts. I use Magit in spacemacs and rebasing is very easy. I’ve done it so many hundreds of times that I can tell it from memory - e.g., fixup-merging the last two commits to the third one: “lljjriff,,” (maybe there’s a quicker way) - that’s less than typing git rebase -i.

Not trying to preach, just sharing why magit users are so happy about it.

Re: Oh shit, git (2016)

#232
post #97

Earlier quoted context omitted.

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. […

imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD. So `git restore file` should reset the worktree, if you allow an unflagged version of that command.

I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.

Re: Oh shit, git (2016)

#233
post #175

Earlier quoted context omitted.

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

"Trivial for whoever knows category theory" is about as serious as "a monad is just a monoid in the category of endofunctors, what's the problem?"

Re: Oh shit, git (2016)

#234

Earlier quoted context omitted.

Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.

And I don't want to say that Git isn't an improvement over many other version control systems. But, IMO, the real sea change there is the shift to a DVCS, and not Git's interface. Within the set of DVCS that I've used, I find Git to be easily the most difficult to understand and work with, and the one where I have to spend the most time reading and grokking abstruse explanations of the tool's implementation details i…

Fair enough. I won't say git's UI is intuitive -- it's not. But once I crested the learning curve, I do prefer it over the alternatives I'm familiar with. When I need to do something unusual, I have better luck figuring out how with git than the others.

That said, I am not familiar with most of the various version control systems out there, and I could easily be missing something that's genuinely better.

Re: Oh shit, git (2016)

#235
post #211

Earlier quoted context omitted.

CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".

Don't you have that backwards? With `git add -p`'s `e`(dit) option, I can (and occasionally do) add just some of the changes of a single line. I can freely edit the diff that dictates what goes in the index. With magit, I believe I'm limited to just selecting whole hunks or maybe whole lines.

It’s possible via ediff if you need it; magit devs didn’t want to implement it within magit itself IIUC because it’s fragile and changes in a temporary buffer may be lost, or something like that.

If you don’t like using ediff and really need to edit tons of hunks before staging, you could always commit/stash your dirty copy, revert back, edit files, check them in the way you want, possibly in multiple commits, then rebase your previously staged working copy on a new head and soft reset the head (it’s easier than it sounds) - which is the way I would do it in the terminal too if there was a lot to edit since it’s more fail-proof.

Re: Oh shit, git (2016)

#236
post #150

Earlier quoted context omitted.

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the…

> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.

Driving a Toyota feels like a game/toy. Which puts me on edge, because I feel detached from what the car is actually doing. The handling feels.... too smooth.

Re: Oh shit, git (2016)

#237

Earlier quoted context omitted.

Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.

Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.

> Don't use the UI. Use the CLI.

I'm specifically talking about the CLI.

> It sucked at first

It still sucks. It'll always suck. The project is unlikely to fix any of the suck.

Re: Oh shit, git (2016)

#238
post #214

Earlier quoted context omitted.

> The trouble is it's viral. By the time you've figured out it's happened, other people have probably pulled from that branch; at best they've spent time merging in the force-pushed version. More likely they've done that and then built more work on top of it, so either both versions make it into mainline and everyone is resolving conflicts, or you have to ask that person to rebase their work and create another chance…

> First, I don't understand how you're suggesting this situation arises. You're talking about a bunch of people all pulling from a branch while the only guy working on it is merrily force-pushing code and has absolutely no clue that anyone else is building work on top of it. Why in the world is there no communication on your team? Code can be communication too. It's really nice to be able to just pull someone's branc…

> Code can be communication too. It's really nice to be able to just pull someone's branch (that they maybe mentioned in standup) without having to interrupt them to tell them you're doing it.

But then if they communicated to you (during stand-up of whatever) their branch is ready to be used to build on, then they've made that code public and would avoid force-pushing, which is what I was saying? Conversely if they haven't told you then you wouldn't just randomly pick a commit and start building on it?

> When a dev gentle-pushes new commits and people merge them into their branches, it doesn't cause problems if they resolve conflicts differently, and other people who pull from their branches in turn don't have to keep re-resolving the same conflicts. > Rebase and force push are two sides of the same coin, let's not argue semantics. I say "no force pushing" rather than "no rebasing" because local rebase before you push doesn't cause problems.

AH so you're fundamentally against ever e.g. having a pull --rebase workflow on any branch you've ever pushed to any remote... regardless of who's working on what, what communication has occurred, whether that branch will even exist 2 hours from now, or whatever. Merge is the only valid approach in your mind, period. Honestly I have zero hope of trying to convince you merge isn't a size-fits-all dogma, so I won't try anymore except to point out that git supports both workflows for a reason, and its own documentation is clear that neither is strictly superior to the other: https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebas...

Re: Oh shit, git (2016)

#239
post #216

Earlier quoted context omitted.

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

re)use re)recorded re)solution. It allows git to record and re-use how merge conflicts are resolved. It's an esoteric command that 9/10 users will probably never use. But if part of your day job is, say, merging your startup's[1] local development with that of an upstream project[2], you will come to love this command very very quickly. 1) Rockmelt; 2) Chromium.

That sounds a lot like the patch theory stuff from darcs and pijul.

Re: Oh shit, git (2016)

#240
post #150

Earlier quoted context omitted.

> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.

lol, go back to jalopnik, dork.

Personal attacks will get you banned here. Would you mind reviewing the site guidelines and taking the spirit of this site more to heart? We've had to ask you this before.

If someone is wrong and you know more, reply with some of what you know, so we can all learn. If you don't want to, that's fine, but in that case please don't post anything.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN