* Re: jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))
From: Junio C Hamano @ 2013-02-13 0:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20130213001213.GA15246@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> * jn/shell-disable-interactive (2013-02-11) 2 commits
>> - shell: pay attention to exit status from 'help' command
>> - shell doc: emphasize purpose and security model
>>
>> Will merge to 'next'.
>
> Please hold off on merging the second patch. I'd like to reroll
> renaming the command to 'no-interactive-login' or some such, which
> would be less disruptive to existing setups and should be easier to
> explain.
Thanks; that sounds like a sensible and safer change.
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
From: Andrew Ardill @ 2013-02-13 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7v621xdql8.fsf@alter.siamese.dyndns.org>
On 13 February 2013 11:06, Junio C Hamano <gitster@pobox.com> wrote:
> * jc/add-delete-default (2012-08-13) 1 commit
> - git add: notice removal of tracked paths by default
>
> "git add dir/" updated modified files and added new files, but does
> not notice removed files, which may be "Huh?" to some users. They
> can of course use "git add -A dir/", but why should they?
>
> Resurrected from graveyard, as I thought it was a worthwhile thing
> to do in the longer term.
>
> Stalled mostly due to lack of responses.
What do you need to progress this?
I have been bitten by this before (the 'huh?' reaction) and think the
previous discussions and patch look reasonable. Does it need testing?
Further input??
Regards,
Andrew Ardill
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
From: Junio C Hamano @ 2013-02-13 0:34 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451nPKq8DKwo+Bkxh08N-wqrYCY4BihbvaE14z5iGVA1iZw@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> On 13 February 2013 11:06, Junio C Hamano <gitster@pobox.com> wrote:
>> * jc/add-delete-default (2012-08-13) 1 commit
>> - git add: notice removal of tracked paths by default
>>
>> "git add dir/" updated modified files and added new files, but does
>> not notice removed files, which may be "Huh?" to some users. They
>> can of course use "git add -A dir/", but why should they?
>>
>> Resurrected from graveyard, as I thought it was a worthwhile thing
>> to do in the longer term.
>>
>> Stalled mostly due to lack of responses.
>
> What do you need to progress this?
>
> I have been bitten by this before (the 'huh?' reaction) and think the
> previous discussions and patch look reasonable. Does it need testing?
I _think_ the code does what it claims it does; I do not think that
is what is lacking (more testing would not _hurt_, of course).
> Further input??
The updated behaviour is a departure from the traditional norm, and
it would surprise people who do not expect "git add ." to update the
index for removed paths. For many of them, it may be a pleasant
surprise, but "many" is not "all".
The change could negatively affect people who expect that removing
files that are not used for their purpose (e.g. a large file that is
unnecessary for their build) will _not_ affect what they get from
"git add ."; obviously they must have trained themselves not to do
"git add -u" or "git commit -a".
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
From: Andrew Ardill @ 2013-02-13 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7vsj51caqb.fsf@alter.siamese.dyndns.org>
On 13 February 2013 11:34, Junio C Hamano <gitster@pobox.com> wrote:
> The change could negatively affect people who expect that removing
> files that are not used for their purpose (e.g. a large file that is
> unnecessary for their build) will _not_ affect what they get from
> "git add .";
How big a problem is this?
If we need to support this behaviour than I would suppose a config
option is required. A default config transition path similar to git
push defaults would probably work well, in the case where breaking
these expectations is unacceptable.
> obviously they must have trained themselves not to do
> "git add -u" or "git commit -a".
Many people use git add -p by default, so I would not be surprised
about people not using -u or -a.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Git-aware HTTP transport docs
From: H. Peter Anvin @ 2013-02-13 1:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080826012643.GD26523@spearce.org>
Hi Shawn,
You wrote a really great protocol spec for the smart HTTP protocol back
in the day. It would be really great if it could be checked into the
git repository (updated if need be). Someone mentioned today trying to
reverse-engineer the protocol because of a lack of specs, and I was a
bit surprised to day the least.
-hpa
^ permalink raw reply
* Re: Git-aware HTTP transport docs
From: Scott Chacon @ 2013-02-13 2:23 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Shawn O. Pearce, git list
In-Reply-To: <511AED98.5070809@zytor.com>
I don't believe it was ever merged into the Git docs. I have a copy of it here:
https://www.dropbox.com/s/pwawp8kmwgyc3w2/http-protocol.txt
Scott
On Tue, Feb 12, 2013 at 5:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Hi Shawn,
>
> You wrote a really great protocol spec for the smart HTTP protocol back
> in the day. It would be really great if it could be checked into the
> git repository (updated if need be). Someone mentioned today trying to
> reverse-engineer the protocol because of a lack of specs, and I was a
> bit surprised to day the least.
>
> -hpa
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] completion: support 'git config --local'
From: Matthieu Moy @ 2013-02-13 7:44 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Dasa Paddock
In-Reply-To: <20130213000519.GA31758@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So yeah. Matthieu's patch is the right thing to do, as it covers both
Thanks,
> (mine fixed only half of it).
(Sorry, I had missed yours)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Pushing a git repository to a new server
From: Michael J Gruber @ 2013-02-13 8:08 UTC (permalink / raw)
To: Jeff King; +Cc: Ethan Reesor, Konstantin Khomoutov, git
In-Reply-To: <20130212204210.GA25330@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 12.02.2013 21:42:
> On Tue, Feb 12, 2013 at 12:28:53PM +0100, Michael J Gruber wrote:
>
>> I'm not sure providers like GitHub would fancy an interface which allows
>> the programmatic creation of repos (giving a new meaning to "fork
>> bomb"). But I bet you know better ;-)
>
> You can already do that:
>
> http://developer.github.com/v3/repos/#create
Nice.
I knew you knew ;)
> We rate-limit API requests, and I imagine we might do something similar
> with create-over-git. But that is exactly the kind of implementation
> detail that can go into a custom create-repo script.
>
>> An alternative would be to teach git (the client) about repo types and
>> how to create them. After all, a repo URL "ssh://host/path" gives a
>> clear indication that "ssh host git init path" will create a repo.
>
> But that's the point of a microformat. It _doesn't_ always work, because
> the server may not allow arbitrary commands, or may have special
> requirements on top of the "init". You can make the microformat be "git
> init path", and servers can intercept calls to "git init" and translate
> them into custom magic. But I think the world is a little simpler if we
> define a new service type (alongside git-upload-pack, git-receive-pack,
> etc), and let clients request it. Then it's clear what the client is
> trying to do, it's easy for servers to hook into it, we can request it
> over http, etc. And it can be extended over time to take more fields
> (like repo description, etc).
>
> I'm really not suggesting anything drastic. The wrapper case for ssh
> would be as simple as a 3-line shell script which calls "git init" under
> the hood, but it provides one level of indirection that makes
> replacing/hooking it much simpler for servers. So the parts that are in
> stock git would not be much work (most of the work would be on _calling_
> it, but that is the same for adding a call to "git init").
>
> I think the main reason the idea hasn't gone anywhere is that nobody
> really cares _that_ much. People just don't create repositories that
> often. I feel like this is one of those topics that comes up once a
> year, and then nothing happens on it, because people just make their
> repo manually and then stop caring about it.
>
> Just my two cents, of course. :)
Most repos are probably created by a local "git init" or "git clone", or
by clicking a button on a provider's web interface. The need for
git-create-repo seems to be restricted to:
- "command line folks" who use a provider for it's hosting service and
don't fancy a web interface for repo creation
- noobs who need to get their head wrapped around local, remote,
push/pull 'n' stuff...
For the server side git-create-repo to take off we would probably need
two things (besides the client support):
- Implement and ship a git-create-repo which makes this work for git
over ssh seamlessly. (Will take some to trickle down to servers in the
wild.)
- Get a large provider to offer this.
Gitosis/Gitolite are probably to follow easily. I'm beginning to like
idea ;)
Michael
^ permalink raw reply
* [PATCH v4 0/4] count-objects improvements
From: Nguyễn Thái Ngọc Duy @ 2013-02-13 9:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <7va9r9igze.fsf@alter.siamese.dyndns.org>
On Wed, Feb 13, 2013 at 12:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> +/* A hook for count-objects to report invalid files in pack directory */
>> +extern void (*report_garbage)(const char *desc, const char *path, int len, const char *name);
>
> We may want to document the strange way the last three parameters
> are used somewhere. e.g.
>
> shows "path" (if "name" is NULL), or prepends "path" in
> front of name (otherwise); only for the latter, "path" can
> be a string that is not NUL-terminated but its length
> specified with "len" and in that case a slash is inserted
> between the path and the "name".
>
> When described clearly, it sounds somewhat ugly and incoherent API,
> even though it covers the immediate need X-<.
One of the reasons why I did not export it explicitly. Changed it to
void (*report_garbage)(const char *desc, const char *path);
and pushed the ugly part back to callers.
> How about doing it something along this line, perhaps?
>
> int i;
> int beginning_of_this_name = -1;
> int seen_bits = 0; /* 01 for .idx, 02 for .pack */
> for (i = 0; i < list->nr; i++) {
> if (beginning_of_this_name < 0)
> beginning_of_this_name = i;
> else if (list->items[i] and list->items[beginning_of_this_name]
> share the same basename)
> ; /* keep scanning */
> else {
> /* one name ended at (i-1) */
> if (seen_bits == 3)
> ; /* both .idx and .pack exist; good */
> else
> report_garbage_for_one_name(list, beginning_of_this_name, i,
> seen_bits);
> seen_bits = 0;
> beginning_of_this_name = i;
> }
> if (list->items[i] is ".idx")
> seen_bits |= 1;
> if (list->items[i] is ".pack")
> seen_bits |= 2;
>
> }
> if (0 <= beginning_of_this_name && seen_bits != 3)
> report_garbages_for_one_name(list, beginning_of_this_name, list->nr, seen_bits);
>
> with a helper function report_garbage_for_one_name() that would look like this:
>
> report_garbage_for_one_name(...) {
> int j;
> const char *msg;
> switch (seen_bits) {
> case 0: msg = "no corresponding .idx nor .pack"; break;
> case 1: msg = "no corresponding .pack"; break;
> case 2: msg = "no corresponding .idx; break;
> }
> for (j = beginning_of_this_name; j < i; j++)
> report_garbage(msg, list->items[j]);
> }
>
> For the above to work, prepare_packed_git_one() needs to retain only the
> paths with known extensions in garbage list. "pack-deadbeef.unk" can and
> should be reported as a garbage immediately when it is seen without being
> placed in the list.
Yup. Looks good.
>> + } else if (has_extension(de->d_name, ".idx")) {
>> + struct string_list_item *item;
>> + int n = strlen(path) - 4;
>> + item = string_list_append_nodup(&garbage,
>> + xstrndup(path, n));
>> + item->util = ".idx";
>> + continue;
>> + } else
>> + report_garbage("garbage found", path, 0, NULL);
>
> Hmm, where is a ".keep" file handled in this flow?
Apparently I smoked/drank while coding or something. .idx is supposed
to be .keep. This calls for a test to guard my code (part of this v4).
> The structure of the if/else cascade is much nicer than the earlier
> iterations, but wouldn't it be even more clear to do this?
>
> if (is .idx file) {
> ... do that .idx thing ...
> }
>
> if (!report_garbage)
> continue; /* it does not matter what the file is */
>
> if (is .pack) {
> ... remember that we saw this .pack ...
> } else if (is .idx) {
> ... remember that we saw this .idx ...
> } else if (is .keep) {
> ... remember that we saw this .keep ...
> } else {
> ... all else --- report as garbage immediately ...
> }
Done. 2/4 is updated to make sure the "if (is .idx file)" block does
not shortcut the loop with "continue;" so that we always get .idx
file in the end of the loop.
Nguyễn Thái Ngọc Duy (4):
git-count-objects.txt: describe each line in -v output
sha1_file: reorder code in prepare_packed_git_one()
count-objects: report garbage files in pack directory too
count-objects: report how much disk space taken by garbage files
Documentation/git-count-objects.txt | 22 ++++++--
builtin/count-objects.c | 30 ++++++++---
cache.h | 3 ++
sha1_file.c | 101 +++++++++++++++++++++++++++++++-----
t/t5304-prune.sh | 26 ++++++++++
5 files changed, 156 insertions(+), 26 deletions(-)
--
1.8.1.2.536.gf441e6d
^ permalink raw reply
* [PATCH v4 1/4] git-count-objects.txt: describe each line in -v output
From: Nguyễn Thái Ngọc Duy @ 2013-02-13 9:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1360746799-3668-1-git-send-email-pclouds@gmail.com>
The current description requires a bit of guessing (what clause
corresponds to what printed line?) and lacks information, such as
the unit of size and size-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-count-objects.txt | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index 23c80ce..e816823 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -20,11 +20,21 @@ OPTIONS
-------
-v::
--verbose::
- In addition to the number of loose objects and disk
- space consumed, it reports the number of in-pack
- objects, number of packs, disk space consumed by those packs,
- and number of objects that can be removed by running
- `git prune-packed`.
+ Report in more detail:
++
+count: the number of loose objects
++
+size: disk space consumed by loose objects, in KiB
++
+in-pack: the number of in-pack objects
++
+size-pack: disk space consumed by the packs, in KiB
++
+prune-packable: the number of loose objects that are also present in
+the packs. These objects could be pruned using `git prune-packed`.
++
+garbage: the number of files in loose object database that are not
+valid loose objects
GIT
---
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH v4 2/4] sha1_file: reorder code in prepare_packed_git_one()
From: Nguyễn Thái Ngọc Duy @ 2013-02-13 9:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1360746799-3668-1-git-send-email-pclouds@gmail.com>
The current loop does
while (...) {
if (!not .idx file)
continue;
process .idx file;
}
and is reordered to
while (...) {
if (!.idx file) {
process .idx file;
}
}
This makes it easier to add new extension file processing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_file.c | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..239bee7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1024,27 +1024,25 @@ static void prepare_packed_git_one(char *objdir, int local)
int namelen = strlen(de->d_name);
struct packed_git *p;
- if (!has_extension(de->d_name, ".idx"))
- continue;
-
if (len + namelen + 1 > sizeof(path))
continue;
- /* Don't reopen a pack we already have. */
strcpy(path + len, de->d_name);
- for (p = packed_git; p; p = p->next) {
- if (!memcmp(path, p->pack_name, len + namelen - 4))
- break;
+
+ if (has_extension(de->d_name, ".idx")) {
+ /* Don't reopen a pack we already have. */
+ for (p = packed_git; p; p = p->next) {
+ if (!memcmp(path, p->pack_name, len + namelen - 4))
+ break;
+ }
+ if (p == NULL &&
+ /*
+ * See if it really is a valid .idx file with
+ * corresponding .pack file that we can map.
+ */
+ (p = add_packed_git(path, len + namelen, local)) != NULL)
+ install_packed_git(p);
}
- if (p)
- continue;
- /* See if it really is a valid .idx file with corresponding
- * .pack file that we can map.
- */
- p = add_packed_git(path, len + namelen, local);
- if (!p)
- continue;
- install_packed_git(p);
}
closedir(dir);
}
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH v4 3/4] count-objects: report garbage files in pack directory too
From: Nguyễn Thái Ngọc Duy @ 2013-02-13 9:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1360746799-3668-1-git-send-email-pclouds@gmail.com>
prepare_packed_git_one() is modified to allow count-objects to hook a
report function to so we don't need to duplicate the pack searching
logic in count-objects.c. When report_pack_garbage is NULL, the
overhead is insignificant.
The garbage is reported with warning() instead of error() in packed
garbage case because it's not an error to have garbage. Loose garbage
is still reported as errors and will be converted to warnings later.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-count-objects.txt | 4 +-
builtin/count-objects.c | 12 +++++-
cache.h | 3 ++
sha1_file.c | 77 ++++++++++++++++++++++++++++++++++++-
t/t5304-prune.sh | 26 +++++++++++++
5 files changed, 118 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index e816823..1611d7c 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -33,8 +33,8 @@ size-pack: disk space consumed by the packs, in KiB
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
+
-garbage: the number of files in loose object database that are not
-valid loose objects
+garbage: the number of files in object database that are not valid
+loose objects nor valid packs
GIT
---
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 9afaa88..1706c8b 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -9,6 +9,14 @@
#include "builtin.h"
#include "parse-options.h"
+static unsigned long garbage;
+
+static void real_report_garbage(const char *desc, const char *path)
+{
+ warning("%s: %s", desc, path);
+ garbage++;
+}
+
static void count_objects(DIR *d, char *path, int len, int verbose,
unsigned long *loose,
off_t *loose_size,
@@ -76,7 +84,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
const char *objdir = get_object_directory();
int len = strlen(objdir);
char *path = xmalloc(len + 50);
- unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
+ unsigned long loose = 0, packed = 0, packed_loose = 0;
off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(&verbose, N_("be verbose")),
@@ -87,6 +95,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
/* we do not take arguments other than flags for now */
if (argc)
usage_with_options(count_objects_usage, opts);
+ if (verbose)
+ report_garbage = real_report_garbage;
memcpy(path, objdir, len);
if (len && objdir[len-1] != '/')
path[len++] = '/';
diff --git a/cache.h b/cache.h
index 7339f21..73de68c 100644
--- a/cache.h
+++ b/cache.h
@@ -1051,6 +1051,9 @@ extern const char *parse_feature_value(const char *feature_list, const char *fea
extern struct packed_git *parse_pack_index(unsigned char *sha1, const char *idx_path);
+/* A hook for count-objects to report invalid files in pack directory */
+extern void (*report_garbage)(const char *desc, const char *path);
+
extern void prepare_packed_git(void);
extern void reprepare_packed_git(void);
extern void install_packed_git(struct packed_git *pack);
diff --git a/sha1_file.c b/sha1_file.c
index 239bee7..5bedf78 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -21,6 +21,7 @@
#include "sha1-lookup.h"
#include "bulk-checkin.h"
#include "streaming.h"
+#include "dir.h"
#ifndef O_NOATIME
#if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
@@ -1000,6 +1001,57 @@ void install_packed_git(struct packed_git *pack)
packed_git = pack;
}
+void (*report_garbage)(const char *desc, const char *path);
+
+static void report_helper(const struct string_list *list,
+ int seen_bits, int first, int last)
+{
+ const char *msg;
+ switch (seen_bits) {
+ case 0: msg = "no corresponding .idx nor .pack"; break;
+ case 1: msg = "no corresponding .idx"; break;
+ case 2: msg = "no corresponding .pack"; break;
+ default:
+ return;
+ }
+ for (; first <= last; first++)
+ report_garbage(msg, list->items[first].string);
+}
+
+static void report_pack_garbage(struct string_list *list)
+{
+ int i, baselen = -1, first = 0, seen_bits = 0;
+
+ if (!report_garbage)
+ return;
+
+ sort_string_list(list);
+
+ for (i = 0; i < list->nr; i++) {
+ const char *path = list->items[i].string;
+ if (baselen != -1 &&
+ strncmp(path, list->items[first].string, baselen)) {
+ report_helper(list, seen_bits, first, i - 1);
+ baselen = -1;
+ seen_bits = 0;
+ }
+ if (baselen == -1) {
+ const char *dot = strrchr(path, '.');
+ if (!dot) {
+ report_garbage("garbage found", path);
+ continue;
+ }
+ baselen = dot - path + 1;
+ first = i;
+ }
+ if (!strcmp(path + baselen, "pack"))
+ seen_bits |= 1;
+ else if (!strcmp(path + baselen, "idx"))
+ seen_bits |= 2;
+ }
+ report_helper(list, seen_bits, first, list->nr - 1);
+}
+
static void prepare_packed_git_one(char *objdir, int local)
{
/* Ensure that this buffer is large enough so that we can
@@ -1009,6 +1061,7 @@ static void prepare_packed_git_one(char *objdir, int local)
int len;
DIR *dir;
struct dirent *de;
+ struct string_list garbage = STRING_LIST_INIT_DUP;
sprintf(path, "%s/pack", objdir);
len = strlen(path);
@@ -1024,7 +1077,17 @@ static void prepare_packed_git_one(char *objdir, int local)
int namelen = strlen(de->d_name);
struct packed_git *p;
- if (len + namelen + 1 > sizeof(path))
+ if (len + namelen + 1 > sizeof(path)) {
+ if (report_garbage) {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addf(&sb, "%.*s/%s", len - 1, path, de->d_name);
+ report_garbage("path too long", sb.buf);
+ strbuf_release(&sb);
+ }
+ continue;
+ }
+
+ if (is_dot_or_dotdot(de->d_name))
continue;
strcpy(path + len, de->d_name);
@@ -1043,8 +1106,20 @@ static void prepare_packed_git_one(char *objdir, int local)
(p = add_packed_git(path, len + namelen, local)) != NULL)
install_packed_git(p);
}
+
+ if (!report_garbage)
+ continue;
+
+ if (has_extension(de->d_name, ".idx") ||
+ has_extension(de->d_name, ".pack") ||
+ has_extension(de->d_name, ".keep"))
+ string_list_append(&garbage, path);
+ else
+ report_garbage("garbage found", path);
}
closedir(dir);
+ report_pack_garbage(&garbage);
+ string_list_clear(&garbage, 0);
}
static int sort_pack(const void *a_, const void *b_)
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index d645328..e4bb3a1 100755
--- a/t/t5304-prune.sh
+++ b/t/t5304-prune.sh
@@ -195,4 +195,30 @@ test_expect_success 'gc: prune old objects after local clone' '
)
'
+test_expect_success 'garbage report in count-objects -v' '
+ : >.git/objects/pack/foo &&
+ : >.git/objects/pack/foo.bar &&
+ : >.git/objects/pack/foo.keep &&
+ : >.git/objects/pack/foo.pack &&
+ : >.git/objects/pack/fake.bar &&
+ : >.git/objects/pack/fake.keep &&
+ : >.git/objects/pack/fake.pack &&
+ : >.git/objects/pack/fake.idx &&
+ : >.git/objects/pack/fake2.keep &&
+ : >.git/objects/pack/fake3.idx &&
+ git count-objects -v 2>stderr &&
+ grep "index file .git/objects/pack/fake.idx is too small" stderr &&
+ grep "^warning:" stderr | sort >actual &&
+ cat >expected <<\EOF &&
+warning: garbage found: .git/objects/pack/fake.bar
+warning: garbage found: .git/objects/pack/foo
+warning: garbage found: .git/objects/pack/foo.bar
+warning: no corresponding .idx nor .pack: .git/objects/pack/fake2.keep
+warning: no corresponding .idx: .git/objects/pack/foo.keep
+warning: no corresponding .idx: .git/objects/pack/foo.pack
+warning: no corresponding .pack: .git/objects/pack/fake3.idx
+EOF
+ test_cmp expected actual
+'
+
test_done
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH v4 4/4] count-objects: report how much disk space taken by garbage files
From: Nguyễn Thái Ngọc Duy @ 2013-02-13 9:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1360746799-3668-1-git-send-email-pclouds@gmail.com>
Also issue warnings on loose garbages instead of errors as a result of
using report_garbage() function in count_objects()
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-count-objects.txt | 2 ++
builtin/count-objects.c | 18 ++++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index 1611d7c..da6e72e 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -35,6 +35,8 @@ the packs. These objects could be pruned using `git prune-packed`.
+
garbage: the number of files in object database that are not valid
loose objects nor valid packs
++
+size-garbage: disk space consumed by garbage files, in KiB
GIT
---
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 1706c8b..3a01a8d 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -10,9 +10,13 @@
#include "parse-options.h"
static unsigned long garbage;
+static off_t size_garbage;
static void real_report_garbage(const char *desc, const char *path)
{
+ struct stat st;
+ if (!stat(path, &st))
+ size_garbage += st.st_size;
warning("%s: %s", desc, path);
garbage++;
}
@@ -20,8 +24,7 @@ static void real_report_garbage(const char *desc, const char *path)
static void count_objects(DIR *d, char *path, int len, int verbose,
unsigned long *loose,
off_t *loose_size,
- unsigned long *packed_loose,
- unsigned long *garbage)
+ unsigned long *packed_loose)
{
struct dirent *ent;
while ((ent = readdir(d)) != NULL) {
@@ -54,9 +57,11 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
}
if (bad) {
if (verbose) {
- error("garbage found: %.*s/%s",
- len + 2, path, ent->d_name);
- (*garbage)++;
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addf(&sb, "%.*s/%s",
+ len + 2, path, ent->d_name);
+ report_garbage("garbage found", sb.buf);
+ strbuf_release(&sb);
}
continue;
}
@@ -107,7 +112,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
if (!d)
continue;
count_objects(d, path, len, verbose,
- &loose, &loose_size, &packed_loose, &garbage);
+ &loose, &loose_size, &packed_loose);
closedir(d);
}
if (verbose) {
@@ -132,6 +137,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
printf("prune-packable: %lu\n", packed_loose);
printf("garbage: %lu\n", garbage);
+ printf("size-garbage: %lu\n", (unsigned long) (size_garbage / 1024));
}
else
printf("%lu objects, %lu kilobytes\n",
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-13 10:06 UTC (permalink / raw)
To: blees
Cc: kusmabite, Ramkumar Ramachandra, Robert Zeh, Junio C Hamano,
Git List, finnag
In-Reply-To: <511AAA92.4030508@gmail.com>
On Tue, Feb 12, 2013 at 09:48:18PM +0100, Karsten Blees wrote:
> However, the difference between git status -uall and -uno was always
> about 1.3 s in all fscache versions, even though
> opendir/readdir/closedir was served entirely from the cache. I added
> a bit of performance tracing to find the cause, and I think most of
> the time spent in wt_status_collect_untracked can be eliminated:
>
> 1.) 0.939 s is spent in dir.c/excluded (i.e. checking
> .gitignore). This check is done for *every* file in the working
> copy, including files in the index. Checking the index first could
> eliminate most of that, i.e.:
>
> (Note: patches are for discussion only, I'm aware that they may have
> unintended side effects...)
>
> @@ -1097,6 +1097,8 @@ static enum path_treatment treat_path(struct dir_struct *dir,
> return path_ignored;
> strbuf_setlen(path, baselen);
> strbuf_addstr(path, de->d_name);
> + if (cache_name_exists(path->buf, path->len, ignore_case))
> + return path_ignored;
> if (simplify_away(path->buf, path->len, simplify))
> return path_ignored;
The below patch passes the test suite for me and still does the same
thing. On my Linux box, running "git status" on gentoo-x86.git with
this patch saves 0.05s (0.548s without the patch, 0.505s with the
patch, best number of 20 runs).
And I just realized gentoo-x86.git does not have any .gitignore. On
webkit.git, it cuts "git status" time from 1.121s down to
0.762s. Unless I'm mistaken, "git add" should have the same benefit on
normal case too. Good finding!
-- 8< --
diff --git a/dir.c b/dir.c
index 57394e4..4b4cf60 100644
--- a/dir.c
+++ b/dir.c
@@ -1244,7 +1244,19 @@ static enum path_treatment treat_one_path(struct dir_struct *dir,
const struct path_simplify *simplify,
int dtype, struct dirent *de)
{
- int exclude = is_excluded(dir, path->buf, &dtype);
+ int exclude;
+
+ if (dtype == DT_UNKNOWN)
+ dtype = get_dtype(de, path->buf, path->len);
+
+ if (!(dir->flags & DIR_SHOW_IGNORED) &&
+ !(dir->flags & DIR_COLLECT_IGNORED) &&
+ dtype == DT_REG &&
+ cache_name_exists(path->buf, path->len, ignore_case))
+ return path_ignored;
+
+ exclude = is_excluded(dir, path->buf, &dtype);
+
if (exclude && (dir->flags & DIR_COLLECT_IGNORED)
&& exclude_matches_pathspec(path->buf, path->len, simplify))
dir_add_ignored(dir, path->buf, path->len);
@@ -1256,9 +1268,6 @@ static enum path_treatment treat_one_path(struct dir_struct *dir,
if (exclude && !(dir->flags & DIR_SHOW_IGNORED))
return path_ignored;
- if (dtype == DT_UNKNOWN)
- dtype = get_dtype(de, path->buf, path->len);
-
switch (dtype) {
default:
return path_ignored;
-- 8< --
^ permalink raw reply related
* [PATCH v2 0/3] Add bash.showUntrackedFiles config option
From: Martin Erik Werner @ 2013-02-13 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, trsten
In-Reply-To: <7vr4kldv2x.fsf@alter.siamese.dyndns.org>
On Tue, 2013-02-12 at 14:29 -0800, Junio C Hamano wrote:
> Martin Erik Werner <martinerikwerner@gmail.com> writes:
>
> > Add a test case for the bash.showUntrackedFiles config option, which
> > checks that the config option can disable the global effect of the
> > GIT_PS1_SHOWUNTRACKEDFILES environmant variable.
> >
> > Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
> > ---
> > t/t9903-bash-prompt.sh | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
> > index f17c1f8..c9417b9 100755
> > --- a/t/t9903-bash-prompt.sh
> > +++ b/t/t9903-bash-prompt.sh
> > @@ -447,6 +447,17 @@ test_expect_success 'prompt - untracked files status indicator - not shown insid
> > test_cmp expected "$actual"
> > '
> >
> > +test_expect_success 'prompt - untracked files status indicator - disabled by config' '
> > + printf " (master)" > expected &&
> > + echo "untracked" > file_untracked &&
> > + test_config bash.showUntrackedFiles false &&
> > + (
> > + GIT_PS1_SHOWUNTRACKEDFILES=y &&
> > + __git_ps1 > "$actual"
> > + ) &&
> > + test_cmp expected "$actual"
> > +'
>
> All six combinations need checking:
>
> * not having the configuration at all and not having the shell
> variable should not show the untracked indicator (already tested).
>
> * not having the configuration at all and having the shell variable
> should show the untracked indicator (already tested).
>
> * setting configuration to true without having the shell variable
> should not show the untracked indicator.
>
> * setting configuration to true and having the shell variable
> should show the unttracked indicator.
>
> * setting configuration to false and having the shell variable
> should not show the untracked indicator (the above test checks
> this).
>
> * setting configuration to false without having the shell variable
> should not show the untracked indicator.
>
> to prevent others from breaking the code you wrote for [PATCH 1/2],
> so you need three more tests, I guess?
Ah, yes, I was mimicing what the test did for bash.showDirtyState, I've
now added the three extra tests for bash.showUntrackedFiles, which
should cover all of the above cases, hopefully?
I've also added in the three extra tests for bash.showDirtyState,
equivalently. These only cover the case of dirty files and not
combinations with content in index, which I felt was a bit overkill, is
that reasonable?
Thanks for the review :)
--
Martin Erik Werner <martinerikwerner@gmail.com>
^ permalink raw reply
* [PATCH v2 1/3] shell prompt: add bash.showUntrackedFiles option
From: Martin Erik Werner @ 2013-02-13 11:01 UTC (permalink / raw)
To: gitster; +Cc: git, trsten, Martin Erik Werner
In-Reply-To: <1360753138.25490.10.camel@mas>
Add a config option 'bash.showUntrackedFiles' which allows enabling
the prompt showing untracked files on a per-repository basis. This is
useful for some repositories where the 'git ls-files ...' command may
take a long time.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
---
contrib/completion/git-prompt.sh | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9bef053..9b2eec2 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -43,7 +43,10 @@
#
# If you would like to see if there're untracked files, then you can set
# GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there're untracked
-# files, then a '%' will be shown next to the branch name.
+# files, then a '%' will be shown next to the branch name. You can
+# configure this per-repository with the bash.showUntrackedFiles
+# variable, which defaults to true once GIT_PS1_SHOWUNTRACKEDFILES is
+# enabled.
#
# If you would like to see the difference between HEAD and its upstream,
# set GIT_PS1_SHOWUPSTREAM="auto". A "<" indicates you are behind, ">"
@@ -332,8 +335,10 @@ __git_ps1 ()
fi
if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ -n "$(git ls-files --others --exclude-standard)" ]; then
- u="%"
+ if [ "$(git config --bool bash.showUntrackedFiles)" != "false" ]; then
+ if [ -n "$(git ls-files --others --exclude-standard)" ]; then
+ u="%"
+ fi
fi
fi
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/3] t9903: add tests for bash.showUntrackedFiles
From: Martin Erik Werner @ 2013-02-13 11:01 UTC (permalink / raw)
To: gitster; +Cc: git, trsten, Martin Erik Werner
In-Reply-To: <1360753321-5002-1-git-send-email-martinerikwerner@gmail.com>
Add 4 test for the bash.showUntrackedFiles config option, covering all
combinations of the shell var being set/unset and the config option
being enabled/disabled.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
---
t/t9903-bash-prompt.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index f17c1f8..cb008e2 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -437,6 +437,46 @@ test_expect_success 'prompt - untracked files status indicator - untracked files
test_cmp expected "$actual"
'
+test_expect_success 'prompt - untracked files status indicator - shell variable unset with config disabled' '
+ printf " (master)" > expected &&
+ test_config bash.showUntrackedFiles false &&
+ (
+ unset -v GIT_PS1_SHOWUNTRACKEDFILES &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - untracked files status indicator - shell variable unset with config enabled' '
+ printf " (master)" > expected &&
+ test_config bash.showUntrackedFiles true &&
+ (
+ unset -v GIT_PS1_SHOWUNTRACKEDFILES &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - untracked files status indicator - shell variable set with config disabled' '
+ printf " (master)" > expected &&
+ test_config bash.showUntrackedFiles false &&
+ (
+ GIT_PS1_SHOWUNTRACKEDFILES=y &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - untracked files status indicator - shell variable set with config enabled' '
+ printf " (master %%)" > expected &&
+ test_config bash.showUntrackedFiles true &&
+ (
+ GIT_PS1_SHOWUNTRACKEDFILES=y &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
test_expect_success 'prompt - untracked files status indicator - not shown inside .git directory' '
printf " (GIT_DIR!)" > expected &&
(
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 3/3] t9903: add extra tests for bash.showDirtyState
From: Martin Erik Werner @ 2013-02-13 11:02 UTC (permalink / raw)
To: gitster; +Cc: git, trsten, Martin Erik Werner
In-Reply-To: <1360753321-5002-1-git-send-email-martinerikwerner@gmail.com>
Added 3 extra tests for the bash.showDirtyState config option, tests
should now cover all combinations of the shell var being set/unset and
the config option being enabled/disabled, given a dirty file.
* Renamed test 'disabled by config' to 'shell variable set with config
disabled' for consistency
---
t/t9903-bash-prompt.sh | 38 +++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index cb008e2..fa81b09 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -360,12 +360,48 @@ test_expect_success 'prompt - dirty status indicator - before root commit' '
test_cmp expected "$actual"
'
-test_expect_success 'prompt - dirty status indicator - disabled by config' '
+test_expect_success 'prompt - dirty status indicator - shell variable unset with config disabled' '
printf " (master)" > expected &&
echo "dirty" > file &&
test_when_finished "git reset --hard" &&
test_config bash.showDirtyState false &&
(
+ unset -v GIT_PS1_SHOWDIRTYSTATE &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - dirty status indicator - shell variable unset with config enabled' '
+ printf " (master)" > expected &&
+ echo "dirty" > file &&
+ test_when_finished "git reset --hard" &&
+ test_config bash.showDirtyState true &&
+ (
+ unset -v GIT_PS1_SHOWDIRTYSTATE &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - dirty status indicator - shell variable set with config disabled' '
+ printf " (master)" > expected &&
+ echo "dirty" > file &&
+ test_when_finished "git reset --hard" &&
+ test_config bash.showDirtyState false &&
+ (
+ GIT_PS1_SHOWDIRTYSTATE=y &&
+ __git_ps1 > "$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - dirty status indicator - shell variable set with config enabled' '
+ printf " (master *)" > expected &&
+ echo "dirty" > file &&
+ test_when_finished "git reset --hard" &&
+ test_config bash.showDirtyState true &&
+ (
GIT_PS1_SHOWDIRTYSTATE=y &&
__git_ps1 > "$actual"
) &&
--
1.7.10.4
^ permalink raw reply related
* Re: A good Git technique for referring back to original files
From: MikeW @ 2013-02-13 11:44 UTC (permalink / raw)
To: git
In-Reply-To: <CALeLG_nFgApPT1B+6sPy7P+jrtjB4KQOBpPO9bEd0rsWKqWi8A@mail.gmail.com>
Paul Campbell <pcampbell <at> kemitix.net> writes:
>
> Hi Mike,
>
> I think git-cvsimport and git-subtree could help you here.
>
That looks very interesting, had not considered git subtree and it looks like
the right kind of method.
Thanks.
Mike
> Hope that helps.
>
> --
> Paul
>
... Super-Snip ...
>
> --
> Paul [W] Campbell
>
^ permalink raw reply
* Re: [git-multimail] License unknown (#1)
From: Michael Haggerty @ 2013-02-13 12:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: git discussion list, Michiel Holtkamp, mhagger/git-multimail
In-Reply-To: <201302121528.07961.andyparkins@gmail.com>
On 02/12/2013 04:28 PM, Andy Parkins wrote:
> On Sunday 27 January 2013 18:52:58 Michael Haggerty wrote:
>> I have a question about the license of contrib/hooks/post-commit-email.
>> [...]
>
> Keeping up with the git mailing list got a bit much, [...]
Very understandable :-)
> My apologies to everyone; I've been lax supporting the script -- I never
> really expected it to be as widely used as it has been, I was always expecting
> someone would come along and replace it so I'm pleased that Michael has done
> so (although it's a little disheartening to read of it being called "hacky",
> when I tried very hard to make it as clear and modular as I could).
FWIW I think the script was quite well-structured (within the
limitations of shell scripting anyway) and I had no problem
understanding it and translating it to Python.
>> If somebody can explain what license the code is under and how they come
>> to that conclusion, I would be very grateful.
>>
>> And if Andy Parkins (the original author) is listening, please indicate
>> whether you had any intent *other* than GPLv2.
>
> I intended it to be under the same license as Git. I had read in one of the
> patch submission files (which I can't seem to find now) that all submissions
> were considered part of git.
Thanks. Given that you submitted the original version under GPLv2, and
later contributors certainly had no reason to assume any *other*
license, I think any reasonable person will be satisfied that the whole
script in its current form is under GPLv2.
> If an explicit declaration is needed, I am happy to give it. Let me know what
> form this should take and I'll supply it.
Personally, I am satisfied by your email statement. I will leave the
derived work, git-multimail, also under GPLv2. Assuming that
git-multimail supersedes yours, its explicit choice of license will make
the situation clear for future users.
Thanks!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-13 12:15 UTC (permalink / raw)
To: blees
Cc: kusmabite, Ramkumar Ramachandra, Robert Zeh, Junio C Hamano,
Git List, finnag, Jeff King
In-Reply-To: <511AAA92.4030508@gmail.com>
On Wed, Feb 13, 2013 at 3:48 AM, Karsten Blees <karsten.blees@gmail.com> wrote:
> 2.) 0.135 s is spent in name-hash.c/hash_index_entry_directories, reindexing the same directories over and over again. In the end, the hashtable contains 939k directory entries, even though the WebKit test repo only has 7k directories. Checking if a directory entry already exists could reduce that, i.e.:
This function is only used when core.ignorecase = true. I probably
won't be able to test this, so I'll leave this to other people who
care about ignorecase.
This function used to have lookup_hash, but it was removed by Jeff in
2548183 (fix phantom untracked files when core.ignorecase is set -
2011-10-06). There's a looong commit message which I'm too lazy to
read. Anybody who works on this should though.
> @@ -53,14 +55,23 @@ static void hash_index_entry_directories(struct index_state *istate, struct cach
> unsigned int hash;
> void **pos;
> double t = ticks();
> + struct cache_entry *ce2;
> + int len = ce_namelen(ce);
>
> - const char *ptr = ce->name;
> - while (*ptr) {
> - while (*ptr && *ptr != '/')
> - ++ptr;
> - if (*ptr == '/') {
> - ++ptr;
> - hash = hash_name(ce->name, ptr - ce->name);
> + while (len > 0) {
> + while (len > 0 && ce->name[len - 1] != '/')
> + len--;
> + if (len > 0) {
> + hash = hash_name(ce->name, len);
> + ce2 = lookup_hash(hash, &istate->name_hash);
> + while (ce2) {
> + if (same_name(ce2, ce->name, len, ignore_case)) {
> + add_since(t, &hash_dirs);
> + return;
> + }
> + ce2 = ce2->dir_next;
> + }
> + len--;
> pos = insert_hash(hash, ce, &istate->name_hash);
> if (pos) {
> ce->dir_next = *pos;
--
Duy
^ permalink raw reply
* Recommended packing for HTTP repositories
From: Robert Clausecker @ 2013-02-13 12:38 UTC (permalink / raw)
To: git
Hello!
I provide dumb HTTP access to a git repository on a server where I can't
enable the smart HTTP protocol. When the history of the repository
grows, should I run git repack to pack all revisions together? Would
that cause clients that just want to download a few commit to download
the whole pack? What is recommended to do?
Yours, Robert Clausecker
^ permalink raw reply
* Re: A good Git technique for referring back to original files
From: MikeW @ 2013-02-13 12:50 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20130213T123734-484@post.gmane.org>
MikeW <mw_phil <at> yahoo.co.uk> writes:
>
> Paul Campbell <pcampbell <at> kemitix.net> writes:
>
> >
> > Hi Mike,
> >
> > I think git-cvsimport and git-subtree could help you here.
> >
>
> That looks very interesting, had not considered git subtree and it looks like
> the right kind of method.
>
> Thanks.
> Mike
The only alternative I can think of is to scan through Working_SDK and replace
the files there with symlinks back to the matching files within the
original subprojects - such scripts exist !
Then any changes in Working_SDK will update the (baselined) originals in-place.
But then no explicit use of git except for tracking work prior to pushing
back to CVS.
Oh well, thanks for ideas, will see which work best.
Mike
^ permalink raw reply
* git svn init throws Not a git repository (or any of the parent directories): .git
From: amccloud @ 2013-02-13 13:01 UTC (permalink / raw)
To: git
Hi all,
I have problem with git svn init:
When I execute
git svn init svn+ssh://username@example.com/path/repo
I see:
fatal: Not a git repository (or any of the parent directories): .git
Already at toplevel, but .git not found
at /usr/lib/git-core/git-svn line 342
But when I execute:
git svn clone svn+ssh://username@example.com/path/repo
Everythins is ok and I see:
Initialized empty Git repository in /tmp/svn_migration/repo/.git/
Any hints why it's no working?
I prefer to do first init and then fetch, because I can fetch selected
revisions (git svn fetch --revision 1:1000) - so it's easier for me to
split migration into groups lets say 1000 revision at once.
My software versions:
git version 1.8.1.1
svn, version 1.6.12 (r955767)
compiled Feb 17 2012, 10:36:45
Best regards.
^ permalink raw reply
* Re: git svn init throws Not a git repository (or any of the parent directories): .git
From: Konstantin Khomoutov @ 2013-02-13 13:15 UTC (permalink / raw)
To: amccloud@gmail.com; +Cc: git
In-Reply-To: <CALiJYpDPf8R2mOZn5Ey_yArSAg73WRASKS1cqLsAu1tGJcO_SA@mail.gmail.com>
On Wed, 13 Feb 2013 14:01:36 +0100
"amccloud@gmail.com" <amccloud@gmail.com> wrote:
> I have problem with git svn init:
> When I execute
> git svn init svn+ssh://username@example.com/path/repo
> I see:
> fatal: Not a git repository (or any of the parent directories): .git
> Already at toplevel, but .git not found
> at /usr/lib/git-core/git-svn line 342
Are you doing `git init` first before running `git svn init ...`?
^ 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