* Re: [PATCH] git-gui: Don't select the wrong file if the last listed file is staged.
From: Shawn O. Pearce @ 2008-06-25 20:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Abhijit Menon-Sen, git
In-Reply-To: <486222A6.70205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Abhijit Menon-Sen schrieb:
> > Johannes Sixt noticed that if the last file in the list was staged, my
> > earlier patch would display the diff for the penultimate file, but show
> > the file _before_ that as being selected.
> >
> > This was due to my misunderstanding the lno argument to show_diff.
> >
> > This patch fixes the problem: lno is not decremented in the special case
> > to handle the last item in the list (though we still need to use $lno-1
> > to find the right path for the next diff).
>
> Thanks. It works here, too:
Thanks, both. Its in my tree.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Avery Pennarun @ 2008-06-25 20:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <7vd4m5z1f8.fsf@gitster.siamese.dyndns.org>
On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
> >> * You say "git checkout -- file" when you want to "check out the file
> >> from the index";
> >
> > The real question here is the --. Is it strictly needed? It's
> > optional in things like git-diff, which just do their best to guess
> > what you mean if you don't use the --.
>
> No, I wrote -- only for clarity, because you can happen to have a branch
> whose name is the same as the file. Otherwise you can safely omit it,
> just like git-diff and any other commands that follow the -- convention.
Oops, I got mixed up. Only git-reset requires the --. Would it make
sense to bring git-reset into line with everything else, then?
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Theodore Tso @ 2008-06-25 21:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Avery Pennarun, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <7v8wwtz1c1.fsf@gitster.siamese.dyndns.org>
On Wed, Jun 25, 2008 at 01:50:06PM -0700, Junio C Hamano wrote:
> I just replied to Avery about that. -- is always the way to disambiguate
> between refs (that come before --) and paths (that come after --), not
> limited to "git checkout" but with other commands such as "git log", "git
> diff", etc.
Stupid quesiton --- where is this documented? I don't see this
documented either in the man page for git or git-checkout.
Regards,
- Ted
^ permalink raw reply
* Re* [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 21:24 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <32541b130806251358n3ab6cfc8y7a90d898b9308e12@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
>> "Avery Pennarun" <apenwarr@gmail.com> writes:
>> >> * You say "git checkout -- file" when you want to "check out the file
>> >> from the index";
>> >
>> > The real question here is the --. Is it strictly needed? It's
>> > optional in things like git-diff, which just do their best to guess
>> > what you mean if you don't use the --.
>>
>> No, I wrote -- only for clarity, because you can happen to have a branch
>> whose name is the same as the file. Otherwise you can safely omit it,
>> just like git-diff and any other commands that follow the -- convention.
>
> Oops, I got mixed up. Only git-reset requires the --. Would it make
> sense to bring git-reset into line with everything else, then?
Ah, interesting. It appears that the current "reset in C" inherited that
bug from the scripted version. It works most of the time without --
except for one place.
# prove that the work tree is clean...
$ git reset --hard
HEAD is now at 7b7f39e Fix use after free() in builtin-fetch
$ git diff
$ git diff --cached
# what's different since HEAD^?
$ git diff --name-only HEAD^
builtin-fetch.c
# reset the path
$ git reset HEAD^ builtin-fetch.c
builtin-fetch.c: needs update
# prove that HEAD did not move
$ git rev-parse HEAD
7b7f39eae6ab0bbcc68d3c42a5b23595880e528f
# prove that work tree did not change
$ git diff HEAD
# prove that index has old version
$ git diff --cached HEAD^
Reset is about resetting the index and --hard option tells it to propagate
the change down to the work tree as well.
There is no "reset to the index", so "reset -- path" would be a redundant
way to spell "reset HEAD path" or "reset HEAD -- path" which is even more
redundant.
As long as builti-fetch.c is not a valid ref, you should be able to get
out of the above mess by any one of:
$ git reset builtin-fetch.c
$ git reset -- builtin-fetch.c
$ git reset HEAD builtin-fetch.c
but the first one complains, saying builtin-fetch.c is not a valid ref.
This may help.
diff --git a/builtin-reset.c b/builtin-reset.c
index f34acb1..c7d60f5 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -194,9 +194,21 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
reflog_action = args_to_str(argv);
setenv("GIT_REFLOG_ACTION", reflog_action, 0);
- if (i < argc && strcmp(argv[i], "--"))
- rev = argv[i++];
-
+ /*
+ * Possible arguments are:
+ *
+ * git reset <rev> <paths>...
+ * git reset <rev> -- <paths>...
+ * git reset -- <paths>...
+ * git reset <paths>...
+ */
+ if (i < argc && strcmp(argv[i], "--")) {
+ /* could be "git reset <path>" */
+ if (get_sha1(argv[i+1], sha1))
+ ;
+ else
+ rev = argv[i++];
+ }
if (get_sha1(rev, sha1))
die("Failed to resolve '%s' as a valid ref.", rev);
^ permalink raw reply related
* Re: Re* [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 21:34 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <7vwskdxl6z.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
>
>> On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Avery Pennarun" <apenwarr@gmail.com> writes:
>>> >> * You say "git checkout -- file" when you want to "check out the file
>>> >> from the index";
>>> >
>>> > The real question here is the --. Is it strictly needed? It's
>>> > optional in things like git-diff, which just do their best to guess
>>> > what you mean if you don't use the --.
>>>
>>> No, I wrote -- only for clarity, because you can happen to have a branch
>>> whose name is the same as the file. Otherwise you can safely omit it,
>>> just like git-diff and any other commands that follow the -- convention.
>>
>> Oops, I got mixed up. Only git-reset requires the --. Would it make
>> sense to bring git-reset into line with everything else, then?
>
> Ah, interesting. It appears that the current "reset in C" inherited that
> bug from the scripted version. It works most of the time without --
> except for one place.
>
> # prove that the work tree is clean...
> $ git reset --hard
> HEAD is now at 7b7f39e Fix use after free() in builtin-fetch
> $ git diff
> $ git diff --cached
>
> # what's different since HEAD^?
> $ git diff --name-only HEAD^
> builtin-fetch.c
>
> # reset the path
> $ git reset HEAD^ builtin-fetch.c
> builtin-fetch.c: needs update
>
> # prove that HEAD did not move
> $ git rev-parse HEAD
> 7b7f39eae6ab0bbcc68d3c42a5b23595880e528f
> # prove that work tree did not change
> $ git diff HEAD
> # prove that index has old version
> $ git diff --cached HEAD^
>
> Reset is about resetting the index and --hard option tells it to propagate
> the change down to the work tree as well.
>
> There is no "reset to the index", so "reset -- path" would be a redundant
> way to spell "reset HEAD path" or "reset HEAD -- path" which is even more
> redundant.
>
> As long as builti-fetch.c is not a valid ref, you should be able to get
> out of the above mess by any one of:
>
> $ git reset builtin-fetch.c
> $ git reset -- builtin-fetch.c
> $ git reset HEAD builtin-fetch.c
>
> but the first one complains, saying builtin-fetch.c is not a valid ref.
>
> This may help.
>
> diff --git a/builtin-reset.c b/builtin-reset.c
> index f34acb1..c7d60f5 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -194,9 +194,21 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
> reflog_action = args_to_str(argv);
> setenv("GIT_REFLOG_ACTION", reflog_action, 0);
>
> - if (i < argc && strcmp(argv[i], "--"))
> - rev = argv[i++];
> -
> + /*
> + * Possible arguments are:
> + *
> + * git reset <rev> <paths>...
> + * git reset <rev> -- <paths>...
> + * git reset -- <paths>...
> + * git reset <paths>...
> + */
> + if (i < argc && strcmp(argv[i], "--")) {
> + /* could be "git reset <path>" */
> + if (get_sha1(argv[i+1], sha1))
typofix: s/i+1/i/;
> + ;
> + else
> + rev = argv[i++];
> + }
> if (get_sha1(rev, sha1))
> die("Failed to resolve '%s' as a valid ref.", rev);
>
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Jakub Narebski @ 2008-06-25 21:35 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <32541b130806251253t3dcada10nbf94fee9e4aed9ec@mail.gmail.com>
On Wed, 25 Jun 2008, Avery Pennarun wrote:
> On 6/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > Which git version do you use? Does it have the following configuration
> > variable (also available as command option):
> >
> > status.showUntrackedFiles::
> > [...]
>
> Thanks, I didn't know about that one. Using that definitely makes
> "git status" go much faster (pretty much instantaneous if I've also
> used --assume-unchanged on everything).
>
> Now the catch is, if I want to implement the daemon I was talking
> about earlier, I'd like to be able to notice untracked files (or
> directories with untracked files) individually. Ideally, I guess the
> best way would be to just keep a separate list of all existing files
> that aren't in the index, and have git status look at that rather than
> at the actual filesystem.
>
> Are there any suggestions for how best to do this?
You can try to take a look at how (third-party and Linux only) inotify
extension for Mercurial works. AFAIK IIRC it uses some kind of daemon
which watches for inotify notices and updates Mercorial's equivalent
of index.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 21:35 UTC (permalink / raw)
To: Theodore Tso
Cc: Avery Pennarun, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <20080625210535.GA8610@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Wed, Jun 25, 2008 at 01:50:06PM -0700, Junio C Hamano wrote:
>> I just replied to Avery about that. -- is always the way to disambiguate
>> between refs (that come before --) and paths (that come after --), not
>> limited to "git checkout" but with other commands such as "git log", "git
>> diff", etc.
>
> Stupid quesiton --- where is this documented? I don't see this
> documented either in the man page for git or git-checkout.
You are asking a wrong person. My git knowledge mostly comes from
yearlong reading of the mailing list articles, and doing a bit myself also
helps ;-).
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 21:34 UTC (permalink / raw)
To: David Jeske; +Cc: Theodore Tso, git
In-Reply-To: <willow-jeske-01l6XqjOFEDjC=91jv>
Some answers thanks to Jakub...
-- David Jeske wrote:
> : "ncvs up" ->
> :
> : git stash; git pull; git apply;
> : git diff --stat <baseof:current branch> - un-pushed filenames
> : git-show-branch <current branch> - un-pushed comments
>
> Question: when I say "baseof:current branch", I mean "the common-ancestor
> between my local-repo tracking branch and the remote-repo branch it's
> tracking". How do I find that out?
I'm told I need...
git diff --stat `git-merge-base HEAD ORIG_HEAD`
> : "ncvs commit" -> "git commit; git push <only this branch>;"
>
> Question: how do I only push the branch I'm on? "eg" says it does this, but
> from a quick look at the code, it wasn't obvious to me how.
and...
git push HEAD
which just leaves this one....
Question: How do I create a branch on a remote repo when I'm on
my local machine, without sshing to it?
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 21:34 UTC (permalink / raw)
To: David Jeske; +Cc: Theodore Tso, git
In-Reply-To: <willow-jeske-01l6XqjOFEDjC=91jv>
Some answers thanks to Jakub...
-- David Jeske wrote:
> : "ncvs up" ->
> :
> : git stash; git pull; git apply;
> : git diff --stat <baseof:current branch> - un-pushed filenames
> : git-show-branch <current branch> - un-pushed comments
>
> Question: when I say "baseof:current branch", I mean "the common-ancestor
> between my local-repo tracking branch and the remote-repo branch it's
> tracking". How do I find that out?
I'm told I need...
git diff --stat `git-merge-base HEAD ORIG_HEAD`
> : "ncvs commit" -> "git commit; git push <only this branch>;"
>
> Question: how do I only push the branch I'm on? "eg" says it does this, but
> from a quick look at the code, it wasn't obvious to me how.
and...
git push HEAD
which just leaves this one....
Question: How do I create a branch on a remote repo when I'm on
my local machine, without sshing to it?
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Jakub Narebski @ 2008-06-25 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <1784.50359167091$1214430241@news.gmane.org>
David Jeske wrote:
> Question: How do I create a branch on a remote repo when I'm on
> my local machine, without sshing to it?
Push into it.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Junio C Hamano @ 2008-06-25 22:13 UTC (permalink / raw)
To: David Jeske; +Cc: Theodore Tso, git
In-Reply-To: <1784.50359167091$1214430241@news.gmane.org>
"David Jeske" <jeske@willowmail.com> writes:
>> : "ncvs up" ->
>> :
>> : git stash; git pull; git apply;
First of all, if you are in CVS mindset, you may not want to necessarily
do "git pull", but "git fetch" followed by "git rebase".
I suspect the last one in the above sequence of yours is "git stash pop".
Definitely not "git apply" without any argument which is a no-op.
>> : git diff --stat <baseof:current branch> - un-pushed filenames
"git diff [--options] origin..." (three-dots) is often used. This is a
shorthand for:
git diff [--options] $(git merge-base origin HEAD) HEAD
that is, "show me what I did since I forked from origin".
>> : git-show-branch <current branch> - un-pushed comments
This would be useful if you are using "fetch + rebase", but in any case
git log --graph --pretty=oneline origin..
may be prettier these days. --graph is a recent invention that appeared
first in 1.5.6.
> Question: How do I create a branch on a remote repo when I'm on
> my local machine, without sshing to it?
I hope that the question is not "How do I do anything on a remote without
having any network connection to it" as its answer cannot be anything but
"telepathy".
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Petr Baudis @ 2008-06-25 22:44 UTC (permalink / raw)
To: Theodore Tso
Cc: Avery Pennarun, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <20080625203822.GA7827@mit.edu>
On Wed, Jun 25, 2008 at 04:38:22PM -0400, Theodore Tso wrote:
> On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:
> > How about making "git checkout" default to HEAD if no revision is
> > supplied? There's precedent for this in, say, git-diff (and I think a
> > few others).
> >
> > Incidentally, "checkout <filename>" was also the way to do a revert
> > operation in CVS. And the way to switch branches, too, iirc. So git
> > isn't being too unusual here. That said, the commands were
> > deliberately renamed in svn because CVS was considered largely insane.
>
> The one thing I would worry about is the potential ambiguity if you do
> something like "git checkout FOOBAR", and FOOBAR was both a branch
> name as well as a file name. How should it be interpreted? I'd argue
> the real problem was we conflated two distinct operations: "switching
> to a new branch", and "reverting a file" to the same name, checkout.
>
> Hence the suggestion to add a new command, "git revert-file", where
> there would be no ambiguity.
Just to chime in, this reminds me of Cogito - it had cg-switch for
switching branches (like git checkout) and cg-restore for restoring
files in working copy (like git checkout, too; but you would pass -f if
you wanted to overwrite existing copy).
(Though, Cogito didn't quite get it right either since it tried to
overload cg-switch with the git branch functionality of creating new
branches. I still didn't quite come in terms with any UI model of the
branches I know about.)
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* [PATCH] git-send-email: Accept fifos as well as files
From: Kevin Ballard @ 2008-06-25 22:44 UTC (permalink / raw)
To: git; +Cc: Kevin Ballard, Junio C Hamano
When a fifo is given, validation must be skipped because we can't
read the fifo twice. Ideally git-send-email would cache the read
data instead of attempting to read twice, but for now just skip
validation.
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
git-send-email.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0b04ba3..16d4375 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -393,7 +393,7 @@ for my $f (@ARGV) {
push @files, grep { -f $_ } map { +$f . "/" . $_ }
sort readdir(DH);
- } elsif (-f $f) {
+ } elsif (-f $f or -p $f) {
push @files, $f;
} else {
@@ -403,8 +403,10 @@ for my $f (@ARGV) {
if (!$no_validate) {
foreach my $f (@files) {
- my $error = validate_patch($f);
- $error and die "fatal: $f: $error\nwarning: no patches were sent\n";
+ unless (-p $f) {
+ my $error = validate_patch($f);
+ $error and die "fatal: $f: $error\nwarning: no patches were sent\n";
+ }
}
}
--
1.5.6.130.g7a997
^ permalink raw reply related
* [PATCH] daemon: accept "git program" as well
From: Junio C Hamano @ 2008-06-25 22:47 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625053848.GJ11793@spearce.org>
This is a step to futureproof git-daemon to accept clients that
ask for "git upload-pack" and friends, instead of using the more
traditional dash-form "git-upload-pack". By allowing both, it
makes the client side easier to handle, as it makes "git" the only
thing necessary to be on $PATH when invoking the remote command
directly via ssh.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Ok, let's map this out seriously.
>
> This plan makes a lot of sense to me. I'm behind it. For whatever
> that means. At least I'll shutup and stop making noise about this
> issue if you take this approach. :-)
>
>> * 1.6.0 will install the server-side programs in $(bindir) so that
>> people coming over ssh will find them on the $PATH
>>
>> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
>> "git-program" and "git program" forms. When the spaced form is used, it
>> will behave as if the dashed form is requested. This is a prerequisite
>> for client side change to start asking for "git program".
>>
>> * In the near future, there will no client-side change. "git-program"
>> will be asked for.
>>
>> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
>> be running that version or newer. Client side will start asking for
>> "git program" by default, but we can still override with --upload-pack
>> and friends.
>>
>> * 12 months after client side changes, everybody will be running that
>> version or newer. We stop installing the server side programs in
>> $(bindir) but people coming over ssh will be asking for "git program"
>> and "git" will be on the $PATH so there is no issue.
>>
>> The above 6 and 12 are yanked out of thin air and I am of course open to
>> tweaking them, but I think the above order of events would be workable.
>
> Yea, 6 and 12 seem like a good idea. Its a couple of releases and
> gives people time to migrate their server installations.
So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
and 1.6.0.
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index 63cd12c..621c567 100644
--- a/daemon.c
+++ b/daemon.c
@@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
struct daemon_service *s = &(daemon_service[i]);
int namelen = strlen(s->name);
- if (!prefixcmp(line, "git-") &&
+ if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
!strncmp(s->name, line + 4, namelen) &&
line[namelen + 4] == ' ') {
/*
^ permalink raw reply related
* [PATCH] Make clients ask for "git program" over ssh and local transport
From: Junio C Hamano @ 2008-06-25 22:55 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7v4p7hxhbd.fsf@gitster.siamese.dyndns.org>
This will allow server side programs such as upload-pack to be installed
outside $PATH. Connections to git-daemon still ask for "git-program" to
retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is essentially your patch. This can be in 1.6.0 clients and it
should also be in 1.5.6.1 as people might keep ancient clients to talk
to new servers that won't have anything but "git" on $PATH.
builtin-clone.c | 2 +-
builtin-fetch-pack.c | 2 +-
connect.c | 10 ++++++++--
git-parse-remote.sh | 4 ++--
transport.c | 4 ++--
5 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 7190952..2f3e9c9 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -36,7 +36,7 @@ static int option_quiet, option_no_checkout, option_bare;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
-static char *option_upload_pack = "git-upload-pack";
+static char *option_upload_pack = "git upload-pack";
static struct option builtin_clone_options[] = {
OPT__QUIET(&option_quiet),
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index de1e8d1..a5f21f9 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1;
static int fetch_unpack_limit = -1;
static int unpack_limit = 100;
static struct fetch_pack_args args = {
- /* .uploadpack = */ "git-upload-pack",
+ /* .uploadpack = */ "git upload-pack",
};
static const char fetch_pack_usage[] =
diff --git a/connect.c b/connect.c
index e92af29..4a32ba4 100644
--- a/connect.c
+++ b/connect.c
@@ -567,6 +567,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
* cannot connect.
*/
char *target_host = xstrdup(host);
+ const char *program_prefix = "";
+
if (git_use_proxy(host))
git_proxy_connect(fd, host);
else
@@ -575,9 +577,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
* Separate original protocol components prog and path
* from extended components with a NUL byte.
*/
+ if (!prefixcmp(prog, "git ")) {
+ program_prefix = "git-";
+ prog += 4;
+ }
packet_write(fd[1],
- "%s %s%chost=%s%c",
- prog, path, 0,
+ "%s%s %s%chost=%s%c",
+ program_prefix, prog, path, 0,
target_host, 0);
free(target_host);
free(url);
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..0f82a93 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -255,10 +255,10 @@ get_uploadpack () {
case "$data_source" in
config)
uplp=$(git config --get "remote.$1.uploadpack")
- echo ${uplp:-git-upload-pack}
+ echo ${uplp:-git upload-pack}
;;
*)
- echo "git-upload-pack"
+ echo "git upload-pack"
;;
esac
}
diff --git a/transport.c b/transport.c
index 3ff8519..351b7f5 100644
--- a/transport.c
+++ b/transport.c
@@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
data->thin = 1;
data->conn = NULL;
- data->uploadpack = "git-upload-pack";
+ data->uploadpack = "git upload-pack";
if (remote && remote->uploadpack)
data->uploadpack = remote->uploadpack;
- data->receivepack = "git-receive-pack";
+ data->receivepack = "git receive-pack";
if (remote && remote->receivepack)
data->receivepack = remote->receivepack;
}
--
1.5.6.86.ge2da6
^ permalink raw reply related
* [PATCH] Ask for "git program" even against git-daemon
From: Junio C Hamano @ 2008-06-25 22:58 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vvdzxw2eo.fsf_-_@gitster.siamese.dyndns.org>
This drops backward compatibility support to ask for "git-program"
form when talking to git-daemon. Now all git native requests use
"git program" form over ssh, local and git transports.
This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
1.6.0 or newer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* According to the roadmap we exchanged earlier, this should happen in a
major release (that increments the second dewey-decimal digit from the
left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
have the "git daemon preparation" patch included) are released.
connect.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/connect.c b/connect.c
index 4a32ba4..f2e72c2 100644
--- a/connect.c
+++ b/connect.c
@@ -567,7 +567,6 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
* cannot connect.
*/
char *target_host = xstrdup(host);
- const char *program_prefix = "";
if (git_use_proxy(host))
git_proxy_connect(fd, host);
@@ -577,13 +576,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
* Separate original protocol components prog and path
* from extended components with a NUL byte.
*/
- if (!prefixcmp(prog, "git ")) {
- program_prefix = "git-";
- prog += 4;
- }
packet_write(fd[1],
- "%s%s %s%chost=%s%c",
- program_prefix, prog, path, 0,
+ "%s %s%chost=%s%c",
+ prog, path, 0,
target_host, 0);
free(target_host);
free(url);
--
1.5.6.86.ge2da6
^ permalink raw reply related
* Re: [PATCH] daemon: accept "git program" as well
From: Shawn O. Pearce @ 2008-06-25 23:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7v4p7hxhbd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This is a step to futureproof git-daemon to accept clients that
> ask for "git upload-pack" and friends, instead of using the more
> traditional dash-form "git-upload-pack". By allowing both, it
> makes the client side easier to handle, as it makes "git" the only
> thing necessary to be on $PATH when invoking the remote command
> directly via ssh.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Obviously correct. Ack. Thanks Junio.
> So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
> and 1.6.0.
>
> daemon.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/daemon.c b/daemon.c
> index 63cd12c..621c567 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
> for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
> struct daemon_service *s = &(daemon_service[i]);
> int namelen = strlen(s->name);
> - if (!prefixcmp(line, "git-") &&
> + if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
> !strncmp(s->name, line + 4, namelen) &&
> line[namelen + 4] == ' ') {
> /*
--
Shawn.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <7viqvxxix0.fsf@gitster.siamese.dyndns.org>
-- Junio C Hamano wrote:
> >> : "ncvs up" ->
> >> :
> >> : git stash; git pull; git apply;
>
> First of all, if you are in CVS mindset, you may not want to necessarily
> do "git pull", but "git fetch" followed by "git rebase".
I don't want to replicate CVS behavior, just the workflow. I've considered
rebase, but the diagrams on the documentation page look scarry. I want to keep
the dag-nodes made by their local git commit;. At those commits the code worked
and tested in their tree. rebase looks like it tosses those dag-nodes when it
rewrites the diffs -- who knows if the tests actually pass for every point
along that new rebase. That's no good.
I can see the use of rebase when your job is to "author an understandable
public source tree", but I'm working on SCM, where the goal is to be able to
reproduce the state of past successes reliably.
I want someone to be able to checkout what was actually in the user's local
client as they were working. Which means I think I want "fetch and merge" which
is pull. Did I get that wrong?
> I suspect the last one in the above sequence of yours is "git stash pop".
> Definitely not "git apply" without any argument which is a no-op.
I meant to type "git stash apply", but I think you're right, pop is what I
wanted.
> >> : git diff --stat <baseof:current branch> - un-pushed filenames
>
> "git diff [--options] origin..." (three-dots) is often used. This is a
> shorthand for:
>
> git diff [--options] $(git merge-base origin HEAD) HEAD
>
> that is, "show me what I did since I forked from origin".
I'm still a little foggy on the remote referenecs, but remember I have two
remotes (shared) and (personal). Something in the docs led me to believe
'origin' was repository wide, not private to each branch. Is "origin" a magic
name for the current branch's target?
> >> : git-show-branch <current branch> - un-pushed comments
>
> This would be useful if you are using "fetch + rebase", but in any case
>
> git log --graph --pretty=oneline origin..
Ahh, yes, Thanks!. How does this interact with the "pull" I just did?
What I want is "show me the commit messages (and sha1 keys) for changes in my
local branch that are not yet submitted to it's remote tracking location"
Will that command above include the commit lines that came down in my pull
(fetch/merge)? If so, how do I not include them?
> > Question: How do I create a branch on a remote repo when I'm on
> > my local machine, without sshing to it?
>
> I hope that the question is not "How do I do anything on a remote without
> having any network connection to it" as its answer cannot be anything but
> "telepathy".
Funny. I'm asking how I can run a command locally, that during the next "git
push HEAD" will cause a branch to be created on a remote repository, without
assuming that is the same repository that my current branch is pointing to.
Will this do the trick?
git branch --track mynewbranch git://myserver/path/foo.git
# hack hack
git commit
git push HEAD
- David
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <7viqvxxix0.fsf@gitster.siamese.dyndns.org>
-- Junio C Hamano wrote:
> >> : "ncvs up" ->
> >> :
> >> : git stash; git pull; git apply;
>
> First of all, if you are in CVS mindset, you may not want to necessarily
> do "git pull", but "git fetch" followed by "git rebase".
I don't want to replicate CVS behavior, just the workflow. I've considered
rebase, but the diagrams on the documentation page look scarry. I want to keep
the dag-nodes made by their local git commit;. At those commits the code worked
and tested in their tree. rebase looks like it tosses those dag-nodes when it
rewrites the diffs -- who knows if the tests actually pass for every point
along that new rebase. That's no good.
I can see the use of rebase when your job is to "author an understandable
public source tree", but I'm working on SCM, where the goal is to be able to
reproduce the state of past successes reliably.
I want someone to be able to checkout what was actually in the user's local
client as they were working. Which means I think I want "fetch and merge" which
is pull. Did I get that wrong?
> I suspect the last one in the above sequence of yours is "git stash pop".
> Definitely not "git apply" without any argument which is a no-op.
I meant to type "git stash apply", but I think you're right, pop is what I
wanted.
> >> : git diff --stat <baseof:current branch> - un-pushed filenames
>
> "git diff [--options] origin..." (three-dots) is often used. This is a
> shorthand for:
>
> git diff [--options] $(git merge-base origin HEAD) HEAD
>
> that is, "show me what I did since I forked from origin".
I'm still a little foggy on the remote referenecs, but remember I have two
remotes (shared) and (personal). Something in the docs led me to believe
'origin' was repository wide, not private to each branch. Is "origin" a magic
name for the current branch's target?
> >> : git-show-branch <current branch> - un-pushed comments
>
> This would be useful if you are using "fetch + rebase", but in any case
>
> git log --graph --pretty=oneline origin..
Ahh, yes, Thanks!. How does this interact with the "pull" I just did?
What I want is "show me the commit messages (and sha1 keys) for changes in my
local branch that are not yet submitted to it's remote tracking location"
Will that command above include the commit lines that came down in my pull
(fetch/merge)? If so, how do I not include them?
> > Question: How do I create a branch on a remote repo when I'm on
> > my local machine, without sshing to it?
>
> I hope that the question is not "How do I do anything on a remote without
> having any network connection to it" as its answer cannot be anything but
> "telepathy".
Funny. I'm asking how I can run a command locally, that during the next "git
push HEAD" will cause a branch to be created on a remote repository, without
assuming that is the same repository that my current branch is pointing to.
Will this do the trick?
git branch --track mynewbranch git://myserver/path/foo.git
# hack hack
git commit
git push HEAD
- David
^ permalink raw reply
* Searching all git objects
From: Sam G. @ 2008-06-25 23:06 UTC (permalink / raw)
To: git
Hi all,
We recently had a developer make a large commit (mostly centered
around one file) which she believed she properly pushed to a remote
repository last week, but looking at both her repository and the
remote repository, that commit is now nowhere to be found. If somehow
the master branch she was working on in her repository has lost the
reference to the commit through perhaps some errant rebasing, then
perhaps an object containing the commit (or an object containing the
file in that commit) still exists somewhere inside her .git/objects
directory? We haven't done any git-gc recently. If so, how can I
search through every single git object in her objects directory,
searching for perhaps a specific part of the commit string, a line in
the code or the filename of the file which was changed? Any help with
this would be greatly appreciated. Thanks!
-Sam
^ permalink raw reply
* Re: [PATCH] Make clients ask for "git program" over ssh and local transport
From: Shawn O. Pearce @ 2008-06-25 23:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vvdzxw2eo.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This will allow server side programs such as upload-pack to be installed
> outside $PATH. Connections to git-daemon still ask for "git-program" to
> retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * This is essentially your patch. This can be in 1.6.0 clients and it
> should also be in 1.5.6.1 as people might keep ancient clients to talk
> to new servers that won't have anything but "git" on $PATH.
Ack. Thanks for cleaning up the code in connect.c to not segfault
or send garbage.
I think you want to squash this in as well:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d76260c..f693a6d 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -12,7 +12,7 @@ static const char send_pack_usage[] =
" --all and explicit <ref> specification are mutually exclusive.";
static struct send_pack_args args = {
- /* .receivepack = */ "git-receive-pack",
+ /* .receivepack = */ "git receive-pack",
};
/*
--
Shawn.
^ permalink raw reply related
* [PATCH v2] update-hook-example: optionally allow non-fast-forward
From: Dmitry Potapov @ 2008-06-25 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzfhz3fb.fsf@gitster.siamese.dyndns.org>
Sometimes it is desirable to have non-fast-forward branches in a
shared repository. A typical example of that is the 'pu' branch.
This patch extends the format of allowed-users and allow-groups
files by using the '+' sign at the beginning as the mark that
non-fast-forward pushes are permitted to the branch.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
On Wed, Jun 25, 2008 at 01:04:56PM -0700, Junio C Hamano wrote:
>
> I'd probably write this part like so:
<snip>
Thank you for advice. I have corrected the patch.
Documentation/howto/update-hook-example.txt | 75 ++++++++++++++++-----------
1 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index a8d3bae..7f430a0 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -65,7 +65,7 @@ function info {
# Implement generic branch and tag policies.
# - Tags should not be updated once created.
-# - Branches should only be fast-forwarded.
+# - Branches should only be fast-forwarded unless their pattern starts with '+'
case "$1" in
refs/tags/*)
git rev-parse --verify -q "$1" &&
@@ -80,7 +80,7 @@ case "$1" in
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
- *) deny >/dev/null "This is not a fast-forward update." ;;
+ *) noff=y; info "This is not a fast-forward update.";;
esac
fi
;;
@@ -97,19 +97,25 @@ info "The user is: '$username'"
if [ -f "$allowed_users_file" ]; then
rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
- while read head_pattern user_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
- info "Found matching head pattern: '$head_pattern'"
- for user_pattern in $user_patterns; do
- info "Checking user: '$username' against pattern: '$user_pattern'"
- matchlen=$(expr "$username" : "$user_pattern")
- if [ "$matchlen" == "${#username}" ]; then
- grant "Allowing user: '$username' with pattern: '$user_pattern'"
- fi
- done
- deny "The user is not in the access list for this branch"
- fi
+ while read heads user_patterns; do
+ # does this rule apply to us?
+ head_pattern=${heads#+}
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ test "$matchlen" = ${#1} || continue
+
+ # if non-ff, $heads must be with the '+' prefix
+ test -n "$noff" &&
+ test "$head_pattern" = "$heads" && continue
+
+ info "Found matching head pattern: '$head_pattern'"
+ for user_pattern in $user_patterns; do
+ info "Checking user: '$username' against pattern: '$user_pattern'"
+ matchlen=$(expr "$username" : "$user_pattern")
+ if [ "$matchlen" == "${#username}" ]; then
+ grant "Allowing user: '$username' with pattern: '$user_pattern'"
+ fi
+ done
+ deny "The user is not in the access list for this branch"
done
)
case "$rc" in
@@ -127,20 +133,27 @@ info "'$groups'"
if [ -f "$allowed_groups_file" ]; then
rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
while read head_pattern group_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
- info "Found matching head pattern: '$head_pattern'"
- for group_pattern in $group_patterns; do
- for groupname in $groups; do
- info "Checking group: '$groupname' against pattern: '$group_pattern'"
- matchlen=$(expr "$groupname" : "$group_pattern")
- if [ "$matchlen" == "${#groupname}" ]; then
- grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
- fi
- done
+
+ # does this rule apply to us?
+ head_pattern=${heads#+}
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ test "$matchlen" = ${#1} || continue
+
+ # if non-ff, $heads must be with the '+' prefix
+ test -n "$noff" &&
+ test "$head_pattern" = "$heads" && continue
+
+ info "Found matching head pattern: '$head_pattern'"
+ for group_pattern in $group_patterns; do
+ for groupname in $groups; do
+ info "Checking group: '$groupname' against pattern: '$group_pattern'"
+ matchlen=$(expr "$groupname" : "$group_pattern")
+ if [ "$matchlen" == "${#groupname}" ]; then
+ grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
+ fi
done
- deny "None of the user's groups are in the access list for this branch"
- fi
+ done
+ deny "None of the user's groups are in the access list for this branch"
done
)
case "$rc" in
@@ -159,6 +172,7 @@ allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
refs/heads/master junio
+ +refs/heads/pu junio
refs/heads/cogito$ pasky
refs/heads/bw/.* linus
refs/heads/tmp/.* .*
@@ -166,7 +180,8 @@ whom. The format of each file would look like this:
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
-do master branch and make versioned tags. And anybody can do
-tmp/blah branches.
+do master and pu branches and make versioned tags. And anybody
+can do tmp/blah branches. The '+' sign at the pu record means
+that JC can make non-fast-forward pushes on it.
------------
--
1.5.6
^ permalink raw reply related
* Re: Searching all git objects
From: Shawn O. Pearce @ 2008-06-25 23:17 UTC (permalink / raw)
To: Sam G.; +Cc: git
In-Reply-To: <E99352BE-5C43-437E-A5E6-622BEEA03DFA@comcast.net>
"Sam G." <ceptorial@comcast.net> wrote:
> We recently had a developer make a large commit (mostly centered
> around one file) which she believed she properly pushed to a remote
> repository last week, but looking at both her repository and the
> remote repository, that commit is now nowhere to be found. If somehow
> the master branch she was working on in her repository has lost the
> reference to the commit through perhaps some errant rebasing, then
> perhaps an object containing the commit (or an object containing the
> file in that commit) still exists somewhere inside her .git/objects
> directory? We haven't done any git-gc recently. If so, how can I
> search through every single git object in her objects directory,
> searching for perhaps a specific part of the commit string, a line in
> the code or the filename of the file which was changed? Any help with
> this would be greatly appreciated. Thanks!
Odds are it is in her HEAD reflog. You can look for it with
`git log -g`. If you know some part of the commit message you
may be able to filter it down with `git log -g --grep=X` or part
of the change with `git log -g -SX`.
A coworker just did something like that today and lost his change;
looking in the HEAD reflog and cherry-picking the commit recovered
it quite easily.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] daemon: accept "git program" as well
From: Junio C Hamano @ 2008-06-25 23:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: tv, しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625230228.GR11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> This is a step to futureproof git-daemon to accept clients that
>> ask for "git upload-pack" and friends, instead of using the more
>> traditional dash-form "git-upload-pack". By allowing both, it
>> makes the client side easier to handle, as it makes "git" the only
>> thing necessary to be on $PATH when invoking the remote command
>> directly via ssh.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Obviously correct. Ack. Thanks Junio.
By the way I looked at gitosis (Tommi CC'ed).
http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4
In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
compared with user commands after doing:
verb, args = command.split(None, 1)
(and "verb" is looked up in the set of valid commands). It should not be
too involved to notice verb is 'git' and then re-split the args part to
see if they are upload-pack/receive-pack, which would be the equivalent
change to this patch. It needs to be done before the clients are
updated.
^ permalink raw reply
* Re: [PATCH] Ask for "git program" even against git-daemon
From: Shawn O. Pearce @ 2008-06-25 23:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vr6alw28s.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This drops backward compatibility support to ask for "git-program"
> form when talking to git-daemon. Now all git native requests use
> "git program" form over ssh, local and git transports.
>
> This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
> 1.6.0 or newer.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * According to the roadmap we exchanged earlier, this should happen in a
> major release (that increments the second dewey-decimal digit from the
> left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
> have the "git daemon preparation" patch included) are released.
Agreed about holding back.
But I wonder if this patch is even worth it at some later point
in time. Are we also going to change git-daemon to stop accepting
"git-" form? Is it a worthwhile change?
--
Shawn.
^ 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