4 ms·

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull dow

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the version control system should be doing.

oivey 4y ago
I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.
samtheprogram 4y ago
These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method. Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.
- bergenty 4y ago
  There shouldn’t be different ways to handle the same problem. It should literally be 4 features and call it a day. Simplicity is a feature.
gspr 4y ago
With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.
- dotancohen 4y ago
  > And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
  - oivey 4y ago
    Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?
    - CuriousCosmic 4y ago
      Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place. If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested. If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
      - oivey 4y ago
        Makes sense. I guess I just implicitly assumed the workflow of rebasing personal stuff and usually merging externally visible stuff.
Akronymus 4y ago
I use stashes all the time, when I realize I am working on the wrong branch.
- dreamcompiler 4y ago
  Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files. To me, rebases are the work of the devil and I never use them. To each their own I guess.
  - Akronymus 4y ago
    > Stashes seem very mysterious to many people. Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)
  - mariusor 4y ago
    Personally I never understood why the stash needs to be a stack. I can't think of a time when the order in which changes have been stashed has mattered, outside of dropping the older ones.
thunderbong 4y ago
You should give Fossil a shot https://fossil-scm.org https://fossil-scm.org

oivey 4y ago

I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.

samtheprogram 4y ago

These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method. Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.

bergenty 4y ago
There shouldn’t be different ways to handle the same problem. It should literally be 4 features and call it a day. Simplicity is a feature.

gspr 4y ago

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

dotancohen 4y ago
> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
- oivey 4y ago
  Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?
  - CuriousCosmic 4y ago
    Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place. If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested. If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
    - oivey 4y ago
      Makes sense. I guess I just implicitly assumed the workflow of rebasing personal stuff and usually merging externally visible stuff.

Akronymus 4y ago

I use stashes all the time, when I realize I am working on the wrong branch.

dreamcompiler 4y ago
Stashes seem very mysterious to many people. They're one of the most sensible parts of git IMHO. They're just a stack of changes to your files. To me, rebases are the work of the devil and I never use them. To each their own I guess.
- Akronymus 4y ago
  > Stashes seem very mysterious to many people. Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)
- mariusor 4y ago
  Personally I never understood why the stash needs to be a stack. I can't think of a time when the order in which changes have been stashed has mattered, outside of dropping the older ones.

thunderbong 4y ago

You should give Fossil a shot https://fossil-scm.org https://fossil-scm.org