Re: [PATCH] Remove perl dependency from git-submodule.sh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 31, 2012 at 11:19:04AM +0200, Johannes Sixt wrote:
> Am 5/31/2012 10:48, schrieb Fredrik Gustafsson:
> > Rewrote a perl section in sh.
> 
> > The code may be a bit slower (doing grep on strings instead of using
> > perl-lists).
> 
> "A lot" would be more correct on Windows :-) But it can be avoided, I think.
> 
> >  module_list()
> >  {
> > +	unmerged=
> > +	null_sha1=0000000000000000000000000000000000000000
> >  	git ls-files --error-unmatch --stage -- "$@" |
> > -	perl -e '
> > -	my %unmerged = ();
> > -	my ($null_sha1) = ("0" x 40);
> > -	while (<STDIN>) {
> > -		chomp;
> > -		my ($mode, $sha1, $stage, $path) =
> > -			/^([0-7]+) ([0-9a-f]{40}) ([0-3])\t(.*)$/;
> > -		next unless $mode eq "160000";
> > -		if ($stage ne "0") {
> > -			if (!$unmerged{$path}++) {
> > -				print "$mode $null_sha1 U\t$path\n";
> > -			}
> > -			next;
> > -		}
> > -		print "$_\n";
> > -	}
> > -	'
> > +	while read mode sha1 stage path
> 
> Be prepared for backslashes in the path name:
> 
> 	while read -r mode sha1 stage path

We are not using -r on any place in git-submodule.sh. Maybe we should? I
can provide a patch if needed.

> 
> > +	do
> > +		if test $mode -eq 160000
> 
> $mode is not a number, but a string: test "$mode" = 160000

okay, fixed in next iteration.

> 
> > +		then
> > +			if test $stage -ne 0
> 
> That $stage looks like a number is of no importance, either.

Actually I don't know what stage does and if it's important here. This
part is just to mimic the perl code. Should it be removed?

> 
> > +			then
> > +				if test -z "$(echo $unmerged | grep "|$path|")"
> > +					then
> > +					echo "$mode $null_sha1 U\t$path"
> > +				fi
> > +				unmerged="$unmerged|$path|"
> 
> IIUC, the purpose of $unmerged and this check is to avoid that an unmerged
> path is dumped for each stage that is listed by ls-files. Therefore it
> should be sufficient to just check that the current path is different from
> the last path.

That requires that submodules always is in the same order, right? That
would not work for:
sub1
sub2
sub1

case. But is that order really a possibility or is it always
sub1
sub1
sub2

?

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]