High-Level Problems with Git and How to Fix Them • Hacker News Board

Re: High-Level Problems with Git and How to Fix Them

#211

Post by Certhas » Tue, Dec 12, 2017, 4:18 PM UTC

CSMastermind wrote: post #193

taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

On source control anti-pattern I've run into is people thinking a commit is a 'save'. It's not. A commit should move you from one working state of your code to another. Compare that to saving my files which I do compulsively every 5 minutes or so regardless of the state the file is in.

So then why do I have the ability to stage individual lines of changes, creating commits that do not reflect a state that my system ever had, ergo was never tested or compiled in, thus can not be known to be working?

Also, what if I use a remote to synchronize between different machines I work on on the same code base?

Re: High-Level Problems with Git and How to Fix Them

#212

Post by fulafel » Tue, Dec 12, 2017, 4:20 PM UTC

nhaehnle wrote: post #74

jcranmer wrote: post #36

Earlier quoted context omitted.

Coming from someone who learned hg well before git, and who's now being more or less forced to use git long after developing comfortable hg workflows, the staging area feels like a half-baked implementation of what it's supposed to be doing. I'm used to thinking of commits as atomic commits--roughly, each commit is the smallest change that atomically makes sense. So you should be able to use the staging area to build…

I think people generally get side-tracked by focusing too much on the staging area. It's a red herring in my opinion. I barely notice that it's there, and I do the crafting-the-public-changelog thing on an almost daily basis. I recommend learning about the combination of `git gui` (including its amend option), `git rebase -i`, and `git commit --squash=/--fixup=` (and don't forget to set `git config --global rebase.au…

Resorting to rebase is a pretty heavy price to pay though.

Re: High-Level Problems with Git and How to Fix Them

#213

Post by kazinator » Tue, Dec 12, 2017, 4:23 PM UTC

tarnacious_ wrote: post #208

majewsky wrote: post #117

Earlier quoted context omitted.

> I try to keep my git workflow simple. > git rebase Yeah... :)

I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch. I find this simpler and cleaner than introducing a series of merge commits in my local branch.

I believe a fork of git should be made which entirely eliminates the concept of multiple parents from the representation of a commit. In the same breath, it would drop support for git merge and git log --graph.

Re: High-Level Problems with Git and How to Fix Them

#214

Post by tome » Tue, Dec 12, 2017, 4:30 PM UTC

masklinn wrote: post #170

therein wrote: post #95

Earlier quoted context omitted.

Same here, I actually find `git add -p` to be very useful.

commit also has a -p flag.

Oh wow. No need for me to use git add ever again!

EDIT: I suppose I have to use it to add new files :)

Re: High-Level Problems with Git and How to Fix Them

#215

Post by saulrh » Tue, Dec 12, 2017, 4:31 PM UTC

A lot of this I can't really speak to, and for some things I can see the point - I use stashes to follow almost exactly the no-staging-area workflow - but in other places this suffers at least a little from being a generalization from one example.

In particular, named branches significantly reduce friction in my day-to-day work. I often have PRs for multiple smallish tickets in flight simultaneously, working on the code for each ticket while I wait for review on the others. This means that branches generally live for about eight hours and I care about maybe three of them at any given time, a different set every day. Invocations are stable, named refs fit in cache and my CLI does fuzzy LRU to improve that further, and I can bounce to the current code for a given ticket/PR at almost the speed of thought. By contrast, the "view the log and copy-paste a hash" workflow makes me cringe - I have to inspect the log every time I want to bounce to the code for a PR, and the invocation to go to a PR changes four times a day? I agree that that that makes sense if you have thirty long-running PRs open at any given time and you don't have brainpower to remember branches anyway, and that's very reasonable for a big open-source project, but that's not all use cases.

Re: High-Level Problems with Git and How to Fix Them

#216

Post by uiri » Tue, Dec 12, 2017, 4:35 PM UTC

masklinn wrote: post #169

uiri wrote: post #75

Earlier quoted context omitted.

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit. I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out. The staging area is a co…

> I realize that I've actually made three separate subchanges so I do partial stages to create each commit. You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash

That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Splitting a single big commit into multiple smaller commits with an interactive rebase is dependent upon the staging area too.

Re: High-Level Problems with Git and How to Fix Them

#217

Post by masklinn » Tue, Dec 12, 2017, 4:38 PM UTC

uiri wrote: post #216

masklinn wrote: post #169

Earlier quoted context omitted.

> I realize that I've actually made three separate subchanges so I do partial stages to create each commit. You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash

That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Splitting a single big commit into multiple smaller commits with an interactive rebase is dependent upon the staging area too.

> That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit.

Errr… no you're not. `commit -p` exists.

Re: High-Level Problems with Git and How to Fix Them

#218

Post by masklinn » Tue, Dec 12, 2017, 4:39 PM UTC

littlestymaar wrote: post #191

dboreham wrote: post #179

Earlier quoted context omitted.

Because git dies not have good documentation. Perhaps that's unfair to the documentation in that it does a good job of detailing commands and their options, but is urinating into a hurricane as far as trying to convey any notion of conceptual integrity for a piece of software that has none.

What about https://git-scm.com/doc ? I wish all the software I use had a documentation half as good as this one.

I guess low expectations are still expectations?

Re: High-Level Problems with Git and How to Fix Them

#219

Post by bluetwo » Tue, Dec 12, 2017, 4:44 PM UTC

TorKlingberg wrote: post #183

bluetwo wrote: post #2

I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.

I have do work with svn quite a lot. It's simpler that git in some ways, but things like merging branches just does not work at all.

Yes, I've seen that pain, but my workflow rarely needs branch merging, so I've avoided that issue.

Re: High-Level Problems with Git and How to Fix Them

#220

Post by kazinator » Tue, Dec 12, 2017, 4:51 PM UTC

tarnacious_ wrote: post #208

majewsky wrote: post #117

Earlier quoted context omitted.

> I try to keep my git workflow simple. > git rebase Yeah... :)

I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch. I find this simpler and cleaner than introducing a series of merge commits in my local branch.

A merge should always be done by rebasing the to-be-merged material onto the target-of-merge branch. This way not only is the history linear (and thus understandable, rather than some indecipherable "git log --graph" ball of yarn) but the individual changes are properly re-worked to fit into the target.

When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.