On 13 Jul 2009, at 15:55, Hartmut Reuter wrote:
Today I pushed another patch (70), but without being aware of it two
other patches (68 and 69) appeared.
What may have caused this behaviour?
You had what is called a 'merge commit'. This is a commit that git
creates in order to glue branches together. Typically,
what causes this is a workflow that looks like
1) Checkout the upstream code
2) Make a change to that code, and commit it to your local tree
3) git pull the upstream changes into the same branch as you made your
change
So, step 1, gives you a history that looks like:
U1--U2--U3
Step 2 gives
U1--U2--U3--L1
However, between step 2 and step 3 upstream has made some changes (say
U4 and U5), which have U3 as a parent, so you actually have something
like
U4--U5
/
U1--U2--U3--L1
git pull squashes this into a single branch (git pull is actually
equivalent to a git fetch plus a git merge), and you get something like
U4-----U5
/ /
U1--U2--U3--L1--M1
(where the merge commit anchors upstream's changes back into your
branch)
Now, with gerrit we don't need to know about your local merge history.
All we actually care about is your local change, L1.
If you aren't publishing your local git tree, then the easiest way to
deal with all of this is through rebasing. So, you end
up with a workflowing that looks like
1) Checkout the upstream code
2) Create a 'topic branch' to hold your changes
3) Make your changes, and commit them
4) git fetch upstream to stay up to date
5) git rebase your branch.
With diagrams, you have:
1) Initial clone:
U1--U2--U3
2) Create a topic branch:
/
U1--U2--U3
3) Make a local change:
L1
/
U1--U2--U3
4) git fetch changes from upstream:
L1
/
U1--U2--U3--U4--U5
5) git rebase your local change onto the new upstream
L1
/
U1--U2--U3--U4--U5
Hope that helps!
Cheers,
Simon.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
