* [OT] Amazon wishlist (was Re: [ANNOUCNE] repo - The Multiple Git Repository Tool)
From: Junio C Hamano @ 2008-10-22 23:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081022231756.GY14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> By the way, are you still in need of a folding bookshelf from Target?
>
> If you saw my wife's book collection, and the space we have, you'd
> understand my need for bookshelves... sadly we only have one.
> Why do you ask?
Because I stumbled across:
http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1XF91IZ5VXGTQ
recalled that you moved recently, thought perhaps it might be a good
idea to send you a housewarming gift, but was not sure if this list really
belonged to the person I thought.
Crazy people claim to be somebody else while wishing for something the
person they are disguising as never would. Once I looked for and found a
Linus Torvalds who wanted a bunch of mysql+php books ;-)
I was on Amazon's wishlist page because recently somebody asked me about
it, probably after reading http://gitster.livejournal.com/ (where I
mentioned I recently created one for myself without mentioning its URL --
the page has since been updated with one).
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Junio C Hamano @ 2008-10-22 23:21 UTC (permalink / raw)
To: Charles Bailey
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081022211720.GA23146@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> I'm pretty keen on this patch, but have no strong opinions on which
> short option is used, so are there any votes against -y?
Between 'n' and 'y', I am in favour of the latter, but at the same time I
have to wonder if there are other commands that would want "Assume yes"
option. It could be that this single command that prompts for "Is this
Ok" is an oddball and giving it an "interactive" option to trigger the
current behaviour might make things more consistent. I dunno.
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdvkte4i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> By the way, are you still in need of a folding bookshelf from Target?
If you saw my wife's book collection, and the space we have, you'd
understand my need for bookshelves... sadly we only have one.
Why do you ask?
--
Shawn.
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Junio C Hamano @ 2008-10-22 23:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081022211320.GW14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Google developed two tools, repo and Gerrit, and open sourced them
>> > under the Apache License:
>> >
>> > http://android.git.kernel.org/?p=tools/repo.git
>> > http://android.git.kernel.org/?p=tools/gerrit.git
>> >
>> > git://android.git.kernel.org/tools/repo.git
>> > git://android.git.kernel.org/tools/gerrit.git
>>
>> Heh, very nice, with a very shallow history ;-)
>
> Yea, well, some of our history messages are downright messy and/or
> contain information we don't want to disclose to the public. Its
> apparently "normal" for Google to just drop history when it opens
> a code base. :-\
Yeah, I understand that would be a norm for anybody who wasn't originally
open. I was just teasing, not really complaining ;-)
By the way, are you still in need of a folding bookshelf from Target?
^ permalink raw reply
* Re: git performance
From: Jakub Narebski @ 2008-10-22 22:42 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000801c93483$2fdad340$8f9079c0$@com>
"Edward Ned Harvey" <git@nedharvey.com> writes:
> I see things all over the Internet saying git is fast. I'm
> currently struggling with poor svn performance and poor attitude of
> svn developers, so I'd like to consider switching to git. A quick
> question first.
>
> The core of the performance problem I'm facing is the need to "walk
> the tree" for many thousand files. Every time I do "svn update" or
> "svn status" the svn client must stat every file to check for local
> modifications (a coffee cup or a beer worth of stats). In essence,
> this is unavoidable if there is no mechanism to constantly monitor
> filesystem activity during normal operations. Analogous to
> filesystem journaling.
>
> So - I didn't see anything out there saying "git is fast because it
> uses inotify" or anything like that. Perhaps git would not help me
> at all? Because git still needs to stat all the files in the tree?
http://git.or.cz/gitwiki/GitBenchmarks
While it should be possible to use 'assume unchanged' bit together
with inotify / icron, it is not something tha is done; IIRC Mercurial
had Linux-only InotifyPlugin...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Jakub Narebski @ 2008-10-22 22:40 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
"Weiwei Shu" <shuww1980@gmail.com> writes:
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
>
> I know it seems a little bit stupid to use Git to do such an easy job.
> But hey, it's the most eye-catching SCM software, isn't it?
First, git does not modify files unless you have core.crlf set,
and even then it warns about irreversible transformations
(core.safecrlf)
Second, using gitattributes you can set diff driver and merge driver;
one of possibilities is to treat file as binary (binary diff and no
using 3-way file merge).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-22 22:35 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810221511590.24463@asgard.lang.hm>
Thanks David.
Well, for binary files, SCM tools (like subversion) usually work as
"lock-modify-unlock" mode in which merging is not supported since the
files are not human-readable. The schematics are ascii files, but I do
not want them to be merged if I run "merge" command. Instead I'd like
Git ask me to "look-and-replace". I know Git is not meant to do this
kind of jobs. Just curious if it is able to be configured to work in
that way.
On Wed, Oct 22, 2008 at 5:13 PM, <david@lang.hm> wrote:
> On Wed, 22 Oct 2008, Weiwei Shu wrote:
>
>> Hello everyone,
>>
>> My first post in this mailing list. Could some one direct me to some
>> document/manual pages to setup Git to treat ascii files as binary
>> files? I'm using Git to do circuit schematics (SPICE files)
>> versioning. I will not do any merging or editing stuff with external
>> editors. The only way to change it is to use schematic capture GUIs
>> (Cadence, ADS, etc). So I'd like to treat them as binary files to
>> reduce the possibilities of messing them up.
>>
>> I know it seems a little bit stupid to use Git to do such an easy job.
>> But hey, it's the most eye-catching SCM software, isn't it?
>
> unless you enable cr/lf handling git won't change ascii files.
>
> what is it that you think needs to be done differently for these files than
> for any other files?
>
> David Lang
>
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: David Symonds @ 2008-10-22 22:13 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
On Wed, Oct 22, 2008 at 2:58 PM, Weiwei Shu <shuww1980@gmail.com> wrote:
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
Git doesn't futz with your file contents unless you explicitly ask it
to, such as the CRLF-munging stuff. By default, all files are
"binary".
Dave.
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: david @ 2008-10-22 22:13 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
On Wed, 22 Oct 2008, Weiwei Shu wrote:
> Hello everyone,
>
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
>
> I know it seems a little bit stupid to use Git to do such an easy job.
> But hey, it's the most eye-catching SCM software, isn't it?
unless you enable cr/lf handling git won't change ascii files.
what is it that you think needs to be done differently for these files
than for any other files?
David Lang
^ permalink raw reply
* Re: [RFC PATCH 1/5] add valgrind support in test scripts
From: Johannes Schindelin @ 2008-10-22 22:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081022202915.GA4547@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> diff --git a/Makefile b/Makefile
> index d6f3695..68f0172 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1343,7 +1345,12 @@ all:: $(TEST_PROGRAMS)
>
> export NO_SVN_TESTS
>
> -test: all
> +valgrind-setup: $(patsubst %.sh,%,$(VALGRIND_SH))
> + rm -rf t/valgrind/bin
> + mkdir t/valgrind/bin
> + for i in git $(PROGRAMS); do cp test-valgrind t/valgrind/bin/$$i; done
I wonder if it would not be better to scrap the t/valgrind/ directory and
regenerate it everytime you run a test manually; I'd use "ln" instead of
"cp", and also parse command-list.txt to catch really all of them (even if
a dashed form is used for a builtin by mistake).
Otherwise: good work, I like it!
Ciao,
Dscho
^ permalink raw reply
* how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-22 21:58 UTC (permalink / raw)
To: git
Hello everyone,
My first post in this mailing list. Could some one direct me to some
document/manual pages to setup Git to treat ascii files as binary
files? I'm using Git to do circuit schematics (SPICE files)
versioning. I will not do any merging or editing stuff with external
editors. The only way to change it is to use schematic capture GUIs
(Cadence, ADS, etc). So I'd like to treat them as binary files to
reduce the possibilities of messing them up.
I know it seems a little bit stupid to use Git to do such an easy job.
But hey, it's the most eye-catching SCM software, isn't it?
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* RE: git performance
From: Edward Ned Harvey @ 2008-10-22 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <20081022203624.GA4585@coredump.intra.peff.net>
> Yes, it does stat all the files. How many files are you talking about,
> and what platform? From a warm cache on Linux, the 23,000 files kernel
> repo takes about a tenth of a second to stat all files for me (and this
> on a several year-old machine). And of course many operations don't
> require stat'ing at all (like looking at logs, or diffs that don't
> involve the working tree).
No worries. No solution can meet everyone's needs.
I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
^ permalink raw reply
* [PATCH] Fixed git archive for bare repos
From: Charles Bailey @ 2008-10-22 21:47 UTC (permalink / raw)
To: git; +Cc: Deskin Miller, kenneth johansson, gitster
In-Reply-To: <20081022210913.GB22541@hashpling.org>
This moves the call to git config to a place where it doesn't break the
logic for using git archive in a bare repository but retains the fix to
make git archive respect core.autocrlf.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
OK, I've had a chance to have a quick look at this issue and I have an
altenative patch.
This is an alternative fix to the current git archive in a bare
repository issue.
It's been lightly tested and doesn't re-break the zip / autocrlf issue
that the previous introduction of git_config was designed to fix.
archive.c | 2 ++
builtin-archive.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/archive.c b/archive.c
index 849eed5..9ac455d 100644
--- a/archive.c
+++ b/archive.c
@@ -336,5 +336,7 @@ int write_archive(int argc, const char **argv, const char *prefix,
parse_treeish_arg(argv, &args, prefix);
parse_pathspec_arg(argv + 1, &args);
+ git_config(git_default_config, NULL);
+
return ar->write_archive(&args);
}
diff --git a/builtin-archive.c b/builtin-archive.c
index 432ce2a..5ceec43 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -111,8 +111,6 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
- git_config(git_default_config, NULL);
-
remote = extract_remote_arg(&argc, argv);
if (remote)
return run_remote_archiver(remote, argc, argv);
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-22 21:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081021122655.GA29294@hashpling.org>
On Tue, Oct 21, 2008 at 01:26:55PM +0100, Charles Bailey wrote:
> On Tue, Oct 21, 2008 at 01:49:30PM +0200, Andreas Ericsson wrote:
> >
> > There is discussion already about "-n should be for dry-run!" and git's
> > inconsistencies in such matters. Wouldn't -y ("assume yes on prompt")
> > be better?
> >
>
> I must have missed this discussion. I've just had a very quick look at
> a handful of basic modifying git commands (merge, pull, commit,
> checkout, reset, revert) and only found 'add' that used -n as
> --dry-run.
>
> That said, I've no real objections to -y if that makes for a better
> consensus.
>
I'm pretty keen on this patch, but have no strong opinions on which
short option is used, so are there any votes against -y?
If I re-roll with the favoured short option is there anything else
that would prevent its adoption into next or master?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 21:16 UTC (permalink / raw)
To: Leo Razoumov; +Cc: git
In-Reply-To: <ee2a733e0810221255u23aabef2i66d878bcbfa11816@mail.gmail.com>
Leo Razoumov <slonik.az@gmail.com> wrote:
> On 10/22/08, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Google developed two tools, repo and Gerrit, and open sourced them
> > under the Apache License:
> >
> > http://android.git.kernel.org/?p=tools/repo.git
> > http://android.git.kernel.org/?p=tools/gerrit.git
> >
> > git://android.git.kernel.org/tools/repo.git
> > git://android.git.kernel.org/tools/gerrit.git
> >
> > repo is a Python application to bind together Git repositories,
> > something like "git submodule",
>
> Are there any plans to make repo an official git command (e.g.
> git-repo) or merge its functionality with git-submodule?
I currently do not plan on asking Junio to consider making repo part
of git. However, I am also not adverse to it if repo development
slows down and there is sufficient community interest.
--
Shawn.
^ permalink raw reply
* Re: git performance
From: Peter Harris @ 2008-10-22 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: Edward Ned Harvey, git
In-Reply-To: <20081022203624.GA4585@coredump.intra.peff.net>
On Wed, Oct 22, 2008 at 4:36 PM, Jeff King wrote:
> On Wed, Oct 22, 2008 at 04:17:16PM -0400, Edward Ned Harvey wrote:
>
>> So - I didn't see anything out there saying "git is fast because it
>> uses inotify" or anything like that. Perhaps git would not help me at
>> all? Because git still needs to stat all the files in the tree?
>
> Yes, it does stat all the files. How many files are you talking about,
> and what platform? From a warm cache on Linux, the 23,000 files kernel
> repo takes about a tenth of a second to stat all files for me (and this
> on a several year-old machine). And of course many operations don't
> require stat'ing at all (like looking at logs, or diffs that don't
> involve the working tree).
Windows is rather slower than Linux, so differences are more obvious.
I find git feels "only" about 2x as fast as svn at status. svn has to
stat all of its base files too, whereas git has the index. git pull
(vs svn update) feels better than 2x faster, since git doesn't need to
walk the tree and lock every sub-dir before it even connects to the
remote server.
So we're not talking 'inotify' fast, but maybe half a cup of coffee
instead of a full cup if you have that many files.
"git-svn" is really quite good. I recommend you try a quick (trunk and
maybe one branch only, last few revisions only) import of your svn
tree to test with.
Peter Harris
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlkwtpbq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Google developed two tools, repo and Gerrit, and open sourced them
> > under the Apache License:
> >
> > http://android.git.kernel.org/?p=tools/repo.git
> > http://android.git.kernel.org/?p=tools/gerrit.git
> >
> > git://android.git.kernel.org/tools/repo.git
> > git://android.git.kernel.org/tools/gerrit.git
>
> Heh, very nice, with a very shallow history ;-)
Yea, well, some of our history messages are downright messy and/or
contain information we don't want to disclose to the public. Its
apparently "normal" for Google to just drop history when it opens
a code base. :-\
The repo and Gerrit histories are short enough that I might
be able to go through them and clean them up some (remove any
comments revealing Google secrets) and publish the history under a
different repository. Folks can always graft it behind the (now)
real repository.
I can't promise anything, but I'll talk to my co-contributors and
consider doing this in the near future.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] archive: fix setup to work in bare repositories
From: Charles Bailey @ 2008-10-22 21:09 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git, gitster
In-Reply-To: <20081022203722.GD2015@riemann.deskinm.fdns.net>
On Wed, Oct 22, 2008 at 04:37:22PM -0400, Deskin Miller wrote:
> cmd_archive was calling git_config -> setup_git_env prior to
> write_archive calling setup_git_directory. In a bare repository, the
> former will set git_dir to be '.git' since the latter has not
> determined that it's operating in a bare repository yet.
>
> Things are complicated, however, by the fact that git archive --list
> should work from anywhere, not just in git repositories, so that
> argument needs to be checked for before setup_git_directory is called.
Just for some background, I think that this issue might be an
unintended consequence of this commit:
b99b5b40cffb5269e4aa38b6b60391b55039e27d
The only reason that the git_config call has been added is to ensure
the correct setting of core.autocrlf before convert_to_working_tree is
called on any blobs.
I haven't looked in detail, but would moving this call later make for
an cleaner change?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [RFC PATCH] archive: fix setup to work in bare repositories
From: Jeff King @ 2008-10-22 20:46 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git, gitster
In-Reply-To: <20081022203722.GD2015@riemann.deskinm.fdns.net>
On Wed, Oct 22, 2008 at 04:37:22PM -0400, Deskin Miller wrote:
> cmd_archive was calling git_config -> setup_git_env prior to
> write_archive calling setup_git_directory. In a bare repository, the
> former will set git_dir to be '.git' since the latter has not
> determined that it's operating in a bare repository yet.
>
> Things are complicated, however, by the fact that git archive --list
> should work from anywhere, not just in git repositories, so that
> argument needs to be checked for before setup_git_directory is called.
Should you perhaps be able to call setup_git_directory_gently(), and
then once you decide that you really do need the setup, call
setup_git_directory()?
You would have to add a "did we already do run" flag to
setup_git_directory_gently(), but I think it is already an error to call
it twice, so you wouldn't be hurting anything by that.
Note also that by moving the setup, you are moving the chdir() that
happens; you may need to prefix paths to any arguments to accomodate
this (I don't think it should matter, since git-archive shouldn't look
at any paths until after it would have done the setup_git_directory()
before, but I didn't check carefully).
-Peff
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 20:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gdo1a3$akl$1@ger.gmane.org>
On Wed, Oct 22, 2008 at 10:12:54PM +0200, Jakub Narebski wrote:
> Currently you can use path_info URL for blob_plain
>
> http://repo.or.cz/w/git/gitbuild.git/platform:/jk/solaris/config.mak
Ah, I didn't know that. Thanks.
> Soon (thanks to Giuseppe patches) you would be able to use
>
> http://repo.or.cz/w/git/gitbuild.git/blob/platform:/jk/solaris/config.mak
Yes, those patches were actually what spurred my comment. :) I am
looking forward to playing with them once they are on repo.or.cz.
-Peff
^ permalink raw reply
* [RFC PATCH] archive: fix setup to work in bare repositories
From: Deskin Miller @ 2008-10-22 20:37 UTC (permalink / raw)
To: kenneth johansson; +Cc: git, gitster
In-Reply-To: <gdnsca$92r$2@ger.gmane.org>
cmd_archive was calling git_config -> setup_git_env prior to
write_archive calling setup_git_directory. In a bare repository, the
former will set git_dir to be '.git' since the latter has not
determined that it's operating in a bare repository yet.
Things are complicated, however, by the fact that git archive --list
should work from anywhere, not just in git repositories, so that
argument needs to be checked for before setup_git_directory is called.
---
On Wed, Oct 22, 2008 at 06:45:30PM +0000, kenneth johansson wrote:
> On Wed, 22 Oct 2008 09:08:29 -0400, Deskin Miller wrote:
>
> > On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> >> I was going to make a tar of the latest stable linux kernel. Done it
> >> before but now I got a strange problem.
> >>
> >> >git archive --format=tar v2.6.27.2
> >> fatal: Not a valid object name
> >
> > I had the same thing happen to me, while trying to make an archive of
> > Git. Were you perchance working in a bare repository, as I was? I spent
> > some time looking at it and I think git archive sets up the environment
> > in the wrong order, though of course I never finished a patch so I'm
> > going from memory:
>
> Yes it was a bare repository.
>
> >
> > After looking at the code again, I think the issue is that git_config is
> > called in builtin-archive.c:cmd_archive before setup_git_directory is
> > called in archive.c:write_archive. The former ends up setting GIT_DIR
> > to be '.git' even if you're in a bare repository. My coding skills
> > weren't up to fixing it easily; moving setup_git_directory before
> > git_config in builtin-archive caused last test of t5000 to fail:
> > GIT_DIR=some/nonexistent/path git archive --list should still display
> > the archive formats.
>
> if I do
> GIT_DIR=. git archive --format=tar v2.6.27.2
>
> it does work so it looks like you are on the right track.
Looks like this works, but I think it's really ugly; let me know if you have
any suggestions for improvement.
archive.c | 13 +++++++++++++
archive.h | 1 +
builtin-archive.c | 4 +++-
t/t5000-tar-tree.sh | 9 +++++++++
4 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/archive.c b/archive.c
index e2280df..d8e4373 100644
--- a/archive.c
+++ b/archive.c
@@ -325,6 +325,19 @@ static int parse_archive_args(int argc, const char **argv,
return argc;
}
+int archive_parse_options_early(int argc, const char **argv)
+{
+ int i;
+ for (i = 1; i < argc; ++i) {
+ if (!strcmp(argv[i], "--list")) {
+ for (i = 0; i < ARRAY_SIZE(archivers); i++)
+ printf("%s\n", archivers[i].name);
+ exit(0);
+ }
+ }
+ return 0;
+}
+
int write_archive(int argc, const char **argv, const char *prefix,
int setup_prefix)
{
diff --git a/archive.h b/archive.h
index 0b15b35..ff5b6cf 100644
--- a/archive.h
+++ b/archive.h
@@ -24,6 +24,7 @@ extern int write_tar_archive(struct archiver_args *);
extern int write_zip_archive(struct archiver_args *);
extern int write_archive_entries(struct archiver_args *args, write_archive_entry_fn_t write_entry);
+extern int archive_parse_options_early(int argc, const char **argv);
extern int write_archive(int argc, const char **argv, const char *prefix, int setup_prefix);
#endif /* ARCHIVE_H */
diff --git a/builtin-archive.c b/builtin-archive.c
index 432ce2a..e518113 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -111,6 +111,8 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
+ archive_parse_options_early(argc, argv);
+ prefix = setup_git_directory();
git_config(git_default_config, NULL);
remote = extract_remote_arg(&argc, argv);
@@ -119,5 +121,5 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
setvbuf(stderr, NULL, _IOLBF, BUFSIZ);
- return write_archive(argc, argv, prefix, 1);
+ return write_archive(argc, argv, prefix, 0);
}
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index e395ff4..53fe25c 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -192,4 +192,13 @@ test_expect_success \
'git archive --list outside of a git repo' \
'GIT_DIR=some/non-existing/directory git archive --list'
+test_expect_success \
+ 'git archive inside bare repository' \
+ 'git clone --bare "$(pwd)"/.git trash-bare &&
+ cd trash-bare &&
+ git archive --format=tar HEAD >/dev/null &&
+ cd .. &&
+ rm -rf trash-bare
+ '
+
test_done
--
1.6.0.2.554.g3041b
^ permalink raw reply related
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 20:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Alexander Gavrilov, git
In-Reply-To: <alpine.DEB.1.00.0810222220410.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 22, 2008 at 10:29:39PM +0200, Johannes Schindelin wrote:
> > Not all greps support "-e", but in this case we can easily
> > convert it to a single extended regex.
>
> I really wonder if we cannot catch these things (unportable grep, sed, etc
> invokations) with a simple patch to the pre-commit hook.
We could probably write a hook for some of the simpler ones, but we
would have quite a few false negatives, I suspect.
FWIW, I am not finding these portability problems by hand. I am nightly
auto-building and testing Junio's maint, master, and next on Solaris 8
and FreeBSD, and Mike Ralphson is doing the same for AIX. So while we
could perhaps catch them sooner, I am very happy to have caught several
issues recently in next, _before_ they hit master.
-Peff
^ permalink raw reply
* Re: git performance
From: Jeff King @ 2008-10-22 20:36 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000801c93483$2fdad340$8f9079c0$@com>
On Wed, Oct 22, 2008 at 04:17:16PM -0400, Edward Ned Harvey wrote:
> So - I didn't see anything out there saying "git is fast because it
> uses inotify" or anything like that. Perhaps git would not help me at
> all? Because git still needs to stat all the files in the tree?
Yes, it does stat all the files. How many files are you talking about,
and what platform? From a warm cache on Linux, the 23,000 files kernel
repo takes about a tenth of a second to stat all files for me (and this
on a several year-old machine). And of course many operations don't
require stat'ing at all (like looking at logs, or diffs that don't
involve the working tree).
-Peff
^ permalink raw reply
* Older git version on the server
From: Diego Algorta @ 2008-10-22 20:33 UTC (permalink / raw)
To: git
Hi all,
= Background
We are a team of 3 developers. Each one has his own clone from a central
public repo in our server where we all push and pull from (you can tell
we come from svn). We do deployments on production from that repo's
master branch.
= Problem
We recently started using git submodules and now we're facing a problem
when switching between branches (git checkout) which have the same
submodule but linked from different sources. Some google research says
the new "git submodule sync" feature may be the solution, but we can't
use a version newer than 1.5.6.1 on the server.
= Question
Would it be a problem for us to use 1.6.0.3 on our development
environments and keep using 1.5.6.1 on the server to do the deployments?
Thank you!
--
Diego Algorta - Web Developer & SysAdmin -
http://www.oboxodo.com - http://diego.algorta.net
^ permalink raw reply
* [RFC PATCH 5/5] fix overlapping memcpy in normalize_absolute_path
From: Jeff King @ 2008-10-22 20:32 UTC (permalink / raw)
To: git
In-Reply-To: <20081022202810.GA4439@coredump.intra.peff.net>
The comments for normalize_absolute_path explicitly claim
that the source and destination buffers may be the same
(though they may not otherwise overlap). Thus the call to
memcpy may involve copying overlapping data, and memmove
should be used instead.
This fixes a valgrind error in t1504.
Signed-off-by: Jeff King <peff@peff.net>
---
An alternative fix, since we declare that only true equality is OK,
would be to keep the memcpy and explicitly check for "comp_start ==
dst". That might have a performance benefit if memcpy is faster than
memmove, but I don't know that normalize_absolute_path is in any
critical paths.
path.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/path.c b/path.c
index 76e8872..c1cb54b 100644
--- a/path.c
+++ b/path.c
@@ -348,7 +348,7 @@ int normalize_absolute_path(char *buf, const char *path)
goto next;
}
- memcpy(dst, comp_start, comp_len);
+ memmove(dst, comp_start, comp_len);
dst += comp_len;
next:
comp_start = comp_end;
--
1.6.0.2.825.g6d19d
^ 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