Supercharging the Git Commit Graph • Hacker News Board

Re: Supercharging the Git Commit Graph

#61

Post by claytonjy » Thu, Jun 28, 2018, 5:20 PM UTC

I wonder if any of these folks will have a hand in improving the Github commit graph, now that Microsoft owns it?

As great as Github is, I've never understood why they still have such a hard-to-read, horizontal commit graph while competitors like Stash/bitbucket/gitlab have all had beautiful vertical graphs (like shown in this article) for as long as I can remember. I think this is especially valuable for newbies who are less inclined to get similar viz at the command line, but still useful for vets when they (inevitably) end up in weird branch situations.

Re: Supercharging the Git Commit Graph

#62

Post by yebyen » Thu, Jun 28, 2018, 5:58 PM UTC

WorldMaker wrote: post #59

yebyen wrote: post #58

One of the best things I ever did for my git usage was installing this ridiculous thing in my .gitconfig aliases: [alias] l = log --date-order --date=iso --graph --full-history --all --pretty=format:'%x08%x09%C(red)%h %C(cyan)%ad%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08 %C(bold blue)%aN%C(reset)%C(bold yellow)%d %C(reset)%s' It lets me type 'git l' and get this kind of commit graph: * 8264cf2a 2018…

I had a similar alias for a while at a past job, but realized I was just using `gitk` anyway, and `gitk` is installed by default everywhere and doesn't need an alias setup, so it's also especially easier to teach to junior developers. Also, I don't encourage rebasing, especially to junior developers. I realize everyone has different preferences, but a messy graph is useful and there are other tools like `git log --fi…

Yes! I agree with you mostly, except that we try to keep from having junior developers for too long. Nobody is really a junior developer, and everyone should get a turn as release manager. The main benefit of this is that people can see directly how their work style impacts the release engineering process, if they do know exactly what that process involves and actually get a turn at it. (You have to stub your own toe in order to know how bad it hurts.)

Our team is actually really small, and we like to make sure everyone knows about the hassles involved in putting together a release and doing a complete code review when it's needed. The main reason I encourage rebasing is because it helps avoid a messy graph, and a messy graph makes it immediately much harder to do a rebase across any number of merges, or any non-trivial span of time.

So in other words, I like to selfishly expect the other developers on my team to do rebases at the appropriate times, in order to preserve my own capability to easily do rebases when needed. (We also learned last week that git rebase has a --preserve-merges option that I feel foolish to not have known about sooner. We've wiped out so many merge commits unnecessarily.)

We treat the master branch as carved in stone like anyone should, but other branches should clearly flow their merges only one way (features into releases, or features into environments), and if a branch hasn't actually been included in a release tag, it's considered fair game for rebasing. It helps us to prevent our three developers' sometimes too many concurrent trains of thought from resulting in equally too many confusing merges, or an intractable number of HEADs to manage and organize into releases.

One of the places we struggle is that we're not all-the-way onboard with CI/CD processes, but we do the best we can so that whenever support for that kind of thing materializes, we will mostly not need to change our processes at all and can obtain the benefits of that kind of tooling as quickly as possible.

Re: Supercharging the Git Commit Graph

#63

Post by jdbernard » Thu, Jun 28, 2018, 5:59 PM UTC

gmueckl wrote: post #56

nemetroid wrote: post #53

Earlier quoted context omitted.

The staging area is not necessary for your particular workflows. I found Mercurial horrible to work with precisely due to the lack of a staging step.

Your dislike of mercurial is noted. But that does not change the fact that the staging area is objectively confusing and hindering users (don't have a link to the study here that looked into it).

Objectivity is not something you can just claim. There must be some objective measure. You mention a study, but that's not sufficient without an actual reference.

Re: Supercharging the Git Commit Graph

#64

Post by a-dub » Thu, Jun 28, 2018, 6:01 PM UTC

pdpi wrote: post #22

01100011 wrote: post #11

Earlier quoted context omitted.

Kinda surprising. I know everyone seems to love git these days, but I find it's really better suited towards distributed and/or smaller projects. After feeling the pain of a megarepo system at work, I'm pushing to switch to a monorepo(well, like 4 repos instead of 200). git sort of sucks for monorepos. Also, even after learning a fair amount of git, I still find I spend a noticeable amount of time dealing with it. I…

> git sort of sucks for monorepos. Microsoft works around several of the issues there by using GVFS. Also, at Microsoft scale, everything "sort of sucks", there's just no silver bullets. You take one of the least bad options and put all the effort you can towards making it work as well as you can.

No. Everything only "sort of sucks" at "Microsoft scale" if you're willing to blame it on "scale."

At "Microsoft scale," you have the resources to purpose build anything you need from scratch for any scale you're working at... therefore if anything "sort of sucks" it's because:

a) It's not worth the money/resources. (The "let it suck" approach)

or

b) Nobody cares (The "acceptance that we suck, at 'scale'" approach)

Re: Supercharging the Git Commit Graph

#65

Post by jdbernard » Thu, Jun 28, 2018, 6:02 PM UTC

gmueckl wrote: post #48

adrianN wrote: post #29

Earlier quoted context omitted.

The additional steps enable workflows that weren't possible before, so it's a tradeoff.

This argument is just wrong. I have fewer steps with less mental load on other VCS implementations, yet I can get better workflows at the same time with zero loss of functionality. Prime example: the git staging area/cache/index needs to die. Git would be half as difficult to use with fewer code shredding surprises. This abomination is a prime example of badly exposed internal structure. Everything feature that is cr…

As a counter-anecdote, the staging area/cache/index is one of the main reasons I use git. When they were first released Mercurial was my initial choice. It was certainly more friendly to a beginner. But I quickly moved to using git and the staging area/cache/index you mention was one of the main reasons.

Re: Supercharging the Git Commit Graph

#66

Post by linkmotif » Thu, Jun 28, 2018, 7:09 PM UTC

WorldMaker wrote: post #59

yebyen wrote: post #58

One of the best things I ever did for my git usage was installing this ridiculous thing in my .gitconfig aliases: [alias] l = log --date-order --date=iso --graph --full-history --all --pretty=format:'%x08%x09%C(red)%h %C(cyan)%ad%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08%x08 %C(bold blue)%aN%C(reset)%C(bold yellow)%d %C(reset)%s' It lets me type 'git l' and get this kind of commit graph: * 8264cf2a 2018…

I had a similar alias for a while at a past job, but realized I was just using `gitk` anyway, and `gitk` is installed by default everywhere and doesn't need an alias setup, so it's also especially easier to teach to junior developers. Also, I don't encourage rebasing, especially to junior developers. I realize everyone has different preferences, but a messy graph is useful and there are other tools like `git log --fi…

Rebasing is fundamental to a proficient local workflow. Interactive rebasing with git rebase -p lets you craft and recraft your commits easily until they are readable and tell a story. The sooner a person can rebase, the sooner they can use Git. It’s not really possibly to proficiently or pleasantly use Git without rebasing.

Re: Supercharging the Git Commit Graph

#67

Post by WorldMaker » Thu, Jun 28, 2018, 7:22 PM UTC

yebyen wrote: post #62

WorldMaker wrote: post #59

Earlier quoted context omitted.

I had a similar alias for a while at a past job, but realized I was just using `gitk` anyway, and `gitk` is installed by default everywhere and doesn't need an alias setup, so it's also especially easier to teach to junior developers. Also, I don't encourage rebasing, especially to junior developers. I realize everyone has different preferences, but a messy graph is useful and there are other tools like `git log --fi…

Yes! I agree with you mostly, except that we try to keep from having junior developers for too long. Nobody is really a junior developer, and everyone should get a turn as release manager. The main benefit of this is that people can see directly how their work style impacts the release engineering process, if they do know exactly what that process involves and actually get a turn at it. (You have to stub your own toe…

> other branches should clearly flow their merges only one way

I tend to disagree on this as well. The best person to merge a conflict is the developer creating the conflict in the first place, as soon or nearly as soon as they create the conflict, because they are most likely to know why the conflict exists in the first place. "Merge early, merge often."

Delaying "reverse" merges until the last possible second means you often don't have the integration expertise needed without research involved, even if it was "you" that introduced the conflict you may have moved on to other problems since and not recall why you did something one way or another, or which bits are important to integrate.

Delaying those merges as rebases I feel is even worse, because not only do you not have the resources to know why an integration needs to be made, you also aren't recording a history of the merge conflicts you saw in the rebase such that you can easily revisit the integration if you made an integration mistake (which does happen, because we are, after all, only human).

My advice tends to be to use a good PR system of some sort that makes your proper, code reviewed "forward" merges clear and obvious, and then don't worry about a mess of other merges "underneath" that top-level of strong PR merges. (Hence the key suggestion is that `git log --first-parent` is your best friend if you want a "clean" view of the DAG. It gives you a linear list of just your PR merges in master, or branch work and PR merges to that branch in any other branch.) Also, yes, CI/CD are really good ideas.

Re: Supercharging the Git Commit Graph

#68

Post by WorldMaker » Thu, Jun 28, 2018, 7:27 PM UTC

linkmotif wrote: post #66

WorldMaker wrote: post #59

Earlier quoted context omitted.

I had a similar alias for a while at a past job, but realized I was just using `gitk` anyway, and `gitk` is installed by default everywhere and doesn't need an alias setup, so it's also especially easier to teach to junior developers. Also, I don't encourage rebasing, especially to junior developers. I realize everyone has different preferences, but a messy graph is useful and there are other tools like `git log --fi…

Rebasing is fundamental to a proficient local workflow. Interactive rebasing with git rebase -p lets you craft and recraft your commits easily until they are readable and tell a story. The sooner a person can rebase, the sooner they can use Git. It’s not really possibly to proficiently or pleasantly use Git without rebasing.

I very strongly disagree with that. I'd rather someone be proficient with the staging index, and maybe even git stash, than rebasing. Maybe, if they are feeling fancy, `git add --interactive`, `git add --patch`, and/or `git commit --amend`.

Rebasing is a fascinating footgun. I'd rather a messy story that includes details of how someone screwed up, then fixed their mistakes, than an entire branch I need to cherry pick in a hazmat suit because a developer rebased the wrong thing.

Re: Supercharging the Git Commit Graph

#69

Post by rakoo » Thu, Jun 28, 2018, 7:34 PM UTC

geezerjay wrote: post #55

rakoo wrote: post #41

Earlier quoted context omitted.

This is about having a single, unified interface for all operations. This is all explained in great details by SQLite itself at https://sqlite.org/appfileformat.html

> This is about having a single, unified interface for all operations. Unless you're intending to run joins on git data, were exactlty do you see any fundamental difference between running CRUD operations via an SQL interface or just importing/exporting a file?

That's the whole point: git data is highly relational. Retrieving a commit alone is completely useless to you, just as retrieving any of the core objects alone is. Every operation you do requires retrieving multiple, interconnected objects... which SQL excels at.

Re: Supercharging the Git Commit Graph

#70

Post by yebyen » Thu, Jun 28, 2018, 7:35 PM UTC

WorldMaker wrote: post #67

yebyen wrote: post #62

Earlier quoted context omitted.

Yes! I agree with you mostly, except that we try to keep from having junior developers for too long. Nobody is really a junior developer, and everyone should get a turn as release manager. The main benefit of this is that people can see directly how their work style impacts the release engineering process, if they do know exactly what that process involves and actually get a turn at it. (You have to stub your own toe…

> other branches should clearly flow their merges only one way I tend to disagree on this as well. The best person to merge a conflict is the developer creating the conflict in the first place, as soon or nearly as soon as they create the conflict, because they are most likely to know why the conflict exists in the first place. "Merge early, merge often." Delaying "reverse" merges until the last possible second means…

> you also aren't recording a history of the merge conflicts you saw in the rebase

This is a good point. Mistakes are made during merge conflict resolution. But if you are tracking your upstream when you develop a long-lived feature branch, and rebasing when there are changes to the base, and actually comparing your rebased feature branches to the version that you had before you force push over the old remote version, then the only thing you really need to track is "does my diff still look like the change I intended to make."

The most valuable skill we are learning from Git is how to avoid merge conflicts altogether, and it tends to be more a human problem than a technological issue. (You don't avoid merge conflicts with some special commit strategy, you do it by ensuring that two people are not actively changing the same part of the codebase unless it's absolutely necessary.)