git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [RFC/PATCH] fsck: default to "git fsck --full"
  2009-10-20 11:56  4%               ` Matthieu Moy
@ 2009-10-20 18:46  0%                 ` Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-10-20 18:46 UTC (permalink / raw)
  To: Matthieu Moy
  Cc: Johannes Schindelin, Alex Riesen, Johannes Sixt, Sergio Callegari,
	git

Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed.  Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths.  It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.

Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.

The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much.  At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.

Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum.  That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> On Tue, 20 Oct 2009, Alex Riesen wrote:
>> ...
>>> --no-full works
>>
>> It works.  Technically.  For human users, though, --loose-objects-only 
>> (with a shortcut "--loose") would be better.
>
> OTOH, the advantage of "--no-full" is that it's compatible with
> existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
> in a script, then my stript works also with older Gits.
>
> But anyway, I think very few people are actually interested in "git
> --no-full" (or call it whatever you like), so I don't think this is
> very important.

For human users, I think --full vs --no-full is quite a nice suggestion,
given that we already have advertised --full and people know the option.

Also people know that splicing "no-" after the double dash is often the
way to negate a boolean-looking option.

The actual patch to do this is tiny, but that is just a bonus ;-)

 Documentation/RelNotes-1.6.6.txt |   10 ++++++++++
 Documentation/git-fsck.txt       |    5 +++--
 builtin-fsck.c                   |    2 +-
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 5f1fecb..1896e05 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -1,6 +1,13 @@
 GIT v1.6.6 Release Notes
 ========================
 
+In this release, "git fsck" defaults to "git fsck --full" and checks
+packfiles.  If you prefer a quicker check only on loose objects (the
+old default), you can say "git fsck --no-full".  This has been
+supported by 1.5.4 and newer versions of git, so it is safe to write
+it in your script if you use slightly older git on some of your
+machines.
+
 In git 1.7.0, which is planned to be the release after 1.6.6, "git
 push" into a branch that is currently checked out will be refused by
 default.
@@ -38,6 +45,9 @@ Updates since v1.6.5
 
 (usability, bells and whistles)
 
+ * "git fsck" by default checks the packfiles (i.e. "--full" is the
+   default); you can turn it off with "git fsck --no-full".
+
  * "git log --decorate" shows the location of HEAD as well.
 
 (developers)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 287c4fc..6fe9484 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
-	 [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+	 [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
 
 DESCRIPTION
 -----------
@@ -52,7 +52,8 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
 	or $GIT_DIR/objects/info/alternates,
 	and in packed git archives found in $GIT_DIR/objects/pack
 	and corresponding pack subdirectories in alternate
-	object pools.
+	object pools.  This is now default; you can turn it off
+	with --no-full.
 
 --strict::
 	Enable more strict checking, namely to catch a file mode
diff --git a/builtin-fsck.c b/builtin-fsck.c
index c58b0e3..2d88e45 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -19,7 +19,7 @@ static int show_root;
 static int show_tags;
 static int show_unreachable;
 static int include_reflogs = 1;
-static int check_full;
+static int check_full = 1;
 static int check_strict;
 static int keep_cache_objects;
 static unsigned char head_sha1[20];

^ permalink raw reply related	[relevance 0%]

* Re: How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)?
  2009-12-14  6:25  4% ` How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)? Doug Ireton
@ 2009-12-14  7:55  0%   ` Matthieu Moy
  0 siblings, 0 replies; 55+ results
From: Matthieu Moy @ 2009-12-14  7:55 UTC (permalink / raw)
  To: Doug Ireton; +Cc: git

Doug Ireton <dougireton@gmail.com> writes:

> I am using the latest version of Git (1.6.6) on a Mac. My wife wants
> to use Git to manage her fiction writing as long as she can still use
> Microsoft Word 2008 (Mac). Instead of pushing her into saving
> everything as plain text, I would like to use Git Difftool to pass the
> files to Word and use Word's Compare Documents feature. She wouldn't
> be able to use Git Diff since Word docs are binary files but she could
> still use Git Difftool.

If you're interested in diff-ing the _text_ itself, you can use the
textconv filter of Git, together with antiword (or catdoc, which does
the same thing, but I think antiword works better).

See this:

http://git.or.cz/gitwiki/GitTips#HowtousegittotrackOpenDocument.28OpenOffice.2CKoffice.29files.3F

and adapt by replacing "OpenOffice" with MS Word, and odt2txt with
antiword.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[relevance 0%]

* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
  2009-12-29  6:47  6% Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE Fyn Fynn
  2009-12-29  8:12  7% ` Tay Ray Chuan
@ 2009-12-29  8:38  0% ` Nguyen Thai Ngoc Duy
  2009-12-29 11:04  0%   ` Nanako Shiraishi
  1 sibling, 1 reply; 55+ results
From: Nguyen Thai Ngoc Duy @ 2009-12-29  8:38 UTC (permalink / raw)
  To: Fyn Fynn; +Cc: git, Jeff King

On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
> The exact same git reset command that works in 1.6.4, fails to work
>  under 1.6.6:
>
>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>  /usr/local/git-1.6.6/bin/git reset --hard
>  fatal: hard reset requires a work tree
>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>  /usr/local/git-1.6.4/bin/git reset --hard
>  HEAD is now at 77ec73f...
>
>  What gives?

A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
- 2009-12-04)) makes sure that "git reset --hard" will not work
outside worktree (which is right). Where was your current directory,
inside $GIT_WORK_TREE or outside?
-- 
Duy

^ permalink raw reply	[relevance 0%]

* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
  2009-12-29  8:38  0% ` Nguyen Thai Ngoc Duy
@ 2009-12-29 11:04  0%   ` Nanako Shiraishi
  2009-12-29 11:36  0%     ` Nguyen Thai Ngoc Duy
  0 siblings, 1 reply; 55+ results
From: Nanako Shiraishi @ 2009-12-29 11:04 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: Fyn Fynn, git, Jeff King

Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:

> On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>> The exact same git reset command that works in 1.6.4, fails to work
>>  under 1.6.6:
>>
>>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  /usr/local/git-1.6.6/bin/git reset --hard
>>  fatal: hard reset requires a work tree
>>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  /usr/local/git-1.6.4/bin/git reset --hard
>>  HEAD is now at 77ec73f...
>>
>>  What gives?
>
> A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
> - 2009-12-04)) makes sure that "git reset --hard" will not work
> outside worktree (which is right).

Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?

Jeff's commit message says:

        make sure we are in a worktree. Otherwise, we can end up
	munging files inside of '.git'

But if you have ~/myproject/.git project, whose working tree is ~/myproject, and if you run

        % cd ~/myproject/.git
	% git reset --hard

the code mistakenly overwrote files in ~/myproject/.git directory before Jeff's patch, and I agree it was a bug.

But shouldn't the correct fix be to go to ~/myproject, the obvious root level of the working tree, and check out the files in that directory?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

^ permalink raw reply	[relevance 0%]

* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
  2009-12-29 11:04  0%   ` Nanako Shiraishi
@ 2009-12-29 11:36  0%     ` Nguyen Thai Ngoc Duy
  2009-12-29 21:09  0%       ` Fyn Fynn
  0 siblings, 1 reply; 55+ results
From: Nguyen Thai Ngoc Duy @ 2009-12-29 11:36 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: Fyn Fynn, git, Jeff King

On 12/29/09, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>
>  > On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>  >> The exact same git reset command that works in 1.6.4, fails to work
>  >>  under 1.6.6:
>  >>
>  >>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>  >>  /usr/local/git-1.6.6/bin/git reset --hard
>  >>  fatal: hard reset requires a work tree
>  >>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>  >>  /usr/local/git-1.6.4/bin/git reset --hard
>  >>  HEAD is now at 77ec73f...
>  >>
>  >>  What gives?
>  >
>  > A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
>  > - 2009-12-04)) makes sure that "git reset --hard" will not work
>  > outside worktree (which is right).
>
>
> Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?

It is generally "right" to work from inside worktree, the way Git
worked before GIT_WORK_TREE came. In case of "git reset --hard", yes
it'd be best if Git could just go to worktree and reset it. I forgot
that "git reset --hard" does not take pathspec. The situation may be a
bit more complicated with "git status" (which also handles worktree as
a whole) because you may need to represent the filename output to be
relative to current working directory, not the GIT_WORK_TREE. Using
GIT_WORK_TREE from outside worktree is imo stretching git to its
limits.
-- 
Duy

^ permalink raw reply	[relevance 0%]

* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
  2009-12-29 11:36  0%     ` Nguyen Thai Ngoc Duy
@ 2009-12-29 21:09  0%       ` Fyn Fynn
  0 siblings, 0 replies; 55+ results
From: Fyn Fynn @ 2009-12-29 21:09 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: Nanako Shiraishi, git, Jeff King

I went over the 952dfc6 patch, and it seems like it was designed to
fix a specific bug - the one demonstrated by Nanako Shiraishi above.

Nowhere there do I see an intention to prevent the action described in
the original post. And even if there was such intention, it should
have been made explicit by providing a proper error message: the
current one simply ignores the fact that we provided GIT_WORK_TREE,
and is thus incorrect since the work tree can be found.

Moreover, if there is an intention to prevent resetting from outside
the worktree (why?), then probably "checkout -f" should be limited as
well.

But it is more likely that the breaking of the original action between
1.6.4 and 1.6.6 came about as an untended consequence of 952dfc6,
which oversimplified by assuming that the worktree can only be found
if we're inside it, ignoring the possibility that GIT_WORK_TREE was
provided.

Thus, the current state should be considered a bug.

--

Fynn

On Tue, Dec 29, 2009 at 3:36 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 12/29/09, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>>
>>  > On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>>  >> The exact same git reset command that works in 1.6.4, fails to work
>>  >>  under 1.6.6:
>>  >>
>>  >>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  >>  /usr/local/git-1.6.6/bin/git reset --hard
>>  >>  fatal: hard reset requires a work tree
>>  >>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  >>  /usr/local/git-1.6.4/bin/git reset --hard
>>  >>  HEAD is now at 77ec73f...
>>  >>
>>  >>  What gives?
>>  >
>>  > A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
>>  > - 2009-12-04)) makes sure that "git reset --hard" will not work
>>  > outside worktree (which is right).
>>
>>
>> Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?
>
> It is generally "right" to work from inside worktree, the way Git
> worked before GIT_WORK_TREE came. In case of "git reset --hard", yes
> it'd be best if Git could just go to worktree and reset it. I forgot
> that "git reset --hard" does not take pathspec. The situation may be a
> bit more complicated with "git status" (which also handles worktree as
> a whole) because you may need to represent the filename output to be
> relative to current working directory, not the GIT_WORK_TREE. Using
> GIT_WORK_TREE from outside worktree is imo stretching git to its
> limits.
> --
> Duy
>

^ permalink raw reply	[relevance 0%]

* Re: git clone against firewall
  2010-01-14 23:45  4% git clone against firewall Sebastian Pipping
@ 2010-01-15 18:17  0% ` Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2010-01-15 18:17 UTC (permalink / raw)
  To: Sebastian Pipping; +Cc: git

Sebastian Pipping <webmaster@hartwork.org> writes:

> with a firewall blocking outgoing connections to port 9418 a
>
>   git clone git://...
>
> of git 1.6.6 seems to never return, i.e. loop forever.  in my rather
> automated environment (gentoo's tool layman calling git) this behavior
> is rather troublesome - i need some kind of abort-and-error instead:
> what i'm trying to do is loop over a number of clone URL alternatives of
> the same repository like ..
>
>   git://git.overlays.gentoo.org/dev/dberkholz.git

What do you exactly mean by "blocking"?

In my environment at work, there is a firewall and I immedately get this:

    $ git clone git://git.overlays.gentoo.org/dev/dberkholz.git/
    Initialized empty Git repository in /var/tmp/dberkholz/.git/
    fatal: Unable to look up git.overlays.gentoo.org (port 9418) (Name or service not known)

as my environment is quite isolated (it is not just a "NAT with selective
port blocking").

I am guessing that you can resolve the hostname in your environment
(i.e. you configured your NAT to let DNS go directly outside).  What
happens when you try the following?

    $ telnet git.overlays.gentoo.org 9418

Do you get:

    Trying 66.219.59.40...
    telnet: Unable to connect to remote host: Connection refused

If you get something like:

    Trying 66.219.59.40...
    Connected to pelican.gentoo.org.
    Escape character is '^]'.

then I don't think you are blocked, and if that is the case, there is not
much we can do about it.

I think your firewall can help, though, by not pretending to be allowing
the connection and then blocking you halfway.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] Fix segfault in fast-export
  2010-01-07  3:58  4% [PATCH] Fix segfault in fast-export Mike Mueller
@ 2010-01-18 17:44  0% ` Heiko Voigt
  0 siblings, 0 replies; 55+ results
From: Heiko Voigt @ 2010-01-18 17:44 UTC (permalink / raw)
  To: Mike Mueller; +Cc: git

Hi,

if want your change included in git you probably want to CC: Junio and
inline your patch so its easier to comment. Please see the file
Documentation/SubmittingPatches for tips on how to do it with your
mailer.

cheers Heiko

P.S.: and include a commit message in your patch

On Wed, Jan 06, 2010 at 10:58:39PM -0500, Mike Mueller wrote:
> Hi all,
> 
> I'm working on a C++ static analyzer (Vigilant Sentry), and git
> is one of my test subjects.  In git-1.6.6, I found a crash in the
> fast-export command:
> 
> The problem is in builtin-fast-export.c, function export_marks:
> 
>     f = fopen(file, "w");
>     if (!f)
>         error("Unable to open marks file %s for writing.", file);
>    
>     for (i = 0; i < idnums.size; i++) {
>         if (deco->base && deco->base->type == 1) {
>             mark = ptr_to_mark(deco->decoration);
>             if (fprintf(f, ":%"PRIu32" %s\n", mark,
>                 sha1_to_hex(deco->base->sha1)) < 0) {
>                 e = 1;
>                 break;
>             }
>         }
>         deco++;
>     }
>    
>     e |= ferror(f);
>     e |= fclose(f);
> 
> If fopen() fails, the error message is printed, but the function
> doesn't exit.  The subsequent calls to fprintf and/or ferror will
> fail because f is NULL.  A simple way to reproduce is to export
> to a path you don't have write access to:
>    
>     $ git fast-export --export-marks=/foo
>     error: Unable to open marks file /foo for writing.
>     Segmentation fault (core dumped)
> 
> I've attached a trivial patch that calls die_errno instead of
> error, so the program exits if f is NULL.
> 
> Regards,
> Mike
> 
> -- 
> Mike Mueller
> mmueller@vigilantsw.com
> 
> http://www.vigilantsw.com/

> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> index b0a4029..963e89b 100644
> --- a/builtin-fast-export.c
> +++ b/builtin-fast-export.c
> @@ -503,7 +503,7 @@ static void export_marks(char *file)
>  
>  	f = fopen(file, "w");
>  	if (!f)
> -		error("Unable to open marks file %s for writing.", file);
> +		die_errno("Unable to open marks file %s for writing", file);
>  
>  	for (i = 0; i < idnums.size; i++) {
>  		if (deco->base && deco->base->type == 1) {

^ permalink raw reply	[relevance 0%]

* Re: [PATCH (resend 3)] git gui: Use git diff --submodule when available
  2010-01-23 22:34  4% ` Shawn O. Pearce
@ 2010-01-23 22:42  0%   ` Jens Lehmann
  0 siblings, 0 replies; 55+ results
From: Jens Lehmann @ 2010-01-23 22:42 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Git Mailing List

Am 23.01.2010 23:34, schrieb Shawn O. Pearce:
> I actually just applied a modified version of your patch, so diff
> on submodules still works via submodule summary if git < 1.6.6.

One caveat: This will only work in versions 1.6.4 and above, as i
had to add the --files option to git submodule summary to make it
work.

^ permalink raw reply	[relevance 0%]

* Re: git stash pop not reapplying deletions
  2010-02-14 19:45  4% git stash pop not reapplying deletions Steve Folly
@ 2010-02-14 22:08  0% ` Thomas Rast
  2010-02-15 14:32  0%   ` Steve Folly
  0 siblings, 1 reply; 55+ results
From: Thomas Rast @ 2010-02-14 22:08 UTC (permalink / raw)
  To: Steve Folly; +Cc: git

On Sunday 14 February 2010 20:45:03 Steve Folly wrote:
> 
> I'm not sure if I've found a bug in 'git stash' or if I'm using 
> it the wrong way? (This is with git 1.6.6):
> 
[eliding a lot everywhere to make it clearer]
> $ git status   # correctly shows renames
> #	renamed:    dira/a -> dirb/a
> #	renamed:    dira/b -> dirb/b
> #	renamed:    dira/c -> dirb/c
> $ git stash
> $ git stash pop
> # Changes to be committed:
> #	new file:   dirb/a
> #	new file:   dirb/b
> #	new file:   dirb/c
> # Changed but not updated:
> #	deleted:    dira/a
> #	deleted:    dira/b
> #	deleted:    dira/c

The problem is that you aren't using --index, but still expecting it
to restore your index.  If you change it to 'git stash pop --index',
everything will work as expected.

Yes, it does stage new files, but that is only to help you: otherwise
you could forget them before committing.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

^ permalink raw reply	[relevance 0%]

* Re: git stash pop not reapplying deletions
  2010-02-14 22:08  0% ` Thomas Rast
@ 2010-02-15 14:32  0%   ` Steve Folly
  0 siblings, 0 replies; 55+ results
From: Steve Folly @ 2010-02-15 14:32 UTC (permalink / raw)
  To: git

Thomas Rast <trast <at> student.ethz.ch> writes:

> 
> On Sunday 14 February 2010 20:45:03 Steve Folly wrote:
> > 
> > I'm not sure if I've found a bug in 'git stash' or if I'm using 
> > it the wrong way? (This is with git 1.6.6):
> > 
> [eliding a lot everywhere to make it clearer]
> > $ git status   # correctly shows renames
> > #	renamed:    dira/a -> dirb/a
> > #	renamed:    dira/b -> dirb/b
> > #	renamed:    dira/c -> dirb/c
> > $ git stash
> > $ git stash pop
> > # Changes to be committed:
> > #	new file:   dirb/a
> > #	new file:   dirb/b
> > #	new file:   dirb/c
> > # Changed but not updated:
> > #	deleted:    dira/a
> > #	deleted:    dira/b
> > #	deleted:    dira/c
> 
> The problem is that you aren't using --index, but still expecting it
> to restore your index.  If you change it to 'git stash pop --index',
> everything will work as expected.

OK, yep - got it. Thanks.
 
> Yes, it does stage new files, but that is only to help you: otherwise
> you could forget them before committing.
> 

But that's even more confusing - not using --index only 
restores *some* of the index. To be honest, 
that's not really helping - I still have to stage deletions 
manually.

If not using --index isn't supposed to restore the index, 
then surely it shouldn't be staging the new files?


Cheers
Steve

^ permalink raw reply	[relevance 0%]

* Writing git remote helpers
  2010-02-19 13:38  4%         ` Sverre Rabbelier
@ 2010-02-19 15:15  0%           ` Gabriel
  0 siblings, 0 replies; 55+ results
From: Gabriel @ 2010-02-19 15:15 UTC (permalink / raw)
  To: Sverre Rabbelier; +Cc: git

Sverre Rabbelier:
> Heya,
> 
> On Fri, Feb 19, 2010 at 13:52, Gabriel <g2p.code@gmail.com> wrote:
> > FWIW, I'm interested in that remote-vcs code, but never figured out
> > where it was published. TIA for pushing it.
> 
> The remote-helpers code is already in git.git, and has been since git
> 1.6.6 with some improvements now in 1.7.0.

Yes, good; I meant I haven't found example uses of that code. I'm aware
of work on a cvs helper and an hg helper. Users of the python library
would be extra convenient.

> > I'll be using it to better integrate fast-import based backup
> > scripts.
> 
> Do you mean that you'll write a remote helper to import your backups?
> If so then my code could be useful as a demonstration on how to hook
> up a fast-import stream.

I think so.

I'm using fast-import to break down a big json file into a tree, and
slurp the tree into git. I'm doing this read only. This gives me a
history of the file, compact, human-readable with git log, with an
incremental remote mirror.

I expect making it work with remote-helpers (I'll need to rebuild json
from the git input to also handle push, I don't know what else is
required) will give me convenient push-pull semantics and I'll be able
to sync that file across machines, taking advantage of git's merging
abilities.
I imagine this kind of sync use case would also work with something
like CouchDB or MongoDB, but git has a low barrier to entry for me, and
I'm not sure how well the others handle tree merging, that sometimes
requires human intervention, in a multi-master replication setup.

Speaking of remote-helpers requirements, besides the fast-import
stream, what else do I need? I imagine I'll do some book-keeping to
note when the current import was last modified (and avoid reimporting
it when unchanged), and the last hash that was pushed (and avoid
re-exporting it needlessly).

When pushing, how do I tell that the current push is a non
fast-forward? I can look for the hash of the json file in the history
of the pushed branch; if it isn't there I'll refuse the push. Do I keep
json hashes in log messages like git-svn does?
Or do I store a commit_id -> json hash mapping next to the json file?
Do I use git notes for that mapping? How do I index back from json hash
to matching commit to commits having the matching commit in their
ancestry?

When pulling, how do I tell there's nothing further to import? Same
approach as for push: look for the json hash in the history or in a
local mapping, import nothing if found?

Thinking about it some more, those two operations need a json_hash ->
commit_id lookup followed by a commit_id, commit_id -> bool DAG ancestry
test. Is that something the support library provides, or would welcome?

^ permalink raw reply	[relevance 0%]

* Re: 16 gig, 350,000 file repository
  2010-02-22 22:20  4%               ` Bill Lear
@ 2010-02-22 22:31  0%                 ` Nicolas Pitre
  0 siblings, 0 replies; 55+ results
From: Nicolas Pitre @ 2010-02-22 22:31 UTC (permalink / raw)
  To: Bill Lear; +Cc: git

On Mon, 22 Feb 2010, Bill Lear wrote:

> On Thursday, February 18, 2010 at 15:58:42 (-0500) Nicolas Pitre writes:
> >On Thu, 18 Feb 2010, Bill Lear wrote:
> >
> >> I'm starting a new, large project and would like a quick bit of advice.
> >> 
> >> Bringing in a set of test cases and other files from a ClearCase
> >> repository resulted in a 350,000 file git repo of about 16 gigabytes.
> >> 
> >> The time to clone over a fast network was about 250 minutes.  I could
> >> not verify if the repo had been packed properly, etc.
> >
> >I'd start from there.  If you didn't do a 'git gc --aggressive' after 
> >the import then it is quite likely that your repo isn't well packed.
> >
> >Of course you'll need a big machine to repack this.  But that should be 
> >needed only once.
> 
> Ok, well they have a "big machine", but not big enough.  It's running
> out of memory on the gc.  I believe they have a fair amount of memory:
> 
> % free
>              total       used       free     shared    buffers     cached
> Mem:      16629680   16051444     578236          0      28332   14385948
> -/+ buffers/cache:    1637164   14992516
> Swap:      8289500       1704    8287796
> 
> and they are using git 1.6.6.

Hmmm. OK.

You might try:

	git repack -a -f -d --depth=200 --window=100 --window-memory=1g


Nicolas

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2] gitk: Show notes by default (like git log do)
  2010-05-20  9:50  3% [PATCH v2] gitk: Show notes by default (like git log do) Kirill Smelkov
@ 2010-05-30  2:22  0% ` Paul Mackerras
  0 siblings, 0 replies; 55+ results
From: Paul Mackerras @ 2010-05-30  2:22 UTC (permalink / raw)
  To: Kirill Smelkov; +Cc: git, Michael J Gruber

On Thu, May 20, 2010 at 01:50:41PM +0400, Kirill Smelkov wrote:

> Starting from ~ git-1.6.6, log, show & whatchanged show notes by default.
> 
> On the other hand, gitk does not show notes by default, because under
> the hood it calls `git log --pretty=raw ...` to get the log, and in
> `git log` notes are turned off, when user specifies format or pretty
> settings.
> 
> Yes, it is possible to invoke `gitk --show-notes` explicitly, but since
> from user's perspective, gitk is gui enabled git log, it would be
> logical for gitk to show notes by default too for consistency.
> 
> In git, --show-notes was introduced in 66b2ed (Fix "log" family not to
> be too agressive about showing notes) which predates 1.6.6.2
> 
> Notes can still be supressed with `gitk --no-notes`.
> 
> Cc: Michael J Gruber <git@drmicha.warpmail.net>
> Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>

Thanks, applied.

Paul.

^ permalink raw reply	[relevance 0%]

* Re: cannot fetch arm git tree
  2011-01-21 13:38  4%         ` Detlef Vollmann
@ 2011-01-21 13:47  0%           ` Uwe Kleine-König
  2011-01-21 13:57  0%             ` Russell King - ARM Linux
  0 siblings, 1 reply; 55+ results
From: Uwe Kleine-König @ 2011-01-21 13:47 UTC (permalink / raw)
  To: Detlef Vollmann
  Cc: Russell King - ARM Linux, Jello huang, git, linux-arm-kernel

Hi Detlef,

On Fri, Jan 21, 2011 at 02:38:11PM +0100, Detlef Vollmann wrote:
> On 01/16/11 14:42, Russell King - ARM Linux wrote:
> >Let's say you already have a copy of my tree from a month ago, and Linus
> >has pulled some work from me into his tree, and repacked his tree into one
> >single pack file.  At the moment, the largest pack file from Linus is
> >400MB plus a 50MB index.
> >
> >You already have most of the contents of that 400MB pack file, but if
> >you're missing even _one_ object which is contained within it, git will
> >have to download the _entire_ 400MB pack file and index file to retrieve
> >it.
> I thought this has changed with "smart http" in git 1.6.6.
> Am I missing something?
Well, not all http repos offer smart http.  E.g. Russell doesn't[1],
probably because the serving machine doesn't have the power to nice
serve a repo via git:// or smart http://.

Best regards
Uwe

[1] I didn't recheck though

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply	[relevance 0%]

* Re: cannot fetch arm git tree
  2011-01-21 13:47  0%           ` Uwe Kleine-König
@ 2011-01-21 13:57  0%             ` Russell King - ARM Linux
  2011-01-21 14:28  0%               ` Detlef Vollmann
  0 siblings, 1 reply; 55+ results
From: Russell King - ARM Linux @ 2011-01-21 13:57 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: Detlef Vollmann, Jello huang, git, linux-arm-kernel

On Fri, Jan 21, 2011 at 02:47:28PM +0100, Uwe Kleine-König wrote:
> Hi Detlef,
> 
> On Fri, Jan 21, 2011 at 02:38:11PM +0100, Detlef Vollmann wrote:
> > On 01/16/11 14:42, Russell King - ARM Linux wrote:
> > >Let's say you already have a copy of my tree from a month ago, and Linus
> > >has pulled some work from me into his tree, and repacked his tree into one
> > >single pack file.  At the moment, the largest pack file from Linus is
> > >400MB plus a 50MB index.
> > >
> > >You already have most of the contents of that 400MB pack file, but if
> > >you're missing even _one_ object which is contained within it, git will
> > >have to download the _entire_ 400MB pack file and index file to retrieve
> > >it.
> > I thought this has changed with "smart http" in git 1.6.6.
> > Am I missing something?
> Well, not all http repos offer smart http.  E.g. Russell doesn't[1],
> probably because the serving machine doesn't have the power to nice
> serve a repo via git:// or smart http://.

What is smart http?  I don't particularly follow git developments.

^ permalink raw reply	[relevance 0%]

* Re: cannot fetch arm git tree
  2011-01-21 13:57  0%             ` Russell King - ARM Linux
@ 2011-01-21 14:28  0%               ` Detlef Vollmann
  2011-01-21 14:30  0%                 ` Jello huang
  0 siblings, 1 reply; 55+ results
From: Detlef Vollmann @ 2011-01-21 14:28 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-arm-kernel, Jello huang, git, Uwe Kleine-König

On 01/21/11 14:57, Russell King - ARM Linux wrote:
> On Fri, Jan 21, 2011 at 02:47:28PM +0100, Uwe Kleine-König wrote:
>> Hi Detlef,
>>
>> On Fri, Jan 21, 2011 at 02:38:11PM +0100, Detlef Vollmann wrote:
>>> On 01/16/11 14:42, Russell King - ARM Linux wrote:
>>>> Let's say you already have a copy of my tree from a month ago, and Linus
>>>> has pulled some work from me into his tree, and repacked his tree into one
>>>> single pack file.  At the moment, the largest pack file from Linus is
>>>> 400MB plus a 50MB index.
>>>>
>>>> You already have most of the contents of that 400MB pack file, but if
>>>> you're missing even _one_ object which is contained within it, git will
>>>> have to download the _entire_ 400MB pack file and index file to retrieve
>>>> it.
>>> I thought this has changed with "smart http" in git 1.6.6.
>>> Am I missing something?
>> Well, not all http repos offer smart http.  E.g. Russell doesn't[1],
>> probably because the serving machine doesn't have the power to nice
>> serve a repo via git:// or smart http://.
>
> What is smart http?  I don't particularly follow git developments.
It seems to be an implementation of the git protocol using
HTTP as transport.
Some info on this is at <http://progit.org/2010/03/04/smart-http.html>.

   Detlef

^ permalink raw reply	[relevance 0%]

* Re: cannot fetch arm git tree
  2011-01-21 14:28  0%               ` Detlef Vollmann
@ 2011-01-21 14:30  0%                 ` Jello huang
  0 siblings, 0 replies; 55+ results
From: Jello huang @ 2011-01-21 14:30 UTC (permalink / raw)
  To: Detlef Vollmann
  Cc: Russell King - ARM Linux, linux-arm-kernel, git,
	Uwe Kleine-König


[-- Attachment #1.1: Type: text/plain, Size: 1570 bytes --]

not a lucky dog. i used 1.6.0,there was a large pack.

On 21 January 2011 22:28, Detlef Vollmann <dv@vollmann.ch> wrote:

> On 01/21/11 14:57, Russell King - ARM Linux wrote:
>
>> On Fri, Jan 21, 2011 at 02:47:28PM +0100, Uwe Kleine-König wrote:
>>
>>> Hi Detlef,
>>>
>>> On Fri, Jan 21, 2011 at 02:38:11PM +0100, Detlef Vollmann wrote:
>>>
>>>> On 01/16/11 14:42, Russell King - ARM Linux wrote:
>>>>
>>>>> Let's say you already have a copy of my tree from a month ago, and
>>>>> Linus
>>>>> has pulled some work from me into his tree, and repacked his tree into
>>>>> one
>>>>> single pack file.  At the moment, the largest pack file from Linus is
>>>>> 400MB plus a 50MB index.
>>>>>
>>>>> You already have most of the contents of that 400MB pack file, but if
>>>>> you're missing even _one_ object which is contained within it, git will
>>>>> have to download the _entire_ 400MB pack file and index file to
>>>>> retrieve
>>>>> it.
>>>>>
>>>> I thought this has changed with "smart http" in git 1.6.6.
>>>> Am I missing something?
>>>>
>>> Well, not all http repos offer smart http.  E.g. Russell doesn't[1],
>>> probably because the serving machine doesn't have the power to nice
>>> serve a repo via git:// or smart http://.
>>>
>>
>> What is smart http?  I don't particularly follow git developments.
>>
> It seems to be an implementation of the git protocol using
> HTTP as transport.
> Some info on this is at <http://progit.org/2010/03/04/smart-http.html>.
>
>  Detlef
>
>


-- 
JUST DO IT,NOTHING IS IMPOSSIBLE

[-- Attachment #1.2: Type: text/html, Size: 2490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: git smart protocol via WebSockets - feedback wanted
  2012-06-05 18:41  4%   ` Stephan Peijnik
@ 2012-06-05 18:54  0%     ` Shawn Pearce
  2012-06-05 19:28  0%       ` Stephan Peijnik
  0 siblings, 1 reply; 55+ results
From: Shawn Pearce @ 2012-06-05 18:54 UTC (permalink / raw)
  To: Stephan Peijnik; +Cc: git

On Tue, Jun 5, 2012 at 11:41 AM, Stephan Peijnik <stephan@peijnik.at> wrote:
> On 06/05/2012 08:31 PM, Junio C Hamano wrote:
>>
>> How does this compare with the smart-http support that tunnels the
>> git protocol over http (with some butchering)?
>
>
> To be honest, I didn't know smart-http support yet. Is that the approach
> introduced with git 1.6.6?

Yes. So its been around for a while now. Like 2 years.

> If so, that approach uses multiple POST requests, meaning multiple TCP and
> HTTP connections need to be established, multiple requests processed, etc.

Its actually only one TCP connection... assuming the servers in
between the client and the Git endpoint correctly support HTTP
keep-alive semantics.

> The WebSocket approach uses a single HTTP connection which gets upgraded to
> a WebSocket. This WebSocket then allows the same communication to happen as
> with the ssh implementation.

How does this fair going through crappy proxy servers that perform
man-in-the-middle attacks on SSL connections? Just last week I was
trying to help someone whose local proxy server was MITM the SSL
session behind Git's back, and their IT department forgot to install
the proxy server's certificate into the system certificate directory.
They only installed it into the browser. That proxy also doesn't
correctly grok HTTP 1.1 keep-alive with chunked transfer encodings.
Let alone something as new as web sockets.

> So in comparison there is possibly a lot less overhead and, in theory, the
> performance should be comparable to running the smart protocol over ssh.
> Personally I'd say the WebSocket approach is cleaner than the HTTP-POST
> approach.

This may be true. But its also a lot more complex to implement. I
noticed you reused Python code to help make this work. Let me know
when there is a GPLv2 client library that implements sufficient
semantics for WebSockets that Git can bundle it out of the box. And
let me know when most corporate IT proxy servers correctly grok
WebSockets. I suspect it will be many more years given that they still
can't even grok chunked transfer encoding.

^ permalink raw reply	[relevance 0%]

* Re: git smart protocol via WebSockets - feedback wanted
  2012-06-05 18:54  0%     ` Shawn Pearce
@ 2012-06-05 19:28  0%       ` Stephan Peijnik
  0 siblings, 0 replies; 55+ results
From: Stephan Peijnik @ 2012-06-05 19:28 UTC (permalink / raw)
  To: git

On 06/05/2012 08:54 PM, Shawn Pearce wrote:
> On Tue, Jun 5, 2012 at 11:41 AM, Stephan Peijnik<stephan@peijnik.at>  wrote:
>> To be honest, I didn't know smart-http support yet. Is that the approach
>> introduced with git 1.6.6?
>
> Yes. So its been around for a while now. Like 2 years.

I have just read-up on that. My fault.

>> If so, that approach uses multiple POST requests, meaning multiple TCP and
>> HTTP connections need to be established, multiple requests processed, etc.
>
> Its actually only one TCP connection... assuming the servers in
> between the client and the Git endpoint correctly support HTTP
> keep-alive semantics.

With keep-alive that is true, but a quick check on the actual data 
exchange tells me that multiple HTTP requests are still needed. But I 
guess the overhead caused by a second HTTP requests can be ignored.

> How does this fair going through crappy proxy servers that perform
> man-in-the-middle attacks on SSL connections? Just last week I was
> trying to help someone whose local proxy server was MITM the SSL
> session behind Git's back, and their IT department forgot to install
> the proxy server's certificate into the system certificate directory.
> They only installed it into the browser. That proxy also doesn't
> correctly grok HTTP 1.1 keep-alive with chunked transfer encodings.
> Let alone something as new as web sockets.

Proxy servers could be an issue, yes. For proxy servers not acting as 
MITM and which are supporting CONNECT this shouldn't be an issue though.
Also, given the current HTML5 hype things should get better in the 
future, but you are correct about potential current issues with the 
approach.

>> So in comparison there is possibly a lot less overhead and, in theory, the
>> performance should be comparable to running the smart protocol over ssh.
>> Personally I'd say the WebSocket approach is cleaner than the HTTP-POST
>> approach.
>
> This may be true. But its also a lot more complex to implement. I
> noticed you reused Python code to help make this work.

The only reason I used Python is that I wanted to quickly come up with a 
prototype. I am also aware of the fact that a proper implementation 
should possibly be done in C.

> Let me know when there is a GPLv2 client library that implements sufficient
> semantics for WebSockets that Git can bundle it out of the box.

As for the WebSocket client library that is GPLv2 compatible: there is 
at least libwebsockets [0], which is licensed under the terms of the 
LGPL v2.1, and as such GPLv2 only compatible.
What do you think about using this as basis for a proper implementation?

> And let me know when most corporate IT proxy servers correctly grok
> WebSockets. I suspect it will be many more years given that they still
> can't even grok chunked transfer encoding.

As stated above, this could be a problem, yes.
The question is whether one only wants to provide an alternative 
approach when it is usable for everyone.
My intention never was to have the current http implementation, be it 
the dumb or http-backend one, replaced. The idea here was to provide an 
additional option that makes use of a fairly new technology, with all 
benefits and drawbacks of using something new.

Thanks for your feedback.

-- Stephan

[0] http://git.warmcat.com/cgi-bin/cgit/libwebsockets/

^ permalink raw reply	[relevance 0%]

* Re: Google Code supports Git
  @ 2011-07-17  2:26  3% ` Shawn Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn Pearce @ 2011-07-17  2:26 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List

On Sat, Jul 16, 2011 at 03:24, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Just out of curiousity and because I happen to know we have Googlers
> here. If it's not confidential, are there any changes in git to make
> it work with Google Code? I am particularly interested in whether
> Google modifies git to use bigtable

A major milestone in Git was adding smart HTTP. If you watch the talk
Sverre linked to, you will learn that Google is based heavily on HTTP.
A fundamental issue at the time Hg on Google Code was added was Git
didn't really work well over HTTP. Adding smart HTTP in Git 1.6.6 made
it more realistic for Google to support Git on Project Hosting. I
added smart HTTP support for kernel.org so their users behind
firewalls could still use an efficient Git protocol to fetch revisions
from kernel.org for projects that are hosted there. Its a nice bonus
that this work made Git on Google Code more realistic for Google.

We are trying to get the engineer responsible for making Git on Google
Code possible to give a recorded tech talk like the one Sverre linked
to. I don't want to steal his thunder, but I can say the Git on Google
Code work is not based on C Git or JGit.  :-)

> (or cassandra, I remember Shawn
> had a prototype).

This was an unrelated project, and is what I deem to be a failure...
quite unlike Git on Google Code. :-)

For some background, at GitTogether in Oct. 2010 I showed a demo of
JGit using the Apache Cassandra database as an object / reference
store. This prototype didn't really scale well; even though I demoed
the linux-2.6 repository being cloned through a JGit daemon using
Cassandra as the backing store, it was slow and used too much CPU and
memory resources to be useful in any context beyond a "Look, I can do
this!" demo. I managed to open source this work, it may still be
laying around somewhere, but I basically threw it out the window and
said "that isn't good, and I can't believe I put my name on it!". (And
for the record I was not the first to try this, Scott Chacon at GitHub
tried something similar first and demoed it at GitTogether in 2009.)

In late Jan/Feb 2011 I released a series of patches for JGit that
added what I called "DHT" (distributed hash table) support. These
patches are now part of the JGit project. Its different from the
original Cassandra prototype. With this work, JGit tries to treat the
DHT as though it were a virtual memory system. Relatively standard
pack files are segmented into ~ 1 MiB chunks, then stored into the DHT
with row keys based on the SHA-1 hash of the content of the "pack
chunk". The bet here is that the locality of data in a pack file is
quite good, so loading a chunk of commits ~1 MiB in size should get us
a number of related commits, amortizing out the round-trip time to the
database. This was to resolve one of the latency problems I saw with
the Cassandra prototype, which stored 1 commit per row and had awful
performance during a major revision traversal like a clone has.

The JGit DHT work lead me to discover the pack locality is not as good
as we think it is. Its good, but it can be better. I added some
patches to JGit's PackWriter to reorder objects in an order that gave
better data locality. After Junio and I started sharing an office, I
began nagging him about this locality problem in Git pack files... and
that nagging lead to a series of patches Junio posted about a week
back to improve pack-objects.c. The improvement is small on local
disk, it reduces some minor page faults, however there isn't much
difference in overall running time. Over higher latency filesystems
however, like an NFS server in another city, it should help reading.

Just recently I posted a message to the jgit-dev mailing list saying I
also now think JGit DHT isn't a viable solution, and am likely to
discard it in the future. Its implementation is very complicated, and
it just doesn't perform as well as I had hoped. FWIW, this work was
not for Google, but was for open source Git hosting sites like
source.android.com, eclipse.org, KDE, etc. where they need to manage a
large number of Git repositories, and want to have hot-failover and
load-balancing to reduce down time caused by hardware failures.
Unfortunately it hasn't been panning out, because the performance loss
is a lot compared to the small administrative improvements it might
bring. Not to mention the additional complexity of running the
clustered database vs. just a bunch of Git repositories in a
directory.


I can tell you that none of this is what Git for Google Code does.

As for how Git on Google Code is implemented... you'll just have to
wait for the tech talk from the engineer responsible. I can say it
wasn't me, and it wasn't Junio. I am too busy with JGit and Gerrit
Code Review, and Junio is too busy being Git maintainer to work on a
major new feature like this.

:-)

-- 
Shawn.

^ permalink raw reply	[relevance 3%]

* [PATCH] smart-http: Don't use Expect: 100-Continue
@ 2011-02-15 16:57  3% Shawn O. Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn O. Pearce @ 2011-02-15 16:57 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Tay Ray Chuan

Some HTTP/1.1 servers or proxies don't correctly implement the
100-Continue feature of HTTP/1.1.  Its a difficult feature to
implement right, and isn't commonly used by browsers, so many
developers may not even be aware that their server (or proxy)
doesn't honor it.

Within the smart HTTP protocol for Git we only use this newer
"Expect: 100-Continue" feature to probe for missing authentication
before uploading a large payload like a pack file during push.
If authentication is necessary, we expect the server to send the
401 Not Authorized response before the bulk data transfer starts,
thus saving the client bandwidth during the retry.

A different method to probe for working authentication is to send an
empty command list (that is just "0000") to $URL/git-receive-pack.
or $URL/git-upload-pack.  All versions of both receive-pack and
upload-pack since the introduction of smart HTTP in Git 1.6.6
cleanly accept just a flush-pkt under --stateless-rpc mode, and
exit with success.

If HTTP level authentication is successful, the backend will return
an empty response, but with HTTP status code 200.  This enables
the client to continue with the transfer.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 remote-curl.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++---------
 1 files changed, 55 insertions(+), 11 deletions(-)

diff --git a/remote-curl.c b/remote-curl.c
index 04d4813..3d82dc2 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -356,14 +356,59 @@ static size_t rpc_in(const void *ptr, size_t eltsize,
 	return size;
 }
 
+static int run_slot(struct active_request_slot *slot)
+{
+	int err = 0;
+	struct slot_results results;
+
+	slot->results = &results;
+	slot->curl_result = curl_easy_perform(slot->curl);
+	finish_active_slot(slot);
+
+	if (results.curl_result != CURLE_OK) {
+		err |= error("RPC failed; result=%d, HTTP code = %ld",
+			results.curl_result, results.http_code);
+	}
+
+	return err;
+}
+
+static int probe_rpc(struct rpc_state *rpc)
+{
+	struct active_request_slot *slot;
+	struct curl_slist *headers = NULL;
+	struct strbuf buf = STRBUF_INIT;
+	int err;
+
+	slot = get_active_slot();
+
+	headers = curl_slist_append(headers, rpc->hdr_content_type);
+	headers = curl_slist_append(headers, rpc->hdr_accept);
+
+	curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+	curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
+	curl_easy_setopt(slot->curl, CURLOPT_URL, rpc->service_url);
+	curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "");
+	curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, "0000");
+	curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDSIZE, 4);
+	curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
+	curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+	curl_easy_setopt(slot->curl, CURLOPT_FILE, buf);
+
+	err = run_slot(slot);
+
+	curl_slist_free_all(headers);
+	strbuf_release(&buf);
+	return err;
+}
+
 static int post_rpc(struct rpc_state *rpc)
 {
 	struct active_request_slot *slot;
-	struct slot_results results;
 	struct curl_slist *headers = NULL;
 	int use_gzip = rpc->gzip_request;
 	char *gzip_body = NULL;
-	int err = 0, large_request = 0;
+	int err, large_request = 0;
 
 	/* Try to load the entire request, if we can fit it into the
 	 * allocated buffer space we can use HTTP/1.0 and avoid the
@@ -386,8 +431,13 @@ static int post_rpc(struct rpc_state *rpc)
 		rpc->len += n;
 	}
 
+	if (large_request) {
+		err = probe_rpc(rpc);
+		if (err)
+			return err;
+	}
+
 	slot = get_active_slot();
-	slot->results = &results;
 
 	curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
 	curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
@@ -401,7 +451,7 @@ static int post_rpc(struct rpc_state *rpc)
 		/* The request body is large and the size cannot be predicted.
 		 * We must use chunked encoding to send it.
 		 */
-		headers = curl_slist_append(headers, "Expect: 100-continue");
+		headers = curl_slist_append(headers, "Expect:");
 		headers = curl_slist_append(headers, "Transfer-Encoding: chunked");
 		rpc->initial_buffer = 1;
 		curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);
@@ -475,13 +525,7 @@ static int post_rpc(struct rpc_state *rpc)
 	curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
 	curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
 
-	slot->curl_result = curl_easy_perform(slot->curl);
-	finish_active_slot(slot);
-
-	if (results.curl_result != CURLE_OK) {
-		err |= error("RPC failed; result=%d, HTTP code = %ld",
-			results.curl_result, results.http_code);
-	}
+	err = run_slot(slot);
 
 	curl_slist_free_all(headers);
 	free(gzip_body);
-- 
1.7.4.rc3.268.g2af8b

^ permalink raw reply related	[relevance 3%]

* [PATCH 1/4 v2] fetch-pack: Finish negotation if remote replies "ACK %s ready"
@ 2011-03-15  0:59  3% Shawn O. Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn O. Pearce @ 2011-03-15  0:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

If multi_ack_detailed was selected in the protocol capabilities
(both client and server are >= Git 1.6.6) the upload-pack side will
send "ACK %s ready" when it knows how to safely cut the graph and
produce a reasonable pack for the want list that was already sent
on the connection.

Upon receiving "ACK %s ready" there is no point in looking at
the remaining commits inside of rev_list.  Sending additional
"have %s" lines to the remote will not construct a smaller pack.
It is unlikely a commit older than the current cut point will have
a better delta base than the cut point itself has.

The original design of this code had fetch-pack empty rev_list by
marking a commit and its transitive ancestors COMMON whenever the
remote side said "ACK %s {continue,common}" and skipping over any
already COMMON commits during get_rev().  This approach does not
work when most of rev_list is actually COMMON_REF, commits that
are pointed to by a reference on the remote, which exist locally,
and which have not yet been sent to the remote as a "have %s" line.

Most of the common references are tags in the ref/tags namespace,
using points in the commit graph that are more than 1 commit apart.
In git.git itself, this is currently 340 tags, 339 of which point to
commits in the commit graph.  fetch-pack pushes all of these into
rev_list, but is unable to mark them COMMON and discard during a
remote's "ACK %s {continue,common}" because it does not parse through
the entire parent chain.  Not parsing the entire parent chain is
an optimization to avoid walking back to the roots of the repository.

Assuming the client is only following the remote (and does not make
its own local commits), the client needs 11 rounds to spin through
the entire list of tags (32 commits per round, ceil(339/32) == 11).
Unfortunately the server knows on the first "have %s" line that
it can produce a good pack, and does not need to see the remaining
320 tags in the other 10 rounds.

Over git:// and ssh:// this isn't as bad as it sounds, the client is
only transmitting an extra 16,000 bytes that it doesn't need to send.

Over smart HTTP, the client must do an additional 10 HTTP POST
requests, each of which incurs round-trip latency, and must upload
the entire state vector of all known common objects.  On the final
POST request, this is 16 KiB worth of data.

Fix all of this by clearing rev_list as soon as the remote side
says it can construct a pack.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---

 Fixed bad indentation that appeared in v1.

 builtin/fetch-pack.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index b999413..5173dc9 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -379,6 +379,8 @@ static int find_common(int fd[2], unsigned char *result_sha1,
 					retval = 0;
 					in_vain = 0;
 					got_continue = 1;
+					if (ack == ACK_ready)
+						rev_list = NULL;
 					break;
 					}
 				}
-- 
1.7.4.1.35.ga52fb.dirty

^ permalink raw reply related	[relevance 3%]

* [PATCH 1/2] fetch-pack: Finish negotation if remote replies "ACK %s ready"
@ 2011-03-14 23:48  3% Shawn O. Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn O. Pearce @ 2011-03-14 23:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

If multi_ack_detailed was selected in the protocol capabilities
(both client and server are >= Git 1.6.6) the upload-pack side will
send "ACK %s ready" when it knows how to safely cut the graph and
produce a reasonable pack for the want list that was already sent
on the connection.

Upon receiving "ACK %s ready" there is no point in looking at
the remaining commits inside of rev_list.  Sending additional
"have %s" lines to the remote will not construct a smaller pack.
It is unlikely a commit older than the current cut point will have
a better delta base than the cut point itself has.

The original design of this code had fetch-pack empty rev_list by
marking a commit and its transitive ancestors COMMON whenever the
remote side said "ACK %s {continue,common}" and skipping over any
already COMMON commits during get_rev().  This approach does not
work when most of rev_list is actually COMMON_REF, commits that
are pointed to by a reference on the remote, which exist locally,
and which have not yet been sent to the remote as a "have %s" line.

Most of the common references are tags in the ref/tags namespace,
using points in the commit graph that are more than 1 commit apart.
In git.git itself, this is currently 340 tags, 339 of which point to
commits in the commit graph.  fetch-pack pushes all of these into
rev_list, but is unable to mark them COMMON and discard during a
remote's "ACK %s {continue,common}" because it does not parse through
the entire parent chain.  Not parsing the entire parent chain is
an optimization to avoid walking back to the roots of the repository.

Assuming the client is only following the remote (and does not make
its own local commits), the client needs 11 rounds to spin through
the entire list of tags (32 commits per round, ceil(339/32) == 11).
Unfortunately the server knows on the first "have %s" line that
it can produce a good pack, and does not need to see the remaining
320 tags in the other 10 rounds.

Over git:// and ssh:// this isn't as bad as it sounds, the client is
only transmitting an extra 16,000 bytes that it doesn't need to send.

Over smart HTTP, the client must do an additional 10 HTTP POST
requests, each of which incurs round-trip latency, and must upload
the entire state vector of all known common objects.  On the final
POST request, this is 16 KiB worth of data.

Fix all of this by clearing rev_list as soon as the remote side
says it can construct a pack.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 builtin/fetch-pack.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index b999413..dfacfdf 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -379,6 +379,8 @@ static int find_common(int fd[2], unsigned char *result_sha1,
 					retval = 0;
 					in_vain = 0;
 					got_continue = 1;
+					if (ack == ACK_ready)
+					  rev_list = NULL;
 					break;
 					}
 				}
-- 
1.7.0.9.5.g6bd7.dirty

^ permalink raw reply related	[relevance 3%]

* Re: gitk: Show notes
  @ 2010-05-12  8:56  3%   ` Kirill Smelkov
  0 siblings, 0 replies; 55+ results
From: Kirill Smelkov @ 2010-05-12  8:56 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: Paul Mackerras, git

On Tue, May 11, 2010 at 04:35:45PM +0200, Michael J Gruber wrote:
> Kirill Smelkov venit, vidit, dixit 11.05.2010 10:26:
> > If in git.git I do
> > 
> >     $ git notes add -m 'This makes status significantly slower with Dokko' \
> >         ee6fc514
> > 
> > then `git log` shows the note...
> > 
> 
> because --show-notes is the default...
> 
> > ... but unfortunately gitk does not.
> 
> ... unless --pretty is given, and gitk uses --pretty.
> 
> But what is wrong with gitk --show-notes?

Sorry, you are right. I learned notes just yesterday and forgot one can
pass such options to gitk.

> If you mean to adjust gitk's default to log's current default please say
> so in the commit message. There's no need to include a longish sample
> output for that.

Ok, agree.

> Also, I don't think proc do_readcommit needs the notes. The other two
> places use $args, so it might make sense to prepend --show-notes to the
> arg list in a central place.

Right.

I've tried to rework the patch -- only I could not find a better way to
prepend --show-notes to arg, than just define $show_notes based on
$git_version and use it in 2 appropriate places.

Also, --show-notes was introduced in git-1.6.6.2, but our $git_version
is 3 digits only, so this will be really enabled for git-1.7.0 .


Thanks for the review, and maybe there is a better way to do it?

Kirill


---- 8< ----

From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Tue, 11 May 2010 12:17:11 +0400
Subject: [PATCH] gitk: Show notes by default (like git log do)

Starting from ~ git-1.6.6, log, show & whatchanged show notes by default.

On the other hand, gitk does not show notes by default, because under
the hood it calls `git log --pretty=raw ...` to get the log, and in
`git log` notes are turned off, when user specifies format or pretty
settings.

Yes, it is possible to invoke `gitk --show-notes` explicitly, but since
from user's perspective, gitk is gui enabled git log, it would be
logical for gitk to show notes by default too for consistency.

In git, --show-notes was introduced in 66b2ed (Fix "log" family not to
be too agressive about showing notes) which predates 1.6.6.2

Notes can still be supressed with `gitk --no-notes`.

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
 gitk |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/gitk b/gitk
index 1b0e09a..45e3380 100755
--- a/gitk
+++ b/gitk
@@ -313,6 +313,7 @@ proc start_rev_list {view} {
     global viewactive viewinstances vmergeonly
     global mainheadid viewmainheadid viewmainheadid_orig
     global vcanopt vflags vrevs vorigargs
+    global show_notes
 
     set startmsecs [clock clicks -milliseconds]
     set commitidx($view) 0
@@ -361,8 +362,8 @@ proc start_rev_list {view} {
     }
 
     if {[catch {
-	set fd [open [concat | git log --no-color -z --pretty=raw --parents \
-			 --boundary $args "--" $files] r]
+	set fd [open [concat | git log --no-color -z --pretty=raw $show_notes \
+			--parents --boundary $args "--" $files] r]
     } err]} {
 	error_popup "[mc "Error executing git log:"] $err"
 	return 0
@@ -456,6 +457,7 @@ proc updatecommits {} {
     global mainheadid viewmainheadid viewmainheadid_orig pending_select
     global isworktree
     global varcid vposids vnegids vflags vrevs
+    global show_notes
 
     set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
     rereadrefs
@@ -508,8 +510,8 @@ proc updatecommits {} {
 	set args $vorigargs($view)
     }
     if {[catch {
-	set fd [open [concat | git log --no-color -z --pretty=raw --parents \
-			  --boundary $args "--" $vfilelimit($view)] r]
+	set fd [open [concat | git log --no-color -z --pretty=raw $show_notes \
+			--parents --boundary $args "--" $vfilelimit($view)] r]
     } err]} {
 	error_popup "[mc "Error executing git log:"] $err"
 	return
@@ -11521,6 +11523,11 @@ set NS [expr {$use_ttk ? "ttk" : ""}]
 
 set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
 
+set show_notes {}
+if {[package vcompare $git_version "1.6.6.2"] >= 0} {
+    set show_notes "--show-notes"
+}
+
 set runq {}
 set history {}
 set historyindex 0
-- 
1.7.1.91.ga63a7

^ permalink raw reply related	[relevance 3%]

* [PATCH v2] gitk: Show notes by default (like git log do)
@ 2010-05-20  9:50  3% Kirill Smelkov
  2010-05-30  2:22  0% ` Paul Mackerras
  0 siblings, 1 reply; 55+ results
From: Kirill Smelkov @ 2010-05-20  9:50 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: git, Kirill Smelkov, Michael J Gruber

Starting from ~ git-1.6.6, log, show & whatchanged show notes by default.

On the other hand, gitk does not show notes by default, because under
the hood it calls `git log --pretty=raw ...` to get the log, and in
`git log` notes are turned off, when user specifies format or pretty
settings.

Yes, it is possible to invoke `gitk --show-notes` explicitly, but since
from user's perspective, gitk is gui enabled git log, it would be
logical for gitk to show notes by default too for consistency.

In git, --show-notes was introduced in 66b2ed (Fix "log" family not to
be too agressive about showing notes) which predates 1.6.6.2

Notes can still be supressed with `gitk --no-notes`.

Cc: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
 gitk |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

Changes since first post:

 o as suggested by Michael, removed --show-notes from do_readcommit

 o as suggested by Michael, tried to put --show-notes arg into a central place

 o --show-notes is only used for git >= 1.6.6.2 (though because $git_version
   has only 3 digits, this may turn to be actually activated only from
   git >= 1.7.0)

diff --git a/gitk b/gitk
index 1b0e09a..45e3380 100755
--- a/gitk
+++ b/gitk
@@ -313,6 +313,7 @@ proc start_rev_list {view} {
     global viewactive viewinstances vmergeonly
     global mainheadid viewmainheadid viewmainheadid_orig
     global vcanopt vflags vrevs vorigargs
+    global show_notes
 
     set startmsecs [clock clicks -milliseconds]
     set commitidx($view) 0
@@ -361,8 +362,8 @@ proc start_rev_list {view} {
     }
 
     if {[catch {
-	set fd [open [concat | git log --no-color -z --pretty=raw --parents \
-			 --boundary $args "--" $files] r]
+	set fd [open [concat | git log --no-color -z --pretty=raw $show_notes \
+			--parents --boundary $args "--" $files] r]
     } err]} {
 	error_popup "[mc "Error executing git log:"] $err"
 	return 0
@@ -456,6 +457,7 @@ proc updatecommits {} {
     global mainheadid viewmainheadid viewmainheadid_orig pending_select
     global isworktree
     global varcid vposids vnegids vflags vrevs
+    global show_notes
 
     set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
     rereadrefs
@@ -508,8 +510,8 @@ proc updatecommits {} {
 	set args $vorigargs($view)
     }
     if {[catch {
-	set fd [open [concat | git log --no-color -z --pretty=raw --parents \
-			  --boundary $args "--" $vfilelimit($view)] r]
+	set fd [open [concat | git log --no-color -z --pretty=raw $show_notes \
+			--parents --boundary $args "--" $vfilelimit($view)] r]
     } err]} {
 	error_popup "[mc "Error executing git log:"] $err"
 	return
@@ -11521,6 +11523,11 @@ set NS [expr {$use_ttk ? "ttk" : ""}]
 
 set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
 
+set show_notes {}
+if {[package vcompare $git_version "1.6.6.2"] >= 0} {
+    set show_notes "--show-notes"
+}
+
 set runq {}
 set history {}
 set historyindex 0
-- 
1.7.1.91.ga63a7

^ permalink raw reply related	[relevance 3%]

* Portability patches vs 1.7.0.2 [5/6]
@ 2010-03-09 16:19  4% Gary V. Vaughan
  0 siblings, 0 replies; 55+ results
From: Gary V. Vaughan @ 2010-03-09 16:19 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

## sockaddr_t->ss_family is not portable

Many of our supported platforms do not have this declaration, for
example solaris2.6 thru 2.8 (I can find a complete list of which of
our supported platforms have this problem).

Normally, I would solve this by importing the relevant modules from
gnulib and linking in the portable equivalent (hence the name of the
patch: gnulib.patch).  But in this case, since git is not built using
Automake, I decided that it would be easier to simply revert the part
of the code that was triggering this problem back to what was used in
git-1.6.6. So that is what this patch represents.

Actually, I'd like some advice on whether this was a good idea?  Was
the change to the code in git-1.7.0 introduced in response to a bug
(latent or reported) that is fixed by the code I reverted in this
patch?  If so, what is the right way to fix it (assuming you don't
want to introduce a dependency on gnulib and Automake into git)?

Cheers,
-- 
Gary V. Vaughan (gary@thewrittenword.com)

[-- Attachment #2: gnulib.patch --]
[-- Type: text/x-diff, Size: 1508 bytes --]

Index: daemon.c
===================================================================
--- daemon.c.orig
+++ daemon.c
@@ -588,24 +588,6 @@ static int execute(struct sockaddr *addr
 	return -1;
 }
 
-static int addrcmp(const struct sockaddr_storage *s1,
-    const struct sockaddr_storage *s2)
-{
-	if (s1->ss_family != s2->ss_family)
-		return s1->ss_family - s2->ss_family;
-	if (s1->ss_family == AF_INET)
-		return memcmp(&((struct sockaddr_in *)s1)->sin_addr,
-		    &((struct sockaddr_in *)s2)->sin_addr,
-		    sizeof(struct in_addr));
-#ifndef NO_IPV6
-	if (s1->ss_family == AF_INET6)
-		return memcmp(&((struct sockaddr_in6 *)s1)->sin6_addr,
-		    &((struct sockaddr_in6 *)s2)->sin6_addr,
-		    sizeof(struct in6_addr));
-#endif
-	return 0;
-}
-
 static int max_connections = 32;
 
 static unsigned int live_children;
@@ -625,7 +607,7 @@ static void add_child(pid_t pid, struct 
 	newborn->pid = pid;
 	memcpy(&newborn->address, addr, addrlen);
 	for (cradle = &firstborn; *cradle; cradle = &(*cradle)->next)
-		if (!addrcmp(&(*cradle)->address, &newborn->address))
+		if (!memcmp(&(*cradle)->address, &newborn->address, sizeof(newborn->address)))
 			break;
 	newborn->next = *cradle;
 	*cradle = newborn;
@@ -658,7 +640,7 @@ static void kill_some_child(void)
 		return;
 
 	for (; (next = blanket->next); blanket = next)
-		if (!addrcmp(&blanket->address, &next->address)) {
+		if (!memcmp(&blanket->address, &next->address, sizeof(next->address))) {
 			kill(blanket->pid, SIGTERM);
 			break;
 		}

^ permalink raw reply	[relevance 4%]

* Re: 16 gig, 350,000 file repository
  @ 2010-02-22 22:20  4%               ` Bill Lear
  2010-02-22 22:31  0%                 ` Nicolas Pitre
  0 siblings, 1 reply; 55+ results
From: Bill Lear @ 2010-02-22 22:20 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git

On Thursday, February 18, 2010 at 15:58:42 (-0500) Nicolas Pitre writes:
>On Thu, 18 Feb 2010, Bill Lear wrote:
>
>> I'm starting a new, large project and would like a quick bit of advice.
>> 
>> Bringing in a set of test cases and other files from a ClearCase
>> repository resulted in a 350,000 file git repo of about 16 gigabytes.
>> 
>> The time to clone over a fast network was about 250 minutes.  I could
>> not verify if the repo had been packed properly, etc.
>
>I'd start from there.  If you didn't do a 'git gc --aggressive' after 
>the import then it is quite likely that your repo isn't well packed.
>
>Of course you'll need a big machine to repack this.  But that should be 
>needed only once.

Ok, well they have a "big machine", but not big enough.  It's running
out of memory on the gc.  I believe they have a fair amount of memory:

% free
             total       used       free     shared    buffers     cached
Mem:      16629680   16051444     578236          0      28332   14385948
-/+ buffers/cache:    1637164   14992516
Swap:      8289500       1704    8287796

and they are using git 1.6.6.

Assuming we can figure out how to gc this puppy (is there any way on a
machine without 64 gigabytes?), there is still a question that
remains: how to organize a project that has a very large amount of
test cases (and test data) that we might not want to pull across the
wire each time.  Instead of shallow clone, as sort of slicing clone
operation?

We thought of using submodules.  That is, code (say) goes in a separate
repo 'src' and functional tests go in another, called 'ftests'.  Then,
we add 'ftests' as a submodule to 'src'.  Great.  However, we need to
be able to branch 'src' and 'ftests' together.  Example: I am working on
a new feature in a branch "GLX-473_incremental_compression".  I would like
to be able to create the branch in both the 'src' repo and the 'ftests'
repo at the same time, make changes, commit, and push to that branch for
both.  When developers check out the repo, they move to that branch, but
do NOT want the cloned ftests.  However, the QA team wants both the source
and the tests that I have checked in and pushed.

Is there an easy way to support this?


Bill

^ permalink raw reply	[relevance 4%]

* [PATCH] Fix segfault in fast-export
@ 2010-01-07  3:58  4% Mike Mueller
  2010-01-18 17:44  0% ` Heiko Voigt
  0 siblings, 1 reply; 55+ results
From: Mike Mueller @ 2010-01-07  3:58 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Hi all,

I'm working on a C++ static analyzer (Vigilant Sentry), and git
is one of my test subjects.  In git-1.6.6, I found a crash in the
fast-export command:

The problem is in builtin-fast-export.c, function export_marks:

    f = fopen(file, "w");
    if (!f)
        error("Unable to open marks file %s for writing.", file);
   
    for (i = 0; i < idnums.size; i++) {
        if (deco->base && deco->base->type == 1) {
            mark = ptr_to_mark(deco->decoration);
            if (fprintf(f, ":%"PRIu32" %s\n", mark,
                sha1_to_hex(deco->base->sha1)) < 0) {
                e = 1;
                break;
            }
        }
        deco++;
    }
   
    e |= ferror(f);
    e |= fclose(f);

If fopen() fails, the error message is printed, but the function
doesn't exit.  The subsequent calls to fprintf and/or ferror will
fail because f is NULL.  A simple way to reproduce is to export
to a path you don't have write access to:
   
    $ git fast-export --export-marks=/foo
    error: Unable to open marks file /foo for writing.
    Segmentation fault (core dumped)

I've attached a trivial patch that calls die_errno instead of
error, so the program exits if f is NULL.

Regards,
Mike

-- 
Mike Mueller
mmueller@vigilantsw.com

http://www.vigilantsw.com/

[-- Attachment #2: git-fast-export.patch --]
[-- Type: text/x-diff, Size: 449 bytes --]

diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index b0a4029..963e89b 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -503,7 +503,7 @@ static void export_marks(char *file)
 
 	f = fopen(file, "w");
 	if (!f)
-		error("Unable to open marks file %s for writing.", file);
+		die_errno("Unable to open marks file %s for writing", file);
 
 	for (i = 0; i < idnums.size; i++) {
 		if (deco->base && deco->base->type == 1) {

^ permalink raw reply related	[relevance 4%]

* git stash pop not reapplying deletions
@ 2010-02-14 19:45  4% Steve Folly
  2010-02-14 22:08  0% ` Thomas Rast
  0 siblings, 1 reply; 55+ results
From: Steve Folly @ 2010-02-14 19:45 UTC (permalink / raw)
  To: git

Hi,

I'm not sure if I've found a bug in 'git stash' or if I'm using 
it the wrong way? (This is with git 1.6.6):

$ git init stashtest
$ cd stashtest
$ mkdir dira
$ touch dira/a dira/b dira/c
$ git stage dira
$ git commit -m "added dira"
$ git mv dira dirb
$ git status   # correctly shows renames

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	renamed:    dira/a -> dirb/a
#	renamed:    dira/b -> dirb/b
#	renamed:    dira/c -> dirb/c
#

$ git stash
$ git stash pop

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   dirb/a
#	new file:   dirb/b
#	new file:   dirb/c
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be 
committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	deleted:    dira/a
#	deleted:    dira/b
#	deleted:    dira/c
#
Dropped refs/stash@{0} (cf9efdede3a3ee8e078192b574520fd2ed7f3d9b)

It's added the new files in dirb but hasn't deleted the old files in dira. Is
this right?

Regards,
Steve

^ permalink raw reply	[relevance 4%]

* Re: cannot fetch arm git tree
  @ 2011-01-21 13:38  4%         ` Detlef Vollmann
  2011-01-21 13:47  0%           ` Uwe Kleine-König
  0 siblings, 1 reply; 55+ results
From: Detlef Vollmann @ 2011-01-21 13:38 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: linux-arm-kernel, Jello huang, git, Uwe Kleine-König

On 01/16/11 14:42, Russell King - ARM Linux wrote:
> Let's say you already have a copy of my tree from a month ago, and Linus
> has pulled some work from me into his tree, and repacked his tree into one
> single pack file.  At the moment, the largest pack file from Linus is
> 400MB plus a 50MB index.
>
> You already have most of the contents of that 400MB pack file, but if
> you're missing even _one_ object which is contained within it, git will
> have to download the _entire_ 400MB pack file and index file to retrieve
> it.
I thought this has changed with "smart http" in git 1.6.6.
Am I missing something?

   Detlef

^ permalink raw reply	[relevance 4%]

* Re: git smart protocol via WebSockets - feedback wanted
  @ 2012-06-05 18:41  4%   ` Stephan Peijnik
  2012-06-05 18:54  0%     ` Shawn Pearce
  0 siblings, 1 reply; 55+ results
From: Stephan Peijnik @ 2012-06-05 18:41 UTC (permalink / raw)
  To: git

On 06/05/2012 08:31 PM, Junio C Hamano wrote:
> How does this compare with the smart-http support that tunnels the
> git protocol over http (with some butchering)?

To be honest, I didn't know smart-http support yet. Is that the approach 
introduced with git 1.6.6?

If so, that approach uses multiple POST requests, meaning multiple TCP 
and HTTP connections need to be established, multiple requests 
processed, etc.

The WebSocket approach uses a single HTTP connection which gets upgraded 
to a WebSocket. This WebSocket then allows the same communication to 
happen as with the ssh implementation.

So in comparison there is possibly a lot less overhead and, in theory, 
the performance should be comparable to running the smart protocol over 
ssh. Personally I'd say the WebSocket approach is cleaner than the 
HTTP-POST approach.

-- Stephan

^ permalink raw reply	[relevance 4%]

* Re: simplest git deamon?
  @ 2010-04-12 14:22  4% ` Shawn O. Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn O. Pearce @ 2010-04-12 14:22 UTC (permalink / raw)
  To: Mihamina Rakotomandimby; +Cc: git

Mihamina Rakotomandimby <mihamina@gulfsat.mg> wrote:
> Manao ahoana, Hello, Bonjour,
> 
> I would like to setup a git repository, on a Debian machine.
> I would like to access it only with git:// (no http://, no ssh://,...)
> 
> How to implement read/write restriction when just wanting to use
> "git://" without dealing with SSH?
> 
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html, at it's
> bottom tlak about this but it requires SSH.
> https://help.ubuntu.com/community/Git talks about gitosis, but it
> requires keys.
> 
> I have the GIT repository setup, with the "git://"-only access scheme, 
> but anyone may push into this.
> 
> I expected just a flat file the SVN way (But I dont want to use SVN):

Git isn't SVN.

The git:// daemon is *anonymous*.  It has no authentication
capability, nor will it probably ever learn how to authenticate
users.  Consequently you can't do what you want with it.

Instead of reinventing the wheel poorly, Git relies on external
servers to perform the authentication.  So if you want authenticated
access, you will need to use either SSH or HTTP.

If you use SSH, lots of people get by with Gitosis, as its fairly
simple to configure.  Another option is to use something much more
complex like Gerrit Code Review[1] that contains its own SSH server.

If you use HTTP, use the newer git-http-backend[2] that was
introduced in Git 1.6.6 (or later), running behind an Apache
HTTP server.

[1] http://code.google.com/p/gerrit/
[2] http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
 
-- 
Shawn.

^ permalink raw reply	[relevance 4%]

* How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)?
       [not found]     <b507cb050912132222x7e1daa9cw73b13f3db0ee22c6@mail.gmail.com>
@ 2009-12-14  6:25  4% ` Doug Ireton
  2009-12-14  7:55  0%   ` Matthieu Moy
  0 siblings, 1 reply; 55+ results
From: Doug Ireton @ 2009-12-14  6:25 UTC (permalink / raw)
  To: git

I am using the latest version of Git (1.6.6) on a Mac. My wife wants
to use Git to manage her fiction writing as long as she can still use
Microsoft Word 2008 (Mac). Instead of pushing her into saving
everything as plain text, I would like to use Git Difftool to pass the
files to Word and use Word's Compare Documents feature. She wouldn't
be able to use Git Diff since Word docs are binary files but she could
still use Git Difftool.

I have written an Applescript which takes two filenames in this
format: /Users/foo/Documents/my_novel.docx and opens Word to do the
file comparison. However, Git Difftool seems to only pass the bare
filenames (e.g. my_novel.docx) as parameters.

Is there anyway to get the full filenames from Git Difftool?

Thanks,

Doug Ireton

^ permalink raw reply	[relevance 4%]

* unchecked mallocs
       [not found]     <D6F784B72498304C93A8A4691967698E8EE2C45016@REX2.intranet.epfl.ch>
@ 2010-01-08 21:59  4% ` Marinescu Paul dan
  0 siblings, 0 replies; 55+ results
From: Marinescu Paul dan @ 2010-01-08 21:59 UTC (permalink / raw)
  To: git@vger.kernel.org


While checking out the git code in xdiff/xpatience.c and xdiff/xmerge.c I
came across several (three) locations where the return values of xdl_malloc
(#defined as malloc) is not checked. Shouldn't this be done here?

In git 1.6.6 the calls are at

xmerge.c:567
merge.c:571
xpatience.c:191

Paul

^ permalink raw reply	[relevance 4%]

* Re: git smart protocol via WebSockets - feedback wanted
  @ 2012-06-05 18:36  4% ` Shawn Pearce
    1 sibling, 0 replies; 55+ results
From: Shawn Pearce @ 2012-06-05 18:36 UTC (permalink / raw)
  To: Stephan Peijnik; +Cc: git

On Tue, Jun 5, 2012 at 11:20 AM, Stephan Peijnik <stephan@peijnik.at> wrote:
> Since I have been working on a proof of concept showing that git's smart
> protocol can be tunneled via WebSocket connections quite easily [0] I wanted
> to ask for some feedback on the idea in general and on my implementation
> [1].
>
> So, basically, what do you think about tunneling git's smart protocol via
> WebSockets (and thus HTTP)?
...
> [0]
> http://blog.sp.or.at/2012/06/git-smart-protocol-via-websockets-proof.html
> [1] https://github.com/speijnik/gitws

How does this compare with the smart HTTP protocol that has been
supported since Git 1.6.6, and uses the git-http-backend CGI at the
server side?

^ permalink raw reply	[relevance 4%]

* Re: git fsck not identifying corrupted packs
  @ 2009-10-20 11:56  4%               ` Matthieu Moy
  2009-10-20 18:46  0%                 ` [RFC/PATCH] fsck: default to "git fsck --full" Junio C Hamano
  0 siblings, 1 reply; 55+ results
From: Matthieu Moy @ 2009-10-20 11:56 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Alex Riesen, Junio C Hamano, Johannes Sixt, Sergio Callegari, git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Tue, 20 Oct 2009, Alex Riesen wrote:
>
>> On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
>> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> >>> It probably is also a good idea to add a "--loose" option that does what
>> >>> "fsck" currently does without "--full".  It is a good name
>> 
>> --no-full works
>
> It works.  Technically.  For human users, though, --loose-objects-only 
> (with a shortcut "--loose") would be better.

OTOH, the advantage of "--no-full" is that it's compatible with
existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
in a script, then my stript works also with older Gits.

But anyway, I think very few people are actually interested in "git
--no-full" (or call it whatever you like), so I don't think this is
very important.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[relevance 4%]

* Re: [PATCH (resend 3)] git gui: Use git diff --submodule when available
  @ 2010-01-23 22:34  4% ` Shawn O. Pearce
  2010-01-23 22:42  0%   ` Jens Lehmann
  0 siblings, 1 reply; 55+ results
From: Shawn O. Pearce @ 2010-01-23 22:34 UTC (permalink / raw)
  To: Jens Lehmann; +Cc: Git Mailing List

Jens Lehmann <Jens.Lehmann@web.de> wrote:
> The necessary feature is present since 1.6.6, it would be good
> to have this patch in the next release (see numbers below).
> 
> Shawn, This is a third re-send, in case you missed the previous
> rounds. Thanks.

I didn't miss them, I just was ignoring git-gui patches for a while.
I only work on git-gui in short spurts.

I actually just applied a modified version of your patch, so diff
on submodules still works via submodule summary if git < 1.6.6.

-- 
Shawn.

^ permalink raw reply	[relevance 4%]

* Re: RFD: git-bzr: anyone interested?
  @ 2010-02-19 13:38  4%         ` Sverre Rabbelier
  2010-02-19 15:15  0%           ` Writing git remote helpers Gabriel
  0 siblings, 1 reply; 55+ results
From: Sverre Rabbelier @ 2010-02-19 13:38 UTC (permalink / raw)
  To: Gabriel; +Cc: git

Heya,

On Fri, Feb 19, 2010 at 13:52, Gabriel <g2p.code@gmail.com> wrote:
> FWIW, I'm interested in that remote-vcs code, but never figured out where it
> was published. TIA for pushing it.

The remote-helpers code is already in git.git, and has been since git
1.6.6 with some improvements now in 1.7.0.

> I'll be using it to better integrate fast-import based backup scripts.

Do you mean that you'll write a remote helper to import your backups?
If so then my code could be useful as a demonstration on how to hook
up a fast-import stream.

-- 
Cheers,

Sverre Rabbelier

^ permalink raw reply	[relevance 4%]

* Re: git-svn taking a long time
  @ 2010-02-10 16:59  4% ` Andrew Myrick
  0 siblings, 0 replies; 55+ results
From: Andrew Myrick @ 2010-02-10 16:59 UTC (permalink / raw)
  To: David Kågedal; +Cc: Git Mailing List

Give 1.7.0-rc2 a try.  It includes commit 8bff7c5383ed833bd1df9c8d85c00a27af3e5b02, which attempts to persistently cache a lot of the processing that git-svn has to do on subversion's merge tickets, which has improved my fetch times significantly.  

Note 1: git did not support subversion merge tickets before git-1.6.6, so there would be no slowdown if you use prior versions.

Note 2: you shouldn't need to clone your subversion repository from scratch.  git will create the caches the first time you fetch after upgrading (so the first fetch will be slow), and it will continue to use and update the caches thereafter.

-Andrew

On Feb 10, 2010, at 4:41 AM, David Kågedal wrote:

> I compiled the perl bindings from subversion 1.6.x, and git git version
> 1.7.0.rc0.52.g64ba.
> 
> I have imported a largish svn repo using "git svn fetch", which takes
> quite a long time (at least a day).
> 
> But my problems is that if I rerun "git svn fetch" again right after
> fetching, it will chew for hours before figuring out there are just a
> few new revisions to import. And the same if I try again.
> 
> I have another import from the same repo (on another machine, using
> slightly different versions of stuff) that doesn't have this problem.
> 
> So, does anyone have any suggestions for what could be done about this?
> 
> This is what the entry i .git/config looks like (url edited to protect
> the innocent)
> 
> [svn-remote "svn"]
>        url = svn://svn.server
>        branches = foo/branches/*:refs/remotes/svn/*
>        tags = foo/tags/*:refs/remotes/svn/tags/*
> 
> -- 
> David Kågedal
> --
> 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	[relevance 4%]

* git clone against firewall
@ 2010-01-14 23:45  4% Sebastian Pipping
  2010-01-15 18:17  0% ` Junio C Hamano
  0 siblings, 1 reply; 55+ results
From: Sebastian Pipping @ 2010-01-14 23:45 UTC (permalink / raw)
  To: git

hello!


with a firewall blocking outgoing connections to port 9418 a

  git clone git://...

of git 1.6.6 seems to never return, i.e. loop forever.  in my rather
automated environment (gentoo's tool layman calling git) this behavior
is rather troublesome - i need some kind of abort-and-error instead:
what i'm trying to do is loop over a number of clone URL alternatives of
the same repository like ..

  git://git.overlays.gentoo.org/dev/dberkholz.git
  http://git.overlays.gentoo.org/gitroot/dev/dberkholz.git
  git+ssh://git@git.overlays.gentoo.org/dev/dberkholz.git

.. and stop at the first clone that returns without error.

are there means to make git fail in such a case or to apply a timout?
if not please consider adding a related commandline option to git-clone.

thank you.



sebastian

^ permalink raw reply	[relevance 4%]

* Error when cloning gc'ed repository
@ 2010-01-20 10:45  5% Andre Loker
  0 siblings, 0 replies; 55+ results
From: Andre Loker @ 2010-01-20 10:45 UTC (permalink / raw)
  To: git

Hi,

First of all, my setup:

Server:
Win 2008
cygwin git 1.6.6, built from source
gitosis

Client:
Win 7
cygwin git 1.6.6, built from source

The server is hosting several repositories, they all work fine, except 
for one (at least I've experienced the following error with only one of 
the repos). For this repository, cloning fails if the repository has 
been repacked (or gc'ed) on the client side:

$ git clone git@theserver:the/repository.git
Initialized empty Git repository in /e/Temp/dr/.git/
remote: Counting objects: 1396, done.
remote: Compressing objects: 100% (654/654), done.
fatal: The remote end hung up unexpectedly
fatal: early EOFs:  47% (657/1396)
fatal: index-pack failed

However, if I unpack the objects completely and delete the pack file, I 
can clone the repository without any problem:

$ git clone git@theserver:the/repository.git
Initialized empty Git repository in /e/Temp/dr/.git/
remote: Counting objects: 1396, done.
remote: Compressing objects: 100% (1293/1293), done.
remote: Total 1396 (delta 639), reused 0 (delta 0)
Receiving objects: 100% (1396/1396), 4.99 MiB | 1.70 MiB/s, done.
Resolving deltas: 100% (639/639), done.

fsck shows no error

Does this problem sound familiar to anyone? May it's a network issue, 
but other repositories (also larger ones) work flawlessly even when in a 
packed state. Any help is appreciated!

Kind regards,
Andre Loker

P.S.:

Here's a trace:
$ GIT_TRACE=1 git clone git@theserver:the/repository.git
trace: built-in: git 'clone' 'git@theserver:the/repository.git'
Initialized empty Git repository in /e/Temp/dr/.git/
trace: run_command: 'ssh' 'git@theserver' 'git-upload-pack 
'\''the/repository.git'\'''
trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 5208 on Phobos'
trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 5208 on Phobos'
remote: Counting objects: 1396, done.
remote: Compressing objects:  19% (125/654)   race: exec: 
'git-index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 5208 on 
Phobos'
remote: Compressing objects:  21% (138/654)
remote: Compressing objects: 100% (654/654), done.
fatal: The remote end hung up unexpectedly
fatal: early EOFs:  88% (1229/1396), 4.76 MiB | 9.23 MiB/s
fatal: index-pack failed

And here's a trace of a successful run:

$ GIT_TRACE=1 git clone git@theserver:the/repository.git
trace: built-in: git 'clone' 'git@theserver:the/repository.git'
Initialized empty Git repository in /e/Temp/dr/.git/
trace: run_command: 'ssh' 'git@theserver' 'git-upload-pack 
'\''the/repository.git'\'''
trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 4624 on Phobos'
trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 4624 on Phobos'
trace: exec: 'git-index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 4624 on Phobos'
trace: run_command: 'git-index-pack' '--stdin' '-v' '--fix-thin' 
'--keep=fetch-pack 4624 on Phobos'
remote: Counting objects: 1396, done.
remote: Compressing objects: 100% (1293/1293), done.
remote: Total 1396 (delta 639), reused 0 (delta 0)
Receiving objects: 100% (1396/1396), 4.99 MiB | 1.68 MiB/s, done.
Resolving deltas: 100% (639/639), done.

^ permalink raw reply	[relevance 5%]

* git version statistics
@ 2012-05-31 11:48  5% Jeff King
  0 siblings, 0 replies; 55+ results
From: Jeff King @ 2012-05-31 11:48 UTC (permalink / raw)
  To: git

Just for fun, I've assembled a few statistics on git client versions
that hit github.com. These are collected from the http user-agent
strings provided by smart-http requests (we don't allow dumb http at all
these days, and the git protocol does not provide any version
information). It includes only the git/* entries (which are the vast
majority of clients hitting "info/refs?service=.*"; the second biggest
is JGit/*). And I counted each version only a single time from each IP
(so this would skew if you had a lot of clients behind a single IP;
their version would be counted only once).

Here are the results from the last few days:

  git/1.7.11.x |  0.1%   (0%) | 
  git/1.7.10.x | 21.1%  (21%) | **********************************
  git/1.7.9.x  | 11.4%  (32%) | ******************
  git/1.7.8.x  | 24.1%  (56%) | ****************************************
  git/1.7.7.x  | 12.2%  (68%) | ********************
  git/1.7.6.x  |  1.8%  (70%) | **
  git/1.7.5.x  |  8.2%  (78%) | *************
  git/1.7.4.x  |  7.2%  (86%) | ***********
  git/1.7.3.x  |  1.9%  (87%) | ***
  git/1.7.2.x  |  3.0%  (90%) | ****
  git/1.7.1.x  |  2.1%  (93%) | ***
  git/1.7.0.x  |  7.0%  (99%) | ***********
  git/1.6.6.x  |  0.0% (100%) | 

In this table, I've collapsed all of the x.y.z.* versions into a single
string to get an overview (a more detailed table is below). The first
percentage is the portion of the total requests; the second is a
cumulative portion (so, for example, 90% of clients are running v1.7.2.x
or higher, though only 3% are running v1.7.2.x itself).

Note that these numbers are skewed away from git versions lower than
v1.6.6, because that is when we added smart http support. Requests over
git:// or ssh are not included at all in these results.

For comparison, here's the same table from mid-September of 2011 (v1.7.7
was in -rc1 at the time):

  git/1.7.7.x |  0.2%   (0%) | 
  git/1.7.6.x | 19.3%  (19%) | *****************
  git/1.7.5.x |  8.0%  (27%) | *******
  git/1.7.4.x | 43.8%  (71%) | ****************************************
  git/1.7.3.x | 10.7%  (82%) | *********
  git/1.7.2.x |  4.9%  (86%) | ****
  git/1.7.1.x |  4.7%  (91%) | ****
  git/1.7.0.x |  8.2%  (99%) | *******
  git/1.6.6.x |  0.1% (100%) | 

So it seems that a large proportion of git users (or at least github
users) stay within a few versions of the most current. In both cases,
70% are within 4 major releases of the most recent version.

Here's a more detailed table (from recent data), showing individual
w.x.y.z versions:

  git/1.7.10.3 |  3.6%   (3%) | *******
  git/1.7.10.2 |  4.4%   (8%) | *********
  git/1.7.10.1 |  1.5%   (9%) | ***
  git/1.7.10   |  2.4%  (11%) | *****
  git/1.7.9.6  |  0.2%  (12%) | 
  git/1.7.9.5  |  9.2%  (21%) | *******************
  git/1.7.9.4  |  1.2%  (22%) | **
  git/1.7.9.3  |  0.3%  (22%) | 
  git/1.7.9.2  |  0.4%  (23%) | 
  git/1.7.9.1  |  0.4%  (23%) | 
  git/1.7.9    |  1.1%  (24%) | **
  git/1.7.8.6  |  0.3%  (25%) | 
  git/1.7.8.5  |  0.0%  (25%) | 
  git/1.7.8.4  |  0.7%  (25%) | *
  git/1.7.8.3  | 12.2%  (38%) | *************************
  git/1.7.8.2  | 18.8%  (56%) | ****************************************
  git/1.7.8.1  |  0.1%  (56%) | 
  git/1.7.8    |  0.3%  (57%) | 
  git/1.7.7.6  |  0.5%  (57%) | *
  git/1.7.7.4  |  0.2%  (57%) | 
  git/1.7.7.3  |  0.4%  (58%) | 
  git/1.7.7.2  |  0.1%  (58%) | 
  git/1.7.7.1  |  0.0%  (58%) | 
  git/1.7.7    |  0.7%  (59%) | *
  git/1.7.6.5  |  0.1%  (59%) | 
  git/1.7.6.4  |  0.2%  (59%) | 
  git/1.7.6.3  |  0.0%  (59%) | 
  git/1.7.6.1  |  0.5%  (59%) | *
  git/1.7.6    |  0.7%  (60%) | *
  git/1.7.5.4  | 10.9%  (71%) | ***********************
  git/1.7.5.3  |  0.1%  (71%) | 
  git/1.7.5.2  |  0.1%  (71%) | 
  git/1.7.5.1  |  0.2%  (71%) | 
  git/1.7.5    |  0.1%  (71%) | 
  git/1.7.4.5  |  0.4%  (72%) | 
  git/1.7.4.4  |  3.3%  (75%) | *******
  git/1.7.4.3  |  0.0%  (75%) | 
  git/1.7.4.2  |  0.0%  (75%) | 
  git/1.7.4.1  |  5.3%  (81%) | ***********
  git/1.7.4    |  0.2%  (81%) | 
  git/1.7.3.5  |  0.2%  (81%) | 
  git/1.7.3.4  |  1.2%  (82%) | **
  git/1.7.3.3  |  0.1%  (82%) | 
  git/1.7.3.2  |  0.4%  (83%) | 
  git/1.7.3.1  |  0.1%  (83%) | 
  git/1.7.3    |  0.1%  (83%) | 
  git/1.7.2.5  |  3.6%  (86%) | *******
  git/1.7.2.3  |  0.3%  (87%) | 
  git/1.7.2.2  |  0.1%  (87%) | 
  git/1.7.2.1  |  0.0%  (87%) | 
  git/1.7.2    |  0.1%  (87%) | 
  git/1.7.1.1  |  0.1%  (87%) | 
  git/1.7.1    |  2.8%  (90%) | ******
  git/1.7.0.6  |  0.0%  (90%) | 
  git/1.7.0.5  |  0.0%  (90%) | 
  git/1.7.0.4  |  7.0%  (97%) | **************
  git/1.7.0    |  2.6%  (99%) | *****
  git/1.6.6    |  0.0% (100%) | 

The interesting thing to me is how spiky it is, and where the spikes
fall. I would expect to see a spike around the highest maint release of
each major version (so v1.7.8.6, for example, with many fewer installs
of v1.7.8.5, v1.7.8.4, and so forth). But that's not what happens. The
most popular v1.7.8.x versions are .3 and .2, and hardly anybody
bothered to move to v1.7.8.6.

I can only assume these are skewed by some widely-used binary
distribution being locked onto particular versions (e.g., the spike at
v1.7.2.5 represents Debian stable).

If anybody has suggestions for other interesting analyses to perform,
let me know.

-Peff

^ permalink raw reply	[relevance 5%]

* Re: git + davfs2, is it safe?
  @ 2010-02-09 17:57  6% ` Shawn O. Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn O. Pearce @ 2010-02-09 17:57 UTC (permalink / raw)
  To: G?bor Farkas; +Cc: git

G?bor Farkas <gabor@nekomancer.net> wrote:
> for various reasons our git repositories are hosted using https (webdav),
> which is http-auth and client-certificate authenticated.
> 
> (linux on both the server and the client)
> 
> it's possible to somehow persuade git to push/fetch from such repositories,
> but it's very annoying because either you have to enter your
> username+password+cert_password
> on every fetch and twice on every push, or you have to write them down
> in $HOME/.netrc .

This is why I prefer SSH.  You have ssh-agent around to retain your
key for you.

A more modern Git (1.6.6 or later IIRC) should avoid prompting for
the password twice, because the HTTP client should actually reuse
the connection for the subsequent requests.  But I haven't tested it.

You might also want to consider upgrading your server to post-1.6.6
and stop using WebDAV... but instead use smart HTTP for push.
That should only need one authentication cycle to perform the push.


It sounds like its time for a proper curl-agent for libcurl though.
Users and applications shouldn't have to keep implementing their
password stores as text files...
 
-- 
Shawn.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH] http: clear POSTFIELDS when initializing a slot
  @ 2011-04-26 16:18  6% ` Shawn Pearce
  0 siblings, 0 replies; 55+ results
From: Shawn Pearce @ 2011-04-26 16:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, Apr 26, 2011 at 08:28, Junio C Hamano <gitster@pobox.com> wrote:
> After posting a short request using CURLOPT_POSTFIELDS, if the slot
> is reused for posting a large payload, the slot ends up having both
> POSTFIELDS (which now points at a random garbage) and READFUNCTION,
> in which case the curl library tries to use the stale POSTFIELDS.
>
> Clear it as part of the general slot initialization in get_active_slot().
>
> Heavylifting-by: Shawn Pearce <spearce@spearce.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Acked-by: Shawn Pearce <spearce@spearce.org>

FWIW, this bug exists since Git 1.6.6, when smart HTTP was first
introduced. We just get lucky most of the time up until 1.7.4, and
usually never have a failure, as fetch-pack/upload-pack negotiation
packets are almost always smaller than the http.postbuffer size.
Between 1.6.6 and 1.7.4, if it exceeds the postbuffer size, it may not
be possible to fetch because the prior POSTFIELDS will be sent, which
means the client will never transmit "done" and get a pack.

In 1.7.5 smart HTTP push is horribly broken without this patch.

>  * This came up while Shawn was looking at the smart HTTP code again.  It
>   makes me wonder why we do not use curl_easy_reset() in this function,
>   though...

Yea, makes me wonder too. :-)

> diff --git a/http.c b/http.c
> index ed6414a..b642eac 100644
> --- a/http.c
> +++ b/http.c
> @@ -494,6 +494,7 @@ struct active_request_slot *get_active_slot(void)
>        curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
>        curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL);
>        curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, NULL);
> +       curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);
>        curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
>        curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);

-- 
Shawn.

^ permalink raw reply	[relevance 6%]

* Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
@ 2009-12-29  6:47  6% Fyn Fynn
  2009-12-29  8:12  7% ` Tay Ray Chuan
  2009-12-29  8:38  0% ` Nguyen Thai Ngoc Duy
  0 siblings, 2 replies; 55+ results
From: Fyn Fynn @ 2009-12-29  6:47 UTC (permalink / raw)
  To: git

The exact same git reset command that works in 1.6.4, fails to work
under 1.6.6:

$ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
/usr/local/git-1.6.6/bin/git reset --hard
fatal: hard reset requires a work tree
$ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
/usr/local/git-1.6.4/bin/git reset --hard
HEAD is now at 77ec73f...

What gives?

^ permalink raw reply	[relevance 6%]

* Git reproducible corruption errors on merge/checkout not detected by git fsck --full --strict
@ 2009-12-27 21:59  6% Denis Rosset
  0 siblings, 0 replies; 55+ results
From: Denis Rosset @ 2009-12-27 21:59 UTC (permalink / raw)
  To: git

Hi all !

I use git regularly since twelve months; on one specific repository, I  
had repetitive "inflate: data stream error (incorrect data check)"  
errors. These errors appear when checking out from one branch to  
another or when merging; however doing a "git fsck --full --strict" on  
either the local repository or the remote repository before the  
operation does not show anything wrong.

The bare repository is located on a Mac OS X 10.5 PPC server with Git  
1.5.X.Y (X, Y not known), the local client is Git 1.6.6 installed  
through MacPorts. I am stuck with Git 1.6.6 due to the MacPorts  
architecture. Local zlib is 1.2.3_3.

I created a new local repository, reimported the files manually (only  
the files, losing all the history in the process), and errors happen  
again. The errors seems to appear when Git creates a local pack to  
store the object files.

I am now installing Macports git 1.6.6 on the server to do further  
testing.

My questions :

1) is "git fsck --full --strict" the most comprehensive check I can do  
on a repository ?
2) are there known bugs leading to data corruption in the git 1.6.6  
prerelease and/or zlib 1.2.3_3 ?
3) is there a verbose flag or a log I can consult (and eventually send  
to this list) ?

Kind regards,

Denis Rosset

^ permalink raw reply	[relevance 6%]

* [BUG] Git 1.6.6 can't clone tags after filter-branch
@ 2010-01-19 22:05  6% James Pickens
  0 siblings, 0 replies; 55+ results
From: James Pickens @ 2010-01-19 22:05 UTC (permalink / raw)
  To: Git ML, Nicolas Pitre

Hi,

This series of commands:

  git init
  touch file1
  git add file1
  git commit -m 1
  echo >> file1
  touch file2
  git add file1 file2
  git commit -m 2
  git tag -m 'mytag' mytag
  git filter-branch --index-filter 'git rm --cached --ignore-unmatch file2' \
    --tag-name-filter cat -f -- --all
  git clone file://$PWD temp

Results in an error from the clone command:

  error: refs/tags/mytag does not point to a valid object!

The clone command exits with zero status, but the new repo doesn't contain
the tag 'mytag'.

Version 1.6.2.5 did not have this problem.  It bisects to:

  commit 5bdc32d3e50d8335c65e136e6b5234c5dd92a7a9
  Author: Nicolas Pitre <nico@fluxnic.net>
  Date:   Fri Sep 25 23:54:42 2009 -0400

      make 'git clone' ask the remote only for objects it cares about

James

^ permalink raw reply	[relevance 6%]

* [ANNOUNCE] Git 1.6.6
@ 2009-12-24  1:06  6% Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-12-24  1:06 UTC (permalink / raw)
  To: git

The latest feature release Git 1.6.6 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.6.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.6.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.6.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  RPMS/$arch/git-*-1.6.6-1.fc11.$arch.rpm	(RPM)

Git v1.6.6 Release Notes
========================

Notes on behaviour change
-------------------------

 * In this release, "git fsck" defaults to "git fsck --full" and
   checks packfiles, and because of this it will take much longer to
   complete than before.  If you prefer a quicker check only on loose
   objects (the old default), you can say "git fsck --no-full".  This
   has been supported by 1.5.4 and newer versions of git, so it is
   safe to write it in your script even if you use slightly older git
   on some of your machines.

Preparing yourselves for compatibility issues in 1.7.0
------------------------------------------------------

In git 1.7.0, which is planned to be the release after 1.6.6, there will
be a handful of behaviour changes that will break backward compatibility.

These changes were discussed long time ago and existing behaviours have
been identified as more problematic to the userbase than keeping them for
the sake of backward compatibility.

When necessary, a transition strategy for existing users has been designed
not to force them running around setting configuration variables and
updating their scripts in order to either keep the traditional behaviour
or adjust to the new behaviour, on the day their sysadmin decides to install
the new version of git.  When we switched from "git-foo" to "git foo" in
1.6.0, even though the change had been advertised and the transition
guide had been provided for a very long time, the users procrastinated
during the entire transtion period, and ended up panicking on the day
their sysadmins updated their git installation.  We are trying to avoid
repeating that unpleasantness in the 1.7.0 release.

For changes decided to be in 1.7.0, commands that will be affected
have been much louder to strongly discourage such procrastination, and
they continue to be in this release.  If you have been using recent
versions of git, you would have seen warnings issued when you used
features whose behaviour will change, with a clear instruction on how
to keep the existing behaviour if you want to.  You hopefully are
already well prepared.

Of course, we have also been giving "this and that will change in
1.7.0; prepare yourselves" warnings in the release notes and
announcement messages for the past few releases.  Let's see how well
users will fare this time.

 * "git push" into a branch that is currently checked out (i.e. pointed by
   HEAD in a repository that is not bare) will be refused by default.

   Similarly, "git push $there :$killed" to delete the branch $killed
   in a remote repository $there, when $killed branch is the current
   branch pointed at by its HEAD, will be refused by default.

   Setting the configuration variables receive.denyCurrentBranch and
   receive.denyDeleteCurrent to 'ignore' in the receiving repository
   can be used to override these safety features.  Versions of git
   since 1.6.2 have issued a loud warning when you tried to do these
   operations without setting the configuration, so repositories of
   people who still need to be able to perform such a push should
   already have been future proofed.

   Please refer to:

   http://git.or.cz/gitwiki/GitFaq#non-bare
   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

   for more details on the reason why this change is needed and the
   transition process that already took place so far.

 * "git send-email" will not make deep threads by default when sending a
   patch series with more than two messages.  All messages will be sent
   as a reply to the first message, i.e. cover letter.  Git 1.6.6 (this
   release) will issue a warning about the upcoming default change, when
   it uses the traditional "deep threading" behaviour as the built-in
   default.  To squelch the warning but still use the "deep threading"
   behaviour, give --chain-reply-to option or set sendemail.chainreplyto
   to true.

   It has been possible to configure send-email to send "shallow thread"
   by setting sendemail.chainreplyto configuration variable to false.
   The only thing 1.7.0 release will do is to change the default when
   you haven't configured that variable.

 * "git status" will not be "git commit --dry-run".  This change does not
   affect you if you run the command without pathspec.

   Nobody sane found the current behaviour of "git status Makefile" useful
   nor meaningful, and it confused users.  "git commit --dry-run" has been
   provided as a way to get the current behaviour of this command since
   1.6.5.

 * "git diff" traditionally treated various "ignore whitespace" options
   only as a way to filter the patch output.  "git diff --exit-code -b"
   exited with non-zero status even if all changes were about changing the
   ammount of whitespace and nothing else.  and "git diff -b" showed the
   "diff --git" header line for such a change without patch text.

   In 1.7.0, the "ignore whitespaces" will affect the semantics of the
   diff operation itself.  A change that does not affect anything but
   whitespaces will be reported with zero exit status when run with
   --exit-code, and there will not be "diff --git" header for such a
   change.


Updates since v1.6.5
--------------------

(subsystems)

 * various gitk updates including use of themed widgets under Tk 8.5,
   Japanese translation, a fix to a bug when running "gui blame" from
   a subdirectory, etc.

 * various git-gui updates including new translations, wm states fixes,
   Tk bug workaround after quitting, improved heuristics to trigger gc,
   etc.

 * various git-svn updates.

 * "git fetch" over http learned a new mode that is different from the
   traditional "dumb commit walker".

(portability)

 * imap-send can be built on mingw port.

(performance)

 * "git diff -B" has smaller memory footprint.

(usability, bells and whistles)

 * The object replace mechanism can be bypassed with --no-replace-objects
   global option given to the "git" program.

 * In configuration files, a few variables that name paths can begin with ~/
   and ~username/ and they are expanded as expected.

 * "git subcmd -h" now shows short usage help for many more subcommands.

 * "git bisect reset" can reset to an arbitrary commit.

 * "git checkout frotz" when there is no local branch "frotz" but there
   is only one remote tracking branch "frotz" is taken as a request to
   start the named branch at the corresponding remote tracking branch.

 * "git commit -c/-C/--amend" can be told with a new "--reset-author" option
   to ignore authorship information in the commit it is taking the message
   from.

 * "git describe" can be told to add "-dirty" suffix with "--dirty" option.

 * "git diff" learned --submodule option to show a list of one-line logs
   instead of differences between the commit object names.

 * "git diff" learned to honor diff.color.func configuration to paint
   function name hint printed on the hunk header "@@ -j,k +l,m @@" line
   in the specified color.

 * "git fetch" learned --all and --multiple options, to run fetch from
   many repositories, and --prune option to remove remote tracking
   branches that went stale.  These make "git remote update" and "git
   remote prune" less necessary (there is no plan to remove "remote
   update" nor "remote prune", though).

 * "git fsck" by default checks the packfiles (i.e. "--full" is the
   default); you can turn it off with "git fsck --no-full".

 * "git grep" can use -F (fixed strings) and -i (ignore case) together.

 * import-tars contributed fast-import frontend learned more types of
   compressed tarballs.

 * "git instaweb" knows how to talk with mod_cgid to apache2.

 * "git log --decorate" shows the location of HEAD as well.

 * "git log" and "git rev-list" learned to take revs and pathspecs from
   the standard input with the new "--stdin" option.

 * "--pretty=format" option to "log" family of commands learned:

   . to wrap text with the "%w()" specifier.
   . to show reflog information with "%g[sdD]" specifier.

 * "git notes" command to annotate existing commits.

 * "git merge" (and "git pull") learned --ff-only option to make it fail
   if the merge does not result in a fast-forward.

 * "git mergetool" learned to use p4merge.

 * "git rebase -i" learned "reword" that acts like "edit" but immediately
   starts an editor to tweak the log message without returning control to
   the shell, which is done by "edit" to give an opportunity to tweak the
   contents.

 * "git send-email" can be told with "--envelope-sender=auto" to use the
   same address as "From:" address as the envelope sender address.

 * "git send-email" will issue a warning when it defaults to the
   --chain-reply-to behaviour without being told by the user and
   instructs to prepare for the change of the default in 1.7.0 release.

 * In "git submodule add <repository> <path>", <path> is now optional and
   inferred from <repository> the same way "git clone <repository>" does.

 * "git svn" learned to read SVN 1.5+ and SVK merge tickets.

 * "git svn" learned to recreate empty directories tracked only by SVN.

 * "gitweb" can optionally render its "blame" output incrementally (this
   requires JavaScript on the client side).

 * Author names shown in gitweb output are links to search commits by the
   author.

Fixes since v1.6.5
------------------

All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.


----------------------------------------------------------------

Changes since v1.6.5 are as follows:

Alex Riesen (1):
      git-gui: Update russian translation

Alex Vandiver (3):
      git-svn: sort svk merge tickets to account for minimal parents
      git-svn: Set svn.authorsfile to an absolute path when cloning
      git-svn: set svn.authorsfile earlier when cloning

Alexander Gavrilov (1):
      git-gui: Increase blame viewer usability on MacOS.

Alexey Borzenkov (1):
      git-gui: store wm state and fix wm geometry

Anders Kaseorg (1):
      bisect reset: Allow resetting to any commit, not just a branch

Andreas Schwab (1):
      Work around option parsing bug in the busybox tar implementation

Andrew Myrick (1):
      git-svn: Remove obsolete MAXPARENT check

Avery Pennarun (1):
      builtin-merge.c: call exclude_cmds() correctly.

Ben Walton (2):
      configure: add macro to set arbitrary make variables
      configure: add settings for gitconfig, editor and pager

Benjamin Kramer (1):
      Explicitly truncate bswap operand to uint32_t

Bernt Hansen (1):
      gitk: Skip translation of "wrong Tcl version" message

Bert Wesarg (2):
      Give the hunk comment its own color
      get_ref_states: strdup entries and free util in stale list

Björn Gustavsson (24):
      Teach 'rebase -i' the command "reword"
      git-clone.txt: Fix grammar and formatting
      bash: complete more options for 'git rebase'
      Teach 'git merge' and 'git pull' the option --ff-only
      Teach the --all option to 'git fetch'
      Teach the --multiple option to 'git fetch'
      Add the configuration option skipFetchAll
      Add missing test for 'git remote update --prune'
      Re-implement 'git remote update' using 'git fetch'
      format-patch: Always generate a patch
      format-patch documentation: Remove diff options that are not useful
      format-patch documentation: Fix formatting
      format-patch: Add "--no-stat" as a synonym for "-p"
      bash: add the merge option --ff-only
      Clarify and correct -z
      apply: apply works outside a repository
      apply: Format all options using back-quotes
      apply: Use the term "working tree" consistently
      Fix truncated usage messages
      User Manual: Write "Git" instead of "GIT"
      Fix over-simplified documentation for 'git log -z'
      gitworkflows: Consistently back-quote git commands
      bash: Support new 'git fetch' options
      rebase -i: abort cleanly if the editor fails to launch

Björn Steinbrink (2):
      clone: Supply the right commit hash to post-checkout when -b is used
      pre-commit.sample: Diff against the empty tree when HEAD is invalid

Brandon Casey (2):
      t4201: use ISO8859-1 rather than ISO-8859-1
      t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'

Brian Collins (1):
      grep: Allow case insensitive search of fixed-strings

Brian Gernhardt (1):
      t/gitweb-lib: Split HTTP response with non-GNU sed

Carlos R. Mafra (1):
      Makefile: clean block-sha1/ directory instead of mozilla-sha1/

Christian Couder (7):
      git: add --no-replace-objects option to disable replacing
      Documentation: add "Fighting regressions with git bisect" article
      replace: use a GIT_NO_REPLACE_OBJECTS env variable
      Documentation: fix typos and spelling in replace documentation
      Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
      bisect: simplify calling visualizer using '--bisect' option
      Documentation: update descriptions of revision options related to '--bisect'

Clemens Buchacher (4):
      modernize fetch/merge/pull examples
      remote-helpers: return successfully if everything up-to-date
      set httpd port before sourcing lib-httpd
      git-gui: search 4 directories to improve statistic of gc hint

Dan Zwell (1):
      git-gui: Limit display to a maximum number of files

Daniel Barkalow (2):
      Require a struct remote in transport_get()
      Allow curl helper to work without a local repository

David Aguilar (2):
      submodule.c: Squelch a "use before assignment" warning
      help: Do not unnecessarily look for a repository

David Brown (1):
      commit: More generous accepting of RFC-2822 footer lines.

David Kågedal (1):
      git-blame.el: Change how blame information is shown.

David Reiss (1):
      Prevent git blame from segfaulting on a missing author name

David Soria Parra (1):
      Documentation: Document --branch option in git clone synopsis

Dmitry V. Levin (1):
      Makefile: add compat/bswap.h to LIB_H

Eric Wong (13):
      git svn: fix fetch where glob is on the top-level URL
      git svn: read global+system config for clone+init
      git svn: add authorsfile test case for ~/.gitconfig
      git svn: attempt to create empty dirs on clone+rebase
      git svn: always reuse existing remotes on fetch
      git svn: strip leading path when making empty dirs
      git svn: log removals of empty directories
      git svn: make empty directory creation gc-aware
      t9146: use 'svn_cmd' wrapper
      git svn: fix --revision when fetching deleted paths
      update release notes for git svn in 1.6.6
      git svn: lookup new parents correctly from svn:mergeinfo
      git svn: branch/tag commands detect username in URLs

Erick Mattos (1):
      commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author

Erik Faye-Lund (6):
      imap-send: use separate read and write fds
      imap-send: use run-command API for tunneling
      imap-send: fix compilation-error on Windows
      imap-send: build imap-send on Windows
      mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
      mingw: enable OpenSSL

Felipe Contreras (5):
      diff.c: stylefix
      Use 'fast-forward' all over the place
      format-patch: fix parsing of "--" on the command line
      format-patch: add test for parsing of "--"
      send-email: automatic envelope sender

Gerrit Pape (1):
      help -i: properly error out if no info viewer can be found

Gisle Aas (2):
      More precise description of 'git describe --abbrev'
      Fix documentation grammar typo

Giuseppe Bilotta (1):
      gitweb: fix esc_param

Greg Price (2):
      Documentation: undocument gc'd function graph_release()
      git svn: Don't create empty directories whose parents were deleted

Guillermo S. Romero (1):
      gitk: Add configuration for UI colour scheme

Heiko Voigt (2):
      git-gui: remove warning when deleting correctly merged remote branch
      git gui: make current branch default in "remote delete branch" merge check

Horst H. von Brand (1):
      git-pull.sh: Fix call to git-merge for new command format

Ingmar Vanhassel (1):
      import-tars: Add support for tarballs compressed with lzma, xz

Jakub Narebski (16):
      gitweb: Add optional "time to generate page" info in footer
      gitweb: Incremental blame (using JavaScript)
      gitweb: Colorize 'blame_incremental' view during processing
      gitweb: Create links leading to 'blame_incremental' using JavaScript
      gitweb: Minify gitweb.js if JSMIN is defined
      gitweb: Add 'show-sizes' feature to show blob sizes in tree view
      gitweb: Do not show 'patch' link for merge commits
      t/gitweb-lib.sh: Split gitweb output into headers and body
      gitweb: Document current snapshot rules via new tests
      gitweb: Refactor 'log' action generation, adding git_log_body()
      gitweb: Refactor common parts of 'log' and 'shortlog' views
      gitweb: Make 'history' view (re)use git_log_generic()
      gitweb.js: Harden setting blamed commit info in incremental blame
      gitweb: Make linking to actions requiring JavaScript a feature
      gitweb: Add link to other blame implementation in blame views
      gitweb: Describe (possible) gitweb.js minification in gitweb/README

Jan Krüger (2):
      rebase -i: more graceful handling of invalid commands
      pull: clarify advice for the unconfigured error case

Jari Aalto (3):
      Documentation/fetch-options.txt: order options alphabetically
      Documentation/git-pull.txt: Add subtitles above included option files
      Documentation/merge-options.txt: order options in alphabetical groups

Jay Soffian (4):
      remote: refactor some logic into get_stale_heads()
      teach warn_dangling_symref to take a FILE argument
      builtin-fetch: add --prune option
      builtin-fetch: add --dry-run option

Jean Privat (1):
      Teach "git describe" --dirty option

Jeff King (18):
      ls-files: excludes should not impact tracked files
      document push's new quiet option
      cvsimport: fix relative argument filenames
      imap-send: remove useless uid code
      push: always load default config
      gitignore: root most patterns at the top-level directory
      add-interactive: handle deletion of empty files
      ls-files: unbreak "ls-files -i"
      t915{0,1}: use $TEST_DIRECTORY
      push: fix typo in usage
      format-patch: make "-p" suppress diffstat
      diffcore-break: free filespec data as we go
      diffcore-break: save cnt_data for other phases
      prune-packed: only show progress when stderr is a tty
      rerere: don't segfault on failure to open rr-cache
      reset: improve worktree safety valves
      add-interactive: fix deletion of non-empty files
      ignore unknown color configuration

Jens Lehmann (7):
      git-gui: display summary when showing diff of a submodule
      git-gui: fix diff for partially staged submodule changes
      git submodule add: make the <path> parameter optional
      git-gui: fix use of uninitialized variable
      add tests for git diff --submodule
      gitk: Fix diffing committed -> staged (typo in diffcmd)
      gitk: Use the --submodule option for displaying diffs when available

Jimmy Angelakos (1):
      git-gui: Added Greek translation & glossary

Jindrich Makovicka (1):
      git-gui: suppress RenderBadPicture X error caused by Tk bug

Joe Perches (1):
      git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s

Johan Herland (10):
      Teach "-m <msg>" and "-F <file>" to "git notes edit"
      fast-import: Add support for importing commit notes
      t3302-notes-index-expensive: Speed up create_repo()
      Add flags to get_commit_notes() to control the format of the note string
      Teach notes code to free its internal data structures on request
      Teach the notes lookup code to parse notes trees with various fanout schemes
      Add selftests verifying that we can parse notes trees with various fanouts
      Refactor notes code to concatenate multiple notes annotating the same object
      Add selftests verifying concatenation of multiple notes for the same commit
      Fix crasher on encountering SHA1-like non-note in notes tree

Johannes Schindelin (11):
      print_wrapped_text(): allow hard newlines
      Add strbuf_add_wrapped_text() to utf8.[ch]
      Introduce commit notes
      Add a script to edit/inspect notes
      Speed up git notes lookup
      Add an expensive test for git-notes
      Add '%N'-format for pretty-printing commit notes
      Add the --submodule option to the diff option family
      blame: make sure that the last line ends in an LF
      help -a: do not unnecessarily look for a repository
      diff --color-words -U0: fix the location of hunk headers

Johannes Sixt (7):
      remote-curl: add missing initialization of argv0_path
      Remove a left-over file from t/t5100
      Mark files in t/t5100 as UTF-8
      Windows: use BLK_SHA1 again
      t4014-format-patch: do not assume 'test' is available as non-builtin
      Add a notice that only certain functions can print color escape codes
      help.autocorrect: do not run a command if the command given is junk

Jonathan Nieder (40):
      Add tests for git check-ref-format
      Documentation: describe check-ref-format --branch
      check-ref-format: simplify --print implementation
      clone: detect extra arguments
      Handle more shell metacharacters in editor names
      Add intermediate build products to .gitignore
      Retire fetch--tool helper to contrib/examples
      Show usage string for 'git grep -h'
      Show usage string for 'git cherry -h'
      Show usage string for 'git commit-tree -h'
      Show usage string for 'git merge-ours -h'
      Show usage string for 'git show-ref -h'
      check-ref-format: update usage string
      merge: do not setup worktree twice
      http-fetch: add missing initialization of argv0_path
      Show usage string for 'git check-ref-format -h'
      Show usage string for 'git fast-import -h'
      Show usage string for 'git get-tar-commit-id -h'
      Show usage string for 'git imap-send -h'
      Show usage string for 'git mailsplit -h'
      Show usage string for 'git merge-one-file -h'
      Show usage string for 'git rev-parse -h'
      Show usage string for 'git show-index -h'
      Show usage string for 'git unpack-file -h'
      Show usage string for 'git stripspace -h'
      Let 'git http-fetch -h' show usage outside any git repository
      Show usage string for 'git http-push -h'
      Let 'git <command> -h' show usage without a git dir
      Introduce usagef() that takes a printf-style format
      merge-{recursive,subtree}: use usagef() to print usage
      diff --no-index: make the usage string less scary
      Do not use VISUAL editor on dumb terminals
      Suppress warnings from "git var -l"
      Teach git var about GIT_EDITOR
      Teach git var about GIT_PAGER
      add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
      am -i, git-svn: use "git var GIT_PAGER"
      Provide a build time default-editor setting
      Speed up bash completion loading
      Makefile: do not clean arm directory

Julian Phillips (4):
      fetch: Speed up fetch by rewriting find_non_local_tags
      remote: Make ref_remove_duplicates faster for large numbers of refs
      fetch: Speed up fetch of large numbers of refs
      remote: fix use-after-free error detected by glibc in ref_remove_duplicates

Junio C Hamano (86):
      mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
      apply --whitespace=fix: fix handling of blank lines at the eof
      apply --whitespace=fix: detect new blank lines at eof correctly
      apply.c: split check_whitespace() into two
      apply --whitespace=warn/error: diagnose blank at EOF
      apply --whitespace: warn blank but not necessarily empty lines at EOF
      diff.c: the builtin_diff() deals with only two-file comparison
      diff --whitespace=warn/error: obey blank-at-eof
      diff --whitespace=warn/error: fix blank-at-eof check
      diff --color: color blank-at-eof
      core.whitespace: split trailing-space into blank-at-{eol,eof}
      diff --whitespace: fix blank lines at end
      diff.c: shuffling code around
      diff.c: split emit_line() from the first char and the rest of the line
      diff.c: emit_add_line() takes only the rest of the line
      diff -B: colour whitespace errors
      Pretty-format: %[+-]x to tweak inter-item newlines
      diff-lib.c: fix misleading comments on oneway_diff()
      unpack-trees: typofix
      unpack_callback(): use unpack_failed() consistently
      git check-ref-format --print
      info/grafts: allow trailing whitespaces at the end of line
      GIT 1.6.5.1
      Start 1.6.6 cycle
      check_filename(): make verify_filename() callable without dying
      DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
      format_commit_message(): fix function signature
      fsck: default to "git fsck --full"
      git checkout --no-guess
      gc --auto --quiet: make the notice a bit less verboase
      receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
      Fix incorrect error check while reading deflated pack data
      Teach --wrap to only indent without wrapping
      Do not fail "describe --always" in a tag-less repository
      Fix list of released versions in the toc document
      GIT 1.6.5.2
      Update draft release notes to 1.6.6
      clone: fix help on options
      Revert "Don't create the $GIT_DIR/branches directory on init"
      diff --color-words: bit of clean-up
      t1200: further modernize test script style
      t1200: prepare for merging with Fast-forward bikeshedding
      builtin-commit.c: fix logic to omit empty line before existing footers
      git-describe.txt: formatting fix
      check-ref-format -h: it does not know the --print option yet
      Provide a build time default-pager setting
      Git 1.6.5.3
      Update draft release notes to 1.6.6
      read_revision_from_stdin(): use strbuf
      Teach --stdin option to "log" family
      setup_revisions(): do not call get_pathspec() too early
      Make --stdin option to "log" family read also pathspecs
      diffcore-rename: reduce memory footprint by freeing blob data early
      Documentation: avoid xmlto input error
      t9001: test --envelope-sender option of send-email
      Git v1.6.6-rc0
      Add trivial tests for --stdin option to log family
      Protect scripted Porcelains from GREP_OPTIONS insanity
      builtin-apply.c: pay attention to -p<n> when determining the name
      Remove dead code from "git am"
      emit_line(): don't emit an empty <SET><RESET> followed by a newline
      Update draft release notes to 1.6.6 before merging topics for -rc1
      git-merge: a deprecation notice of the ancient command line syntax
      Update draft release notes to 1.6.6 before -rc1
      Do not misidentify "git merge foo HEAD" as an old-style invocation
      merge: do not add standard message when message is given with -m option
      Prepare for 1.6.5.4
      Git 1.6.6-rc1
      Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
      Unconditionally set man.base.url.for.relative.links
      Git 1.6.5.4
      Documentation: xmlto 0.0.18 does not know --stringparam
      Prepare for 1.6.5.5
      Git 1.6.5.5
      Revert recent "git merge <msg> HEAD <commit>..." deprecation
      Update draft release notes to 1.6.6 before -rc2
      Git 1.6.6-rc2
      Remove post-upload-hook
      Fix archive format with -- on the command line
      Git 1.6.5.6
      Update Release Notes for 1.6.6 to remove old bugfixes
      worktree: don't segfault with an absolute pathspec without a work tree
      Git 1.6.5.7
      Git 1.6.6-rc3
      Git 1.6.6-rc4
      Git 1.6.6

Linus Torvalds (2):
      Add '--bisect' revision machinery argument
      Fix diff -B/--dirstat miscounting of newly added contents

Lukas Sandström (1):
      git am/mailinfo: Don't look at in-body headers when rebasing

Marius Storm-Olsen (1):
      MSVC: Enable OpenSSL, and translate -lcrypto

Mark Lodato (5):
      http-backend: add GIT_PROJECT_ROOT environment var
      http-backend: reword some documentation
      http-backend: use mod_alias instead of mod_rewrite
      http-backend: add example for gitweb on same URL
      http-backend: more explict LocationMatch

Mark Rada (3):
      gitweb: check given hash before trying to create snapshot
      instaweb: support mod_cgid for apache2
      gitweb: Smarter snapshot names

Markus Heidelberg (4):
      t7800-difftool: fix the effectless GIT_DIFFTOOL_PROMPT test
      bash completion: difftool accepts the same options as diff
      t4034-diff-words: add a test for word diff without context
      gitk: Fix "git gui blame" invocation when called from top-level directory

Martin Storsjö (3):
      Disable CURLOPT_NOBODY before enabling CURLOPT_PUT and CURLOPT_POST
      Refactor winsock initialization into a separate function
      Enable support for IPv6 on MinGW

Matt Kraai (2):
      grep: do not segfault when -f is used
      Documentation/git-gc.txt: change "references" to "reference"

Matthew Ogilvie (6):
      core.autocrlf documentation: mention the crlf attribute
      cvsserver doc: database generally can not be reproduced consistently
      config documentation: some configs are auto-set by git-init
      t2300: use documented technique to invoke git-sh-setup
      t3409 t4107 t7406 t9150: use dashless commands
      t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH

Matthieu Moy (6):
      Expand ~ and ~user in core.excludesfile, commit.template
      expand_user_path: expand ~ to $HOME, not to the actual homedir.
      merge-recursive: point the user to commit when file would be overwritten.
      user-manual: Document that "git merge" doesn't like uncommited changes.
      merge-recursive: make the error-message generation an extern function
      builtin-merge: show user-friendly error messages for fast-forward too.

Michael J Gruber (2):
      Make t9150 and t9151 test scripts executable
      Documentation: Fix a few i.e./e.g. mix-ups

Miklos Vajna (1):
      git-stash documentation: mention default options for 'list'

Mizar (2):
      gitk: Add Japanese translation
      gitk: Update Japanese translation

Nanako Shiraishi (5):
      git push: remove incomplete options list from help text
      git push: say that --tag can't be used with --all or --mirror in help text
      t1200: fix a timing dependent error
      prepare send-email for smoother change of --chain-reply-to default
      Illustrate "filter" attribute with an example

Nasser Grainawi (1):
      Document `delta` attribute in "git help attributes".

Nicolas Pitre (4):
      change throughput display units with fast links
      pack-objects: move thread autodetection closer to relevant code
      give priority to progress messages
      pack-objects: split implications of --all-progress from progress activation

Pat Thoyts (4):
      gitk: Use themed tk widgets
      gitk: Fix errors in the theme patch
      gitk: Default to the system colours on Windows
      gitk: Fix selection of tags

Paul Mackerras (5):
      gitk: Restore scrolling position of diff pane on back/forward in history
      gitk: Add a user preference to enable/disable use of themed widgets
      gitk: Show diff of commits at end of compare-commits output
      gitk: Don't compare fake children when comparing commits
      gitk: Improve appearance of radiobuttons and checkbuttons

Pauli Virtanen (1):
      git-add--interactive: never skip files included in index

Petr Baudis (1):
      gitweb: Fix blob linenr links in pathinfo mode

Philippe Bruhat (1):
      Make sure $PERL_PATH is defined when the test suite is run.

Raman Gupta (1):
      Add branch management for releases to gitworkflows

Ramsay Allan Jones (5):
      Makefile: merge two Cygwin configuration sections into one
      Makefile: keep MSVC and Cygwin configuration separate
      MSVC: Add support for building with NO_MMAP
      t9700-perl-git.sh: Fix a test failure on Cygwin
      git-count-objects: Fix a disk-space under-estimate on Cygwin

René Scharfe (9):
      describe: load refnames before calling describe()
      Implement wrap format %w() as if it is a mode switch
      log --format: don't ignore %w() at the start of format string
      grep: unset GREP_OPTIONS before spawning external grep
      strbuf_add_wrapped_text(): factor out strbuf_add_indented_text()
      log --format: document %w
      strbuf_add_wrapped_text(): skip over colour codes
      mergetool--lib: simplify guess_merge_tool()
      archive: clarify description of path parameter

Robert Zeh (1):
      git svn: add test for a git svn gc followed by a git svn mkdirs

Robin Rosenberg (1):
      Don't create the $GIT_DIR/branches directory on init

SZEDER Gábor (2):
      Documentation: add 'git replace' to main git manpage
      bash: update 'git commit' completion

Sam Vilain (10):
      git-svn: add test data for SVK merge, with script.
      git-svn: allow test setup script to support PERL env. var
      git-svn: convert SVK merge tickets to extra parents
      git-svn: add test data for SVN 1.5+ merge, with script.
      git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
      git-svn: expand the svn mergeinfo test suite, highlighting some failures
      git-svn: memoize conversion of SVN merge ticket info to git commit ranges
      git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
      git-svn: exclude already merged tips using one rev-list call
      git-svn: detect cherry-picks correctly.

Scott Chacon (2):
      mergetool--lib: add p4merge as a pre-configured mergetool option
      Update packfile transfer protocol documentation

Sebastian Schuberth (3):
      Do not try to remove directories when removing old links
      Use faster byte swapping when compiling with MSVC
      Make the MSVC projects use PDB/IDB files named after the project

Shawn O. Pearce (28):
      git-gui: Ensure submodule path is quoted properly
      sha1_file: Fix infinite loop when pack is corrupted
      pkt-line: Add strbuf based functions
      pkt-line: Make packet_read_line easier to debug
      fetch-pack: Use a strbuf to compose the want list
      Move "get_ack()" back to fetch-pack
      Add multi_ack_detailed capability to fetch-pack/upload-pack
      remote-curl: Refactor walker initialization
      fetch: Allow transport -v -v -v to set verbosity to 3
      remote-helpers: Fetch more than one ref in a batch
      remote-helpers: Support custom transport options
      Move WebDAV HTTP push under remote-curl
      Git-aware CGI to provide dumb HTTP transport
      Add stateless RPC options to upload-pack, receive-pack
      Smart fetch and push over HTTP: server side
      Discover refs via smart HTTP server when available
      Smart push over HTTP: client side
      Smart fetch over HTTP: client side
      Smart HTTP fetch: gzip requests
      http tests: use /dumb/ URL prefix
      test smart http fetch and push
      http-backend: Use http.getanyfile to disable dumb HTTP serving
      http-backend: Test configuration options
      Git-aware CGI to provide dumb HTTP transport
      http-backend: Protect GIT_PROJECT_ROOT from /../ requests
      t5551-http-fetch: Work around some libcurl versions
      t5551-http-fetch: Work around broken Accept header in libcurl
      http-backend: Fix bad treatment of uintmax_t in Content-Length

Sitaram Chamarty (1):
      gitk: Disable checkout of remote branches

Stephen Boyd (13):
      rebase -i: fix reword when using a terminal editor
      gitweb: linkify author/committer names with search
      t1402: Make test executable
      t1200: cleanup and modernize test style
      t1200: Make documentation and test agree
      git-add.txt: fix formatting of --patch section
      t3101: test more ls-tree options
      ls-tree: migrate to parse-options
      gitweb.js: fix null object exception in initials calculation
      instaweb: restart server if already running
      gitweb.js: fix padLeftStr() and its usage
      api-strbuf.txt: fix typos and document launch_editor()
      technical-docs: document hash API

Tarmigan Casebolt (3):
      Check the format of more printf-type functions
      http-backend: Fix access beyond end of string.
      http-backend: Let gcc check the format of more printf-type functions.

Tay Ray Chuan (3):
      http-push: fix check condition on http.c::finish_http_pack_request()
      t5540-http-push: remove redundant fetches
      remote-curl.c: fix rpc_out()

Thiago Farina (1):
      Documentation: update pt-BR

Thomas Rast (15):
      bash completion: complete refs for git-grep
      Let --decorate show HEAD position
      Refactor pretty_print_commit arguments into a struct
      reflog-walk: refactor the branch@{num} formatting
      Introduce new pretty formats %g[sdD] for reflog information
      stash list: use new %g formats instead of sed
      stash list: drop the default limit of 10 stashes
      Quote ' as \(aq in manpages
      describe: when failing, tell the user about options that work
      filter-branch: stop special-casing $filter_subdir argument
      filter-branch: nearest-ancestor rewriting outside subdir filter
      Documentation: clarify 'ours' merge strategy
      rebase docs: clarify --merge and --strategy
      Document git-svn's first-parent rule
      describe: do not use unannotated tag even if exact match

Tim Henigan (2):
      Update 'git remote update' usage string to match man page.
      git remote: Separate usage strings for subcommands

Toby Allsopp (1):
      git svn: handle SVN merges from revisions past the tip of the branch

Todd Zullinger (2):
      Makefile: Ensure rpm packages can be read by older rpm versions
      Documentation: Avoid use of xmlto --stringparam

Uwe Kleine-König (1):
      shortlog: respect commit encoding

Vietor Liu (2):
      git-gui: adjust the minimum height of diff pane for shorter screen height
      imap-send.c: fix compiler warnings for OpenSSL 1.0

Štěpán Němec (1):
      git-update-index.txt: Document the --really-refresh option.

^ permalink raw reply	[relevance 6%]

* [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
@ 2012-01-22  5:46  7% Jonathan Nieder
  0 siblings, 0 replies; 55+ results
From: Jonathan Nieder @ 2012-01-22  5:46 UTC (permalink / raw)
  To: Gabriel Filion
  Cc: git, Simon Poirier, Sverre Rabbelier, Jeff King, David Barr,
	Dmitry Ivankov

Git 1.7.7 (commit 9504bc9d, "transport-helper: change import
semantics", 2011-07-16) incompatibly changed the interface of the
"import" capability.

Before, git would always send a single import command, which the
remote helper would respond to with a fast-import stream, terminated
by end of file, meaning there was no way to fetch multiple refs in one
connection.  Nowadays, git instead sends a sequence of import lines:

	import refs/heads/foo
	import refs/heads/bar

terminated by a blank line.  The helper is to respond with a
fast-import stream terminated by the "done" command and process
further commands until another blank line indicates the end of the
command stream.
---
Hi Simon and Gabriel,

Here's a rough patch against git://github.com/lelutin/git-remote-bzr.git
master.

Without this patch, whenever I try to use "git clone bzr::<something>",
after doing all the work it removes the resulting repo and exits with
status 141 (SIGPIPE).  Maybe the transport-helper should mask SIGPIPE
when writing the final newline to avoid that.

I'd have prefered to write a patch for remote-bzr that works with
older versions of git fast-import, too, but it wasn't obvious how.
Hints welcome.

BTW, would you mind if I sent a patch to include git-remote-bzr in
git.git under contrib/?

Thanks for git remote-bzr!  I'd be happy for any thoughts you have.

Ciao,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/176002/focus=176606

 README.rst     |    2 +-
 git-remote-bzr |   33 ++++++++++++++++++++++++++++++---
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/README.rst b/README.rst
index 3eb3e476..f4dbbeb2 100644
--- a/README.rst
+++ b/README.rst
@@ -34,7 +34,7 @@ Relevant bug reports
 Requirements
 ------------
 
-- git 1.6.6 or later
+- git 1.7.7 or later
 - python 2.5 +
 - bzr 2.x
 - bzr-fastimport
diff --git a/git-remote-bzr b/git-remote-bzr
index 1e3a05f9..501fffe3 100755
--- a/git-remote-bzr
+++ b/git-remote-bzr
@@ -49,7 +49,7 @@ def do_list(repo, args):
     print  # end list
 
 
-def do_import(repo, args):
+def import_one_ref(repo, args):
     """Import a fast-import stream that is exported from Bazaar."""
     if len(args) != 1:
         die("Import needs exactly one ref")
@@ -65,6 +65,23 @@ def do_import(repo, args):
     if bzrp.wait():
         die("'bzr fast-export' returned unexpectedly with code %d",
             bzrp.returncode)
+    print "done"
+
+
+def do_import(repo,args):
+    import_one_ref(repo, args)
+
+    cmdline = True
+    while cmdline:
+        cmdline = next_command()
+        if not cmdline:
+            # Return to main processing loop
+            return True
+        cmd = cmdline.pop(0)
+        if cmd != "import":
+            warn("Unexpected command %s during import" % cmd)
+            return False
+        import_one_ref(repo, cmdline)
 
 
 def do_push(repo, args):
@@ -123,8 +140,8 @@ def sanitize(value):
     return value
 
 
-def read_one_line(repo):
-    """Read and process one command."""
+def next_command():
+    """Read one command."""
     line = sys.stdin.readline()
 
     cmdline = line
@@ -138,6 +155,16 @@ def read_one_line(repo):
         # Blank line means we're about to quit
         return False
 
+    return cmdline
+
+
+def read_one_line(repo):
+    """Read and process one command."""
+    cmdline = next_command()
+
+    if not cmdline:
+        return False
+
     cmd = cmdline.pop(0)
     debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
 
-- 
1.7.9.rc2

^ permalink raw reply related	[relevance 7%]

* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
  2009-12-29  6:47  6% Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE Fyn Fynn
@ 2009-12-29  8:12  7% ` Tay Ray Chuan
  2009-12-29  8:38  0% ` Nguyen Thai Ngoc Duy
  1 sibling, 0 replies; 55+ results
From: Tay Ray Chuan @ 2009-12-29  8:12 UTC (permalink / raw)
  To: Fyn Fynn; +Cc: git

Hi,

On Tue, Dec 29, 2009 at 2:47 PM, Fyn Fynn <fynfynn@gmail.com> wrote:
> The exact same git reset command that works in 1.6.4, fails to work
> under 1.6.6:
>
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.6/bin/git reset --hard
> fatal: hard reset requires a work tree
> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
> /usr/local/git-1.6.4/bin/git reset --hard
> HEAD is now at 77ec73f...
>
> What gives?

perhaps you should also specify the --exec-path option or
GIT_EXEC_PATH environment variable.

Assuming a full installation in /usr/local/git-1.6.6/ and thus that
the git commands are installed at
/usr/local/git-1.6.6/libexec/git-core/, the reset for 1.6.6 would look
like this:

$ GIT_WORK_TREE=$HOME/rawdata/ \
GIT_DIR=$HOME/rawdata/.git \
GIT_EXEC_PATH=/usr/local/git-1.6.6/libexec/git-core/ \
/usr/local/git-1.6.6/bin/git reset --hard

-- 
Cheers,
Ray Chuan

^ permalink raw reply	[relevance 7%]

* [ANNOUNCE] GIT 1.6.6.rc1
@ 2009-12-02 23:24  8% Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-12-02 23:24 UTC (permalink / raw)
  To: git

A release candidate GIT 1.6.6.rc1 is available at the usual places
for testing:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.6.rc1.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.6.rc1.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.6.rc1.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  testing/git-*-1.6.6.rc1-1.fc11.$arch.rpm	(RPM)

Git v1.6.6 Release Notes (draft)
================================

Notes on behaviour change
-------------------------

 * In this release, "git fsck" defaults to "git fsck --full" and
   checks packfiles, and because of this it will take much longer to
   complete than before.  If you prefer a quicker check only on loose
   objects (the old default), you can say "git fsck --no-full".  This
   has been supported by 1.5.4 and newer versions of git, so it is
   safe to write it in your script even if you use slightly older git
   on some of your machines.

Preparing yourselves for compatibility issues in 1.7.0
------------------------------------------------------

In git 1.7.0, which is planned to be the release after 1.6.6, there will
be a handful of behaviour changes that will break backward compatibility.

These changes were discussed long time ago and existing behaviours have
been identified as more problematic to the userbase than keeping them for
the sake of backward compatibility.

When necessary, transition strategy for existing users has been designed
not to force them running around setting configuration variables and
updating their scripts in order to either keep the traditional behaviour
or use the new behaviour on the day their sysadmin decides to install
the new version of git.  When we switched from "git-foo" to "git foo" in
1.6.0, even though the change had been advertised and the transition
guide had been provided for a very long time, the users procrastinated
during the entire transtion period, and ended up panicking on the day
their sysadmins updated their git installation.  We tried very hard to
avoid repeating that unpleasantness.

For changes decided to be in 1.7.0, we have been much louder to strongly
discourage such procrastination.  If you have been using recent versions
of git, you would have already seen warnings issued when you exercised
features whose behaviour will change, with the instruction on how to
keep the existing behaviour if you want to.  You hopefully should be
well prepared already.

Of course, we have also given "this and that will change in 1.7.0;
prepare yourselves" warnings in the release notes and announcement
messages.  Let's see how well users will fare this time.

 * "git push" into a branch that is currently checked out (i.e. pointed by
   HEAD in a repository that is not bare) will be refused by default.

   Similarly, "git push $there :$killed" to delete the branch $killed
   in a remote repository $there, when $killed branch is the current
   branch pointed at by its HEAD, will be refused by default.

   Setting the configuration variables receive.denyCurrentBranch and
   receive.denyDeleteCurrent to 'ignore' in the receiving repository
   can be used to override these safety features.  Versions of git
   since 1.6.2 have issued a loud warning when you tried to do them
   without setting the configuration, so repositories of people who
   still need to be able to perform such a push should already have
   been future proofed.

   Please refer to:

   http://git.or.cz/gitwiki/GitFaq#non-bare
   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

   for more details on the reason why this change is needed and the
   transition process that already took place so far.

 * "git send-email" will not make deep threads by default when sending a
   patch series with more than two messages.  All messages will be sent
   as a reply to the first message, i.e. cover letter.  Git 1.6.6 (this
   release) will issue a warning about the upcoming default change, when
   it uses the traditional "deep threading" behaviour as the built-in
   default.  To squelch the warning but still use the "deep threading"
   behaviour, give --chain-reply-to option or set sendemail.chainreplyto
   to true.

   It has been possible to configure send-email to send "shallow thread"
   by setting sendemail.chainreplyto configuration variable to false.
   The only thing 1.7.0 release will do is to change the default when
   you haven't configured that variable.

 * "git status" will not be "git commit --dry-run".  This change does not
   affect you if you run the command without pathspec.

   Nobody sane found the current behaviour of "git status Makefile" useful
   nor meaningful, and it confused users.  "git commit --dry-run" has been
   provided as a way to get the current behaviour of this command since
   1.6.5.

 * "git diff" traditionally treated various "ignore whitespace" options
   only as a way to filter the patch output.  "git diff --exit-code -b"
   exited with non-zero status even if all changes were about changing the
   ammount of whitespace and nothing else.  and "git diff -b" showed the
   "diff --git" header line for such a change without patch text.

   In 1.7.0, the "ignore whitespaces" will affect the semantics of the
   diff operation itself.  A change that does not affect anything but
   whitespaces will be reported with zero exit status when run with
   --exit-code, and there will not be "diff --git" header for such a
   change.


Updates since v1.6.5
--------------------

(subsystems)

 * various git-gui updates including new translations, wm states, etc.

 * git-svn updates.

 * "git fetch" over http learned a new mode that is different from the
   traditional "dumb commit walker".

(portability)

 * imap-send can be built on mingw port.

(performance)

 * "git diff -B" has smaller memory footprint.

(usability, bells and whistles)

 * The object replace mechanism can be bypassed with --no-replace-objects
   global option given to the "git" program.

 * In configuration files, a few variables that name paths can begin with ~/
   and ~username/ and they are expanded as expected.

 * "git subcmd -h" now shows short usage help for many more subcommands.

 * "git bisect reset" can reset to an arbitrary commit.

 * "git checkout frotz" when there is no local branch "frotz" but there
   is only one remote tracking branch "frotz" is taken as a request to
   start the named branch at the corresponding remote tracking branch.

 * "git commit -c/-C/--amend" can be told with a new "--reset-author" option
   to ignore authorship information in the commit it is taking the message
   from.

 * "git describe" can be told to add "-dirty" suffix with "--dirty" option.

 * "git diff" learned --submodule option to show a list of one-line logs
   instead of differences between the commit object names.

 * "git diff" learned to honor diff.color.func configuration to paint
   function name hint printed on the hunk header "@@ -j,k +l,m @@" line
   in the specified color.

 * "git fetch" learned --all and --multiple options, to run fetch from
   many repositories, and --prune option to remove remote tracking
   branches that went stale.  These make "git remote update" and "git
   remote prune" less necessary (there is no plan to remove "remote
   update" nor "remote prune", though).

 * "git fsck" by default checks the packfiles (i.e. "--full" is the
   default); you can turn it off with "git fsck --no-full".

 * "git grep" can use -F (fixed strings) and -i (ignore case) together.

 * import-tars contributed fast-import frontend learned more types of
   compressed tarballs.

 * "git instaweb" knows how to talk with mod_cgid to apache2.

 * "git log --decorate" shows the location of HEAD as well.

 * "git log" and "git rev-list" learned to take revs and pathspecs from
   the standard input with the new "--stdin" option.

 * "--pretty=format" option to "log" family of commands learned:

   . to wrap text with the "%w()" specifier.
   . to show reflog information with "%g[sdD]" specifier.

 * "git notes" command to annotate existing commits.

 * "git merge" (and "git pull") learned --ff-only option to make it fail
   if the merge does not result in a fast-forward.

 * The ancient "git merge <message> HEAD <branch>..." syntax will be
   removed in later versions of git.  A warning is given and tells
   users to use the "git merge -m <message> <branch>..." instead.

 * "git mergetool" learned to use p4merge.

 * "git rebase -i" learned "reword" that acts like "edit" but immediately
   starts an editor to tweak the log message without returning control to
   the shell, which is done by "edit" to give an opportunity to tweak the
   contents.

 * "git send-email" can be told with "--envelope-sender=auto" to use the
   same address as "From:" address as the envelope sender address.

 * "git send-email" will issue a warning when it defaults to the
   --chain-reply-to behaviour without being told by the user and
   instructs to prepare for the change of the default in 1.7.0 release.

 * In "git submodule add <repository> <path>", <path> is now optional and
   inferred from <repository> the same way "git clone <repository>" does.

 * "git svn" learned to read SVN 1.5+ and SVK merge tickets.

 * "gitweb" can optionally render its "blame" output incrementally (this
   requires JavaScript on the client side).

 * Author names shown in gitweb output are links to search commits by the
   author.

Fixes since v1.6.5
------------------

All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.

 * Enumeration of available merge strategies iterated over the list of
   commands in a wrong way, sometimes producing an incorrect result.
   Will backport by merging ed87465 (builtin-merge.c: call
   exclude_cmds() correctly., 2009-11-25).

 * "git format-patch revisions... -- path" issued an incorrect error
   message that suggested to use "--" on the command line when path
   does not exist in the current work tree (it is a separate matter if
   it makes sense to limit format-patch with pathspecs like that
   without using the --full-diff option).  Will backport by merging
   7e93d3b (format-patch: add test for parsing of "--", 2009-11-26).

 * "git shortlog" did not honor the "encoding" header embedded in the
   commit object like "git log" did.  Will backport by merging 79f7ca0
   (shortlog: respect commit encoding, 2009-11-25).

----------------------------------------------------------------

Changes since v1.6.6-rc0 are as follows:

Avery Pennarun (1):
      builtin-merge.c: call exclude_cmds() correctly.

Benjamin Kramer (1):
      Explicitly truncate bswap operand to uint32_t

Bert Wesarg (2):
      Give the hunk comment its own color
      get_ref_states: strdup entries and free util in stale list

Björn Gustavsson (11):
      Teach the --all option to 'git fetch'
      Teach the --multiple option to 'git fetch'
      Add the configuration option skipFetchAll
      Add missing test for 'git remote update --prune'
      Re-implement 'git remote update' using 'git fetch'
      Clarify and correct -z
      apply: apply works outside a repository
      apply: Format all options using back-quotes
      apply: Use the term "working tree" consistently
      Fix over-simplified documentation for 'git log -z'
      gitworkflows: Consistently back-quote git commands

Brian Gernhardt (1):
      t/gitweb-lib: Split HTTP response with non-GNU sed

Christian Couder (6):
      Documentation: add "Fighting regressions with git bisect" article
      replace: use a GIT_NO_REPLACE_OBJECTS env variable
      Documentation: fix typos and spelling in replace documentation
      Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
      bisect: simplify calling visualizer using '--bisect' option
      Documentation: update descriptions of revision options related to '--bisect'

David Aguilar (1):
      help: Do not unnecessarily look for a repository

David Soria Parra (1):
      Documentation: Document --branch option in git clone synopsis

Erick Mattos (1):
      commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author

Felipe Contreras (3):
      format-patch: fix parsing of "--" on the command line
      format-patch: add test for parsing of "--"
      send-email: automatic envelope sender

Horst H. von Brand (1):
      git-pull.sh: Fix call to git-merge for new command format

Jakub Narebski (10):
      gitweb: Add optional "time to generate page" info in footer
      gitweb: Incremental blame (using JavaScript)
      gitweb: Colorize 'blame_incremental' view during processing
      gitweb: Create links leading to 'blame_incremental' using JavaScript
      gitweb: Minify gitweb.js if JSMIN is defined
      t/gitweb-lib.sh: Split gitweb output into headers and body
      gitweb: Document current snapshot rules via new tests
      gitweb.js: Harden setting blamed commit info in incremental blame
      gitweb: Make linking to actions requiring JavaScript a feature
      gitweb: Add link to other blame implementation in blame views

Jay Soffian (4):
      remote: refactor some logic into get_stale_heads()
      teach warn_dangling_symref to take a FILE argument
      builtin-fetch: add --prune option
      builtin-fetch: add --dry-run option

Jeff King (1):
      prune-packed: only show progress when stderr is a tty

Johannes Sixt (2):
      t4014-format-patch: do not assume 'test' is available as non-builtin
      Add a notice that only certain functions can print color escape codes

Jonathan Nieder (1):
      Makefile: do not clean arm directory

Junio C Hamano (19):
      mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
      Pretty-format: %[+-]x to tweak inter-item newlines
      read_revision_from_stdin(): use strbuf
      Teach --stdin option to "log" family
      setup_revisions(): do not call get_pathspec() too early
      Make --stdin option to "log" family read also pathspecs
      t9001: test --envelope-sender option of send-email
      Add trivial tests for --stdin option to log family
      Protect scripted Porcelains from GREP_OPTIONS insanity
      builtin-apply.c: pay attention to -p<n> when determining the name
      Remove dead code from "git am"
      emit_line(): don't emit an empty <SET><RESET> followed by a newline
      Update draft release notes to 1.6.6 before merging topics for -rc1
      git-merge: a deprecation notice of the ancient command line syntax
      Update draft release notes to 1.6.6 before -rc1
      Do not misidentify "git merge foo HEAD" as an old-style invocation
      merge: do not add standard message when message is given with -m option
      Prepare for 1.6.5.4
      Git 1.6.6-rc1

Mark Rada (2):
      gitweb: check given hash before trying to create snapshot
      gitweb: Smarter snapshot names

Martin Storsjö (3):
      Disable CURLOPT_NOBODY before enabling CURLOPT_PUT and CURLOPT_POST
      Refactor winsock initialization into a separate function
      Enable support for IPv6 on MinGW

Matthew Ogilvie (5):
      cvsserver doc: database generally can not be reproduced consistently
      config documentation: some configs are auto-set by git-init
      t2300: use documented technique to invoke git-sh-setup
      t3409 t4107 t7406 t9150: use dashless commands
      t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH

Matthieu Moy (4):
      merge-recursive: point the user to commit when file would be overwritten.
      user-manual: Document that "git merge" doesn't like uncommited changes.
      merge-recursive: make the error-message generation an extern function
      builtin-merge: show user-friendly error messages for fast-forward too.

Michael J Gruber (1):
      Documentation: Fix a few i.e./e.g. mix-ups

Nanako Shiraishi (2):
      t1200: fix a timing dependent error
      prepare send-email for smoother change of --chain-reply-to default

Nicolas Pitre (1):
      pack-objects: split implications of --all-progress from progress activation

Ramsay Allan Jones (1):
      git-count-objects: Fix a disk-space under-estimate on Cygwin

René Scharfe (2):
      strbuf_add_wrapped_text(): skip over colour codes
      mergetool--lib: simplify guess_merge_tool()

Stephen Boyd (3):
      gitweb.js: fix null object exception in initials calculation
      instaweb: restart server if already running
      gitweb.js: fix padLeftStr() and its usage

Tay Ray Chuan (1):
      remote-curl.c: fix rpc_out()

Uwe Kleine-König (1):
      shortlog: respect commit encoding

^ permalink raw reply	[relevance 8%]

* [ANNOUNCE] Git 1.6.6.rc2
@ 2009-12-10  1:44 12% Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-12-10  1:44 UTC (permalink / raw)
  To: git

A release candidate Git 1.6.6.rc2 is available at the usual places
for testing:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.6.rc2.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.6.rc2.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.6.rc2.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  testing/git-*-1.6.6.rc2-1.fc11.$arch.rpm	(RPM)

The changes since rc1 are mostly updates to the subsystems.

The regression to "git pull" that made the command give annoying warning
message when there is no local commit has been fixed; it appeared in rc1.

----------------------------------------------------------------

Changes since v1.6.6-rc1 are as follows:

Alex Vandiver (3):
      git-svn: sort svk merge tickets to account for minimal parents
      git-svn: Set svn.authorsfile to an absolute path when cloning
      git-svn: set svn.authorsfile earlier when cloning

Alexander Gavrilov (1):
      git-gui: Increase blame viewer usability on MacOS.

Bernt Hansen (1):
      gitk: Skip translation of "wrong Tcl version" message

Brandon Casey (2):
      t4201: use ISO8859-1 rather than ISO-8859-1
      t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'

Clemens Buchacher (1):
      git-gui: search 4 directories to improve statistic of gc hint

Eric Wong (1):
      git svn: log removals of empty directories

Greg Price (1):
      git svn: Don't create empty directories whose parents were deleted

Guillermo S. Romero (1):
      gitk: Add configuration for UI colour scheme

Heiko Voigt (1):
      git gui: make current branch default in "remote delete branch" merge check

Jakub Narebski (1):
      gitweb: Describe (possible) gitweb.js minification in gitweb/README

Jan Krüger (1):
      pull: clarify advice for the unconfigured error case

Jeff King (3):
      rerere: don't segfault on failure to open rr-cache
      reset: improve worktree safety valves
      add-interactive: fix deletion of non-empty files

Jens Lehmann (2):
      gitk: Fix diffing committed -> staged (typo in diffcmd)
      gitk: Use the --submodule option for displaying diffs when available

Jindrich Makovicka (1):
      git-gui: suppress RenderBadPicture X error caused by Tk bug

Johan Herland (1):
      Fix crasher on encountering SHA1-like non-note in notes tree

Junio C Hamano (9):
      Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
      Unconditionally set man.base.url.for.relative.links
      Git 1.6.5.4
      Documentation: xmlto 0.0.18 does not know --stringparam
      Prepare for 1.6.5.5
      Git 1.6.5.5
      Revert recent "git merge <msg> HEAD <commit>..." deprecation
      Update draft release notes to 1.6.6 before -rc2
      Git 1.6.6-rc2

Linus Torvalds (1):
      Fix diff -B/--dirstat miscounting of newly added contents

Markus Heidelberg (1):
      gitk: Fix "git gui blame" invocation when called from top-level directory

Mizar (2):
      gitk: Add Japanese translation
      gitk: Update Japanese translation

Pat Thoyts (4):
      gitk: Use themed tk widgets
      gitk: Fix errors in the theme patch
      gitk: Default to the system colours on Windows
      gitk: Fix selection of tags

Paul Mackerras (5):
      gitk: Restore scrolling position of diff pane on back/forward in history
      gitk: Add a user preference to enable/disable use of themed widgets
      gitk: Show diff of commits at end of compare-commits output
      gitk: Don't compare fake children when comparing commits
      gitk: Improve appearance of radiobuttons and checkbuttons

René Scharfe (1):
      archive: clarify description of path parameter

SZEDER Gábor (1):
      bash: update 'git commit' completion

Sitaram Chamarty (1):
      gitk: Disable checkout of remote branches

Todd Zullinger (1):
      Documentation: Avoid use of xmlto --stringparam

^ permalink raw reply	[relevance 12%]

* [ANNOUNCE] Git 1.6.6.rc4
@ 2009-12-20 22:59 14% Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-12-20 22:59 UTC (permalink / raw)
  To: git

A release candidate Git 1.6.6.rc4 is available at the usual places
for final testing:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.6.rc4.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.6.rc4.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.6.rc4.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  testing/git-*-1.6.6.rc4-1.fc11.$arch.rpm	(RPM)

Hopefully I'll do the final this Wednesday to make 1.6.6 a holiday gift to
everybody.

I would very much prefer news outlets like kernelpodcast.org and lwn.net
_not_ to say "... is released; it comes with many _fixes_".  Fixes to
released versions have indeed been included in the 'master' branch, but
they all appear in the maintenance release.  The main _point_ of using a
new feature release like 1.6.6 is to get new _features_, so it is more
appropriate to say "it comes with many new features."

Thanks for all contributors who have worked hard to whip this release into
shape.

----------------------------------------------------------------

Changes since v1.6.6-rc3 are as follows:

Björn Gustavsson (1):
      rebase -i: abort cleanly if the editor fails to launch

Eric Wong (2):
      git svn: make empty directory creation gc-aware
      t9146: use 'svn_cmd' wrapper

Junio C Hamano (1):
      Git 1.6.6-rc4

Stephen Boyd (2):
      api-strbuf.txt: fix typos and document launch_editor()
      technical-docs: document hash API

^ permalink raw reply	[relevance 14%]

* [ANNOUNCE] Git 1.6.6.rc3
@ 2009-12-17  0:30 14% Junio C Hamano
  0 siblings, 0 replies; 55+ results
From: Junio C Hamano @ 2009-12-17  0:30 UTC (permalink / raw)
  To: git

A release candidate Git 1.6.6.rc3 is available at the usual places
for testing:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.6.rc3.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.6.rc3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.6.rc3.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  testing/git-*-1.6.6.rc3-1.fc11.$arch.rpm	(RPM)

Things have really calmed down and hopefully we can give the final release
as holiday present to everybody in time ;-)

----------------------------------------------------------------

Changes since v1.6.6-rc2 are as follows:

Björn Gustavsson (1):
      bash: Support new 'git fetch' options

Jeff King (1):
      ignore unknown color configuration

Johannes Sixt (1):
      help.autocorrect: do not run a command if the command given is junk

Junio C Hamano (7):
      Remove post-upload-hook
      Fix archive format with -- on the command line
      Git 1.6.5.6
      Update Release Notes for 1.6.6 to remove old bugfixes
      worktree: don't segfault with an absolute pathspec without a work tree
      Git 1.6.5.7
      Git 1.6.6-rc3

Nanako Shiraishi (1):
      Illustrate "filter" attribute with an example

^ permalink raw reply	[relevance 14%]

Results 1-55 of 55 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-12-17  0:30 14% [ANNOUNCE] Git 1.6.6.rc3 Junio C Hamano
2009-12-20 22:59 14% [ANNOUNCE] Git 1.6.6.rc4 Junio C Hamano
2009-12-10  1:44 12% [ANNOUNCE] Git 1.6.6.rc2 Junio C Hamano
2009-12-02 23:24  8% [ANNOUNCE] GIT 1.6.6.rc1 Junio C Hamano
2012-01-22  5:46  7% [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command Jonathan Nieder
2009-12-29  6:47  6% Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE Fyn Fynn
2009-12-29  8:12  7% ` Tay Ray Chuan
2009-12-29  8:38  0% ` Nguyen Thai Ngoc Duy
2009-12-29 11:04  0%   ` Nanako Shiraishi
2009-12-29 11:36  0%     ` Nguyen Thai Ngoc Duy
2009-12-29 21:09  0%       ` Fyn Fynn
2009-12-27 21:59  6% Git reproducible corruption errors on merge/checkout not detected by git fsck --full --strict Denis Rosset
2009-12-24  1:06  6% [ANNOUNCE] Git 1.6.6 Junio C Hamano
2010-01-19 22:05  6% [BUG] Git 1.6.6 can't clone tags after filter-branch James Pickens
2012-05-31 11:48  5% git version statistics Jeff King
2010-01-20 10:45  5% Error when cloning gc'ed repository Andre Loker
2010-01-07  3:58  4% [PATCH] Fix segfault in fast-export Mike Mueller
2010-01-18 17:44  0% ` Heiko Voigt
     [not found]     <AANLkTikRrewCLGDTU7DjVssjpxz-EFK8AhRScAGPRumg@mail.gmail.com>
     [not found]     ` <20110116092315.GA27542@n2100.arm.linux.org.uk>
2011-01-16 11:08       ` cannot fetch arm git tree Uwe Kleine-König
     [not found]         ` <AANLkTinrZ0GnT71GCueUUpAXM5ckq+LBd0RjA51DMR-a@mail.gmail.com>
2011-01-16 13:42           ` Russell King - ARM Linux
2011-01-21 13:38  4%         ` Detlef Vollmann
2011-01-21 13:47  0%           ` Uwe Kleine-König
2011-01-21 13:57  0%             ` Russell King - ARM Linux
2011-01-21 14:28  0%               ` Detlef Vollmann
2011-01-21 14:30  0%                 ` Jello huang
     [not found]     <20100211234753.22574.48799.reportbug@gibbs.hungrycats.org>
2010-02-14  1:18     ` [PATCH] don't use mmap() to hash files Dmitry Potapov
2010-02-18  1:16       ` [PATCH] Teach "git add" and friends to be paranoid Junio C Hamano
2010-02-18 10:14         ` Thomas Rast
2010-02-18 18:16           ` Junio C Hamano
2010-02-18 19:58             ` Nicolas Pitre
2010-02-18 20:11               ` 16 gig, 350,000 file repository Bill Lear
2010-02-18 20:58                 ` Nicolas Pitre
2010-02-22 22:20  4%               ` Bill Lear
2010-02-22 22:31  0%                 ` Nicolas Pitre
     [not found]     <b507cb050912132222x7e1daa9cw73b13f3db0ee22c6@mail.gmail.com>
2009-12-14  6:25  4% ` How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)? Doug Ireton
2009-12-14  7:55  0%   ` Matthieu Moy
     [not found]     <D6F784B72498304C93A8A4691967698E8EE2C45016@REX2.intranet.epfl.ch>
2010-01-08 21:59  4% ` unchecked mallocs Marinescu Paul dan
2010-02-14 19:45  4% git stash pop not reapplying deletions Steve Folly
2010-02-14 22:08  0% ` Thomas Rast
2010-02-15 14:32  0%   ` Steve Folly
2010-01-14 23:45  4% git clone against firewall Sebastian Pipping
2010-01-15 18:17  0% ` Junio C Hamano
2010-03-09 16:19  4% Portability patches vs 1.7.0.2 [5/6] Gary V. Vaughan
2011-03-14 23:48  3% [PATCH 1/2] fetch-pack: Finish negotation if remote replies "ACK %s ready" Shawn O. Pearce
2010-05-20  9:50  3% [PATCH v2] gitk: Show notes by default (like git log do) Kirill Smelkov
2010-05-30  2:22  0% ` Paul Mackerras
2011-03-15  0:59  3% [PATCH 1/4 v2] fetch-pack: Finish negotation if remote replies "ACK %s ready" Shawn O. Pearce
2011-02-15 16:57  3% [PATCH] smart-http: Don't use Expect: 100-Continue Shawn O. Pearce
2010-02-10 12:41     git-svn taking a long time David Kågedal
2010-02-10 16:59  4% ` Andrew Myrick
2011-07-16 10:24     Google Code supports Git Nguyen Thai Ngoc Duy
2011-07-17  2:26  3% ` Shawn Pearce
2012-06-05 18:20     git smart protocol via WebSockets - feedback wanted Stephan Peijnik
2012-06-05 18:36  4% ` Shawn Pearce
2012-06-05 18:31     ` Junio C Hamano
2012-06-05 18:41  4%   ` Stephan Peijnik
2012-06-05 18:54  0%     ` Shawn Pearce
2012-06-05 19:28  0%       ` Stephan Peijnik
2010-04-12 13:47     simplest git deamon? Mihamina Rakotomandimby
2010-04-12 14:22  4% ` Shawn O. Pearce
2010-02-09 16:39     git + davfs2, is it safe? Gábor Farkas
2010-02-09 17:57  6% ` Shawn O. Pearce
2009-10-19  7:56     git fsck not identifying corrupted packs Sergio Callegari
2009-10-19  9:11     ` Johannes Sixt
2009-10-19 10:04       ` Johannes Schindelin
2009-10-19 19:03         ` Junio C Hamano
2009-10-20  6:26           ` Matthieu Moy
2009-10-20  6:45             ` Junio C Hamano
2009-10-20  9:25               ` Alex Riesen
2009-10-20 10:22                 ` Johannes Schindelin
2009-10-20 11:56  4%               ` Matthieu Moy
2009-10-20 18:46  0%                 ` [RFC/PATCH] fsck: default to "git fsck --full" Junio C Hamano
2010-01-23 22:04     [PATCH (resend 3)] git gui: Use git diff --submodule when available Jens Lehmann
2010-01-23 22:34  4% ` Shawn O. Pearce
2010-01-23 22:42  0%   ` Jens Lehmann
2010-05-11  8:26     [PATCH] gitk: Show notes Kirill Smelkov
2010-05-11 14:35     ` Michael J Gruber
2010-05-12  8:56  3%   ` Kirill Smelkov
2010-02-18 18:13     RFD: git-bzr: anyone interested? Gabriel Filion
2010-02-18 18:37     ` Sverre Rabbelier
2010-02-19  7:05       ` Gabriel Filion
2010-02-19  7:49         ` Sverre Rabbelier
2010-02-19 12:52           ` Gabriel
2010-02-19 13:38  4%         ` Sverre Rabbelier
2010-02-19 15:15  0%           ` Writing git remote helpers Gabriel
2011-04-26 15:28     [PATCH] http: clear POSTFIELDS when initializing a slot Junio C Hamano
2011-04-26 16:18  6% ` Shawn Pearce

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).