Oh shit, git (2016) • Hacker News Board

Re: Oh shit, git (2016)

#211

Post by jolmg » Tue, May 14, 2019, 3:46 PM UTC

aldanor wrote: post #126

jolmg wrote: post #66

Earlier quoted context omitted.

I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.

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.

Re: Oh shit, git (2016)

#212

Post by mehrdadn » Tue, May 14, 2019, 3:46 PM UTC

lmm wrote: post #158

mehrdadn wrote: post #50

Earlier quoted context omitted.

> but it happens regularly in reviews But then you already know someone is reviewing that branch! So both of you avoid force-pushing. > or when casually working together on the same thing in Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one. > or when basing branches on other people's unfinalized work Without any sort of hint to the guy w…

> Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one. Well, one of force-pushing or casually working together had better be a rare exception, otherwise you'll do both at the same time. I'd rather not make force-pushing part of my normal workflow, because casually working together has more value to me. > Without any sort of hint to the guy…

> 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 for the same problem to occur.

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. Ignoring the questionable assumption that any commit on any branch is a sane one to build on top of -- why/how in the world is there zero communication on your team when you guys start building on each others' work?

Second... how is this any different from when the dev just gentle-pushes new commits instead of force-pushing?! You all will still end up having to resolve conflicts just the same when you rebase on top of their branch again... it sounds to me like what you're against is actually rebasing, only disguised as force-pushing.

Re: Oh shit, git (2016)

#213

Post by jolmg » Tue, May 14, 2019, 3:53 PM UTC

tomjakubowski wrote: post #81

jolmg wrote: post #66

Earlier quoted context omitted.

I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.

You're missing out on the lightning fast pull, interactive rebase, staging and commit capabilities of magit-status. The key bindings are intuitive and excellent.

They are intuitive and excellent, but I don't think they make things that much faster if at all. There's not much difference in speed between doing `C-x g s c -a c` and typing `git ci -a`.

Re: Oh shit, git (2016)

#214

Post by lmm » Tue, May 14, 2019, 3:55 PM UTC

mehrdadn wrote: post #212

lmm wrote: post #158

Earlier quoted context omitted.

> Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one. Well, one of force-pushing or casually working together had better be a rare exception, otherwise you'll do both at the same time. I'd rather not make force-pushing part of my normal workflow, because casually working together has more value to me. > Without any sort of hint to the guy…

> 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 branch (that they maybe mentioned in standup) without having to interrupt them to tell them you're doing it.

> Second... how is this any different from when the dev just gentle-pushes new commits instead of force-pushing?! You all will still end up having to resolve conflicts just the same when you rebase on top of their branch again... it sounds to me like what you're against is actually rebasing, only disguised as force-pushing.

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.

Re: Oh shit, git (2016)

#215

Post by jolmg » Tue, May 14, 2019, 3:58 PM UTC

aldanor wrote: post #156

drchickensalad wrote: post #137

Earlier quoted context omitted.

What do you feel the UI does better than git add -p? The main concession I have is picking arbitrary files, but I feel like I've achieved 90%+ of what I want with ' .cs' or ' Controller*' etc.

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.

Re: Oh shit, git (2016)

#216

Post by js2 » Tue, May 14, 2019, 4:00 PM UTC

fouronnes3 wrote: post #181

andrewla wrote: post #172

Earlier quoted context omitted.

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

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.

Re: Oh shit, git (2016)

#217

Post by scarejunba » Tue, May 14, 2019, 4:02 PM UTC

tropdrop wrote: post #74

scarejunba wrote: post #18

Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…

Most of OP's post isn't just the basic Git commands - it's super-user features that might help a novice who can do the basic add/commit/push/pull chain but doesn't even know you can revert in Git history, or make new branches. Nothing shameful in someone sharing that knowledge to help a newcomer become a super-user faster.

Nothing against the post. It’s sharing tips. I’m talking about what the other commenters are talking about. The ‘difficulty’.

Reason I posted top-level is that it isn’t an indictment of any specific “this is hard” poster but of the general view. I don’t know when it started becoming this common belief but it’s not true.

Re: Oh shit, git (2016)

#218

Post by darkpuma » Tue, May 14, 2019, 4:03 PM UTC

mehrdadn wrote: post #63

_pmf_ wrote: post #34

I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.

> I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch. I can lose something for you in 2 seconds in git. Have fun e.g. recovering from this: $ git init $ mkdir -p widget && echo…

> "I can lose something for you in 2 seconds _in_ git."

You just demonstrated losing something that was not in git... All you've demonstrated is that neglecting to put something into git is a good way of losing it.

Re: Oh shit, git (2016)

#219

Post by rusk » Tue, May 14, 2019, 4:04 PM UTC

swish_bob wrote: post #182

rusk wrote: post #127

Earlier quoted context omitted.

A "trivial example" is where you demonstrate a concept using a simplified or trivial scenario. It's quite a common term, and I didn't mean it as a put-down. "victime-blaming", "shoot in the face" .. I feel are fairly extreme terms to describe what's happening here. The scenario you've concocted is really only one that could occur where you didn't know what you were doing and Git (or the command line) aren't really th…

It's not a concocted scenario, the cli command in question explicitly has a property that defaults to preventing it from doing what it should do, unless you override the property. Explicitly because it's so destructive when you do it by mistake.

it's concocted because that's something you'd never do.

Re: Oh shit, git (2016)

#220

Post by darkpuma » Tue, May 14, 2019, 4:06 PM UTC

jchw wrote: post #167

darkpuma wrote: post #69

Earlier quoted context omitted.

> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket. The world di…

I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab. I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary? My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tr…

> "You can export data from Github or Gitlab."

And then do what with it, import it into your own bugzilla instance? Have you ever tried that? It's a nightmare.