Hacker News Reader

Comment by hannofcart | Hacker News Reader

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/

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.

View on HN

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.

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

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.

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

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.

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.

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`.

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.

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.

On occasion, others will force push their feature branch that's associated with a merge/pull request. In that case, running git fetch origin and git reset --hard origin/branch-name to get your local tracking branch in the same state as the remote is the appropriate thing to do.

Indeed, I forgot that I have `git fetch` also disguised under my `git mr` alias :)

I am with you on this one. Pull existing by default is one of the numerous aberration of git. It is just an alias for fetch/merge or fetch/rebase anyway. It doesn't even work the same way for everyone as you can configure what it does.

It's up there with stashes (which actually are just temporary commits ahead of the head anyway) and staging as things which shouldn't be there by default.

Git really likes making things complicated for newcomers.

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

Reply on news.ycombinator.com