* 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
* 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: 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 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: [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: 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: 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] 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: 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 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] 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: 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 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] 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: 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
* 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: 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
* Re: [PATCH 6/7] Eradicate yet-another-buffer implementation in buitin-rerere.c
From: Johannes Schindelin @ 2007-09-06 14:05 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11890776112641-git-send-email-madcoder@debian.org>
Hi,
On Thu, 6 Sep 2007, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> builtin-rerere.c | 56 +++++++++++++++++------------------------------------
> 1 files changed, 18 insertions(+), 38 deletions(-)
I like that one very much, but ...
> FILE *f = fopen(path, "r");
> FILE *out;
>
> + strbuf_init(&minus);
> + strbuf_init(&plus);
> +
You used spaces instead of tabs here.
Ciao,
Dscho
^ permalink raw reply
* Re: inconsistent use of worktree?
From: martin f krafft @ 2007-09-06 13:41 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070906132906.GA7791@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2007.09.06.1529 +0200]:
> What is git doing? Could it be that it's getting utterly confused
> and inconsistently uses the worktree? I'd be happy to investigate
> this, but want to make sure I am not doing anything wrong!
git-commit -a also does not work:
piper:~/.bin/colgit.git> git commit -m'add list action to enumerate all known repos' -a
error: .bin/colgit: cannot add to the index - missing --add option?
fatal: Unable to process path .bin/colgit
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
redistribution of this email via the
microsoft network is prohibited.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* inconsistent use of worktree?
From: martin f krafft @ 2007-09-06 13:29 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]
Hi there,
I have a $GIT_DIR in ~/.bin/colgit.git, which is bare=false and has
worktree=.. (the parent). This relates back to a suggestion by
Johannes Schindelin [0] for maintaining files like ~/.vimrc and
~/.zshrc in separate repos sharing the same worktree. In short:
while ~/.bin/colgit.git holds all of colgit's objects, refs, and the
index, the repository's files are in ~/.bin (and thus in $PATH).
0. http://marc.info/?l=git&m=118418927823760&w=2
I am trying to figure out a sensible way to work with this, ideally
one which does not require me to set $GIT_DIR (which works):
GIT_DIR=~/.bin/colgit.git git status
GIT_DIR=~/.bin/colgit.git git add ...
GIT_DIR=~/.bin/colgit.git git commit ...
(or one export GIT_DIR)
but that's a lot of typing and thus error-prone.
So in a flash of utter genius, I found this to work:
piper:~/.bin/colgit.git> git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: colgit
#
no changes added to commit (use "git add" and/or "git commit -a")
piper:~/.bin/colgit.git> git add ../colgit
piper:~/.bin/colgit.git> git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: colgit
and I rejoiced, because that's really pretty cool. But then, trying
to commit, reality hit back:
piper:~/.bin/colgit.git> git commit -m'initial commit'
nothing to commit (use "git add file1 file2" to include for commit)
So I had to revert to using GIT_DIR for this:
piper:~/.bin> GIT_DIR=colgit.git git commit -m'initial commit'
Created initial commit 008594d: initial commit
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100755 colgit
And then things got really weird, after I accidentally tried the
direct commit (without GIT_DIR) again, following some touchups
I made to the colgit file:
piper:~/.bin/colgit.git> git commit -m'repairing registration and other touchups'
Created commit acd86b9: Merge branch 'vimplate'
Huh, vimplate? What happened to the commit? Why vimplate?
piper:~/.bin/colgit.git> git log
commit 0ad26b00c31617bf3e31a052e3c3af9ef661407b
Author: martin f. krafft <madduck@madduck.net>
Date: Thu Sep 6 11:45:38 2007 +0200
repairing registration and other touchups
[...]
But the commit appears alright, acd86b9 is the tip of ~/.git,
further up, and the output of git-rev-parse HEAD in ~/.bin, the
parent directory and worktree of ~/.bin/colgit.git.
What is git doing? Could it be that it's getting utterly confused
and inconsistently uses the worktree? I'd be happy to investigate
this, but want to make sure I am not doing anything wrong!
Cheers,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"there are more things in heaven and earth, horatio,
than are dreamt of in your philosophy."
-- hamlet
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [announce] colgit: manage git repository collections
From: martin f krafft @ 2007-09-06 13:15 UTC (permalink / raw)
To: git discussion list; +Cc: home in vcs discussion list
In-Reply-To: <20070906101115.GA29360@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2007.09.06.1211 +0200]:
> With SVN, I'd have a repository for each machine, which existed only
> of svn:externals references pulling in other repos and thus
> assembling my home directory. git-submodule isn't quite designed for
> this sort of stuff, and thus I came up with colgit.
You might want to read over this short discussion between Peter and
I on why git-submodules aren't up for the task:
http://colabti.de/irclogger/irclogger_log/git?date=2007-09-06,Thu&sel=578#l979
Cheers,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"'the answer to the great question...'
'of life, the universe and everything...' said deep thought.
'is...' said deep thought, and paused.
'is...'
'forty-two,' said deep thought, with infinite majesty and calm."
-- hitchhiker's guide to the galaxy
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: strbuf new API, take 2 for inclusion
From: Jeff King @ 2007-09-06 12:58 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11890776114037-git-send-email-madcoder@debian.org>
On Thu, Sep 06, 2007 at 01:20:04PM +0200, Pierre Habouzit wrote:
> I've also stripped as many STRBUF_INIT uses as possible, some people
> didn't liked it. I've kept its use for "static" strbufs where it's way
> more convenient that a function call.
The STRBUF_INIT initializer just sets everything to '0' or NULL. Static
objects already have this done automagically by the compiler, so there's
no need to use STRBUF_INIT at all there.
-Peff
^ permalink raw reply
* Re: Git's database structure
From: Johannes Schindelin @ 2007-09-06 12:56 UTC (permalink / raw)
To: Jon Smirl
Cc: Julian Phillips, Andreas Ericsson, Theodore Tso, Junio C Hamano,
Git Mailing List
In-Reply-To: <9e4733910709050912i57ed7137o6abb02ee741d394b@mail.gmail.com>
Hi,
On Wed, 5 Sep 2007, Jon Smirl wrote:
> On 9/5/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> > On Wed, 5 Sep 2007, Jon Smirl wrote:
> >
> > >> Ah, there we go. A use-case at last :)
> >
> > But not a brilliant one. You sign off on commits not blobs. So you
> > go from the sign-off to paths, then to blobs. There is no need to go
> > from blob to path unless you deliberately introduce such a need.
>
> Use blame for an example. Blame has to crawl every commit to see if it
> touched the file. It keeps doing this until it figures out the last
> author for every line in the file. Worse case blame has to crawl every
> commit in the data store.
But you can add _yet another_ index to it, which can be generated on the
fly, so that Git only has to generate the information once, and then reuse
it later. As a benefit of this method, the underlying well-tested
structure needs no change at all.
BTW could you please, please, please cut the quoted message that you are
_not_ responding to? It really _wastes_ my time.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git.__remotes_from_dir() should only return lists
From: Pavel Roskin @ 2007-09-06 12:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070906112645.GA31888@diana.vm.bytemark.co.uk>
On Thu, 2007-09-06 at 13:26 +0200, Karl Hasselström wrote:
> On 2007-09-05 12:57:22 -0400, Pavel Roskin wrote:
>
> > If there are no remotes, return empty list, not None. The later
> > doesn't work with builtin set().
>
> 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.
> > This fixes t1001-branch-rename.sh
>
> 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:
Traceback (most recent call last):
File "/home/proski/src/stgit/t/../stg", line 43, in <module>
main()
File "/home/proski/src/stgit/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/home/proski/src/stgit/stgit/commands/branch.py", line 163, in func
parentremote = git.identify_remote(parentbranch)
File "/home/proski/src/stgit/stgit/git.py", line 994, in identify_remote
for remote in remotes_list():
File "/home/proski/src/stgit/stgit/git.py", line 963, in remotes_list
| set(__remotes_from_dir('branches')))
TypeError: 'NoneType' object is not iterable
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-06 12:08 UTC (permalink / raw)
To: Miles Bader; +Cc: Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <buoir6oo05v.fsf@dhapc248.dev.necel.com>
Hi,
On Thu, 6 Sep 2007, Miles Bader wrote:
> Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:
> > When I first looked at Git source code two things struck me as odd:
> > 1. Pure C as opposed to C++. No idea why. Please don't talk about
> > portability, it's BS.
>
> Just to piss you off.
Hehe.
FWIW I strongly disagree that it's BS. As others have stated, the reasons
are easily found, and they are no weak arguments.
Ciao,
Dscho
^ 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