cogito - how do I ???

cogito - how do I ???

[Sam Ravnborg]

Hi all.

While trying to get up to speed on cogito/git I stumbled across
a few things that I at least did not find available in cogito.

1) Something similar to "bk changes -R". I use this to see what has
happened upstream - to see if I really want to merge stuff.

2) Export of individual patches. "bk export -tpatch -r1.2345"
I have nu public git repository yet so I have to feed changes as
plain patches. Browsing cg-* I did not find the command to do this.

I do try to avoid having to develop my little army of shell scripts,
and due to this I have avoided the git- commands for now.

Any help appreciated,
	Sam

Re: cogito - how do I ???

[Sean]

On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:
> Hi all.
>
> While trying to get up to speed on cogito/git I stumbled across
> a few things that I at least did not find available in cogito.
>
> 1) Something similar to "bk changes -R". I use this to see what has
> happened upstream - to see if I really want to merge stuff.

Not sure what bk did here, but you can do something like:

cg-pull origin
cg-log -c -r origin

To see what is at the head of the unmerged objects you just pulled down,
and if you want to merge then "cg-merge origin".  Although as far as I
know there's no way to have the log stop automatically at the proper spot.

> 2) Export of individual patches. "bk export -tpatch -r1.2345"
> I have nu public git repository yet so I have to feed changes as
> plain patches. Browsing cg-* I did not find the command to do this.

cg-diff -p -r SHA1

Which asks for the diff from the parent (-p) to the revision (-r).

Sean

Re: cogito - how do I ???

[Linus Torvalds]

On Sat, 21 May 2005, Sean wrote:

> On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:
> > Hi all.
> >
> > While trying to get up to speed on cogito/git I stumbled across
> > a few things that I at least did not find available in cogito.
> >
> > 1) Something similar to "bk changes -R". I use this to see what has
> > happened upstream - to see if I really want to merge stuff.
> 
> Not sure what bk did here, but you can do something like:
> 
> cg-pull origin
> cg-log -c -r origin

In the raw git interfaces, you'd basically have to do the same thing that
"git-pull-script" does, except that _instead_ of calling the
git-resolve-script thing, you'd do

	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin

to show what is in the downloaded MERGE_HEAD but not in HEAD.

> > 2) Export of individual patches. "bk export -tpatch -r1.2345"
> > I have nu public git repository yet so I have to feed changes as
> > plain patches. Browsing cg-* I did not find the command to do this.
> 
> cg-diff -p -r SHA1

And again, without the porcelain this is:

	git-diff-tree -v -p <name>

(Basically, you can do _anything_ with "git-diff-tree". For example, you 
want "cg log"? Do

	git-rev-list HEAD | git-diff-tree --stdin -v -m -s

which is basically what "git-whatchanged" does).

		Linus

Re: cogito - how do I ???

[Sam Ravnborg]

> > > 1) Something similar to "bk changes -R". I use this to see what has
> > > happened upstream - to see if I really want to merge stuff.
> > 
> > Not sure what bk did here, but you can do something like:
> > 
> > cg-pull origin
> > cg-log -c -r origin
> 
> In the raw git interfaces, you'd basically have to do the same thing that
> "git-pull-script" does, except that _instead_ of calling the
> git-resolve-script thing, you'd do
> 
> 	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin
That looks ... long.
I can teach my fingers to use: cg-log, but the above is just too much 
to type/remeber do a daily operation.

In bk the usage pattern was to check what was in mainline _before_
fetching and merging. So it seems that with git/cogoto one
has to fetch the chages, inspect them, and then decide to apply or not.

When the fetches changes stay in MERGE_HEAD I assume my work when
committed will be based on top of HEAD - so I do not have to know
if I have fetched some (unmerged) updates.

> to show what is in the downloaded MERGE_HEAD but not in HEAD.
> 
> > > 2) Export of individual patches. "bk export -tpatch -r1.2345"
> > > I have nu public git repository yet so I have to feed changes as
> > > plain patches. Browsing cg-* I did not find the command to do this.
> > 
> > cg-diff -p -r SHA1
> 
> And again, without the porcelain this is:
> 
> 	git-diff-tree -v -p <name>

The key here is the SHA1. I hoped to avoid specifying SHA1's with
cogito, I so often miss one character when doing copy'n'paste.


Thanks all for the replies. Now I feel a bit more confident in this.


	Sam

Re: cogito - how do I ???

[Linus Torvalds]

On Sun, 22 May 2005, Sam Ravnborg wrote:
>
> > > > 1) Something similar to "bk changes -R". I use this to see what has
> > > > happened upstream - to see if I really want to merge stuff.
> > > 
> > > Not sure what bk did here, but you can do something like:
> > > 
> > > cg-pull origin
> > > cg-log -c -r origin
> > 
> > In the raw git interfaces, you'd basically have to do the same thing that
> > "git-pull-script" does, except that _instead_ of calling the
> > git-resolve-script thing, you'd do
> > 
> > 	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin
> That looks ... long.

That's why people don't generally use git natively. 

I want teach people what the "raw" interfaces are not because you're 
supposed to use them, but because I expect that the raw ones are useful 
for scripting.

> In bk the usage pattern was to check what was in mainline _before_
> fetching and merging.

In git (and cogito, although it's less obvious), the "fetching" is totally 
separate from the "merging". In BK, the two were the same - you couldn't 
merge without fetching, and you couldn't fetch without merging.

> So it seems that with git/cogoto one has to fetch the chages, inspect
> them, and then decide to apply or not.

Well, that's really what you ended up largely doing in BK too, since even
if it _looks_ like you first inspect them with "bk changes -R", the fact
is, in order to do that, you do have to _fetch_ the data first. It's just
that BK (a) fetched just the changeset changes (I think) and (b) then
threw the data away.

With git, you can also do the "fetch just the changeset changes", since if 
you use "git-http-pull" you can instruct it to first _only_ fetch the 
actual commits, and forget about the actual data. But since git considers 
"fetching" and "merging" totally separate phases, it's up to your scripts 
whether they leave the objects around or not afterwards. The normal 
operaion is to leave everything around, since that means that if/when you 
do decide to merge, you already have the data, and you don't need to 
re-fetch.

If you decide to throw it away, you first remove the reference to the
stuff you pulled, and then use "git-prune-script" to get rid of the
objects you used. Right now that is admittedly quite expensive, it's
considered a "rare" thing to do (sicne even if you decide not to merge,
the extra objects never hurt - you can prune things once a week if you
care).

> When the fetches changes stay in MERGE_HEAD I assume my work when
> committed will be based on top of HEAD - so I do not have to know
> if I have fetched some (unmerged) updates.

Yes. Note that MERGE_HEAD ends up being just a totally temporary reference
to the top (that you decided not to merge). It has no meaning for git
itself, and the naming and meaning is purely as a git-pull-script (and
git-resolve-script) internal temporary thing.

> > And again, without the porcelain this is:
> > 
> > 	git-diff-tree -v -p <name>
> 
> The key here is the SHA1. I hoped to avoid specifying SHA1's with
> cogito, I so often miss one character when doing copy'n'paste.

You don't have to use the raw SHA1. git understands tags and references, 
so for example, if you take the "fetch" part of git-pull-script (I really 
should split it up into "git-fetch-script"), then you can, for example, do

	git-diff-tree -v -p MERGE_HEAD

to see the top of the (unmerged) thing. Similarly, doing a

	git-rev-list MERGE_HEAD | git-diff-tree --stdin -v -s

will give you the changelog for the unmerged side. No SHA1's necessary.

Of course, if you don't have a reference to the thing you want to look at, 
you do need to figure out the SHA1 some way. But for example, gitk will 
work fine for the unmerged stuff too - ie you can do

	gitk MERGE_HEAD ^HEAD

_before_ you merge, and get all the nice graphical tools to inspect what 
the hell there is that is new there..

Notice how this "fetch is independent of merge" thing thus means that you 
can do a lot _more_ than "bk changes -R" ever did. But yes, it's a bit 
more complex too (so normally you'd probably only use the porcelain 
layer).

		Linus

Re: cogito - how do I ???

[Thomas Glanzmann]

Hello Linus,

> 	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin

This doesn't work for me:

(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97
1116799695 2cb45e95438c113871fbbea5b4f629f9463034e7:1 09d74b3b5ac634495e17b92b2b785fa996ffce97:3
(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | git-diff-tree -v -m -s --stdin
(faui00u) [~/work/git/git]

Bit this does:

(faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | awk '{print $2'} | sed 's#:.*##' | git-diff-tree -v -m -s --stdin

was that a typo or is git-diff-tree supposed to handle the output of
git-rev-tree as well and it is a bug?

	Thomas

Re: cogito - how do I ???

[Junio C Hamano]

>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:

>> git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin

TG> This doesn't work for me:

It should not.  "diff-tree --stdin" expects the line to begin
with an SHA1 and it either takes (1) one SHA1 followed by one
space followed by another SHA1 potentially followed by garbage
til the newline, or (2) one SHA1 potentially followed by garbage
til the newline.  rev-tree has the timestamp at the beginning
which does not match either of them.  What you are doing with
awk should work, so should this:

  git-rev-tree MH ^H | sed -e 's/^[0-9]* //' | git-diff-tree --stdin ...

Re: cogito - how do I ???

[Thomas Glanzmann]

Hello,

> It should not.  "diff-tree --stdin" expects the line to begin
> with an SHA1 and it either takes (1) one SHA1 followed by one
> space followed by another SHA1 potentially followed by garbage
> til the newline, or (2) one SHA1 potentially followed by garbage
> til the newline.  rev-tree has the timestamp at the beginning
> which does not match either of them.  What you are doing with
> awk should work, so should this:

thanks for the clarification.

>   git-rev-tree MH ^H | sed -e 's/^[0-9]* //' | git-diff-tree --stdin ...

This is very usefull with a 'pull only' mode.

Thanks,
	Thomas

Re: cogito - how do I ???

[Linus Torvalds]

On Mon, 23 May 2005, Thomas Glanzmann wrote:
> 
> > 	git-rev-tree MERGE_HEAD ^HEAD | git-diff-tree -v -m -s --stdin
> 
> This doesn't work for me:

Yeah, I'm an idiot.

> Bit this does:
> 
> (faui00u) [~/work/git/git] git-rev-tree 2cb45e95438c113871fbbea5b4f629f9463034e7 ^09d74b3b5ac634495e17b92b2b785fa996ffce97 | awk '{print $2'} | sed 's#:.*##' | git-diff-tree -v -m -s --stdin
> 
> was that a typo or is git-diff-tree supposed to handle the output of
> git-rev-tree as well and it is a bug?

It was me just forgetting about the time thing in rev-tree, forcing you to
have a second phase there (I usually use just "cut -d' ' -f2" - the input
_can_ have the ":n" flag thing that rev-tree outputs, and git-diff-tree
will just ignore it).

I actually suspect that whole time thing was a mistake, it seemed sensible 
back when we didn't have any other way of ordering the changesets well, 
but it's really a bad ordering anyway to do it by time (ie add a "sort 
-rn" in there), and we can (and probably should) order rev-tree output 
with some topological sort based on the commit tree.

		Linus

Re: cogito - how do I ???

[Junio C Hamano]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> ..., and we can (and probably should) order rev-tree output 
LT> with some topological sort based on the commit tree.

Seconded.

Re: cogito - how do I ???

[Herbert Xu]

Linus Torvalds <torvalds@osdl.org> wrote:
> 
> I actually suspect that whole time thing was a mistake, it seemed sensible 
> back when we didn't have any other way of ordering the changesets well, 
> but it's really a bad ordering anyway to do it by time (ie add a "sort 
> -rn" in there), and we can (and probably should) order rev-tree output 
> with some topological sort based on the commit tree.

Yes please.  Can we also have a rev-* command that outputs parent
relations instead of a simple list? That is,

<tree-1> <parent-1>
<tree-1> <parent-2>
<tree-2> <parent-3>
...

Then you could just run tsort for rev-tree, plus you could use this
for other things like finding merges.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: cogito - how do I ???

[Linus Torvalds]

On Tue, 24 May 2005, Herbert Xu wrote:
> 
> Yes please.  Can we also have a rev-* command that outputs parent
> relations instead of a simple list? That is,
> 
> <tree-1> <parent-1>
> <tree-1> <parent-2>
> <tree-2> <parent-3>

That's not <tree-n>, it's <commit-n>.

I think that would be "git-rev-list --parents" or something - that 
wouldn't impact any existing users.

Patches welcome.

As to git-rev-tree, that's likely used by scripts in various places 
(cogito, gitk, gitweb etc), so changing that is nastier, but at least the 
output could be _sorted_ better.

Of course, I really think that the bigger problem with git-rev-tree
currently is that global reachability analysis, which is just not
acceptable performance-wise.

		Linus

Re: cogito - how do I ???

[Frank Sorenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean wrote:
> On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:
> 
>>Hi all.
>>
>>While trying to get up to speed on cogito/git I stumbled across
>>a few things that I at least did not find available in cogito.
>>
>>1) Something similar to "bk changes -R". I use this to see what has
>>happened upstream - to see if I really want to merge stuff.
> 
> 
> Not sure what bk did here, but you can do something like:
> 
> cg-pull origin
> cg-log -c -r origin
> 
> To see what is at the head of the unmerged objects you just pulled down,
> and if you want to merge then "cg-merge origin".  Although as far as I
> know there's no way to have the log stop automatically at the proper spot.

Here's what I use:

cg-log -c -f -r :origin

- -c = colorize the output
- -f = list files affected
- -r :origin = only display this range (equivalent to "-r HEAD:origin")

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkBhAaI0dwg4A47wRAtrdAJ9Hy/H4BNurGd+Ukjtz+0+6sUDIkgCdHJIr
KnponX5ITXEDe/r+0dAOmqc=
=jaNR
-----END PGP SIGNATURE-----