> 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 ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
