3 ms·

I understand the sentiment, but since git is probably one of the longer-lasting constants in our industry (if not the longest-lasting constant), I personally th

I understand the sentiment, but since git is probably one of the longer-lasting constants in our industry (if not the longest-lasting constant), I personally think it's really worth to have a bit of a look into it. Something I wish someone suggested to me years ago: Instead of trying to understand the commands, try to understand the datamodel. A branch is just a pointer to a commit, a commit is just a pointer (with metadata) to a tree, a tree is just... and so on. Once you understood this (which really isn't any harder than, say, understanding how quick-sort works), going from the data-model to the commands is fairly easy, almost intuitive if it weren't for all the convoluted options that each command can take. Anyway, not trying to convince you or anything, just saying that I've been in your place a few years back, and wish I'd realized earlier how easy it actually is.

Dylan16807 4y ago
> Once you understood this (which really isn't any harder than, say, understanding how quick-sort works), going from the data-model to the commands is fairly easy, almost intuitive if it weren't for all the convoluted options that each command can take. So, not intuitive at all? I've had to make very minor changes to the commit history that took a bunch of obnoxious commands. I know the git model very well but it didn't help. It would have been easier to copy all the source files out, check out the branch I wanted, then copy them all back in.
- Shacklz 4y ago
  > It would have been easier to copy all the source files out, check out the branch I wanted, then copy them all back in. That would be "git checkout -b some-branch" and then "git reset --soft origin/main" (or whatever branch you want to be on top of). "reset" sets the pointer where you want it to be, "--soft" ensures that the actual files on your filesystem (the working tree) isn't touched. You will then have uncommitted files (your changes compared to the origin/main), that you can then recommit everything the way you want it. reset --soft is my goto-recommendation for devs who have to satisfy a linear history but don't really care about git-history at all. Just do your changes as you normally would, using merge and whatever else floats your boat, and then once you're done, just use a soft-reset and then commit everything in one single commit. It's of course not ideal (meaningful atomic commits or some such would be better), but compared to having dozens of "fix stuff" and "merge from main" commits, it's definitely better.
daneel_w 4y ago
You have misunderstood. It's not a case of not knowing more about Git and its toolset. It's about our underlying workflow, letting us do version control of our software with simple means instead of throwing everything at it. It's easy to throw a hammer, mallet, pein and a club all at once on a nail, but that doesn't mean it's necessary or helpful.
- Shacklz 4y ago
  > letting us do version control of our software with simple means instead of throwing everything at it VCS is a pretty difficult topic, and it's not like git is the only tool out there (let alone the very first). Multiple people potentially working on the same file in conflicting ways is always going to be something that cannot just magically be made simple. After all, if there are no conflicts, "rebase" is literally the simplest command there is - just "git rebase origin/main" or whatever your equivalent is and you're good. It's only with conflicts where the fun stuff starts.
  - daneel_w 4y ago
    I don't understand what it is you want to communicate. The reason we mostly get away with minimal interaction with version control is because we plan our work to avoid (or at least minimize) multiple ongoing efforts in one and the same part of the platform - for reasons that are entirely unrelated to version control itself, not because someone on the team doesn't know how to resolve merge conflicts with Git.
theptip 4y ago
Agreed, once you grok the start/end semantics of rebase it is not hard to work with. But it can be intimidating for new users. I actually think it is easier to teach the fully-specified and interactive form ‘git rebase -i start-sha-a end-branch-b —-onto target-c’ which makes it really explicit what is going on (“snip from A to B and put that chain on C”). When you understand that you can start using the defaults that abbreviate the common cases. (Specifically “end-branch-b” is usually not needed since you usually run the command from that branch.) And getting to this level of grokking requires you to understand the data model mentioned above, but not any obscure internals, so I think it is a good bar for “knows enough of git” for senior engineers in most orgs.

Dylan16807 4y ago

> Once you understood this (which really isn't any harder than, say, understanding how quick-sort works), going from the data-model to the commands is fairly easy, almost intuitive if it weren't for all the convoluted options that each command can take. So, not intuitive at all? I've had to make very minor changes to the commit history that took a bunch of obnoxious commands. I know the git model very well but it didn't help. It would have been easier to copy all the source files out, check out the branch I wanted, then copy them all back in.

Shacklz 4y ago
> It would have been easier to copy all the source files out, check out the branch I wanted, then copy them all back in. That would be "git checkout -b some-branch" and then "git reset --soft origin/main" (or whatever branch you want to be on top of). "reset" sets the pointer where you want it to be, "--soft" ensures that the actual files on your filesystem (the working tree) isn't touched. You will then have uncommitted files (your changes compared to the origin/main), that you can then recommit everything the way you want it. reset --soft is my goto-recommendation for devs who have to satisfy a linear history but don't really care about git-history at all. Just do your changes as you normally would, using merge and whatever else floats your boat, and then once you're done, just use a soft-reset and then commit everything in one single commit. It's of course not ideal (meaningful atomic commits or some such would be better), but compared to having dozens of "fix stuff" and "merge from main" commits, it's definitely better.

daneel_w 4y ago

You have misunderstood. It's not a case of not knowing more about Git and its toolset. It's about our underlying workflow, letting us do version control of our software with simple means instead of throwing everything at it. It's easy to throw a hammer, mallet, pein and a club all at once on a nail, but that doesn't mean it's necessary or helpful.

Shacklz 4y ago
> letting us do version control of our software with simple means instead of throwing everything at it VCS is a pretty difficult topic, and it's not like git is the only tool out there (let alone the very first). Multiple people potentially working on the same file in conflicting ways is always going to be something that cannot just magically be made simple. After all, if there are no conflicts, "rebase" is literally the simplest command there is - just "git rebase origin/main" or whatever your equivalent is and you're good. It's only with conflicts where the fun stuff starts.
- daneel_w 4y ago
  I don't understand what it is you want to communicate. The reason we mostly get away with minimal interaction with version control is because we plan our work to avoid (or at least minimize) multiple ongoing efforts in one and the same part of the platform - for reasons that are entirely unrelated to version control itself, not because someone on the team doesn't know how to resolve merge conflicts with Git.

theptip 4y ago

Agreed, once you grok the start/end semantics of rebase it is not hard to work with. But it can be intimidating for new users. I actually think it is easier to teach the fully-specified and interactive form ‘git rebase -i start-sha-a end-branch-b —-onto target-c’ which makes it really explicit what is going on (“snip from A to B and put that chain on C”). When you understand that you can start using the defaults that abbreviate the common cases. (Specifically “end-branch-b” is usually not needed since you usually run the command from that branch.) And getting to this level of grokking requires you to understand the data model mentioned above, but not any obscure internals, so I think it is a good bar for “knows enough of git” for senior engineers in most orgs.