* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: David Kastrup @ 2007-11-15 1:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Björn Steinbrink, Alex Riesen, Guido Ostkamp,
git
In-Reply-To: <alpine.LFD.0.9999.0711141640400.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 14 Nov 2007, Junio C Hamano wrote:
>>
>> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
>
> Actually, for old pre-C99 compilers, you're probably better off using
> -DFLEX_ARRAY=1, since a zero-sized array could be considered bogus by
> some.
Is that supposed to work? I would have thought that the only options
would be empty and 0. I am pretty sure I have seen size calculations in
the deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_
-DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could
try seeing whether I find those locations again.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: David Kastrup @ 2007-11-15 1:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sergei Organov, Matthieu Moy, Johannes Schindelin, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <7vfxz8hbcf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But cloning void to start the same project by multiple people
> and pushing their initial commits as roots to start a project
> indicates the lack of developer communication (besides, it just
> feels like a bad style, a hangover from centralized SCM
> mentality, but that is fine).
I do not like the approach of policy by force. It assumes that the
developers know better than the users what the users are going to do
with git.
For example, I use git for tracking and versioning installations and
updaters of complex programs. They are basically built into a directory
tree, and this tree is checked into a bare repository in a branch
corresponding to a particular customer. The trees are _target_ trees
created completely by something akin to make install. So every checkin
is from scratch. The checkins for a particular customer happen in one
branch so that it is easy to generate a diff and from that an updater
(the diff gets converted into a batch file removing old files and a zip
file unpacking new files over the old ones).
There simply is no common reference/starting point for the disparate
branches. I have some "README" in master, but that is an utterly stupid
and unnatural starting point.
One might argue that one should use one repository per customer and just
share the objects (many of which are similar). But that disallows
making diffs between the trees of different customers. Since the
purpose of git here is just to track history and not do any sort of
merging or rebasing, there are no interesting ancestry connections
between branches.
Am I stupid for using git for this sort of thing? I believe not. And
yet git developers choose to call me stupid because my work flow does
not lend any sense to a common ancestor commit.
> But this time, the "feature" is not a zero cost thing. As
> Matthieu said in the thread, we do not let you do so right now.
> Which means that it would involve new development, the code
> changes would risk regressing behaviour existing users rely on,
> and we would need testing for that. These all take resources.
And they will continue to take resources. And since the trend goes more
and more into name-calling on those who still feel that their workflow
justifies disparate branches without common registered ancestry, it will
increasingly drain the most important resources of all: goodwill and
enthusiasm.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Integrating with hooks
From: Jakub Narebski @ 2007-11-15 1:43 UTC (permalink / raw)
To: git
In-Reply-To: <20071115011837.GD32746@penguin.codegnome.org>
Todd A. Jacobs wrote:
> On Wed, Nov 14, 2007 at 12:07:29AM +0100, Jakub Narebski wrote:
>
>> Take a look at gitattributes(5), namely 'filter' attribute.
>
> Thanks, I took a look at the man page you suggested. The "ident" feature
> almost does what I want, but doesn't seem to take any sort of format
> string.
The `ident` feature provides only sensible Id for a file (if you want to
avoid potentially rewriting _all_ and not only changed files on checkout /
switching branch / reset --hard). All Ids which have commit info, like
commit id, commit date, author are not sensible in mentioned sense.
> So, I thought I'd explore "filter," but can't really find any
> examples of how to implement the smudge and clean commands, which seem
> to be what I'm really trying to do here.
>
> Is there an example somewhere that you can point me to? The man page
> doesn't really show any examples of how to implement the filter
> attribute, so I'm a little unsure how to proceed.
Cannot help you there, but see examples of `diff` and `merge` attributes,
it should I think be similar.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Integrating with hooks
From: Johannes Schindelin @ 2007-11-15 1:43 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <20071115011837.GD32746@penguin.codegnome.org>
Hi,
On Wed, 14 Nov 2007, Todd A. Jacobs wrote:
> On Wed, Nov 14, 2007 at 12:07:29AM +0100, Jakub Narebski wrote:
>
> > Take a look at gitattributes(5), namely 'filter' attribute.
>
> Thanks, I took a look at the man page you suggested. The "ident" feature
> almost does what I want, but doesn't seem to take any sort of format
> string.
Note that the ident feature will give you _only_ the blob sha1.
I guess that you're more interested in the export-subst feature.
Hth,
Dscho
^ permalink raw reply
* [BULLS**T PATCH] Allow Git to work at Insane Bank Corp
From: Shawn O. Pearce @ 2007-11-15 1:52 UTC (permalink / raw)
To: git
Oh what a day I've had. Today Insane Bank Corp (my day-job employer)
upgraded their Windows desktop encryption software. *Every*
directory on every computer is now blessed with a "Desktop.ini" file.
Git of course loves this concept:
$ git for-each-ref >/dev/null && echo yes
error: refs/Desktop.ini points nowhere!
error: refs/heads/Desktop.ini points nowhere!
yes
Fortunately for-each-ref allows corrupt refs to exist in the ref
namespace. So until Git is properly patched we are at least able
to ignore these error messages.
For corporate security reasons it is obviously absolutely vital that
these Desktop.ini files exist in every directory of every system.
Even if application software scans all files in a particular
directory and assumes those files belong to it. If these files did
not exist it would not be possible for Insane Bank Corp to protect
its customer's data, which of course must be toted around on $1000
laptops in the posession of any employee who asks for one.
Because Insane Bank Corp is one of the largest banks in the world
all 3rd party software vendors must comply and correct their
applications to not fail when they encounter Desktop.ini in an
application's internal data directory. Or they will lose their
contract with Insane Bank Corp.
This patch must be applied to Git, since Git is a 3rd party software
product and its global assets are much smaller than those of Insane
Bank Corp. If not applied Git won't be permitted for use. Git could
lose all of its software licenses and support contracts. Git shall
do as Insane Bank Corp requests.
Never-Shall-Be-Signed-Off-By: me
---
</rant off>
Seriously, this patch shouldn't ever be made to Git. I'll likely
have to carry it in my own local build process until the end
of time.
Our corporate security goons are unable to fathom why having
"Desktop.ini" shoved into every directory of every filesystem may
cause problems for some applications. Especially those who may
attempt to read every file in a given directory.
Just thought folks would like to see what sort of bulls**t patches
internal developers need to create for systems because they are
unable to rely upon the operating system they are forced to rely
upon for "security reasons". Yes, really, Insane Bank Corp feels
that Microsoft Windows Xtreme Professional is more trustworthy
than RedHat Linux. Especially when toted in someone's backpack.
Just so long as Desktop.ini is in every directory we're safe.
Grrrrrrrrrrrrr.
</rant really is now off>
git-compat-util.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index ca0a597..ca875c7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -172,6 +172,19 @@ extern uintmax_t gitstrtoumax(const char *, char **, int);
extern const char *githstrerror(int herror);
#endif
+#ifdef WORK_FOR_INSANE_BANK_CORP
+static inline struct dirent *gitreaddir(DIR *dirp)
+{
+ struct dirent *r;
+ while ((r = readdir(dirp))) {
+ if (!strcasecmp(r->d_name, "Desktop.ini"))
+ continue;
+ }
+ return r;
+}
+#define readdir gitreaddir
+#endif
+
extern void release_pack_memory(size_t, int);
static inline char* xstrdup(const char *str)
--
1.5.3.5.1728.g34b3e
^ permalink raw reply related
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Linus Torvalds @ 2007-11-15 1:53 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Bj?rn Steinbrink, Alex Riesen, Guido Ostkamp, git
In-Reply-To: <85ir441exj.fsf@lola.goethe.zz>
On Thu, 15 Nov 2007, David Kastrup wrote:
>
> Is that supposed to work? I would have thought that the only options
> would be empty and 0.
I think it should work, even though some things allocations will end up
being a bit too large (ie anything that uses "sizeof()" will have that one
unnecessary entry)
But no, I didn't actually test it.
Linus
^ permalink raw reply
* Re: [BULLS**T PATCH] Allow Git to work at Insane Bank Corp
From: Johannes Schindelin @ 2007-11-15 2:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115015227.GA2116@spearce.org>
Hi,
On Wed, 14 Nov 2007, Shawn O. Pearce wrote:
> For corporate security reasons it is obviously absolutely vital that
> these Desktop.ini files exist in every directory of every system.
This makes sense, absolutely.
> Never-Shall-Be-Signed-Off-By: me
Never-To-Be-Acked-By: me.
But seriously, some things like these should make it possible for one of
the fastest SCMs in the world (both in performance and in development) to
get some serious contracts.
I mean, how does svn cope with something like that?
Ciao,
Dscho
^ permalink raw reply
* Re: [BULLS**T PATCH] Allow Git to work at Insane Bank Corp
From: Shawn O. Pearce @ 2007-11-15 2:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711150211360.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 14 Nov 2007, Shawn O. Pearce wrote:
>
> > For corporate security reasons it is obviously absolutely vital that
> > these Desktop.ini files exist in every directory of every system.
>
> But seriously, some things like these should make it possible for one of
> the fastest SCMs in the world (both in performance and in development) to
> get some serious contracts.
Well, see, you can't actually use Git at Insane Bank Corp because it
wasn't put on the approved list of software. Furthermore if it was
put on that list it would probably only ever be approved for use on
RedHat Linux, as on Windows there is Microsoft Visual Source Suck
and on Solaris there is Rational ConfusingCase. All provide the
same function and therefore are exactly suitable for those platforms.
Any deviants get Desktop.ini files where they don't want them.
Keep in mind that Insane Bank Corp has approved the following OS
and database combinations, as they are all the same thing. Any
mixing/matching is not permitted:
OS Database
------------------------------
Windows Microsoft SQL Server
Solaris Oracle
AIX IBM DB2
Linux MySQL
Because you can do anything that Oracle does with MySQL if Linux
is your OS. Didn't you know that MySQL understands all of Oracle's
extended SQL syntax? Silly developers. :-)
> I mean, how does svn cope with something like that?
SVN probably doesn't care. As in SVN probably only scans the working
directory, which you can tell it to ignore Desktop.ini files in.
When it looks at the SVN/ metadata directory in a checkout it
probably knows exactly what files its going after. Extra files
don't matter to it.
In the fsfs and bdb backends SVN is probably again only going after
known filenames. So it probably isn't impacted by extra crap shoved
into the directory.
I'm waiting for the next release of the desktop security software,
the one that adds an extra 1M binary header to the front of every one
of Java source files, because that's the only way they can protect
the data that never should have been on a portable computing device
in the first place.
I can't wait for Java 6 update 4 Special Edition for Insane Bank
Corp version to be rolled out to ignore those headers. Or for the
Eclipse 3.3.1.1.1 release which will also ignore those headers.
--
Shawn.
^ permalink raw reply
* Re: [BULLS**T PATCH] Allow Git to work at Insane Bank Corp
From: Morten Welinder @ 2007-11-15 2:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115015227.GA2116@spearce.org>
Can't you just load a root kit^w^wsystem extension that hides such
files from any
and all application?
Morten
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Junio C Hamano @ 2007-11-15 3:27 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Björn Steinbrink, Alex Riesen, Guido Ostkamp,
git
In-Reply-To: <85ir441exj.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> ... I am pretty sure I have seen size calculations in
> the deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_
> -DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could
> try seeing whether I find those locations again.
I do recall that I received a patch with an explicit member
elem[1] that is in fact used as a flexible array, foolishly
converted it to use FLEX_ARRAY and saw it mysteriously fail, and
realized what it was doing and reverted my changes, and applied
the patch as received. IIRC it all happened before I pushed the
results out. I unfortunately do not recall which area the patch
was about.
^ permalink raw reply
* Re: [BULLS**T PATCH] Allow Git to work at Insane Bank Corp
From: Junio C Hamano @ 2007-11-15 3:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115015227.GA2116@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Because Insane Bank Corp is one of the largest banks in the world
> all 3rd party software vendors must comply and correct their
> applications to not fail when they encounter Desktop.ini in an
> application's internal data directory. Or they will lose their
> contract with Insane Bank Corp.
>
> This patch must be applied to Git, since Git is a 3rd party software
> product and its global assets are much smaller than those of Insane
> Bank Corp. If not applied Git won't be permitted for use. Git could
> lose all of its software licenses and support contracts. Git shall
> do as Insane Bank Corp requests.
.gitignore? ... ducks ... then comes back.
> +#ifdef WORK_FOR_INSANE_BANK_CORP
> +static inline struct dirent *gitreaddir(DIR *dirp)
> +{
> + struct dirent *r;
> + while ((r = readdir(dirp))) {
> + if (!strcasecmp(r->d_name, "Desktop.ini"))
> + continue;
> + }
> + return r;
> +}
> +#define readdir gitreaddir
> +#endif
Something like this could be used as an emulation layer for
case-corrupting filesystems ;-)
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Jeff King @ 2007-11-15 4:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20071114071929.GA2942@steel.home>
On Wed, Nov 14, 2007 at 08:19:29AM +0100, Alex Riesen wrote:
> Well, it is kind of undefined. git push just updated some remote
> references and failed on the others. It has had some failures, so it
> returns non-0. And as I said, it really is not about the operation,
> but about if the tracking and remote branches are set as we want them.
My goal with the recent patches is that _any_ failure will cause a non-0
exit code (but you have to read the stderr output to find out which, if
any, refs were successful).
-Peff
^ permalink raw reply
* Re: git-clean won't read global ignore
From: Miles Bader @ 2007-11-15 4:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <7vsl39l0b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think the problem is core.excludesfile is too new to be
> noticed by anything other than git-add and git-status.
"git-add -i" _doesn't_ seems to notice it though...
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Jeff King @ 2007-11-15 4:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071113231048.GB19444@sigill.intra.peff.net>
On Tue, Nov 13, 2007 at 06:10:48PM -0500, Jeff King wrote:
> > This one is on top of what is in next. It also include the check for
> > deleting remote braches I sent before. Regarding this one: if a remote
> > branch is deleted, shouldn't the matching tracking branch be removed
> > as well? The code in master seem to do that.
>
> Yes, it should (the code in update_tracking_ref seems to handle that
> case, but I haven't tested, so I may have bungled something). I am
> literally walking out the door, now, though, so I will be out of touch
> for at least a day.
After I became disconnected, I looked at my 'next', and the reason for
the failure to delete the ref seems to be your is_null_sha1
error-checking patch, which Junio put in next. But maybe you have
figured that out in the intervening time. :)
-Peff
^ permalink raw reply
* [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Han-Wen Nienhuys @ 2007-11-15 4:22 UTC (permalink / raw)
To: git
With this patch, cat-file can be invoked either on an arbitrary number
of objects, eg.
git cat-file commit HEAD HEAD^^^
the object names can also be supplied on stdin, like so
echo -e 'HEAD\nHEAD^^^' | git cat-file commit -
With this functionality, the entire object database can be dumped with
a limited number of processes: two cat-file processes for discovering size and
type, and one cat-file process per type.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
builtin-cat-file.c | 63 ++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index f132d58..57e2111 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -76,31 +76,17 @@ static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long
write_or_die(1, cp, endp - cp);
}
-int cmd_cat_file(int argc, const char **argv, const char *prefix)
+
+int cat_one_file (const char *obj_name, int opt, const char *exp_type)
{
unsigned char sha1[20];
- enum object_type type;
void *buf;
unsigned long size;
- int opt;
- const char *exp_type, *obj_name;
-
- git_config(git_default_config);
- if (argc != 3)
- usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
- exp_type = argv[1];
- obj_name = argv[2];
+ enum object_type type;
if (get_sha1(obj_name, sha1))
die("Not a valid object name %s", obj_name);
- opt = 0;
- if ( exp_type[0] == '-' ) {
- opt = exp_type[1];
- if ( !opt || exp_type[2] )
- opt = -1; /* Not a single character option */
- }
-
buf = NULL;
switch (opt) {
case 't':
@@ -157,3 +143,46 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
write_or_die(1, buf, size);
return 0;
}
+
+int cmd_cat_file(int argc, const char **argv, const char *prefix)
+{
+ int opt = 0;
+ const char *exp_type;
+ int all_exists = 1;
+ struct strbuf buf;
+
+ git_config(git_default_config);
+ if (argc < 3)
+ usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1> ... ");
+ exp_type = argv[1];
+
+ if ( exp_type[0] == '-' ) {
+ opt = exp_type[1];
+ if ( !opt || exp_type[2] )
+ opt = -1; /* Not a single character option */
+ }
+
+ argv += 2;
+ strbuf_init(&buf, 0);
+ do {
+ const char *arg = NULL;
+ if (argv[0] == NULL)
+ break;
+ if (strcmp(argv[0], "-")) {
+ arg = *argv;
+ argv++;
+ } else {
+ if (strbuf_getline(&buf, stdin, '\n') == EOF)
+ break;
+ arg = buf.buf;
+ }
+ int not_exists_one = cat_one_file(arg, opt, exp_type);
+ if (opt == 'e')
+ all_exists = all_exists && !not_exists_one;
+ if (not_exists_one)
+ break;
+ } while (1);
+ strbuf_release(&buf);
+ return !all_exists;
+}
+
--
1.5.3.4
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: git-clean won't read global ignore
From: Miles Bader @ 2007-11-15 4:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <buo6404gmu7.fsf@dhapc248.dev.necel.com>
Miles Bader <miles.bader@necel.com> writes:
>> I think the problem is core.excludesfile is too new to be
>> noticed by anything other than git-add and git-status.
>
> "git-add -i" _doesn't_ seems to notice it though...
To clarify: the "add untracked" sub-menu of "git-add -i"
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Johannes Schindelin @ 2007-11-15 4:34 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <fhghqv$98a$1@ger.gmane.org>
Hi,
On Thu, 15 Nov 2007, Han-Wen Nienhuys wrote:
> With this functionality, the entire object database can be dumped with a
> limited number of processes: two cat-file processes for discovering size
> and type, and one cat-file process per type.
IMHO a better idea would be a counterpart to fast-import, probably called
"fast-export". You'd need only one process then, and it would not only be
faster, but would be usable by even more people, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Jeff King @ 2007-11-15 4:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20071115041801.GA9794@sigill.intra.peff.net>
On Wed, Nov 14, 2007 at 11:18:01PM -0500, Jeff King wrote:
> My goal with the recent patches is that _any_ failure will cause a non-0
> exit code (but you have to read the stderr output to find out which, if
> any, refs were successful).
BTW, since there seems to be some debate on how this _should_ work, I
think the "signal failure if anything failed" approach is the better.
Why?
Because either way you do it, there is an ambiguity, and I would rather
that ambiguity lie with the "failure" case. If I see exit code '0', I
_know_ that all of my refs were updated. If I see exit code '1', then
there was some failure detected, but my refs might or might not have
been updated. But that ambiguity _already_ exists. Consider the case
where we send refs, but the connection dies in the middle. We have to
signal error, then, but for all we know the other side was about to
"successfully updated all refs". So you can only ever _know_ success,
and with failure, you simply guess (and presumably retry).
-Peff
^ permalink raw reply
* Re: [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Han-Wen Nienhuys @ 2007-11-15 4:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711150432420.4362@racer.site>
Johannes Schindelin escreveu:
> Hi,
>
> On Thu, 15 Nov 2007, Han-Wen Nienhuys wrote:
>
>> With this functionality, the entire object database can be dumped with a
>> limited number of processes: two cat-file processes for discovering size
>> and type, and one cat-file process per type.
>
> IMHO a better idea would be a counterpart to fast-import, probably called
> "fast-export". You'd need only one process then, and it would not only be
> faster, but would be usable by even more people, I guess.
I know, and that's what I was thinking. However, I was hoping someone else
would pick up the hint :-)
I suppose fast-export would just be cat-file with a different name and
slightly saner interface. How about
type <sha1> <newline>
size <sha1> <newline>
dump <type> <sha1> <newline>
?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH v2 3/3] send-pack: assign remote errors to each ref
From: Jeff King @ 2007-11-15 4:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit, Daniel Barkalow, Alex Riesen
In-Reply-To: <7vbq9xpprg.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 13, 2007 at 05:41:39PM -0800, Junio C Hamano wrote:
> Is it really "arbitrary msg", or just a fixed set of strings?
It is for a fixed version of the remote receive-pack, but I don't want
to start relying on that.
> Also I think we can rely on the order report-status extension
> reports the per-ref result. It gives back the information the
> same order send-pack side supplies the head information, no?
I considered that, but I didn't want to rely on it without your say-so.
We could also just use it as a hint to boost performance. I.e., track
the last match, and start our linear search there, but if we fail, drop
back to searching the whole list. Something like (on top of my other
patch):
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 7d466d9..8e9580a 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -146,7 +146,8 @@ static void get_local_heads(void)
for_each_ref(one_local_ref, NULL);
}
-static void set_ref_error(struct ref *refs, const char *line) {
+static struct ref *set_ref_error(struct ref *refs, const char *line)
+{
struct ref *ref;
for (ref = refs; ref; ref = ref->next) {
@@ -159,8 +160,9 @@ static void set_ref_error(struct ref *refs, const char *line) {
ref->status = REF_STATUS_REMOTE_REJECT;
ref->error = xstrdup(msg);
ref->error[strlen(ref->error)-1] = '\0';
- return;
+ return ref;
}
+ return NULL;
}
/* a return value of -1 indicates that an error occurred,
@@ -168,6 +170,7 @@ static void set_ref_error(struct ref *refs, const char *line) {
* value of -2 means we couldn't even get that far. */
static int receive_status(int in, struct ref *refs)
{
+ struct ref *hint;
char line[1000];
int ret = 0;
int len = packet_read_line(in, line, sizeof(line));
@@ -179,6 +182,7 @@ static int receive_status(int in, struct ref *refs)
fputs(line, stderr);
ret = -1;
}
+ hint = NULL;
while (1) {
len = packet_read_line(in, line, sizeof(line));
if (!len)
@@ -191,7 +195,10 @@ static int receive_status(int in, struct ref *refs)
}
if (!memcmp(line, "ok", 2))
continue;
- set_ref_error(refs, line + 3);
+ if (hint)
+ hint = set_ref_error(hint, line + 3);
+ if (!hint)
+ hint = set_ref_error(refs, line + 3);
ret = -1;
}
return ret;
^ permalink raw reply related
* Re: [PATCH v2 3/3] send-pack: assign remote errors to each ref
From: Jeff King @ 2007-11-15 4:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, git, Pierre Habouzit, Daniel Barkalow,
Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0711140159550.4362@racer.site>
On Wed, Nov 14, 2007 at 02:01:14AM +0000, Johannes Schindelin wrote:
> Since when can refnames contain spaces? In my copy of git, bad_ref_char()
> in refs.c returns 1 if ch <= ' '. It's the first error path, even.
Oops, I'm clearly an idiot. I explicitly looked at bad_ref_char before
writing the original message, and somehow read that as strictly less
than.
So the parsing problem goes away, and I think using the sort order as a
hint takes away the potential performance problem (I don't even know if
it was a problem -- there may be other O(n^2) behavior).
I will take a look at the tests Alex has been working on, maybe add a
few to it, and submit a cleaned-up series.
-Peff
^ permalink raw reply
* [PATCH] Teach git clean to use setup_standard_excludes()
From: Shawn Bohrer @ 2007-11-15 5:00 UTC (permalink / raw)
To: gitster; +Cc: madcoder, palglowr, git, Shawn Bohrer
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
builtin-clean.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/builtin-clean.c b/builtin-clean.c
index 01fb887..dc6a21e 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -22,7 +22,7 @@ static int git_clean_config(const char *var, const char *value)
{
if (!strcmp(var, "clean.requireforce"))
force = !git_config_bool(var, value);
- return 0;
+ return git_default_config(var, value);
}
int cmd_clean(int argc, const char **argv, const char *prefix)
@@ -57,7 +57,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
memset(&dir, 0, sizeof(dir));
if (ignored_only) {
dir.show_ignored =1;
- dir.exclude_per_dir = ".gitignore";
}
if (ignored && ignored_only)
@@ -70,11 +69,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
dir.show_other_directories = 1;
if (!ignored) {
- dir.exclude_per_dir = ".gitignore";
- if (!access(git_path("info/exclude"), F_OK)) {
- char *exclude_path = git_path("info/exclude");
- add_excludes_from_file(&dir, exclude_path);
- }
+ setup_standard_excludes(&dir);
}
pathspec = get_pathspec(prefix, argv);
--
1.5.3.GIT
^ permalink raw reply related
* Re: How to change a submodue as a subdirectory?
From: Ping Yin @ 2007-11-15 5:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20071114202651.GC3973@steel.home>
On Nov 15, 2007 4:26 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Ping Yin, Wed, Nov 14, 2007 15:37:57 +0100:
> > I have a super project superA, and a submodue subB. Now i decide to
> > switch subB from submodule to sub directory. Any good way to do that
> > and not losing any history?
>
> $ mv subB sub
> $ git add sub
> $ git update-index --force-remove subB
> $ git commit
>
> Which history were you afraid of losing?
>
I want to keep the history of the submodule
--
Ping Yin
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Junio C Hamano @ 2007-11-15 5:55 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20071115043513.GA10193@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... So you can only ever _know_ success,
> and with failure, you simply guess (and presumably retry).
Good thinking. I agree.
^ permalink raw reply
* Re: [PATCH] Extend cat-file to take multiple arguments or read input from stdin.
From: Junio C Hamano @ 2007-11-15 6:09 UTC (permalink / raw)
To: hanwen; +Cc: git, Adam Roben
In-Reply-To: <fhgitt$b8d$1@ger.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> I know, and that's what I was thinking. However, I was hoping someone else
> would pick up the hint :-)
>
> I suppose fast-export would just be cat-file with a different name and
> slightly saner interface. How about
>
> type <sha1> <newline>
> size <sha1> <newline>
> dump <type> <sha1> <newline>
I wondered why that looked so familiar ;-)
http://thread.gmane.org/gmane.comp.version-control.git/62295/focus=62441
Adam Roben CC'ed.
^ 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