* Re: [PATCH] rename dirlink to gitlink.
From: Junio C Hamano @ 2007-05-21 23:32 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Martin Waitz, Junio C Hamano, git
In-Reply-To: <e7bda7770705211612w3ce1b7dew8d48f1ddeb7d100e@mail.gmail.com>
"Torgil Svensson" <torgil.svensson@gmail.com> writes:
> On 5/21/07, Martin Waitz <tali@admingilde.org> wrote:
>> Unify naming of plumbing dirlink/gitlink concept:
>>
>> perl -pi -e 's/dirlink/gitlink/g' -e 's/DIRLNK/GITLINK/g'
>> ---
>
> Does this mean that the link doesn't necessarily has to be represented
> as a directory (even though current code does it) ?
I do not think the patch has that much deep meaning.
Personally I think the patch is similar to renaming "cache" used
in the code to "index" --- needless code shuffling that does not
buy you anything.
As an internal symbol, S_IFDIRLNK makes _much_ more sense than
S_IFGITLINK, exactly because it is a mixture of S_IFDIR and
S_IFLNK.
The only excuse that we _might_ want to consider the patch is
that S_IFDIRLNK has not lived that long, compared to the use of
word "cache" in our codebase. It's only two weeks old -- so if
we were to apply this patch, we would need to do that right
away, or it will be never.
But I am not _so_ enthused about the renaming in the code.
^ permalink raw reply
* [PATCH] git-status: respect core.excludesFile
From: Johannes Schindelin @ 2007-05-22 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b1pdbjf.fsf@assigned-by-dhcp.cox.net>
git-add reads this variable, and honours the contents of that file if that
exists. Match this behaviour in git-status, too.
Noticed by Evan Carroll on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 21 May 2007, Junio C Hamano wrote:
> Sounds good, and probably is a 'maint' material.
>
> Don't we need a documentation update and additional test for it,
> though?
Here you are.
Documentation/config.txt | 5 +++++
Documentation/git-status.txt | 5 +++++
t/t3001-ls-files-others-exclude.sh | 20 ++++++++++++++++++++
wt-status.c | 9 +++++++++
4 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ee1c35e..179cb17 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -256,6 +256,11 @@ You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
+core.excludeFile::
+ In addition to '.gitignore' (per-directory) and
+ '.git/info/exclude', git looks into this file for patterns
+ of files which are not meant to be tracked.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index e9e193f..d701538 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -42,6 +42,11 @@ mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
+As for gitlink:git-add[1], the configuration variable
+'core.excludesfile' can indicate a path to a file containing patterns
+of file names to exclude, in addition to patterns given in
+'info/exclude' and '.gitignore'.
+
Author
------
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index db7a847..fcfcfbb 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -79,4 +79,24 @@ test_expect_success \
>output &&
git diff expect output'
+cat > excludes-file << EOF
+*.[1-8]
+e*
+EOF
+
+git-config core.excludesFile excludes-file
+
+git-runstatus | grep "^# " > output
+
+cat > expect << EOF
+# .gitignore
+# a.6
+# one/
+# output
+# three/
+EOF
+
+test_expect_success 'git-status honours core.excludesfile' \
+ 'diff -u expect output'
+
test_done
diff --git a/wt-status.c b/wt-status.c
index a055990..4bfe8f1 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -22,6 +22,7 @@ static const char use_add_rm_msg[] =
"use \"git add/rm <file>...\" to update what will be committed";
static const char use_add_to_include_msg[] =
"use \"git add <file>...\" to include in what will be committed";
+static const char *excludes_file;
static int parse_status_slot(const char *var, int offset)
{
@@ -259,6 +260,8 @@ static void wt_status_print_untracked(struct wt_status *s)
x = git_path("info/exclude");
if (file_exists(x))
add_excludes_from_file(&dir, x);
+ if (excludes_file && file_exists(excludes_file))
+ add_excludes_from_file(&dir, excludes_file);
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
@@ -356,5 +359,11 @@ int git_status_config(const char *k, const char *v)
int slot = parse_status_slot(k, 13);
color_parse(v, k, wt_status_colors[slot]);
}
+ if (!strcmp(k, "core.excludesfile")) {
+ if (!v)
+ die("core.excludesfile without value");
+ excludes_file = xstrdup(v);
+ return 0;
+ }
return git_default_config(k, v);
}
--
1.5.2.746.g222b
^ permalink raw reply related
* Re: gitweb - encoding problems
From: David Woodhouse @ 2007-05-22 0:33 UTC (permalink / raw)
To: Martin Koegler; +Cc: git, Jakub Narebski, Junio C Hamano
In-Reply-To: <20070521205721.GA21771@auto.tuwien.ac.at>
On Mon, 2007-05-21 at 22:57 +0200, Martin Koegler wrote:
> I use ISO-8859-1 as my locale, so my blobs, commits and tags are in
> this encoding.
That's a very strange thing for anyone to do in the 21st century.
Did you configure this archaic thing correctly in .git/config?
Otherwise, gitweb will assume that you're using utf-8 like any normal
person would, and of course you'll have problems when it tries to deal
with your legacy character set as if it were something sensible.
--
dwmw2
^ permalink raw reply
* subsystems/modules
From: Aaron Gray @ 2007-05-22 0:56 UTC (permalink / raw)
To: Git Mailing List
Is there any support for modules or subsystems in GIT or is that the
proposed subprojects territory ?
Aaron
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Junio C Hamano @ 2007-05-22 1:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550705210423i34dc481es61d3b886ae77c5f7@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 5/21/07, Junio C Hamano <junkio@cox.net> wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>
>>
>> We somehow end up removing one LF too many, like this:
>>
>> diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
>> index c531d98..016d3b1 100644
>> --- a/contrib/emacs/.gitignore
>> +++ b/contrib/emacs/.gitignore
>> @@ -1 +1 @@
>> -*.elc
>> +*.elc
>> \ No newline at end of file
>>
>
> I also had that, but after adding
>
> +
> + if (empty < trailing_added_lines)
> + empty--;
> +
>
> everything worked correctly. I made again the same test myself
> without problems.
>
> I really don't understand how could be broken.
Hmmm. Puzzled.
Let's say that the patch is to create a file that has a single
line, like this:
diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
new file mode 100644
index 0000000..c531d98
--- /dev/null
+++ b/contrib/emacs/.gitignore
@@ -0,0 +1 @@
+*.elc
The function "apply_one_fragment" gets two lines ('@' and '+').
We come to "while (size > 0)" loop. During the first round,
'first' is '@' and the line is ignored. In the second round,
'first' is '+', so apply_line appends the contents to 'new'
buffer, while we count trailing_added_lines.
End result is
- newsize = 6, new has "*.elc\n";
- oldsize = 0, and old has "";
- trailing_added_lines = 1;
when we get to the "empty" counting code.
Then you count empty up to trailing_added_lines. When we get to
the "if (empty < trailing_added_lines)" code, empty is 1. You
do not decrement this, and take that number in
trailing_added_lines, to be used to strip the trailing run of
newlines in the for (;;) loop later. That's how you can lose
the last newline that is not on a blank line.
^ permalink raw reply related
* Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch
From: Stian Haklev @ 2007-05-22 4:05 UTC (permalink / raw)
To: Andy Parkins, git
In-Reply-To: <200705211016.58067.andyparkins@gmail.com>
OK, I made the following script:
do.sh:
git --version > ../file1
date >> ../file1
git status >> ../file1
echo checking out works with old >> ../file1
git checkout works-with-old >> ../file1
git status >> ../file1
git checkout master >> ../file1
git status >> ../file1
date >> ../file1
I ran it, and I got the following result:
nurhaliza:~/wiki stian$ less ../file1
git version 1.5.2.14.g45bde
Tue May 22 11:05:19 WIT 2007
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# do.sh
nothing added to commit but untracked files present (use "git add" to track)
checking out works with old
# On branch works-with-old
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# do.sh
nothing added to commit but untracked files present (use "git add" to track)
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: NOTES
# modified: display-page.rb
# deleted: eee_darwin
# modified: gui.rb
# modified: htmlshrinker-data.rb
# modified: htmlshrinker.rb
# modified: mongrel-web-gui.rb
# modified: mongrel-web.rb
# modified: zarchive.rb
# new file: zcompress.rb
# modified: zdump-7z.rb
# modified: zdump.rb
# modified: zipdoc.rb
# deleted: zutil.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# do.sh
Tue May 22 11:05:20 WIT 2007
...
I should add that I am working in OSX 10.4.9.
Thank you,
Stian
^ permalink raw reply
* Re: subsystems/modules
From: Martin Waitz @ 2007-05-22 5:53 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <00aa01c79c0c$17a07200$0200a8c0@AMD2500>
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
hoi :)
On Tue, May 22, 2007 at 01:56:54AM +0100, Aaron Gray wrote:
> Is there any support for modules or subsystems in GIT or is that the
> proposed subprojects territory ?
that is called subproject in Git and is currently under construction, yes.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] rename dirlink to gitlink.
From: Martin Waitz @ 2007-05-22 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torgil Svensson, git
In-Reply-To: <7vodkdbvmk.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
hoi :)
On Mon, May 21, 2007 at 04:32:51PM -0700, Junio C Hamano wrote:
> As an internal symbol, S_IFDIRLNK makes _much_ more sense than
> S_IFGITLINK, exactly because it is a mixture of S_IFDIR and
> S_IFLNK.
But then we also should be consequent and rename the entire
low-level plumbing to dirlink. I don't see a reason to keep
both.
For me the S_ macro names are about the file type which is represented
by them. The fact that dirlinks/gitlinks are represented as
DIR + LNK is nice but not so important that we have to name the
macro that way.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add ability to specify environment extension to run_command
From: Martin Waitz @ 2007-05-22 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Sven Verdoolaege
In-Reply-To: <7v7ir1dbl9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
hoi :)
On Mon, May 21, 2007 at 04:02:42PM -0700, Junio C Hamano wrote:
> I had a feeling that some callers needed to be able to unsetenv
> some. How would this patch help them, or are they outside of
> the scope?
At first I had the same objection but the putenv documentation
told me that at least in glibc you can unsetenv by providing
the variable name without a "=".
But perhaps we should check for other systems?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Junio C Hamano @ 2007-05-22 6:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brian Gernhardt, Anand Kumria, git, Johannes Schindelin
In-Reply-To: <20070521072025.GO3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Teach git-describe how to run name-rev
>
> Often users want to know not which tagged version a commit came
> after, but which tagged version a commit is contained within.
> This latter task is the job of git-name-rev, but most users are
> looking to git-describe to do the job.
>
> Junio suggested we make `git describe --contains` run the correct
> tool, `git name-rev`, and that's exactly what we do here. The output
> of name-rev was adjusted slightly through the new --name-only option,
> allowing describe to execv into name-rev and maintain its current
> output format.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ...
> diff --git a/builtin-describe.c b/builtin-describe.c
> index 165917e..efbd43f 100644
> --- a/builtin-describe.c
> +++ b/builtin-describe.c
> ...
> @@ -272,6 +276,17 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
>
> save_commit_buffer = 0;
>
> + if (contains) {
> + const char **nr = xmalloc((4 + argc - i) * sizeof(char*));
> + nr[0] = "name-rev";
> + nr[1] = "--name-only";
> + nr[2] = "--tags";
> + memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
> + nr[3 + argc - i] = NULL;
> + execv_git_cmd(nr);
> + die("unable to start %s", nr[0]);
> + }
> +
> if (argc <= i)
> describe("HEAD", 1);
> else
Sorry for a belated question, but is there a reason not to do
this (on top)?
diff --git a/builtin-describe.c b/builtin-describe.c
index efbd43f..2a32af6 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -283,8 +283,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
nr[2] = "--tags";
memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
nr[3 + argc - i] = NULL;
- execv_git_cmd(nr);
- die("unable to start %s", nr[0]);
+ return cmd_name_rev(3 + argc - i, nr, prefix);
}
if (argc <= i)
^ permalink raw reply related
* [PATCH] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-22 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
Using fast-import and repack with the max-pack-size patch,
3628 commits were imported from Perforce comprising
100.35GB (uncompressed) in 38829 blobs, and saved in
7 packfiles of 12.5GB total (--window=0 and --depth=0 were
used due to runtime limits). When using these packfiles,
several git commands showed very large process sizes,
and some slowdowns (compared to comparable operations
on the linux kernel repo) were also apparent.
git stores data in loose blobs or in packfiles. The former
has essentially now become an exception mechanism, to store
exceptionally *young* blobs. Why not use this to store
exceptionally *large* blobs as well? This allows us to
re-use all the "exception" machinery with only a small change.
Repacking the entire repository with a max-blob-size of 256KB
resulted in a single 13.1MB packfile, as well as 2853 loose
objects totaling 15.4GB compressed and 100.08GB uncompressed,
11 files per objects/xx directory on average. All was created
in half the runtime of the previous yet with standard
--window=10 and --depth=50 parameters. The data in the
packfile was 270MB uncompressed in 35976 blobs. Operations
such as "git-log --pretty=oneline" were about 30X faster
on a cold cache and 2 to 3X faster otherwise. Process sizes
remained reasonable.
This patch implements the following:
1. git pack-objects takes a new --max-blob-size=N flag,
with the effect that only blobs less than N KB are written
to the packfiles(s). If a blob was in a pack but violates
this limit (perhaps the packs were created by fast-import
or max-blob-size was reduced), then a new loose object
is written out if needed so the data is not lost.
2. git repack inspects repack.maxblobsize . If set, its
value is passed to git pack-objects on the command line.
The user should change repack.maxblobsize , NOT specify
--max-blob-size=N .
3. No other caller of git pack-objects supplies this new flag,
so other callers see no change.
This patch is on top of the earlier max-pack-size patch,
because I thought I needed some behavior it supplied,
but could be rebased on master if desired.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
builtin-pack-objects.c | 33 +++++++++++++++++++++++++++++++--
cache.h | 2 ++
git-repack.sh | 4 ++++
sha1_file.c | 17 +++++++++++++++--
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 930b57a..e88f6b7 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -16,7 +16,7 @@
static const char pack_usage[] = "\
git-pack-objects [{ -q | --progress | --all-progress }] [--max-pack-size=N] \n\
- [--local] [--incremental] [--window=N] [--depth=N] \n\
+ [--local] [--incremental] [--window=N] [--depth=N] [--max-blob-size=N]\n\
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
[--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
[--stdout | base-name] [<ref-list | <object-list]";
@@ -73,6 +73,7 @@ static int num_preferred_base;
static struct progress progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
+static uint32_t max_blob_size;
/*
* The object names in objects array are hashed with this hashtable,
@@ -562,6 +563,24 @@ static off_t write_one(struct sha1file *f,
return 0;
}
+ /* refuse to include megablobs */
+ if (max_blob_size && e->size >= max_blob_size) {
+ if (e->in_pack) {
+ /* rewrite as loose object so git-repack doesn't lose data */
+ void *buf;
+ enum object_type type;
+ unsigned long size;
+ buf = read_sha1_file(e->sha1, &type, &size);
+ if (!buf)
+ die("unable to read %s", sha1_to_hex(e->sha1));
+ if (write_sha1_file_ignore_packs(buf, size, typename(type), NULL) < 0)
+ die("failed to write object");
+ free(buf);
+ }
+ written++;
+ return offset;
+ }
+
e->offset = offset;
size = write_object(f, e, offset);
if (!size) {
@@ -1391,13 +1410,16 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
/* Now some size filtering heuristics. */
trg_size = trg_entry->size;
+ src_size = src_entry->size;
+ /* prevent use if later dropped from packfile */
+ if (max_blob_size && (trg_size >= max_blob_size || src_size >= max_blob_size))
+ return 0;
max_size = trg_size/2 - 20;
max_size = max_size * (max_depth - src_entry->depth) / max_depth;
if (max_size == 0)
return 0;
if (trg_entry->delta && trg_entry->delta_size <= max_size)
max_size = trg_entry->delta_size-1;
- src_size = src_entry->size;
sizediff = src_size < trg_size ? trg_size - src_size : 0;
if (sizediff >= max_size)
return 0;
@@ -1701,6 +1723,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
incremental = 1;
continue;
}
+ if (!prefixcmp(arg, "--max-blob-size=")) {
+ char *end;
+ max_blob_size = strtoul(arg+16, &end, 0) * 1024;
+ if (!arg[16] || *end)
+ usage(pack_usage);
+ continue;
+ }
if (!prefixcmp(arg, "--compression=")) {
char *end;
int level = strtoul(arg+14, &end, 0);
diff --git a/cache.h b/cache.h
index 3143853..ad39f67 100644
--- a/cache.h
+++ b/cache.h
@@ -343,6 +343,8 @@ extern int sha1_object_info(const unsigned char *, unsigned long *);
extern void * read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size);
extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
+extern int write_sha1_file_ignore_packs(void *buf, unsigned long len, const char *type,
+ unsigned char *return_sha1);
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
diff --git a/git-repack.sh b/git-repack.sh
index 4ea6e5b..c2b2112 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -35,6 +35,10 @@ true)
extra="$extra --delta-base-offset" ;;
esac
+# handle blob limiting
+mbs="`git config --int repack.maxblobsize`"
+[ -n "$mbs" ] && extra="$extra --max-blob-size=$mbs"
+
PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
PACKTMP="$GIT_OBJECT_DIRECTORY/.tmp-$$-pack"
rm -f "$PACKTMP"-*
diff --git a/sha1_file.c b/sha1_file.c
index e715527..8786af7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1979,7 +1979,8 @@ int hash_sha1_file(const void *buf, unsigned long len, const char *type,
return 0;
}
-int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
+static int write_sha1_file_core(void *buf, unsigned long len, const char *type,
+ int checkpacks, unsigned char *returnsha1)
{
int size, ret;
unsigned char *compressed;
@@ -1997,7 +1998,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
filename = sha1_file_name(sha1);
if (returnsha1)
hashcpy(returnsha1, sha1);
- if (has_sha1_file(sha1))
+ if (checkpacks && has_sha1_file(sha1))
return 0;
fd = open(filename, O_RDONLY);
if (fd >= 0) {
@@ -2062,6 +2063,18 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
return move_temp_to_file(tmpfile, filename);
}
+int write_sha1_file(void *buf, unsigned long len, const char *type,
+ unsigned char *returnsha1)
+{
+ return write_sha1_file_core(buf, len, type, 1, returnsha1);
+}
+
+int write_sha1_file_ignore_packs(void *buf, unsigned long len, const char *type,
+ unsigned char *returnsha1)
+{
+ return write_sha1_file_core(buf, len, type, 0, returnsha1);
+}
+
/*
* We need to unpack and recompress the object for writing
* it out to a different file.
--
1.5.2.rc3.726.g279d-dirty
^ permalink raw reply related
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Shawn O. Pearce @ 2007-05-22 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Anand Kumria, git, Johannes Schindelin
In-Reply-To: <7vhcq59yiy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Teach git-describe how to run name-rev
>
> Sorry for a belated question, but is there a reason not to do
> this (on top)?
Nope, I just completely missed it. Please make it so! ;-)
> diff --git a/builtin-describe.c b/builtin-describe.c
> index efbd43f..2a32af6 100644
> --- a/builtin-describe.c
> +++ b/builtin-describe.c
> @@ -283,8 +283,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
> nr[2] = "--tags";
> memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
> nr[3 + argc - i] = NULL;
> - execv_git_cmd(nr);
> - die("unable to start %s", nr[0]);
> + return cmd_name_rev(3 + argc - i, nr, prefix);
> }
>
> if (argc <= i)
>
--
Shawn.
^ permalink raw reply
* Re: [PATCH] rename dirlink to gitlink.
From: Junio C Hamano @ 2007-05-22 6:19 UTC (permalink / raw)
To: Martin Waitz; +Cc: Torgil Svensson, git
In-Reply-To: <20070522055939.GG5412@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> hoi :)
>
> On Mon, May 21, 2007 at 04:32:51PM -0700, Junio C Hamano wrote:
>> As an internal symbol, S_IFDIRLNK makes _much_ more sense than
>> S_IFGITLINK, exactly because it is a mixture of S_IFDIR and
>> S_IFLNK.
>
> But then we also should be consequent and rename the entire
> low-level plumbing to dirlink. I don't see a reason to keep
> both.
Ok. Let's do that then before it is too late.
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Shawn O. Pearce @ 2007-05-22 6:30 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46528A48.9050903@gmail.com>
Dana How <danahow@gmail.com> wrote:
...
> 7 packfiles of 12.5GB total (--window=0 and --depth=0 were
> used due to runtime limits). When using these packfiles,
...
> Repacking the entire repository with a max-blob-size of 256KB
> resulted in a single 13.1MB packfile, as well as 2853 loose
> objects totaling 15.4GB compressed and 100.08GB uncompressed,
> 11 files per objects/xx directory on average. All was created
> in half the runtime of the previous yet with standard
> --window=10 and --depth=50 parameters. The data in the
> packfile was 270MB uncompressed in 35976 blobs. Operations
> such as "git-log --pretty=oneline" were about 30X faster
> on a cold cache and 2 to 3X faster otherwise. Process sizes
> remained reasonable.
Can you give me details about your system? Is this a 64 bit binary?
What is your core.packedGitWindowSize and core.packedGitLimit set to?
It sounds like the packed version was almost 3 GiB smaller, but
was slower because we were mmap'ing far too much data at startup
and that was making your OS page in things that you didn't really
need to have.
Mind trying git-log with a smaller core.packedGitWindow{Size,Limit}?
Perhaps its just as simple as our defaults are far far too high for
your workload...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add ability to specify environment extension to run_command
From: Junio C Hamano @ 2007-05-22 6:33 UTC (permalink / raw)
To: Martin Waitz; +Cc: Alex Riesen, git, Sven Verdoolaege
In-Reply-To: <20070522060302.GH5412@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Mon, May 21, 2007 at 04:02:42PM -0700, Junio C Hamano wrote:
>> I had a feeling that some callers needed to be able to unsetenv
>> some. How would this patch help them, or are they outside of
>> the scope?
>
> At first I had the same objection but the putenv documentation
> told me that at least in glibc you can unsetenv by providing
> the variable name without a "=".
I recall SysV putenv() does not remove "ENVNAME" without '=', and
http://www.opengroup.org/onlinepubs/000095399/functions/putenv.html
seems to say that as well.
> But perhaps we should check for other systems?
Probably.
At least we have setenv/unsetenv calls already (with emulation
where they aren't available), we could do something like this:
struct child_process {
...
const struct {
const char *name;
const char *value; /* NULL to unsetenv */
} *env;
...
};
and in start_command():
if (cmd->env) {
int i;
for (i = 0; cmd->env[i].name; i++) {
if (cmd->env[i].value)
setenv(cmd->env[i].name, cmd->env[i].value, 1);
else
unsetenv(cmd->env[i].name);
}
}
^ permalink raw reply
* Re: [PATCH] Add ability to specify environment extension to run_command
From: Shawn O. Pearce @ 2007-05-22 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Alex Riesen, git, Sven Verdoolaege
In-Reply-To: <7v646l9xkn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > On Mon, May 21, 2007 at 04:02:42PM -0700, Junio C Hamano wrote:
> >> I had a feeling that some callers needed to be able to unsetenv
> >> some. How would this patch help them, or are they outside of
> >> the scope?
> >
> > At first I had the same objection but the putenv documentation
> > told me that at least in glibc you can unsetenv by providing
> > the variable name without a "=".
>
> I recall SysV putenv() does not remove "ENVNAME" without '=', and
> http://www.opengroup.org/onlinepubs/000095399/functions/putenv.html
> seems to say that as well.
Are we overbuilding this thing?
I thought this thread all started because we wanted to run a
command in a subproject, and did not want the parent's GIT_*
environment variables to confuse the subproject process when
it started. That's a pretty simple concept: clear any GIT_*
environment variable that can change behavior in the subproject.
And almost everyone who is trying to use this API and alter the
env wants exactly that - a subproject command.
--
Shawn.
^ permalink raw reply
* Re: problem with import-tars?
From: Joshua N Pritikin @ 2007-05-22 6:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705211441310.6410@racer.site>
On Mon, May 21, 2007 at 02:43:33PM +0100, Johannes Schindelin wrote:
> On Mon, 21 May 2007, Joshua N Pritikin wrote:
> > I ran the import-tars which comes with 1:1.5.1.1-1 (Debian). I checked
> > out the import-tars branch but now I can't commit:
>
> I think that the bug you experienced is solved in 1.5.2.
Indeed, I confirm that the problem is fixed.
You guys rock!
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Junio C Hamano @ 2007-05-22 6:52 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <46528A48.9050903@gmail.com>
Dana How <danahow@gmail.com> writes:
> Using fast-import and repack with the max-pack-size patch,
> 3628 commits were imported from Perforce comprising
> 100.35GB (uncompressed) in 38829 blobs, and saved in
> 7 packfiles of 12.5GB total (--window=0 and --depth=0 were
> used due to runtime limits). When using these packfiles,
> several git commands showed very large process sizes,
> and some slowdowns (compared to comparable operations
> on the linux kernel repo) were also apparent.
>
> git stores data in loose blobs or in packfiles. The former
> has essentially now become an exception mechanism, to store
> exceptionally *young* blobs. Why not use this to store
> exceptionally *large* blobs as well? This allows us to
> re-use all the "exception" machinery with only a small change.
Well, I had an impression that mmapping a single loose object
(and then munmapping it after done) would be more expensive than
mmapping a whole pack and accessing that object through window,
as long as you touch the same set of objects and the object in
the pack is not deltified.
> Repacking the entire repository with a max-blob-size of 256KB
> resulted in a single 13.1MB packfile, as well as 2853 loose
> objects totaling 15.4GB compressed and 100.08GB uncompressed,
> 11 files per objects/xx directory on average. All was created
> in half the runtime of the previous yet with standard
> --window=10 and --depth=50 parameters. The data in the
> packfile was 270MB uncompressed in 35976 blobs. Operations
> such as "git-log --pretty=oneline" were about 30X faster
> on a cold cache and 2 to 3X faster otherwise. Process sizes
> remained reasonable.
I think more reasonable comparison to figure out what is really
going on would be to create such a pack with the same 0/0 window
and depth (i.e. "keeping the huge objects out of the pack" would
be the only difference with the "horrible" case). With huge
packs, I wouldn't be surprised if seeking to extract base object
from a far away part of a packfile takes a lot longer than
reading delta and applying the delta to base object that is kept
in the in-core delta base cache.
Also if you mean by "process size" the total VM size, not RSS, I
think it is a wrong measure. As long as you do not touch the
rest of the pack, even if you mmap a huge packfile, you would
not bring that much data actually into your main memory, would
you? Well, assuming that your mmap() implementation and virtual
memory subsystem does a descent job... maybe we are spoiled by
Linux here...
^ permalink raw reply
* Re: [PATCH] Add ability to specify environment extension to run_command
From: Sven Verdoolaege @ 2007-05-22 6:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Martin Waitz, Alex Riesen, git
In-Reply-To: <20070522063821.GE11636@spearce.org>
On Tue, May 22, 2007 at 02:38:22AM -0400, Shawn O. Pearce wrote:
> I thought this thread all started because we wanted to run a
> command in a subproject, and did not want the parent's GIT_*
> environment variables to confuse the subproject process when
> it started. That's a pretty simple concept: clear any GIT_*
> environment variable that can change behavior in the subproject.
> And almost everyone who is trying to use this API and alter the
> env wants exactly that - a subproject command.
This would work for me, I suppose.
Right now, I sometimes set GIT_DIR explicitly, but I could just chdir
(or use --git-dir=).
skimo
^ permalink raw reply
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Dana How @ 2007-05-22 7:01 UTC (permalink / raw)
To: Martin Koegler; +Cc: git, Junio C Hamano, danahow
In-Reply-To: <20070521175950.GA13818@auto.tuwien.ac.at>
On 5/21/07, Martin Koegler <mkoegler@auto.tuwien.ac.at> wrote:
> On Sun, May 20, 2007 at 09:35:56PM -0700, Dana How wrote:
> > On 5/20/07, Martin Koegler <mkoegler@auto.tuwien.ac.at> wrote:
> > > This patch adds support for caching deltas from the deltifing phase, so
> > > that that the writing phase is faster.
> > >
> > > The caching is limited to small deltas to avoid increasing memory usage
> > > very much.
> > > The implemented limit is (memory needed to create the delta)/1024.
> >
> > Your limit is applied per-object, and there is no overall limit
> > on the amount of memory not freed in the delta phase.
> > I suspect this caching would be disastrous for the large repo
> > with "megablobs" I'm trying to wrestle with at the moment.
>
> http://www.spinics.net/lists/git/msg31241.html:
> > At the moment I'm experimenting on a git repository with
> > a 4.5GB checkout, and 18 months of history in 4K commits
> > comprising 100GB (uncompressed) of blobs stored in
> > 7 packfiles of 2GB or less. Hopefully I'll be able to say
> > more about tweaking packing shortly.
>
> I you have 100 GB of uncompressed data in your pack files, the cache
> limit is between 100MB and 200MB with the current policy.
Yes, there is an implicit limit in your patch, and it would be
sufficient in my case. It's still the case that there is no absolute
limit, but perhaps you have to do something truly insane
for that to matter.
> The aim of my patch is to speed up pack writing without increasing
> memory usage very much, if you have blobs of some hundred MB size in
> your repository.
>
> The caching policy could be extended to speed more memory on caching
> other deltas. Ideas on this topic are welcome.
There _is_ something useful in your patch.
Unfortunately I don't think it helps my problem that much.
> PS: If you are trying to optimize packing speed/size, you could test
> the following patch: http://marc.info/?l=git&m=117908942525171&w=2
I remember this post -- I hope you continue to refine it.
What I've concluded is that there are cases where the packfile
treatment is just not appropriate for some part of the data.
[NOTE: I'm talking about disk storage here, not packs for communications.]
With the "delta" attribute Junio proposed, and the "repack"
attribute I proposed in response, we were starting to move in that
direction already.
The order of objects in the packfile(s) in my test repo after repacking
seems to be commit+ [ tree+ blob+ ]+, in other words, the commits
are all at the beginning and the new tree blobs are interspersed amongst
the data blobs (this was imported with only straightline history, no branching).
If some of these blobs are enormous, the tree blobs which are accessed
all the time get pushed apart. This seemed to really hurt performance.
If I simply refuse to insert enormous blobs in the packfiles, and keep
them loose, the performance is better. More importantly, my packfiles
are now sized like everyone else's, so I'm in an operating regime which
everyone is testing and optimizing. This was not true with 12GB+ of packfiles.
Of course, loose objects are slower, but slight extra overhead to access
something large enough to be noticeable already doesn't bother me.
Finally, loose objects don't get deltified. This is a problem, but I would
need to repack at least every week, and nonzero window/depth would
be prohibitive with large objects included. So if I put the large objects
in the packs, not only are the large objects still undeltified, but everything
else is undeltified as well. Note also that Perforce, what we're currently
using, doesn't deltify large objects either, so people here who migrate
to git aren't going to lose anything, but they will gain compression
on the remaining "normal" objects (Perforce uses deltification or compression,
but not both).
So at the moment I'm finding keeping enormous objects loose
to be a reasonable compromise which keeps my packfiles
"normal" and imposes overheads only on objects whose size
already imposes an even larger overhead.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-22 7:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <20070522063050.GD11636@spearce.org>
On 5/21/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Dana How <danahow@gmail.com> wrote:
> > ... Operations
> > such as "git-log --pretty=oneline" were about 30X faster
> > on a cold cache and 2 to 3X faster otherwise. Process sizes
> > remained reasonable.
>
> Can you give me details about your system? Is this a 64 bit binary?
RHEL4/Nahant on an Opteron. Yes.
> What is your core.packedGitWindowSize and core.packedGitLimit set to?
I didn't change the default.
> It sounds like the packed version was almost 3 GiB smaller, but
> was slower because we were mmap'ing far too much data at startup
> and that was making your OS page in things that you didn't really
> need to have.
The difference in size is because of the "Custom compression levels"
patch -- now the loose objects use Z_BEST_SPEED, whereas the packs
use Z_DEFAULT_COMPRESSION.
> Mind trying git-log with a smaller core.packedGitWindow{Size,Limit}?
> Perhaps its just as simple as our defaults are far far too high for
> your workload...
I think that's a good idea and it should be easy to try tomorrow.
It will improve the cold cache case definitely.
But we need to consider both *read* and *creation* performance.
The portion of the repo I imported to git grows at about 500MB/week
(compressed). Should I repack -a every week? Every month? In any case,
should I use default window/depth, or 0/0? If default, run-times are
prohibitive (in fact, I've always killed each attempt so the machine
could be used for "real" work), and if 0/0, then I lose deltification
on all objects.
These megablobs really are outliers and stress the "one size fits
all" approach of packing in git. As a thought experiment,
let's (1) pretend git-repack takes --max-blob-size= and --max-pack-size= ,
(2) pretend the patch doesn't add the repack.maxblobsize variable,
and (3) do the following:
% git-repack -a -d --max-blob-size=256
% git-repack --max-pack-size=2047 --window=0 --depth=0
The first step makes a digestible 13MB packfile, and the second
puts all the megablobs in 6+ 2GB packfiles. Is there really any
advantage to carrying out the second step? If I'm processing
a 100MB+ blob, do I really care about an extra open(2) call?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-22 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7vtzu58i4c.fsf@assigned-by-dhcp.cox.net>
On 5/21/07, Junio C Hamano <junkio@cox.net> wrote:
> Dana How <danahow@gmail.com> writes:
> > git stores data in loose blobs or in packfiles. The former
> > has essentially now become an exception mechanism, to store
> > exceptionally *young* blobs. Why not use this to store
> > exceptionally *large* blobs as well? This allows us to
> > re-use all the "exception" machinery with only a small change.
> Well, I had an impression that mmapping a single loose object
> (and then munmapping it after done) would be more expensive than
> mmapping a whole pack and accessing that object through window,
> as long as you touch the same set of objects and the object in
> the pack is not deltified.
I agree with your comparison. However, if I'm processing a 100MB+
blob, I doubt the extra open/mmap/munmap/close calls are going
to matter to me. What I think _helped_ me was that, with the megablobs
pushed out of the pack, git-log etc could play around inside a
"tiny" 13MB packfile very quickly. This packfile contained all the
commits, all the trees, and all the blobs < 256KB.
> > Repacking the entire repository with a max-blob-size of 256KB
> > resulted in a single 13.1MB packfile, as well as 2853 loose
> > objects totaling 15.4GB compressed and 100.08GB uncompressed,
> > 11 files per objects/xx directory on average. All was created
> > in half the runtime of the previous yet with standard
> > --window=10 and --depth=50 parameters. The data in the
> > packfile was 270MB uncompressed in 35976 blobs. Operations
> > such as "git-log --pretty=oneline" were about 30X faster
> > on a cold cache and 2 to 3X faster otherwise. Process sizes
> > remained reasonable.
>
> I think more reasonable comparison to figure out what is really
> going on would be to create such a pack with the same 0/0 window
> and depth (i.e. "keeping the huge objects out of the pack" would
> be the only difference with the "horrible" case). With huge
> packs, I wouldn't be surprised if seeking to extract base object
> from a far away part of a packfile takes a lot longer than
> reading delta and applying the delta to base object that is kept
> in the in-core delta base cache.
Yes, changing only one variable at a time would be better.
I will do that experiment. However, the huge pack _did_ have
0/0, and the small pack had default/default, which I think is the
reverse of what you concluded above?, so the experiment should
make things no better for the huge pack case.
> Also if you mean by "process size" the total VM size, not RSS, I
> think it is a wrong measure. As long as you do not touch the
> rest of the pack, even if you mmap a huge packfile, you would
> not bring that much data actually into your main memory, would
> you? Well, assuming that your mmap() implementation and virtual
> memory subsystem does a descent job... maybe we are spoiled by
> Linux here...
You are right that the VM number was more shocking, but both
were too high. But let's compare using 12GB+ of packfiles versus 13MB.
In the former case, I'm depending on the sliding mmap windows doing
the right thing in an operating regime no one uses (which is why
Shawn was asking about my packedGitLimit settings etc), and in the
latter case, the packfile is <10% of the linux2.6 packfile but I have
to endure an extra open/mmap/munmap/close sequence when accessing
enormouse files. The small extra cost of the latter is more attractive
to me than an unknown amount of tuning to get the former right,
and in the former case I still have to figure out how to *create*
the packfiles efficiently.
There's actually an even more extreme example from my day job.
The software team has a project whose files/revisions would be
similar to those in the linux kernel (larger commits, I'm sure).
But they have *ONE* 500MB file they check in because it takes
2 or 3 days to generate and different people use different versions of it.
I'm sure it has 50+ revisions now. If they converted to git and included
these blobs in their packfile, that's a 25GB uncompressed increase!
*Every* git operation must wade through 10X -- 100X more packfile.
Or it could be kept in 50+ loose objects in objects/xx ,
requiring a few extra syscalls by each user to get a new version.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] git-pack-objects: cache small deltas between big objects
From: Junio C Hamano @ 2007-05-22 8:04 UTC (permalink / raw)
To: Dana How; +Cc: Martin Koegler, git, Junio C Hamano
In-Reply-To: <56b7f5510705220001q78b42d08kffd95d25c0af478e@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> If I simply refuse to insert enormous blobs in the packfiles, and keep
> them loose, the performance is better. More importantly, my packfiles
> are now sized like everyone else's, so I'm in an operating regime which
> everyone is testing and optimizing. This was not true with 12GB+ of packfiles.
> Of course, loose objects are slower, but slight extra overhead to access
> something large enough to be noticeable already doesn't bother me.
>
> Finally, loose objects don't get deltified. This is a problem, but I would
> need to repack at least every week, and nonzero window/depth would
> be prohibitive with large objects included.
Here are a few quick comments before going to bed.
* The objects in the packfile are ordered in "recency" order,
as "rev-list --objects" feeds you, so it is correct that we
get trees and blobs mixed. It might be an interesting
experiment, especially with a repository without huge blobs,
to see how much improvement we might get if we keep the
recency order _but_ emit tags, commits, trees, and then
blobs, in this order. In write_pack_file() we have a single
loop to call write_one(), but we could make it a nested loop
that writes only objects of each type.
* Also my earlier "nodelta" attribute thing would be worth
trying with your repository with huge blobs, with the above
"group by object type" with further tweak to write blobs
without "nodelta" marker first and then finally blobs with
"nodelta" marker.
I suspect the above two should help "git log" and "git log --
pathspec..." performance, as these two do not look at blobs at
all (pathspec limiting does invoke diff machinery, but that is
only at the tree level).
The "I want to have packs with reasonable size as everybody
else" (which I think is a reasonable thing to want, but does not
have much technical meaning as other issues do) wish is
something we cannot _measure_ to judge pros and cons, but with
the above experiment, you could come up with three set of packs
such that, all three sets use "nodelta" to leave the huge blobs
undeltified, and use the default window and depth for others,
and:
(1) One set has trees and blobs mixed;
(2) Another set has trees and blobs grouped, but "nodelta" blobs
and others are not separated;
(3) The third set has trees and blobs grouped, and "nodelta"
blobs and others are separated.
Comparing (1) and (2) would show how bad it is to have huge
blobs in between trees (which are presumably accessed more
often). I suspect that comparing (2) and (3) would show that
for most workloads, the split is not worth it.
And compare (3) with another case where you leave "nodelta"
blobs loose. That's the true comparison that would demonstrate
why placing huge blobs in packs is bad and they should be left
loose. I'm skeptical if there will be significant differences,
though.
^ permalink raw reply
* Re: Fwd: Problem: git doesn't update working dir (always) when checkout'ing other branch
From: Andy Parkins @ 2007-05-22 8:04 UTC (permalink / raw)
To: git; +Cc: Stian Haklev
In-Reply-To: <566574ef0705212105k1387cf41n18e076c0bdf47ec6@mail.gmail.com>
On Tuesday 2007 May 22, Stian Haklev wrote:
> git --version > ../file1
Good stuff. The ">" only redirects stdout to file1; stderr would still be
written to your terminal - did you notice any errors from this script? Could
you run again, but append "2>&1" to the end of each redirecting line?
> git status >> ../file1
Seemed fine after this.
> echo checking out works with old >> ../file1
> git checkout works-with-old >> ../file1
Seemed fine after this.
> git status >> ../file1
Seemed fine after this.
> git checkout master >> ../file1
> git status >> ../file1
Kaboom!
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # deleted: NOTES
> # modified: display-page.rb
> # deleted: eee_darwin
> # modified: gui.rb
> # modified: htmlshrinker-data.rb
> # modified: htmlshrinker.rb
> # modified: mongrel-web-gui.rb
> # modified: mongrel-web.rb
> # modified: zarchive.rb
> # new file: zcompress.rb
> # modified: zdump-7z.rb
> # modified: zdump.rb
> # modified: zipdoc.rb
> # deleted: zutil.rb
Wow. I've never seen anything like that. Neither the index nor the working
tree has actually been updated - but HEAD now points at master.
What was the output of that last git-checkout (unfortunately it outputs to
stderr not stdout, so you'll need the "2>&1" at the end of each line in your
script)? git-checkout won't change HEAD unless the change of index and
working tree worked. I can't see the path through the git-checkout script
that would have done what you're describing. I think it's going to need a
guru on this one, however, we'll keep at it until I can't think of any more
questions :-)
Do you observe the same behaviour on all repositories or just this one
particular repository?
What's the form of this repository? That is to say, is works-with-old a
branch from master or is it an independent branch? e.g.
0 -- * -- * -- * (master) 0 -- * -- * -- * (master)
or \
0 -- * -- * -- * (works-with-old) * -- * -- * (works-with-old)
I assume once you get into this broken state that running "git-reset --hard"
restores the working tree back to master?
Does changing that last checkout to "git-checkout -f master" improve things?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git-svn or git problem...
From: Eric Wong @ 2007-05-22 9:16 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86abvylihb.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> wrote:
>
> Hi,
>
> I have used git-svn for checking out the trunk of a large Subversion
> archive. The .git subdirectory now sits in the /rep/texlive/trunk
> directory.
>
> But I actually would now want to have the branches (which are pretty
> small in comparison) available in git as well, without checking the
> whole trunk out again.
> Is there a way to move the .git tracking one directory level upwards
> and get the branches into it as well, without checking out the trunk
> again (the trunk is several Gigabytes of size)?
If you're using a 1.5.1 or later version of git-svn, you can do so
pretty easily by editing your .git/config:
If you already have something like:
[svn-remote "svn"]
# url here is the repository root, and 'mpc/trunk' in fetch
# is the relative path within the repository
url = https://svn.musicpd.org
fetch = mpc/trunk:refs/remotes/git-svn
You can just add the following lines to the config in the above section:
branches = mpc/branches/*:refs/remotes/*
tags = mpc/tags/*:refs/remotes/tags/*
If you have something like:
[svn-remote "svn"]
# url here is the full path of what you're tracking,
url = https://svn.musicpd.org/mpc/trunk
fetch = :refs/remotes/git-svn
Change it to something like in the first example (assuming you
have read permissions to the repository root).
If recompiling SVN is feasible for you and the branches (as a fresh
checkout) are as big as trunk, I highly recommend the do_switch patch
for SVN which lets you transfer only a delta between the branch/tag
point of trunk:
http://svn.haxx.se/dev/archive-2007-01/0936.shtml
--
Eric Wong
^ 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