* 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
* Re: [PATCH] Ignore file filter
From: Petr Baudis @ 2005-05-14 12:21 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <4285B6A8.4080309@dgreaves.com>
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...
> >>#. ${COGITO_LIB}cg-Xlib
> >>_git=${GIT_DIR:-.git}
> >>
> >>
> >
> >...but it makes no sense anyway I think to reinclude this stuff from a
> >cg-Xfile you are including from other scripts anyway.
> >
> >
> cg-Xignore isn't included - only called.
Oh yes, I'm stupid.
> it's also just a library program.
> 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.
> >> 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.
> >
> >
> Ah
> 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?
--
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: Petr Baudis @ 2005-05-14 12:18 UTC (permalink / raw)
To: David Greaves; +Cc: GIT Mailing Lists
In-Reply-To: <4285B5CA.8060106@dgreaves.com>
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:
>
> >Dear diary, on Sat, May 14, 2005 at 12:32:22AM CEST, I got a letter
> >where David Greaves <david@dgreaves.com> told me that...
> >
> >
> >>Updated
> >> cg-add
> >> cg-commit
> >>
> >>
> >
> >I consider this Bad Thing (tm). Or could you please point a situation
> >where this would be actually useful? If you explicitly cg-add, you
> >likely know what are you doing, and same thing with cg-commit - if it's
> >already added, it should be watches, no matter what ignore patterns, I
> >think.
> >
> >
> OK, lets say I'm clever and know what an ignore pattern is.
> I can
> find * | xargs cg-add
> my laziness something my hubris acknowledges :)
Makes sense, ok.
What about cg-commit? You already even added it.
> >>Index: cg-status
> >>===================================================================
> >>--- d2490ad0bc8b38647c6baff9da3e72c0f25e9f35/cg-status (mode:100755)
> >>+++ 03662df7d089d4a84987ef9edb50a017b8b42439/cg-status (mode:100755)
> >>@@ -15,21 +15,11 @@
> >>
> >> {
> >> git-ls-files -z -t --others --deleted --unmerged $EXCLUDE
> >>-} | sort -z -k 2 | xargs -0 sh -c '
> >>-while [ "$1" ]; do
> >>- tag=${1% *};
> >>- filename=${1#* };
> >>- case "$filename" in
> >>- *.[ao] | tags | ,,merge*) ;;
> >>- *) echo "$tag $filename";;
> >>- esac
> >>- shift
> >>-done
> >>-' padding
> >>+} | sort -z -k 2 | cg-Xignore -0 -t | tr "\000" "\n"
> >>
> >>
> >
> >So you have two ignores now - exclude and Xignore.
> >
> >
> 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.
--
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: Junio C Hamano @ 2005-05-14 11:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: Zack Brown, git, torvalds
In-Reply-To: <20050514103937.GA3905@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Dear diary, on Sat, May 14, 2005 at 11:50:24AM CEST, I got a letter
PB> where Junio C Hamano <junkio@cox.net> told me that...
>> + buffer = read_sha1_file(item->object.sha1, type, &size);
PB> If it do that, I wonder how much speedup would be using this instead.
PB> But probably still significant one.
I would imagine so (only benchmark would tell), because you
would not spawn git-cat-file for each individual commit object.
Whenever I work with those "struct object" derivatives, I get
very frustrated by the fact that they are designed to cater only
to the need of very narrow immediate users. The first round of
tree objects did not even have names for each entry because the
only thing it cared about was connectivity checking, and for
that purpose callers would not care about what each blob or
subtree was referred as. Now when I want to use commit objects
I find that it only records the commit date (other than
connectivity information). It really appears that connectivity
is the primary thing and everything else is bolted on top.
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. Not that I
would want to solve this myself ...
^ permalink raw reply
* Re: speeding up cg-log -u
From: Petr Baudis @ 2005-05-14 11:14 UTC (permalink / raw)
To: Zack Brown, Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <20050514103937.GA3905@pasky.ji.cz>
Where was my English? Sorry.
> If it do that, I wonder how much speedup would be using this instead.
(does)
> But probably still significant one.
>
> What I don't like is that it searches only the author field. I find the
> behaviour that it searches in the committer field as well very useful,
> since I can easily check whose patches on a file I checked it
(which patches of a file I checked in)
--
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 cogito] "cg-whatsnew" command
From: Petr Baudis @ 2005-05-14 11:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx64xm5b2b.fsf@arm.com>
Dear diary, on Sat, May 14, 2005 at 12:58:04PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> told me that...
> This patch adds a simple command that shows the unmerged changes on a
> branch. I find it quite useful to be able to see the diff or the log
> before merging (gnuarch has something similar with "missing").
I'd prefer this to be functionality builtin to cg-log and cg-mkpatch.
Perhaps some
cg-log -m $branch2 [$branch1]
to show stuff in branch2 not yet merged to branch1.
--
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