Re: git: avoiding merges, rebasing

[Bruno Haible]

Hello Benoit,

> You shouldn't pull if you want to rebase.  Read man git-pull, it  
> clearly states that pull = fetch + merge in current branch.  If you  
> want to rebase, you don't want to merge.  That's why you had to solve  
> conflicts twice (once for merge, once for rebase).  The resulting  
> commit tree will also have an extra commit (that of the merge done by  
> git-pull) which is stupid since the goal of rebase is to preserve a  
> linear history and have your commits on top of it (so why add merge- 
> commits if there is no merge in the end?).

Thanks for explaining. It was all motivated by the desire to do a merge
without getting into the business of branches.

> > $ git pull
> > Updating 61135ee..0f0eb9b
> > ChangeLog: needs update
> > fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
> 
> You can't merge (and thus can't pull) if your tree is not clean.   
> Possible solutions:
>    1. commit your change if it's ready for commit.
>    2. stash your changes away (man git-stash, requires git >= 1.5.3)
> 
> I personally use git-stash:
> $ git stash
> $ git pull / fetch+rebase
> <solve conflicts + commit>
> $ git stash apply
> $ git stash clear # unless you want to keep the stash

Thanks a lot! This indeed solves the problem for me. (It also does a
"git add ." but this can be undone through "git reset".)

Both the following work for me:

  $ git stash
  $ git pull
  $ git stash apply
  <resolve conflicts>
  $ git stash clear
  $ git reset

as well as:

  $ git stash
  $ git fetch
  $ git rebase origin/master
  $ git stash apply
  <resolve conflicts>
  $ git stash clear
  $ git reset

> Pitfalls:
>    - Changing branch while having uncommitted changes will work and  
> keep the changes (if the merge is not trivial, otherwise it will bail  
> out with an error).
>      http://marc.info/?l=git&m=118975544126497&w=4

This is one of the reasons why I want to avoid "git checkout" without -b.

Thanks for a very helpful answer!

Bruno