* Re: [PATCH 2/4] tests: Remove heredoc usage inside quotes
From: Herbert Xu @ 2006-05-26 12:22 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11486091783808-git-send-email-normalperson@yhbt.net>
On Thu, May 25, 2006 at 07:06:16PM -0700, Eric Wong wrote:
> The use of heredoc inside quoted strings doesn't seem to be
> supported by dash. pdksh seems to handle it fine, however.
This is a bug in dash and should be fixed there instead.
Thanks for drawing my attention to it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] gitk: Replace "git-" commands with "git "
From: Paul Mackerras @ 2006-05-26 12:26 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: raa.lkml, git
In-Reply-To: <20060526145954.cea5613c.tihirvon@gmail.com>
OK, thanks. I have applied your patch. The ones that gitk uses that
aren't built-in now are git-rev-parse and git-repo-config, which
aren't performance-critical.
Paul.
^ permalink raw reply
* Re: [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Herbert Xu @ 2006-05-26 12:23 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11486091793385-git-send-email-normalperson@yhbt.net>
On Thu, May 25, 2006 at 07:06:17PM -0700, Eric Wong wrote:
> None of the variables seem to conflict, so local was unnecessary.
BTW, dash supports (and has always supported) local which is a quite
useful feature.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/4] t6000lib: workaround a possible dash bug
From: Herbert Xu @ 2006-05-26 12:33 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11486091792604-git-send-email-normalperson@yhbt.net>
On Thu, May 25, 2006 at 07:06:18PM -0700, Eric Wong wrote:
>
> t/t6000lib.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> cba907ce0b1c0927fb15cbb5dd91a4129ff9a950
> diff --git a/t/t6000lib.sh b/t/t6000lib.sh
> index c6752af..d402621 100755
> --- a/t/t6000lib.sh
> +++ b/t/t6000lib.sh
> @@ -69,7 +69,9 @@ on_committer_date()
> {
> _date=$1
> shift 1
> - GIT_COMMITTER_DATE=$_date "$@"
> + export GIT_COMMITTER_DATE="$_date"
> + "$@"
> + unset GIT_COMMITTER_DATE
The original code looks correct to me. So I think this too should
be fixed in dash instead.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Johannes Schindelin @ 2006-05-26 13:36 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Stefan Pfetzing, Git Mailing List
In-Reply-To: <20060526011153.GA27720@spearce.org>
Hi,
On Thu, 25 May 2006, Shawn Pearce wrote:
> Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
> >
> > for some reason I could not yet figure out, t8001-annotate.sh fails at test
> > 18.
>
> I've been seeing the same failed test case for a long time now on
> my own Mac OS X system.
... which is sort of funny, because I don't see it on my system. Running
an iBook G3 with Mac OS X 10.2.8. "make test" runs through, and no, AFAICT
I do not have any local modifications which could be responsible for that.
Ciao,
Dscho
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Stefan Pfetzing @ 2006-05-26 13:51 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605261534270.27610@wbgn013.biozentrum.uni-wuerzburg.de>
Hi Johannes,
2006/5/26, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > I've been seeing the same failed test case for a long time now on
> > my own Mac OS X system.
>
> ... which is sort of funny, because I don't see it on my system. Running
> an iBook G3 with Mac OS X 10.2.8. "make test" runs through, and no, AFAICT
> I do not have any local modifications which could be responsible for that.
Hm, well thats strange, although I guess Shawn runs Tiger - as I do.
(10.4.6 currently).
I tried already with DarwinPorts perl and OSX sytem perl. Both did not
work as expected.
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* (unknown)
From: Juergen Ruehle @ 2006-05-26 15:16 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* ~/.git/config ?
From: Anand Kumria @ 2006-05-26 15:28 UTC (permalink / raw)
To: git
Hi,
git is unable to construct a reasonable default email address in my
current environment. So, I use GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
to override things.
This has worked well but, now, I need to vary the email address for some
repositories. Unfortunately the environment variables override
.git/config.
It would be good if things were like:
- try to construct one automagically
- use ~/.git/config (if available)
- use .git/config
- use environment variables
That way I could set my default email address in ~/.git/config and
override it as required for those repositories that need it.
Thanks,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: Slow fetches of tags
From: Ralf Baechle @ 2006-05-26 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd5e21zh9.fsf@assigned-by-dhcp.cox.net>
On Wed, May 24, 2006 at 09:48:34PM -0700, Junio C Hamano wrote:
> I think the right fix for this is to change upload-pack to
> traverse reachability chain from the "want" heads as it gets
> "have" from the downloader, and stop responding "continue" when
> all "want" heads can reach some "have" commits. This would not
> prevent it from going down all the way to the root commit if
> what is wanted does not have anything to do with what the other
> end has (e.g. if you have only my main project branches, and you
> ask for html head for the first time), but it would have
> prevented Ralf's tree from getting "continue" after he asked
> only for v2.6.16.18 tag and said he has 2.6.16.18 commit and its
> ancestors. It should not be too difficult to do this, but here
> is an alternative, client-side workaround.
>
> -- >8 --
> [PATCH] fetch-pack: give up after getting too many "ack continue"
So I did test your patch. In the big, slow repository it cuts down the
time for a
git fetch git://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git master:v2.6.16-stable
from like 6min to about 7s.
Thanks!
Ralf
^ permalink raw reply
* git-apply can't apply patches to CRLF-files
From: Salikh Zakirov @ 2006-05-26 16:00 UTC (permalink / raw)
To: git
Hello,
git-apply can't apply the patch to file with windows-style CRLF line endings,
even if the patch was generated by git-format-patch.
Is this a bug or known deficiency?
The following script reproduces the problem
---------
#!/bin/sh
set -e
mkdir trash
cd trash
git init-db
echo "abc" > a
unix2dos a
git add a
git commit -m "a added" a
echo "cde" >> a
unix2dos a
git commit -m "a modified" a
git format-patch HEAD^
git reset --hard HEAD^
git am 0001*.txt
---------
The resulting output is
---------
$ ./test
defaulting to local storage area
a: done.
Committing initial tree 357c56061b96c1548b15168bc0d02e8d1a319e0b
a: done.
0001-a-modified.txt
Applying 'a modified'
error: patch failed: a:1
error: a: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".
---------
If I remove unix2dos calls and so the file has normal unix LF line endings,
then the result is correct as expected
---------
$ ./test
defaulting to local storage area
Committing initial tree 6afc8719a182fed19980da0e53d13fba1f94dd3f
0001-a-modified.txt
Applying 'a modified'
Wrote tree 49f5181a399bbcaac1da3bf693c466a281c4a255
Committed: 2b0a2936d0a65b3511882b8e88586ab054dd15b2
---------
^ permalink raw reply
* Re: ~/.git/config ?
From: Timo Hirvonen @ 2006-05-26 16:33 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <20060526152837.GQ23852@progsoc.uts.edu.au>
Anand Kumria <wildfire@progsoc.uts.edu.au> wrote:
> Hi,
>
> git is unable to construct a reasonable default email address in my
> current environment. So, I use GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
> to override things.
>
> This has worked well but, now, I need to vary the email address for some
> repositories. Unfortunately the environment variables override
> .git/config.
>
> It would be good if things were like:
> - try to construct one automagically
> - use ~/.git/config (if available)
> - use .git/config
> - use environment variables
>
> That way I could set my default email address in ~/.git/config and
> override it as required for those repositories that need it.
I backup my $HOME using git, so there's a .git directory in ~. I don't
think a global config file is really needed but it would be nice if
.git/config would override the environment variables, not the other way
around.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: ~/.git/config ?
From: Jakub Narebski @ 2006-05-26 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <20060526193325.d2a530a4.tihirvon@gmail.com>
Timo Hirvonen wrote:
> Anand Kumria <wildfire@progsoc.uts.edu.au> wrote:
>
>> Hi,
>>
>> git is unable to construct a reasonable default email address in my
>> current environment. So, I use GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
>> to override things.
>>
>> This has worked well but, now, I need to vary the email address for some
>> repositories. Unfortunately the environment variables override
>> .git/config.
>>
>> It would be good if things were like:
>> - try to construct one automagically
>> - use ~/.git/config (if available)
>> - use .git/config
>> - use environment variables
>>
>> That way I could set my default email address in ~/.git/config and
>> override it as required for those repositories that need it.
>
> I backup my $HOME using git, so there's a .git directory in ~. I don't
> think a global config file is really needed but it would be nice if
> .git/config would override the environment variables, not the other way
> around.
Well, I'm not sure if environmental variables overriding wouldn't make
invocations like 'GIT_DIR=something git command' possible.
There are templates, also for config. Currently git lacks user (not
repository) config file, e.g. ~/.gitconfig (common for all repositories).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-26 16:38 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Anand Kumria, git
In-Reply-To: <20060526193325.d2a530a4.tihirvon@gmail.com>
Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> I backup my $HOME using git, so there's a .git directory in ~.
Then it should be called ~/.gitconfig. :-)
> I don't think a global config file is really needed but it would be
> nice if .git/config would override the environment variables, not the
> other way around.
Then you have no other way to override .git/config e.g. when committing
patches submitted by other people.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Call builtin ls-tree in git-cat-file -p
From: Petr Baudis @ 2006-05-26 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
builtin-cat-file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 8ab136e..4d36817 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -141,7 +141,7 @@ int cmd_cat_file(int argc, const char **
/* custom pretty-print here */
if (!strcmp(type, tree_type))
- return execl_git_cmd("ls-tree", argv[2], NULL);
+ return cmd_ls_tree(2, argv + 1, NULL);
buf = read_sha1_file(sha1, type, &size);
if (!buf)
^ permalink raw reply related
* Re: ~/.git/config ?
From: Timo Hirvonen @ 2006-05-26 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: wildfire, git
In-Reply-To: <20060526163829.GB10488@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> where Timo Hirvonen <tihirvon@gmail.com> said that...
> > I backup my $HOME using git, so there's a .git directory in ~.
>
> Then it should be called ~/.gitconfig. :-)
I just wanted to point the fact that ~/.git/ could not be used :)
> > I don't think a global config file is really needed but it would be
> > nice if .git/config would override the environment variables, not the
> > other way around.
>
> Then you have no other way to override .git/config e.g. when committing
> patches submitted by other people.
git commit --author "name <email>"
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-26 17:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: wildfire, git
In-Reply-To: <20060526200526.d8a2f776.tihirvon@gmail.com>
Dear diary, on Fri, May 26, 2006 at 07:05:26PM CEST, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I don't think a global config file is really needed but it would be
> > > nice if .git/config would override the environment variables, not the
> > > other way around.
> >
> > Then you have no other way to override .git/config e.g. when committing
> > patches submitted by other people.
>
> git commit --author "name <email>"
Except that this just sets the environment variables for you. :-)
Now, you could do some really funny stuff with overriding the
environment variables at git commit's entry point with .git/config
stuff, then possibly setting them again in case --author was passed, but
I seriously think such a confusion is not worth it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-26 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vac95m799.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index a3bcad0..c767d84 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -260,6 +260,27 @@ static void mark_recent_complete_commits
>> }
>> }
>>
>> +static struct ref **get_sha1_heads(struct ref **refs, int nr_heads, char
> **head)
>> +{
>> + int i;
>> + for (i = 0; i < nr_heads; i++) {
>> + struct ref *ref;
>> + unsigned char sha1[20];
>> + char *s = head[i];
>> + int len = strlen(s);
>> +
>> + if (len != 40 || get_sha1_hex(s, sha1))
>> + continue;
>
> So the new convention is fetch-pack can take ref name (as
> before), or a bare 40-byte hexadecimal. I think sane people
> would not use ambiguous refname that says "deadbeef" five times,
> and even if the do so they could disambiguate by explicitly
> saying "refs/heads/" followed by "deadbeef" five times, so it
> should be OK.
Yes.
>> +
>> + ref = xcalloc(1, sizeof(*ref) + len + 1);
>> + memcpy(ref->old_sha1, sha1, 20);
>> + memcpy(ref->name, s, len + 1);
>> + *refs = ref;
>> + refs = &ref->next;
>> + }
>> + return refs;
>> +}
>> +
>
> This function takes the pointer to a location that holds a
> pointer to a "struct ref" -- it is the location to store the
> newly allocated ref structure, i.e. the next pointer of the last
> element in the list. When it returns, the location pointed at
> by the pointer given to you points at the first element you
> allocated, and it returns the next pointer of the last element
> allocated by it. That is the same calling convention as
> connect.c::get_remote_heads(). So when calling this function to
> append to a list you already have, you would give the next
> pointer to the last element of the existing list. But you do
> not seem to do that.
Ack. That does look like a bug. I knew there as something
fishy about that code. But it worked for my basic testing so I didn't
worry about it.
> I think the body of fetch_pack() should become something like:
>
> struct ref *ref, **tail;
>
> tail = get_remote_heads(fd[0], &ref, 0, NULL, 0);
> if (server_supports("multi_ack")) {
> ...
> }
> tail = get_sha1_heads(tail, nr_match, match);
> if (everything_local(&ref, nr_match, match)) {
> ...
Actually because we want the filter to resolve sha1s by
default in terms of what was passed on the command line. I'm pretty
certain that should be:
tail = get_sha1_heads(&ref, nr_match, match);
tail = get_remote_heads(fd[0], tail, 0, NULL, 0);
...
>> @@ -311,6 +332,8 @@ static int everything_local(struct ref *
>> if (cutoff)
>> mark_recent_complete_commits(cutoff);
>>
>> + filter_refs(refs, nr_match, match);
>> +
>
> I am not sure about this change.
Agreed. It was a hold over from an earlier way of injecting
the sha1 into the logic.
As for what happens I think I need to audit everything that
takes a ref from fetch_pack. To make certain I have not
messed up the logic.
> In the original code we do not let get_remote_heads() to filter
> the refs but call filter_refs() after the "mark all complete
> remote refs as common" step for a reason. Even though we may
> not be fetching from some remote refs, we would want to take
> advantage of the knowledge of what objects they have so that we
> can mark as many objects as common as possible in the early
> stage. I suspect this change defeats that optimization.
It feels like it.
> So instead I would teach "mark all complete remote refs" loop
> that not everything in refs list is a valid remote ref, and skip
> what get_sha1_heads() injected, because these arbitrary ones we
> got from the command line are not something we know exist on the
> remote side. Maybe something like this.
Sounds sane. We also introduce a new possibility of having a
ref that is complete but not remote.
> /*
> * Mark all complete remote refs as common refs.
> * Don't mark them common yet; the server has to be told so first.
> */
> for (ref = *refs; ref; ref = ref->next) {
> struct object *o;
> if (ref is SHA1 from the command line)
> continue;
> o = deref_tag(lookup_object(ref->old_sha1), NULL, 0);
> if (!o || o->type != commit_type || !(o->flags & COMPLETE))
> continue;
> ...
>
> To implement "ref is SHA1 from the command line", I would add
> another 1-bit field to "struct ref" and mark the new ones you
> create in get_sha1_heads() as such (existing "force" field
> could also become an 1-bit field -- we do not neeed a char).
Sounds sane.
So that gives me:
unsigned int force : 1;
unsigned int injected : 1;
Which aligns them to an int boundary but since we are followed
immediately by a pointer should result in no additional storage being
consumed.
>> @@ -373,6 +394,7 @@ static int fetch_pack(int fd[2], int nr_
>> packet_flush(fd[1]);
>> die("no matching remote head");
>> }
>> + get_sha1_heads(&ref, nr_match, match);
>
> I talked about this one already...
>
>> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
>> index 187f088..2372df8 100755
>> --- a/git-parse-remote.sh
>> +++ b/git-parse-remote.sh
>> @@ -105,6 +105,7 @@ canon_refs_list_for_fetch () {
>> '') remote=HEAD ;;
>> refs/heads/* | refs/tags/* | refs/remotes/*) ;;
>> heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
>> +
> [0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F])
> ;;
>
> Yuck. Don't we have $_x40 somewhere?
I couldn't find one in shell.
> We never use uppercase so at least we could save 24 columns from
> here ;-).
I'm not certain why we always add make $remote="refs/heads/$remote" by
default in that switch statement. git-fetch-pack at least doesn't need
it.
If that is true of the other consumers we could easily make the test:
[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]*) ;;
Or even simply make the default case *) ;;
But for the moment I will stick to the long form because it is
obviously correct.
Eric
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-26 17:38 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <20060526152837.GQ23852@progsoc.uts.edu.au>
Anand Kumria <wildfire@progsoc.uts.edu.au> writes:
> It would be good if things were like:
> - try to construct one automagically
> - use ~/.git/config (if available)
> - use .git/config
> - use environment variables
>
> That way I could set my default email address in ~/.git/config and
> override it as required for those repositories that need it.
If you mean by the above "do all of these and take the last
value that was available", that sounds sane. Except perhaps I
would suggest to use ~/.git-config instead. Some people seem to
want to track their home directory with git, and that way, your
personal fallback default file can be version controlled.
^ permalink raw reply
* Re: git-apply can't apply patches to CRLF-files
From: Junio C Hamano @ 2006-05-26 18:05 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <4477262A.5000301@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> git-apply can't apply the patch to file with windows-style CRLF line endings,
> even if the patch was generated by git-format-patch.
I do not think that is the case.
> Is this a bug or known deficiency?
This particular reproduction recipe looks like a PEBCAK; it does
not reproduce for me, but I do not have/use unix2dos so I did
DOSsy line endings a bit differently.
git init-db
echo 'abc@' | tr '[@]' '[\015]' >a
git add a
git commit -m initial
echo 'def@' | tr '[@]' '[\015]' >>a
git commit -a -m second
git format-patch HEAD^
git reset --hard HEAD^
git am 0*.txt
> The following script reproduces the problem
> ---------
> #!/bin/sh
> set -e
> mkdir trash
> cd trash
> git init-db
> echo "abc" > a
> unix2dos a
> git add a
> git commit -m "a added" a
> echo "cde" >> a
> unix2dos a
Here the first line of a ends with \r\n already end the second
line ends with a \n. Does running unix2dos on that do a
sensible thing on the first line? Compare it with my above
recipe which appends DOSsy line at the end of the file.
Having said that, CRLF is unsafe for E-mail transfers anyway, so
I think we would need a special option to tell git-apply that it
should match '\n' that appears in the patch with '\r\n' in the
file being patched. But I do not think that has anything to do
with the breakage you saw in your reproduction recipe.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Ryan Anderson @ 2006-05-27 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vpsi1qyi2.fsf@assigned-by-dhcp.cox.net>
On Thu, May 25, 2006 at 08:02:45PM -0700, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I think we had hoped that one of the two tools would prove to be
> > _the_ annotation/blame tool and would get used but thus far that
> > hasn't happened.
>
> I've been taking this as an indication that annotate/blame does
> not actually matter in the real world.
It probably doesn't matter in the real world.
At the moment, I'd blame annotate for being wrong, I know it does the
wrong thing on some merges, and I had a plan to try to fix it, but I got
distracted by finding a new job and moving across the country, so I
haven't really had a chance to fix it, something to look at shortly, I
hope. (I'm having problems getting one of my machines back up, so
that's going to slow me down slightly)
> Or git is not yet used in the real world. Or perhaps a bit of
> both.
It's just that "annotate" isn't a common operation in the communities
that Git has made it into.
^ permalink raw reply
* [PATCH/RFC] upload-pack: stop "ack continue" when we know common commits for wanted refs
From: Junio C Hamano @ 2006-05-27 2:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: git, Linus Torvalds
In-Reply-To: <20060526154239.GA20839@linux-mips.org>
When the downloader's repository has more roots than the server
side has, the "have" exchange to figure out recent common
commits ends up traversing the whole history of branches that
only exist on the downloader's side. When the downloader is
asking for newer commits on the branch that exists on both ends,
this is totally unnecessary.
This adds logic to the server side to see if the wanted refs can
reach the "have" commits received so far, and stop issuing "ack
continue" once all of them can be reached from "have" commits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Ralf Baechle <ralf@linux-mips.org> writes:
>> [PATCH] fetch-pack: give up after getting too many "ack continue"
>
> So I did test your patch. In the big, slow repository it cuts down the
> time for a
>
> git fetch git://www./.../linux-2.6.16.y.git master:v2.6.16-stable
>
> from like 6min to about 7s.
>
> Thanks!
This patch is still rough, but it passes my test of asking for
"master" from git.git repository into a repository that is a
merge between linux-2.6.git and a slightly older git.git.
Without this change, and without the client-side hack Ralf
tested, it ends up walking down the entire kernel history.
The code to walk back from wanted ref is unnecessarily ugly and
inefficient -- if we only support a handful want's (say 25) at a
time, we could make the traversal go as we receive "have" by
using something similar to what show-branches does. I am
reworking on that part.
upload-pack.c | 182 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 167 insertions(+), 15 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..e57733b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -11,12 +11,18 @@ static const char upload_pack_usage[] =
#define THEY_HAVE (1U << 0)
#define OUR_REF (1U << 1)
#define WANTED (1U << 2)
+#define COMMON_KNOWN (1U << 3)
+
+#define TRACE_SEEN (1U << 4)
+#define TRACE_BASE 5
+#define MAX_TRACE 20 /* should not exceed bits_per_int - TRACE_BASE */
+
#define MAX_HAS 256
#define MAX_NEEDS 256
static int nr_has = 0, nr_needs = 0, multi_ack = 0, nr_our_refs = 0;
static int use_thin_pack = 0;
-static unsigned char has_sha1[MAX_HAS][20];
-static unsigned char needs_sha1[MAX_NEEDS][20];
+static struct object *has_sha1[MAX_HAS];
+static struct object *needs_sha1[MAX_NEEDS];
static unsigned int timeout = 0;
static void reset_timeout(void)
@@ -69,19 +75,22 @@ static void create_pack_file(void)
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
else {
+ struct object **o = needs_sha1;
for (i = 0; i < nr_needs; i++) {
*p++ = buf;
- memcpy(buf, sha1_to_hex(needs_sha1[i]), 41);
+ memcpy(buf, sha1_to_hex((*o++)->sha1), 41);
buf += 41;
}
}
- if (!create_full_pack)
+ if (!create_full_pack) {
+ struct object **o = has_sha1;
for (i = 0; i < nr_has; i++) {
*p++ = buf;
*buf++ = '^';
- memcpy(buf, sha1_to_hex(has_sha1[i]), 41);
+ memcpy(buf, sha1_to_hex((*o++)->sha1), 41);
buf += 41;
}
+ }
*p++ = NULL;
execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
@@ -93,6 +102,125 @@ static void create_pack_file(void)
die("git-upload-pack: unable to exec git-pack-objects");
}
+static int trace_want(struct object **trace, int cnt)
+{
+ /* start from these cnt objects, traverse the reachability
+ * chain, without parsing new objects, to see if we can
+ * reach objects they have.
+ */
+ int i, j;
+ unsigned trace_flags = 0;
+ struct object_list *list = NULL;
+
+ for (i = 0; i < cnt; i++)
+ trace_flags |= (1U << (TRACE_BASE + i));
+
+ for (i = 0; i < obj_allocs; i++)
+ if (objs[i])
+ objs[i]->flags &= ~trace_flags;
+
+ for (i = 0; i < cnt; i++) {
+ trace[i]->flags |= 1U << (TRACE_BASE + i);
+ object_list_insert(trace[i], &list);
+ }
+
+ while (list) {
+ struct object_list *next = list->next;
+ struct object *o = list->item;
+ unsigned flags = o->flags & trace_flags;
+
+ free(list);
+ list = next;
+ if (o->flags & TRACE_SEEN)
+ continue;
+ o->flags |= TRACE_SEEN;
+ if (!strcmp(o->type, tag_type)) {
+ o = deref_tag(o, NULL, 0);
+ if (o && (o->flags & trace_flags) != flags) {
+ o->flags |= flags;
+ object_list_insert(o, &list);
+ }
+ continue;
+ }
+ if (!strcmp(o->type, commit_type)) {
+ struct commit *c = (struct commit *)o;
+ struct commit_list *l = c->parents;
+ while (l) {
+ struct commit *p = l->item;
+ l = l->next;
+ if ((p->object.flags & trace_flags) != flags) {
+ p->object.flags |= flags;
+ object_list_insert(&p->object, &list);
+ }
+ }
+ }
+ }
+
+ /* Now scan the objects they have, and see if the wanted one
+ * reach which ones.
+ */
+ for (j = 0; j < nr_needs; j++) {
+ for (i = 0;
+ (i < nr_has &&
+ !(needs_sha1[j]->flags & COMMON_KNOWN));
+ i++) {
+ if (has_sha1[i]->flags & (1U << (TRACE_BASE + j)))
+ needs_sha1[j]->flags |= COMMON_KNOWN;
+ }
+ }
+
+ for (j = 0; j < nr_needs; j++) {
+ if (!(needs_sha1[j]->flags & COMMON_KNOWN))
+ return 1;
+ }
+ return 0;
+}
+
+static void check_want_heads(void)
+{
+ /* Do not keep saying "ack continue" if we already know
+ * common ancestor for all the "want"ed heads. This is
+ * particularly important if some of the "have" heads does
+ * not share any root commit with us. Otherwise we would
+ * keep asking for that branch, hoping we might get a better
+ * common ancestor than we already have.
+ */
+ int i, still_missing;
+ struct object *trace[MAX_TRACE];
+ int trace_bit;
+
+ if (!multi_ack)
+ return;
+
+ still_missing = 0;
+ trace_bit = 0;
+ for (i = 0; still_missing && i < nr_needs; i++) {
+ struct object *o = needs_sha1[i];
+ if (o->flags & COMMON_KNOWN)
+ continue;
+ if (strcmp(o->type, tag_type) &&
+ strcmp(o->type, commit_type))
+ /* Asking for non traceable types - there
+ * is not much we can do to optimize it here.
+ * We will let rev-list deal with it.
+ */
+ continue;
+ if (trace_bit < MAX_TRACE) {
+ trace[trace_bit] = o;
+ trace_bit++;
+ }
+ else {
+ still_missing = trace_want(trace, trace_bit);
+ trace_bit = 0;
+ }
+ }
+ if (trace_bit && !still_missing)
+ still_missing = trace_want(trace, trace_bit);
+
+ if (!still_missing)
+ multi_ack = 0;
+}
+
static int got_sha1(char *hex, unsigned char *sha1)
{
if (get_sha1_hex(hex, sha1))
@@ -107,15 +235,39 @@ static int got_sha1(char *hex, unsigned
die("oops (%s)", sha1_to_hex(sha1));
if (o->type == commit_type) {
struct commit_list *parents;
+ int we_knew_they_have = 0;
+
+ /* Because we deliberately stay behind by one
+ * window in order to make the protocol
+ * stream, many commits can already be in
+ * flight when we notice that the latest one
+ * in the series is already what we have. Do
+ * not waste the has_sha1[] slot for extra commits
+ * sent that way.
+ *
+ * This relies on fetch-pack sending the "have"
+ * lines without skipping.
+ */
if (o->flags & THEY_HAVE)
- return 0;
- o->flags |= THEY_HAVE;
+ we_knew_they_have = 1;
+ else
+ o->flags |= THEY_HAVE;
for (parents = ((struct commit*)o)->parents;
parents;
parents = parents->next)
parents->item->object.flags |= THEY_HAVE;
+ if (we_knew_they_have)
+ return 0;
}
- memcpy(has_sha1[nr_has++], sha1, 20);
+ has_sha1[nr_has++] = o;
+
+ /* Check to see if we know a common ancestor for
+ * all the "want" heads, and if so turn multi_ack
+ * off. There is nothing more gained by further
+ * exchange.
+ */
+ check_want_heads();
+
}
return 1;
}
@@ -141,7 +293,7 @@ static int get_common_commits(void)
len = strip(line, len);
if (!strncmp(line, "have ", 5)) {
if (got_sha1(line+5, sha1) &&
- (multi_ack || nr_has == 1)) {
+ (multi_ack || nr_has == 1)) {
if (nr_has >= MAX_HAS)
multi_ack = 0;
packet_write(1, "ACK %s%s\n",
@@ -156,7 +308,7 @@ static int get_common_commits(void)
if (nr_has > 0) {
if (multi_ack)
packet_write(1, "ACK %s\n",
- sha1_to_hex(last_sha1));
+ sha1_to_hex(last_sha1));
return 0;
}
packet_write(1, "NAK\n");
@@ -174,23 +326,21 @@ static int receive_needs(void)
needs = 0;
for (;;) {
struct object *o;
- unsigned char dummy[20], *sha1_buf;
+ unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
if (!len)
return needs;
- sha1_buf = dummy;
if (needs == MAX_NEEDS) {
fprintf(stderr,
"warning: supporting only a max of %d requests. "
"sending everything instead.\n",
MAX_NEEDS);
}
- else if (needs < MAX_NEEDS)
- sha1_buf = needs_sha1[needs];
- if (strncmp("want ", line, 5) || get_sha1_hex(line+5, sha1_buf))
+ if (strncmp("want ", line, 5) ||
+ get_sha1_hex(line+5, sha1_buf))
die("git-upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
if (strstr(line+45, "multi_ack"))
@@ -211,6 +361,8 @@ static int receive_needs(void)
die("git-upload-pack: not our ref %s", line+5);
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
+ if (needs < MAX_NEEDS)
+ needs_sha1[needs] = o;
needs++;
}
}
--
1.3.3.g2a0a
^ permalink raw reply related
* [SCRIPT] chomp: trim trailing whitespace
From: Jeff Garzik @ 2006-05-27 2:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
Attached to this email is chomp.pl, a Perl script which removes trailing
whitespace from several files. I've had this for years, as trailing
whitespace is one of my pet peeves.
Now that git-applymbox complains loudly whenever a patch adds trailing
whitespace, I figured this script may be useful to others.
Jeff
[-- Attachment #2: chomp.pl --]
[-- Type: application/x-perl, Size: 1043 bytes --]
^ permalink raw reply
* [PATCH] Actually support embedded Qt, make configuration code more robust
From: Pavel Roskin @ 2006-05-27 2:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Add -DQWS and -fno-rtti flags for embedded Qt.
Don't add X11 flags for embedded Qt and threading specific flags for
non-multithreaded Qt.
Before checking for the Qt library, make sure it actually exists in the
Qt library path and not elsewhere.
Fix missing ";;" before "esac" (potentially non-portable).
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
config/gwqt.m4 | 40 ++++++++++++++++++++++++++--------------
1 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/config/gwqt.m4 b/config/gwqt.m4
index 78bed1d..cccccfe 100644
--- a/config/gwqt.m4
+++ b/config/gwqt.m4
@@ -91,17 +91,19 @@ fi
# Checking for possible dependencies of the Qt library
gwqt_save_LDFLAGS="$LDFLAGS"
-QT_LIBS="$X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
-AC_CHECK_LIB(pthread, pthread_exit, [QT_LIBS="-lpthread $QT_LIBS"])
+QT_LIBS_X="$X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
+AC_CHECK_LIB(pthread, pthread_exit, [QT_LIBS_MT="-lpthread $QT_LIBS"])
LDFLAGS="$LDFLAGS $X_LIBS"
-AC_CHECK_LIB(Xft, XftFontOpen, [QT_LIBS="-lXft $QT_LIBS"], , [$QT_LIBS])
+AC_CHECK_LIB(Xft, XftFontOpen, [QT_LIBS_X="-lXft $QT_LIBS_X"], , [$QT_LIBS_X])
# Checking for the Qt library
LDFLAGS="$LDFLAGS -L$QTLIBDIR"
for i in qt-mt qt qte-mt qte qt-gl; do
- AC_CHECK_LIB([$i], Get_Class, [qtlib="$i"; break], , [$QT_LIBS])
+ set X "$QTLIBDIR/lib$i."*
+ test "$[2]" = "$QTLIBDIR/lib$i.*" && continue
+ AC_CHECK_LIB([$i], main, [qtlib="$i"; break], , [$QT_LIBS_X $QT_LIBS_MT])
done
if test -z "$qtlib"; then
@@ -110,30 +112,40 @@ fi
LDFLAGS="$gwqt_save_LDFLAGS"
-# Calculate QT_CPPFLAGS
+# Calculate QT_CPPFLAGS, QT_LDFLAGS and QT_LIBS
+QT_LIBS="-l$qtlib"
case "$qtlib" in
- *-mt) QT_CPPFLAGS="-D_REENTRANT -DQT_THREAD_SUPPORT";;
+ *-mt)
+ QT_CPPFLAGS="-D_REENTRANT -DQT_THREAD_SUPPORT"
+ QT_LIBS="$QT_LIBS $QT_LIBS_MT";;
esac
+case "$qtlib" in
+ qte*)
+ QT_CPPFLAGS="-DQWS -fno-rtti";;
+ *)
+ QT_LIBS="$QT_LIBS $QT_LIBS_X"
+ QT_LDFLAGS="$X_LIBS";;
+esac
+
+# Add Qt include path
if test "$QTINCDIR" != "/usr/include"; then
QT_CPPFLAGS="-I$QTINCDIR $QT_CPPFLAGS"
fi
-AC_MSG_NOTICE([QT_CPPFLAGS = $QT_CPPFLAGS])
-AC_SUBST(QT_CPPFLAGS)
-# Calculate QT_LDFLAGS
-QT_LDFLAGS="$X_LIBS"
+# Add Qt library path
case "$QTLIBDIR" in
/usr/lib) ;;
/usr/lib64) ;;
/usr/X11R6/lib) ;;
- *) QT_LDFLAGS="$QT_LDFLAGS -L$QTLIBDIR";
+ *) QT_LDFLAGS="$QT_LDFLAGS -L$QTLIBDIR";;
esac
+
+# Report the results
+AC_MSG_NOTICE([QT_CPPFLAGS = $QT_CPPFLAGS])
+AC_SUBST(QT_CPPFLAGS)
AC_MSG_NOTICE([QT_LDFLAGS = $QT_LDFLAGS])
AC_SUBST(QT_LDFLAGS)
-
-# Calculate QT_LIBS
-QT_LIBS="-l$qtlib $QT_LIBS"
AC_MSG_NOTICE([QT_LIBS = $QT_LIBS])
AC_SUBST(QT_LIBS)
])
^ permalink raw reply related
* Re: ~/.git/config ?
From: Pavel Roskin @ 2006-05-27 2:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Timo Hirvonen, Anand Kumria, git
In-Reply-To: <20060526163829.GB10488@pasky.or.cz>
On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> where Timo Hirvonen <tihirvon@gmail.com> said that...
> > I backup my $HOME using git, so there's a .git directory in ~.
>
> Then it should be called ~/.gitconfig. :-)
No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
I know, it's becoming a bikeshed issue :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-27 2:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Timo Hirvonen, Anand Kumria, git
In-Reply-To: <1148697382.5599.1.camel@dv>
Dear diary, on Sat, May 27, 2006 at 04:36:22AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> > where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I backup my $HOME using git, so there's a .git directory in ~.
> >
> > Then it should be called ~/.gitconfig. :-)
>
> No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
does, that is providing default options for git commands. ~/.gitconfig
would just give you per-user defaults for the repository config file.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ 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