Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supercharging the Git Commit Graph

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Supercharging the Git Commit Graph

#51

Post by rootlocus »

MaxBarraclough wrote: post #50
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…

> I find it's really better suited towards distributed and/or smaller projects But it was specifically designed for the Linux kernel.

Which is highly distributed with multiple contributors, maintainers, etc. The "monolithic" aspect is just one glorified repo: Linus's

Re: Supercharging the Git Commit Graph

#52

Post by LyalinDotCom »

LyalinDotCom wrote: post #5
xkcdefgh wrote: post #4

Earlier quoted context omitted.

Yeah, i believe it was a huge effort some time ago to migrate windows to git

Yep we use Git to build windows! here is the story that was told about our efforts. https://arstechnica.com/gadgets/2018/03/building-windows-4-m...

oh and also we did an interview with the DevOps lead for both source control and build system around Windows, so check that out too if you want: https://www.youtube.com/watch?v=nsXiKLLaH4M

Re: Supercharging the Git Commit Graph

#53

Post by nemetroid »

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…

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.

Re: Supercharging the Git Commit Graph

#54

Post by erik_seaberg »

nemetroid wrote: post #53
gmueckl wrote: post #48

Earlier quoted context omitted.

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…

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.

Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.

Re: Supercharging the Git Commit Graph

#55

Post by geezerjay »

rakoo wrote: post #41
rhencke wrote: post #40

Earlier quoted context omitted.

I love SQLite, and Fossil is very cool, but I don't see the fundamental difference between Git adding another file in the .git directory, and Fossil adding another table or index in the SQLite database.

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?

Re: Supercharging the Git Commit Graph

#56

Post by gmueckl »

nemetroid wrote: post #53
gmueckl wrote: post #48

Earlier quoted context omitted.

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…

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).

Re: Supercharging the Git Commit Graph

#57

Post by WorldMaker »

rakoo wrote: post #49
kyberias wrote: post #45

Earlier quoted context omitted.

I think you don't fully understand what you are proposing. The storage engine (file system or SQLite) has little to do with git graph algorithm performance. SQLite doesn't magically "display a graph quickly".

What I'm saying is, the iteration step from "existing dataset" (what we have today) to "faster data traversal" (what the article proposes) is a custom file with a custom format on one side, and the appropriate query/index on the other side; one is definitely more understandable, portable and maintainable than the other.

Except that SQL has never had great DAG data structures, queries, nor indexes. You can model a DAG in a relational database, and you can non-standard SQL extensions to get some decent but not great recursive queries to do some okay semi-poorly indexed graph work, but having maintained databases like that at various times that all gets to be just as much a "custom file with a custom format" as dependent on database version and business logic as anything git is doing here.

If there was a stronger graph database store and graph query language for consideration than SQL you might be on to something. SQL isn't a great fit here either.

Re: Supercharging the Git Commit Graph

#58

Post by yebyen »

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-06-28 yebyen (origin/dev, dev) ...
    |\
    | *     df6e4c49 blabla commit messages
    | *     195d8924 commit messages
    |/
    | *     96e74a5c (branch-label) commit message
    | |\
    | | *   b2786c07 blabla
    | | *   85721288 blabla
This is semi-related but not nearly as interesting from a technical perspective. But it's one of the missing features in Git, to visually help people understand why it's helpful to rebase occasionally, and keep your commit history clean.

I think I found it here[1]

[1]: https://stackoverflow.com/a/16735971/661659

Re: Supercharging the Git Commit Graph

#59

Post by WorldMaker »

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 --first-parent` for getting "clean" baselines from the graph. The great thing about using a graph in the first place is there are a lot of traversal options and you don't have to micromanage where the trees are to still see the forest.

Re: Supercharging the Git Commit Graph

#60

Post by DaiPlusPlus »

erik_seaberg wrote: post #54
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.

Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.

> Untested commits should never exist

Says who? Branches and commits are cheap, it's how we can undo ourselves and freely experiment.

I agree that untested commits into a publishing/release branch shouldn't exist: all commits there should be merges from dev branches, but to say every commit should be tested is utter bollocks and denies us the advantages of cheap branching and commits.

Post reply on HN