cg-log patches

cg-log patches

[Sean]

Hi Petr,

A few minor cg-log patches outlined below available for you at:
http://git.homelinux.com/cogito


commit ce5e8e645754f3051ce3b3cf87c085544339acef

    Permit cg-log command line options to be given in any order

commit a1c2b474ad39750a07a43ddee2682f5613624652

    Make sure that CC: and From: lines are picked up as a valid
    part of the sign off process and given the proper color

commit 33762f33ee87377c0cfcea51382bad04d7c9ba8d

    Fix cg-log -f option so that a complete list of files is
    displayed when a commit has more than one parent.

    Move the list of files so they're displayed after the
    commit message

    List the files in columns, instead of one big line of comma-
    separated files.

---
cg-log | 135
++++++++++++++++++++++++++---------------------------------------
 1 files changed, 56 insertions(+), 79 deletions(-)

Cheers,
Sean

Re: cg-log patches

[Marcel Holtmann]

Hi Sean,

> commit 33762f33ee87377c0cfcea51382bad04d7c9ba8d
> 
>     Fix cg-log -f option so that a complete list of files is
>     displayed when a commit has more than one parent.
> 
>     Move the list of files so they're displayed after the
>     commit message
> 
>     List the files in columns, instead of one big line of comma-
>     separated files.

why don't you use diffstat for it? I think that it is more handy then
the list of modified files.

Regards

Marcel

Re: cg-log patches

[Sean]

On Sun, May 8, 2005 1:42 pm, Marcel Holtmann said:

> why don't you use diffstat for it? I think that it is more handy then
> the list of modified files.

Hi Marcel,

Is a good idea, but would be a fair bit harder to generate unfortunately. 
Right now the blobs themselves don't have to be opened and inspected, just
the commit trees.   Actually, i'm not sure exactly how you'd even go about
generating a correct diffstat for commits that have multiple parents.

Sean

Re: cg-log patches

[Marcel Holtmann]

Hi Sean,

> > why don't you use diffstat for it? I think that it is more handy then
> > the list of modified files.
> 
> Is a good idea, but would be a fair bit harder to generate unfortunately. 
> Right now the blobs themselves don't have to be opened and inspected, just
> the commit trees.   Actually, i'm not sure exactly how you'd even go about
> generating a correct diffstat for commits that have multiple parents.

I am not a really good git expert, but maybe another option for it would
be fine.

However there is another thing that I am missing. With Bitkeeper I was
able to do something like "bk changes -umarcel" to list all changes done
by the user "marcel". I like to have something similar with cg-log. Any
ideas on how to do that?

Regards

Marcel

Re: cg-log patches

[Petr Baudis]

Dear diary, on Sun, May 08, 2005 at 09:00:07PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Sean,
> 
> > > why don't you use diffstat for it? I think that it is more handy then
> > > the list of modified files.
> > 
> > Is a good idea, but would be a fair bit harder to generate unfortunately. 
> > Right now the blobs themselves don't have to be opened and inspected, just
> > the commit trees.   Actually, i'm not sure exactly how you'd even go about
> > generating a correct diffstat for commits that have multiple parents.
> 
> I am not a really good git expert, but maybe another option for it would
> be fine.
> 
> However there is another thing that I am missing. With Bitkeeper I was
> able to do something like "bk changes -umarcel" to list all changes done
> by the user "marcel". I like to have something similar with cg-log. Any
> ideas on how to do that?

What should it take in regard? Username portion of the email address?
The email address itself? The realname?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-log patches

[Sean]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Sun, May 8, 2005 3:18 pm, Petr Baudis said:

>> I am not a really good git expert, but maybe another option for it would
>> be fine.
>>
>> However there is another thing that I am missing. With Bitkeeper I was
>> able to do something like "bk changes -umarcel" to list all changes done
>> by the user "marcel". I like to have something similar with cg-log. Any
>> ideas on how to do that?
>
> What should it take in regard? Username portion of the email address?
> The email address itself? The realname?
>

Attached is a new version of cg-log that includes a -u option that takes a
single parameter.   Whatever you put in that parameter will be searched in
the author line, so it can be part or all of an authors name and/or email
address.

So you could do:

cg-log -c -f -u petr

or

cg-log -uxpasky

Sean

[-- Attachment #2: cg-log --]
[-- Type: application/octet-stream, Size: 3187 bytes --]

#!/usr/bin/env bash
#
# Make a log of changes in a GIT branch.
# Copyright (c) Petr Baudis, 2005.
# Copyright (c) David Woodhouse, 2005.
# Copyright (c) Sean Estabrooks, 2005.
#
# Takes a -c option to add color to the output.
# Currently, the colors are:
#
#	header		Green	
#	author 		Cyan
#	committer	Magenta
#	files		Blue
#	signoff		Yellow
#
# Takes an -f option to list which files was changed.
#
# Takes an -r followed with id resolving to a commit to start from
# (HEAD by default), or id1:id2 representing an (id1;id2] range
# of commits to show.
#
# The rest of arguments are took as filenames; cg-log then displays
# only changes in those files.

. cg-Xlib
# Try to fix the annoying "Broken pipe" output. May not help, but apparently
# at least somewhere it does. Bash is broken.
trap exit SIGPIPE

colheader=
colauthor=
colcommitter=
colfiles=
colsignoff=
coldefault=

list_files=

log_start=
log_end=

user=

while getopts cfr:u: o
do
	case $o in
	c)	# See terminfo(5), "Color Handling"
		colheader="$(tput setaf 2)"    # Green
		colauthor="$(tput setaf 6)"    # Cyan
		colcommitter="$(tput setaf 5)" # Magenta
		colfiles="$(tput setaf 4)"     # Blue
		colsignoff="$(tput setaf 3)"   # Yellow
		coldefault="$(tput op)"        # Restore default
		;;
	f)	list_files=1 
		;;
	r)	if [ -z $log_start ]; then
			log_start="${OPTARG/:*}"
			[ $OPTARG != $log_start ] && log_end="${OPTARG/*:}"
		else	log_end="$OPTARG"
		fi
		;;
	u)	user="$OPTARG"
		;;
	*)	exit 1
		;;
	esac
done
shift $((OPTIND-1))

list_commit_files()
{
	echo
	if [ -z $2 ]; then
		git-ls-tree $1  # List all files for initial commit
	else	
		local tree1=$1; shift
		for tree2; do
			git-diff-tree -r $tree1 $tree2
		done
	fi | cut -f4 | sort -u | column | column -t | \
	sed "s/^/$colfiles    * /;s/$/$coldefault/"
}

id1="$(commit-id $log_start)" || exit 1
if [ "$log_end" ]; then
	id2="$(commit-id $log_end)" || exit 1
	git-rev-tree $id2 ^$id1 | sort -rn | cut -d' ' -f2
else
	git-rev-list $id1
fi | \
while read commit
do
	trap exit SIGPIPE
	trees=
	if [ $# -ne 0 ]; then
		parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
		[ "$parent" ] && [ "$(git-diff-tree -r $commit $parent "$@")" ] || continue
	fi
	if [ ! -z "$user" ]; then
		git-cat-file commit $commit | grep '^author ' | grep -qi "$user" || continue
	fi
	echo $colheader""commit ${commit%:*} $coldefault;
	git-cat-file commit $commit | \
		while read key rest; do
			trap exit SIGPIPE
			case "$key" in
			"author"|"committer")
				if [ "$key" = "author" ]; then
					color="$colauthor"
				else
					color="$colcommitter"
				fi

				date=(${rest#*> })
				pdate="$(showdate $date)"
				if [ "$pdate" ]; then
					echo -n $color$key $rest | sed "s/>.*/> $pdate/"
					echo $coldefault
				else
					echo $color$key $rest $coldefault
				fi
				;;
			"tree"|"parent")
				trees="$trees $rest"
				echo $colheader$key $rest $coldefault
				;;
			"")
				echo; sed -re "
				 s/^(from|cc|signed.off.by|acked.by): .*/$colsignoff&$coldefault/I
				 s/^/    /"
				[ -n "$list_files" ] && list_commit_files $trees
				;;
			*)
				echo $colheader$key $rest $coldefault
				;;
			esac

		done
	echo
done | ${PAGER:-less} ${PAGER_FLAGS:--R}

Re: cg-log patches

[Petr Baudis]

Dear diary, on Sun, May 08, 2005 at 09:23:50PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On Sun, May 8, 2005 3:18 pm, Petr Baudis said:
> 
> >> I am not a really good git expert, but maybe another option for it would
> >> be fine.
> >>
> >> However there is another thing that I am missing. With Bitkeeper I was
> >> able to do something like "bk changes -umarcel" to list all changes done
> >> by the user "marcel". I like to have something similar with cg-log. Any
> >> ideas on how to do that?
> >
> > What should it take in regard? Username portion of the email address?
> > The email address itself? The realname?
> >
> 
> Attached is a new version of cg-log that includes a -u option that takes a
> single parameter.   Whatever you put in that parameter will be searched in
> the author line, so it can be part or all of an authors name and/or email
> address.
> 
> So you could do:
> 
> cg-log -c -f -u petr
> 
> or
> 
> cg-log -uxpasky
> 
> Sean

That sounds great. Could you please post a patch against the current
Cogito's cg-log?

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-log patches

[Sean]

On Sun, May 8, 2005 3:25 pm, Petr Baudis said:

>>
>> cg-log -c -f -u petr
>>
>> or
>>
>> cg-log -uxpasky
>>
>> Sean
>
> That sounds great. Could you please post a patch against the current
> Cogito's cg-log?
>

Hey Petr,

Sorry it relies on other patches in a series.  If you're interested in
them they're available from:

http://git.homelinux.com/cogito

Actually, if you look you'll see I renamed the option -a and added help so
that it shows up on -h or --help.

Cheers,
Sean

Re: cg-log patches

[Marcel Holtmann]

Hi Petr,

> > However there is another thing that I am missing. With Bitkeeper I was
> > able to do something like "bk changes -umarcel" to list all changes done
> > by the user "marcel". I like to have something similar with cg-log. Any
> > ideas on how to do that?
> 
> What should it take in regard? Username portion of the email address?
> The email address itself? The realname?

good question. Bitkeeper was only able to handle the user part of the
address. Maybe we can make cg-log a little bit more intelligent. We also
have the author and the committer. My idea would be to use -A for the
author and -C for the committer and maybe -U to search in both. If the
value contains and "@" it should search in the email address part and
otherwise in the username portion. Some regular expression stuff like
"^marcel" (case insensitive) would also be great.

I have no idea how to realize it, but would be thankful for such an
option. It is one of the last pieces that I miss.

Regards

Marcel

Re: cg-log patches

[Petr Baudis]

Dear diary, on Sun, May 08, 2005 at 08:42:13PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On Sun, May 8, 2005 2:03 pm, Petr Baudis said:
> 
> > do you think you could also send the patches by mail, please?
> 
> Yes, attached.  But i'm hoping you'll accept them from my .git repository
> so that I can keep my own repository consistent, without conflicts from my
> own patches being pulled back in from you with different commit id's.

Different commit id's shouldn't make much difference w.r.t. conflicts.

> Is there a problem with just using cogito to manage the patches?

No problem if I decide to accept all of your patches.  But that's what I
need to find out by reviewing the patches, and when I have any comments,
I want to point them out easily in the context of the patch.

 From this viewpoint the cumulative patch you've sent is unfortunately
useless - I need it broken to the commits, in separate mails, and either
as text/plain attachments or inline, please.

> >> What do you use to publish a repository?
> >
> > What do you mean?
> 
> Well, I just copied the .git directory and everything under it up to the
> website.   But I wondered if there was a cg-push or something similar
> which would handle things a little better.  No biggy.

Nothing like that so far. It should be possible with the ssh protocol
relatively easily, and doable with rsync (although the locking is going
to be pretty be hard).

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-log patches

[Jonas Fonseca]

Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> commit 33762f33ee87377c0cfcea51382bad04d7c9ba8d
> 
>     Fix cg-log -f option so that a complete list of files is
>     displayed when a commit has more than one parent.

This sounds great.

>     Move the list of files so they're displayed after the
>     commit message

The reason I put it at the top was to make it more similar to GNU-style
changelogs (if there is such a style).

>     List the files in columns, instead of one big line of comma-
>     separated files.

I think that will make `-f' less usable because of the extra scrolling.

Assuming use of wc will not create more dependency nightmares and the
extra overhead is acceptable here is a patch that will wrap file listing
lines near the 80th column.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

--- d4119364a7fbf5a4b8f00f061e4f5d58fa4abd0e/cg-log  (mode:100755)
+++ uncommitted/cg-log  (mode:100755)
@@ -64,8 +64,16 @@
 	fi
 	echo
 	$list_cmd | while read modes type sha1s file; do
-		echo -n "$sep$file"
+		echo -n "$sep"
 		sep=", "
+		if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
+			line="$line$sep$file"
+			echo -n "$file"
+		else
+			line="$file"
+			echo "$coldefault"
+			echo -n "    $colfiles$file"
+		fi
 	done
 	echo "$coldefault:"
 }

-- 
Jonas Fonseca

Re: cg-log patches

[Sean]

On Sun, May 8, 2005 7:49 pm, Jonas Fonseca said:


Hey Jonas,

>>     Fix cg-log -f option so that a complete list of files is
>>     displayed when a commit has more than one parent.
>
> This sounds great.

You might want to rip it out and submit it, because it's not likely to see
the light of day otherwise.

> The reason I put it at the top was to make it more similar to GNU-style
> changelogs (if there is such a style).

Yeah, I felt a bit guilty sliding that shift in, really I had no rationale
other than it looked better _to me_.

> I think that will make `-f' less usable because of the extra scrolling.
>
> Assuming use of wc will not create more dependency nightmares and the
> extra overhead is acceptable here is a patch that will wrap file listing
> lines near the 80th column.

Your patch will work fine but I did test my version out against the kernel
repo and it didn't seem to be a problem.

Cheers,
Sean

Re: cg-log patches

[Jonas Fonseca]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> On Sun, May 8, 2005 7:49 pm, Jonas Fonseca said:
> Hey Jonas,

Hi Sean,

> >>     Fix cg-log -f option so that a complete list of files is
> >>     displayed when a commit has more than one parent.
> >
> > This sounds great.
> 
> You might want to rip it out and submit it, because it's not likely to see
> the light of day otherwise.

I ripped it out and made a patch only with the fix.

Pasky, I also updated the line-wrapping patch if you want it.

> > The reason I put it at the top was to make it more similar to GNU-style
> > changelogs (if there is such a style).
> 
> Yeah, I felt a bit guilty sliding that shift in, really I had no rationale
> other than it looked better _to me_.

I don't feel strong about it. I guess I have just gotten used to it that
way.

-- 
Jonas Fonseca

[-- Attachment #2: fix-cg-log.patch --]
[-- Type: text/plain, Size: 2218 bytes --]

Fix cg-log -f option so that a complete list of files is
displayed when a commit has more than one parent.

Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

---
commit 06a6b40f8e52eff0e34706c7024b54df50abb6b9
tree 95bc73fd188347aa294991d1c5c7cffd60422098
parent 4ed293bc0a5ffca9683e139cad499b69a4c4d569
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200

 cg-log |   34 +++++++++++++++-------------------
 1 files changed, 15 insertions(+), 19 deletions(-)

Index: cg-log
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-log  (mode:100755)
+++ 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log  (mode:100755)
@@ -53,17 +53,20 @@
 
 list_commit_files()
 {
-	tree1="$1"
-	tree2="$2"
+	tree="$1"
 	sep="    * $colfiles"
-	# List all files for for the initial commit
-	if [ -z $tree2 ]; then
-		list_cmd="git-ls-tree $tree1"
-	else
-		list_cmd="git-diff-tree -r $tree1 $tree2"
-	fi
 	echo
-	$list_cmd | while read modes type sha1s file; do
+	if [ -z $2 ]; then
+		# List all files for the initial commit
+		git-ls-tree $tree
+	else
+		shift
+		# List changes from each parent
+		for parent; do
+			git-diff-tree -r $tree $parent
+		done
+	fi | sort -u | \
+	while read modes type sha1s file; do
 		echo -n "$sep$file"
 		sep=", "
 	done
@@ -102,8 +105,7 @@
 
 $revls | $revsort | while read time commit parents; do
 	trap exit SIGPIPE
-	tree1=
-	tree2=
+	trees=
 	[ "$revfmt" = "git-rev-list" ] && commit="$time"
 	if [ $# -ne 0 ]; then
 		parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
@@ -131,17 +133,11 @@
 				fi
 				;;
 			"tree"|"parent")
-				if [ -z $tree1 ]; then
-					tree1=$rest
-				elif [ -z $tree2 ]; then
-					tree2=$rest
-				fi
+				trees="$trees $rest"
 				echo $colheader$key $rest $coldefault
 				;;
 			"")
-				if [ -n "$list_files" ]; then
-					list_commit_files "$tree1" "$tree2"
-				fi
+				[ -n "$list_files" ] && list_commit_files $trees
 				echo; sed -re '
 					/ *Signed-off-by:.*/Is//'$colsignoff'&'$coldefault'/
 					/ *Acked-by:.*/Is//'$colsignoff'&'$coldefault'/

[-- Attachment #3: wrap-file-listing-lines.patch --]
[-- Type: text/plain, Size: 1030 bytes --]

Wrap file listing lines near the 80th column.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

---
commit 9d86f44f7d1eee525ed4c45731ad07b95f62dbb6
tree ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8
parent 06a6b40f8e52eff0e34706c7024b54df50abb6b9
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200

 cg-log |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletion(-)

Index: cg-log
===================================================================
--- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log  (mode:100755)
+++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log  (mode:100755)
@@ -67,8 +67,16 @@
 		done
 	fi | sort -u | \
 	while read modes type sha1s file; do
-		echo -n "$sep$file"
+		echo -n "$sep"
 		sep=", "
+ 		if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
+ 			line="$line$sep$file"
+ 			echo -n "$file"
+ 		else
+ 			line="$file"
+ 			echo "$coldefault"
+ 			echo -n "    $colfiles$file"
+ 		fi
 	done
 	echo "$coldefault:"
 }

Re: cg-log patches

[Petr Baudis]

Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Fix cg-log -f option so that a complete list of files is
> displayed when a commit has more than one parent.
> 
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

But that makes no sense, since each merge will have enormous amount of
files listed, making no sense. E.g. each merge of Cogito with Linus will
have all the Cogito files listed, since they aren't in the Linus branch
- but that's wrong, since the merge _to_ the Cogito branch concerns no
Cogito files.

In git, the parents list is unordered. But this is different in Cogito,
where the first parent _is_ special. If you are merging _from_ branch B
_to_ branch A, the order of parents will be always

parent A
parent B

In practice, it does not make too much difference, but this is one of
the cases where it makes difference. So I think the current behaviour is
right.

BTW, this also implies that merges

  A --
      \
  B ---+--

and

  A ---+--
      /
  B --

are considered as different ones by Cogito; in git itself, you might
model that as

  A --.
       >---
  B --'

which is not possible in Cogito. I could imagine doing it by e.g.
passing cg-clone multiple arguments, but I'd have to first see a
compelling real-world usage for this first.

> Index: cg-log
> ===================================================================
> --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log  (mode:100755)
> +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log  (mode:100755)
> @@ -67,8 +67,16 @@
>  		done
>  	fi | sort -u | \
>  	while read modes type sha1s file; do
> -		echo -n "$sep$file"
> +		echo -n "$sep"
>  		sep=", "
> + 		if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
> + 			line="$line$sep$file"
> + 			echo -n "$file"
> + 		else
> + 			line="$file"
> + 			echo "$coldefault"
> + 			echo -n "    $colfiles$file"
> + 		fi
>  	done
>  	echo "$coldefault:"
>  }

Could we have a trailing comma at the previous line?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-log patches

[Jonas Fonseca]

Petr Baudis <pasky@ucw.cz> wrote Mon, May 09, 2005:
> Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> told me that...
> > Fix cg-log -f option so that a complete list of files is
> > displayed when a commit has more than one parent.
> > 
> > Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> 
> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
> 
> parent A
> parent B

Ok, forget the patch then. I was not sure how to handle the multiple parents.

> > Index: cg-log
> > ===================================================================
> > --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log  (mode:100755)
> > +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log  (mode:100755)
> > @@ -67,8 +67,16 @@
> >  		done
> >  	fi | sort -u | \
> >  	while read modes type sha1s file; do
> > -		echo -n "$sep$file"
		# Always put a trailing comma
> > +		echo -n "$sep"
> >  		sep=", "
> > + 		if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
> > + 			line="$line$sep$file"
> > + 			echo -n "$file"
> > + 		else
> > + 			line="$file"
> > + 			echo "$coldefault"
> > + 			echo -n "    $colfiles$file"
> > + 		fi
> >  	done
> >  	echo "$coldefault:"
> >  }
> 
> Could we have a trailing comma at the previous line?

It should already do that ..

committer Petr Baudis <xpasky@machine.sinus.cz> Sun, 08 May 2005 23:54:08 +0200

    * cg-Xlib, cg-update, cg-seek, cg-pull, cg-tag-ls, cg-branch-ls, cg-merge,
    cg-commit, cg-tag, cg-init, cg-branch-add, cg-admin-lsobj, cg-status,
    cg-cancel, cg-admin-uncommit:

-- 
Jonas Fonseca

Re: cg-log patches

[Sean]

On Mon, May 9, 2005 8:14 am, Petr Baudis said:

> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always

But, there are commits (even in your tree) that aren't produced by Cogito.
 And the current logic gets them wrong.

Look at commit:  211232bae64bcc60bbf5d1b5e5b2344c22ed767e in your tree.

The current logic will miss the fact that one of the other parents
altered, git-apply-patch-script.   Seems better to over report, than under
report changes, although I agree that some way must be found to handle the
merge case.

Sean

Re: cg-log patches

[Petr Baudis]

Dear diary, on Mon, May 09, 2005 at 02:14:35PM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
> 
> parent A
> parent B
> 
> In practice, it does not make too much difference, but this is one of
> the cases where it makes difference. So I think the current behaviour is
> right.
> 
> BTW, this also implies that merges
> 
>   A --
>       \
>   B ---+--
> 
> and
> 
>   A ---+--
>       /
>   B --
> 
> are considered as different ones by Cogito

Ok. So you do

A ---+--
    /
B --

and now merge A to B, which results in fast-forward and

A ---+----
    /  \
B --    --

but when doing cg-log in B, the merge is the wrong way around now.

Sean counterexample works too, it's a good thing to maintain
compatibility with git at this one too.

Still, I would like to have the files list separated. What about one
bullet per parent? Like

    * asdf, hjkl, xyzzy
    * hjkl, quux

for a regular two-parents merge.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor