* Re: [PATCH] clone: disconnect transport after fetching
From: Daniel Barkalow @ 2009-09-02 16:38 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Sverre Rabbelier, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <20090902063647.GA29559@coredump.intra.peff.net>
On Wed, 2 Sep 2009, Jeff King wrote:
> The current code just leaves the transport in whatever state
> it was in after performing the fetch. For a non-empty clone
> over the git protocol, the transport code already
> disconnects at the end of the fetch.
>
> But for an empty clone, we leave the connection hanging, and
> eventually close the socket when clone exits. This causes
> the remote upload-pack to complain "the remote end hung up
> unexpectedly". While this message is harmless to the clone
> itself, it is unnecessarily scary for a user to see and may
> pollute git-daemon logs.
>
> This patch just explicitly calls disconnect after we are
> done with the remote end, which sends a flush packet to
> upload-pack and cleanly disconnects, avoiding the error
> message.
>
> Other transports are unaffected or slightly improved:
>
> - for a non-empty repo over the git protocol, the second
> disconnect is a no-op (since we are no longer connected)
>
> - for "walker" transports (like HTTP or FTP), we actually
> free some used memory (which previously just sat until
> the clone process exits)
>
> - for "rsync", disconnect is always a no-op anyway
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This was suggested by Daniel, so theoretically
>
> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
>
> :)
This is what I intended, so:
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
> As you can see from the commit message, I did a little extra hunting to
> make sure we are not going to impact any other code paths, and I am
> pretty sure we are fine.
Also, builtin-fetch already does the explicit disconnect, and commonly
exercises both the "we want something" and "we don't want anything" cases,
so any problems would have to be surprisingly clone-specific.
> builtin-clone.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 991a7ae..0f231d8 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -580,8 +580,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> option_no_checkout = 1;
> }
>
> - if (transport)
> + if (transport) {
> transport_unlock_pack(transport);
> + transport_disconnect(transport);
> + }
>
> if (!option_no_checkout) {
> struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
> --
> 1.6.4.2.401.ga275f.dirty
>
^ permalink raw reply
* [ANNOUNCE] GitTogether '09 (Developer/User Summit Oct 26-28)
From: Shawn O. Pearce @ 2009-09-02 15:23 UTC (permalink / raw)
To: git; +Cc: gittogether
Google is hosting GitTogether '09, October 26th through 28th, at
its Mountain View, CA headquarters. I had posted before that were
planning for these dates; now it is certain.
Like last year, this GitTogether immediately follows the Google
Summer of Code mentor summit, so some of our end-user groups may
already have representatives in the area and might like to attend.
We've timed the GitTogether to follow the summit so we can get some
users to attend while they are still in the area.
Git contributors and users alike are welcome to attend. Admission is
free, as everything is being donated by Google, but you will need
to arrange for your own travel and lodging. If you are looking
at flights try the SJC and SFO airports. SFO usually has cheaper
flights as its a bigger, more active airport.
We are looking to solicit proposals for talks, round-table
discussions, centers of focus for patch hack-a-thons, etc.
A Git Wiki page is being used for planning:
http://git.or.cz/gitwiki/GitTogether09
and of course, so is this email thread.
If you would like to attend, please add your name to the Attendees
list on the wiki page, even if you had previously responded to the
survey that was posted a while ago.
--
Shawn.
^ permalink raw reply
* [PATCH] git-pull: fix fetch-options.txt to not document --quiet and --verbose twice in git-pull.txt
From: Emmanuel Trillaud @ 2009-09-02 14:38 UTC (permalink / raw)
To: git
Hello all!
the current man page of git-pull documents twice the --quiet and
--verbose options. fetch-options.txt and merge-options.txt which both
documents these options.
I choose to "ifndef" the paragraphs in fetch-options.txt because IMHO
they give too much details on the --quiet option (see the patch
below). Of course we could modify merge-options.txt instead (the
--quiet paragraph just says : "operate quietly"), I can provide a
patch if you want.
Best regards
-----------------
git-pull.txt includes fetch-options.txt and merge-options.txt which both
document the --quiet and --verbose parameters. So we supress the
--quiet and --verbose paragraphs if fetch-options.txt is included by
git-pull.txt.
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
Documentation/fetch-options.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ea3b1bc..5eb2b0e 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,3 +1,4 @@
+ifndef::git-pull[]
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
@@ -6,6 +7,7 @@
-v::
--verbose::
Be verbose.
+endif::git-pull[]
-a::
--append::
--
1.6.4.2.253.g0b1fac
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Mark Brown @ 2009-09-02 12:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902051248.GB12046@coredump.intra.peff.net>
On Wed, Sep 02, 2009 at 01:12:48AM -0400, Jeff King wrote:
> On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:
> > [1] It might even make sense to omit other sections and show only
> > "updated" and "unmerged" in this order when the index is unmerged, but
> > that is a lot more drastic change for 1.7.0.
> I think that is a really bad idea. The mental model of "git status"
> (versus individual diff or ls-files commands) is to see _everything_
> going on in the repo. Showing a subset breaks that model and gives a
> false sense of what is actually happening.
It would be nice to be able to explicitly ask to suppress some of the
output for cases where there's a lot of it and only a small part is
interesting (like when resolving a large merge as mentioned earlier) - I
often end up doing this by hand in those situations. I do agree that
doing this by default would be surprising.
^ permalink raw reply
* Re: [PATCH] git-submodule and --upload-pack
From: Giulio Eulisse @ 2009-09-02 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk50jtud8.fsf@alter.siamese.dyndns.org>
>> There was a thread a while ago aboyt having --upload-pack support for
>> git-submodule.
>>
>> Given that there was no followup (as far as I can tell) and I needed
>> pretty much
>> the same functionality I ported Jason's patch to work on top of
>> 1.6.4.2.
>
> Thanks.
>
> Can you point at the original patch with a usable commit log
> message, in
> the gmane archive (i.e. http://thread.gmane.org/...) if possible? I
> do not think we have that patch queued anywhere even in 'pu'.
Ciao,
sorry for the mangled patch... Looks like Mail.app did something
weird...
http://article.gmane.org/gmane.comp.version-control.git/104188/match=git+submodule+upload+pack
> Given that it looks like a new feature, I do not think it would be
> appropriate for any of the future 1.6.4.X series, but if it is
> useful we
> may want to have it in the upcoming 1.6.5 release.
[...]
Ok. I will try to follow your suggestion and post an updated patch.
Ciao,
Giulio
^ permalink raw reply
* Re: [PATCH] git-completion.bash: prevent 'git help' from searching for git repository
From: Sverre Rabbelier @ 2009-09-02 11:47 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20090902095843.28914.qmail@3cd9dde586d86b.315fe32.mid.smarden.org>
Heya,
On Wed, Sep 2, 2009 at 11:58, Gerrit Pape<pape@smarden.org> wrote:
> + for i in $(git --git-dir=/nonexistent help -a|egrep '^ ')
Wouldn't implementing "git --no-git-dir" be more appropriate?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: David Aguilar @ 2009-09-02 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Sixt, bill lam, git
In-Reply-To: <7vljkxdiil.fsf@alter.siamese.dyndns.org>
On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:
>
> Here is how I would justify the change (the patch is the same as Hannes's
> first version.
>
> From: Johannes Sixt <j6t@kdbg.org>
> Date: Tue, 1 Sep 2009 22:13:53 +0200
> Subject: [PATCH] status: list unmerged files much later
>
> When resolving a conflicted merge, two lists in the status output need
> more attention from the user than other parts.
>
> - the list of updated paths is useful to review the amount of changes the
> merge brings in (the user cannot do much about them other than
> reviewing, though); and
>
> - the list of unmerged paths needs the most attention from the user; the
> user needs to resolve them in order to proceed.
>
> Since the output of git status does not by default go through the pager,
> the early parts of the output can scroll away at the top. It is better to
> put the more important information near the bottom. During a merge, local
> changes that are not in the index are minimum, and you should keep the
> untracked list small in any case, so moving the unmerged list from the top
> of the output to immediately after the list of updated paths would give us
> the optimum layout..
I agree with all of this but would also add that we can have
our cake and eat it too with respect to wanting to "keep
similar things together" and having "unmerged near bottom".
No one has suggested this, so I figured I would.
What do you think about this layout?
- untracked
- staged
- modified
- unmerged
This isn't the first thing someone would think of, but here's
why it is intuitive:
- untracked entries come first because in the git world they
are weird. We don't like to see these things and we tend to
.gitignore them away.
- staged entries come next, though we know that in practice
staged is often shown first since we tend to not care about
untracked files. This often contains entries when merging
but we do not often do much with these besides review them.
- modified entries come next because they need our attention.
When merging this list is often small or non-existant,
thus unmerged often follows immediately after staged.
- unmerged comes last for all of the reasons listed above.
We give these special treatment because they often
require even more attention than modified files.
What do you guys think?
While I've got you guys.. I have a patch for the new 1.7
status that makes it:
git status [<tree-ish>] [--] [pathspec]
(it adds support for tree-ish)
I added that because I thought that the porcelain-ish short
status output could be useful for "what does commit --amend
do" from a script-writers' pov, and thus adding <tree-ish>
enables git status -s HEAD^.
Is this a good idea? I'll send the patch if others are
interested. It seemed useful to me; my rationale was that
right now git-status is hardcoded to HEAD and thus exposing
that variable seemed useful.
BTW is status -s intended to be something plumbing-like;
something we can build upon and expect to be stable?
I'm just curious because other commands have a --porcelain
option and I wasn't sure if this was the intent.
Thanks,
--
David
^ permalink raw reply
* [PATCH] git-completion.bash: prevent 'git help' from searching for git repository
From: Gerrit Pape @ 2009-09-02 9:58 UTC (permalink / raw)
To: Junio C Hamano, git
On 'git <TAB><TAB>' the bash completion runs 'git help -a'. Since
'git help' actually doesn't need to be run inside a git repository,
this commit uses the option --git-dir=/nonexistent to prevent it
from searching a git directory. Unnecessary searching for a git
directory can be annoying in auto-mount environments.
The annoying behavior and suggested fix has been reported by Vincent
Danjean through
http://bugs.debian.org/539273
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bf688e1..d51854a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -500,7 +500,7 @@ __git_all_commands ()
return
fi
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ ')
+ for i in $(git --git-dir=/nonexistent help -a|egrep '^ ')
do
case $i in
*--*) : helper pattern;;
--
1.6.0.3
^ permalink raw reply related
* [PATCH] git-cvsserver: no longer use deprecated 'git-subcommand' commands
From: Gerrit Pape @ 2009-09-02 9:23 UTC (permalink / raw)
To: Junio C Hamano, git
git-cvsserver still references git commands like 'git-config', which
is depcrecated. This commit changes git-cvsserver to use the
'git subcommand' form.
Sylvain Beucler reported the problem through
http://bugs.debian.org/536067
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-cvsserver.perl | 40 ++++++++++++++++++++--------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ab6cea3..6dc45f5 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -285,7 +285,7 @@ sub req_Root
return 0;
}
- my @gitvars = `git-config -l`;
+ my @gitvars = `git config -l`;
if ($?) {
print "E problems executing git-config on the server -- this is not a git repository or the PATH is not set correctly.\n";
print "E \n";
@@ -702,7 +702,7 @@ sub req_Modified
# Save the file data in $state
$state->{entries}{$state->{directory}.$data}{modified_filename} = $filename;
$state->{entries}{$state->{directory}.$data}{modified_mode} = $mode;
- $state->{entries}{$state->{directory}.$data}{modified_hash} = `git-hash-object $filename`;
+ $state->{entries}{$state->{directory}.$data}{modified_hash} = `git hash-object $filename`;
$state->{entries}{$state->{directory}.$data}{modified_hash} =~ s/\s.*$//s;
#$log->debug("req_Modified : file=$data mode=$mode size=$size");
@@ -1289,7 +1289,7 @@ sub req_ci
# do a checkout of the file if it is part of this tree
if ($wrev) {
- system('git-checkout-index', '-f', '-u', $filename);
+ system('git', 'checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
die "Error running git-checkout-index -f -u $filename : $!";
}
@@ -1331,15 +1331,15 @@ sub req_ci
{
$log->info("Removing file '$filename'");
unlink($filename);
- system("git-update-index", "--remove", $filename);
+ system("git", "update-index", "--remove", $filename);
}
elsif ( $addflag )
{
$log->info("Adding file '$filename'");
- system("git-update-index", "--add", $filename);
+ system("git", "update-index", "--add", $filename);
} else {
$log->info("Updating file '$filename'");
- system("git-update-index", $filename);
+ system("git", "update-index", $filename);
}
}
@@ -1351,7 +1351,7 @@ sub req_ci
return;
}
- my $treehash = `git-write-tree`;
+ my $treehash = `git write-tree`;
chomp $treehash;
$log->debug("Treehash : $treehash, Parenthash : $parenthash");
@@ -1368,7 +1368,7 @@ sub req_ci
}
close $msg_fh;
- my $commithash = `git-commit-tree $treehash -p $parenthash < $msg_filename`;
+ my $commithash = `git commit-tree $treehash -p $parenthash < $msg_filename`;
chomp($commithash);
$log->info("Commit hash : $commithash");
@@ -1821,7 +1821,7 @@ sub req_annotate
# TODO: if we got a revision from the client, use that instead
# to look up the commithash in sqlite (still good to default to
# the current head as we do now)
- system("git-read-tree", $lastseenin);
+ system("git", "read-tree", $lastseenin);
unless ($? == 0)
{
print "E error running git-read-tree $lastseenin $ENV{GIT_INDEX_FILE} $!\n";
@@ -1830,7 +1830,7 @@ sub req_annotate
$log->info("Created index '$ENV{GIT_INDEX_FILE}' with commit $lastseenin - exit status $?");
# do a checkout of the file
- system('git-checkout-index', '-f', '-u', $filename);
+ system('git', 'checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
print "E error running git-checkout-index -f -u $filename : $!\n";
return;
@@ -1861,7 +1861,7 @@ sub req_annotate
close ANNOTATEHINTS
or (print "E failed to write $a_hints: $!\n"), return;
- my @cmd = (qw(git-annotate -l -S), $a_hints, $filename);
+ my @cmd = (qw(git annotate -l -S), $a_hints, $filename);
if (!open(ANNOTATE, "-|", @cmd)) {
print "E error invoking ". join(' ',@cmd) .": $!\n";
return;
@@ -2078,17 +2078,17 @@ sub transmitfile
die "Need filehash" unless ( defined ( $filehash ) and $filehash =~ /^[a-zA-Z0-9]{40}$/ );
- my $type = `git-cat-file -t $filehash`;
+ my $type = `git cat-file -t $filehash`;
chomp $type;
die ( "Invalid type '$type' (expected 'blob')" ) unless ( defined ( $type ) and $type eq "blob" );
- my $size = `git-cat-file -s $filehash`;
+ my $size = `git cat-file -s $filehash`;
chomp $size;
$log->debug("transmitfile($filehash) size=$size, type=$type");
- if ( open my $fh, '-|', "git-cat-file", "blob", $filehash )
+ if ( open my $fh, '-|', "git", "cat-file", "blob", $filehash )
{
if ( defined ( $options->{targetfile} ) )
{
@@ -2935,7 +2935,7 @@ sub update
push @git_log_params, $self->{module};
}
# git-rev-list is the backend / plumbing version of git-log
- open(GITLOG, '-|', 'git-rev-list', @git_log_params) or die "Cannot call git-rev-list: $!";
+ open(GITLOG, '-|', 'git', 'rev-list', @git_log_params) or die "Cannot call git-rev-list: $!";
my @commits;
@@ -3021,7 +3021,7 @@ sub update
next;
}
my $base = eval {
- safe_pipe_capture('git-merge-base',
+ safe_pipe_capture('git', 'merge-base',
$lastpicked, $parent);
};
# The two branches may not be related at all,
@@ -3033,7 +3033,7 @@ sub update
if ($base) {
my @merged;
# print "want to log between $base $parent \n";
- open(GITLOG, '-|', 'git-log', '--pretty=medium', "$base..$parent")
+ open(GITLOG, '-|', 'git', 'log', '--pretty=medium', "$base..$parent")
or die "Cannot call git-log: $!";
my $mergedhash;
while (<GITLOG>) {
@@ -3075,7 +3075,7 @@ sub update
if ( defined ( $lastpicked ) )
{
- my $filepipe = open(FILELIST, '-|', 'git-diff-tree', '-z', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git', 'diff-tree', '-z', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
local ($/) = "\0";
while ( <FILELIST> )
{
@@ -3149,7 +3149,7 @@ sub update
# this is used to detect files removed from the repo
my $seen_files = {};
- my $filepipe = open(FILELIST, '-|', 'git-ls-tree', '-z', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git', 'ls-tree', '-z', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
local $/ = "\0";
while ( <FILELIST> )
{
@@ -3451,7 +3451,7 @@ sub commitmessage
return $message;
}
- my @lines = safe_pipe_capture("git-cat-file", "commit", $commithash);
+ my @lines = safe_pipe_capture("git", "cat-file", "commit", $commithash);
shift @lines while ( $lines[0] =~ /\S/ );
$message = join("",@lines);
$message .= " " if ( $message =~ /\n$/ );
--
1.6.0.3
^ permalink raw reply related
* Better wang parameters!
From: Raphael Vickers @ 2009-09-02 10:17 UTC (permalink / raw)
To: git
Better than bluepilule if you can imagine that. http://zh.ghexduvitie.com/
^ permalink raw reply
* Re: unmerged files listed in the beginning of git-status
From: bill lam @ 2009-09-02 9:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, bill lam, git
In-Reply-To: <200909012140.08953.j6t@kdbg.org>
On Tue, 01 Sep 2009, Johannes Sixt wrote:
> > But unmerged entries are something you need to deal with _first_ before
> > being able to go further, so in that sense it is more important than
> > anything else in the traditional output.
>
> This is actually an argument to place the unmerged entries *last* because this
> is what will be visible after 'git status' finished. Remember that we don't
> pass its output through the pager.
If output of git-status is read indirectly such as by gui client, then
it usually shows the top portion, in such cases, it might be desirable
to put unmerged file (the most important port) immediately visible.
But I don't have that experience.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] git.el: Make it easy to add unmerged files
From: Alexandre Julliard @ 2009-09-02 8:48 UTC (permalink / raw)
To: Martin Nordholts; +Cc: git, Junio C Hamano
In-Reply-To: <4A9E0717.9040801@chromecode.com>
Martin Nordholts <martin@chromecode.com> writes:
> On 08/30/2009 05:58 PM, Alexandre Julliard wrote:
>> Martin Nordholts <martin@chromecode.com> writes:
>>
>>> (Resending as I managed to mangle the previous patch despite trying not to...)
>>>
>>> It is nice and easy to git-add ignored and unknown files in a
>>> git-status buffer. Make it equally easy to add unmerged files which is
>>> a common use case.
>>
>> That's not quite what adding a file means in git.el, unmerged files are
>> considered added already, and marking them resolved is done through the
>> git-resolve-file command. Of course that was implemented before git
>> overloaded the meaning of git-add to mean git-update-index, so maybe we
>> should follow the trend and use git-add-file for all index updates. In
>> that case git-resolve-file should probably be removed.
>
> Since git instructs the user to use git-add for marking unmerged files
> as resolved ("After resolving the conflicts, mark the corrected paths
> with 'git add <paths>' or 'git rm <paths>' and commit the result.") and
> doesn't even mention git-update-index, I think we should change git.el
> accordingly.
>
> But why do we need to also remove and disable git-resolve-file from
> git.el? It doesn't hurt to keep that function and the keybinding, does
> it?
It doesn't hurt much, but having two keybindings for the same thing is a
bit wasteful since there aren't that many simple bindings available. If
we remove it, it opens the door to later reusing the 'R' key for
something else (a git-rename function would be the obvious choice).
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Sverre Rabbelier @ 2009-09-02 8:18 UTC (permalink / raw)
To: Jeff King; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <20090902075713.GA1832@coredump.intra.peff.net>
Heya,
On Wed, Sep 2, 2009 at 09:57, Jeff King<peff@peff.net> wrote:
> 2. Count the commits on each side that are not in the other.
[...]
> You can also do that by parsing the output of:
> git rev-list --left-right $a...$b --
Perhaps it is useful to introduce a --left-right-count or such?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-02 8:19 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20090902080305.GA11549@neumann>
On Wed, Sep 02, 2009 at 10:03:05AM +0200, SZEDER Gábor wrote:
> As the subject says, 'git add -u' does not work from an untracked
> subdir, because it doesn't add modified files to the index. The
> following script reproduces the issue:
>
> mkdir repo
> cd repo
> git init
> echo 1 >foo
> git add foo
> git commit -m first
> echo 2 >foo
> mkdir untracked_subdir
> cd untracked_subdir
> git add -u
> git diff
>
> It worked in the initial 'git add -u' implementation (dfdac5d, git-add
> -u: match the index with working tree, 2007-04-20), but 2ed2c222
> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it
> later, and is broken ever since.
It is not just untracked subdirs. Try:
mkdir repo && cd repo && git init
echo 1 >foo
mkdir subdir
echo 1 >subdir/bar
git add . && git commit -m first
echo 2 >foo
echo 2 >subdir/bar
cd subdir
git add -u
git diff ;# still shows foo/1 in index
git diff --cached ;# shows subdir/bar was updated
While I have sometimes found the behavior a bit annoying[1], I always
assumed that was the intended behavior.
And indeed, in modern builtin-add.c, we find this:
if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
}
which seems pretty explicit.
-Peff
[1] I would prefer "git add -u ." to add only the current directory, and
"git add -u" to touch everything. But then, I am one of the people who
turn off status.relativepaths, so I think I may be in the minority in
always wanting to think of the project as a whole.
^ permalink raw reply
* [BUG] 'add -u' doesn't work from untracked subdir
From: SZEDER Gábor @ 2009-09-02 8:03 UTC (permalink / raw)
To: git
Hi,
As the subject says, 'git add -u' does not work from an untracked
subdir, because it doesn't add modified files to the index. The
following script reproduces the issue:
mkdir repo
cd repo
git init
echo 1 >foo
git add foo
git commit -m first
echo 2 >foo
mkdir untracked_subdir
cd untracked_subdir
git add -u
git diff
It worked in the initial 'git add -u' implementation (dfdac5d, git-add
-u: match the index with working tree, 2007-04-20), but 2ed2c222
(git-add -u paths... now works from subdirectory, 2007-08-16) broke it
later, and is broken ever since.
Regards,
Gábor
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Jeff King @ 2009-09-02 7:57 UTC (permalink / raw)
To: Tim Visher; +Cc: Git Mailing List
In-Reply-To: <c115fd3c0908311320q46d585d2v457ccd0f411a6404@mail.gmail.com>
On Mon, Aug 31, 2009 at 04:20:47PM -0400, Tim Visher wrote:
> I'm interested in being able to get a message such as 'dev and master
> have diverged, having 1 and 2 commits different respectively' or 'dev
> is behind master by 3 commits and can be fast-forwarded', etc. I'm
> sure this is simple, but I can't figure out how to do it in the docs.
> Sorry for the noobness of the question.
No, there isn't a simple command to say "show me this status text for
these two arbitrary branches".
However, the process is relatively simple to implement in a shell
script:
1. Pick your two branches. I'm not clear on whether you want to
compare two arbitrary branches, or what.
For the regular "status", one is the current branch, and the other
is the "upstream" branch (as configured by your
branch.$current.merge variables). Calculating "upstream" can
actually be a bit tricky because it involves looking at several
configuraiton variables. However, recent versions of git allow this
shell snippet (the 'upstream' formatter was added in v1.6.3):
current=`git symbolic-ref HEAD`
upstream=`git for-each-ref --format='%(upstream)' $current`
2. Count the commits on each side that are not in the other. The
simplest way to do this is:
in_a=`git rev-list $b..$a -- | wc -l`
in_b=`git rev-list $a..$b -- | wc -l`
but the internal code actually does both traversals simultaneously,
which is slightly more efficient. You can also do that by parsing
the output of:
git rev-list --left-right $a...$b --
which will mark commits in "a" with a '<' and commits in "b" with
a '>'. I don't know whether the extra complexity is worth the
efficiency gain (in the internal code it is easier, since we
aren't actually generating output and parsing it; we just keep a
count).
3. Compare the counts. If:
a=0, b=0: they are the same commit
a=0, b>0: a is behind b by $b commits, and can be fast-forwarded
a>0, b=0: a is ahead of b by $a commits (and can be pushed, or b
can be fast-forwarded to a)
a>0, b>0: branches have diverged and have $a and $b commits
respectively
So it's easy to script, but not exactly a one-liner. We might be able to
do better if you reduce the problem space. What exactly are you trying
to accomplish?
-Peff
^ permalink raw reply
* Re: [PATCH] clone: disconnect transport after fetching
From: Sverre Rabbelier @ 2009-09-02 7:37 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Daniel Barkalow, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <20090902072638.GC31528@coredump.intra.peff.net>
Heya,
On Wed, Sep 2, 2009 at 09:26, Jeff King<peff@peff.net> wrote:
> So think of it as you exposing a long-standing bug. ;)
Ah, well in that case, you're all welcome :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] clone: disconnect transport after fetching
From: Jeff King @ 2009-09-02 7:26 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, git, Daniel Barkalow, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <fabb9a1e0909020009r3ee28b1fo3cba095abafec9d4@mail.gmail.com>
On Wed, Sep 02, 2009 at 09:09:19AM +0200, Sverre Rabbelier wrote:
> On Wed, Sep 2, 2009 at 08:36, Jeff King<peff@peff.net> wrote:
> > As you can see from the commit message, I did a little extra hunting to
> > make sure we are not going to impact any other code paths, and I am
> > pretty sure we are fine.
>
> Thank you for fixing my mistake :).
You're welcome, though I am not sure it is your mistake. Arguably this
is something we should have been doing all along. The point of
abstracting transports was that we didn't need to know their details at
the outer layer, but in this case we were relying on the fact that no
transports (until empty-clone-over-git) needed an explicit
transport_disconnect to cleanly hang up on the other end.
So think of it as you exposing a long-standing bug. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] clone: disconnect transport after fetching
From: Sverre Rabbelier @ 2009-09-02 7:09 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Daniel Barkalow, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <20090902063647.GA29559@coredump.intra.peff.net>
Heya,
On Wed, Sep 2, 2009 at 08:36, Jeff King<peff@peff.net> wrote:
> As you can see from the commit message, I did a little extra hunting to
> make sure we are not going to impact any other code paths, and I am
> pretty sure we are fine.
Thank you for fixing my mistake :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: stash --dwim safety
From: Johannes Schindelin @ 2009-09-02 6:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <20090902045937.GA12046@coredump.intra.peff.net>
Hi,
On Wed, 2 Sep 2009, Jeff King wrote:
> [cc'ing Dscho, as he was the main opponent of similar proposals, and I
> suspect his silence here means he missed this discussion.
Your assumption is correct.
I am overloaded with work, and in such times it is highly unlikely that I
get back to a discussion that was less than fun.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] clone: disconnect transport after fetching
From: Jeff King @ 2009-09-02 6:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Daniel Barkalow, Sverre Rabbelier, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <alpine.LNX.2.00.0909020159080.28290@iabervon.org>
The current code just leaves the transport in whatever state
it was in after performing the fetch. For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.
But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.
This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.
Other transports are unaffected or slightly improved:
- for a non-empty repo over the git protocol, the second
disconnect is a no-op (since we are no longer connected)
- for "walker" transports (like HTTP or FTP), we actually
free some used memory (which previously just sat until
the clone process exits)
- for "rsync", disconnect is always a no-op anyway
Signed-off-by: Jeff King <peff@peff.net>
---
This was suggested by Daniel, so theoretically
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
:)
As you can see from the commit message, I did a little extra hunting to
make sure we are not going to impact any other code paths, and I am
pretty sure we are fine.
builtin-clone.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 991a7ae..0f231d8 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -580,8 +580,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_no_checkout = 1;
}
- if (transport)
+ if (transport) {
transport_unlock_pack(transport);
+ transport_disconnect(transport);
+ }
if (!option_no_checkout) {
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
--
1.6.4.2.401.ga275f.dirty
^ permalink raw reply related
* Re: stash --dwim safety
From: Matthieu Moy @ 2009-09-02 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy6oyj892.fsf@alter.siamese.dyndns.org>
Thanks for taking care of this,
Junio C Hamano <gitster@pobox.com> writes:
> 'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]
To be precise, you can change this to
> 'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [--] [<message>]]
(added [--])
--
Matthieu
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Daniel Barkalow @ 2009-09-02 6:02 UTC (permalink / raw)
To: Jeff King
Cc: Sverre Rabbelier, Björn Steinbrink, Matthieu Moy,
Sitaram Chamarty, git
In-Reply-To: <20090902051615.GC12046@coredump.intra.peff.net>
On Wed, 2 Sep 2009, Jeff King wrote:
> On Wed, Sep 02, 2009 at 12:33:52AM -0400, Daniel Barkalow wrote:
>
> > > The patch below seems to work for me, but I'm a little concerned how it
> > > might impact other transports.
> >
> > Does putting a "transport_disconnect(transport);" after the
> > "transport_unlock_pack(transport);" in builtin-clone.c also work for you?
> > I think that's a cleaner solution, and should future-proof it in case we
> > have a future transport that both doesn't disconnect itself after a fetch
> > and gives an error message if the connection is dropped suddenly.
> >
> > It's kind of just an accident that the only transport that cares about
> > disconnect very much doesn't care if you've fetched after getting the
> > refs.
>
> It does work, and I think that is a much saner solution for the reasons
> you mention. Thanks. Do you want to write it up and submit it, or should
> I?
You probably should; I'm not sure when I'd get to putting together a
patch, and you did the hard part (figuring out what was going on) anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git.el: Make it easy to add unmerged files
From: Martin Nordholts @ 2009-09-02 5:48 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Junio C Hamano
In-Reply-To: <87ws4l47k2.fsf@wine.dyndns.org>
On 08/30/2009 05:58 PM, Alexandre Julliard wrote:
> Martin Nordholts <martin@chromecode.com> writes:
>
>> (Resending as I managed to mangle the previous patch despite trying not to...)
>>
>> It is nice and easy to git-add ignored and unknown files in a
>> git-status buffer. Make it equally easy to add unmerged files which is
>> a common use case.
>
> That's not quite what adding a file means in git.el, unmerged files are
> considered added already, and marking them resolved is done through the
> git-resolve-file command. Of course that was implemented before git
> overloaded the meaning of git-add to mean git-update-index, so maybe we
> should follow the trend and use git-add-file for all index updates. In
> that case git-resolve-file should probably be removed.
Since git instructs the user to use git-add for marking unmerged files
as resolved ("After resolving the conflicts, mark the corrected paths
with 'git add <paths>' or 'git rm <paths>' and commit the result.") and
doesn't even mention git-update-index, I think we should change git.el
accordingly.
But why do we need to also remove and disable git-resolve-file from
git.el? It doesn't hurt to keep that function and the keybinding, does
it?
/ Martin
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Junio C Hamano @ 2009-09-02 5:32 UTC (permalink / raw)
To: Nick Edelen; +Cc: git
In-Reply-To: <c77435a80909011525m3a6e7917xe066d61f3863e615@mail.gmail.com>
Nick Edelen <sirnot@gmail.com> writes:
> I vaguely remember something concerning those tests when starting the
> project. I'm a bit disconnected from everything right now, but I'll
> try to get those fixed as soon as I can.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox