"tla missing -s" equivalent with git/cogito

"tla missing -s" equivalent with git/cogito

[Belmar-Letelier]

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 paul@mail.com--public/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 paul@mail.com--public/project--paul--0.1

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

$ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6

tks


-- 
Luis

Re: "tla missing -s" equivalent with git/cogito

[Andreas Ericsson]

Belmar-Letelier wrote:
> 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 paul@mail.com--public/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 paul@mail.com--public/project--paul--0.1
> 
> or I cherry pick only one of them (here patch-6) with
> 
> $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: "tla missing -s" equivalent with git/cogito

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> 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).

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.

Re: "tla missing -s" equivalent with git/cogito

[Martin Langhoff]

On 1/19/06, Junio C Hamano <junkio@cox.net> wrote:
> 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

Cogito wishlist: ability to set merge strategy

[H. Peter Anvin]

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

Re: Cogito wishlist: ability to set merge strategy

[Petr Baudis]

Dear diary, on Tue, Jan 17, 2006 at 04:29:49AM CET, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> 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.

Dear diary, on Wed, Jan 18, 2006 at 07:06:07PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> One of these days I'll convince Pasky to use git-merge for
> cg-merge's internals.

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

Re: Cogito wishlist: ability to set merge strategy

[Martin Langhoff]

On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:
> though. From the Git merge strategies, I guess only recursive is
> useful for Cogito...

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)

> Patches welcome.  ;-)

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

Re: "tla missing -s" equivalent with git/cogito

[Martin Langhoff]

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

On 1/19/06, Belmar-Letelier <luis@itaapy.com> wrote:
> arch-tla equivalent of
>
> $ cd project--luis--0.1
> $ tla missing -sD paul@mail.com--public/project--paul--0.1

 $ 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

> 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 paul@mail.com--public/project--paul--0.1

 # 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

> or I cherry pick only one of them (here patch-6) with
>
> $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6

  # 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

Re: "tla missing -s" equivalent with git/cogito

[Petr Baudis]

Dear diary, on Wed, Jan 18, 2006 at 06:56:38PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> Andreas' response is good is you're into pure git. Let me add some
> cogito tricks ;-)
> 
> On 1/19/06, Belmar-Letelier <luis@itaapy.com> wrote:
> > arch-tla equivalent of
> >
> > $ cd project--luis--0.1
> > $ tla missing -sD paul@mail.com--public/project--paul--0.1
> 
>  $ 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

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).

> > or I cherry pick only one of them (here patch-6) with
> >
> > $ tla replay  somefriend@mail.com--public/project--branchA--0.1--patch-6
> 
>   # 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

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.

> 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.

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

Re: "tla missing -s" equivalent with git/cogito

[Martin Langhoff]

On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:
> 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:
...
> And you get a conflict instead of b\nc.

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

Re: "tla missing -s" equivalent with git/cogito

[Petr Baudis]

Dear diary, on Wed, Jan 18, 2006 at 08:07:27PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:
> > 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:
> ...
> > And you get a conflict instead of b\nc.
> 
> 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.

  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