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

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

#241

Post by kazinator » Tue, Dec 12, 2017, 6:38 PM UTC

rbehrends wrote: post #235

zegl wrote: post #129

Earlier quoted context omitted.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.

History is only "cleaner" because Git in its default configuration only throws the raw version graph at you and fails to visualize it in a readable fashion. With a properly structured visualization, such as Bazaar's hierarchical logs, merging is not just as clean, it actually carries more information. In hierarchical logs, a merge commit stands for the series of commits that are being merged. You can then unfold such…

> it actually carries more information

None of that information is too relevant. If you have the commits individually cherry picked in your stream, that's most of the info you ever need about those commits. There is some earlier version of those commits in a different stream, where they look different. Usually, who cares.

The way to track that is some sort of additional meta-data. An example of this is the Gerrit Change-ID.

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

#242

Post by kazinator » Tue, Dec 12, 2017, 6:44 PM UTC

saltedmd5 wrote: post #144

zegl wrote: post #129

Earlier quoted context omitted.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.

Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations…

That is not correct; rebase per se doesn't rewrite history.

Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history.

The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history.

If some developers are collaborating on a feature which is on a branch, they could agree from time to time to rebase that branch to a newer mainline.

Whether or not that is done by a history rewrite simply hinges on whether the same branch name is used for the rebased branch or not. The rebase is what it is: if you plant that rewrite as the original branch name, then you have a non-fastforward change. If a new branch name is made, then it isn't a rewrite.

Merging a feature branch onto a trunk can always be done in a fastforward way using rebase/cherry-pick.

Rebasing is provably simpler than merge. Merge depends on complications in the git object representation which could be removed while rebase remains what it is. If you only ever rebase, you never see a commit with multiple parents; the feature is superfluous and turns git histories into hairballs.

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

#243

Post by mikestew » Tue, Dec 12, 2017, 6:58 PM UTC

golergka wrote: post #149

jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. I have used git for a long time, but never arrived at such a state, apart from when I was converting existing SVN repo to git (where startin…

How did you manage to do it

Same way everyone else manages it, including myself: abject ignorance. You and I (as a now more experienced git user) know that it is extremely unlikely to actually be in a state where blowing away the repository is necessary. Like you, I can’t think of how one would pull that off. That’s why I tell less experienced users “if you’ve committed, even just locally, you can’t lose your work without really trying. If you get in trouble, don’t use the ‘-f’ switch, and come get me, we’ll get it sorted out.

But that was not me nine years ago as I blew away the repository again because I got in a confused state (me, not git). And be honest, that was you nine years ago, too, before you wrapped your head around git.

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

#244

Post by maccam94 » Tue, Dec 12, 2017, 7:14 PM UTC

mmebane wrote: post #171

maccam94 wrote: post #125

Earlier quoted context omitted.

Some useful commands I'd use in scenarios like this are: git add -p # select what to add to the staging area git reset -p # deselect chunks that I decided I don't want anymore git stash # saves your working state in a temporary commit (not in your branch) git stash pop # restores the working state from the last git stash command and drops the temporary commit git rebase -i $start_point # where $start_point is either…

> I do wish git had some notion of sub-commits with their own messages You could use the "fast-forward with merge commit" style. [1] Then you can treat the commits from the branch as sub-commits, and the merge commit as the parent commit. [1]: https://stackoverflow.com/questions/15631890/how-to-achieve-...

Interesting! That's almost what I want, except here's the specific behavior I want to achieve:

  A clean git log view that shows only meta-commits
  Git blame shows both the meta-commit and the sub-commit for each line

I suppose I could get creative by enforcing that tags be embedded in commit messages and then filtering them in the log view, but it would be better if it was standard.

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

#245

Post by maccam94 » Tue, Dec 12, 2017, 7:18 PM UTC

wutbrodo wrote: post #225

maccam94 wrote: post #125

Earlier quoted context omitted.

Some useful commands I'd use in scenarios like this are: git add -p # select what to add to the staging area git reset -p # deselect chunks that I decided I don't want anymore git stash # saves your working state in a temporary commit (not in your branch) git stash pop # restores the working state from the last git stash command and drops the temporary commit git rebase -i $start_point # where $start_point is either…

> I do wish git had some notion of sub-commits with their own messages, and a better UX for cleaning up a set of commits before merging them. Does rebase -i handle this adequately or am I misunderstanding what you're describing here? My workflow sounds like exactly what you're saying here, where "subcommits" are my development commits and the UX is the rebase -i editor.

See my reply to mmebane about sub-commits. Re: UX, specifically the patch editor (git add/reset -p) is sometimes difficult to use. For example, I've had issues with changes that happen around empty lines refusing to apply for unknown reasons.

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

#246

Post by carussell » Tue, Dec 12, 2017, 7:18 PM UTC

txdv wrote: post #67

carussell wrote: post #35

Earlier quoted context omitted.

Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…

If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.

I do consider the LKML-centric use case. (Often—probably more often than most.) No such realization is setting in. How about you elaborate?

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

#247

Post by mmebane » Tue, Dec 12, 2017, 7:33 PM UTC

maccam94 wrote: post #244

mmebane wrote: post #171

Earlier quoted context omitted.

> I do wish git had some notion of sub-commits with their own messages You could use the "fast-forward with merge commit" style. [1] Then you can treat the commits from the branch as sub-commits, and the merge commit as the parent commit. [1]: https://stackoverflow.com/questions/15631890/how-to-achieve-...

Interesting! That's almost what I want, except here's the specific behavior I want to achieve: A clean git log view that shows only meta-commits Git blame shows both the meta-commit and the sub-commit for each line I suppose I could get creative by enforcing that tags be embedded in commit messages and then filtering them in the log view, but it would be better if it was standard.

You can show only merge commits with

    git log --merges

However, I don't know if there's any way to achieve that with git blame, and not all tools may offer that kind of log view.

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

#248

Post by acdha » Tue, Dec 12, 2017, 7:38 PM UTC

fulafel wrote: post #212

nhaehnle wrote: post #74

Earlier quoted context omitted.

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.

How so? It's very fast and you can abort if you do it wrong.

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

#249

Post by dwheeler » Tue, Dec 12, 2017, 7:45 PM UTC

tomxor wrote: post #156

I like what this guy has to say so far, but it's a bit surprising that someone with his knowledge got this wrong: > The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached I dislike the mess of crappy synonyms too, but git diff --staged is already an alias, in fact it's the primary way I di…

One small improvement would to make sure that all the options with "--cached" also have "--staged", and make sure that all the documentation uses term "staging" (deprecating "index" and "cached"). The git UI is historically terrible, but it's gotten a little better over time... it could definitely be improved further with a little more effort.

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

#250

Post by geezerjay » Tue, Dec 12, 2017, 8:03 PM UTC

jhanschoo wrote: post #135

qznc wrote: post #116

Earlier quoted context omitted.

> In a decade of using Mercurial > I never really used git all that much Does not sound like a fair comparison ;)

It's a valid comparison for his point that Mercurial is much more reliable for his workflows than git.

> It's a valid comparison for his point that Mercurial is much more reliable for his workflows than git

To me it reads as a warning that Mercurial repos are prone to being screwed up even if the user has over a decade of experience avoiding Mercurial's traps while with Git only bold inexperienced users can screw up repos in a similar matter.