* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Johannes Schindelin @ 2007-09-06 14:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <118907761140-git-send-email-madcoder@debian.org>
Hi,
let me thank you for this very nicely done patch series. Except for 5/7,
they look pretty much obvious changes to me. I'll review that in detail
later.
On Thu, 6 Sep 2007, Pierre Habouzit wrote:
> +#define STRBUF_INIT { 0, 0, 0, NULL }
Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
standards-keen as other people, who I have no doubt will gladly answer
this one.)
Ciao,
Dscho
^ permalink raw reply
* git stash usage
From: Nikodemus Siivola @ 2007-09-06 14:20 UTC (permalink / raw)
To: git
I'm not sure if I understand git-stash correctly.
...work...
git stash
...quick fix & commit...
git stash apply
...more work...
is my understanding of the normal workflow. If this is
correct, why does "apply" leave the stash in the list
of stashes?
mkdir git-stash-test
cd git-stash-test
git init
echo foo > save-apply-test.txt
git add save-apply-test.txt
git commit -m "foo"
echo bar > save-apply-test.txt
git stash
echo quux > save-apply-test.txt
git commit -a -m "quux"
git stash apply
git commit -a -m "bar"
# I would expect the list to be empty now, but it isn't.
git stash list
Is this intentional?
It's a bit inconvenient, especially considering that
"clear" removes all the stashes.
I can easily accumulate several stashes, some of which
are applied and some of which are not -- but have no
way to easily know which are which.
Cheers,
-- Nikodemus
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Jeff King @ 2007-09-06 14:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709061506330.28586@racer.site>
On Thu, Sep 06, 2007 at 03:09:28PM +0100, Johannes Schindelin wrote:
> let me thank you for this very nicely done patch series. Except for 5/7,
> they look pretty much obvious changes to me. I'll review that in detail
> later.
I second that; I am glad somebody is taking an interest in this area
(though I haven't closely reviewed the patches yet).
> > +#define STRBUF_INIT { 0, 0, 0, NULL }
>
> Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
> standards-keen as other people, who I have no doubt will gladly answer
> this one.)
Yes, it would, according to the standard.
-Peff
^ permalink raw reply
* Re: [PATCH] git.__remotes_from_dir() should only return lists
From: Karl Hasselström @ 2007-09-06 14:26 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1189082306.3695.5.camel@gx>
On 2007-09-06 08:38:26 -0400, Pavel Roskin wrote:
> On Thu, 2007-09-06 at 13:26 +0200, Karl Hasselström wrote:
>
> > Thanks. But I guess an even nicer fix would be to make this
> > function return a set in the first place.
>
> Fine with me. But it was returning a list or None, so the simplest
> fix was to return a list in all cases.
Oh, your fix is excellent to fix the immediate problem. I was just
trying to say that making this function (an a heap of others) return
sets would be a useful refactoring.
> > Hmm. I don't believe I saw t1001 break without this patch (I run
> > the test suite before I push, but I might have made a mistake of
> > course). Does the user's environment leak into the test sandbox?
>
> I don't think it's the user environment, at least on my side. I'm
> using Fedora 7, which has python-2.5-12.fc7. That's the error from
> the t1001 before my patch:
OK. I'll try to reproduce it when I get home, but it certainly looks
like I only _thought_ I'd run the test suite.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: David Kastrup @ 2007-09-06 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709061506330.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> let me thank you for this very nicely done patch series. Except for 5/7,
> they look pretty much obvious changes to me. I'll review that in detail
> later.
>
> On Thu, 6 Sep 2007, Pierre Habouzit wrote:
>
>> +#define STRBUF_INIT { 0, 0, 0, NULL }
>
> Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
> standards-keen as other people, who I have no doubt will gladly answer
> this one.)
AFAIR, non-specified static memory areas are initialized to zero bits,
and NULL resp (void *)0 is not guaranteed to be represented by zero
bits.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: David Kastrup @ 2007-09-06 14:44 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <20070906142155.GB3002@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 06, 2007 at 03:09:28PM +0100, Johannes Schindelin wrote:
>
>> let me thank you for this very nicely done patch series. Except for 5/7,
>> they look pretty much obvious changes to me. I'll review that in detail
>> later.
>
> I second that; I am glad somebody is taking an interest in this area
> (though I haven't closely reviewed the patches yet).
>
>> > +#define STRBUF_INIT { 0, 0, 0, NULL }
>>
>> Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
>> standards-keen as other people, who I have no doubt will gladly answer
>> this one.)
>
> Yes, it would, according to the standard.
Have a citation for that?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] basic threaded delta search
From: Nicolas Pitre @ 2007-09-06 14:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsv4cm6b.fsf@gitster.siamese.dyndns.org>
On Thu, 6 Sep 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > this is still rough, hence it is disabled by default. You need to compile
> > with "make THREADED_DELTA_SEARCH=1 ..." at the moment.
> >
> > Threading is done on different portions of the object list to be
> > deltified. This is currently done by spliting the list into n parts and
> > then a thread is spawned for each of them. A better method would consist
> > of spliting the list into more smaller parts and have the n threads
> > pick the next part available.
>
> Hmmm. I wonder how the result is affected by such a partition;
> aren't you going to have many objects that could have used
> somebody else as a delta but gets stored as base because they
> happen to be a very early part of their partition (and lacking
> delta base candidates in the window)?
Yes. On a largish repo that shouldn't be significant though, not worse
than repacking multiple packs into one without -f.
> You cannot solve it with
> overlapping partitions without busting the depth limit easily
> either, I suspect.
My plan is to call find_deltas() again over partition boundaries after
adjacent partitions have been processed. If delta_child is properly
maintained in all cases (trivial) then this should just work.
> Also how would this interact with the LRU
> delta base window we discussed a week or two ago?
This is completely orthogonal.
> Separating the list into different object types would not have
> any adverse impact coming from the "horizon" of delta base
> candidates window (because we do not deltify across types), but
> that is not very useful because we cannot gain much parallerism
> from such a partition.
Indeed. Even with a straight split with equal number of objects, some
threads currently complete much faster than others. This is why a more
sophisticated distribution of work is still needed to keep the desired
amount of threads busy all the time.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Jeff King @ 2007-09-06 14:50 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <857in3dfad.fsf@lola.goethe.zz>
On Thu, Sep 06, 2007 at 04:44:42PM +0200, David Kastrup wrote:
> >> Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
> >> standards-keen as other people, who I have no doubt will gladly answer
> >> this one.)
> >
> > Yes, it would, according to the standard.
>
> Have a citation for that?
Of course.
See ISO 9899:1999, section 6.7.8.
Paragraph 10:
If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate. If an object that has static
storage duration is not initialized explicitly, then:
-- if it has pointer type, it is initialized to a null pointer;
-- if it has arithmetic type, it is initialized to (positive or
unsigned) zero;
-- if it is an aggregate, every member is initialized (recursively)
according to these rules;
-- if it is a union, the first named member is initialized (recursively)
according to these rules.
Paragraph 21:
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration.
-Peff
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Jeff King @ 2007-09-06 14:52 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <85bqcfdfc7.fsf@lola.goethe.zz>
On Thu, Sep 06, 2007 at 04:43:36PM +0200, David Kastrup wrote:
> > Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
> > standards-keen as other people, who I have no doubt will gladly answer
> > this one.)
>
> AFAIR, non-specified static memory areas are initialized to zero bits,
> and NULL resp (void *)0 is not guaranteed to be represented by zero
> bits.
You are right that the NULL pointer is not necessarily represented as
zero bits, but static pointers are explicitly initialized to the NULL
pointer (not all-bits-zero).
-Peff
^ permalink raw reply
* Re: [PATCH] Include a git-push example for creating a remote branch
From: Kristian Høgsberg @ 2007-09-06 14:57 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <A3C344D0-B2A0-44DC-BCBD-3B2C1EBD24B1@wincent.com>
On Thu, 2007-09-06 at 12:50 +0200, Wincent Colaiuta wrote:
> El 6/9/2007, a las 6:44, Shawn O. Pearce escribió:
>
> > +git push origin master:refs/heads/experimental::
> > + Create the branch `experimental` in the `origin` repository
> > + by copying the current `master` branch. This form is usually
> > + needed to create a new branch in the remote repository as
> > + there is no `experimental` branch to match.
> > +
>
> A welcome addition; I was puzzled the first time I tried this myself
> too.
Indeed, but a even better approach might be to expand the error message
with a sugestion on how to create a branch.
Kristian
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: David Kastrup @ 2007-09-06 15:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <20070906145035.GA3546@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 06, 2007 at 04:44:42PM +0200, David Kastrup wrote:
>
>> >> Would not "struct strbuf sb = { 0 };" have the same effect? (I am not so
>> >> standards-keen as other people, who I have no doubt will gladly answer
>> >> this one.)
>> >
>> > Yes, it would, according to the standard.
>>
>> Have a citation for that?
>
> Of course.
>
> See ISO 9899:1999, section 6.7.8.
>
> Paragraph 10:
>
> If an object that has automatic storage duration is not initialized
> explicitly, its value is indeterminate. If an object that has static
> storage duration is not initialized explicitly, then:
>
> -- if it has pointer type, it is initialized to a null pointer;
That's actually a new one to me. I don't think that it has been
always the case in ANSI C.
Thanks.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Jeff King @ 2007-09-06 15:36 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <85tzq7bzoz.fsf@lola.goethe.zz>
On Thu, Sep 06, 2007 at 05:06:52PM +0200, David Kastrup wrote:
> > If an object that has automatic storage duration is not initialized
> > explicitly, its value is indeterminate. If an object that has static
> > storage duration is not initialized explicitly, then:
> >
> > -- if it has pointer type, it is initialized to a null pointer;
>
> That's actually a new one to me. I don't think that it has been
> always the case in ANSI C.
I don't have the C89 standard, so it's hard to be authoritative.
However, according to TCOR1 to the C89 standard, the original text of
6.5.7 contained:
If an object that has static storage duration is not initialized
explicitly, it is initialized implicitly as if every member that has
arithmetic type were assigned 0 and every member that has pointer type
were assigned a null pointer constant.
and was changed to:
If an object that has static storage duration is not initialized
explicitly, then:
- if it has pointer type, it is initialized to a null pointer;
- if it has arithmetic type, it is initialized to zero;
- if it is an aggregate, every member is initialized (recursively)
according to these rules;
- if it is a union, the first named member is initialized
(recursively) according to these rules.
But for the case of pointer initializations, both have the same effect.
So I think it has always been the case. Pre-ANSI, who knows. :)
You can find TCOR1 here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/tc1.htm
And now I must go get some real work done instead of snooping through
standards. :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: Johannes Sixt @ 2007-09-06 15:45 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <85tzq7bzoz.fsf@lola.goethe.zz>
David Kastrup schrieb:
> Jeff King <peff@peff.net> writes:
>> See ISO 9899:1999, section 6.7.8.
>>
>> Paragraph 10:
>>
>> If an object that has automatic storage duration is not initialized
>> explicitly, its value is indeterminate. If an object that has static
>> storage duration is not initialized explicitly, then:
>>
>> -- if it has pointer type, it is initialized to a null pointer;
>
> That's actually a new one to me. I don't think that it has been
> always the case in ANSI C.
AFAIR, this has always been the case.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/7] Rework strbuf API and semantics.
From: David Kastrup @ 2007-09-06 15:53 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <20070906153613.GA4008@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 06, 2007 at 05:06:52PM +0200, David Kastrup wrote:
>
>> > If an object that has automatic storage duration is not initialized
>> > explicitly, its value is indeterminate. If an object that has static
>> > storage duration is not initialized explicitly, then:
>> >
>> > -- if it has pointer type, it is initialized to a null pointer;
>>
>> That's actually a new one to me. I don't think that it has been
>> always the case in ANSI C.
>
> I don't have the C89 standard, so it's hard to be authoritative.
> However, according to TCOR1 to the C89 standard, the original text of
> 6.5.7 contained:
>
> If an object that has static storage duration is not initialized
> explicitly, it is initialized implicitly as if every member that has
> arithmetic type were assigned 0 and every member that has pointer type
> were assigned a null pointer constant.
Maybe I am confusing this with the effects of calloc or memset(...,0).
> But for the case of pointer initializations, both have the same
> effect. So I think it has always been the case. Pre-ANSI, who
> knows. :)
In the original K&R C, a null pointer likely could have been assumed
to have zero bits throughout. The non-zero-bits NULL pointer concept
just reeks of standard committees... So maybe this never had been an
issue, for different reasons.
> And now I must go get some real work done instead of snooping
> through standards. :)
Sorry for the diversion.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Johannes Schindelin @ 2007-09-06 15:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Nix, Steven Grimm, Linus Torvalds,
Git Mailing List
In-Reply-To: <7vr6lcj2zi.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 5 Sep 2007, Junio C Hamano wrote:
> @@ -20,6 +20,7 @@ static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
>
> static int pack_refs = 1;
> static int aggressive_window = -1;
> +static int gc_auto_threshold = 6700;
Please don't do that.
When you share objects with another git directory, git-gc --auto can get
rid of the objects when some objects go away in the referenced repository.
So we need _at least_ check gc.auto not being set in the repo when "git
clone --share"ing it (and fail otherwise).
My preferred way would be to set it in "git init" so that existing setups
are not affected, and put some big red message on top of the next release
notes that people might want to set gc.auto in their existing setups.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Include a git-push example for creating a remote branch
From: Carl Worth @ 2007-09-06 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, Shawn O. Pearce, git
In-Reply-To: <7v8x7ke260.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Wed, 05 Sep 2007 23:30:31 -0700, Junio C Hamano wrote:
> It is just nobody felt strong enough reason to sugarcoat the
> normalized syntax with something like:
>
> git push --create remote foo v1.2.0
Couldn't we just use an initial + to indicate this as well?
I would imagine an exchange like this:
$ git push remote foo
git: No branch 'foo' exists in the remote server, to create it use:
git push remote +foo
But regardless of the syntax, it would be nice if the error message
were explicit about how to achieve the goal the user wants. It's just
that forcing the user to say "foo:refs/heads/foo" seems a way to force
the user to get plumbing grime on their clean hands.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Sixt @ 2007-09-06 16:18 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD0C16.70101@eudaptics.com>
Johannes Sixt schrieb:
> Marius Storm-Olsen schrieb:
>> Johannes Schindelin wrote:
>>> To make it easier on others, I just uploaded it into the "teststat"
>>> branch on 4msysgit.git (subject to removal in a few days).
>>
>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.
>> RFC, and please test.
>
> Thanks a lot! I've pushed it out in mingw.git's master.
>
> The reason that t4200-rerere.sh fails is that we now store UTC in
> st_mtime. However, for the garbage-collection we compare this entry to a
> local time stamp.
This analysis is incorrect, I think. The reason we fail seems to be that
t4200 uses test-chmtime, which uses utime(). Likely, we need a wrapper for
that one?
-- Hannes
^ permalink raw reply
* [PATCH 4/3] archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR"
From: René Scharfe @ 2007-09-06 16:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Andreas Ericsson, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <7vzm02klip.fsf@gitster.siamese.dyndns.org>
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/gitattributes.txt | 5 +++-
builtin-archive.c | 52 +++++++++++++++++++++++++++++++++++---
t/t5000-tar-tree.sh | 4 +-
3 files changed, 53 insertions(+), 8 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 47a621b..37b3be8 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -432,7 +432,10 @@ several placeholders when adding this file to an archive. The
expansion depends on the availability of a commit ID, i.e. if
gitlink:git-archive[1] has been given a tree instead of a commit or a
tag then no replacement will be done. The placeholders are the same
-as those for the option `--pretty=format:` of gitlink:git-log[1].
+as those for the option `--pretty=format:` of gitlink:git-log[1],
+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
+in the file. E.g. the string `$Format:%H$` will be replaced by the
+commit hash.
GIT
diff --git a/builtin-archive.c b/builtin-archive.c
index faccce3..a8a0f01 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -81,14 +81,58 @@ static int run_remote_archiver(const char *remote, int argc,
return !!rv;
}
+static void *format_specfile(const struct commit *commit, const char *format,
+ unsigned long *sizep)
+{
+ unsigned long len = *sizep, result_len = 0;
+ const char *a = format;
+ char *result = NULL;
+
+ for (;;) {
+ const char *b, *c;
+ char *fmt, *formatted = NULL;
+ unsigned long a_len, fmt_len, formatted_len, allocated = 0;
+
+ b = memchr(a, '$', len);
+ if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
+ break;
+ c = memchr(b + 8, '$', len - 8);
+ if (!c)
+ break;
+
+ a_len = b - a;
+ fmt_len = c - b - 8;
+ fmt = xmalloc(fmt_len + 1);
+ memcpy(fmt, b + 8, fmt_len);
+ fmt[fmt_len] = '\0';
+
+ formatted_len = format_commit_message(commit, fmt, &formatted,
+ &allocated);
+ result = xrealloc(result, result_len + a_len + formatted_len);
+ memcpy(result + result_len, a, a_len);
+ memcpy(result + result_len + a_len, formatted, formatted_len);
+ result_len += a_len + formatted_len;
+ len -= c + 1 - a;
+ a = c + 1;
+ }
+
+ if (result && len) {
+ result = xrealloc(result, result_len + len);
+ memcpy(result + result_len, a, len);
+ result_len += len;
+ }
+
+ *sizep = result_len;
+
+ return result;
+}
+
static void *convert_to_archive(const char *path,
const void *src, unsigned long *sizep,
const struct commit *commit)
{
static struct git_attr *attr_specfile;
struct git_attr_check check[1];
- char *interpolated = NULL;
- unsigned long allocated = 0;
if (!commit)
return NULL;
@@ -102,9 +146,7 @@ static void *convert_to_archive(const char *path,
if (!ATTR_TRUE(check[0].value))
return NULL;
- *sizep = format_commit_message(commit, src, &interpolated, &allocated);
-
- return interpolated;
+ return format_specfile(commit, src, sizep);
}
void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 3d5d01b..6e89e07 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -36,7 +36,7 @@ test_expect_success \
echo simple textfile >a/a &&
mkdir a/bin &&
cp /bin/sh a/bin &&
- printf "%s" "$SPECFILEFORMAT" >a/specfile &&
+ printf "A\$Format:%s\$O" "$SPECFILEFORMAT" >a/specfile &&
ln -s a a/l1 &&
(p=long_path_to_a_file && cd a &&
for depth in 1 2 3 4 5; do mkdir $p && cd $p; done &&
@@ -119,7 +119,7 @@ test_expect_success \
test_expect_success \
'validate specfile contents' \
- 'git log --max-count=1 "--pretty=format:$SPECFILEFORMAT" HEAD \
+ 'git log --max-count=1 "--pretty=format:A${SPECFILEFORMAT}O" HEAD \
>f/a/specfile.expected &&
diff f/a/specfile.expected f/a/specfile'
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Miklos Vajna @ 2007-09-06 16:26 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85abs1hr6t.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Wed, Sep 05, 2007 at 09:01:46PM +0200, David Kastrup <dak@gnu.org> wrote:
> > the situation what triggers the 'no such file' problem is:
> >
> > ----
> > $ touch foo/Makefile
> > $ mkdir bar
> > $ ln -s foo/Makefile bar
> > $ cd bar
> > $ cat Makefile
> > cat: Makefile: No such file or directory
> > ----
>
> This is under Vista? It would be the same under Unix.
no, i never stated that this is Vista ;-) this is Linux.
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] Enable wt-status output to a given FILE pointer.
From: Johannes Schindelin @ 2007-09-06 16:27 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11890382183913-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 228 bytes --]
Hi,
On Wed, 5 Sep 2007, Kristian Høgsberg wrote:
> Still defaults to stdout, but you can now override wt_status.fp after
> calling wt_status_prepare().
Would it not be easier to freopen(filename, "a", stdout)?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/9] Introduce entry point for launching add--interactive.
From: Johannes Schindelin @ 2007-09-06 16:31 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11890382253220-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1310 bytes --]
Hi,
On Wed, 5 Sep 2007, Kristian Høgsberg wrote:
> diff --git a/builtin-add.c b/builtin-add.c
> index 3dd4ded..e79e8f7 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -153,6 +154,13 @@ static int git_add_config(const char *var, const char *value)
> return git_default_config(var, value);
> }
>
> +int interactive_add(void)
> +{
> + const char *argv[2] = { "add--interactive", NULL };
> +
> + return run_command_v_opt(argv, RUN_GIT_CMD);
> +}
I'd rather have this in builtin-commit.c, since it is quite funny if
builtin-add.c has code to fork() and exec() itself (eventually, that
is) ;-)
> diff --git a/commit.h b/commit.h
> index 467872e..64e1d4b 100644
> --- a/commit.h
> +++ b/commit.h
> @@ -122,4 +122,13 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
> int depth, int shallow_flag, int not_shallow_flag);
>
> int in_merge_bases(struct commit *, struct commit **, int);
> +
> +extern const unsigned char *
> +create_commit(const unsigned char *tree_sha1,
> + unsigned char parent_sha1[][20], int parents,
> + const char *author_info, const char *committer_info,
> + const char *message, int length);
> +
> +extern int interactive_add(void);
> +
Just a guess: you did not want create_commit() to creep in here, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: David Kastrup @ 2007-09-06 16:33 UTC (permalink / raw)
To: git
In-Reply-To: <20070906162657.GF2329@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Wed, Sep 05, 2007 at 09:01:46PM +0200, David Kastrup <dak@gnu.org> wrote:
>> > the situation what triggers the 'no such file' problem is:
>> >
>> > ----
>> > $ touch foo/Makefile
>> > $ mkdir bar
>> > $ ln -s foo/Makefile bar
>> > $ cd bar
>> > $ cat Makefile
>> > cat: Makefile: No such file or directory
>> > ----
>>
>> This is under Vista? It would be the same under Unix.
>
> no, i never stated that this is Vista ;-) this is Linux.
Ok, so now we have established that we have not actually established
anything with regard to relative links under Vista short of what
Microsoft claims in its developer information (which has its fair
share of misleading and wrong information).
If anybody is as fortunate as to actually have Vista available, it
would be nice if he corroborated that relative links under Vista are
indeed (as Microsoft appears to claim) relative with regard to the
current work directory rather than the directory containing the link.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Marius Storm-Olsen @ 2007-09-06 16:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Johannes Sixt, Git Mailing List
In-Reply-To: <46E0285E.1000603@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
Johannes Sixt wrote:
> Johannes Sixt schrieb:
>> Marius Storm-Olsen schrieb:
>>> Johannes Schindelin wrote:
>>>> To make it easier on others, I just uploaded it into the
>>>> "teststat" branch on 4msysgit.git (subject to removal in a few
>>>> days).
>>>
>>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat'
>>> branch. RFC, and please test.
>>
>> Thanks a lot! I've pushed it out in mingw.git's master.
>>
>> The reason that t4200-rerere.sh fails is that we now store UTC in
>> st_mtime. However, for the garbage-collection we compare this entry
>> to a local time stamp.
>
> This analysis is incorrect, I think. The reason we fail seems to be
> that t4200 uses test-chmtime, which uses utime(). Likely, we need a
> wrapper for that one?
Ok, could you make a quick patch to add a git_utime() (and probably
git_time()) and see if the tests pass without the UTC to Local time patch?
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 6/9] Rewrite launch_editor, create_tag and stripspace to use strbufs.
From: Johannes Schindelin @ 2007-09-06 16:38 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1189038225525-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1594 bytes --]
Hi,
On Wed, 5 Sep 2007, Kristian Høgsberg wrote:
> diff --git a/strbuf.c b/strbuf.c
> index fcfc05e..ed2afea 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -73,43 +74,15 @@ void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> {
> char buffer[2048];
> va_list args;
> - int len, size = 2 * sizeof buffer;
> + int len;
>
> va_start(args, fmt);
> len = vsnprintf(buffer, sizeof(buffer), fmt, args);
> va_end(args);
>
> - if (len > sizeof(buffer)) {
> - /*
> - * Didn't fit in the buffer, but this vsnprintf at
> - * least gives us the required length back. Grow the
> - * buffer acccordingly and try again.
> - */
> - strbuf_grow(sb, len);
> - va_start(args, fmt);
> - len = vsnprintf(sb->buf + sb->len,
> - sb->alloc - sb->len, fmt, args);
> - va_end(args);
> - } else if (len >= 0) {
> - /*
> - * The initial vsnprintf fit in the temp buffer, just
> - * copy it to the strbuf.
> - */
> - strbuf_add(sb, buffer, len);
> - } else {
> - /*
> - * This vnsprintf sucks and just returns -1 when the
> - * buffer is too small. Keep doubling the size until
> - * it fits.
> - */
> - while (len < 0) {
> - strbuf_grow(sb, size);
> - va_start(args, fmt);
> - len = vsnprintf(sb->buf + sb->len,
> - sb->alloc - sb->len, fmt, args);
> - va_end(args);
> - size *= 2;
> - }
> - }
> + if (len > sizeof(buffer) || len < 0)
> + die("out of buffer space\n");
> +
> + strbuf_add(sb, buffer, len);
> }
Really?
(If you find the time, it would be really nice to rebase that patch series
on top of Pierre's strbuf work...)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-svn: remove --first-parent, add --upstream
From: Lars Hjemli @ 2007-09-06 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20070906075104.GA10192@hand.yhbt.net>
This makes git-svn always issue the --first-parent option to git-log when
trying to establish the "base" subversion branch, so the --first-parent
option to git-svn is no longer needed. Instead a new option, --upstream
<revspec>, is introduced. When this is specified the search for embedded
git-svn-id lines in commit messages starts at the specified revision, if
not specified the search starts at HEAD.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-svn.txt | 10 +++++-----
git-svn.perl | 18 +++++++++---------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 42d7b82..2903777 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -317,15 +317,15 @@ This is only used with the 'dcommit' command.
Print out the series of git arguments that would show
which diffs would be committed to SVN.
---first-parent::
+--upstream=<revspec>::
This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and
'show-ignore' commands.
-These commands tries to detect the upstream subversion branch by means of
-the embedded 'git-svn-id' line in commit messages. When --first-parent is
-specified, git-svn only follows the first parent of each commit, effectively
-ignoring commits brought into the current branch through merge-operations.
+These commands tries to detect the upstream subversion branch by traversing
+the first parent of each commit (starting at HEAD), looking for an embedded
+'git-svn-id' line in the commit messages. When --upstream is specified,
+git-svn starts the traversal at the specified commit instead of HEAD.
--
diff --git a/git-svn.perl b/git-svn.perl
index d21eb7f..947a944 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
- $_prefix, $_no_checkout, $_verbose, $_first_parent);
+ $_prefix, $_no_checkout, $_verbose, $_upstream);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -119,14 +119,14 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'no-rebase' => \$_no_rebase,
- 'first-parent' => \$_first_parent,
+ 'upstream=s' => \$_upstream,
%cmt_opts, %fc_opts } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
'show-ignore' => [ \&cmd_show_ignore, "Show svn:ignore listings",
{ 'revision|r=i' => \$_revision,
- 'first-parent' => \$_first_parent
+ 'upstream=s' => \$_upstream
} ],
'multi-fetch' => [ \&cmd_multi_fetch,
"Deprecated alias for $0 fetch --all",
@@ -148,11 +148,11 @@ my %cmd = (
'authors-file|A=s' => \$_authors,
'color' => \$Git::SVN::Log::color,
'pager=s' => \$Git::SVN::Log::pager,
- 'first-parent' => \$_first_parent
+ 'upstream=s' => \$_upstream
} ],
'find-rev' => [ \&cmd_find_rev, "Translate between SVN revision numbers and tree-ish",
{
- 'first-parent' => \$_first_parent
+ 'upstream=s' => \$_upstream
} ],
'rebase' => [ \&cmd_rebase, "Fetch and rebase your working directory",
{ 'merge|m|M' => \$_merge,
@@ -160,7 +160,7 @@ my %cmd = (
'strategy|s=s' => \$_strategy,
'local|l' => \$_local,
'fetch-all|all' => \$_fetch_all,
- 'first-parent' => \$_first_parent,
+ 'upstream=s' => \$_upstream,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
'Commit a diff between two trees',
@@ -818,9 +818,9 @@ sub cmt_metadata {
sub working_head_info {
my ($head, $refs) = @_;
- my @args = ('log', '--no-color');
- push @args, '--first-parent' if $_first_parent;
- my ($fh, $ctx) = command_output_pipe(@args, $head);
+ my @args = ('log', '--no-color', '--first-parent');
+ push @args, ($_upstream ? $_upstream : $head);
+ my ($fh, $ctx) = command_output_pipe(@args);
my $hash;
my %max;
while (<$fh>) {
--
1.5.3.1.g0e33-dirty
^ permalink raw reply related
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