7 ms·

Git Branches Have No Rules

41 points by hasheddan 3y ago

chungy 3y ago
I wonder if this might be an educational issue? Maybe people are learning "convenient lies" about how Git works so they can get started, and don't move forward to learning the real truth of the matter? Just speaking from the perspective of someone that's used git since nearly the very beginning (and CVS and Subversion before that), Git's strong adherence to the Unix philosophy ("give enough rope to hang yourself") was definitely a breath of fresh air compared to the restrictive systems.
- david_allison 3y ago
  What's the convenient lie taught about branches? The standard concept that I remember is 'a branch is a pointer to a commit', which still feels accurate
  - chungy 3y ago
    Given TFA (a comic) has "you might expect git to enforce some rules about branches", I figured there might be an education problem going on. I didn't expect such things, but being there from the earliest days might be why. I don't even think reset and rebase are "weird stuff", for that matter. I use them multiple times a week.
  - DiggyJohnson 3y ago
    I’m not GP, but the main one I see if the mental model that a commit is a full representation of the contents of the repo at the time that commit was created (rather than being a change set or deltas between commits).
    - Brian_K_White 3y ago
      Right in this subthread people have said that. I now have no idea what is right. Which seems to only support the comics assertion, which was only "you might think x but you'd be wrong"
      - weaksauce 3y ago
        originally every commit was a full snapshot of the current state of the repository. the repository is now compressed after the fact using deltas but like another person said but it’s really just an implementation detail.
    - Karellen 3y ago
      Um, I'm pretty sure that one's not a lie. Yes, git currently stores deltas between commits in its pack files, but that's an implementation detail to save space. Importantly, it's not how git was originally written, but was added at a later time (although, still a long time ago now). Edit: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...
  - dcow 3y ago
    The way I'm reading the comic, it'd be something like "main/master is special", and "always merge in changes". Things that make people assume that forward history is somehow enforced by the software. But yeah fixing up work and cleaning up a branch prior to merging is a feature not a bug. Git got it right.
  - csours 3y ago
    Other people did not get the education you got. Thus, this being a problem with education. People say things like "a branch does this" when they mean "We have rules on the git server that enforce this", or when they mean "We have a convention to do this, you have to keep track of it". One word to describe this is synecdoche - a part represents the whole or vice versa. Some part of the system does something, or some part of the PROCESS does something, and so people say "git does this thing". Imprecise speech is shorter, but it can waste a great deal of time in the long run.
  - nophunphil 3y ago
    It's accurate in most common workflows, but definitely a convenient lie. Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A.
    - yankjenets 3y ago
      By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1? A commit SHA represents the entire DAG up until that point, not a given changeset. So in your example, branch B is still a pointer to a commit, and branch A is a pointer to a different commit. Where is the convenient lie?
      - nophunphil 3y ago
        That is one way to “remove a commit” and I agree with your analysis for that case. The method I had in mind is an interactive rebase. Assume there are n > 5 commits on my branch, choosing 5 arbitrarily. If I run “git rebase -i HEAD~5” then use the “drop” command on the third-most-recent commit, I do end up with a different DAG. The change is subtractive and not just the removal of the current HEAD. This kind of history change is definitely a bit less common but not obscure by any means. I’ve rebased to drop commits on my own feature branches many times.
        yankjenets 3y ago
        Ah ok, understood. I would argue that is still not a convenient lie of "a branch is a pointer to a commit". Rather, the rebase command is changing what the branch is pointing to, and git tries to make that clear. After that rebase command, there is a message like `Successfully rebased and updated refs/heads/yourbranch`, showing that the branch named yourbranch is now pointing at something new. Your original comment: >Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A. My counterpoint taking this to the extreme: >Consider the case where I create a new branch B from A then run git reset --hard SOMESHA1 In my example, again the new branch is pointing at a completely different commit--because I am repointing the branch.
- dogleash 3y ago
  >I wonder if this might be an educational issue? It certainly is. There are two things that a team needs to do to use git: 1) Team members all learn git 2) A few conventions are agreed upon to facilitate collaboration People use #2 to replace #1. And that's why we've had to sit through a neverending flow of blog posts obsessing over git workflows. Git is flexible to whatever your business workflow is, play around with it a bit, choose something, then make changes when it's not working. The topic fundamentally does not need this many explainers. But if you're supplanting understanding the tool, it does.
- EPWN3D 3y ago
  It's best to think of git as a suite of primitives for building a VCS, not a VCS itself. For larger teams, you should pretty much expect to have a dedicated integrator (or integration team) with git scripts for creating branches, PRs, etc.
- Ygg2 3y ago
  I suspect it's caused by Git being such a leaky abstraction. No matter what convenient lie you use in learning it will trip up someone, sooner or later. > Unix philosophy ("give enough rope to hang yourself") was That and RTFM are probably reasons why *Nix will always be a bit player when it comes to anything that has contact with people. And, yes, Android runs Linux, so it doesn't count as an OS. I wouldn't call JVM or Spider Monkey my OS either.
dncornholio 3y ago
I missed the part on why should git branches have rules in the first place?
- charcircuit 3y ago
  Usually software should make it hard to do the wrong thing and make it easy to do the right thing. This is git we are talking about so it is fair to expect it to have a poor UX.
  - Ayesh 3y ago
    > wrong thing Rebase/reset are major and first class features of Git. It's only wrong if you work with a team that expect the centralized server to be consistent.
    - charcircuit 3y ago
      You are assuming git's design is good. Being a first class feature does not mean much if the feature doesn't work towards the user's goals.
  - dncornholio 3y ago
    For me this is a feature, and so it should be for you as well. Freedom, responsibility..
015a 3y ago
One interesting, slightly related thing about git branching I run into every once in a while: $ git checkout -b test Switched to a new branch 'test' $ git checkout -b test/1 fatal: cannot lock ref 'refs/heads/test/1': 'refs/heads/test' exists; cannot create 'refs/heads/test/1' Forward slashes are special in branch names; I'd guess because there's a filesystem representation of the branch name happening in there.
- mhink 3y ago
  Is this on Windows? Or maybe you're on an older version of Git? I make branches with slashes in the name all the time, never had a problem with it.
  - hiatus 3y ago
    The parent comment is specifically referring to creating a new branch from an existing branch with a slash in the name (ex: 'test-branch' and 'test-branch/new'). Trying it on my own machine (macos) yields an error. Even switching branches first and creating the new one yields an error.
    - Smaug123 3y ago
      You should find that vice versa also errors. After all, in principle I guess it's possible to store data in a directory (it looks like EXT2 in particular would let you store data in between entries, https://tldp.org/LDP/tlk/fs/filesystem.html#ext2fs-dir-figure https://tldp.org/LDP/tlk/fs/filesystem.html#ext2fs-dir-figur... ), but the natural law is that a directory can't contain file contents.
    - nevinera 3y ago
      First ran into this on persistent servers, where the deployed instance knew branch names github had long forgotten about.. Someone pushed a branch named "bugfix", and `git fetch` started erroring. You get even _more_ interesting problems if part of your team has case-insensitive file-systems!
  - shagie 3y ago
Espressosaurus 3y ago
A git branch is a pointer. It can point at whatever. This shouldn't be confusing, but it is because that's not a natural way to think about revision control, so we instead have to relitigate it all the time for people that haven't learned git's obtuse naming conventions.
- Buttons840 3y ago
  It seems like the natural way to me. What do you think the natural way is?
  - Espressosaurus 3y ago
    > It seems like the natural way to me. What do you think the natural way is? A branch is a DAG of commits terminating at one commit. They should have just called it a pointer if it's a pointer. But here we are anyway.
    - lakpan 3y ago
      That’s not right. A branch is a single pointer to a single commit. Just open your .git folder. It’s then Git itself that follows that commit’s pointer to its parent(s). The branch, like the tag, is a single reference to a commit. Do this: $ cat .git/refs/heads/main
      - Buttons840 3y ago
        It seems accurate enough to say the branch includes all the parents of the pointed to commit. It's a matter of definition, but both definitions are technically accurate. (Also, note the path you ask us to cat does not contain the word "branch". You refer to how things are stored to support your definition, but the way things are stored doesn't use the term "branch".)
      - Espressosaurus 3y ago
        The question was "what do you think is the most natural way to think about it", not "how does git represent it".
csours 3y ago
I think a lot of people drop any wrong information. It's a waste of time to think about wrong information. This comic presents a scenario where someone believes wrong information: git branches have rules. Git branches do not in fact have rules. This is wrong information. Why would we talk about wrong information? We talk about wrong information because other people do not have up to date and correct information. We can try to just update their information to be correct, but that does not always work. In some cases they have built a structure of reasoning based on their belief. It is traumatic to destroy this structure of reasoning without providing a replacement. Thus it can be helpful to understand the bad reasoning (based on wrong information) in order to communicate more effectively.
- cryptonector 3y ago
  Git branches do have rules. The most basic rule is that if you have a branch checked out and you add a commit, then the branch name moves. Upstreams can also have rules like "no history rewriting".
  - csours 3y ago
    Thank you for more correct information.
  - jgavris 3y ago
    Git ‘remotes’ can have rules (hooks that run on push, and decline). GitHub has ‘branch protection’ which prevents various changes. But GitHub is not Git. A common misconception lately due to its popularity. Git itself is nothing more than a set of tools to manage the versions of a repository. How you choose to use it is up to you, and what you allow. Solo developer? Rebase, or don’t. Do you collaborate? Maybe consider using a SaaS product like GitHub and setup your rules.
    - cryptonector 3y ago
      > Git itself is nothing more than a set of tools to manage the versions of a repository. "Git" is also the protocol, not just the implementation. Indeed, here I'm referring to the Git protocol more than to the Git implementation. There are multiple implementations of the Git protocol. GitHub is but one of several. > But GitHub is not Git. To the client it's indistinguishable.
munk-a 3y ago
Git branches have rules on origin - those rules are enforced with a big stick. What you do in your own clone of the repository is between you and god alone.
- deleted 3y ago
  [deleted]
User23 3y ago
The reflog is not always there. By default git gc only keeps the last 90 days.
piinbinary 3y ago
Another rule that git branches do not have: they don't have to have originally come from the same repo. You can pull a branch from a different project if you want to. (This is useful if you are trying to combine two repos while preserving history.)
manbash 3y ago
With respect, the person doesn't understand the purpose of git. Doing 'git pull' often would fit for a very specific workflow, and one that in time proves to be a wrong workflow, in my opinion. Don't do things that don't have a conscious purpose.
- not2b 3y ago
  You are commenting on one page of a webzine, written by a person who has used git for years and has written lots of educational material on git and other technical subjects. She understands the purpose of git. In the linked comic she is pointing out, correctly, that while there are conventions that make good workflows, git doesn't enforce them and allows you to do stupid stuff. Surely you don't disagree with that.
tonymet 3y ago
Git is a distributed system, meaning that you're supposed to have different histories. Git gives you the tools to allow any member of the team to reconcile those histories cleanly for others. Forcing everyone to be in sync all the time also means lots of merge conflicts. Git allows for everyone to drift in their own way and provides tools for them to reconcile that drift in a way that others can integrate easily. Until you embrace the distributed nature and start using tools to manage your history (rebase & reset) , you will suffer with git. I cringe when editors refer to "rebase & reset" as "weird". Rebase and reset are the primary power tools of git. Along with reflog, revert, interactive-add . The worst repositories I've seen are people who `git merge` 20x a day to stay "in sync" and create labyrinthian change logs that are impossible to parse.
- tsimionescu 3y ago
  Paying the cost of a distributed system for a centralized team of 10 is a horrible idea. Better for someone on the team to teach everyone else a simple set of rules (git checkout -b before starting a new featire, git pull --rebase origin to keep up to date, git push origin when you're done) and pretend Git is a centralized system as much as possible. You're anyway going to have a central server which is the source of truth. If your local copy goes bad, there's always rm -rf ./ && git clone. No reason to pretend your local history has some value. Of course, if you are working on a highly distributed project, like the Linux kernel, many of the Git tools are absolutely invaluable. But there's no reason to bother with them if you're not.
  - tonymet 3y ago
    I like your idea of feature branches, but people do need to know the data model and how to manage their history. They will inevitably be out of sync and clumsily tring to get merge all day to get their files in sync. Keeping the history clean is more important than just syncing files.
- fouric 3y ago
  This seems like a reasonable take - there's only one problem: you haven't told us how to draw the rest of the owl. How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?
deleted 3y ago
[deleted]
cryptonector 3y ago
This is not a problem. I rewrite history all the time, locally (where locally means "unpublished" rather than "not pushed anywhere"). This is a feature. Upstream branches can and do have rules, like "fast-forward only pushes", which means "no history rewriting here (because this branch is published)".
tripleo1 3y ago
This is more interesting: https://timothya.com/blog/git-stack/ https://timothya.com/blog/git-stack/ https://gitlab.com/wavexx/git-assembler https://gitlab.com/wavexx/git-assembler https://www.thregr.org/wavexx/software/git-assembler/ https://www.thregr.org/wavexx/software/git-assembler/

41 points by hasheddan 3y ago

I wonder if this might be an educational issue? Maybe people are learning "convenient lies" about how Git works so they can get started, and don't move forward to learning the real truth of the matter? Just speaking from the perspective of someone that's used git since nearly the very beginning (and CVS and Subversion before that), Git's strong adherence to the Unix philosophy ("give enough rope to hang yourself") was definitely a breath of fresh air compared to the restrictive systems.

david_allison 3y ago
What's the convenient lie taught about branches? The standard concept that I remember is 'a branch is a pointer to a commit', which still feels accurate
- chungy 3y ago
  Given TFA (a comic) has "you might expect git to enforce some rules about branches", I figured there might be an education problem going on. I didn't expect such things, but being there from the earliest days might be why. I don't even think reset and rebase are "weird stuff", for that matter. I use them multiple times a week.
- DiggyJohnson 3y ago
  I’m not GP, but the main one I see if the mental model that a commit is a full representation of the contents of the repo at the time that commit was created (rather than being a change set or deltas between commits).
  - Brian_K_White 3y ago
    Right in this subthread people have said that. I now have no idea what is right. Which seems to only support the comics assertion, which was only "you might think x but you'd be wrong"
    - weaksauce 3y ago
      originally every commit was a full snapshot of the current state of the repository. the repository is now compressed after the fact using deltas but like another person said but it’s really just an implementation detail.
  - Karellen 3y ago
    Um, I'm pretty sure that one's not a lie. Yes, git currently stores deltas between commits in its pack files, but that's an implementation detail to save space. Importantly, it's not how git was originally written, but was added at a later time (although, still a long time ago now). Edit: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...
- dcow 3y ago
  The way I'm reading the comic, it'd be something like "main/master is special", and "always merge in changes". Things that make people assume that forward history is somehow enforced by the software. But yeah fixing up work and cleaning up a branch prior to merging is a feature not a bug. Git got it right.
- csours 3y ago
  Other people did not get the education you got. Thus, this being a problem with education. People say things like "a branch does this" when they mean "We have rules on the git server that enforce this", or when they mean "We have a convention to do this, you have to keep track of it". One word to describe this is synecdoche - a part represents the whole or vice versa. Some part of the system does something, or some part of the PROCESS does something, and so people say "git does this thing". Imprecise speech is shorter, but it can waste a great deal of time in the long run.
- nophunphil 3y ago
  It's accurate in most common workflows, but definitely a convenient lie. Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A.
  - yankjenets 3y ago
    By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1? A commit SHA represents the entire DAG up until that point, not a given changeset. So in your example, branch B is still a pointer to a commit, and branch A is a pointer to a different commit. Where is the convenient lie?
    - nophunphil 3y ago
      That is one way to “remove a commit” and I agree with your analysis for that case. The method I had in mind is an interactive rebase. Assume there are n > 5 commits on my branch, choosing 5 arbitrarily. If I run “git rebase -i HEAD~5” then use the “drop” command on the third-most-recent commit, I do end up with a different DAG. The change is subtractive and not just the removal of the current HEAD. This kind of history change is definitely a bit less common but not obscure by any means. I’ve rebased to drop commits on my own feature branches many times.
      - yankjenets 3y ago
        Ah ok, understood. I would argue that is still not a convenient lie of "a branch is a pointer to a commit". Rather, the rebase command is changing what the branch is pointing to, and git tries to make that clear. After that rebase command, there is a message like `Successfully rebased and updated refs/heads/yourbranch`, showing that the branch named yourbranch is now pointing at something new. Your original comment: >Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A. My counterpoint taking this to the extreme: >Consider the case where I create a new branch B from A then run git reset --hard SOMESHA1 In my example, again the new branch is pointing at a completely different commit--because I am repointing the branch.
dogleash 3y ago
>I wonder if this might be an educational issue? It certainly is. There are two things that a team needs to do to use git: 1) Team members all learn git 2) A few conventions are agreed upon to facilitate collaboration People use #2 to replace #1. And that's why we've had to sit through a neverending flow of blog posts obsessing over git workflows. Git is flexible to whatever your business workflow is, play around with it a bit, choose something, then make changes when it's not working. The topic fundamentally does not need this many explainers. But if you're supplanting understanding the tool, it does.
EPWN3D 3y ago
It's best to think of git as a suite of primitives for building a VCS, not a VCS itself. For larger teams, you should pretty much expect to have a dedicated integrator (or integration team) with git scripts for creating branches, PRs, etc.
Ygg2 3y ago
I suspect it's caused by Git being such a leaky abstraction. No matter what convenient lie you use in learning it will trip up someone, sooner or later. > Unix philosophy ("give enough rope to hang yourself") was That and RTFM are probably reasons why *Nix will always be a bit player when it comes to anything that has contact with people. And, yes, Android runs Linux, so it doesn't count as an OS. I wouldn't call JVM or Spider Monkey my OS either.

dncornholio 3y ago

I missed the part on why should git branches have rules in the first place?

charcircuit 3y ago
Usually software should make it hard to do the wrong thing and make it easy to do the right thing. This is git we are talking about so it is fair to expect it to have a poor UX.
- Ayesh 3y ago
  > wrong thing Rebase/reset are major and first class features of Git. It's only wrong if you work with a team that expect the centralized server to be consistent.
  - charcircuit 3y ago
    You are assuming git's design is good. Being a first class feature does not mean much if the feature doesn't work towards the user's goals.
- dncornholio 3y ago
  For me this is a feature, and so it should be for you as well. Freedom, responsibility..

015a 3y ago

One interesting, slightly related thing about git branching I run into every once in a while: $ git checkout -b test Switched to a new branch 'test' $ git checkout -b test/1 fatal: cannot lock ref 'refs/heads/test/1': 'refs/heads/test' exists; cannot create 'refs/heads/test/1' Forward slashes are special in branch names; I'd guess because there's a filesystem representation of the branch name happening in there.

mhink 3y ago
Is this on Windows? Or maybe you're on an older version of Git? I make branches with slashes in the name all the time, never had a problem with it.
- hiatus 3y ago
  The parent comment is specifically referring to creating a new branch from an existing branch with a slash in the name (ex: 'test-branch' and 'test-branch/new'). Trying it on my own machine (macos) yields an error. Even switching branches first and creating the new one yields an error.
  - Smaug123 3y ago
    You should find that vice versa also errors. After all, in principle I guess it's possible to store data in a directory (it looks like EXT2 in particular would let you store data in between entries, https://tldp.org/LDP/tlk/fs/filesystem.html#ext2fs-dir-figure https://tldp.org/LDP/tlk/fs/filesystem.html#ext2fs-dir-figur... ), but the natural law is that a directory can't contain file contents.
  - nevinera 3y ago
    First ran into this on persistent servers, where the deployed instance knew branch names github had long forgotten about.. Someone pushed a branch named "bugfix", and `git fetch` started erroring. You get even _more_ interesting problems if part of your team has case-insensitive file-systems!
- shagie 3y ago

Espressosaurus 3y ago

A git branch is a pointer. It can point at whatever. This shouldn't be confusing, but it is because that's not a natural way to think about revision control, so we instead have to relitigate it all the time for people that haven't learned git's obtuse naming conventions.

Buttons840 3y ago
It seems like the natural way to me. What do you think the natural way is?
- Espressosaurus 3y ago
  > It seems like the natural way to me. What do you think the natural way is? A branch is a DAG of commits terminating at one commit. They should have just called it a pointer if it's a pointer. But here we are anyway.
  - lakpan 3y ago
    That’s not right. A branch is a single pointer to a single commit. Just open your .git folder. It’s then Git itself that follows that commit’s pointer to its parent(s). The branch, like the tag, is a single reference to a commit. Do this: $ cat .git/refs/heads/main
    - Buttons840 3y ago
      It seems accurate enough to say the branch includes all the parents of the pointed to commit. It's a matter of definition, but both definitions are technically accurate. (Also, note the path you ask us to cat does not contain the word "branch". You refer to how things are stored to support your definition, but the way things are stored doesn't use the term "branch".)
    - Espressosaurus 3y ago
      The question was "what do you think is the most natural way to think about it", not "how does git represent it".

csours 3y ago

I think a lot of people drop any wrong information. It's a waste of time to think about wrong information. This comic presents a scenario where someone believes wrong information: git branches have rules. Git branches do not in fact have rules. This is wrong information. Why would we talk about wrong information? We talk about wrong information because other people do not have up to date and correct information. We can try to just update their information to be correct, but that does not always work. In some cases they have built a structure of reasoning based on their belief. It is traumatic to destroy this structure of reasoning without providing a replacement. Thus it can be helpful to understand the bad reasoning (based on wrong information) in order to communicate more effectively.

cryptonector 3y ago
Git branches do have rules. The most basic rule is that if you have a branch checked out and you add a commit, then the branch name moves. Upstreams can also have rules like "no history rewriting".
- csours 3y ago
  Thank you for more correct information.
- jgavris 3y ago
  Git ‘remotes’ can have rules (hooks that run on push, and decline). GitHub has ‘branch protection’ which prevents various changes. But GitHub is not Git. A common misconception lately due to its popularity. Git itself is nothing more than a set of tools to manage the versions of a repository. How you choose to use it is up to you, and what you allow. Solo developer? Rebase, or don’t. Do you collaborate? Maybe consider using a SaaS product like GitHub and setup your rules.
  - cryptonector 3y ago
    > Git itself is nothing more than a set of tools to manage the versions of a repository. "Git" is also the protocol, not just the implementation. Indeed, here I'm referring to the Git protocol more than to the Git implementation. There are multiple implementations of the Git protocol. GitHub is but one of several. > But GitHub is not Git. To the client it's indistinguishable.

munk-a 3y ago

Git branches have rules on origin - those rules are enforced with a big stick. What you do in your own clone of the repository is between you and god alone.

deleted 3y ago
[deleted]

User23 3y ago

The reflog is not always there. By default git gc only keeps the last 90 days.

piinbinary 3y ago

Another rule that git branches do not have: they don't have to have originally come from the same repo. You can pull a branch from a different project if you want to. (This is useful if you are trying to combine two repos while preserving history.)

manbash 3y ago

With respect, the person doesn't understand the purpose of git. Doing 'git pull' often would fit for a very specific workflow, and one that in time proves to be a wrong workflow, in my opinion. Don't do things that don't have a conscious purpose.

not2b 3y ago
You are commenting on one page of a webzine, written by a person who has used git for years and has written lots of educational material on git and other technical subjects. She understands the purpose of git. In the linked comic she is pointing out, correctly, that while there are conventions that make good workflows, git doesn't enforce them and allows you to do stupid stuff. Surely you don't disagree with that.

tonymet 3y ago

Git is a distributed system, meaning that you're supposed to have different histories. Git gives you the tools to allow any member of the team to reconcile those histories cleanly for others. Forcing everyone to be in sync all the time also means lots of merge conflicts. Git allows for everyone to drift in their own way and provides tools for them to reconcile that drift in a way that others can integrate easily. Until you embrace the distributed nature and start using tools to manage your history (rebase & reset) , you will suffer with git. I cringe when editors refer to "rebase & reset" as "weird". Rebase and reset are the primary power tools of git. Along with reflog, revert, interactive-add . The worst repositories I've seen are people who `git merge` 20x a day to stay "in sync" and create labyrinthian change logs that are impossible to parse.

tsimionescu 3y ago
Paying the cost of a distributed system for a centralized team of 10 is a horrible idea. Better for someone on the team to teach everyone else a simple set of rules (git checkout -b before starting a new featire, git pull --rebase origin to keep up to date, git push origin when you're done) and pretend Git is a centralized system as much as possible. You're anyway going to have a central server which is the source of truth. If your local copy goes bad, there's always rm -rf ./ && git clone. No reason to pretend your local history has some value. Of course, if you are working on a highly distributed project, like the Linux kernel, many of the Git tools are absolutely invaluable. But there's no reason to bother with them if you're not.
- tonymet 3y ago
  I like your idea of feature branches, but people do need to know the data model and how to manage their history. They will inevitably be out of sync and clumsily tring to get merge all day to get their files in sync. Keeping the history clean is more important than just syncing files.
fouric 3y ago
This seems like a reasonable take - there's only one problem: you haven't told us how to draw the rest of the owl. How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?

deleted 3y ago

[deleted]

cryptonector 3y ago

This is not a problem. I rewrite history all the time, locally (where locally means "unpublished" rather than "not pushed anywhere"). This is a feature. Upstream branches can and do have rules, like "fast-forward only pushes", which means "no history rewriting here (because this branch is published)".

tripleo1 3y ago

This is more interesting: https://timothya.com/blog/git-stack/ https://timothya.com/blog/git-stack/ https://gitlab.com/wavexx/git-assembler https://gitlab.com/wavexx/git-assembler https://www.thregr.org/wavexx/software/git-assembler/ https://www.thregr.org/wavexx/software/git-assembler/