5 ms·

Aside: I am want to know people who use anything other than the very basic git checkout, fetch, push, merge, rebase, stash, status commit, reset. What are you

Aside: I am want to know people who use anything other than the very basic git checkout, fetch, push, merge, rebase, stash, status commit, reset. What are you doing? I think I have used cherrypick once? Generally I open two copies of the same repo, copy paste the code I need and commit as a new commit - the former invariably ends up as a whole mess which takes longer than copy paste efforts of the “feature” I wanted to retrieve. This is a genuine question not rage bait. I have been in the game for 15 years. Surely there are mega complex things using git internals / obscure commands to run analytics in CI systems or hosted git solutions. But I want to know what you are doing in your workflow that requires “more” of git.

rat87 2y ago
Well for one thing even doing basic commands its easy to mess up if you don't understand it. Even people who are better at git still often don't know that much about it. I was the git person at our last job and Im not that good. Besides push, merge, rebase, stash, status commit I've used submodules and git-svn(both for converting a repo to git and for having a local copy for my own use). Rebasing when you run into conflicts is annoying, I much prefer to have intellij to guide me through the rebase then using the commandline. Submodule are annoying but I assume part of that is inevitable when you have two repos linked like that, some of it is probably gits fault.
ImHereToVote 2y ago
I second the copy paste solution. I don't understand devs that cherrypick.
- fragmede 2y ago
  when setup right, cherry-pick is simply more efficient.
  - ykonstant 2y ago
    How do you set it up right?
    - fragmede 2y ago
      By making commits that can be cherry-picked. If one commit adds five different things then you can't add just one of those five things with git cherry-pick. Then instead of making a second copy and then pasting the code over and commiting it, it's just git cherry-pick and you're done.
      - ImHereToVote 2y ago
        So trust other devs. Got it.
        fragmede 2y ago
        Yeah, I know that other people suck and dealing with them is difficult, but this is why there's code review and a company culture. Those soft skills that you think you don't need because you're so smart and everyone else is dumb? turns out they're the smart ones and you're the dumb one for not working on those skills in addition to the stuff you're awesome at because those skills will get them (and you) further in life than any others.
- ghosty141 2y ago
  There is a semantic difference. If you just copy paste code from the master branch to a release branch it might be unclear where that code came from. A cherry pick makes it clear that you ported a bugfix from the master to the release branch. You obviously don't need many git features if you are working alone or with only 1-2 team members but the bigger the organization the more complex the git workflow becomes.
barrkel 2y ago
The most common thing that causes me pain in git today is asynchronous review of a chain of commits. If you work in a commit to trunk model, every commit needs to build and pass tests and be a self-contained unit of work, ideally small, so it's quick to review. Since you don't want to be held up by the speed of review, you make more commits, each one building on the last, to form a chain. The chain of commits is reviewed, each commit separately, and they're merged in order as you go, in one big bunch at the end, or some mix. That doesn't really matter. The problem is addressing review comments on early commits in a chain. With git, you need to stash your work or make a WIP commit, jump to the right commit, made edits, then rebase the rest of your chain on that commit. This requires fiddly copying of commit hashes or a proliferation of branch names. If you have a tree of commits instead of a linear chain, it's even more work. Ideally, when looking at all the comments on your chain of commits, you just make local edits and run a magic command which amends every commit each edit "belongs" to, automatically - this is what `hg absorb` does in mercurial. (All of the above shouldn't be mistaken for saying jj makes this easier to do. I don't know if it does. I just know that git is painful for this workflow and I'd like something better.)
- fragmede 2y ago
  > This requires fiddly copying of commit hashes git rebase -i ?
- maltelau 2y ago
  Would git commit --fixup <sha> and git rebase -i --autosquash <previous-sha> do what you need? Random blog link explaining it: [1] [1] https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html https://fle.github.io/git-tip-keep-your-branch-clean-with-fi...
fragmede 2y ago
You probably also use clone, init, show, log, reset, checkout, add, rm, diff, and remote. git archive's more obscure, as is ls-files and cat-file. git worktree's useful; might want to take a look at that one. bisect is another one that comes in handy. There's a lot more to be gotten from git, but if you can't get cherry-pick to work for you, I'd start there. (which, if you open two copies of the same repo and copy and paste code, you're doing it wrong) Be able to split a commit into multiple smaller commits. Be able to split a single commits into separate hunks, be able to rebase -i and squash them into something that looks good. You should be able to move between branches effortlessly and cherry-pick commits onto different branches while working. Using git well means making it work for you instead of fighting it. Locally, I do "git commit -a -m wip" incessantly and messily, but it all gets squashed and picked back apart before it goes up for review.
- pinoy420 2y ago
  > if you open two copies of the same repo and copy and paste code, you're doing it wrong It has worked for 10+ years - is that really doing it wrong, or just doing it in a way different from you. > into something that looks good Is this a requirement? Or just out of being particular? >squashed […] before review Is deleting (obfuscating) the history of your approach (chain of thought) important to you? The reviewer will review the last commit anyway (always) so is this necessary other than subjective neatness? This can be squashed at the point it is merged It appears you are very efficient at git. I am having difficulty understanding the real utility of much you described. I wonder if it is a justification for finding the fun in using more uncommon features of git, or for “neatness”? Which is fine.
  - fragmede 2y ago
    It's about making your tools work for you, not against you. If you've got something that works for you and you don't want to change it, don't. But when the tool you're using has a feature specifically designed for copying its kind of things from one place to another, and then you choose not to use that feature, and choose to copy things from one place to another using a different but more familiar system, then yes I'm going to say you're doing it wrong. Now, that's just my opinion as a random Internet someone who doesn't know you, your workflow, your use-case, so it's entirely possible I'm wrong about you being wrong. But without clarifying details, yes, that's wrong. Now, wrong things still work, and fundamentally things need to work, so just because it's wrong doesn't mean it doesn't work. > Is deleting (obfuscating) the history of your approach (chain of thought) important to you? It's essential. I do dumb things but I don't like looking dumb, so no one needs to know that I spent however many hours going off in the wrong direction before figuring out what I'm really trying to do. The reviewer only sees what I show them, and they'll never see the abandoned commits and branches on my laptop. They don't need to, it's a waste of their time. Treat your reviewer's time as the most valuable thing in the world and don't waste it by having them trawl through your mess. > I am having difficulty understanding the real utility of much you described. The real utility, the thing that got me to invest the time into learning git so it works for me, is that when things stop working, I can rewind to when things were working, do a git diff, and it highlights the change which would have taken me hours to find without git. There's more utility elsewhere, but that's the singular thing that convinced me to invest the time to get good at git. What's the oldest code you've written? Go back to then and try and tweak a feature. Being neat about git is because that'll happen to you at some point, and future you, two or twenty years from now, will either thank you, or curse you for your commit message.
kartoffelmos 2y ago
It was after discovering/learning `git bisect`, I started really understanding the value of using Git "properly". Being able to pinpoint in which commit an error was introduced is really invaluable. I `git cherry-pick` all the time when I graft a PR. Sometimes I drift and start doing something unrelated to a task, and I often want to push it as a separate thing. Cherry picking it into another branch is most often how I achieve this. This does mean that I have to be structured in how I construct commits while I work though. Drafting, crafting, fixing and maintaining releases is however probably the most common use case for cherry-picking. Some commits needs to be cherry-picked for other release lanes. `git worktree` is a feature I've often heard being raved about. I've not yet been able to use it for myself, in out code bases, but I imagine it being very nice if you have it work for you. Aside: suggestion to add `git switch` and `git restore` to your repertoire. I'm guessing you use `git checkout` for these commands, but switching branches and resetting the staging area are two _very_ different tasks and making these two different commands is a wise decision. Lessens the likelihood for errors, at least for me.
- pinoy420 2y ago
  Interesting I have only worked on huge applications that take ages to spin up so bisect was never really an option. > start doing something unrelated to the task I would change branch to that — if I ever had liberty to change priorities like that. I have not tried git switch thank you
  - kartoffelmos 2y ago
    We try to have a clean-as-you-go policy. Try to improve bits and bobs while maintaining the code base as a whole. While (IMO) a one-liner here and there is fine, it can quickly spiral out of control. I usually keep an improvements commit at the start of my branch which I `--amend` to while picking away at the task. If the commit gets too big I submit it separately, to be reviewed in isolation.
  - Izkata 2y ago
    > I have only worked on huge applications that take ages to spin up so bisect was never really an option. That's the best time to use bisect, set up a script to automate the build and test for the specific thing you're looking for, then use "git bisect auto ./foo.sh" and go to lunch.
wodenokoto 2y ago
Are those basic? Because those cause me more than enough pain on the command line.
steinuil 2y ago
Sounds like you'd enjoy using JJ! It looks to me that you have this workflow to work around git's poor tooling for manipulating local commits before pushing. JJ makes that very easy! Forgot to add something to a previous commit? Run "jj squash -i" to move the lines you select to whatever commit you want. Or you can run "jj edit" to check out that commit and edit it directly. Want to split a commit into two separate commits? Run "jj split". Need to reorder commits? Run "jj rebase", and if you have a conflict you can "jj edit" the commits that are marked as conflicted to fix it later, unlike Git where you have to run through a lengthy process of fixing conflicts on commits you don't remember and then review the changes later to see whether they still make sense. If you want to have a messy working copy of your repo that's very easy to do. The workflow would mostly involve: - Develop the feature - "jj split" to pick out the stuff you need into a separate commit, which will appear between master and the working copy commit - "jj describe" to add a commit message - "jj bookmark set feature-branch" on the commit containing the stuff you want to push - "jj git push" to push it - "jj edit" to return to the commit containing the working copy. You'd end up with a tree that looks kind of like this: @ ptswumyk 2025-02-12 13:16:36 de46f8c1 │ messy working copy ○ slwozrlr 2025-02-12 13:16:22 feature-branch@origin d3d246a1 │ feature implementation ◆ tssssuzr 2025-02-12 12:34:28 master* 8a9bab0f │ generate flake registry from inputs ~ So it's not that I really need more features to git, just a better UX, which is what JJ provides.
Snild 2y ago
Cherrypicking preserves the original metadata -- author name, date, commit message. At my job, we use it to backport upstream commits from vendors or other internal branches. If we just copied the contents (everything at once?!) and made new commits, it would become impossible to track and we'd end up with chaos. Keeping the original rationale for changes is invaluable when trying to understand complex code. There are few things more frustrating than a commit that says only "fix bug". As for other git commands, git bisect is wonderful.

rat87 2y ago

Well for one thing even doing basic commands its easy to mess up if you don't understand it. Even people who are better at git still often don't know that much about it. I was the git person at our last job and Im not that good. Besides push, merge, rebase, stash, status commit I've used submodules and git-svn(both for converting a repo to git and for having a local copy for my own use). Rebasing when you run into conflicts is annoying, I much prefer to have intellij to guide me through the rebase then using the commandline. Submodule are annoying but I assume part of that is inevitable when you have two repos linked like that, some of it is probably gits fault.

ImHereToVote 2y ago

I second the copy paste solution. I don't understand devs that cherrypick.

fragmede 2y ago
when setup right, cherry-pick is simply more efficient.
- ykonstant 2y ago
  How do you set it up right?
  - fragmede 2y ago
    By making commits that can be cherry-picked. If one commit adds five different things then you can't add just one of those five things with git cherry-pick. Then instead of making a second copy and then pasting the code over and commiting it, it's just git cherry-pick and you're done.
    - ImHereToVote 2y ago
      So trust other devs. Got it.
      - fragmede 2y ago
        Yeah, I know that other people suck and dealing with them is difficult, but this is why there's code review and a company culture. Those soft skills that you think you don't need because you're so smart and everyone else is dumb? turns out they're the smart ones and you're the dumb one for not working on those skills in addition to the stuff you're awesome at because those skills will get them (and you) further in life than any others.
ghosty141 2y ago
There is a semantic difference. If you just copy paste code from the master branch to a release branch it might be unclear where that code came from. A cherry pick makes it clear that you ported a bugfix from the master to the release branch. You obviously don't need many git features if you are working alone or with only 1-2 team members but the bigger the organization the more complex the git workflow becomes.

barrkel 2y ago

The most common thing that causes me pain in git today is asynchronous review of a chain of commits. If you work in a commit to trunk model, every commit needs to build and pass tests and be a self-contained unit of work, ideally small, so it's quick to review. Since you don't want to be held up by the speed of review, you make more commits, each one building on the last, to form a chain. The chain of commits is reviewed, each commit separately, and they're merged in order as you go, in one big bunch at the end, or some mix. That doesn't really matter. The problem is addressing review comments on early commits in a chain. With git, you need to stash your work or make a WIP commit, jump to the right commit, made edits, then rebase the rest of your chain on that commit. This requires fiddly copying of commit hashes or a proliferation of branch names. If you have a tree of commits instead of a linear chain, it's even more work. Ideally, when looking at all the comments on your chain of commits, you just make local edits and run a magic command which amends every commit each edit "belongs" to, automatically - this is what `hg absorb` does in mercurial. (All of the above shouldn't be mistaken for saying jj makes this easier to do. I don't know if it does. I just know that git is painful for this workflow and I'd like something better.)

fragmede 2y ago
> This requires fiddly copying of commit hashes git rebase -i ?
maltelau 2y ago
Would git commit --fixup <sha> and git rebase -i --autosquash <previous-sha> do what you need? Random blog link explaining it: [1] [1] https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html https://fle.github.io/git-tip-keep-your-branch-clean-with-fi...

fragmede 2y ago

You probably also use clone, init, show, log, reset, checkout, add, rm, diff, and remote. git archive's more obscure, as is ls-files and cat-file. git worktree's useful; might want to take a look at that one. bisect is another one that comes in handy. There's a lot more to be gotten from git, but if you can't get cherry-pick to work for you, I'd start there. (which, if you open two copies of the same repo and copy and paste code, you're doing it wrong) Be able to split a commit into multiple smaller commits. Be able to split a single commits into separate hunks, be able to rebase -i and squash them into something that looks good. You should be able to move between branches effortlessly and cherry-pick commits onto different branches while working. Using git well means making it work for you instead of fighting it. Locally, I do "git commit -a -m wip" incessantly and messily, but it all gets squashed and picked back apart before it goes up for review.

pinoy420 2y ago
> if you open two copies of the same repo and copy and paste code, you're doing it wrong It has worked for 10+ years - is that really doing it wrong, or just doing it in a way different from you. > into something that looks good Is this a requirement? Or just out of being particular? >squashed […] before review Is deleting (obfuscating) the history of your approach (chain of thought) important to you? The reviewer will review the last commit anyway (always) so is this necessary other than subjective neatness? This can be squashed at the point it is merged It appears you are very efficient at git. I am having difficulty understanding the real utility of much you described. I wonder if it is a justification for finding the fun in using more uncommon features of git, or for “neatness”? Which is fine.
- fragmede 2y ago
  It's about making your tools work for you, not against you. If you've got something that works for you and you don't want to change it, don't. But when the tool you're using has a feature specifically designed for copying its kind of things from one place to another, and then you choose not to use that feature, and choose to copy things from one place to another using a different but more familiar system, then yes I'm going to say you're doing it wrong. Now, that's just my opinion as a random Internet someone who doesn't know you, your workflow, your use-case, so it's entirely possible I'm wrong about you being wrong. But without clarifying details, yes, that's wrong. Now, wrong things still work, and fundamentally things need to work, so just because it's wrong doesn't mean it doesn't work. > Is deleting (obfuscating) the history of your approach (chain of thought) important to you? It's essential. I do dumb things but I don't like looking dumb, so no one needs to know that I spent however many hours going off in the wrong direction before figuring out what I'm really trying to do. The reviewer only sees what I show them, and they'll never see the abandoned commits and branches on my laptop. They don't need to, it's a waste of their time. Treat your reviewer's time as the most valuable thing in the world and don't waste it by having them trawl through your mess. > I am having difficulty understanding the real utility of much you described. The real utility, the thing that got me to invest the time into learning git so it works for me, is that when things stop working, I can rewind to when things were working, do a git diff, and it highlights the change which would have taken me hours to find without git. There's more utility elsewhere, but that's the singular thing that convinced me to invest the time to get good at git. What's the oldest code you've written? Go back to then and try and tweak a feature. Being neat about git is because that'll happen to you at some point, and future you, two or twenty years from now, will either thank you, or curse you for your commit message.

kartoffelmos 2y ago

It was after discovering/learning `git bisect`, I started really understanding the value of using Git "properly". Being able to pinpoint in which commit an error was introduced is really invaluable. I `git cherry-pick` all the time when I graft a PR. Sometimes I drift and start doing something unrelated to a task, and I often want to push it as a separate thing. Cherry picking it into another branch is most often how I achieve this. This does mean that I have to be structured in how I construct commits while I work though. Drafting, crafting, fixing and maintaining releases is however probably the most common use case for cherry-picking. Some commits needs to be cherry-picked for other release lanes. `git worktree` is a feature I've often heard being raved about. I've not yet been able to use it for myself, in out code bases, but I imagine it being very nice if you have it work for you. Aside: suggestion to add `git switch` and `git restore` to your repertoire. I'm guessing you use `git checkout` for these commands, but switching branches and resetting the staging area are two _very_ different tasks and making these two different commands is a wise decision. Lessens the likelihood for errors, at least for me.

pinoy420 2y ago
Interesting I have only worked on huge applications that take ages to spin up so bisect was never really an option. > start doing something unrelated to the task I would change branch to that — if I ever had liberty to change priorities like that. I have not tried git switch thank you
- kartoffelmos 2y ago
  We try to have a clean-as-you-go policy. Try to improve bits and bobs while maintaining the code base as a whole. While (IMO) a one-liner here and there is fine, it can quickly spiral out of control. I usually keep an improvements commit at the start of my branch which I `--amend` to while picking away at the task. If the commit gets too big I submit it separately, to be reviewed in isolation.
- Izkata 2y ago
  > I have only worked on huge applications that take ages to spin up so bisect was never really an option. That's the best time to use bisect, set up a script to automate the build and test for the specific thing you're looking for, then use "git bisect auto ./foo.sh" and go to lunch.

wodenokoto 2y ago

Are those basic? Because those cause me more than enough pain on the command line.

steinuil 2y ago

Sounds like you'd enjoy using JJ! It looks to me that you have this workflow to work around git's poor tooling for manipulating local commits before pushing. JJ makes that very easy! Forgot to add something to a previous commit? Run "jj squash -i" to move the lines you select to whatever commit you want. Or you can run "jj edit" to check out that commit and edit it directly. Want to split a commit into two separate commits? Run "jj split". Need to reorder commits? Run "jj rebase", and if you have a conflict you can "jj edit" the commits that are marked as conflicted to fix it later, unlike Git where you have to run through a lengthy process of fixing conflicts on commits you don't remember and then review the changes later to see whether they still make sense. If you want to have a messy working copy of your repo that's very easy to do. The workflow would mostly involve: - Develop the feature - "jj split" to pick out the stuff you need into a separate commit, which will appear between master and the working copy commit - "jj describe" to add a commit message - "jj bookmark set feature-branch" on the commit containing the stuff you want to push - "jj git push" to push it - "jj edit" to return to the commit containing the working copy. You'd end up with a tree that looks kind of like this: @ ptswumyk 2025-02-12 13:16:36 de46f8c1 │ messy working copy ○ slwozrlr 2025-02-12 13:16:22 feature-branch@origin d3d246a1 │ feature implementation ◆ tssssuzr 2025-02-12 12:34:28 master* 8a9bab0f │ generate flake registry from inputs ~ So it's not that I really need more features to git, just a better UX, which is what JJ provides.

Snild 2y ago

Cherrypicking preserves the original metadata -- author name, date, commit message. At my job, we use it to backport upstream commits from vendors or other internal branches. If we just copied the contents (everything at once?!) and made new commits, it would become impossible to track and we'd end up with chaos. Keeping the original rationale for changes is invaluable when trying to understand complex code. There are few things more frustrating than a commit that says only "fix bug". As for other git commands, git bisect is wonderful.