8 ms·

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what

by dakiol 1y ago

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affected, and jumping easily to such versions). Git conflicts are easily solvable as well with a gui (jetbrain IDEs) via the cli or via something like Sourcetree. Easily, the most used "feature" of git that i use is: - for a given line of code, see all the files that were touched when that line was introduced But I usually do that via the IDE (because to go through dozens of files via cli is a bit of a hassle for me) So, what am I missing? I know jujutsu is much simple (and powerful) than git, but I only have used the "good parts" of git and it has never been a bottleneck... but ofc, you don't know what you don't know.

phyrex 1y ago
Not to be a jerk, but 'hundreds of devs and dozens of MR per day' is not 'huge repos'. Certain functionality only becomes relevant at scale, and what is easy on a repo worth hundreds of megabytes doesn't work anymore once you have terabytes of source code to deal with.
- ffsm8 1y ago
  > terabytes of source code You sure that exists? Git repositories that contain terabytes of source code? I could imagine a repo that is terabytes but has binaries committed or similar... But source code?
  - CBLT 1y ago
    Google's monorepo is in fact terabytes with no binaries. It does stretch the definition of source code though - a lot of that is configuration files (at worst, text protos) which are automatically generated.
  - jeffbee 1y ago
    git could never, but piper at google is way over that figure. Way, way over.
    - phyrex 1y ago
      Microsoft has actually done a lot of work to scale got to large repos
      - p_l 1y ago
        It's why there's special Microsoft Git VFS (a lot like VFS at google that is also referenced in the talk). It was made to make working on Windows source code possible with Git.
  - packetslave 1y ago
    Google had 86TB of sourcecode data in Piper way back in 2016.
    - ffsm8 1y ago
      Dang, that's mind boggling - especially if I keep in mind that a book series like lord of the rings is mere kilobytes if saved as plain text. Having 86 TB of plain text/source code - I can't fathom the scale, honestly Are you absolutely sure there aren't binaries in there (honestly asking, the scale is just insane from my perspective - even the largest book compilation like Anna's isn't approaching that number - if you strip out images ... And that's pretty much all books in circulation - with multiple versions per title)
      - phyrex 1y ago
        Each snapshot of the repo isn't that big, but all the snapshots together, plus all the commit metadata and such, are
  - phyrex 1y ago
    Very sure, i work in one
Craighead 1y ago
[dead]
nh23423fefe 1y ago
I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok
- CuriouslyC 1y ago
  My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.
- bqmjjx0kac 1y ago
  I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.
  - fernandotakai 1y ago
    and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.
- largbae 1y ago
  I've worked with many folks over the years after learning myself... The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes. Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.
- thefifthsetpin 1y ago
  I've long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it. I don't see this anywhere nearly as drastically with other tools.
cosmosgenius 1y ago
one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).
- OkayPhysicist 1y ago
  My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.
  - metabagel 1y ago
    > git init --bare --shared=group This is a very git command.
    - OkayPhysicist 1y ago
      It does exactly what it says on the tin: It calls "git" to "init"ialize a repository, which we don't need a working tree for ("bare") and that it's going to be "shared" with members of the "group".
- vlovich123 1y ago
  I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.
  - steveklabnik 1y ago
    > You can copy a .git folder around just fine. You can do this, but due to file locking, you can corrupt the state if it's shared. jj is specifically designed so that it won't corrupt the repo in this way: https://jj-vcs.github.io/jj/latest/technical/concurrency/ https://jj-vcs.github.io/jj/latest/technical/concurrency/
qudat 1y ago
When you start doing git surgery where there are commit chains that need to stay logical is where JJ starts to shine. If you are constantly editing previous commits and placing code in your working area into those previous commits and rebasing original/main. I also really like that every change is automatically committed. It’s a great mental model once you get used to it.
- elAhmo 1y ago
  Git rebase works fairly well and is somewhat uneventful, unless there are major changes happening. I do hate the experience when one file was remove in my feature branch, but main did a major refactor which affected the original file, so conflicts are a bit awkward then - but other than that, this seems like a fairly clean workflow.
  - stouset 1y ago
    Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.
    - Mic92 1y ago
      git has rerere for this usecase, jj doesn't - you have to find the conflict resolution manually in your history in this case if you made a mistake.
      - steveklabnik 1y ago
        git has rere, but jj doesn't because its equivalent is built in. https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831788 https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... is some discussion about the differences here.
    - 1718627440 1y ago
kubanczyk 1y ago
> So, what am I missing? Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.
- verdverm 1y ago
  What if we don't use git rebase at all? What does jj have to offer us?
  - zhivota 1y ago
    Yes, I don't rebase, I only merge. We squash commits on merge of MR/PR anyway, so there is no value to rebase for us AFAICT. It also removes a ton of gnarly situations you can find yourself in when you mess up a rebase somehow.
  - kubanczyk 1y ago
    But I'm not offering anything to you. Unless there's a budget, in which case I will make that svn fly in circles over your enterprise, dear sir.
kyrra 1y ago
The biggest for me: merge-conflict as first-class state within JJ. I regularly have multiple commits being worked on at a time across different parts of the codebase. If I have to sync to head (or any rebase) and one of my side branches that I'm not actively working on hits a merge conflict, I don't have to deal with it in that moment and get distracted from my work at hand (ie: I don't need to context switch). This is a big productivity win for me. If you want some other points, check out: https://fallthrough.transistor.fm/43#t=0h31m5s https://fallthrough.transistor.fm/43#t=0h31m5s Some points from the episode: * With no separate index vs commit, (everything is just a commit), you don't need different commands and flags to deal with the different concepts, they are all just marked together. In JJ, if you want to stack/stage something, it's just a normal commit (no reason to have different concepts here). * You don't have to name/commit a change at all. Every time you run any JJ command (like `jj log`, or `jj status`), it will snapshot the changes you have. This means that if you want to go work on some other branch, you don't have to go and commit your changes (they auto-commit, and you don't have to write a description immediately), then update to master branch and start working again. * Or you can just `jj split` (https://jj-vcs.github.io/jj/latest/cli-reference/#jj-split https://jj-vcs.github.io/jj/latest/cli-reference/#jj-split), and split a working changeset into 2 separate commits.
- joquarky 1y ago
  This seems similar to the "Local History" feature in JetBrains IDEs.

by dakiol 1y ago

phyrex 1y ago

Not to be a jerk, but 'hundreds of devs and dozens of MR per day' is not 'huge repos'. Certain functionality only becomes relevant at scale, and what is easy on a repo worth hundreds of megabytes doesn't work anymore once you have terabytes of source code to deal with.

ffsm8 1y ago
> terabytes of source code You sure that exists? Git repositories that contain terabytes of source code? I could imagine a repo that is terabytes but has binaries committed or similar... But source code?
- CBLT 1y ago
  Google's monorepo is in fact terabytes with no binaries. It does stretch the definition of source code though - a lot of that is configuration files (at worst, text protos) which are automatically generated.
- jeffbee 1y ago
  git could never, but piper at google is way over that figure. Way, way over.
  - phyrex 1y ago
    Microsoft has actually done a lot of work to scale got to large repos
    - p_l 1y ago
      It's why there's special Microsoft Git VFS (a lot like VFS at google that is also referenced in the talk). It was made to make working on Windows source code possible with Git.
- packetslave 1y ago
  Google had 86TB of sourcecode data in Piper way back in 2016.
  - ffsm8 1y ago
    Dang, that's mind boggling - especially if I keep in mind that a book series like lord of the rings is mere kilobytes if saved as plain text. Having 86 TB of plain text/source code - I can't fathom the scale, honestly Are you absolutely sure there aren't binaries in there (honestly asking, the scale is just insane from my perspective - even the largest book compilation like Anna's isn't approaching that number - if you strip out images ... And that's pretty much all books in circulation - with multiple versions per title)
    - phyrex 1y ago
      Each snapshot of the repo isn't that big, but all the snapshots together, plus all the commit metadata and such, are
- phyrex 1y ago
  Very sure, i work in one

Craighead 1y ago

[dead]

nh23423fefe 1y ago

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

CuriouslyC 1y ago
My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.
bqmjjx0kac 1y ago
I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.
- fernandotakai 1y ago
  and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.
largbae 1y ago
I've worked with many folks over the years after learning myself... The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes. Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.
thefifthsetpin 1y ago
I've long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it. I don't see this anywhere nearly as drastically with other tools.

cosmosgenius 1y ago

one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).

OkayPhysicist 1y ago
My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.
- metabagel 1y ago
  > git init --bare --shared=group This is a very git command.
  - OkayPhysicist 1y ago
    It does exactly what it says on the tin: It calls "git" to "init"ialize a repository, which we don't need a working tree for ("bare") and that it's going to be "shared" with members of the "group".
vlovich123 1y ago
I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.
- steveklabnik 1y ago
  > You can copy a .git folder around just fine. You can do this, but due to file locking, you can corrupt the state if it's shared. jj is specifically designed so that it won't corrupt the repo in this way: https://jj-vcs.github.io/jj/latest/technical/concurrency/ https://jj-vcs.github.io/jj/latest/technical/concurrency/

qudat 1y ago

When you start doing git surgery where there are commit chains that need to stay logical is where JJ starts to shine. If you are constantly editing previous commits and placing code in your working area into those previous commits and rebasing original/main. I also really like that every change is automatically committed. It’s a great mental model once you get used to it.

elAhmo 1y ago
Git rebase works fairly well and is somewhat uneventful, unless there are major changes happening. I do hate the experience when one file was remove in my feature branch, but main did a major refactor which affected the original file, so conflicts are a bit awkward then - but other than that, this seems like a fairly clean workflow.
- stouset 1y ago
  Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.
  - Mic92 1y ago
    git has rerere for this usecase, jj doesn't - you have to find the conflict resolution manually in your history in this case if you made a mistake.
    - steveklabnik 1y ago
      git has rere, but jj doesn't because its equivalent is built in. https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831788 https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... is some discussion about the differences here.
  - 1718627440 1y ago

kubanczyk 1y ago

> So, what am I missing? Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.

verdverm 1y ago
What if we don't use git rebase at all? What does jj have to offer us?
- zhivota 1y ago
  Yes, I don't rebase, I only merge. We squash commits on merge of MR/PR anyway, so there is no value to rebase for us AFAICT. It also removes a ton of gnarly situations you can find yourself in when you mess up a rebase somehow.
- kubanczyk 1y ago
  But I'm not offering anything to you. Unless there's a budget, in which case I will make that svn fly in circles over your enterprise, dear sir.

kyrra 1y ago

The biggest for me: merge-conflict as first-class state within JJ. I regularly have multiple commits being worked on at a time across different parts of the codebase. If I have to sync to head (or any rebase) and one of my side branches that I'm not actively working on hits a merge conflict, I don't have to deal with it in that moment and get distracted from my work at hand (ie: I don't need to context switch). This is a big productivity win for me. If you want some other points, check out: https://fallthrough.transistor.fm/43#t=0h31m5s https://fallthrough.transistor.fm/43#t=0h31m5s Some points from the episode: * With no separate index vs commit, (everything is just a commit), you don't need different commands and flags to deal with the different concepts, they are all just marked together. In JJ, if you want to stack/stage something, it's just a normal commit (no reason to have different concepts here). * You don't have to name/commit a change at all. Every time you run any JJ command (like `jj log`, or `jj status`), it will snapshot the changes you have. This means that if you want to go work on some other branch, you don't have to go and commit your changes (they auto-commit, and you don't have to write a description immediately), then update to master branch and start working again. * Or you can just `jj split` (https://jj-vcs.github.io/jj/latest/cli-reference/#jj-split https://jj-vcs.github.io/jj/latest/cli-reference/#jj-split), and split a working changeset into 2 separate commits.

joquarky 1y ago
This seems similar to the "Local History" feature in JetBrains IDEs.