"tla missing -s" equivalent with git/cogito

It would be nice if Cogito would let one override the default merge strategy, i.e. to use the recursive merge strategy. I've had some moderate luck with using recursive merge for the klibc trees recently.

-hpa

Hello,

Could someone say me how we do in cogito or git the

arch-tla equivalent of

$ cd project--luis--0.1
$ tla missing -sD [email protected]/project--paul--0.1

so I get the information like what are the interesting patch to get

and then I take all of them with

$ tla star-merge -t [email protected]/project--paul--0.1

or I cherry pick only one of them (here patch-6) with

$ tla replay  [email protected]/project--branchA--0.1--patch-6

tks

Luis

Not that I'm even half aware of how arch does this, but if the two repos are cloned from the same one (which they seem to be), you could just do

	$ git checkout -b paul
	$ git pull <path-to-pauls-repo> <branch-from-pauls-repo>

The "pull" above will do the merging nessecary. You can merge several branches at once if you like (known as "doing an octopus" in gittish. I imagine that's a star-merge in arch).

Then, if you want to cherry-pick commits from Paul's repo to your master-branch, you do

	$ git checkout master
	$ git cherry-pick -r paul~3

to replay the commit 3 steps below the tip of Paul's latest commit in the branch you just pulled from.

If you want to import all of them into your own master branch you can do

	$ git checkout master
	$ git pull . paul

You can also do

	$ cd pauls-repo
	$ git format-patch --mbox -k HEAD~10 -o /your/repo
	$ cd /your/repo
	$ git am -k 00*.txt

but that has the feel of doing things the wrong way around (exporting from a repo to import to another should be done by a fetch or, if you want to merge them into whatever branch you're currently on, a pull).

Two things worth noting:
* git repositories are damn near indestructible, so long as you don't run "git prune" while mucking around doing very strange things or suffer hardware failure. Don't be afraid to experiment.

* gitk is your friend for finding out where you are in the repo and what actually happens when you merge, reset, revert, rebase, commit, pull, fetch, branch, tag or does something else entirely. Use it. You'll be glad you did.

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Arch star-merge is not an octopus. They have different "merge strategy" just like we have more than one. No, I do not remember the details of how they do it.

In Arch, star-merge is roughly equivalent to git-merge. When I was an Arch user, I could go out and take a walk under the stars while it tried to work its magic on my 10K file tree -- so the name was quite fitting ;-)

The main difference with git is that it has explicit rename tracking and explicit "patches already applied" tracking. We detect those things at merge time, and in my projects it has so far worked better than tla's explicit tracking of things -- but only when I merge with git-merge. One of these days I'll convince Pasky to use git-merge for cg-merge's internals.

cheers,

martin

Dear diary, on Tue, Jan 17, 2006 at 04:29:49AM CET, I got a letter where "H. Peter Anvin" <[email protected]> said that...

Dear diary, on Wed, Jan 18, 2006 at 07:06:07PM CET, I got a letter where Martin Langhoff <[email protected]> said that...

For the record, I acknowledge that the merge strategies are useful and I plan to make cg-merge use them, but I'm unable to tell when that will happen. I would still like to keep the current Cogito merging the default merge strategy at least for a while until the dust settles down, though. From the Git merge strategies, I guess only recursive is useful for Cogito...

Patches welcome. ;-)

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

I haven't had time to figure out where the problem is, I do have some cases where git-merge does the right thing, and cg-merge gets it wrong. And without renames.

An example from yesterday:
http://locke.catalyst.net.nz/gitweb?p=moodle.git;a=commit;h=b69d60a5141dfe22a073dd9931e6c8ff5dded0b9

(the repo is accessble via http://locke.catalyst.net.nz/git/moodle.org
if anyone is interested)

I know I promised patches in that direction, but I haven't had the time to look into it. Sorry! (and, as a user, I just cheat and fall back to git-merge)

cheers,

martin

Andreas' response is good is you're into pure git. Let me add some cogito tricks ;-)

 $ cd project-luis
 # only if have to do cg-branch-add the first time!
 $ cg-branch-add paul http://server/git/project.git
 $ cg-fetch paul
 # show what paul has that we don't
 $ cg-log -r master:paul
 $ cg-diff -r master:paul
 # show what we have that paul doesn't
 $ cg-log -r paul:master
 $ cg-diff -r master:paul

You can also do

 $ cg-diff -r master:paul

 # if you've done cg-fetch paul and reviewed it what you're about to
merge, just do
 cg-merge paul

# otherwise, for a shortcut of cg-fetch <branch> && cg-merge <branch> do

 $ cg-update paul

  # export the patches paul has that we don't
  $ mkdir .patchesfrompaul
  $ git-format-patch --mbox --signoff -o .patchesfrompaul master paul
  # review the contents of .patchesfrompaul and decide what patches you want
  $ git-am -3 .patchesfrompaul/0006-fix-frob-invocation.txt

Note that git does not track patch application _explicitly_ like Arch does, it tracks them only indirectly. Merges (tla star-merge type of merges) are recorded explicitly. This work surprisingly well. If you do a cg-update, cg-merge or git-merge, git will keep a good record of what points of the history have been merged.

When you cherry pick patches, if the patch applies cleanly, the next time you do a merge from that branch it will be skipped automagically. If the patch needs serious editing, there's a good chance that git will try to apply it again.

cheers.

martin

Dear diary, on Wed, Jan 18, 2006 at 06:56:38PM CET, I got a letter where Martin Langhoff <[email protected]> said that...

I usually do this as

	$ cg-log -m -r paul

which is shorter (and in some situations more accurately describes which commits are actually going to get merged).

But I believe that Belmar-Letelier might be happier with git-cherry, since he wants to do cherrypicking (and wrapping that in cg-log might not be bad idea).

If you just want to pick one commit, it shouldn't be more difficult than

	$ cg-diff -p -r commitid | cg-patch
	$ cg-commit -c commitid

but I was actually thinking about wrapping this up to something like cg-cherrypick or cg-pick. Perhaps I will just overload cg-patch, though
- I want to add support for autocommitting the patches there anyway.

No, it will not be skipped automagically - GIT really does not properly support merging of branch you've cherrypicked before. It might work, but that's just luck - very similar to the luck you might have when re-merging branches in CVS using the original merge base.

Imagine having branch with two patches 1 and 2. There is a file X:

a

Ppatch1:

	-a
	+b
	+c

Patch2:

	-b
	+a
	c

Resulting file:

a
c

Now, you've cherrypicked patch1, so your file is:

b
c

Now you want to merge the branch as a whole. Cherrypicking-aware VCS would just merge the patch2, but you are taking the whole diff:

	a
	+c

And you get a conflict instead of b\nc.

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

...

While I haven't tested your particular example, it looks to me like git-cherry would identify it correctly. So far my experience has been that git-cherry's strategy detects my cherry-picked patches pretty well.

Why would it not work in your example? Patch 1 has clearly been applied in both branches, and git-cherry would normally detect that alright.

btw, when is cg-merge switching to use git-merge? :-p

martin

Dear diary, on Wed, Jan 18, 2006 at 08:07:27PM CET, I got a letter where Martin Langhoff <[email protected]> said that...

It probably would. So? We are talking about git-merge and cg-merge
here. Now, it might be interesting to have a cherry-aware merge strategy, but I suspect that the conflicts handling there would be quite non-trivial.

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams