HN Explorer

13 comments

[ 4.3 ms ] story [ 46.5 ms ] thread
kemayo
`git pull --rebase` is very useful if you use git with an authoritative remote repo, treating your own repo as having disposable history.

In fact, you can make it the default! Just do: `git config --global branch.autosetuprebase always` and every branch you create from now on will be set up to rebase without needing the manual `--rebase`.

Existing branches you can switch by doing: `git config branch.[branch-name].rebase true` in the repo.

trust-me
Ufff, I must be doing something very wrong. Once in a while rebase continue will just fail with cryptic error messages and nothing but a hard reset will let me continue using the repository. Never had a problem with regular git pull.
X-Istence
What are the cryptic error messages?

The only one that I know if is the message stating that the commit is empty ...

In that case simple use git rebase --skip, to skip applying that patch. That tends to happen when after you fix the "merge" conflict after replaying a patch and the changeset is empty.

MBlume
If you're really having trouble using git rebase the escape hatch is git rebase --abort
crazydiamond
So when I create a new branch, do stuff and want to merge back to master, I should rebase instead ? (assuming nothing else was done such as pushing elsewhere etc).
trust-me
Yeap, the advice here is that you should use `pull --rebase` instead of `pull`. What that does is it eliminates the merge commit to the "central" branch (e.g. on github). That is it fakes the history to look as if you started to work on a branch with all the commits applied and so there were no merges necessary.
drewcoo
Rebase is polite, imho. You probably want a pull request that is "clean" for the code reviewers. And future bug chasers. A bunch of interleaved commits makes it harder for anyone to reason about the code history.
oelmekki
I suppose you are talking about making pull requests for an upstream repository owned by someone else (typically : making a pull request to an open source project), in which case you ask to merge your master in their master ?

When working on a repository where you make a pull request from a feature branch to master in the same repos (typically : your company private repos), I would rather merge the feature branch in master rather than rebasing it, at least to know at which point a dev work has been merged.

The same logic stand, though. If developer has used several branches to build her feature, I don't want to know about it : she must rebase them instead of merging them.

Additionally, I like pull requests to master branch to be in a single, well documented commit. So I encourage developers to make a lot of small commits, then use `git rebase -i` to squash them into a single commit with a long and detailed commit message (the one-line previous commit messages being used to write a changelog). Using github, this has the advantage that the commit message of a single commit pull request is automatically pre-filled as pull request message.

npsimons
Number five (rebase instead of merge) is what we started doing shortly before we started using Gerrit. If you've ever gotten sick of seeing all those "merging" commit messages in git, it's worth trying.
perlgeek
Maybe a bit off-topic, but still on the topic of git and merge conflicts:

Soon I will have to do a pretty big merge, with so many conflicts expected that I don't know if I can resolve them in one day. So usually when I have such a non-minimal task, I create a branch for it. Is there any sensible way to do a merge in a branch, and resolve the conflicts on a file-by-file base, with separate commits for each one?

Or maybe some other way to break down many merge conflicts into several small pieces?

(We have a heavily patched version of an open source project at $work, and whenever there is a new upstream release, merging is a huge pain. We do try to contribute some of our changes back to upstream, but many changes are simply too specific to go upstream).