4 ms·

I think git is here to stay for a long time. However, I wonder if there's space for a command line git wrapper makes it much harder to shoot yourselves in the f

I think git is here to stay for a long time. However, I wonder if there's space for a command line git wrapper makes it much harder to shoot yourselves in the foot via scenarios documented at: https://ohshitgit.com/ https://ohshitgit.com/ I imagine this could be achieved by using more intuitive nouns for subcommands (reflog, rebase) and giving informative warning messages on the command line when you are about to screw something up irrevocably. Eventually, one would hope that some of the more effective features of such a wrapper can find their way back to the git project itself.

wickedOne 6y ago
git has a steep learning curve for sure, but eventually scenarios described at oshitgit should be common knowledge for anyone using it. personally i think putting out sites like that is more helpfull than dumbing down git
IgorPartola 6y ago
git pull rebase should be a top level command for example. Now you don’t get extraneous merge commits if you pull after making a local commit. I have it as an alias for git pull.
- jasonpeacock 6y ago
  You can make that the default `pull` behavior in your Git config: git config --global pull.rebase true You should also enable `rerere`[0]: git config --global rerere.enabled true [0] https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
- u801e 6y ago
  Personally, I think that git pull should not be a command that one can run in normal situations. The common expectation when one is making changes, is to commit and then push. So why shouldn't the same apply when getting changes from the remote. That is, fetch and then apply to the local work tree.
  - 8note 6y ago
    I'm not sure what I'd gain from that. I'm not going to undo my colleagues work so I can put mine in instead
    - u801e 6y ago
      But you need to figure out how to integrate your collegue's work into your own working tree. Automatically merging the changes isn't what should be done in all cases.
    - ptx 6y ago
      This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your uncommitted changes or merging your commits right at that very moment.
      - seba_dos1 6y ago
        Well, if I want to look at my colleagues' work without disturbing my uncommitted changes or merging my commits right at that very moment, I use `git fetch`.
        ptx 6y ago
        Right, as do I. And "git fetch", as u801e was saying further up the thread, is perhaps what most people should actually prefer most of the time. Mercurial only has this pure fetch operation (although it calls it pull) and no combined fetch-and-merge operation. There is no reason fetching and merging have to be connected, so perhaps the most prominent command (as a counterpart to "push") shouldn't be this combined operation.
        seba_dos1 6y ago
        OTOH, I use `git fetch` very rarely, since it's super rare to have unpushed or uncommited changes on the branch where I want to pull others' work from - so, in practice, I usually use `git pull`. The workflow is usually like this: 1. Work on my branch. 2. Checkout to master (with `git stash` if needed) 3. `git pull` 4. Do whatever I wanted to do with the updated branch (switch back and rebase, or test something, or start a new branch etc.) In a code-reviewed, merge request-oriented workflow there's little point in splitting `git pull` into separate commands.

wickedOne 6y ago

git has a steep learning curve for sure, but eventually scenarios described at oshitgit should be common knowledge for anyone using it. personally i think putting out sites like that is more helpfull than dumbing down git

IgorPartola 6y ago

git pull rebase should be a top level command for example. Now you don’t get extraneous merge commits if you pull after making a local commit. I have it as an alias for git pull.

jasonpeacock 6y ago
You can make that the default `pull` behavior in your Git config: git config --global pull.rebase true You should also enable `rerere`[0]: git config --global rerere.enabled true [0] https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere
u801e 6y ago
Personally, I think that git pull should not be a command that one can run in normal situations. The common expectation when one is making changes, is to commit and then push. So why shouldn't the same apply when getting changes from the remote. That is, fetch and then apply to the local work tree.
- 8note 6y ago
  I'm not sure what I'd gain from that. I'm not going to undo my colleagues work so I can put mine in instead
  - u801e 6y ago
    But you need to figure out how to integrate your collegue's work into your own working tree. Automatically merging the changes isn't what should be done in all cases.
  - ptx 6y ago
    This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your uncommitted changes or merging your commits right at that very moment.
    - seba_dos1 6y ago
      Well, if I want to look at my colleagues' work without disturbing my uncommitted changes or merging my commits right at that very moment, I use `git fetch`.
      - ptx 6y ago
        Right, as do I. And "git fetch", as u801e was saying further up the thread, is perhaps what most people should actually prefer most of the time. Mercurial only has this pure fetch operation (although it calls it pull) and no combined fetch-and-merge operation. There is no reason fetching and merging have to be connected, so perhaps the most prominent command (as a counterpart to "push") shouldn't be this combined operation.
        seba_dos1 6y ago
        OTOH, I use `git fetch` very rarely, since it's super rare to have unpushed or uncommited changes on the branch where I want to pull others' work from - so, in practice, I usually use `git pull`. The workflow is usually like this: 1. Work on my branch. 2. Checkout to master (with `git stash` if needed) 3. `git pull` 4. Do whatever I wanted to do with the updated branch (switch back and rebase, or test something, or start a new branch etc.) In a code-reviewed, merge request-oriented workflow there's little point in splitting `git pull` into separate commands.