2 ms·

I think Git is conceptually simple... each commit is just conceptually a diff from a previous commit -- possibly from two commits. Branches and tags are just po

I think Git is conceptually simple... each commit is just conceptually a diff from a previous commit -- possibly from two commits. Branches and tags are just pointers to a commit. A merge is when you join two commits and thus may result in one merge conflict, while a rebase is resetting your branch to some other target commit and then /re-applying/ _each_ of your commits on top, which may generate more than 1 merge conflict (due to each _one_ of your commits effectively being re-committed all over again) but hides the fact that you applying old changes to a newer base. But the tooling around Git is not great. I think showing merge conflicts properly so you don't mess them up is also tooling issue more than anything. I'm going to plug this app called SmartGit which I have no relationship with that I don't think a lot of people have tried but it's awesome. Doesn't obscure anything about Git and shows merge conflicts well IMO. Costs $ though.

eru 3y ago
> I think Git is conceptually simple... each commit is just conceptually a diff from a previous commit -- possibly from two commits. Branches and tags are just pointers to a commit. That's backwards. Git commits are complete snapshots of the state of your repository at the time. You can compute diffs between arbitrary commits, be that between child and parent commits, or completely unrelated commits. Have a look at https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge https://stackoverflow.com/questions/4129049/why-is-a-3-way-m...
- wayfinder 3y ago
  Oh I know. I do that all that time. (And in SmartFGit, you can select any two commits.) But I said conceptually and that’s how I see them and it works for me.
  - OskarS 3y ago
    Conceptually, though, that's the wrong model. Pijul works like that, but git does not: commits are not diffs, they are full snapshots of the repository, including history. If you cherry-pick a commit from one branch to another, that's an entire new commit, it's not just "this patch moved from one branch to another". If your idea of a commit is "it's a diff to the previous commit", you'll get into trouble.
    - globular-toast 3y ago
      Yes and no. When you do a checkout or reset etc. you are indeed operating on snapshots. You're just saying "get me this version right here". But when you do cherry-pick or rebase etc, git is operating on diffs. A cherry-pick doesn't set your head or workdir to that version[0], it applies the changes to a new commit that sits on top of your current head. Similarly, a rebase walks through the changes and applies each one to the target. Commits and diffs are a duality and it matters not one bit how git stores them underneath. You can always calculate one from the other. [0] If you did want to do that for some reason then git reset will do it for you. That sets your current branch to that commit and with --hard it makes your workdir match. `git checkout <sha1> .` makes your workdir match that older commit, but it doesn't do deletes. If you want to make just your workdir match an older commit the only way I know is something like: `git reset --hard <sha1>; git reset --soft HEAD@{1}` which can be read as "set my current branch to be at sha1 and make working directory match that snapshot exactly, then set my branch to be at where it was before that operation, leaving my workdir alone". It's not a very common thing to want to do.
IlliOnato 3y ago
> Branches and tags are just pointers to a commit Technically that's correct, but it is not how branches are thought of and used. Conceptually a branch is, well, a line of development, a sequence of commits with a name. (Actually it is not necessary just a sequence, but this is not important here) I think the implementation of branches in Git as just a kind of fancy tags is one of the sources of confusion about/around Git. And I love Git, don't get me wrong! But some things in it make things harder than necessary.

eru 3y ago

> I think Git is conceptually simple... each commit is just conceptually a diff from a previous commit -- possibly from two commits. Branches and tags are just pointers to a commit. That's backwards. Git commits are complete snapshots of the state of your repository at the time. You can compute diffs between arbitrary commits, be that between child and parent commits, or completely unrelated commits. Have a look at https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge https://stackoverflow.com/questions/4129049/why-is-a-3-way-m...

wayfinder 3y ago
Oh I know. I do that all that time. (And in SmartFGit, you can select any two commits.) But I said conceptually and that’s how I see them and it works for me.
- OskarS 3y ago
  Conceptually, though, that's the wrong model. Pijul works like that, but git does not: commits are not diffs, they are full snapshots of the repository, including history. If you cherry-pick a commit from one branch to another, that's an entire new commit, it's not just "this patch moved from one branch to another". If your idea of a commit is "it's a diff to the previous commit", you'll get into trouble.
  - globular-toast 3y ago
    Yes and no. When you do a checkout or reset etc. you are indeed operating on snapshots. You're just saying "get me this version right here". But when you do cherry-pick or rebase etc, git is operating on diffs. A cherry-pick doesn't set your head or workdir to that version[0], it applies the changes to a new commit that sits on top of your current head. Similarly, a rebase walks through the changes and applies each one to the target. Commits and diffs are a duality and it matters not one bit how git stores them underneath. You can always calculate one from the other. [0] If you did want to do that for some reason then git reset will do it for you. That sets your current branch to that commit and with --hard it makes your workdir match. `git checkout <sha1> .` makes your workdir match that older commit, but it doesn't do deletes. If you want to make just your workdir match an older commit the only way I know is something like: `git reset --hard <sha1>; git reset --soft HEAD@{1}` which can be read as "set my current branch to be at sha1 and make working directory match that snapshot exactly, then set my branch to be at where it was before that operation, leaving my workdir alone". It's not a very common thing to want to do.

IlliOnato 3y ago

> Branches and tags are just pointers to a commit Technically that's correct, but it is not how branches are thought of and used. Conceptually a branch is, well, a line of development, a sequence of commits with a name. (Actually it is not necessary just a sequence, but this is not important here) I think the implementation of branches in Git as just a kind of fancy tags is one of the sources of confusion about/around Git. And I love Git, don't get me wrong! But some things in it make things harder than necessary.