* Test scripts naming
From: Petr Baudis @ 2005-05-14 16:53 UTC (permalink / raw)
To: junkio; +Cc: git
Hello,
I think we should do something about the test script names. Currently
it appears almost like the scripts are basically unordered, and the
digit you increment is chosen mostly randomly. Also, the "freeform"
field after the test number is not as informative as it could be. What
are the rules you use for naming the testcases? Could you please
document it in the README?
I'd propose:
First digit: "family", e.g. the absolute basics and global stuff (0),
the basic db-side commands (read-tree, write-tree, commit-tree), the
basic working-tree-side commands (checkout-cache, update-cache), the
other basic commands (ls-files), the diff commands, the pull commands,
exporting commands, revision tree commands...
Second digit: the particular command we are testing
Third digit: (optionally) the particular switch or group of switches
we are testing
Freeform part: commandname-details
How would I rename the current scripts?
t1000-checkout-cache.sh -> t2000-checkout-cache-clash.sh
t1001-checkout-cache.sh -> t2001-checkout-cache-clash.sh
t0200-update-cache.sh -> t2010-update-cache-badpath.sh
t0400-ls-files.sh -> t3000-ls-files-others.sh
t0500-ls-files.sh -> t3010-ls-files-killed.sh
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Rename tracking
From: Junio C Hamano @ 2005-05-14 16:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: torvalds, git
In-Reply-To: <20050514162133.GW3905@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Well, I'd say that with those renaming patches we are feeling the need
PB> for it?
Again, not me. What I did (and asked you to do) was to help
_others_ who are interested in rename tracking, not me. Find
the following message in the archive if you want to know why I
am not in urgent need for rename tracking.
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Greaves <david@dgreaves.com>, git@vger.kernel.org
Subject: GIT blame (was Re: Quick command reference)
From: Junio C Hamano <junkio@cox.net>
Date: Fri, 06 May 2005 02:32:30 -0700
X-Mailing-List: git@vger.kernel.org
>>>>> I == Junio C Hamano <junkio@cox.net> said:
JCH> Linus, please pull from git-jc.git archive at:
JCH> http://members.cox.net/junkio/git-jc.git/
Since that message I have added a couple more commits there.
One of the things is a backport of -t (tag) flag to git-ls-files
from Cogito fork.
The reason I am writing this message is not because I am excited
about the backport [*1*], but because I find it quite cool the
way I found out which commit in Pasky's development line
introduced the change. It demonstrates your previous "renames
does not matter when doing CVS blame" argument actually works.
Here is what I did: ... (the rest omitted) ...
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Junio C Hamano @ 2005-05-14 16:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050514150356.GK3905@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
Now I understand which discussion I was missing ;-).
PB> For humans I'd say "Mode change" instead of "mode" would be better, and
PB> for machines I still think "@" would be better than "#". "#" can occur
PB> quite naturally in some code snippets or whatever pasted to the commit
PB> message, which is extremely unlikely for "@". What are the advantages
PB> of "#"?
Wait a minute. Aren't we scanning starting from the first
'---\n'? Why does what's in commit message matter?
And it is not really "Mode change" anymore. If you used to have
file there and you replaced it with a symlink, that is 100644 to
120000 "mode change". I experimented with different things in
where I have "# mode: " there and seriously considered to spell
it "# git:" instead, because that is not really mode and it is
something that means something special to git. Also I tried to
say just "@. " --- it _was_ confusing to human eye, especially
if you are used to reading diffs.
What I think is that this should not really matter much for
human consumption, because mode change is rare and type change
is even more rare.
PB> I like the rest. That's basically what I've imagined, and
PB> without the arrows it's even better. :-)
Here is what I'd propose for you to do. (1) Take the patch as
is and commit; (2) Change the definition of git_prefix in diff.c
to "\n@. " and commit; (3) If you already took the test suite,
match t/t2000-diff.sh for the "\n@. " format, and commit.
It will look something like this. thanks to the leading newline,
the output becomes a bit less confusing (without that blank
line, it really is a disaster for human eyes).
@. 100644 100755 path0
--- a/path0
+++ b/path0
@@ -1,3 +1,3 @@
Line 1
Line 2
-line 3
+Line 3
@. 100755 . path1
--- a/path1
+++ /dev/null
@@ -1,3 +0,0 @@
-Line 1
-Line 2
-line 3
^ permalink raw reply
* Re: Rename tracking
From: Petr Baudis @ 2005-05-14 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7v4qd523p1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, May 14, 2005 at 06:05:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> I'll postpone it for another while since there is still some discussion
> PB> about tuning the output.
>
> What discussion did I miss???
Mainly
From: Petr Baudis <pasky@ucw.cz>
Date: Sat, 14 May 2005 17:03:56 +0200
Subject: Re: [PATCH] Resurrect diff-tree-helper -R
Message-ID: <20050514150356.GK3905@pasky.ji.cz>
> PB> I'm thinking about using "\n---\n\n" in commit message to separate some
> PB> "internal data" like this. cg-log (and web interfaces and other
> PB> toolkits, if we get to agree on something common) could then by default
> PB> hide it. Below it would contain something which we could hopefully embed
> PB> in patches too (actually less work for extracting patches by cg-mkpatch
> PB> or similar tools). What do you think?
>
> Since I have not been particularly interested in rename tracking
> (because I myself personally have not felt the need for it), I
> do not offhand have much idea worth to offer. Sorry.
Well, I'd say that with those renaming patches we are feeling the need
for it?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Add --author match to git-rev-list and git-rev-tree.
From: Zack Brown @ 2005-05-14 16:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, torvalds, git
In-Reply-To: <20050514155257.GR3905@pasky.ji.cz>
On Sat, May 14, 2005 at 05:52:57PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, May 14, 2005 at 05:06:07PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > On Sat, May 14, 2005 at 02:50:24AM -0700, Junio C Hamano wrote:
> > > Zack Brown wondered if handling author match at core GIT level
> > > would make cg-log -u go faster (JIT also can use this in jit-log
> > > --author). Here is a patch to implement it.
> > >
> > > I considered adding author and committer strings to commit
> > > objects for general use as commit objects are parsed, but I was
> > > unsure about the lifetime rules of the commit objects (nobody
> > > seems to free them in the current code), so refrained from doing
> > > so for the time being. The code instead re-reads the commit
> > > object when it needs to filter them by the author.
> >
> > I applied this, but can't figure out the change to make to cg-log in order to
> > actually test it.
> >
> > - git-cat-file commit $commit | grep -e '^author ' -e '^committer ' | grep -qi "$user" || continue
> > + git-cat-file --author $user commit $commit || continue
> >
> > sure didn't work.
>
> You throw that whole thing away and pass the --author parameter directly
> to git-rev-(list|tree).
You mean like this?
Be well,
Zack
Use git-rev-(list|tree) --author to cg-log
Signed-off-by: Zack Brown <zbrown@tumblerings.org>
--- de641904363cd3759f132ee7c0dfaf8a2ee58388/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -112,12 +112,20 @@
if [ "$log_end" ]; then
id1="$(commit-id $log_start)" || exit 1
id2="$(commit-id $log_end)" || exit 1
- revls="git-rev-tree $id2 ^$id1"
+ if [ "$user" ]; then
+ revls="git-rev-tree --author $user $id2 ^$id1"
+ else
+ revls="git-rev-tree $id2 ^$id1"
+ fi
revsort="sort -rn"
revfmt="git-rev-tree"
else
id1="$(commit-id $log_start)" || exit 1
- revls="git-rev-list $id1"
+ if [ "$user" ]; then
+ revls="git-rev-list --author $user $id1"
+ else
+ revls="git-rev-list $id1"
+ fi
revsort="cat"
revfmt="git-rev-list"
fi
@@ -131,9 +139,6 @@
parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
[ "$parent" ] && [ "$(git-diff-tree -r $commit $parent "$@")" ] || continue
fi
- if [ "$user" ]; then
- git-cat-file commit $commit | grep -e '^author ' -e '^committer ' | grep -qi "$user" || continue
- fi
echo $colheader""commit ${commit%:*} $coldefault;
git-cat-file commit $commit | \
while read key rest; do
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: Rename tracking
From: Junio C Hamano @ 2005-05-14 16:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: torvalds, git
In-Reply-To: <20050514151159.GL3905@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> I'll postpone it for another while since there is still some discussion
PB> about tuning the output.
What discussion did I miss???
PB> I'm thinking about using "\n---\n\n" in commit message to separate some
PB> "internal data" like this. cg-log (and web interfaces and other
PB> toolkits, if we get to agree on something common) could then by default
PB> hide it. Below it would contain something which we could hopefully embed
PB> in patches too (actually less work for extracting patches by cg-mkpatch
PB> or similar tools). What do you think?
Since I have not been particularly interested in rename tracking
(because I myself personally have not felt the need for it), I
do not offhand have much idea worth to offer. Sorry.
^ permalink raw reply
* Re: cg-log gives error on old tags
From: Zack Brown @ 2005-05-14 15:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050514155134.GQ3905@pasky.ji.cz>
On Sat, May 14, 2005 at 05:51:34PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, May 14, 2005 at 05:41:21PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > On Sat, May 14, 2005 at 05:31:58PM +0200, Petr Baudis wrote:
> > > Dear diary, on Sat, May 14, 2005 at 05:19:22PM CEST, I got a letter
> > > where Zack Brown <zbrown@tumblerings.org> told me that...
> > > > I should add, I'm fully current with the cogito origin, with Junio's --author
> > > > patch on top.
> > >
> > > Hmm, works here. I forgot to update the tags immediately after the big
> > > rehashing, so you could get them from that time and rsync wouldn't
> > > overwrite them. Try deleting them from .git/refs/tags/ and re-pull.
> >
> > Well, I did a fresh clone of cogito, and the problem went away. Weird.
>
> Yes, so you did an equivalent of removing the old tags and re-pulling.
> What's weird on it?
Nothing really.
>
> > But now I notice that some files from the broken tree are not in the new tree:
>
> Those are old git executables from before the big renaming to use git-
> prefix for those. Harmless.
That's what I figured. But I thought one of the cg-updates would have been
a cg-rm to get rid of them.
Z
>
> --
> Petr "Pasky the avid GIT Traffic reader" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] Add --author match to git-rev-list and git-rev-tree.
From: Petr Baudis @ 2005-05-14 15:52 UTC (permalink / raw)
To: Zack Brown; +Cc: Junio C Hamano, torvalds, git
In-Reply-To: <20050514150607.GA14184@tumblerings.org>
Dear diary, on Sat, May 14, 2005 at 05:06:07PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Sat, May 14, 2005 at 02:50:24AM -0700, Junio C Hamano wrote:
> > Zack Brown wondered if handling author match at core GIT level
> > would make cg-log -u go faster (JIT also can use this in jit-log
> > --author). Here is a patch to implement it.
> >
> > I considered adding author and committer strings to commit
> > objects for general use as commit objects are parsed, but I was
> > unsure about the lifetime rules of the commit objects (nobody
> > seems to free them in the current code), so refrained from doing
> > so for the time being. The code instead re-reads the commit
> > object when it needs to filter them by the author.
>
> I applied this, but can't figure out the change to make to cg-log in order to
> actually test it.
>
> - git-cat-file commit $commit | grep -e '^author ' -e '^committer ' | grep -qi "$user" || continue
> + git-cat-file --author $user commit $commit || continue
>
> sure didn't work.
You throw that whole thing away and pass the --author parameter directly
to git-rev-(list|tree).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-log gives error on old tags
From: Petr Baudis @ 2005-05-14 15:51 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050514154121.GD14184@tumblerings.org>
Dear diary, on Sat, May 14, 2005 at 05:41:21PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Sat, May 14, 2005 at 05:31:58PM +0200, Petr Baudis wrote:
> > Dear diary, on Sat, May 14, 2005 at 05:19:22PM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> told me that...
> > > I should add, I'm fully current with the cogito origin, with Junio's --author
> > > patch on top.
> >
> > Hmm, works here. I forgot to update the tags immediately after the big
> > rehashing, so you could get them from that time and rsync wouldn't
> > overwrite them. Try deleting them from .git/refs/tags/ and re-pull.
>
> Well, I did a fresh clone of cogito, and the problem went away. Weird.
Yes, so you did an equivalent of removing the old tags and re-pulling.
What's weird on it?
> But now I notice that some files from the broken tree are not in the new tree:
Those are old git executables from before the big renaming to use git-
prefix for those. Harmless.
--
Petr "Pasky the avid GIT Traffic reader" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-log gives error on old tags
From: Zack Brown @ 2005-05-14 15:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050514153158.GO3905@pasky.ji.cz>
On Sat, May 14, 2005 at 05:31:58PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, May 14, 2005 at 05:19:22PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > I should add, I'm fully current with the cogito origin, with Junio's --author
> > patch on top.
>
> Hmm, works here. I forgot to update the tags immediately after the big
> rehashing, so you could get them from that time and rsync wouldn't
> overwrite them. Try deleting them from .git/refs/tags/ and re-pull.
Well, I did a fresh clone of cogito, and the problem went away. Weird.
But now I notice that some files from the broken tree are not in the new tree:
Only in cogito.broke: cat-file
Only in cogito.broke: check-files
Only in cogito.broke: checkout-cache
Only in cogito.broke: commit-tree
Only in cogito.broke: convert-cache
Only in cogito.broke: diff-cache
Only in cogito.broke: diff-tree
Only in cogito.broke: diff-tree-helper
Only in cogito.broke: fsck-cache
Only in cogito.broke: http-pull
Only in cogito.broke: init-db
Only in cogito.broke: ls-tree
Only in cogito.broke: merge-base
Only in cogito.broke: merge-cache
Only in cogito.broke: read-tree
Only in cogito.broke: rev-list
Only in cogito.broke: rev-tree
Only in cogito.broke: rpull
Only in cogito.broke: rpush
Only in cogito.broke: show-diff
Only in cogito.broke: show-files
Only in cogito.broke: unpack-file
Only in cogito.broke: update-cache
Only in cogito.broke: write-tree
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: cg-log gives error on old tags
From: Petr Baudis @ 2005-05-14 15:31 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050514151922.GC14184@tumblerings.org>
Dear diary, on Sat, May 14, 2005 at 05:19:22PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> I should add, I'm fully current with the cogito origin, with Junio's --author
> patch on top.
Hmm, works here. I forgot to update the tags immediately after the big
rehashing, so you could get them from that time and rsync wouldn't
overwrite them. Try deleting them from .git/refs/tags/ and re-pull.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [RFD] Ignore rules
From: Petr Baudis @ 2005-05-14 15:30 UTC (permalink / raw)
To: David Greaves; +Cc: Junio C Hamano, torvalds, GIT Mailing Lists
In-Reply-To: <42861584.6020601@dgreaves.com>
Here, I would like more people to speak up, plaese, especially the
authors of other layers over git than Cogito, since I think it'd be
great if we could agree on common ignore rules format and we could just
call the files ".gitignore" instead of ".cgignore", ".jitignore" etc.
Dear diary, on Sat, May 14, 2005 at 05:13:08PM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> I was wondering about supporting _both_ globs and re's
> right now my ignore file has a # to precede comment lines
I assume \# will override that?
> maybe re: precedes regexp lines and unadorned lines are globs.
Or maybe even /, which is the common regexp prefix anyway...
To mention it in this mail too, I think leading '!' should do the
"ignore exclude" - that is, it would override any possible previous
ignore decisions about the file. E.g. '!*' would throw away all
previously applied ignore rules.
> However the re's provided by regex(7) are too weedy to be worth
> bothering with.
> If however, there is a serious plan to go to perl, it may be worth
> providing for this now in the ignore syntax.
>
> Also... you haven't mentioned perl for a while - can you give us an update?
> I personally think we're making life needlessly unpleasant by sticking
> with shell.
If there is still a serious plan, it is much more long-term now, since
shell turns out to keep doing fine and everything we need, and that all
reasonably fast.
That said, I think it's fine to use Perl regexps. I think they rule. :-)
But what do others think? Should we stick with POSIX regexps (I assume
at least extended instead of basic), or go with Perl regexps?
> Additionally this causes problems with sharing the same exclude file as
> used by git.
> However...
> I really think git's exclude file capability and cogito's are different.
> Cogito is aiming to provide full-blown SCM capabilities - git isn't
If we get to agree on some common format, I'm thinking whether it
wouldn't be actually good to extend the --exclude option to support it.
How much of an issue would that be? What do others think?
> I am also concerned that a centralised ignore file is not flexible enough.
> Certainly limiting if we support globs only.
> It may be that you want different rules in different trees - someone on
> lkml mentioned that excludes vary in different parts of the source.
> Eg .s files may be generally ignored - but not in the asm parts of the tree.
I imagine it as (ignore rules applied in this order):
<default ignore list>:
Some builtin ignore list catching files like *.o, *.a and such.
Remember that you can throw it away with !* if you don't like it.
/.git/ignore:
Per-repository ignore list, not version tracked etc; really a local thing.
/.gitignore
/**/.gitignore:
(Applied in the order from the project root to the current directory.)
Version tracked ignore list, which concerns the current directory, BUT
may match pathnames instead of just filenames (but no ..). That is, you
could do something like
echo '*.o' >.gitignore
to ignore all the object files in the current directory, and
echo '**.o' >.gitignore
to also ignore the object files in all the subdirectories.
Opinions?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-log gives error on old tags
From: Zack Brown @ 2005-05-14 15:19 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20050514151157.GB14184@tumblerings.org>
I should add, I'm fully current with the cogito origin, with Junio's --author
patch on top.
Z
On Sat, May 14, 2005 at 08:11:57AM -0700, Zack Brown wrote:
> I'm seeing the following:
>
> 08:10:03 [zbrown] ~/git/cogito$ cg-tag-ls
> cogito-0.10 4ed293bc0a5ffca9683e139cad499b69a4c4d569
> cogito-0.8 f9f0459b5b39cf83143c91ae39b4eaf187cf678a
> cogito-0.9 cc5517b4ea4134c296d4ce2b1d82700c44200c1e
> git-pasky-0.1 6bd145ee46a0be6c2ae618379054647121078d8e
> git-pasky-0.2 b56ce0c70dbd8d74e63f437555f15aa1462c2075
> git-pasky-0.3 2538cadf3e22d768b8eb0d0824ab1e11ac035234
> git-pasky-0.4 fba83970090ef54c6eb86dcc2c2d5087af5ac637
> git-pasky-0.5 cb18faf513e3903cd57f4c3a5b3547b3ffe3292f
> git-pasky-0.6 0605614328f3c150a3dac85904afed5686959335
> git-pasky-0.6.1 8a49796121aef48d3030bb1d812cff1491f850fd
> git-pasky-0.6.2 55f9d5042603fff4ddfaf4e5f004d2995286d6d3
> git-pasky-0.6.3 dd69ca5f806c8b10bb29ecb8d77c88be007c981c
> git-pasky-0.7 c83b95297c2a6336c2007548f909769e0862b509
> pull_from_pasky 11ed64c1b141c9ba397a1ca76aef2cd250976007
> 08:10:07 [zbrown] ~/git/cogito$ cg-log -r git-pasky-0.1:git-pasky-0.2
> error: cannot map sha1 file 6bd145ee46a0be6c2ae618379054647121078d8e
> fatal: git-cat-file 6bd145ee46a0be6c2ae618379054647121078d8e: bad file
> Invalid id: 6bd145ee46a0be6c2ae618379054647121078d8e
> 08:10:14 [zbrown] ~/git/cogito$
>
> --
> Zack Brown
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* cg-log gives error on old tags
From: Zack Brown @ 2005-05-14 15:11 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
I'm seeing the following:
08:10:03 [zbrown] ~/git/cogito$ cg-tag-ls
cogito-0.10 4ed293bc0a5ffca9683e139cad499b69a4c4d569
cogito-0.8 f9f0459b5b39cf83143c91ae39b4eaf187cf678a
cogito-0.9 cc5517b4ea4134c296d4ce2b1d82700c44200c1e
git-pasky-0.1 6bd145ee46a0be6c2ae618379054647121078d8e
git-pasky-0.2 b56ce0c70dbd8d74e63f437555f15aa1462c2075
git-pasky-0.3 2538cadf3e22d768b8eb0d0824ab1e11ac035234
git-pasky-0.4 fba83970090ef54c6eb86dcc2c2d5087af5ac637
git-pasky-0.5 cb18faf513e3903cd57f4c3a5b3547b3ffe3292f
git-pasky-0.6 0605614328f3c150a3dac85904afed5686959335
git-pasky-0.6.1 8a49796121aef48d3030bb1d812cff1491f850fd
git-pasky-0.6.2 55f9d5042603fff4ddfaf4e5f004d2995286d6d3
git-pasky-0.6.3 dd69ca5f806c8b10bb29ecb8d77c88be007c981c
git-pasky-0.7 c83b95297c2a6336c2007548f909769e0862b509
pull_from_pasky 11ed64c1b141c9ba397a1ca76aef2cd250976007
08:10:07 [zbrown] ~/git/cogito$ cg-log -r git-pasky-0.1:git-pasky-0.2
error: cannot map sha1 file 6bd145ee46a0be6c2ae618379054647121078d8e
fatal: git-cat-file 6bd145ee46a0be6c2ae618379054647121078d8e: bad file
Invalid id: 6bd145ee46a0be6c2ae618379054647121078d8e
08:10:14 [zbrown] ~/git/cogito$
--
Zack Brown
^ permalink raw reply
* Re: [PATCH 2/2] update cg-* to use cg-Xignore
From: Petr Baudis @ 2005-05-14 15:14 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <42860EB0.9000105@dgreaves.com>
Dear diary, on Sat, May 14, 2005 at 04:44:00PM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Petr Baudis wrote:
>
> >Dear diary, on Sat, May 14, 2005 at 10:24:42AM CEST, I got a letter
> >where David Greaves <david@dgreaves.com> told me that...
> >
> >
> >>Petr Baudis wrote:
> >>
> >>
> >Makes sense, ok.
> >
> >What about cg-commit? You already even added it.
> >
> >
>
> I'd use the same argument - you want to commit files changed in a directory:
> find src | xargs cg-commit
> find Documentation | xargs cg-commit
> I agree it's less compelling.
> I admit I was primarily just making sure that all cg-* commands behaved
> the same way.
Thinking about it, I think we can actually live with it. I agree that
it's more consistent.
> I also don't have an ignore-override - do you think we need one?
I'd prefer CVS-like format. That is, lines starting with ! are
exceptions to previous ignore rules.
> >>No, cogito has an ignore.
> >>git has a less powerful exclude.
> >>cogito users won't need exclude but power-users aren't barred from it.
> >>
> >>
> >
> >I think having two essentially redundant things is useless. But you'll
> >be able to use the --exclude powers now since you have to fall back to
> >good ol' globs.
> >
> >
> unless...
See my other mail that I'd prefer globs as the main ignoring mechanism
anyway. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Ignore file filter
From: David Greaves @ 2005-05-14 15:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, GIT Mailing Lists
In-Reply-To: <20050514142421.GG3905@pasky.ji.cz>
Petr Baudis wrote:
>Dear diary, on Sat, May 14, 2005 at 11:01:49AM CEST, I got a letter
>where Junio C Hamano <junkio@cox.net> told me that...
>
>
>>>>>>>"DG" == David Greaves <david@dgreaves.com> writes:
>>>>>>>
>>>>>>>
>>>>>if [[ $file =~ $patt ]]; then
>>>>>
>>>>>
>>>>I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.
>>>>
>>>>
>>DG> OK
>>DG> I don't know how to do that.
>>
>>Is that regexp or shell glob? If regexp, expr is your friend,
>>like this:
>>
>> if expr "$file" : "$patt" >/dev/null; then
>>
>>
>
>Oh, this looks nice. I didn't know expr can do that. :-)
>
>Still, I'd prefer the old-fashioned globs as primary matching mechanism.
>
>
OK
I was wondering about supporting _both_ globs and re's
right now my ignore file has a # to precede comment lines
maybe re: precedes regexp lines and unadorned lines are globs.
However the re's provided by regex(7) are too weedy to be worth
bothering with.
If however, there is a serious plan to go to perl, it may be worth
providing for this now in the ignore syntax.
Additionally this causes problems with sharing the same exclude file as
used by git.
However...
I really think git's exclude file capability and cogito's are different.
Cogito is aiming to provide full-blown SCM capabilities - git isn't
I am also concerned that a centralised ignore file is not flexible enough.
Certainly limiting if we support globs only.
It may be that you want different rules in different trees - someone on
lkml mentioned that excludes vary in different parts of the source.
Eg .s files may be generally ignored - but not in the asm parts of the tree.
Also... you haven't mentioned perl for a while - can you give us an update?
I personally think we're making life needlessly unpleasant by sticking
with shell.
David
--
^ permalink raw reply
* Rename tracking
From: Petr Baudis @ 2005-05-14 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vk6m260xf.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, May 14, 2005 at 03:39:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Here are three patches to update diff we discussed earlier.
>
> [PATCH 1/3] Update mode-change strings in diff output.
> [PATCH 2/3] Rename git-diff-tree-helper to git-diff-helper.
> [PATCH 3/3] Rename git-diff-tree-helper to git-diff-helper (part 2).
>
> The first one is to normalize the mode bits output to be more
> machine friendly, which we discussed.
I'll postpone it for another while since there is still some discussion
about tuning the output.
> The second commit records only renames for two files and there
> is no content change. The third one is to change the Makefiles,
> documentation, and also usage string in git-diff-helper itself.
>
> I am deliverately doing the 2 and 3 in separate steps for two
> reasons. (1) to reduce the possibility of mistakes during the
> rename for myself; (2) people doing the git repository browser
> can use the commit trail for practicing their rename detection
> logic. So please keep these two steps separate when you commit.
I buy that it is nice for now to keep the changes to the renamed files
separate, but I don't see why should I withhold changing other files
in parallel with the rename.
But I think we really need explicit rename tracking, since this really
sucks. And even if someone would written a hyperintelligent content
moves heuristic tracker, it would be horribly slow on longer distances,
and more importantly it could still be confused when renaming several
similar or same files in parallel.
I'm thinking about using "\n---\n\n" in commit message to separate some
"internal data" like this. cg-log (and web interfaces and other
toolkits, if we get to agree on something common) could then by default
hide it. Below it would contain something which we could hopefully embed
in patches too (actually less work for extracting patches by cg-mkpatch
or similar tools). What do you think?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Add --author match to git-rev-list and git-rev-tree.
From: Zack Brown @ 2005-05-14 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pasky, torvalds, git
In-Reply-To: <7vu0l62l27.fsf@assigned-by-dhcp.cox.net>
On Sat, May 14, 2005 at 02:50:24AM -0700, Junio C Hamano wrote:
> Zack Brown wondered if handling author match at core GIT level
> would make cg-log -u go faster (JIT also can use this in jit-log
> --author). Here is a patch to implement it.
>
> I considered adding author and committer strings to commit
> objects for general use as commit objects are parsed, but I was
> unsure about the lifetime rules of the commit objects (nobody
> seems to free them in the current code), so refrained from doing
> so for the time being. The code instead re-reads the commit
> object when it needs to filter them by the author.
I applied this, but can't figure out the change to make to cg-log in order to
actually test it.
- git-cat-file commit $commit | grep -e '^author ' -e '^committer ' | grep -qi "$user" || continue
+ git-cat-file --author $user commit $commit || continue
sure didn't work.
Z
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> commit.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> commit.h | 2 ++
> rev-list.c | 6 ++++++
> rev-tree.c | 13 +++++++++++--
> 4 files changed, 61 insertions(+), 2 deletions(-)
>
> --- a/commit.c
> +++ b/commit.c
> @@ -152,3 +152,45 @@
> }
> return ret;
> }
> +
> +int author_match(const struct commit *item, const char *author)
> +{
> + char type[20];
> + void *buffer;
> + char *author_line, *ep;
> + unsigned long size;
> + int ret;
> +
> + buffer = read_sha1_file(item->object.sha1, type, &size);
> + if (!buffer)
> + return error("Could not read %s",
> + sha1_to_hex(item->object.sha1));
> + if (strcmp(type, commit_type)) {
> + free(buffer);
> + error("Object %s not a commit",
> + sha1_to_hex(item->object.sha1));
> + return 0;
> + }
> + /* we do not care what is in the message; we do not
> + * want to overrun with strstr and strchr.
> + */
> + ep = buffer + (size -1);
> + *ep = 0;
> + if ((author_line = strstr(buffer, "\nauthor ")) == 0) {
> + free(buffer);
> + error("Commit %s does not have author.",
> + sha1_to_hex(item->object.sha1));
> + return 0;
> + }
> + author_line = strchr(author_line, ' ') + 1;
> + if ((ep = strchr(author_line, '>')) == 0) {
> + free(buffer);
> + error("Commit %s has a malformed author line.",
> + sha1_to_hex(item->object.sha1));
> + return 0;
> + }
> + *++ep = 0;
> + ret = (strstr(author_line, author) != 0);
> + free(buffer);
> + return ret;
> +}
> --- a/commit.h
> +++ b/commit.h
> @@ -36,4 +36,6 @@
> struct commit *pop_most_recent_commit(struct commit_list **list,
> unsigned int mark);
>
> +int author_match(const struct commit *, const char *);
> +
> #endif /* COMMIT_H */
> --- a/rev-list.c
> +++ b/rev-list.c
> @@ -11,6 +11,7 @@
> unsigned long max_age = -1;
> unsigned long min_age = -1;
> int max_count = -1;
> + const char *author = NULL;
>
> for (i = 1 ; i < argc; i++) {
> char *arg = argv[i];
> @@ -21,6 +22,8 @@
> max_age = atoi(arg + 10);
> } else if (!strncmp(arg, "--min-age=", 10)) {
> min_age = atoi(arg + 10);
> + } else if (!strncmp(arg, "--author=", 9)) {
> + author = arg + 9;
> } else {
> commit_arg = arg;
> }
> @@ -28,6 +31,7 @@
>
> if (!commit_arg || get_sha1(commit_arg, sha1))
> usage("usage: rev-list [OPTION] commit-id\n"
> + " --author=author\n"
> " --max-count=nr\n"
> " --max-age=epoch\n"
> " --min-age=epoch\n");
> @@ -44,6 +48,8 @@
> continue;
> if (max_age != -1 && (commit->date < max_age))
> break;
> + if (author && !author_match(commit, author))
> + continue;
> if (max_count != -1 && !max_count--)
> break;
> printf("%s\n", sha1_to_hex(commit->object.sha1));
> --- a/rev-tree.c
> +++ b/rev-tree.c
> @@ -64,7 +64,7 @@
> }
>
> /*
> - * Usage: rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id2>]
> + * Usage: rev-tree [--edges] [--author <author>] [--cache <cache-file>] <commit-id> [<commit-id2>]
> *
> * The cache-file can be quite important for big trees. This is an
> * expensive operation if you have to walk the whole chain of
> @@ -75,6 +75,7 @@
> int i;
> int nr = 0;
> unsigned char sha1[MAX_COMMITS][20];
> + const char *author = NULL;
>
> /*
> * First - pick up all the revisions we can (both from
> @@ -83,6 +84,11 @@
> for (i = 1; i < argc ; i++) {
> char *arg = argv[i];
>
> + if (!strcmp(arg, "--author")) {
> + author = argv[++i];
> + continue;
> + }
> +
> if (!strcmp(arg, "--cache")) {
> read_cache_file(argv[++i]);
> continue;
> @@ -98,7 +104,7 @@
> basemask |= 1<<nr;
> }
> if (nr >= MAX_COMMITS || get_sha1(arg, sha1[nr]))
> - usage("rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id>]");
> + usage("rev-tree [--edges] [--author <author>] [--cache <cache-file>] <commit-id> [<commit-id>]");
> process_commit(sha1[nr]);
> nr++;
> }
> @@ -125,6 +131,9 @@
> if (!interesting(commit))
> continue;
>
> + if (author && !author_match(commit, author))
> + continue;
> +
> printf("%lu %s:%d", commit->date, sha1_to_hex(obj->sha1),
> obj->flags);
> p = commit->parents;
> ------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Petr Baudis @ 2005-05-14 15:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7voebe63zs.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, May 14, 2005 at 02:33:11AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Another possibility. How about generating the following _only_
> when mode changes (including create and delete), even for human
> consumption? There will be _no_ such line when mode or type
> does not change.
>
> # mode: 100644 100755 path/to/a/file/that/changed/mode
> # mode: 100644 120000 path/to/a/file/that/changed/to/symlink
> # mode: 100644 100644 path/to/a/file/with/no/mode/change
> # mode: . 100644 path/to/a/new/file
> # mode: 100644 . path/to/a/deleted/file
>
> This is not "something like this", but a proposal for the exact
> output format specification (I am going to code immediately).
> Each token above is separated with exactly one ' ' (ASCII 0x20)
> each, and such a line comes immediately before the patch for the
> file. Showing both mode bits is to prepare for the case you
> would want to apply the patch in reverse.
>
> This is for machine consumption and there is no need to force
> them to parse out -> and (), so I dropped them. And mode or
> type change happens so rarely, it would be OK for human
> consumption if we show these garbage (from human point of view)
> only when things change. Can you parse this, or do you always
> want to have them even if nothing changes?
>
> Let's see how this would look like to humans.
For humans I'd say "Mode change" instead of "mode" would be better, and
for machines I still think "@" would be better than "#". "#" can occur
quite naturally in some code snippets or whatever pasted to the commit
message, which is extremely unlikely for "@". What are the advantages
of "#"?
I like the rest. That's basically what I've imagined, and without the
arrows it's even better. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Petr Baudis @ 2005-05-14 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzqy7k47.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, May 14, 2005 at 01:59:36AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> Dear diary, on Sat, May 14, 2005 at 12:59:31AM CEST, I got a letter
> PB> where Junio C Hamano <junkio@cox.net> told me that...
> >> Created: t/t2000-diff.sh (mode:100755)
> >> +Mode changed: path0 (100644->100755)
>
> PB> Great, so it's even worse than before. :/
>
> Depends on the definition of "before". At the beginning, we did
> not do anything special and always said l/foo k/foo even when
> create/delete was involved. Then we did a misguided attempt to
> minimally be cg-diff compatible, which Linus complained that it
> was too distracting for human consumption. The current one is
> something in between, a lot more human side.
By "before" I meant the Linus proposal I was originally replying too.
It seems I'm still missing part of the history. :-)
> You have seen what the current "something in between" does.
> What I think is that in order not to distract human (read:
> Linus) who reads patches, they should not share the same special
> characters like "@". Which unfortunately completely contradicts
> what you are attempting to do.
I don't think it discards humans, actually. I'd rather say it makes them
aware that this is something special. And if you show it only when the
mode changes, it will always be a special thing, not only something
which clutters the view.
So I'd say it's better for humans too, since it is clear for them that
this is not part of the commit message, and it carries special meaning
for the tool they will feed it to.
> Another thing we did while you were looking other way ;-) was that we
> say mode changed only when things change, so in that sense it is
> "inconsistent" from the scripting point of view.
I have no issue with that.
> I do not think nobody uses that current textual "comment"
> information in automated tools (I do not), so changing them
> should not be a problem. How about we do something like this:
>
> 1. Invent an environment variable you can define. Let's say
> GIT_DIFF_SHOW_MODES. It could alternatively a flag you
> pass from git-diff-{files,cache,tree,tree-helper} to the
> internal diff engine but then you need to add the necessary
> command line parameter for all these commands. I can be
> persuaded in either way.
I think this completely misses the point. You are viewing what I'm
suggesting as trying to just aid Cogito's internals using cg-diff |
cg-patch, but that's actually not my major reason for doing this at all.
I view that as a hack anyway and it should eventually do a three-way
merge too at those places.
What I'm trying to do is to figure out a good encapsulation for mode
changes which can be put in *all* the patches. So when you are sending
me some new testcases, I don't have to chmod them manually. That's the
main point of doing this. I could deal with mode changes completely
separately if it was only about Cogito's internal stuff.
> BTW, what do you think about renaming git-diff-tree-helper to
> just git-diff-helper? It used to be for grokking diff-tree's
> output but now the family have the same raw output format it
> does not make much sense to keep "tree" in its name.
No issue with that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH 2/2] update cg-* to use cg-Xignore
From: David Greaves @ 2005-05-14 14:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050514121846.GE3905@pasky.ji.cz>
Petr Baudis wrote:
>Dear diary, on Sat, May 14, 2005 at 10:24:42AM CEST, I got a letter
>where David Greaves <david@dgreaves.com> told me that...
>
>
>>Petr Baudis wrote:
>>
>>
>Makes sense, ok.
>
>What about cg-commit? You already even added it.
>
>
I'd use the same argument - you want to commit files changed in a directory:
find src | xargs cg-commit
find Documentation | xargs cg-commit
I agree it's less compelling.
I admit I was primarily just making sure that all cg-* commands behaved
the same way.
I also don't have an ignore-override - do you think we need one?
>>No, cogito has an ignore.
>>git has a less powerful exclude.
>>cogito users won't need exclude but power-users aren't barred from it.
>>
>>
>
>I think having two essentially redundant things is useless. But you'll
>be able to use the --exclude powers now since you have to fall back to
>good ol' globs.
>
>
unless...
--
^ permalink raw reply
* Re: speeding up cg-log -u
From: Petr Baudis @ 2005-05-14 14:40 UTC (permalink / raw)
To: Zack Brown; +Cc: Junio C Hamano, git, torvalds
In-Reply-To: <20050514142325.GC14353@tumblerings.org>
Dear diary, on Sat, May 14, 2005 at 04:23:25PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Sat, May 14, 2005 at 04:17:44AM -0700, Junio C Hamano wrote:
> > Not wanting to keep the whole object because of their size is
> > understandable since the users of "struct object" derivatives
> > rarely if ever seem to free them once they get hold of them.
> > And not wanting to think ahead about what is worth keeping (like
> > names for tree entries back then, or commit author names) is
> > also understandable, but it still is frustrating.
>
> So if this design is changed to suit -u, would a further redesign be needed
> to support an option to filter on keywords in the body of the changelog
> entry? Perhaps this will result in a net slowdown for the usual case of just
> grabbing all log entries.
I admit not looking at this code for a rather long time, but what about
just telling the commit parser what stuff are you interested in and it
would leave the rest of the structure fields NULL? That would mean only
slight memory usage increase and basically no time increase.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: speeding up cg-log -u
From: Zack Brown @ 2005-05-14 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, torvalds
In-Reply-To: <7vk6m212g7.fsf@assigned-by-dhcp.cox.net>
On Sat, May 14, 2005 at 04:17:44AM -0700, Junio C Hamano wrote:
> Not wanting to keep the whole object because of their size is
> understandable since the users of "struct object" derivatives
> rarely if ever seem to free them once they get hold of them.
> And not wanting to think ahead about what is worth keeping (like
> names for tree entries back then, or commit author names) is
> also understandable, but it still is frustrating.
So if this design is changed to suit -u, would a further redesign be needed
to support an option to filter on keywords in the body of the changelog
entry? Perhaps this will result in a net slowdown for the usual case of just
grabbing all log entries.
Be well,
Zack
> Not that I
> would want to solve this myself ...
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] Ignore file filter
From: David Greaves @ 2005-05-14 14:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050514122134.GF3905@pasky.ji.cz>
Petr Baudis wrote:
>Dear diary, on Sat, May 14, 2005 at 10:28:24AM CEST, I got a letter
>where David Greaves <david@dgreaves.com> told me that...
>
>
>>Also I don't think cg-Xlib should be doing arg handling.
>>As an include it should provide an arg handling function that the
>>scripts call.
>>
>>
>
>I'd prefer the few and scattered users which don't want arg handling to
>explicitly set some magic variable before calling cg-Xlib rather than
>adding the arg parser function call everywhere else.
>
>
OK
>>>> if [[ $file =~ $patt ]]; then
>>>>
>>>>
>>>I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.
>>>We're already bash-only, but further reducing that to bash3 really won't
>>>work. I *might* get convinced to add some bash2+-only feature, but only
>>>if you'll be really good at explaining that it makes sense.
>>>
>>>
>>OK
>>I don't know how to do that.
>>I was actually aiming for glob matching when I came upon this in the
>>manpage.
>>
>>
>Ok, so what's the outcome? Are you going to stop at this point, or will
>you change the scripts so that they use the glob list?
>
>
Well, Junio solved that for me - I'll gather the comments and resubmit.
David
--
^ permalink raw reply
* Re: [PATCH] Ignore file filter
From: Petr Baudis @ 2005-05-14 14:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Greaves, GIT Mailing Lists
In-Reply-To: <7vy8ai2nb6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, May 14, 2005 at 11:01:49AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "DG" == David Greaves <david@dgreaves.com> writes:
>
> >>> if [[ $file =~ $patt ]]; then
> >>
> >> I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.
> DG> OK
> DG> I don't know how to do that.
>
> Is that regexp or shell glob? If regexp, expr is your friend,
> like this:
>
> if expr "$file" : "$patt" >/dev/null; then
Oh, this looks nice. I didn't know expr can do that. :-)
Still, I'd prefer the old-fashioned globs as primary matching mechanism.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox