[vtk-developers] git stupid question #4

[Brad King]

Biddiscombe, John A. wrote:
> I'm afraid I don't understand what your reply means.

My understanding is that you're trying to maintain a set of local
changes on top of upstream ParaView.  Here is how it should work:

 ...o----o  kitware/master
     \
      A----B *cscs-pv

Each letter represents a commit, ascii-art lines represent ancestry
(each commit is preceded by its parent commit(s)).  Upstream work
is on "master".  Your work is on "cscs-pv", consisting of commits
A and B.  It is based on some version in master's history when you
created the "cscs-pv" branch.  The "*" indicates in this notation
that the branch is your current HEAD (the version you currently have
checked out in your work tree on disk).

Now, your goal is to integrate upstream work into your local branch.
To do this, you run "git pull kitware master".  First, that fetches
new work from upstream, say one commit, giving:

 ...o----o----o  kitware/master
     \
      A----B *cscs-pv

Then, it merges the work into your branch:

 ...o----o----o  kitware/master
     \         \
      A----B----M *cscs-pv

During creation of commit M there may be conflicts.  If so, it stops
and asks you to edit the files to resolve the conflicts, and then do

 $ git add -- (files)
 $ git commit

The commit command creates 'M' in the graph and updates your local
cscs-pv branch and HEAD to point at it as shown above.  Once this
has been done, all changes from both sides of the merge have been
considered and will not be considered again.  Therefore the merge
conflicts should not occur again.

Next, in the future when you want to merge from upstream again,
run the same command "git pull kitware master".  It will fetch any
new commits from upstream and merge them into your local branch:

 ...o----o----o----o kitware/master
     \         \    \
      A----B----M----o *cscs-pv

This time you should only see conflicts involving changes since the
last merge.

After that, if you *rebase* your work, you'll get this:

 ...o----o----o----o kitware/master
                    \
                     A'----B' *cscs-pv

Note the prime (') on each commit label.  In this notation that
means that the commit A' is the same change as commit A, but it
is a new commit object because it is based on a different commit.
The rebase replays changes you've made on your branch on top of
the new upstream version.  This will require resolving conflicts
again.  That's one reason merging is better than rebasing.

All of the above assumes you're not trying to make any commits to
push back to upstream.  Don't work too hard trying to learn how
to push stuff upstream yet; we're about to change how it is done.

-Brad