* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-06 17:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Thomas Rast, Git Mailing List, Nicolas Pitre
In-Reply-To: <AANLkTi=-gomYOpX6+RSboBXBytPry1Qhf31ohmv1dC5d@mail.gmail.com>
On Thu, Jan 6, 2011 at 1:47 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 1:07 AM, Luke Kenneth Casson Leighton
> <luke.leighton@gmail.com> wrote:
>> the plan is to turn that variation in the git pack-objects responses,
>> across multiple peers, into an *advantage* not a liability. how?
>> like this:
>>
>> * a client requiring objects from commit abcd0123 up to commit
>> efga3456 sends out a DHT broadcast query to all and sundry who have
>> commits abcd0123 and everything in between up to efga3456.
>>
>> * those clients that can be bothered to respond, do so [refinements below]
>>
>> * the requestor selects a few of them, and asks them to create git
>> pack-objects. this takes time, but that's ok. once created, the size
>> of the git pack-object is sent as part of the acknowledgement.
>>
>> * the requestor, on receipt of all the sizes, selects the *smallest*
>> one to begin the p2p (.torrent) from (by asking the remote client to
>> create a .torrent specifically for that purpose, with the filename
>> abcd0123-ebga3456).
>
> That defeats the purpose of distributing. You are putting pressure on
> certain peers.
that's unavoidable, but it's not actually as bad as it seems. think
about it. normally, "pressure" is put onto a git server, by forcing
that server to perform multiple "git pack-object" calculations,
repeatedly, for each and every "git pull".
so, the principle behind this RFC (is it an RFC? yes, kinda...) is
that a) you cache those git pack-objects, thus avoiding heavy CPU
usage b) you make the requests to _many_ peers that you'll likely find
already are in the process of distributing that particular
commit-range _anyway_ so will _definitely_ have it ... etc. etc.
so there's a ton of reasons why it's quite a big improvement over the
present star-network arrangement.
>
>> now, an immediately obvious refinement of this is that those .torrent
>> (pack-objects) "stick around", in a cache (with a hard limit defined
>> on the cache size of course). and so, when the client that requires a
>> pack-object makes the request, of course, those remote clients that
>> *already* have that cached pack-object for that specific commit-range
>> should be given first priority, to avoid other clients from having to
>> make massive amounts of git pack-objects.
>
> Cache have its limits too. Suppose I half-fetch a pack then stop and
> go wild for a month. The next month I restart the fetch, the pack may
> no longer in cache. A new pack may or may not be identical to the old
> pack.
correct. that's not in the slightest bit a problem. the peer which
has that new pack will be asked to make a new .torrent for _that_
pack. with a new name that uniquely identifies it (the md5sum of the
pack would do as the .torrent filename)
> Also if you go with packs, you are tied to the peer that generates
> that pack. Two different peers can, in theory, generate different
> packs (in encoding) for the same input.
yes. correct. i _did_ say that you pick the one that is the
smallest of the two (or three. or 10). in this way you actually do
much better than you would otherwise in a "star network" such as a
standard HTTP git server, because you've asked 2, 3 or 10 (whatever)
peers, and you'll end up with _the_ most efficient representation of
that commit-range. statistically speaking, of course :)
> Another thing with packs (ok, not exactly with packs) is how you
> verify that's you have got what you asked.
ok - how do you verify that you've got what you asked, when you ask
from a git server using HTTP?
> Bittorrent can verify every
> piece a peer receives because sha-1 sum of those pieces are recorded
> in .torrent file.
yes. this is simply a part of the bittorrent protocol, to ensure
that the file being transferred is correctly transferred.
these verifications steps should be _trusted_ and should _not_ be
confused with anything else (i've deleted the rest of the paragraph
you wrote, in order to reduce any opportunity for confusion).
if you mentally keep git separate from bittorrent it helps. imagine
that bittorrent is merely a drop-in replacement for git over HTTP
(nicolas kindly explained the plugin system for git which would add
another protocol for downloading of git repos, and yes this can all be
implemented as a plugin)
>> so, can you see that a) this is a far cry from the "simplistic
>> transfer of blobs and trees" b) it's *not* going to overload peoples'
>> systems by splattering (eek!) millions of md5 sums across the internet
>> as bittorrent files c) it _does_ fit neatly into the bittorrent
>> protocol d) it combines the best of git with the best of p2p
>> distributed networking principles...
>
> How can you advertise what you have to another peer?
you don't. it's done "on-demand".
the concept of "git push" becomes virtually a null-op, updating the
bittorrent tracker and that's... about it.
it's where "git pull" that all the work is done, starting with that
DHT query [no i know "bittorrent the protocol" doesn't have DHT, but
many bittorrent clients _do_ have DHT, and Tribler has an extremely
good one].
l.
^ permalink raw reply
* manual http authorization (no netrc)
From: tom fogal @ 2011-01-06 17:20 UTC (permalink / raw)
To: git
I'm getting authorization errors when I lack a .netrc for an http-based
server. Specifically:
tf@shigeru tmp $ git clone http://myhost:port/git/io.git
Cloning into io...
Username:
Password:
error: The requested URL returned error: 401 (curl_result = 22, http_code =
401, sha1 = 9c201da4d64e2fd178935b9ebbd6e110a97578d4)
error: Unable to find 9c201da4d64e2fd178935b9ebbd6e110a97578d4 under
http://shigeru.sci.utah.edu:1234/git/io.git
Cannot obtain needed blob 9c201da4d64e2fd178935b9ebbd6e110a97578d4
while processing commit b1853d6f6a54cf22e259a75f77770eef53b8cb38.
error: Fetch failed.
I did try multiple times; the username/password combo is correct :)
A friend of mine is also experiencing the same problem. The server is
running git 1.5.6.5; my client is 1.7.3.4, and I'm not sure what the
other party's is, but it's likely to be recent.
Everything works fine if we just create a ~/.netrc and set things up
appropriately. `curl-config --version' says "libcurl 7.18.2" on my
workstation.
What have we configured incorrectly?
-tom
^ permalink raw reply
* [PATCH] t9010: svnadmin can fail even if available
From: Jonathan Nieder @ 2011-01-06 18:00 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4D25F9C5.6030503@gmail.com>
If svn is built against one version of SQLite and run against
another, svnadmin (needlessly) errors out during t9010:
<<< Started new transaction, based on original revision 1
* adding path : branches ... done.
* adding path : trunk ... done.
svnadmin: Couldn't perform atomic initialization
svnadmin: Couldn't perform atomic initialization
svnadmin: SQLite compiled for 3.7.4, but running with 3.7.3
Work around this by putting the svn invocations into a single test
that builds a repo to compare the test-svn-fe result against. This
test would always pass but only set the new SVNREPO test prereq if svn
succeeds; and the test using that repo gets an SVNREPO prerequisite so
it only runs with working svn installations.
This seems like the right thing to, anyway: the test script is meant
to test the version of git just built, not the installed svn.
As a side effect, earlier tests will run now even if svn is not
installed. Remove the svn_cmd () helper to decrease the temptation to
run svn from those tests.
Works-around: http://bugs.debian.org/608925
Reported-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Thanks. Does this patch work for you?
t/t9010-svn-fe.sh | 35 +++++++++++++++--------------------
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
index c96bf2f..88a9751 100755
--- a/t/t9010-svn-fe.sh
+++ b/t/t9010-svn-fe.sh
@@ -4,22 +4,6 @@ test_description='check svn dumpfile importer'
. ./test-lib.sh
-if ! svnadmin -h >/dev/null 2>&1
-then
- skip_all='skipping svn-fe tests, svn not available'
- test_done
-fi
-
-svnconf=$PWD/svnconf
-export svnconf
-
-svn_cmd () {
- subcommand=$1 &&
- shift &&
- mkdir -p "$svnconf" &&
- svn "$subcommand" --config-dir "$svnconf" "$@"
-}
-
reinit_git () {
rm -fr .git &&
git init
@@ -41,10 +25,21 @@ test_expect_success 'v3 dumps not supported' '
test_cmp empty stream
'
-test_expect_success 't9135/svn.dump' '
- svnadmin create simple-svn &&
- svnadmin load simple-svn <"$TEST_DIRECTORY/t9135/svn.dump" &&
- svn_cmd export "file://$PWD/simple-svn" simple-svnco &&
+test_expect_success 'set up svn repo' '
+ svnconf=$PWD/svnconf &&
+ mkdir -p "$svnconf" &&
+
+ if
+ svnadmin -h >/dev/null 2>&1 &&
+ svnadmin create simple-svn &&
+ svnadmin load simple-svn <"$TEST_DIRECTORY/t9135/svn.dump" &&
+ svn export --config-dir "$svnconf" "file://$PWD/simple-svn" simple-svnco
+ then
+ test_set_prereq SVNREPO
+ fi
+'
+
+test_expect_success SVNREPO 't9135/svn.dump' '
git init simple-git &&
test-svn-fe "$TEST_DIRECTORY/t9135/svn.dump" >simple.fe &&
(
--
1.7.4.rc1
^ permalink raw reply related
* Re: Repeatable test t9010-svn-fe.sh failure w/ master (685e9d9, 1.7.4.rc1)
From: Junio C Hamano @ 2011-01-06 18:15 UTC (permalink / raw)
To: gitzilla; +Cc: Jonathan Nieder, Git Mailing List
In-Reply-To: <4D25F9C5.6030503@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> + svnadmin load simple-svn
> <<< Started new transaction, based on original revision 1
> * adding path : branches ... done.
> * adding path : trunk ... done.
> svnadmin: Couldn't perform atomic initialization
> svnadmin: Couldn't perform atomic initialization
> svnadmin: SQLite compiled for 3.7.4, but running with 3.7.3
> + eval_ret=1
Hmm. Do any other svn related tests that use "svnadmin load" work in your
environment?
$ cd t/
$ git grep -l 'svnadmin load'
t9010-svn-fe.sh
t9110-git-svn-use-svm-props.sh
t9111-git-svn-use-svnsync-props.sh
t9112-git-svn-md5less-file.sh
t9115-git-svn-dcommit-funky-renames.sh
t9121-git-svn-fetch-renamed-dir.sh
t9126-git-svn-follow-deleted-readded-directory.sh
t9131-git-svn-empty-symlink.sh
t9132-git-svn-broken-symlink.sh
t9135-git-svn-moved-branch-empty-file.sh
t9136-git-svn-recreated-branch-empty-file.sh
t9150-svk-mergetickets.sh
t9151-svn-mergeinfo.sh
t9153-git-svn-rewrite-uuid.sh
t9154-git-svn-fancy-glob.sh
Web searching for "svnadmin: SQLite compiled for" seems to give a handful
of hits, even though I don't see anything from Debian offhand.
^ permalink raw reply
* [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Ramsay Jones @ 2011-01-06 18:29 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano, stevenrwalter, normalperson
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
This test fails for me, because my svn version(s) are too old (1.4.3 and 1.4.6), and
so I've got into the habit of running the tests with NO_SVN_TESTS=1. (which is a bit
of a shame in terms of test coverage, but it is *much* quicker!)
I don't know the details, but it seems that the 'svn merge' of this vintage does not
support the operations required by this test. Unfortunately, I don't know what the
minimum required version of svn is, so I'm hoping that someone can take this patch
and fix it up properly ...
ATB,
Ramsay Jones
t/t9157-git-svn-fetch-merge.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/t9157-git-svn-fetch-merge.sh b/t/t9157-git-svn-fetch-merge.sh
index da582c5..accf61e 100755
--- a/t/t9157-git-svn-fetch-merge.sh
+++ b/t/t9157-git-svn-fetch-merge.sh
@@ -6,6 +6,14 @@
test_description='git svn merge detection'
. ./lib-git-svn.sh
+svn_ver="$(svn --version --quiet)"
+case $svn_ver in
+[0-1].[0-4].[0-6])
+ skip_all="skipping git-svn test - SVN too old ($svn_ver)"
+ test_done
+ ;;
+esac
+
test_expect_success 'initialize source svn repo' '
svn_cmd mkdir -m x "$svnrepo"/trunk &&
svn_cmd mkdir -m x "$svnrepo"/branches &&
--
1.7.3
^ permalink raw reply related
* Re: [PATCH] t9010: svnadmin can fail even if available
From: A Large Angry SCM @ 2011-01-06 18:32 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20110106180051.GC11346@burratino>
On 01/06/2011 01:00 PM, Jonathan Nieder wrote:
> If svn is built against one version of SQLite and run against
> another, svnadmin (needlessly) errors out during t9010:
>
> <<< Started new transaction, based on original revision 1
> * adding path : branches ... done.
> * adding path : trunk ... done.
> svnadmin: Couldn't perform atomic initialization
> svnadmin: Couldn't perform atomic initialization
> svnadmin: SQLite compiled for 3.7.4, but running with 3.7.3
>
> Work around this by putting the svn invocations into a single test
> that builds a repo to compare the test-svn-fe result against. This
> test would always pass but only set the new SVNREPO test prereq if svn
> succeeds; and the test using that repo gets an SVNREPO prerequisite so
> it only runs with working svn installations.
>
> This seems like the right thing to, anyway: the test script is meant
> to test the version of git just built, not the installed svn.
>
> As a side effect, earlier tests will run now even if svn is not
> installed. Remove the svn_cmd () helper to decrease the temptation to
> run svn from those tests.
>
> Works-around: http://bugs.debian.org/608925
> Reported-by: A Large Angry SCM<gitzilla@gmail.com>
> Signed-off-by: Jonathan Nieder<jrnieder@gmail.com>
> ---
> Thanks. Does this patch work for you?
$ sh t9010-svn-fe.sh
ok 1 - empty dump
ok 2 - v3 dumps not supported
ok 3 - set up svn repo
ok 4 # skip t9135/svn.dump (missing SVNREPO)
# passed all 4 test(s)
1..4
Rerunning the full test suite now ...
^ permalink raw reply
* Re: git mergetool broken when rerere active
From: Junio C Hamano @ 2011-01-06 18:56 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Magnus Baeck, Avery Pennarun, Jay Soffian, David Aguilar
In-Reply-To: <alpine.DEB.1.10.1101052119530.26654@debian>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> When rerere is enabled, git mergetool uses 'git rerere status' to find
> out which files to run the merge tool on. This was introduced in
> bb0a484 (mergetool: Skip autoresolved paths, 2010-08-17). Before that,
> 'git ls-files -u' was used, whether or not rerere was active.
>
> This change caused two problems:
>
> (1) Before this change, it used to be that case that all conflicts
> would be resolved and added to the index after running 'git
> mergetool' without arguments, i.e. on all files. After the
> change, conflicts of type 'deleted by them' or 'deleted by us'
> would be ignored, since they are not listed shown by 'git rerere
> status'.
Good point. We used to say "everything that had conflict after a mergy
operation", now we say "everything that rerere attempted resolution but
didn't succeed". Missing are paths that rerere didn't even attempt to
apply previous resolution at all.
Probably we would need a "git rerere remaining" sobcommand that is similar
to status but also includes the "punted" paths.
^ permalink raw reply
* Re: Repeatable test t9010-svn-fe.sh failure w/ master (685e9d9, 1.7.4.rc1)
From: A Large Angry SCM @ 2011-01-06 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git Mailing List
In-Reply-To: <7vipy1c313.fsf@alter.siamese.dyndns.org>
On 01/06/2011 01:15 PM, Junio C Hamano wrote:
> A Large Angry SCM<gitzilla@gmail.com> writes:
>
>> + svnadmin load simple-svn
>> <<< Started new transaction, based on original revision 1
>> * adding path : branches ... done.
>> * adding path : trunk ... done.
>> svnadmin: Couldn't perform atomic initialization
>> svnadmin: Couldn't perform atomic initialization
>> svnadmin: SQLite compiled for 3.7.4, but running with 3.7.3
>> + eval_ret=1
>
> Hmm. Do any other svn related tests that use "svnadmin load" work in your
> environment?
>
> $ cd t/
> $ git grep -l 'svnadmin load'
> t9010-svn-fe.sh
> t9110-git-svn-use-svm-props.sh
> t9111-git-svn-use-svnsync-props.sh
> t9112-git-svn-md5less-file.sh
> t9115-git-svn-dcommit-funky-renames.sh
> t9121-git-svn-fetch-renamed-dir.sh
> t9126-git-svn-follow-deleted-readded-directory.sh
> t9131-git-svn-empty-symlink.sh
> t9132-git-svn-broken-symlink.sh
> t9135-git-svn-moved-branch-empty-file.sh
> t9136-git-svn-recreated-branch-empty-file.sh
> t9150-svk-mergetickets.sh
> t9151-svn-mergeinfo.sh
> t9153-git-svn-rewrite-uuid.sh
> t9154-git-svn-fancy-glob.sh
>
> Web searching for "svnadmin: SQLite compiled for" seems to give a handful
> of hits, even though I don't see anything from Debian offhand.
>
It looks like all of the svn tests are failing.
I checked out the last version I built and tested, f2665ec, and it's
failing the svn tests also. So, it looks like the current Debian
(Squeeze) svn package is broken. And the following seems to confirm that.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608925
^ permalink raw reply
* [PATCH/RFC] alias: use run_command api to execute aliases
From: Erik Faye-Lund @ 2011-01-06 19:13 UTC (permalink / raw)
To: git; +Cc: msysgit, j6t
On Windows, system() executes with cmd.exe instead of /bin/sh. This
means that aliases currently has to be batch-scripts instead of
bourne-scripts. On top of that, cmd.exe does not handle single quotes,
which is what the code-path currently uses to handle arguments with
spaces.
To solve both problems in one go, use run_command_v_opt() to execute
the alias. It already does the right thing prepend "sh -c " to the
alias.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
This fixes issue 553 in the msysGit issue tracker.
git.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/git.c b/git.c
index 68334f6..5b0b9d8 100644
--- a/git.c
+++ b/git.c
@@ -177,19 +177,20 @@ static int handle_alias(int *argcp, const char ***argv)
alias_string = alias_lookup(alias_command);
if (alias_string) {
if (alias_string[0] == '!') {
+ const char **alias_argv;
+ int i;
+
commit_pager_choice();
- if (*argcp > 1) {
- struct strbuf buf;
-
- strbuf_init(&buf, PATH_MAX);
- strbuf_addstr(&buf, alias_string);
- sq_quote_argv(&buf, (*argv) + 1, PATH_MAX);
- free(alias_string);
- alias_string = buf.buf;
- }
- trace_printf("trace: alias to shell cmd: %s => %s\n",
- alias_command, alias_string + 1);
- ret = system(alias_string + 1);
+
+ /* build alias_argv */
+ alias_argv = malloc(sizeof(char *) * *argcp + 1);
+ alias_argv[0] = alias_string + 1;
+ for (i = 1; i < *argcp; ++i)
+ alias_argv[i] = (*argv)[i];
+ alias_argv[*argcp] = NULL;
+
+ ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
+
if (ret >= 0 && WIFEXITED(ret) &&
WEXITSTATUS(ret) != 127)
exit(WEXITSTATUS(ret));
--
1.7.3.3.585.g74f6e
^ permalink raw reply related
* Re: git mergetool broken when rerere active
From: Junio C Hamano @ 2011-01-06 19:33 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Magnus Baeck, Avery Pennarun, Jay Soffian, David Aguilar
In-Reply-To: <7vbp3tc142.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Probably we would need a "git rerere remaining" sobcommand that is similar
> to status but also includes the "punted" paths.
... which may look like this.
Replace use of "git rerere status" in bb0a484 (mergetool: Skip
autoresolved paths, 2010-08-17) with "git rerere remainder" and see what
happens.
builtin/rerere.c | 12 +++++++++-
rerere.c | 63 +++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 64 insertions(+), 11 deletions(-)
diff --git a/builtin/rerere.c b/builtin/rerere.c
index 642bf35..081fccc 100644
--- a/builtin/rerere.c
+++ b/builtin/rerere.c
@@ -8,7 +8,7 @@
#include "xdiff-interface.h"
static const char * const rerere_usage[] = {
- "git rerere [clear | status | diff | gc]",
+ "git rerere [clear | status | remaining | diff | gc]",
NULL,
};
@@ -147,6 +147,8 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
if (!strcmp(argv[0], "clear")) {
for (i = 0; i < merge_rr.nr; i++) {
const char *name = (const char *)merge_rr.items[i].util;
+ if (!name)
+ continue;
if (!has_rerere_resolution(name))
unlink_rr_item(name);
}
@@ -154,12 +156,20 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
} else if (!strcmp(argv[0], "gc"))
garbage_collect(&merge_rr);
else if (!strcmp(argv[0], "status"))
+ for (i = 0; i < merge_rr.nr; i++) {
+ if (!merge_rr.items[i].util)
+ continue;
+ printf("%s\n", merge_rr.items[i].string);
+ }
+ else if (!strcmp(argv[0], "remaining"))
for (i = 0; i < merge_rr.nr; i++)
printf("%s\n", merge_rr.items[i].string);
else if (!strcmp(argv[0], "diff"))
for (i = 0; i < merge_rr.nr; i++) {
const char *path = merge_rr.items[i].string;
const char *name = (const char *)merge_rr.items[i].util;
+ if (!name)
+ continue;
diff_two(rerere_path(name, "preimage"), path, path, path);
}
else
diff --git a/rerere.c b/rerere.c
index d260843..eb47f97 100644
--- a/rerere.c
+++ b/rerere.c
@@ -350,21 +350,57 @@ static int find_conflict(struct string_list *conflict)
int i;
if (read_cache() < 0)
return error("Could not read index");
- for (i = 0; i+1 < active_nr; i++) {
- struct cache_entry *e2 = active_cache[i];
- struct cache_entry *e3 = active_cache[i+1];
- if (ce_stage(e2) == 2 &&
- ce_stage(e3) == 3 &&
- ce_same_name(e2, e3) &&
- S_ISREG(e2->ce_mode) &&
- S_ISREG(e3->ce_mode)) {
- string_list_insert(conflict, (const char *)e2->name);
- i++; /* skip over both #2 and #3 */
+
+ /*
+ * Collect paths with conflict, mark them with NULL (punted) or
+ * !NULL (eligible) in their ->util field.
+ */
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *e = active_cache[i];
+ struct string_list_item *it;
+
+ if (!ce_stage(e))
+ continue;
+ it = string_list_insert(conflict, (const char *)e->name);
+ it->util = NULL;
+ if (ce_stage(e) == 1) {
+ if (active_nr <= ++i)
+ break;
}
+
+ /* Only handle regular files with both stages #2 and #3 */
+ if (i + 1 < active_nr) {
+ struct cache_entry *e2 = active_cache[i];
+ struct cache_entry *e3 = active_cache[i + 1];
+ if (ce_stage(e2) == 2 &&
+ ce_stage(e3) == 3 &&
+ ce_same_name(e, e3) &&
+ S_ISREG(e2->ce_mode) &&
+ S_ISREG(e3->ce_mode))
+ it->util = (void *) 1;
+ }
+
+ /* Skip the entries with the same name */
+ while (i < active_nr && ce_same_name(e, active_cache[i]))
+ i++;
+ i--; /* compensate for the outer loop */
}
return 0;
}
+static void add_punted(struct string_list *merge_rr)
+{
+ int i;
+ struct string_list conflict = STRING_LIST_INIT_DUP;
+
+ find_conflict(&conflict);
+ for (i = 0; i < conflict.nr; i++) {
+ if (conflict.items[i].util)
+ continue;
+ string_list_insert(merge_rr, conflict.items[i].string);
+ }
+}
+
static int merge(const char *name, const char *path)
{
int ret;
@@ -451,6 +487,8 @@ static int do_plain_rerere(struct string_list *rr, int fd)
for (i = 0; i < conflict.nr; i++) {
const char *path = conflict.items[i].string;
+ if (!conflict.items[i].util)
+ continue; /* punted */
if (!string_list_has_string(rr, path)) {
unsigned char sha1[20];
char *hex;
@@ -478,6 +516,8 @@ static int do_plain_rerere(struct string_list *rr, int fd)
const char *path = rr->items[i].string;
const char *name = (const char *)rr->items[i].util;
+ if (!name)
+ continue;
if (has_rerere_resolution(name)) {
if (!merge(name, path)) {
if (rerere_autoupdate)
@@ -552,6 +592,7 @@ int setup_rerere(struct string_list *merge_rr, int flags)
fd = hold_lock_file_for_update(&write_lock, merge_rr_path,
LOCK_DIE_ON_ERROR);
read_rr(merge_rr);
+ add_punted(merge_rr);
return fd;
}
@@ -607,6 +648,8 @@ int rerere_forget(const char **pathspec)
find_conflict(&conflict);
for (i = 0; i < conflict.nr; i++) {
struct string_list_item *it = &conflict.items[i];
+ if (!conflict.items[i].util)
+ continue; /* punted */
if (!match_pathspec(pathspec, it->string, strlen(it->string),
0, NULL))
continue;
^ permalink raw reply related
* Re: Concurrent pushes updating the same ref
From: Junio C Hamano @ 2011-01-06 19:37 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Git Mailing List
In-Reply-To: <20110106163035.GA7812@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jan 06, 2011 at 10:46:38AM -0500, Marc Branchaud wrote:
>
>> fatal: Unable to create
>> '/usr/xiplink/git/public/Main.git/refs/builds/3.3.0-3.lock': File exists.
>> If no other git process is currently running, this probably means a
>> git process crashed in this repository earlier. Make sure no other git
>> process is running and remove the file manually to continue.
>> fatal: The remote end hung up unexpectedly
>>
>> I think the cause is pretty obvious, and in a normal interactive situation
>> the solution would be to simply try again. But in a script trying again
>> isn't so straightforward.
>>
>> So I'm wondering if there's any sense or desire to make git a little more
>> flexible here. Maybe teach it to wait and try again once or twice when it
>> sees a lock file. I presume that normally a ref lock file should disappear
>> pretty quickly, so there shouldn't be a need to wait very long.
>
> Yeah, we probably should try again. The simplest possible (and untested)
> patch is below. However, a few caveats:
>
> 1. This patch unconditionally retries for all lock files. Do all
> callers want that?
I actually have to say that _no_ caller should want this. If somebody
earlier crashed, we would want to know about it (and how). If somebody
else alive is actively holding a lock, why not make it the responsibility
of a calling script to decide if it wants to retry itself or perhaps
decide to do something else?
^ permalink raw reply
* Re: [PATCH/RFC] alias: use run_command api to execute aliases
From: Jonathan Nieder @ 2011-01-06 19:41 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, j6t
In-Reply-To: <1294341187-3956-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund wrote:
> --- a/git.c
> +++ b/git.c
> @@ -177,19 +177,20 @@ static int handle_alias(int *argcp, const char ***argv)
[...]
> - trace_printf("trace: alias to shell cmd: %s => %s\n",
> - alias_command, alias_string + 1);
Replaced by
trace: run_command: ...
(followed by "trace: exec: ..." on non-Windows (execv_shell_cmd)).
Ok.
> - ret = system(alias_string + 1);
> +
> + /* build alias_argv */
> + alias_argv = malloc(sizeof(char *) * *argcp + 1);
This seems to be missing parentheses, so valgrind will complain
except on 8-bit systems. ;-)
What if malloc fails?
> + alias_argv[0] = alias_string + 1;
> + for (i = 1; i < *argcp; ++i)
> + alias_argv[i] = (*argv)[i];
> + alias_argv[*argcp] = NULL;
Nit: all these *argcp are noisy.
> +
> + ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
> +
> if (ret >= 0 && WIFEXITED(ret) &&
The return value from run_command and from system do not mean
the same thing.
> die("Failed to run '%s' when expanding alias '%s'",
> alias_string + 1, alias_command);
run_command already prints an error message, but this one still
seems useful since it mentions the alias.
Except as noted above,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
diff --git a/git.c b/git.c
index 5b0b9d8..dbf061d 100644
--- a/git.c
+++ b/git.c
@@ -178,22 +178,20 @@ static int handle_alias(int *argcp, const char ***argv)
if (alias_string) {
if (alias_string[0] == '!') {
const char **alias_argv;
- int i;
+ int argc = *argcp, i;
commit_pager_choice();
- /* build alias_argv */
- alias_argv = malloc(sizeof(char *) * *argcp + 1);
+ alias_argv = xmalloc(sizeof(*alias_argv) * (argc + 1));
alias_argv[0] = alias_string + 1;
- for (i = 1; i < *argcp; ++i)
+ for (i = 1; i < argc; ++i)
alias_argv[i] = (*argv)[i];
- alias_argv[*argcp] = NULL;
+ alias_argv[argc] = NULL;
ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
+ if (ret >= 0) /* normal exit */
+ exit(ret);
- if (ret >= 0 && WIFEXITED(ret) &&
- WEXITSTATUS(ret) != 127)
- exit(WEXITSTATUS(ret));
die("Failed to run '%s' when expanding alias '%s'",
alias_string + 1, alias_command);
}
^ permalink raw reply related
* Re: log -p hides changes in merge commit
From: Junio C Hamano @ 2011-01-06 19:43 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4D25F6BE.7010300@cfl.rr.com>
Phillip Susi <psusi@cfl.rr.com> writes:
> It seems that adding -c or --cc to the log correctly shows the change to
> a, but why is this not shown by default?
Depends on the definition of "correctly", but perhaps you have a
definition different from ours ;-) The "patches" shown with -c/--cc are
designed to be different from normal diff so that people do not
accidentally try to apply them with "patch" or "git apply".
"log -p" omits merge commits by default because diffs of merges are mostly
not useful for ordinary purposes. If you are trying to use "log -p" to
reproduce a (part of) history, perhaps you would want to also study -m
option.
^ permalink raw reply
* Re: git mergetool broken when rerere active
From: Martin von Zweigbergk @ 2011-01-06 19:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Magnus Baeck, Avery Pennarun, Jay Soffian, David Aguilar
In-Reply-To: <7v62u1bzeg.fsf@alter.siamese.dyndns.org>
On Thu, Jan 6, 2011 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Probably we would need a "git rerere remaining" sobcommand that is similar
>> to status but also includes the "punted" paths.
>
> ... which may look like this.
Thanks! Will have a look at this tonight when I get home.
^ permalink raw reply
* Re: [PATCH/RFC] alias: use run_command api to execute aliases
From: Erik Faye-Lund @ 2011-01-06 19:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, msysgit, j6t
In-Reply-To: <20110106194101.GA14750@burratino>
On Thu, Jan 6, 2011 at 8:41 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Erik Faye-Lund wrote:
>
>> --- a/git.c
>> +++ b/git.c
>> @@ -177,19 +177,20 @@ static int handle_alias(int *argcp, const char ***argv)
> [...]
>> - trace_printf("trace: alias to shell cmd: %s => %s\n",
>> - alias_command, alias_string + 1);
>
> Replaced by
>
> trace: run_command: ...
>
> (followed by "trace: exec: ..." on non-Windows (execv_shell_cmd)).
> Ok.
>
>> - ret = system(alias_string + 1);
>> +
>> + /* build alias_argv */
>> + alias_argv = malloc(sizeof(char *) * *argcp + 1);
>
> This seems to be missing parentheses, so valgrind will complain
> except on 8-bit systems. ;-)
>
> What if malloc fails?
>
2x whoops :)
>> + alias_argv[0] = alias_string + 1;
>> + for (i = 1; i < *argcp; ++i)
>> + alias_argv[i] = (*argv)[i];
>> + alias_argv[*argcp] = NULL;
>
> Nit: all these *argcp are noisy.
>
Yes. Fetching argc once is cleaner, thanks.
>> +
>> + ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
>> +
>> if (ret >= 0 && WIFEXITED(ret) &&
>
> The return value from run_command and from system do not mean
> the same thing.
>
Yet another "whoops" :)
>> die("Failed to run '%s' when expanding alias '%s'",
>> alias_string + 1, alias_command);
>
> run_command already prints an error message, but this one still
> seems useful since it mentions the alias.
>
> Except as noted above,
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>
Thanks, I agree with all your comments. But why did you remove the "/*
build alias_argv */"-comment? :)
v2 coming up!
^ permalink raw reply
* [PATCH v2] alias: use run_command api to execute aliases
From: Erik Faye-Lund @ 2011-01-06 19:54 UTC (permalink / raw)
To: git; +Cc: msysgit, j6t, jrnieder
On Windows, system() executes with cmd.exe instead of /bin/sh. This
means that aliases currently has to be batch-scripts instead of
bourne-scripts. On top of that, cmd.exe does not handle single quotes,
which is what the code-path currently uses to handle arguments with
spaces.
To solve both problems in one go, use run_command_v_opt() to execute
the alias. It already does the right thing prepend "sh -c " to the
alias.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
---
Fixed the issues pointed out by Jonathan Nieder.
git.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/git.c b/git.c
index 68334f6..f3666a8 100644
--- a/git.c
+++ b/git.c
@@ -177,22 +177,22 @@ static int handle_alias(int *argcp, const char ***argv)
alias_string = alias_lookup(alias_command);
if (alias_string) {
if (alias_string[0] == '!') {
+ const char **alias_argv;
+ int argc = *argcp, i;
+
commit_pager_choice();
- if (*argcp > 1) {
- struct strbuf buf;
-
- strbuf_init(&buf, PATH_MAX);
- strbuf_addstr(&buf, alias_string);
- sq_quote_argv(&buf, (*argv) + 1, PATH_MAX);
- free(alias_string);
- alias_string = buf.buf;
- }
- trace_printf("trace: alias to shell cmd: %s => %s\n",
- alias_command, alias_string + 1);
- ret = system(alias_string + 1);
- if (ret >= 0 && WIFEXITED(ret) &&
- WEXITSTATUS(ret) != 127)
- exit(WEXITSTATUS(ret));
+
+ /* build alias_argv */
+ alias_argv = xmalloc(sizeof(char *) * argc + 1);
+ alias_argv[0] = alias_string + 1;
+ for (i = 1; i < argc; ++i)
+ alias_argv[i] = (*argv)[i];
+ alias_argv[argc] = NULL;
+
+ ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
+ if (ret >= 0) /* normal exit */
+ exit(ret);
+
die("Failed to run '%s' when expanding alias '%s'",
alias_string + 1, alias_command);
}
--
1.7.3.3.585.g74f6e
^ permalink raw reply related
* Re: [PATCH v2] alias: use run_command api to execute aliases
From: Jonathan Nieder @ 2011-01-06 20:05 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, j6t
In-Reply-To: <1294343649-6272-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund wrote:
> --- a/git.c
> +++ b/git.c
> @@ -177,22 +177,22 @@ static int handle_alias(int *argcp, const char ***argv)
[...]
> + alias_argv = xmalloc(sizeof(char *) * argc + 1);
Missed a spot? (missing parens)
Thanks for this. It also should provide a minor speedup in the case
of commands with no shell metacharacters.
^ permalink raw reply
* Re: [PATCH v2] alias: use run_command api to execute aliases
From: Erik Faye-Lund @ 2011-01-06 20:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, msysgit, j6t
In-Reply-To: <20110106200518.GA14945@burratino>
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
On Jan 6, 2011 9:05 PM, "Jonathan Nieder" <jrnieder@gmail.com> wrote:
>
> Erik Faye-Lund wrote:
>
> > --- a/git.c
> > +++ b/git.c
> > @@ -177,22 +177,22 @@ static int handle_alias(int *argcp, const char
***argv)
> [...]
> > + alias_argv = xmalloc(sizeof(char *) * argc + 1);
>
> Missed a spot? (missing parens)
>
Blergh... I guess that teaches me a lesson about sending out patches in a
hurry. New version a bit later, then ;)
> Thanks for this. It also should provide a minor speedup in the case
> of commands with no shell metacharacters.
Nice. Not intentional, but hey :)
[-- Attachment #2: Type: text/html, Size: 796 bytes --]
^ permalink raw reply
* Re: [PATCH] t9010: svnadmin can fail even if available
From: Junio C Hamano @ 2011-01-06 20:16 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: A Large Angry SCM, Git Mailing List
In-Reply-To: <20110106180051.GC11346@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> If svn is built against one version of SQLite and run against
> another, svnadmin (needlessly) errors out during t9010:
>
> <<< Started new transaction, based on original revision 1
> * adding path : branches ... done.
> * adding path : trunk ... done.
> svnadmin: Couldn't perform atomic initialization
> svnadmin: Couldn't perform atomic initialization
> svnadmin: SQLite compiled for 3.7.4, but running with 3.7.3
>
> Work around this by putting the svn invocations into a single test
> that builds a repo to compare the test-svn-fe result against. This
> test would always pass but only set the new SVNREPO test prereq if svn
> succeeds; and the test using that repo gets an SVNREPO prerequisite so
> it only runs with working svn installations.
>
> This seems like the right thing to, anyway: the test script is meant
> to test the version of git just built, not the installed svn.
Yes, and I understand that this will prevent the mailing list from getting
spammed by useless "bug reports" that should have been directed to distros
that packaged broken subversion, which is a plus.
But I am somewhat unhappy because I do not think we want to cater to all
the broken installations of system tools. When tests fail because
somebody's "mkdir -p" (just a random example I picked from your patch)
does not work correctly, we would just say "Your system is broken, and
here is a nickle; get a better computer". Why is svnadmin so special?
Also isn't the breakage not just this test, but also in all the tests that
try to run "svnadmin load"? Shouldn't we somehow hoist this logic out of
t9010 and put it in t/lib-vcs-svn.sh or somewhere?
As far as I understand, svn interoperability bits (git-svn and vcs-svn) do
not rely on svnadmin at runtime, so a breakage in the system's svnadmin
would not be a reason to omit building and installing them. It however
somehow feels wrong to install something we cannot even test. I do not
have a good solution to this offhand, though.
^ permalink raw reply
* Re: [PATCH v2] alias: use run_command api to execute aliases
From: Johannes Sixt @ 2011-01-06 20:27 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, jrnieder
In-Reply-To: <1294343649-6272-1-git-send-email-kusmabite@gmail.com>
On Donnerstag, 6. Januar 2011, Erik Faye-Lund wrote:
> @@ -177,22 +177,22 @@ static int handle_alias(int *argcp, const char
> ***argv) alias_string = alias_lookup(alias_command);
> if (alias_string) {
> if (alias_string[0] == '!') {
> + const char **alias_argv;
> + int argc = *argcp, i;
> +
> commit_pager_choice();
> - if (*argcp > 1) {
> - struct strbuf buf;
> -
> - strbuf_init(&buf, PATH_MAX);
> - strbuf_addstr(&buf, alias_string);
> - sq_quote_argv(&buf, (*argv) + 1, PATH_MAX);
> - free(alias_string);
> - alias_string = buf.buf;
> - }
> - trace_printf("trace: alias to shell cmd: %s => %s\n",
> - alias_command, alias_string + 1);
> - ret = system(alias_string + 1);
> - if (ret >= 0 && WIFEXITED(ret) &&
> - WEXITSTATUS(ret) != 127)
> - exit(WEXITSTATUS(ret));
> +
> + /* build alias_argv */
> + alias_argv = xmalloc(sizeof(char *) * argc + 1);
> + alias_argv[0] = alias_string + 1;
> + for (i = 1; i < argc; ++i)
> + alias_argv[i] = (*argv)[i];
> + alias_argv[argc] = NULL;
> +
> + ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
> + if (ret >= 0) /* normal exit */
> + exit(ret);
> +
> die("Failed to run '%s' when expanding alias '%s'",
> alias_string + 1, alias_command);
At this point, errno has a meaning. I'd perhaps change this to:
die_errno("While expanding alias '%s': '%s'",
alias_command, alias_string + 1);
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] t0001,t1510,t3301: use sane_unset which always returns with status 0
From: Junio C Hamano @ 2011-01-06 20:32 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <gmeXEearzUOUEst4-B2b8nKnIcuDy8iOxR9s9wmOFYzBZT5rwFSFsnedLx8orqTDP1ztkJap7K8@cipher.nrlssc.navy.mil>
Thanks; there are a bit more from
$git grep -n -e '^[ ]*unset[ ].*&&' t
* t/t4150-am.sh:132: unset test_tick &&
This should be safe, as we have already run test_tick to set it earlier.
* t/t5560-http-backend-noserver.sh:20: unset REQUEST_METHOD &&
* t/t5560-http-backend-noserver.sh:33: unset REQUEST_METHOD &&
* t/t5560-http-backend-noserver.sh:34: unset CONTENT_TYPE &&
The varilable was earlier set inside the same function; safe.
* t/t5601-clone.sh:167: unset GIT_CONFIG_NOGLOBAL &&
test-lib.sh sets this for us and this unsets it inside a subshell; safe.
* t/t6032-merge-large-rename.sh:98: unset GIT_MERGE_VERBOSITY &&
test-lib.sh sets this for us and this unsets it; safe.
However, this unsets the variable permanently, damaging the environment
for tests other people later may add at the end of the script, which is
bad. But that is outside the scope of your fix.
* t/t9130-git-svn-authors-file.sh:99: unset GIT_CONFIG_NOGLOBAL &&
* t/t9130-git-svn-authors-file.sh:100: unset GIT_DIR &&
test-lib.sh and then lib-git-svn.sh set these for us and this unsets them
inside a subshell; safe.
* t/t9130-git-svn-authors-file.sh:101: unset GIT_CONFIG &&
As far as I can tell, this is unsafe; nobody has set GIT_CONFIG up to this
point.
* t/t9200-git-cvsexportcommit.sh:324: unset GIT_DIR &&
test-lib.sh sets this for us and this unsets it inside a subshell; safe.
^ permalink raw reply
* Re: --find-copies-harder finds fewer copies/renames than -C does
From: Junio C Hamano @ 2011-01-06 20:42 UTC (permalink / raw)
To: Stefan Haller; +Cc: git
In-Reply-To: <1juopju.rh4v4z97i9hmM%lists@haller-berlin.de>
lists@haller-berlin.de (Stefan Haller) writes:
> But what about the suggestion of falling back to -C if
> --find-copies-harder exceeds the rename limit, but -C does not?
> Wouldn't that be the desired behaviour?
Maybe. Patches welcome ;-)
^ permalink raw reply
* Re: log -p hides changes in merge commit
From: Phillip Susi @ 2011-01-06 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrmhakdz.fsf@alter.siamese.dyndns.org>
On 1/6/2011 2:43 PM, Junio C Hamano wrote:
> Depends on the definition of "correctly", but perhaps you have a
> definition different from ours ;-) The "patches" shown with -c/--cc are
> designed to be different from normal diff so that people do not
> accidentally try to apply them with "patch" or "git apply".
>
> "log -p" omits merge commits by default because diffs of merges are mostly
> not useful for ordinary purposes. If you are trying to use "log -p" to
> reproduce a (part of) history, perhaps you would want to also study -m
> option.
What I would like to do is be able to review a merge to sign off on it.
While the full diff against the left parent would be a large and
unhelpful amalgamation of the changes in the merged branch, any
additional changes made during the commit should not be hidden. This
allows someone performing the merge to effectively sneak in unintended
changes. I would expect any such changes to be shown by log -p, but
this only seems to happen if you add -c.
^ permalink raw reply
* Re: [PATCH] t9010: svnadmin can fail even if available
From: Jonathan Nieder @ 2011-01-06 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: A Large Angry SCM, Git Mailing List, Ramkumar Ramachandra
In-Reply-To: <7vpqs9aiul.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> But I am somewhat unhappy because I do not think we want to cater to all
> the broken installations of system tools. When tests fail because
> somebody's "mkdir -p" (just a random example I picked from your patch)
> does not work correctly, we would just say "Your system is broken, and
> here is a nickle; get a better computer". Why is svnadmin so special?
>
> Also isn't the breakage not just this test, but also in all the tests that
> try to run "svnadmin load"? Shouldn't we somehow hoist this logic out of
> t9010 and put it in t/lib-vcs-svn.sh or somewhere?
>
> As far as I understand, svn interoperability bits (git-svn and vcs-svn) do
> not rely on svnadmin at runtime, so a breakage in the system's svnadmin
> would not be a reason to omit building and installing them.
You're right, I did not do a good job of selling the patch. I should
have said:
Subject: t9010: svnadmin can fail even if available
If svn is built against one version of SQLite and run against
another, libsvn_subr needlessly errors out in operations that
need to make a commit.
That is clearly not a bug in git but let us consider the
ramifications for the test suite. git-svn uses libsvn directly
and is probably broken by that bug; it is right for git-svn
tests to fail. The vcs-svn lib, on the other hand, does not use
libsvn and the test t9010 only uses svn to check its work. This
points to two possible improvements:
- do not disable most vcs-svn tests if svn is missing.
- skip validation rather than failing it when svn fails.
Bring about both by putting the svn invocations into a single
test that builds a repo to compare the test-svn-fe result
against. The test will always pass but only will set the new
SVNREPO test prereq if svn succeeds; and validation using that
repo gets an SVNREPO prerequisite so it only runs with working
svn installations.
Works-around: http://bugs.debian.org/608925
Noticed-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* clone breaks replace
From: Phillip Susi @ 2011-01-06 21:00 UTC (permalink / raw)
To: git
I've been experimenting with git replace to remove ancient history, and
I have found that cloning a repository breaks replace. I read about
this process at http://progit.org/2010/03/17/replace.html. I managed to
correctly add a replace commit that truncates the history and contains
instructions where you can find it, and running git log only goes back
to the replacement commit, unless you add --no-replace-objects, which
causes it to show the original full history.
The problem is that when I clone the repository, I expect the clone to
contain only history up to the replacement record, and not the old
history before that. Instead, the clone contains only the full original
history, and the replacement ref is not imported at all. A git replace
in the new clone shows nothing.
Shouldn't clone copy .git/refs/replace?
^ 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