Joining cg-*-id

Joining cg-*-id

[Pavel Roskin]

Hello!

I believe Cogito should keep the command list short.  When the *-id
utilities got the cg-prefix, the list became longer by 3 commands.

What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id
(or cg-admin-id) utility?  It would work like cg-commit-id in absence of
switches, -p would make it work like cg-parent-id, and -t would make it
cg-tree-id.

Alternatively, this functionality should go to git.  It's low-level
enough to be there.

-- 
Regards,
Pavel Roskin

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello!

Hello,

> I believe Cogito should keep the command list short.  When the *-id
> utilities got the cg-prefix, the list became longer by 3 commands.

well, those commands are semi-public, actually. E.g. cg-help does not
list them.

> What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id
> (or cg-admin-id) utility?  It would work like cg-commit-id in absence of
> switches, -p would make it work like cg-parent-id, and -t would make it
> cg-tree-id.

Perhaps cg-object-id? I'm not principially opposed to that, but I don't
see much value in it either. Perhaps if this would come along with
the usage of git-rev-parse (see below)...

> Alternatively, this functionality should go to git.  It's low-level
> enough to be there.

There is git-rev-parse, but it is not as powerful (cannot take dates and
sha1 completion does not work when listing parents) - OTOH it can
complete sha1 ids even inside packs, which is really useful. Still, IMHO
its usage is awful, so it'd take place for cg-Xnormid, but we would
still keep the *-id frontends (which would also handle the dates).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: Joining cg-*-id

[Linus Torvalds]

On Mon, 19 Sep 2005, Petr Baudis wrote:
> 
> There is git-rev-parse, but it is not as powerful (cannot take dates and
> sha1 completion does not work when listing parents)

Hmm.

That lack of sha1 completion is a bug. 

How does the date thing work? It sounds like something horribly ambiguous, 
but hey, maybe some useful semantics could be found.

The short sha1 problem is fixed thus,

		Linus

----
Fix extended short SHA1 name completion

get_sha1() would not do sha1 completion of short SHA1's when they were 
part of a more complex expression. So doing

	git-rev-parse 727132834e6be48a93c1bd6458a29d474ce7d5d5^

would work, and return 87c6aeb4efdd4355918d127a91bd0adc5a02f8ff. But using 
the shorthand version 

	git-rev-list 72713^

wouldn't work.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/sha1_name.c b/sha1_name.c
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -84,19 +84,19 @@ static int find_short_packed_object(int 
 	return 0;
 }
 
-static int get_short_sha1(const char *name, unsigned char *sha1)
+static int get_short_sha1(const char *name, int len, unsigned char *sha1)
 {
 	int i;
 	char canonical[40];
 	unsigned char res[20];
 
+	if (len < 4)
+		return -1;
 	memset(res, 0, 20);
 	memset(canonical, 'x', 40);
-	for (i = 0;;i++) {
+	for (i = 0; i < len ;i++) {
 		unsigned char c = name[i];
 		unsigned char val;
-		if (!c || i > 40)
-			break;
 		if (c >= '0' && c <= '9')
 			val = c - '0';
 		else if (c >= 'a' && c <= 'f')
@@ -112,8 +112,6 @@ static int get_short_sha1(const char *na
 			val <<= 4;
 		res[i >> 1] |= val;
 	}
-	if (i < 4)
-		return -1;
 	if (find_short_object_filename(i, canonical, sha1))
 		return 0;
 	if (find_short_packed_object(i, res, sha1))
@@ -254,7 +252,7 @@ static int get_sha1_1(const char *name, 
 	ret = get_sha1_basic(name, len, sha1);
 	if (!ret)
 		return 0;
-	return get_short_sha1(name, sha1);
+	return get_short_sha1(name, len, sha1);
 }
 
 /*

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 12:16:03AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> How does the date thing work? It sounds like something horribly ambiguous, 
> but hey, maybe some useful semantics could be found.

Currently, in Cogito it is basically:

	git-rev-list --min-age="$(date --date=$id +%s)" --max-count=1 HEAD

The point is that you can then say

	cg-log -r yesterday

to see all the changes which happenned during the last day, and such
(so it is really useful to have the syntactic power of date(1) available).

But that semantics sucks, and I wouldn't mind changing it at all. I
think taking the previous commit works for everything but the start of
cg-log range, and it is how CVS behaves. And with cg-log, you'll just
have one commit more, not so big a deal I think.

Jonas was who introduced this, IIRC, so cc'ing him too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Joining cg-*-id

[Linus Torvalds]

On Tue, 20 Sep 2005, Petr Baudis wrote:
> 
> Currently, in Cogito it is basically:
> 
> 	git-rev-list --min-age="$(date --date=$id +%s)" --max-count=1 HEAD

Yes, for git-rev-list it makes sense, because that already more or less
"serializes" things by date.

> But that semantics sucks, and I wouldn't mind changing it at all. I
> think taking the previous commit works for everything but the start of
> cg-log range, and it is how CVS behaves.

The thing is, it may have sensible behaviour for CVS, but only because CVS 
doesn't have any notion of concurrent development (even a branch isn't 
concurrent - it's totally separate, and when you merge it, it becomes just 
one big diff at the time of the merge).

So I'd love to have

	git diff yesterday..

but the fact is, there's no sensible semantics for it. _which_ yesterday? 
There might be five different points that are "close to 24 hours ago", 
along five different paths backwards in the history.

I suspect that the date-based thing really doesn't make sense as a
revision, only as a git log cut-off (ie the "--min-age=" flag is as close
to sensibility as you can get).

		Linus

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 02:50:21AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Tue, 20 Sep 2005, Petr Baudis wrote:
> > But that semantics sucks, and I wouldn't mind changing it at all. I
> > think taking the previous commit works for everything but the start of
> > cg-log range, and it is how CVS behaves.
> 
> The thing is, it may have sensible behaviour for CVS, but only because CVS 
> doesn't have any notion of concurrent development (even a branch isn't 
> concurrent - it's totally separate, and when you merge it, it becomes just 
> one big diff at the time of the merge).
> 
> So I'd love to have
> 
> 	git diff yesterday..
> 
> but the fact is, there's no sensible semantics for it. _which_ yesterday? 
> There might be five different points that are "close to 24 hours ago", 
> along five different paths backwards in the history.

A well-defined meaning for this from Cogito standpoint would be "the
last commit on our HEAD before the date and all commits committed and
merged to the HEAD". In Cogito, you don't merge two branches _together_,
you merge one branch _into_ another (represented by the parents order),
so this would be sensible.

But we would have to sort the log in merge order for this to be possible
(and probably teach git-rev-list about it anyway).  I would absolutely
*love* to have cg-log in merge order instead of date order - longer I
see it the more I believe that it's evil and you should really want
merge order instead. The trouble is that cg-log would be no longer
incremental and would have to load the whole history first, a no-go for
any measurably long history.

By the way, did I understand it right that the only difference between
the results of merge ordering and topo ordering is the order commits
with regard to the order of parents?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Joining cg-*-id

[Linus Torvalds]

On Tue, 20 Sep 2005, Petr Baudis wrote:
> > 
> > So I'd love to have
> > 
> > 	git diff yesterday..
> > 
> > but the fact is, there's no sensible semantics for it. _which_ yesterday? 
> > There might be five different points that are "close to 24 hours ago", 
> > along five different paths backwards in the history.
> 
> A well-defined meaning for this from Cogito standpoint would be "the
> last commit on our HEAD before the date and all commits committed and
> merged to the HEAD". In Cogito, you don't merge two branches _together_,
> you merge one branch _into_ another (represented by the parents order),
> so this would be sensible.

No, it's _not_ sensible or well-defined.

The order of the parents does not matter. It fundamentally _cannot_ 
matter. I realize that both git and cogito put the "primary parent" first, 
but that doesn't help one iota - because git is distributed, if the other 
side merged and we just did a fast-forward, the "primary parent" will be 
the _other_ side.

In other words, anybody who thinks that the order of parents is meaningful 
is in for some nasty shocks. It really _fundamentally_ isn't true. I 
realize that's hard to accept, but it's a truism in a distributed system. 
You really cannot have parent ordering and distribution at the same time.

> But we would have to sort the log in merge order for this to be possible
> (and probably teach git-rev-list about it anyway).

It's not sensible regardless of how you order things. There _is_ no 
ordering. 

So if you give a date, and there is a merge after that date, you will
always have at least two ways to reach the next older commit (now, if
you're lucky, it will be a common one and unambiguous, but more commonly
you'll simply have _two_ commits that are "most recent commit older than
the date".

And if you select one of them at random (or by deciding which parent is 
the "primary" one), then 

	git diff yesterday..

will show not the changes since yesterday, but _all_ the changes that came 
in through the merge.

> By the way, did I understand it right that the only difference between
> the results of merge ordering and topo ordering is the order commits
> with regard to the order of parents?

The only guarantees topo-ordering gives is that a parent will be shown 
before its children. So it may still mix up commits that happened 
between two parallell workflows, unlike merge-order that will always show 
one parallell chain of development as a contiguous set of commits.

Only merge-order gives any meaning to the order of the parents, but as 
mentioned, that is irrelevant - a merge on the other side will "flip" the 
whole world-view.

And they happen.

		Linus

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 04:53:11PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Tue, 20 Sep 2005, Petr Baudis wrote:
> > > 
> > > So I'd love to have
> > > 
> > > 	git diff yesterday..
> > > 
> > > but the fact is, there's no sensible semantics for it. _which_ yesterday? 
> > > There might be five different points that are "close to 24 hours ago", 
> > > along five different paths backwards in the history.
> > 
> > A well-defined meaning for this from Cogito standpoint would be "the
> > last commit on our HEAD before the date and all commits committed and
> > merged to the HEAD". In Cogito, you don't merge two branches _together_,
> > you merge one branch _into_ another (represented by the parents order),
> > so this would be sensible.
> 
> No, it's _not_ sensible or well-defined.
> 
> The order of the parents does not matter. It fundamentally _cannot_ 
> matter. I realize that both git and cogito put the "primary parent" first, 
> but that doesn't help one iota - because git is distributed, if the other 
> side merged and we just did a fast-forward, the "primary parent" will be 
> the _other_ side.
> 
> In other words, anybody who thinks that the order of parents is meaningful 
> is in for some nasty shocks. It really _fundamentally_ isn't true. I 
> realize that's hard to accept, but it's a truism in a distributed system. 
> You really cannot have parent ordering and distribution at the same time.

Ok ok. I can now remember already learning about this once, but I forgot
again. I should write it down into some README for myself or so, I
guess. ;-) Sorry about the noise.

I'll just drop the date revision specifier support from Cogito. I don't
know if any measurable number of people actually use it in the real
world anyway.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which

Re: Joining cg-*-id

[Linus Torvalds]

On Tue, 20 Sep 2005, Petr Baudis wrote:
> 
> I'll just drop the date revision specifier support from Cogito. I don't
> know if any measurable number of people actually use it in the real
> world anyway.

I think the date specifier makes sense for cg-log, though. 

Ie it doesn't make sense as a generic cg-*-id thing, but it _does_ make 
sense as a totally log-specific case.

Maybe it could use "-d" instead of "-r", since it's really a totally 
separate control. For example, there's nothing wrong with

	cg-log -d yesterday v2.6.12..

which would limit the revisions _both_ to a date _and_ to a version.

So it's just "diff against time" that makes no sense. But both "git log" 
and "git whatchanged" are sensible in time: there's no problem with saying 
"what commits happened in the last 24 hours", but there _is_ a problem 
with saying "show me the difference from 24 hours ago".

See? The "list of commits" is sensible, it's just the "one revision" thing 
that isn't.

Here's a stupid example of how to do this in git. 

With this silly patch, this like

	git whatchanged --since="1 month ago"
	git log --since="5 days ago"
	gitk --since=yesterday

all work. I don't know how _useful_ it is, but it's kind of cool.

(Side note: the "gitk" thing works really badly. gitk doesn't quote its 
arguments to "git-rev-list", so something like

	gitk --since="1 month ago"

does NOT work, while "--since=yesterday" does, because it has no spaces. 
Gaah. "Obi-Paul Mackerras, you're our only hope")

		Linus

---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -6,6 +6,7 @@
 #include "cache.h"
 #include "commit.h"
 #include "refs.h"
+#include "quote.h"
 
 #define DO_REVS		1
 #define DO_NOREV	2
@@ -125,6 +126,27 @@ static int show_reference(const char *re
 	return 0;
 }
 
+static void show_datestring(const char *datestr)
+{
+	FILE *date;
+	static char buffer[100] = "--max-age=";
+	static char cmd[1000];
+	int len;
+
+	/* date handling requires both flags and revs */
+	if ((filter & (DO_FLAGS | DO_REVS)) != (DO_FLAGS | DO_REVS))
+		return;
+	snprintf(cmd, sizeof(cmd), "date --date=%s +%%s", sq_quote(datestr));
+	date = popen(cmd, "r");
+	if (!date || !fgets(buffer + 10, sizeof(buffer) - 10, date))
+		die("git-rev-list: bad date string");
+	pclose(date);
+	len = strlen(buffer);
+	if (buffer[len-1] == '\n')
+		buffer[--len] = 0;
+	show(buffer);
+}
+
 int main(int argc, char **argv)
 {
 	int i, as_is = 0, verify = 0;
@@ -207,6 +229,10 @@ int main(int argc, char **argv)
 				printf("%s/.git\n", cwd);
 				continue;
 			}
+			if (!strncmp(arg, "--since=", 8)) {
+				show_datestring(arg+8);
+				continue;
+			}
 			if (verify)
 				die("Needed a single revision");
 			show_flag(arg);

Re: Joining cg-*-id

[Linus Torvalds]

On Tue, 20 Sep 2005, Linus Torvalds wrote:
> 
> (Side note: the "gitk" thing works really badly. gitk doesn't quote its 
> arguments to "git-rev-list", so something like
> 
> 	gitk --since="1 month ago"
> 
> does NOT work, while "--since=yesterday" does, because it has no spaces. 
> Gaah. "Obi-Paul Mackerras, you're our only hope")

Fixed thusly, I think.

There is 'eval' magic with pure lists. I'm getting convinced that tcl is 
evil after all - that's just _confusing_. A real language shouldn't have 
semantic differences from this change, but it clearly does.

However, getting gitk working also shows a problem with --topo-order
(which gitk uses) and the time limits. See

	[torvalds@g5 git]$ git-rev-list $(git-rev-parse --since="8 days ago" HEAD) | wc
	     80      80    3280
	[torvalds@g5 git]$ git-rev-list --topo-order $(git-rev-parse --since="8 days ago" HEAD) | wc
	     10      10     410

which is because when we sort things topologically, they won't be in date 
order any more (surprise surprise), so the whole date-cut-off logic 
doesn't actually work.

So I'm sad to say that

	gitk --since="5 days ago"

still doesn't do what you'd actually _want_ it to do with gitk. But at 
least gitk can now parse the arguments right.

		Linus

---
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -33,8 +33,8 @@ proc getcommits {rargs} {
     set nextupdate [expr $startmsecs + 100]
     set ncmupdate 1
     if [catch {
-	set parse_args [concat --default HEAD $rargs]
-	set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
+	set parse_cmd [concat git-rev-parse --default HEAD $rargs]
+	set parsed_args [split [eval exec $parse_cmd] "\n"]
     }] {
 	# if git-rev-parse failed for some reason...
 	if {$rargs == {}} {

Re: Joining cg-*-id

[Paul Mackerras]

Linus Torvalds writes:

> On Tue, 20 Sep 2005, Linus Torvalds wrote:
> > 
> > (Side note: the "gitk" thing works really badly. gitk doesn't quote its 
> > arguments to "git-rev-list", so something like
> > 
> > 	gitk --since="1 month ago"
> > 
> > does NOT work, while "--since=yesterday" does, because it has no spaces. 
> > Gaah. "Obi-Paul Mackerras, you're our only hope")

<scratches head> It works for me - with your rev-list.c and
rev-parse.c patches, an unmodified gitk (as in current git.git) works
just fine; both gitk --since=yesterday and gitk --since="1 day ago"
give the same set of commits (two merges and an NTFS change, plus
"Linux v2.6.14-rc2" and a SCSI zfcp patch shown with open circles).

> There is 'eval' magic with pure lists. I'm getting convinced that tcl is 
> evil after all - that's just _confusing_. A real language shouldn't have 
> semantic differences from this change, but it clearly does.

I can't see any semantic difference...

Can you still replicate the problem with an unmodified gitk?

Paul.

Re: Joining cg-*-id

[Linus Torvalds]

On Wed, 21 Sep 2005, Paul Mackerras wrote:
> 
> Can you still replicate the problem with an unmodified gitk?

Oooh. I can't. Very strange. I definitely could yesterday:  
"--since=yesterday" worked, but "--since='1 week ago'" didn't.

Magic. Maybe I mistyped something.

		Linus

Re: Joining cg-*-id

[Paul Mackerras]

Linus Torvalds writes:

> Oooh. I can't. Very strange. I definitely could yesterday:  
> "--since=yesterday" worked, but "--since='1 week ago'" didn't.

Ahhh... "--since='1 week ago'" doesn't work because of the extra set
of single quotes: we end up doing:

	git-rev-parse --default HEAD "--since='1 week ago'"

which gives this error:

	date: invalid date `'1 week ago''
	fatal: git-rev-list: bad date string

Gitk's error message is admittedly less than informative, but that's
the worst it's guilty of (this time :).

Paul.

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 06:54:57PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Tue, 20 Sep 2005, Petr Baudis wrote:
> > 
> > I'll just drop the date revision specifier support from Cogito. I don't
> > know if any measurable number of people actually use it in the real
> > world anyway.
> 
> I think the date specifier makes sense for cg-log, though. 
> 
> Ie it doesn't make sense as a generic cg-*-id thing, but it _does_ make 
> sense as a totally log-specific case.
> 
> Maybe it could use "-d" instead of "-r", since it's really a totally 
> separate control. For example, there's nothing wrong with
> 
> 	cg-log -d yesterday v2.6.12..

Yes, I agree on that. I added the -d option now and will remove the -r
date functionality soon.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Joining cg-*-id

[Matthias Urlichs]

Hi, Linus Torvalds wrote:

> And if you select one of them at random (or by deciding which parent is
> the "primary" one), then
> 
> 	git diff yesterday..
> 
> will show not the changes since yesterday, but _all_ the changes that came
> in through the merge.

IMHO the way out is to realize that you did the same thing yesterday,
so presumably, if we teach git to remember what yesterday's head was,
there's no problem.

So let's do a "git diff-since yesterday" which simply forks a
"git diff since/yesterday..HEAD", and then copies .git/HEAD to
.git/refs/since/yesterday.

Just don't call it "yesterday" in the documentation ;-)  and print a nice
error message instead of an ugly one if the user hasn't run the program
before. (But still do the copy.)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
What if everything is an illusion and nothing exists?  In that case, I
definitely overpaid for my carpet.
		-- Woody Allen, "Without Feathers"

Re: Joining cg-*-id

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> That lack of sha1 completion is a bug. 
>
> How does the date thing work? It sounds like something horribly ambiguous, 
> but hey, maybe some useful semantics could be found.

I am not even sure what I would want to see, let alone what I
could show, when I say "show logs of what happened last week",
after I just pulled from a remote or two.

I would imagine a gitk graph with nodes colored red for commits
with last week's timestamps, would be what I would want, but
probably that is useful only because I can see in the same gitk
window how those red nodes connect with each other and with
commits outside the specified time window.  Without that context
information I would probably be lost.

> The short sha1 problem is fixed thus,

Thanks.  Applied.

Re: Joining cg-*-id

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> I would imagine a gitk graph with nodes colored red for commits
> with last week's timestamps,

One feature I'd like to see in this context is a gitk tree view that lists
nodes in date order, instead of the "walk down one branch as far as
possible before doing the next one" process it currently uses.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
How often I found where I should be going only by setting out for somewhere
else.
		-- R. Buckminster Fuller

Re: Joining cg-*-id

[Paul Mackerras]

Matthias Urlichs writes:

> One feature I'd like to see in this context is a gitk tree view that lists
> nodes in date order, instead of the "walk down one branch as far as
> possible before doing the next one" process it currently uses.

It's there already: the -d flag to gitk does that.

That shows them in date order subject to the constraint that children
are shown before parents.  Yes, it is possible to have a commit that
is older than its parent(s), if it or its parent(s) were created on a
machine whose date is set wrong.

Paul.

Re: Joining cg-*-id

[Pavel Roskin]

Hello, Petr!

Thanks for quick replies.  I'm replying to both your messages.

On Mon, 2005-09-19 at 23:56 +0200, Petr Baudis wrote:
> Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > Hello!
> 
> Hello,
> 
> > I believe Cogito should keep the command list short.  When the *-id
> > utilities got the cg-prefix, the list became longer by 3 commands.
> 
> well, those commands are semi-public, actually. E.g. cg-help does not
> list them.

But cg-<TAB><TAB> does.

> > What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id
> > (or cg-admin-id) utility?  It would work like cg-commit-id in absence of
> > switches, -p would make it work like cg-parent-id, and -t would make it
> > cg-tree-id.
> 
> Perhaps cg-object-id? I'm not principially opposed to that, but I don't
> see much value in it either. Perhaps if this would come along with
> the usage of git-rev-parse (see below)...

The value is having one command, one manpage and one place to fix little
bugs and add more functionality.  Potentially, cg-Xnormid could be
incorporated into that script, so bash wouldn't have to open one more
file.

> > Alternatively, this functionality should go to git.  It's low-level
> > enough to be there.
> 
> There is git-rev-parse, but it is not as powerful (cannot take dates and
> sha1 completion does not work when listing parents) - OTOH it can
> complete sha1 ids even inside packs, which is really useful. Still, IMHO
> its usage is awful, so it'd take place for cg-Xnormid, but we would
> still keep the *-id frontends (which would also handle the dates).

I see.  I guess time for git is just as abstract as phases of the moon -
nobody would goes crazy when they repeat.

Please don't apply my patch yet - I forgot to document the optional
argument.  I'll try to make cg-object-id now.

-- 
Regards,
Pavel Roskin

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 12:30:21AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> On Mon, 2005-09-19 at 23:56 +0200, Petr Baudis wrote:
> > Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter
> > where Pavel Roskin <proski@gnu.org> told me that...
> > > I believe Cogito should keep the command list short.  When the *-id
> > > utilities got the cg-prefix, the list became longer by 3 commands.
> > 
> > well, those commands are semi-public, actually. E.g. cg-help does not
> > list them.
> 
> But cg-<TAB><TAB> does.

Good point.

> > > What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id
> > > (or cg-admin-id) utility?  It would work like cg-commit-id in absence of
> > > switches, -p would make it work like cg-parent-id, and -t would make it
> > > cg-tree-id.
> > 
> > Perhaps cg-object-id? I'm not principially opposed to that, but I don't
> > see much value in it either. Perhaps if this would come along with
> > the usage of git-rev-parse (see below)...
> 
> The value is having one command, one manpage and one place to fix little
> bugs and add more functionality.  Potentially, cg-Xnormid could be
> incorporated into that script, so bash wouldn't have to open one more
> file.

Well, cg-Xnormid is basically pointless if it's not going to be a common
backend for multiple other commands. So I'd say either supersede it with
git-rev-parse or just merge it with cg-object-id.

> Please don't apply my patch yet - I forgot to document the optional
> argument.  I'll try to make cg-object-id now.

Which patch?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Joining cg-*-id

[Pavel Roskin]

On Tue, 2005-09-20 at 00:58 +0200, Petr Baudis wrote:
> Dear diary, on Tue, Sep 20, 2005 at 12:30:21AM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > The value is having one command, one manpage and one place to fix little
> > bugs and add more functionality.  Potentially, cg-Xnormid could be
> > incorporated into that script, so bash wouldn't have to open one more
> > file.
> 
> Well, cg-Xnormid is basically pointless if it's not going to be a common
> backend for multiple other commands. So I'd say either supersede it with
> git-rev-parse or just merge it with cg-object-id.

Agreed.

> > Please don't apply my patch yet - I forgot to document the optional
> > argument.  I'll try to make cg-object-id now.
> 
> Which patch?

The one that adds USAGE.  Never mind - I see it's fixed already.

As for merging, I see that the existing *-id scripts are a mess.  For
instance, cg-parent returns parents separated by spaces, but cg-diff
used "head -1" on its output to get the first parent, i.e it assumes
newline separated output.

Another thing that is broken is "cg-commit-id origin^" - apparently the
"^" parsing is only designed for cg-parent-id.

I think I'll start a local branch for fixing this, and then I'll send
separate patches.

-- 
Regards,
Pavel Roskin

Re: Joining cg-*-id

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 02:19:50AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> As for merging, I see that the existing *-id scripts are a mess.  For
> instance, cg-parent returns parents separated by spaces, but cg-diff
> used "head -1" on its output to get the first parent, i.e it assumes
> newline separated output.

Actually, cg-parent-id's documentation seems to be wrong. We always
return only the first parent. I've just updated the documentation for
now, even though in the future we might want to change this to reflect
the original documentation instead.

> Another thing that is broken is "cg-commit-id origin^" - apparently the
> "^" parsing is only designed for cg-parent-id.

That's a bug, IIRC it was originally meant to be general.

> I think I'll start a local branch for fixing this, and then I'll send
> separate patches.

Good idea.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.