8 ms·

I must be some kind of genius, as I find git quite easy? I've been using it daily for years now, but I started out with subversion which was quite nice because

I must be some kind of genius, as I find git quite easy? I've been using it daily for years now, but I started out with subversion which was quite nice because it had TortoiseSVN. Later went to Mercurial which was pleasant to work with but since GitHub arrived to the scene the choice both private and professionally became the obvious. Besides git and hg are IMHO not that different anyway from a daily use pov.

edu 3y ago
Same story here.
Charlie_26 3y ago
I feel sort of in the same boat, at least from reading this blogpost. Though it might be time for me to master fetch rather than pull. What I wonder is how anyone (read: most people) get by with using GUIs for Git that tend to abstract some of these fundamentals away
bboygravity 3y ago
OK, Git is easy? I got a trivial sounding task for ya: delete 1 file from (all commits in) a repository with 100's or 1000's of commits. Without using any external tools. You've got 5 minutes. Should be plenty of time to delete 1 file and/or figure out how to do that simple task right? Good luck.
- civopsec 3y ago
  > Without using any external tools. git-filter-branch is the only mass-rewrite helper tool that I know of in git(1) and it's deprecated.
  - sshine 3y ago
    Check out “git filter-repo”. It’s safer, faster, easier to use. Oh, and not built-in.
    - civopsec 3y ago
      The rule was to not use any external tools so it doesn't qualify. But you're right. filter-repo is a great tool. You can even use pleasant Python "callbacks" instead of a hodge-podge of env variables and shell snippets.
      - sshine 3y ago
        The rule is arbitrary and unhelpful and only helps drive a rhetorical point, not actual advice: you really don’t want to do this without a tool as safe and fast as filter-repo. Even recommending filter-branch is just aligning the footgun slightly. If a point is to be made that confirms OP: removing a file completely isn’t trivial, and thinking one did when one didn’t it is too easy.
        civopsec 3y ago
        > Even recommending filter-branch is just aligning the footgun slightly. Who recommended it?
        sshine 3y ago
        It ships with git, so without extra tools, it is the implied solution to OP’s question, and the default choice for many. I’m not saying they recommend it, as the question drives a rhetorical point. But it’s worth mentioning “git filter-repo” as a solution you will not stumble into as easily as the more difficult, brittle and slow “git filter-branch”.
        civopsec 3y ago
        What I said in my one-sentence-reply is that there are no non-deprecated, built-in tools that helps with this task in a streamlined manner. Which means by extension that it is not a trivial task.
- szszrk 3y ago
  How does that sound trivial? Let's rephrase it. Delete every mention of a single file in all history of work of a large team over multiple years. How does that sound trivial?
- Xeamek 3y ago
  Delete the file from (past) commits? Isn't the whole point (idiomatic way) that you don't do that, and only delete it in the newest commit? Unless you mean some intentionally weird scenario, where you want to just delete the file to prevent it from being accessible period. But that's (afaik) against the whole concept of git, and so verry much outside the intended use. Do I understand your example?
  - kibibu 3y ago
    It's a fairly common problem when people realise they have inadvertently committed a secrets file. You could say "well don't commit secrets files" but that doesn't immediately solve the problem.
    - nikau 3y ago
      In that case the secret is blown so you rotate it and leaving in the repo isn't an issue.
      - kibibu 3y ago
        Maybe the repo hasn't been made public yet and it's a clean up before release.
- sshine 3y ago
  > Without using any external tools. How about: using the right tool for the job? In this case, the right tool would be “git filter-repo”.
- TheChaplain 3y ago
  When I learned Git, many tutorials were pretty clear that what goes into git stays there as they were added, which is the whole point of a vcs. So I would dare to say that your example is not entirely a good one? In my 10 years of using Git, in both privately and professional this has happened exactly zero times. But that's just me. To use an somewhat odd analogy, it would be akin to asking the average car driver to replace the crown wheel in the differential. I'm certain everyone can do it with enough youtube tutorials and practice, but.. I digress. But actually it makes sense, Git is like a car, once they understand what basic problem it tries to solve and learn the commands to push, pull, commit, rebase and merge, it's enough as learning navigating traffic and use the car from point a to point b. So I believe git is easy enough for normal, but of course when situations like your example occurs it's harder (but understandable considering what problem the tool is trying to solve). I am not being condescending here, it's my real world experience that tells me that very few people have issues with git, and looking at how many use github/gitlab/gitea/etc everyday shows the same.
- kiney 3y ago
  The whole point of git is to preserve history. So removing stuff from history is obviously not super easy. "Without external tool" Why? Git defines a data structure on disk and not a monopoly on imolementation. The right tool for this job would be BFG.
sshine 3y ago
> I must be some kind of genius, as I find git quite easy? It’s hard to compare when you knew a conceptually simpler VCS before learning git, since you have no clear memory of getting blasted with the full conceptual model of git at once. I had to teach git to two colleagues recently, and it helped greatly that they could start with GitHub Desktop, since they also weren’t command-line veterans. The two concepts that were hardest for them to stick was (a) that there is a difference between “main”, “origin/main” and the remote “main”: the idea of a local copy of a remote branch that is different from your local branch seems abstract and unnecessary until you have merge conflicts and you need the conflicting code to live somewhere locally. (b) that you want to branch off from “main” instead of whatever branch you’re on right now, when you start on a new thing. This is true when you do a pull request and then begin something new. I talk about branches as parallel dimensions and merging as portals between them. I don’t remember when it happened, but there comes a point where you go from “it’s hard to use git without screwing up and having to start over” (https://xkcd.com/1597/ https://xkcd.com/1597/) to “it’s hard to use git and screw up”. Having “git reflog” makes you quite invulnerable which makes you dare rebasing more. Reaching consistent undo should happen sooner than reaching complex history rewriting ability, because it greatly affects what you dare do.
- kibibu 3y ago
  Importantly, neither of these are solved merely by learning the dag structures internal to git.
JohnFen 3y ago
You're smarter than me, anyway. I'll confess that I don't actually understand git and I sweat bullets every time I have to use it. My only consolation is that's true of most of my team as well.

edu 3y ago

Same story here.

Charlie_26 3y ago

I feel sort of in the same boat, at least from reading this blogpost. Though it might be time for me to master fetch rather than pull. What I wonder is how anyone (read: most people) get by with using GUIs for Git that tend to abstract some of these fundamentals away

bboygravity 3y ago

OK, Git is easy? I got a trivial sounding task for ya: delete 1 file from (all commits in) a repository with 100's or 1000's of commits. Without using any external tools. You've got 5 minutes. Should be plenty of time to delete 1 file and/or figure out how to do that simple task right? Good luck.

civopsec 3y ago
> Without using any external tools. git-filter-branch is the only mass-rewrite helper tool that I know of in git(1) and it's deprecated.
- sshine 3y ago
  Check out “git filter-repo”. It’s safer, faster, easier to use. Oh, and not built-in.
  - civopsec 3y ago
    The rule was to not use any external tools so it doesn't qualify. But you're right. filter-repo is a great tool. You can even use pleasant Python "callbacks" instead of a hodge-podge of env variables and shell snippets.
    - sshine 3y ago
      The rule is arbitrary and unhelpful and only helps drive a rhetorical point, not actual advice: you really don’t want to do this without a tool as safe and fast as filter-repo. Even recommending filter-branch is just aligning the footgun slightly. If a point is to be made that confirms OP: removing a file completely isn’t trivial, and thinking one did when one didn’t it is too easy.
      - civopsec 3y ago
        > Even recommending filter-branch is just aligning the footgun slightly. Who recommended it?
        sshine 3y ago
        It ships with git, so without extra tools, it is the implied solution to OP’s question, and the default choice for many. I’m not saying they recommend it, as the question drives a rhetorical point. But it’s worth mentioning “git filter-repo” as a solution you will not stumble into as easily as the more difficult, brittle and slow “git filter-branch”.
        civopsec 3y ago
        What I said in my one-sentence-reply is that there are no non-deprecated, built-in tools that helps with this task in a streamlined manner. Which means by extension that it is not a trivial task.
szszrk 3y ago
How does that sound trivial? Let's rephrase it. Delete every mention of a single file in all history of work of a large team over multiple years. How does that sound trivial?
Xeamek 3y ago
Delete the file from (past) commits? Isn't the whole point (idiomatic way) that you don't do that, and only delete it in the newest commit? Unless you mean some intentionally weird scenario, where you want to just delete the file to prevent it from being accessible period. But that's (afaik) against the whole concept of git, and so verry much outside the intended use. Do I understand your example?
- kibibu 3y ago
  It's a fairly common problem when people realise they have inadvertently committed a secrets file. You could say "well don't commit secrets files" but that doesn't immediately solve the problem.
  - nikau 3y ago
    In that case the secret is blown so you rotate it and leaving in the repo isn't an issue.
    - kibibu 3y ago
      Maybe the repo hasn't been made public yet and it's a clean up before release.
sshine 3y ago
> Without using any external tools. How about: using the right tool for the job? In this case, the right tool would be “git filter-repo”.
TheChaplain 3y ago
When I learned Git, many tutorials were pretty clear that what goes into git stays there as they were added, which is the whole point of a vcs. So I would dare to say that your example is not entirely a good one? In my 10 years of using Git, in both privately and professional this has happened exactly zero times. But that's just me. To use an somewhat odd analogy, it would be akin to asking the average car driver to replace the crown wheel in the differential. I'm certain everyone can do it with enough youtube tutorials and practice, but.. I digress. But actually it makes sense, Git is like a car, once they understand what basic problem it tries to solve and learn the commands to push, pull, commit, rebase and merge, it's enough as learning navigating traffic and use the car from point a to point b. So I believe git is easy enough for normal, but of course when situations like your example occurs it's harder (but understandable considering what problem the tool is trying to solve). I am not being condescending here, it's my real world experience that tells me that very few people have issues with git, and looking at how many use github/gitlab/gitea/etc everyday shows the same.
kiney 3y ago
The whole point of git is to preserve history. So removing stuff from history is obviously not super easy. "Without external tool" Why? Git defines a data structure on disk and not a monopoly on imolementation. The right tool for this job would be BFG.

sshine 3y ago

> I must be some kind of genius, as I find git quite easy? It’s hard to compare when you knew a conceptually simpler VCS before learning git, since you have no clear memory of getting blasted with the full conceptual model of git at once. I had to teach git to two colleagues recently, and it helped greatly that they could start with GitHub Desktop, since they also weren’t command-line veterans. The two concepts that were hardest for them to stick was (a) that there is a difference between “main”, “origin/main” and the remote “main”: the idea of a local copy of a remote branch that is different from your local branch seems abstract and unnecessary until you have merge conflicts and you need the conflicting code to live somewhere locally. (b) that you want to branch off from “main” instead of whatever branch you’re on right now, when you start on a new thing. This is true when you do a pull request and then begin something new. I talk about branches as parallel dimensions and merging as portals between them. I don’t remember when it happened, but there comes a point where you go from “it’s hard to use git without screwing up and having to start over” (https://xkcd.com/1597/ https://xkcd.com/1597/) to “it’s hard to use git and screw up”. Having “git reflog” makes you quite invulnerable which makes you dare rebasing more. Reaching consistent undo should happen sooner than reaching complex history rewriting ability, because it greatly affects what you dare do.

kibibu 3y ago
Importantly, neither of these are solved merely by learning the dag structures internal to git.

JohnFen 3y ago

You're smarter than me, anyway. I'll confess that I don't actually understand git and I sweat bullets every time I have to use it. My only consolation is that's true of most of my team as well.