Signed-off-by: Thiago Farina <tfransosi@gmail.com> --- builtin/clean.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/builtin/clean.c b/builtin/clean.c index b508d2c..c8798f5 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -44,7 +44,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix) struct dir_struct dir; static const char **pathspec; struct strbuf buf = STRBUF_INIT; - struct string_list exclude_list = { NULL, 0, 0, 0 }; + struct ...

Signed-off-by: Elijah Newren <newren@gmail.com> --- builtin/revert.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/builtin/revert.c b/builtin/revert.c index 8b9d829..54d13cf 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -495,7 +495,6 @@ static int do_pick_commit(void) free_message(&msg); /* - * * If we are cherry-pick, and if the merge did not result in * hand-editing, we will hit this commit and inherit the original * author date ...

I mean "convenience" interchangeably with "standard" as this paragraph I.e. `git gui citool` and `git citool` launch the same thing, the latter is just a shorter way to do it. --

Its main purpose is to populate the command list in git.1: Main porcelain commands [...] git-citool(1) Graphical alternative to git-commit. [...] git-gui(1) A portable graphical interface to Git. What do you think this should say? (Honest question --- I haven't thought hard about it.) --

That's because it isn't, no? SYNOPSIS git citool DESCRIPTION A Tcl/Tk based graphical interface to review modified files, stage them into the index, enter a commit message and record the new commit onto the current branch. This interface is an alternative to the less interactive git commit program. git citool is actually a standard alias for git gui citool. See git-gui(1) for more details. --

Someone handed me a tarball that represented an unknown release from a project. Here's what I came up with to identify the commit: cd $SOME_WORK_DIR find . -path ./.git -prune -o -print0 | xargs -0 rm tar xvfz $TARBALL for commit in {0..100}; do id="master~${commit}" if git diff --quiet --exit-code "$id" then echo "Matched on commit $id" break fi done Someone please tell me there's an easier way to find a ...

Hi Stefan, first time I hear of this (or see this myself, and I use git gui every day on Mac OS X); in part this may be due to the fact that many of the menu shortcuts assigned by git gui conflict with existing OS X shortcuts and don't work anyway e.g. cmd-A (esp if a text widget is in focus)... please don't brute-force around the problem in this way, there are many features that the Cocoa Tk in 8.5+ adds that would be lost by such a change. Moreover the fact that 8.4 is present in that ...

I think that makes a lot of sense. I think you would not only end up changing the indentation of many subshells (not only those that I added), you will also have to deal with tests using spaces instead of tabs for indentation. But these issues have to be addressed anyway ... --

Fixed all places where it was a straightforward change from cd'ing into a directory and back via "cd .." to a cd inside a subshell. Found these places with "git grep -w "cd \.\.". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> --- This patch applies to maint. t/t1020-subdirectory.sh | 6 +- t/t1302-repo-version.sh | 6 +- t/t2101-update-index-reupdate.sh | 6 +- t/t3060-ls-files-with-tree.sh | 4 ...

This is v5 of the patch thanks to Junio and AEvar for the review and help. context: -------- I'm not familiar at all with Perl so comments on style or usage most welcomed. This patch is to introduce a way to pass specific options to the SMTP server used by git-send-email. I need that to be able to use different SMTP account (wanadoo, gmail...) on some Git repositories to send over proper identity. change since v4: ---------------- Add the missing signed-off-by. change since ...

Signed-off-by: Pascal Obry <pascal@obry.net> --- git-send-email.perl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index 6dab3bf..0063606 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -212,7 +212,7 @@ my %config_settings = ( "smtpserverport" => \$smtp_server_port, "smtpuser" => \$smtp_authuser, "smtppass" => \$smtp_authpass, - "smtpdomain" => \$smtp_domain, + "smtpdomain" => ...

This is v4 of the patch thanks to Junio and AEvar for the review and help. context: -------- I'm not familiar at all with Perl so comments on style or usage most welcomed. This patch is to introduce a way to pass specific options to the SMTP server used by git-send-email. I need that to be able to use different SMTP account (wanadoo, gmail...) on some Git repositories to send over proper identity. change since v3: ---------------- I have moved smtp server option description after ...

--- git-send-email.perl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index 6dab3bf..0063606 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -212,7 +212,7 @@ my %config_settings = ( "smtpserverport" => \$smtp_server_port, "smtpuser" => \$smtp_authuser, "smtppass" => \$smtp_authpass, - "smtpdomain" => \$smtp_domain, + "smtpdomain" => \$smtp_domain, "to" => \@to, "cc" => ...

Hi, There are a few fixes in Git-gui's repository that were not merged in git: $ git log --oneline --decorate git-gui/master ^origin/master aef0b48 (git-gui/master) git-gui: ensure correct application termination in git-gui--askpass d5257fb (git-gui/pu) git-gui: handle textconv filter on Windows and in development 62f9a63 git-gui: use shell to launch textconv filter in "blame" 7807777 (git-gui/maint) git-gui: display error launching blame as a message box. ea47503 git-gui: Make usage ...

Heya, Curious. That does not seem like correct behavior, no. Can you investigate where this goes wrong? -- Cheers, Sverre Rabbelier --

Modify git-completion.bash so that it also works with zsh when using bashcompinit. In particular: declare -F Zsh doesn't have the same 'declare -F' as bash, but 'declare -f' is the same, and it works just as well for our purposes. ${var:2} Zsh does not implement ${var:2} to skip the first 2 characters, but ${var#??} works in both shells to replace the first 2 characters with nothing. Thanks to Jonathan Nieder for the suggestion. for (( n=1; "$n" ... )) Zsh does ...

It's not possible to exclude with git diff/grep, but you can do somtehing like that : find . -type f ! -path "./drivers/staging/*" | xargs git diff --

Hello, I am a newbie in git technology, please bear with me. I am interested to implement git over http along with gitweb. At first I have already created a demo git repository in the server , After restating apache I can see gitweb at http://192.168.1.1/gitweb Here is the apache related configuration ``````````````` Alias /gitweb /var/gitdir/ RewriteEngine On RewriteRule ^gitweb$ gitweb/ [R] SetEnv GITWEB_CONFIG /etc/gitweb.conf <Directory "/var/gitdir/"> AllowOverride ...

The existing docs say that negative values correspond to immediate execution, zero to never, and positive to a delay in deciseconds. That looks much nicer, I was hoping for such a suggestion. -- David Barr. --

Added a new configuration value for help.autocorrect. A value of 'prompt' causes git to wait for confirmation before executing the assumed command. Signed-off-by: David Barr <david.barr@cordelta.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> --- help.c | 19 ++++++++++++++++--- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/help.c b/help.c index 7f4928e..2282885 100644 --- a/help.c +++ b/help.c @@ -267,8 +267,12 @@ static struct cmdnames aliases; static ...

Hi, git top links is my attempt to gather all the links people have been tagging as "git" in delicious.com[1] (these are not chosen by me). It seems the amount of new links has decreased significantly, so this time I’m going to post recurring links too. Enjoy ;) The fancier blog version is here: http://gitlog.wordpress.com/2010/09/06/git-top-links-2010-8/ = New = 1. A few git tips you didn't know about (157) Very useful tips, even for git ...

I already done in the test-string-list.c patch I sent. :-) --

OK, removed that section. --

I think that is about as fast as you will get. You could try something with git-merge-base, but it should be about the same speed. Note that neither will tell you _which_ head the target was reachable from. For that, given the current interface you have to test each head individually. If you write some C code, you can do it all in a single traversal. See this thread for some discussion of how "git tag --contains" can be sped up: ...

As i think i'll only need this to prevent leaking (private) commits that wouldn't be reachable from the (public) heads, just catching the unreachable ones should be enough. $ time git rev-list -n1 v2.6.12 ^v33 ^v35 0m2.333s user 0m0.040s system 0m2.379s elapsed 99.77% CPU $ time git rev-list -n1 v2.6.36-rc2 ^v33 ^v35 76be97c1fc945db08aae1f1b746012662d643e97 0m0.500s user 0m0.010s system 0m0.514s elapsed 99.13% CPU A bit expensive, but I guess should it become a problem I could ...

Depends on the definition of "best", but I often find myself typing git branch --with C where C often is somewhere between 'master' and 'ko/master' (the 'master' branch everybody else has already seen on k.org). When I have second thoughts sometime after applying a patch directly on top of 'master', I need to see if I have built a new topic branch forking from the faulty commit before rewinding it, as such a topic branch also needs to be rewound. --

It was originally called --with. I wrote it to help me in the exact use case in this thread, and the option was naturally named --with, as the request I wanted to make was "Give me branches _with_ this commit, so that I know which ones I need to rewind before reintegrating and publishing". Somehow people wanted to see an option with a longer name, but by that time my fingers were well trained, so I kept "--with" but didn't bother advertising duplicated options. --

Hi Sitaram, Thanks for the feedback. Yes, that's true- even among my friends, only a few expert Hindi speakers were able to follow hindi.po completely. However, I figured that only those people who are more comfortable in Hindi than English will actually use hindi.po, so we might as well do it right :) I also discovered another thing- even expert Hindi speakers don't seem to understand Hindi grammar very well :p After a few hours of studying, I was able to correct a few more mistakes that ...

I can tell you that I *didn't* solve a similar problem with t/harness: ? (test_args => [ split /\s+/, $ENV{GIT_TEST_OPTS} ]) That'll fail if the GIT_TEST_OPTS contains a space, e.g. GIT_TEST_OPTS='--root="/tmp/a space"'. But I just ignored it at the time. It would be useful for both of these if we had a str_to_options() utility function in e.g. Git.pm. If nothing else it's probably more user friendly to specify them in one smtpserveroption string, since you can copy/paste an ...

And test if it is easy to arrange (otherwise I'll take a look myself, so That is a good and important point. We could [sendemail] smtpserveroption = opt1 smtpserveroption = opt2 or if we choose to split at WS [sendemail] smtpserveroption = "opt1 opt2" but with the second form there always is this nagging "how would you specify an option with WS in it" issue, so the former might be easier. If we take the latter route, we should ...

turns out all this was moot. It was *because* I was using something other than "200 OK" that the user was not seeing the message. Ilari's patch just makes the message *look* better/cleaner, but I still have to send it out with a "200 OK" status. That was... a surprise :-) Thanks all sitaram --

From what I remember from smart HTTP discussion (during fleshing-out the protocol/exchange details), the fact that errors from git are send with "200 OK" HTTP status are very much conscious decision. But I don't remember *why* it was chosen this way. If I remember correctly it was something about transparent proxies and caches... Is it documented anywhere? Can anyone explain it? Nevertheless I think it would be a good idea to make *client* more accepting, which means: 1. Printing full ...

I wasn't involved in the decision process, but I suspect it's because HTTP is the transport layer to the Git application. It's the same logic as trying to log in to a Web application with bogus credentials and getting back a page (HTTP 200 OK) stating that the login failed. As far as HTTP is concerned, the transaction succeeded. Josh --

I meant here that programs (including git) do not provide full details about error condition, especially if it has to do womething with authentication, to avoid leaking sensitive information (like e.g. saying that username + password combination is invalid, instead of telling which one is wrong, to avoid disclosing usernames). -- Jakub Narebski Poland --

Feh. I can't count. The first count is correct. The second count should also be 001e. I guess that should be obvious by just looking The only other command that matters is info/refs. For smart clients, its what I said above. For dumb clients, you have to use some sort of HTTP error status that isn't 404. Dumb clients pre-1.6.6 use a curl error message buffer to print out an error. But they don't check the format of info/refs at all, and skip over garbage and/or interpret garbage as ...

Correct. I do not think they are outside the structure because they are overlooked. They simply do not make sense outside the context of "builtin/checkout.c" where "struct checkout" is used (e.g. what would patch-mode possibly mean in the context of "builtin/apply" where the struct is used to check out a path that is not checked out to the working tree). Moving them into the structure would thus make no sense and _will_ confuse people. --

Hi, So, I downloaded your patches and even made sure to sort them appropriately to fix the order, but I'm getting conflicts trying to You're too modest; your comparison simply omitted some of the areas where your series shines, such as the get_pathspec fixes (my stuff was broken and much less complete), merge support, and nicer fetch/push/clone support. You also had some other nice touches (documentation updates, new rev-parse flag) that may not have been a big deal, but they're still ...

Heya, It's considered best practice to base your patches on master if possible. You should only base them on next if you rely on a particular series that has already landed there. You should never base your patches on pu itself, on a topic in pu perhaps, but never on pu. -- Cheers, Sverre Rabbelier --

I read it, but I'm not sure how to do this. Maybe you could point me It is basic, so anyone can read it, and say "Oh, I can do this.". Looking through the code maybe not so easy. It can be expanded later by anyone to test many other things though. So, why not? (Is it so bad to not have it at all?). --

Hmm..maybe before I get ahead of myself, I should back up for a second. Which way do we think is better -- handling this in cache_tree_update() or doing a fixup in commit_tree()? If the latter, then I should just drop my 7/15 and 8/15 for your 13/17 and 14/17. If the former, then it makes sense to look into this change you suggest. In that case, we'd probably keep my 7/15 but drop 8/15 for patch(es) that implement your idea above. But you're more familiar with the index format than I am and ...

Right. I wanted to keep it in buildable state at anytime so I made zero changes to tree-diff.c. But you're right, that should be a move and make sure the code builds. -- Duy --

This function can be potentially used in more places than just tree-diff.c. This patches removes struct diff_options dependency from the function, and moves it to tree-walk.c. No functionality change intended. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- tree-diff.c | 121 ++--------------------------------------------------------- tree-walk.c | 25 +++++------- tree-walk.h | 3 + 3 files changed, 17 insertions(+), 132 deletions(-) diff --git a/tree-diff.c ...

The former makes more sense. I still keep an eye on remote merge support. Think of this case: you request a remote merge and have a completely new base tree, different from HEAD. Then you get some conflicts inside narrow/sparse area. By the time you resolve all conflicts and are about to commit, where do you get the base tree? It could follow the same way merge does, store it in a file in $GIT_DIR, similar to $GIT_DIR/MERGE_HEAD, and make "git commit" pick it up. Or just store it in index. ...

From: Elijah Newren <newren@gmail.com> When traversing commits, the selection of commits would heed the list of pathspecs passed, but subsequent walking of the trees of those commits would not. This resulted in 'rev-list --objects HEAD -- <paths>' displaying objects at unwanted paths. Have process_tree() call tree_entry_interesting() to determine which paths are interesting and should be walked. Naturally, this change can provide a large speedup when paths are specified together with ...

If you are changing the API and structures around this area, you really should aim to help us to support the globbing in diff-tree family just like we do in ls-files family, so yes. --

(+cc: Christian) Right, parts of speech can be a pain. So: An idea (it may or may not be a good one ;-)): what if we made the gettext poison into an automatically generated .po file? Then testing poison would be a special case of running tests with an arbitrary locale: $ TEST_LANGUAGE=poison prove t[0-9]*.sh and this test prerequisite could be more intuitively named LOCALE_C or similar. --

The "me" variable is used in many later messages to indicate whether we're using revert or cherry-pick. Mark it for translation for later use. Also leave a TRANSLATORS message explaining what these are for. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/revert.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/builtin/revert.c b/builtin/revert.c index ece0c0f..2f319f8 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -552,7 +552,9 @@ ...

Split up the "Auto packing the repository" message into quiet and verbose variants to make translation easier. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/gc.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/builtin/gc.c b/builtin/gc.c index 05aed1f..74e77cb 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -216,13 +216,13 @@ int cmd_gc(int argc, const char **argv, const char *prefix) */ if (!need_to_gc()) return ...

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/notes.c | 108 +++++++++++++++++++++++++++--------------------------- 1 files changed, 54 insertions(+), 54 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index fbc347c..d171f6f 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -119,13 +119,13 @@ static void write_commented_object(int fd, const unsigned char *object) show.err = 0; show.git_cmd = 1; if (start_command(&show)) - die("unable to ...

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/revert.c | 42 +++++++++++++++++++++--------------------- 1 files changed, 21 insertions(+), 21 deletions(-) diff --git a/builtin/revert.c b/builtin/revert.c index 4b47ace..ece0c0f 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -79,7 +79,7 @@ static void parse_args(int argc, const char **argv) OPT_END(), }; if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra)) - die("program ...

Here's more work on top of my existing 63 patch series, bringing it to 78 patches in total. With this all of the 'mainporcelain common' *and* 'mainporcelain' in command-list.txt has been made translatable, aside from these shellscripts: git-am mainporcelain git-bisect mainporcelain common git-pull mainporcelain common git-rebase mainporcelain ...

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/describe.c | 36 ++++++++++++++++++------------------ t/t6120-describe.sh | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/builtin/describe.c b/builtin/describe.c index 43caff2..616d405 100644 --- a/builtin/describe.c +++ b/builtin/describe.c @@ -202,13 +202,13 @@ static void display_name(struct commit_name *n) if (n->prio == 2 && !n->tag) { n->tag = lookup_tag(n->sha1); if (!n->tag ...

Use sprintf format for the error message that's displayed if GIT_NOTES_REWRITE_MODE is invalid, and leave a note in a TRANSLATORS comment indicating what the message means. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/notes.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index d171f6f..fe58a41 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -371,8 +371,10 @@ struct notes_rewrite_cfg ...

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- builtin/bundle.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/bundle.c b/builtin/bundle.c index 80649ba..f92970f 100644 --- a/builtin/bundle.c +++ b/builtin/bundle.c @@ -44,7 +44,7 @@ int cmd_bundle(int argc, const char **argv, const char *prefix) close(bundle_fd); if (verify_bundle(&header, 1)) return 1; - fprintf(stderr, "%s is okay\n", bundle_file); + fprintf(stderr, _("%s ...

What good does it do to translate it? The command name is the same Unrelated question: Are reflog actions supposed to be translated? (I have not thought about that carefully.) --

Not all uses of it are references to git-%s, e.g. in the next patch: die(_("Your local changes would be overwritten by %s.\n"), _(me)); But maybe it's used in enough contexts for it to be useless to translate it like this, i.e. we'll have to fix it later, but we'll see In this updated series I've explicitly reverted patches that (accidentally) translated some of the reflog. I'm only translating things which'll be viewed by human eyes, and human eyes alone. That doesn't apply to the ...

Right, forget about this comment. Maybe this patch should be squashed Thanks for explaining. --

On Mon, 06 Sep 2010 18:24:58 +0200, Jens Lehmann <Jens.Lehmann@web.de> Full Ack again! Many german IT people use many english special terms daily (like compiler, linker, terminal, interrupt). Normally the translation of the special terms generates confusion all over the place. That's why I also start git-gui or gitk only in english (and the manpages too, by the way). Thus the git special terms should not be translated, even though I might be helpful to have a glossary which ...

Hi Thomas, thanks for your comments so far. I pretty much agree with all of your thoughts, so below I'm going to focus on those where I have something That's me being careless. I will add an additional check to my workflow This was one of the more difficult things to decide on while translating. Both are difficult to translate into something that "flows", and individually I think both work okay the way I decided to translate them (but see the next paragraph), but of course it would ...

git-gui/po/glossary/git-gui-glossary.txt also has something like that. It would be useful to merge this and that into some Something msgfmt --check wouldn't flag, but running the test suite I think Fast-forward should be changed to "Update without merge" in the English version, although that might not be viable at this point. It would probably improve Git for newbies a lot if we clearly told them during every "git pull" that whether we did a merge or not by using wording to that effect ...

It's a bug in the recursive merge strategy (i.e. the default one), and affects current master as well as 1.7.0.4. The resolve strategy (which can be used with cherry-pick since 1.7.2) handles this correctly: $ git cherry-pick --strategy=resolve branch1 Trying simple merge. Simple merge failed, trying Automatic merge. [master e95e377] added falafel 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 falafel I'll investigate. Elijah --

This fixes an issue reported by Nick, as well as a closely related issue in the handling of rename + directory/file conflicts, particularly where a file on one side of the rename is a directory name on the other side of the merge. Elijah Newren (3): t3509: Add rename + D/F conflict testcases that recursive strategy fails merge-recursive: Small code cleanup merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir merge-recursive.c | 50 ...

Hmmm...should I have split this off from the rest of the series (its only relation is that it cleans up code that made it harder for me to find the real fix)? If I did that, I could rebase the rest of the series on maint... --

When one side of a file rename matches a directory name on the other side, the recursive merge strategy will fail. This is true even if the merge is trivially resolvable. Signed-off-by: Elijah Newren <newren@gmail.com> --- t/t3509-cherry-pick-merge-df.sh | 66 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 66 insertions(+), 0 deletions(-) diff --git a/t/t3509-cherry-pick-merge-df.sh b/t/t3509-cherry-pick-merge-df.sh index a5ccdbf..eb5826f 100755 --- ...

In merge-recursive.c, whenever there was a rename where a file name on one side of the rename matches a directory name on the other side of the merge, then the very first check that string_list_has_string(&o->current_directory_set, ren1_dst) would trigger forcing it into marking it as a rename/directory conflict. However, if the path is only renamed on one side and a simple three-way merge between the separate files resolves cleanly, then we don't need to mark it as a rename/directory ...

I think you broke "tNNNN-X.sh -v"; isn't $DIFF used in t/ scripts everywhere? Even if install-webdoc.sh were the sole user (which is not), please don't do it this way. Instead, introduce "SHOW_PATCH_WHILE_INSTALLING_WEBDOC" or something, and run "$DIFF" with "-q" when it is not set. Otherwise you would forbid people from using $DIFF for its intended purpose: name a diff binary that can be used that is different from a crappy diff your platform gives you by default. --

Well, either you'll come to the same conclusion as the other people before you (myself included), or you'll surprise us all with some clever solution. But that part is up to you. In either cases, I think it is a good thing if I can help you grasp the technical limitations and issues faster so you don't waste your time on false assumptions. Nicolas

I didn't want to get into this discussion, but where in the above picture does the usual "want/ack" exchange fit? The biggest trouble before object transfer actually happens is that the sending end needs to find a set of commits that are known to exist at the receiving end, but it needs to do that starting from a state where the tip commits the receiving end has are not known by it. That is why the receiver must go back in his history and keep asking the sender "I have this, this, this, ...

Before object enumeration obviously. But I think that Luke has enough to play with already by only assuming the easy case for now. If Git P2P is to be viable, it has to prove itself at least with the easy case first. Nicolas --

This bases on the original work by Robin Rosenberg. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- "nanoseconds (modulo 1G)" is changed to "nanosecond fractions" Documentation/technical/index-format.txt | 144 ++++++++++++++++++++++++++++++ 1 files changed, 144 insertions(+), 0 deletions(-) create mode 100644 Documentation/technical/index-format.txt diff --git a/Documentation/technical/index-format.txt ...

Plan is to kill hive-fetch in favor of a fetch helper so the ordinary git retrieval commands may be used. --CJD --

Hi. Was this patch simply forgotten, or are there some remaining concerns about it? Should I submit a new patch which simply fixes the inconsistency which breaks checkout, and leaves the removal of foreign idents on commit to user interaction or hook scripts, as suggested by Jonathan? That would at least restore deterministic behavior... // Marcus --