Re: [Emc-developers] Git Goofs

[Sebastian K. <se...@hi...>]

> What am I doing wrong? I keep pushing trivial merges by accident.
>
> My process is to work in a separate branch, then cherry-pick the
> commits into my tracking branch, then push --dry-run and git log to
> make sure it looks right, then push.
>
> So, what part of that process is pushing a merge?

I don't believe you!  I think nothing in the process you described 
creates merges.  I think you left something out.

Here's the top couple of commits in v2.5_branch right now:

0 seb@dirt /home/seb/emc2.git>   git log --graph --pretty=format:'%h  %ad %an -- %s' 2e13c3a..origin/v2.5_branch
*   43a1574  Fri Sep 30 00:52:39 2011 +0100 Andy Pugh -- Merge branch 'v2.5_branch' of ssh://git.linuxcnc.org/git/emc2 into v2.5_branch
|\
| * 799075f  Mon Aug 29 09:17:29 2011 -0700 Dewey Garrett -- encoder_ratio: support names= option
| * d782cf5  Mon Aug 29 09:15:07 2011 -0700 Dewey Garrett -- sim_encoder: support names= option
| * 7e7158a  Mon Aug 29 09:13:25 2011 -0700 Dewey Garrett -- at_pid: support names= option
| * 8afcf37  Mon Aug 29 09:11:25 2011 -0700 Dewey Garrett -- siggen: support names= option
| * 77a0082  Mon Aug 29 09:08:15 2011 -0700 Dewey Garrett -- pid: bugfix: use howmany not num_chan in test
| * bc5b33c  Mon Aug 29 09:03:56 2011 -0700 Dewey Garrett -- encoder: rename export_counter to export_encoder
| * 1ee985d  Sun Sep 25 23:49:14 2011 -0700 cmorley -- pncconf - set dac scale and dac max output to default of 10
| * 32ab33a  Sun Sep 25 23:39:50 2011 -0700 cmorley -- pncconf - add detail about dac scale and max output
* | d467b5e  Fri Sep 30 00:49:41 2011 +0100 Andy Pugh -- Make it possible to alter bldc.N.encoder-offset live.
* | 067285c  Fri Sep 30 00:45:52 2011 +0100 Andy Pugh -- Remove completely bogus arithmetic from 8i20 driver.
|/
* cf36cff  Sat Sep 24 00:41:59 2011 -0700 cmorley -- pncconf -fix stepgen's max velocity,max acceleration setting
* 5a0cf8a  Sat Sep 24 00:40:29 2011 -0700 cmorley -- pncconf - add max velocity override capability


This looks to me like you had last fetched origin sometime between Sep 
24 00:41 and Sep 25 23:39.  Your local v2.5_branch was updated to 
cf36cff in your repo.  Then on Sep 30 just after local midnight you made 
your commits 067285c and d467b5e and put them into your local v2.5_branch.

In between your fetch and your commits, Chris Morley and Dewey Garret 
were pushing their commits to v2.5_branch in the central repo - their 
commits' timestamps are between your shared ancestor's timestamp and 
your commits' timestamps.

When you went to push your v2.5_branch, git informed you that your 
v2.5_branch had diverged from origin's.  You probably did "git pull" at 
that point, which is shorthand for "git fetch; git merge", and that's 
where your extra merge came from: "git pull" merged origin/v2.5_branch 
(with Chris and Dewey's commits) into your local v2.5_branch with your 
new commits.  You pushed the result and here it is, gracing our shared 
repo for all time.  ;-)

Let me try to describe my git work flow, which avoids spurious merges.

My steady state is that I have a fairly up-to-date copy of our shared 
repo (origin, aka git.linuxcnc.org) inside my repo.  I update my copy of 
our shared history often with "git fetch origin", which *only* syncs the 
upstream repo into my local repo, it doesn't monkey with any of my local 
branches.  I never use "git pull", because it *does* monkey with local 
branches, and I'm anal enough that I want total control over that.

Ok, so i safely stay up to date with origin using "git fetch", and i do 
it often because it's quick and safe and doesnt require any real attention.

I usually have several local branches that i'm working on.  These are 
branches I don't push off my private development machines, so i can do 
with them as i please and they don't affect anyone else.  Some of my 
local branches are based on origin/v2.4_branch, some are based on 
origin/v2.5_branch, and some on origin/master.  When I fetch, the 
origin/* branches move, but my local branches are unaffected.

When I want to work on one of my local branches, my workflow goes like this:

git fetch origin               # always stay up-to-date!
git checkout my-branch         # let's say this one's based on origin/v2.5_branch
git rebase origin/v2.5_branch  # this is the secret sauce


The rebase command is one of my absolute favourite things about git. 
  Rebase can do a couple of cool things, but in the simple use case 
above, it says: find the most recent common ancestor between the current 
branch (my-branch) and the one i'm rebasing onto (origin/v2.5_branch). 
  "Rewind" the commits on my-branch until you get to that ancestor. 
  Fast-forward my-branch up along origin/v2.5_branch until you get to 
the tip.  Then "replay" the original commits from my-branch on the tip 
of origin/v2.5_branch.

Each commit that rebase replays can potentially have a "merge conflict", 
which you then manually resolve in the context of that commit.  This 
way you never have merges or merge conflicts in the final history, 
because each little conflict gets resolved in the commit that introduced 
it.  The history looks linear and neat.

Ok, so after the fetch and rebase, you have an up-to-date 
origin/v2.5_branch in your repo, and my-branch is a pure fast-forward 
from origin/v2.5_branch.  So you can just push it, and no extra merges 
are needed.

If my words above are not clear, take a look at the git rebase help, it 
does a pretty good job of laying out graphically what happens.

And if that wasnt enough to make you a little weak in the knees and/or 
dizzy, check out "git rebase --interactive".  It lets you rewrite and 
clean up local history before pushing to the shared repo...  But that'll 
be the topic for another email, if anyone wants it.


-- 
Sebastian Kuzminsky