From: Sam Ravnborg <hidden> Date: 2016-06-15 22:41:58
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
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
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.
quoted
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
From: Frank Sorenson <hidden> Date: 2016-06-15 22:41:58
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sean wrote:
On Sat, May 21, 2005 5:47 pm, Sam Ravnborg said:
quoted
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-----
From: Sam Ravnborg <hidden> Date: 2016-06-15 22:41:58
quoted
quoted
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.
quoted
quoted
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
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.
quoted
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
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
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
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-06-15 22:41:58
Linus Torvalds [off-list ref] 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~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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