"tla missing -s" equivalent with git/cogito

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

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

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

On 1/19/06, Belmar-Letelier [off-list ref] 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

Dear diary, on Wed, Jan 18, 2006 at 06:56:38PM CET, I got a letter
where Martin Langhoff [off-list ref] said that...

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

On 1/19/06, Belmar-Letelier [off-list ref] wrote:

quoted

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

quoted

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

On 1/19/06, Petr Baudis [off-list ref] 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

Dear diary, on Wed, Jan 18, 2006 at 08:07:27PM CET, I got a letter
where Martin Langhoff [off-list ref] said that...

On 1/19/06, Petr Baudis [off-list ref] wrote:

quoted

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:

...

quoted

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