bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git: avoiding merges, rebasing


From: Bruno Haible
Subject: Re: git: avoiding merges, rebasing
Date: Sun, 30 Sep 2007 16:48:30 +0200
User-agent: KMail/1.5.4

Hello Jim,

> >   - Did "git pull". It told me:
> 
> Then (everything is committed), you switch to the trunk and pull
> (update from public repo) from there:
> 
>   git checkout master
>   git pull
> 
> then go back to your branch and use git-rebase to make your branch
> change set(s) apply cleanly to the new tip of the trunk:
> 
>   git checkout branch-B
>   git rebase master
> 
> The rebase is where you'll resolve any conflicts.

OK, then my problem was that I did "git pull" without a rebase step.

Remember that I don't like to use "git checkout", because I want to memoize
my working topic by directory name, and not have git modify my source files
unnecessarily when I have built object files in the same directory.

In this situation, I wanted to use "git pull" just to update my changes
and let me reduce conflicts. This is not the moment where I want to start
bookkeeping (adding files, thinking about a commit message etc.)

$ git checkout master
M       ChangeLog
Already on branch "master"

$ git pull
Updating 61135ee..0f0eb9b
ChangeLog: needs update
fatal: Entry 'ChangeLog' not uptodate. Cannot merge.

$ git rebase master
ChangeLog: needs update

What am I supposed to do here?
  - "git fetch" does too not enough: it only fetches changes but does not
     store them in my "master" branch.
  - "git rebase master" without "git add" does nothing;
    "git rebase master" after "git add" tells me
    "Current branch master is up to date.".
  - "git pull" after "git add" forces me to do conflict resolution and
    creates a diamond commit.

> > Here's what I did:
> >   - Created some modifications to the ChangeLog and other files.
> 
> First off, it's best to make local changes on a branch,
> and to commit them there.

What happens then? Let's try it.

  - Take a git checkout from two hours ago.
  - "git checkout -b private"
  - Created some modifications to the ChangeLog and other files.
  - git add ChangeLog
  - git commit
  - "git rebase master" tells me: Current branch private is up to date.
  - "git pull" fetches some changes into the repository but then says
    Warning: No merge candidate found because value of config option
             "branch.private.merge" does not match any remote branch fetched.
  - "git-config branch.private.merge refs/heads/master"
  - "git pull" then tells me:
    Auto-merged ChangeLog
    CONFLICT (content): Merge conflict in ChangeLog
    Automatic merge failed; fix conflicts and then commit the result.
  - So I resolve the conflict in ChangeLog.
  - git add ChangeLog
  - git commit
  - git rebase master
    works fine without a human interaction!

So, in summary:

* People who don't want to switch branches in a directory should, right after
  cloning, do
    git checkout -b private
    git-config branch.private.merge refs/heads/master
  This enables "git pull" to do merges, which it refuses to do if you're on
  the "master" branch.

* Without "git add" and "git commit", git never does merges, fearing to
  destroy your working file.

* In such a situation, it's the "git pull" where the conflict resolution
  happens; the "git rebase master" then works unattended.

Right?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]