Re: New branch for No Gnus

[Steinar Bang <sb@dod.no>]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> But I guess I don't really want to merge No Gnus as is into master.  I
> just want to cherry-pick any commits I make, I guess? 

Merges are always better than cherry picks: with merges the commits gets
their original identity and commit time.  You also get a clear ancestry
for the file, and the commits in the file.

> I certainly don't want to merge the commit I just did that bumped the
> version number to No Gnus 0.20, for instance.

What you can do, is always merge with
 cd ~/git/mgnus/
 git fetch
 git merge --no-ff --no-commit orgin/no-gnus

The "--no-ff" means that the merge will always create a merge commit in
the branch you're merging into.  History-wise that's a good thing.

The "--no-commit" tells git merge not to do an auto-commit, but stop,
like it always does of there is a commit.

If you then do `M-x magit-status RET' in cd ~/git/mgnus/ you will see
all files affected by the merge.  And entering the files and doing
`C-x v =' will show the diffs with the current branch.

If you don't want the changes for a particular file at all, eg. you want
to keep the current version of the lisp/silly.el file, do
 git checkout origin/master lisp/silly.el

If you do a `g' in the "magit: mgnus" buffer, you will see that
lisp/silly.el has gone away.

If you get a conflict: enter the file, look at the conflict markers and
edit the file to your satisfaction, and then stage the file.

Once you're satisfied with the merge results, just press `c' in the
"magit: mgnus" buffer, og do
 git commit
at the command line, whatever suits you best.

The best thing about this, is that if the files you don't want merged
doesn't have any changes on the no-gnus branch, you won't be bothered by
them on the next merge.  As far as git is concerned it has already been
merged with the master branch, and the current version on master (which
was the old version on master) is the result.

> So how do I cherry-pick commits?

  git cherry-pick sha1-of-commit

But like I said earlier: if you can do it with regular merges, that's
much to be preferred.

(it's chapter 3 in that book again...)