Git development
 help / color / mirror / Atom feed
* [PATCH 3/7] Add notify and warn to util.py
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---

	These turned out to be quite useful for my git-remote-hg, if
	desired this patch can move to later in the series, but I
	figured that it might be useful to someone else already.

 git_remote_helpers/util.py |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/git_remote_helpers/util.py b/git_remote_helpers/util.py
index 7d6adb4..d3ca487 100644
--- a/git_remote_helpers/util.py
+++ b/git_remote_helpers/util.py
@@ -15,6 +15,10 @@ import subprocess
 # Whether or not to show debug messages
 DEBUG = False
 
+def notify(msg, *args):
+	"""Print a message to stderr."""
+	print >> sys.stderr, msg % args
+
 def debug (msg, *args):
     """Print a debug message to stderr when DEBUG is enabled."""
     if DEBUG:
@@ -24,6 +28,10 @@ def error (msg, *args):
     """Print an error message to stderr."""
     print >> sys.stderr, "ERROR:", msg % args
 
+def warn(msg, *args):
+	"""Print a warning message to stderr."""
+	print >> sys.stderr, "warning:", msg % args
+
 def die (msg, *args):
     """Print as error message to stderr and exit the program."""
     error(msg, *args)
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* [PATCH 0/7] Prepare git-remote-helpers series for hg support
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland

This series does not add hg support, but it does do all the
refactoring that is needed to make it possible. With this series
applied actually adding full-fledged hg support is a matter of adding
the git-remote-hg file.
The reason the git-remote-hg file is not included in this series is
that while I have finished support for 'git clone hg::/path/to/hg' as
well as 'git fetch hg::/path/to/hg' and 'git fetch hgremote',
currently it does a full export on each run (that is, incremental
fetch is not supported).
Nevertheless, I think it is vital that this is included in the series
before we do anything serious with it. I hope to have the
git-remote-hg bit done tomorrow before I get on my airplane, but no
promises there.

Junio, I can try to re-roll the entire series after I finish
git-remote-hg, or I can just send it in on top of this series.

Based on abdcdc5c [More fixes to the git-remote-cvs...].

Johannes Schindelin (1):
      Finally make remote helper support useful

Sverre Rabbelier (5):
      .gitignore: add git-remote-cvs
      Add notify and warn to util.py
      Allow both url and foreign vcs in remote config
      When updating refs after a fetch, resolve the symref if set
      Factor ref updating out of fetch_with_import

 .gitignore                 |    1 +
 builtin-clone.c            |    7 +++++++
 builtin-fetch.c            |    4 ++++
 git_remote_helpers/util.py |    8 ++++++++
 remote.c                   |    2 +-
 transport-helper.c         |   22 +++++++++++++++-------
 transport.c                |   10 ++++++++++
 transport.h                |    7 +++++--
 8 files changed, 51 insertions(+), 10 deletions(-)

^ permalink raw reply
* [PATCH 4/7] Allow both url and foreign vcs in remote config
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

The current logic prevents both 'remote.url' and 'remote.vcs' from
being set, while that might be useful.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---

	This way I can do:

	remote.hgremote.url = /path/to/hg/repo
	remote.hgremote.vcs = hg

	As well as:

	remote.hgremote.url = hg::/path/to/hg/repo

 remote.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/remote.c b/remote.c
index f0441c4..29365de 100644
--- a/remote.c
+++ b/remote.c
@@ -50,7 +50,7 @@ static char buffer[BUF_SIZE];
 
 static int valid_remote(const struct remote *remote)
 {
-	return !remote->url != !remote->foreign_vcs;
+	return (!!remote->url) || (!!remote->foreign_vcs);
 }
 
 static const char *alias_url(const char *url)
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* [PATCH 6/7] When updating refs after a fetch, resolve the symref if set
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

This makes it possible to return in response to 'list':
	@refs/hg/origin/tip refs/heads/tip
And have HEAD resolve properly after the import completes.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---

	Without this it is very hard to support 'git clone' on a
	non-git repository, which I think is a very important thing
	to have.

 transport-helper.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/transport-helper.c b/transport-helper.c
index 639f08c..a361366 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -159,7 +159,7 @@ static int fetch_with_import(struct transport *transport,
 		posn = to_fetch[i];
 		if (posn->status & REF_STATUS_UPTODATE)
 			continue;
-		read_ref(posn->name, posn->old_sha1);
+		read_ref(posn->symref ? posn->symref : posn->name, posn->old_sha1);
 	}
 	return 0;
 }
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* Insertions/Deletions summary for a contributor
From: Laszlo Papp @ 2009-10-29  6:44 UTC (permalink / raw)
  To: git

Hello,

It would be nice to see summary for a contributor in insertions/deletions
lines, changed files regard, in the life of the whole project.

So the output would be the summary of the following output lines:
git log --author="Laszlo Papp" --pretty=tformat: --numstat

Can I deal with it, does it make sense, what do you think about it ?

Best Regards,
Laszlo Papp

^ permalink raw reply
* [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

Also allow the new update_refs to actually update the refs set, this
way the remote helper can set the value of previously unknown refs.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---

	This is the most important patch of the series, without it it
	is truly impossible to 'git clone hg::/path/to/hg/repo' since
	when we try to guess remote_head, we use
	find_ref_by_name(refs, "HEAD"), which will not find anything
	unless we set refs to the updated refs _after_ doing the
	import. This is a result of the fact that we do not know the
	value of the remote HEAD until after the import is complete.

 builtin-clone.c    |    7 +++++++
 builtin-fetch.c    |    4 ++++
 transport-helper.c |   22 +++++++++++++++-------
 transport.h        |    7 +++++--
 4 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index f281756..768668d 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -512,6 +512,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		if (refs) {
 			struct ref *ref_cpy = copy_ref_list(refs);
 			transport_fetch_refs(transport, ref_cpy);
+			if (transport->update_refs)
+			{
+				ref_cpy = copy_ref_list(refs);
+				transport->update_refs(transport, ref_cpy);
+				refs = ref_cpy;
+				mapped_refs = wanted_peer_refs(refs, refspec);
+			}
 		}
 	}
 
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 63a4ff0..3aaac47 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -479,7 +479,11 @@ static int fetch_refs(struct transport *transport, struct ref *ref_map)
 {
 	int ret = quickfetch(ref_map);
 	if (ret)
+	{
 		ret = transport_fetch_refs(transport, ref_map);
+		if (transport->update_refs)
+			transport->update_refs(transport, ref_map);
+	}
 	if (!ret)
 		ret |= store_updated_refs(transport->url,
 				transport->remote->name,
diff --git a/transport-helper.c b/transport-helper.c
index a361366..9a98fae 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -154,13 +154,6 @@ static int fetch_with_import(struct transport *transport,
 	finish_command(&fastimport);
 	free((char *) fastimport.argv[2]);
 	free((char *) fastimport.argv[3]);
-
-	for (i = 0; i < nr_heads; i++) {
-		posn = to_fetch[i];
-		if (posn->status & REF_STATUS_UPTODATE)
-			continue;
-		read_ref(posn->symref ? posn->symref : posn->name, posn->old_sha1);
-	}
 	return 0;
 }
 
@@ -255,6 +248,20 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
 	return ret;
 }
 
+static int update_refs(struct transport *transport, struct ref *refs)
+{
+	struct ref *ref = refs;
+
+	while (ref) {
+		if (ref->status & REF_STATUS_UPTODATE)
+			continue;
+		read_ref(ref->symref ? ref->symref : ref->name, ref->old_sha1);
+		ref = ref->next;
+	}
+
+	return 0;
+}
+
 int transport_helper_init(struct transport *transport, const char *name)
 {
 	struct helper_data *data = xcalloc(sizeof(*data), 1);
@@ -264,5 +271,6 @@ int transport_helper_init(struct transport *transport, const char *name)
 	transport->get_refs_list = get_refs_list;
 	transport->fetch = fetch;
 	transport->disconnect = release_helper;
+	transport->update_refs = update_refs;
 	return 0;
 }
diff --git a/transport.h b/transport.h
index 40dfe64..6d31df3 100644
--- a/transport.h
+++ b/transport.h
@@ -32,12 +32,15 @@ struct transport {
 	/**
 	 * Fetch the objects for the given refs. Note that this gets
 	 * an array, and should ignore the list structure.
-	 *
+	 **/
+	int (*fetch)(struct transport *transport, int refs_nr, struct ref **refs);
+
+	/**
 	 * If the transport did not get hashes for refs in
 	 * get_refs_list(), it should set the old_sha1 fields in the
 	 * provided refs now.
 	 **/
-	int (*fetch)(struct transport *transport, int refs_nr, struct ref **refs);
+	int (*update_refs)(struct transport *transport, struct ref *refs);
 
 	/**
 	 * Push the objects and refs. Send the necessary objects, and
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* [PATCH 5/7] Finally make remote helper support useful
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Johannes Schindelin, Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The common case for remote helpers will be to import some repository which
can be specified by a single URL.  Rather than supporting those who say
that Git is really complicated, let's be nice to users so that they will
be able to say:

	git clone hg::https://soc.googlecode.com/hg/ soc

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
--

	Dscho wrote this a while back and it really does make the
	series so much more useful.

 transport.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/transport.c b/transport.c
index ef33404..a682c75 100644
--- a/transport.c
+++ b/transport.c
@@ -813,6 +813,16 @@ struct transport *transport_get(struct remote *remote, const char *url)
 		url = remote->url[0];
 	ret->url = url;
 
+	/* maybe it is a foreign URL? */
+	if (url) {
+		const char *p = url;
+
+		while (isalnum(*p))
+			p++;
+		if (!prefixcmp(p, "::"))
+			remote->foreign_vcs = xstrndup(url, p - url);
+	}
+
 	if (remote && remote->foreign_vcs) {
 		transport_helper_init(ret, remote->foreign_vcs);
 		return ret;
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* [PATCH 2/7] .gitignore: add git-remote-cvs
From: Sverre Rabbelier @ 2009-10-29  6:40 UTC (permalink / raw)
  To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
  Cc: Sverre Rabbelier
In-Reply-To: <1256798426-21816-1-git-send-email-srabbelier@gmail.com>

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 46c26cd..b8afdf4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,7 @@ git-reflog
 git-relink
 git-remote
 git-remote-curl
+git-remote-cvs
 git-repack
 git-repo-config
 git-request-pull
-- 
1.6.5.2.291.gf76a3

^ permalink raw reply related
* Re: [PATCH] git-rebase -i: improve usage message
From: Junio C Hamano @ 2009-10-29  6:24 UTC (permalink / raw)
  To: Brian Ewins; +Cc: git, kusmabite
In-Reply-To: <1256774549-8191-1-git-send-email-brian.ewins@gmail.com>

Brian Ewins <brian.ewins@gmail.com> writes:

> The usage message was confusing as it implied that interactive
> mode was optional but the default. Change the message to more
> appropriately report usage when the -i flag is supplied.
> In addition, use the same division into 3 command formats as
> the man page.

I agree; if "git rebase--interactive -h" were asked, "-i is always used"
might be a correct thing to say, but nobody will get the message that way.
Instead, "git rebase --nonsense -i" and "git rebase -i --nonsense" will be
the most common way for users to see the message (also "git rebase -i -h").

The OPTIONS_SPEC in rebase--interactive is for the interactive mode and
for nothing else, so it may be a good idea to clearly say so at the
beginning.  The user experience perhaps should look like:

    $ git rebase -i -h
    Note: this help is only about the interactive mode;
    see 'git rebase -h' for help on non-interactive mode.

    usage: git rebase -i [<options>] [--] <upstream> [<branch>]
       or: git rebase -i (--continue|--abort|--skip)

    Available options are
    -v,--verbose          verbose output
    --onto <commit>       rebase onto given commit instead of <upstream>
    -p,--preserve-merges  try to recreate merges
    -i,--interactive      (always in effect in interactive mode)
    -m,--merge            (always in effect in interactive mode)

    Actions:
        --continue        continue the interrupted rebase session
        ...

By the way, I think the main "git rebase" help should be improved first
for this improvement to make sense.

 * Its first line "usage" is too long;

 * It only mentions [-i] in the first line but does not hint that the
   detailed help on interactive mode is available with "rebase -i -h".

The user experience perhaps should look like this:

    $ git rebase -h
    usage: git rebase [<options>] (<upstream>|--root) [<branch>]

    -i,--interactive  go interactive (see 'git rebase -i -h')
    -v,--verbose      verbose output
    ...

Also see

  http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646

I agree with Peff that the first-line usage should just say <options> in general
and have a table of options and their descriptions.

^ permalink raw reply
* Re: [PATCH] Teach 'git merge' and 'git pull' the option --ff-only
From: Björn Gustavsson @ 2009-10-29  6:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4yfi1dd.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Björn Gustavsson <bgustavsson@gmail.com> writes:
>>  
>> +--ff-only::
>> +	Refuse to merge unless the merge can be resolved as a
>> +	fast-forward.
> 
> Do you or do you not allow "already up to date"?  I think it makes sense
> to allow it, but it is unclear from these two lines.

I do allow it. I will change the description to the following in the
re-roll:

--ff-only::
	Refuse to merge and exit with a non-zero status unless the
	current `HEAD` is already up-to-date or the merge can be
	resolved as a fast-forward.


> 
>> @@ -874,6 +877,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>>  		option_commit = 0;
>>  	}
>>  
>> +	if (!allow_fast_forward && fast_forward_only)
>> +		die("You cannot combine --no-ff with --ff-only.");
> 
> Are these the only nonsensical combinations?  How should this interact
> with other options, e.g. --squash or --message?

They are the only options I can think of that flatly contradict each other.

Combining --squash and --ff-only will succeed if the current HEAD can be
fast-forwarded and will abort otherwise. I don't know how useful that
would be in practice, but I see no strong reason to forbid it.

The -m option will always be ignored, of course, and there will be
the usual warning if fast-forward is possible:

   Fast forward (no commit created; -m option ignored)

I don't think there is any need to explicitly forbid the combination
of -m and --ff-only.

I should probably update the commit message in the re-roll to include
the information in the previous paragraphs.

>> @@ -969,8 +975,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>>  	}
>>  
>>  	for (i = 0; i < use_strategies_nr; i++) {
>> -		if (use_strategies[i]->attr & NO_FAST_FORWARD)
>> +		if (use_strategies[i]->attr & NO_FAST_FORWARD) {
>>  			allow_fast_forward = 0;
>> +			if (fast_forward_only)
>> +				die("You cannot combine --ff-only with the merge strategy '%s'.", use_strategies[i]->name);
>> +		}
> 
> I am not convinced this tests the right condition nor it is placed at the
> right place in the codepath---even if a specified strategy happens to
> allow fast-forward, wouldn't it be nonsense to say
> 
>     $ git merge --ff-only -s resolve that-one
> 
> in the first place?  Note that I am not saying "I am convinced this is
> wrong."

Re-thinking it, I think that the test should be removed. It seemed like
a good idea at the time to point out which strategy that prevented the 
fast-forward, but if there is a list of merge strategies, the test will prevent
--ff-only to succeed if *any* of merge strategies cannot fast-forward.
(Also, but I am not sure about this, a merge strategy that does not allow
fast-forward might allow up-to-date.)

Therefore, I will remove the test in the re-roll.


Thanks for the comments!

/Björn

^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool  option
From: Jay Soffian @ 2009-10-29  6:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Scott Chacon, git list, Charles Bailey, David Aguilar
In-Reply-To: <7v1vkngkdm.fsf@alter.siamese.dyndns.org>

On Wed, Oct 28, 2009 at 4:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks.  Is Jay happy with this version?

It's good enough, but I'm still going to send a follow up patch that
looks in /Applications and $HOME/Applications since I don't think the
user should have to set the full path (they don't on other platforms).

So:

Acked-by: Jay Soffian

j.

^ permalink raw reply
* Re: [RFC PATCH v4 06/26] Add multi_ack_detailed capability to fetch-pack/upload-pack
From: Junio C Hamano @ 2009-10-29  5:57 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-7-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> ACK %s
> -----------------------------------
>   * no multi_ack or multi_ack_detailed:
>
>     Sent in response to "have" when the object exists on the remote
>     side and is therefore an object in common between the peers.
>     The argument is the SHA-1 of the common object.

Do you mean by "exists" something a bit stronger than that, namely, it
exists and everything reachable from it also exists, right?

> ACK %s common
> -----------------------------------
>   * multi_ack_detailed only:
>
>     Sent in response to "have".  Both sides have this object.
>     Like with "ACK %s continue" above the client should stop
>     sending have lines reachable for objects from the argument.
>
> ACK %s ready
> -----------------------------------
>   * multi_ack_detailed only:
>
>     Sent in response to "have".
>
>     The client should stop transmitting objects which are reachable
>     from the argument, and send "done" soon to get the objects.
>
>     If the remote side has the specified object, it should
>     first send an "ACK %s common" message prior to sending
>     "ACK %s ready".
>
>     Clients may still submit additional "have" lines if there are
>     more side branches for the client to explore that might be added
>     to the common set and reduce the number of objects to transfer.

I do not understand this after reading it three times.  The remote side
says "ACK $it common", allow the requestor to feed more "have", then
eventually send an "ACK $it ready" for the same object it earlier sent
"common" for?  The first one tells the requestor not to go down the path
from $it further, so presumably all the "have"s that come after it will be
about different ancestry paths.

What is the advantage of using this?  In other words, how, in what
situation and why would the remote side choose to use "ready" --- it looks
to me that it could always say "common" whenever it hits a "have" that it
can determine to be common.

^ permalink raw reply
* Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack
From: Junio C Hamano @ 2009-10-29  3:42 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-15-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> When --stateless-rpc is passed as a command line parameter to
> upload-pack or receive-pack the programs now assume they may
> perform only a single read-write cycle with stdin and stdout.
> This fits with the HTTP POST request processing model where a
> program may read the request, write a response, and must exit.
>
> When --advertise-refs is passed as a command line parameter only
> the initial ref advertisement is output, and the program exits
> immediately.  This fits with the HTTP GET request model, where
> no request content is received but a response must be produced.

Is the idea to first run with --advertise-refs to get the set of refs, and
then doing another, separate run with --stateless-rpc, assuming that the
refs the other end advertised does not change in the meantime, to conclude
the business?

I suspect that two separate invocations on a (supposedly) single
repository made back-to-back can produce an inconsistent response in
verious situations (e.g. somebody pushing in the middle, or the same
hostname served by more than one mirrors) and the other end can get
confused.

I do not think there is any way to avoid it, short of adding to the second
request some "cookie" that allows the second requestee to verify that the
request is based on what he would give to the requester if this request
were the first step of the request made to him, iow, his state did not
change in the middle since the first request was made (either to him or to
the equivalent mirror sitting next to himm).

I wouldn't worry too much about this if the only negative effect could be
that the requestor's second request may result in an error, but I am
wondering if this can be used to attack the requestee.

^ permalink raw reply
* Re: [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Junio C Hamano @ 2009-10-29  3:27 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-4-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> diff --git a/pkt-line.c b/pkt-line.c
> index bd603f8..893dd3c 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -124,12 +124,14 @@ static int packet_length(const char *linelen)
>  int packet_read_line(int fd, char *buffer, unsigned size)
>  {
>  	int len;
> -	char linelen[4];
> +	char linelen[5];
>  
>  	safe_read(fd, linelen, 4);
>  	len = packet_length(linelen);
> -	if (len < 0)
> -		die("protocol error: bad line length character");
> +	if (len < 0) {
> +		linelen[4] = '\0';
> +		die("protocol error: bad line length character: %s", linelen);
> +	}

Since this is not called recursively, you can make linelen[] static and do
without the NUL assignment; safe_read() won't read beyond 4 bytes anyway.

>  	if (!len)
>  		return 0;
>  	len -= 4;
> -- 
> 1.6.5.2.181.gd6f41

^ permalink raw reply
* Re: [RFC PATCH v4 05/26] Move "get_ack()" back to fetch-pack
From: Junio C Hamano @ 2009-10-29  3:24 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-6-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> In 41cb7488 Linus moved this function to connect.c for reuse inside
> of the git-clone-pack command.  That was 2005, but in 2006 Junio
> retired git-clone-pack in commit efc7fa53.  Since then the only
> caller has been fetch-pack.  Since this ACK/NAK exchange is only
> used by the fetch-pack/upload-pack protocol we should keep move
> it back to a private detail of fetch-pack.

Should we keep it there or should we move it?  which? ;-)

^ permalink raw reply
* Re: [RFC PATCH v4 26/26] test smart http fetch and push
From: Junio C Hamano @ 2009-10-29  3:20 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-27-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> +test_expect_success 'clone http repository' '
> +	GIT_CURL_VERBOSE=1 git clone $HTTPD_URL/git/repo.git clone 2>err &&
> +	test_cmp file clone/file &&
> +	egrep "^([<>]|Pragma|Accept|Content-|Transfer-)" err |
> +	egrep -v "^< (Server|Expires|Date|Content-Length:|Transfer-Encoding: chunked)" |
> +	sed -e "
> +		s/
> //
> +		s/^Content-Length: .*$/Content-Length: xxxx/
> +	" >act &&

This chomped line is so unlike you---what happened?

Also, when the last downstream is sed, why would you even need two egrep
process?

^ permalink raw reply
* Re: [PATCH 1/3] add splash screen
From: A Large Angry SCM @ 2009-10-29  2:25 UTC (permalink / raw)
  To: Jeff King; +Cc: git
In-Reply-To: <20091029002400.GA1057@sigill.intra.peff.net>

Jeff King wrote:
> Because bash completion is so slow to start, we need to
> entertain users with a splash screen, so reuse the one from
> git-gui.
> 
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Sam Vilain <sam@vilain.net>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> Signed-off-by: Nick Edelen <sirnot@gmail.com>
> Signed-off-by: "J.H." <warthog9@kernel.org>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  .gitignore    |    1 +
>  Makefile      |    3 +++
>  git-splash.sh |    4 ++++
>  git.c         |    6 ++++++
>  4 files changed, 14 insertions(+), 0 deletions(-)
>  create mode 100644 git-splash.sh
> 

If you're going to assume that the user has a working network connection 
for every git command invoked for part 3 of this series, why not get the 
logo image from kernel.org also so you always have the most up-to-date logo?

^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-29  1:53 UTC (permalink / raw)
  To: Avery Pennarun; +Cc: git list
In-Reply-To: <32541b130910280900p421e69b1nbcd8dcfa211521ac@mail.gmail.com>

On 29/10/2009, at 3:00 AM, Avery Pennarun wrote:

> On Wed, Oct 28, 2009 at 1:59 AM, Lachlan Deck  
> <lachlan.deck@gmail.com> wrote:
>> On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
>>> So which are the files you don't want to import from trunk?  It
>>> doesn't sound like there are any... so it's getting simpler already.
>>
>> There are. I've currently (as a workaround) done the following  
>> within the
>> main branch:
>> add the following to .git/info/exclude
>> .settings
>> target
>> .classpath
>> .project
>>
>> The last two of these has no effect of course because .project and
>> .classpath files already exist -- and thus are marked as modified.  
>> So I'm
>> currently doing a git stash && git svn rebase && git svn dcommit &&  
>> git
>> stash pop
>>
>> I'm also wanting to exclude 'lib' folders from trunk (as these are  
>> not
>> needed).
>
> The problem is that as your branch diverges from what you *actually*
> want to commit, it becomes exponentially more complicated to figure
> out what you *do* want to commit.

Sure.

> Note that if you're planning to share your git project with other
> people anyway, then you have an additional problem: you're using git
> svn rebase, which is almost useless for sharing with other people
> (other than through svn, of course), for the same reason any git
> rebase is.
>
> One option you have is to maintain two branches:
>
> 1. (git-svn) The git-svn trunk, which contains only stuff you want  
> upstream
>
> 2. (master) Your live branch, which contains everything from (1) plus
> your local customizations.
>
> When you want to fetch from svn, you do this:
>
>  git checkout master
>  git svn fetch git-svn
>  git merge git-svn
>
> When you want to push to svn, you do this:
>
>  git checkout git-svn
>  git merge --squash --no-commit master
>    (now undo your local customizations)
>  git commit
>  git svn dcommit
>  git checkout master
>  git merge git-svn
>
> Note that master never gets rebased, only merged.  If you can write a
> simple script for "undo your local customizations" - such as reverting
> a particular commit, for example - then you can put the above in a
> shell script and it should work fine most of the time.

Thanks Avery!
  - that gives me something to think about.

with regards,
--

Lachlan Deck

^ permalink raw reply
* Re: [PATCH 1/3] add splash screen
From: Michael Witten @ 2009-10-29  1:28 UTC (permalink / raw)
  To: Jeff King; +Cc: git
In-Reply-To: <20091029002400.GA1057@sigill.intra.peff.net>

On Wed, Oct 28, 2009 at 7:24 PM, Jeff King <peff@peff.net> wrote:
> Because bash completion is so slow to start, we need to
> entertain users with a splash screen, so reuse the one from
> git-gui.

According to Wolfram Alpha, you're about 22 weeks off in your timing.

^ permalink raw reply
* Re: [RFC PATCH v4 26/26] test smart http fetch and push
From: Clemens Buchacher @ 2009-10-29  0:31 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-27-git-send-email-spearce@spearce.org>

On Wed, Oct 28, 2009 at 05:00:48PM -0700, Shawn O. Pearce wrote:

> --- /dev/null
> +++ b/t/t5541-http-push.sh
[...]
> +LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5550'}

This should be 5541. We need different ports to be able to run the tests
simultenously.

> --- a/t/t5550-http-fetch.sh
> +++ b/t/t5550-http-fetch.sh

There is also a http port related bug in t5550. I'm attaching the patch
below. Maybe you want to squash this in here.

> --- /dev/null
> +++ b/t/t5551-http-fetch.sh
[...]
> +LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5550'}

Ditto, 5551.

Clemens

-->o--
Subject: [PATCH] set httpd port before sourcing lib-httpd

If LIB_HTTPD_PORT is not set already, lib-httpd will set it to the
default 8111.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
 t/t5540-http-push.sh  |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 5c0f4d7..ea46d1e 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -9,17 +9,16 @@ This test runs various sanity checks on http-push.'
 
 . ./test-lib.sh
 
-ROOT_PATH="$PWD"
-LIB_HTTPD_DAV=t
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5540'}
-
 if git http-push > /dev/null 2>&1 || [ $? -eq 128 ]
 then
 	say "skipping test, USE_CURL_MULTI is not defined"
 	test_done
 fi
 
+LIB_HTTPD_DAV=t
+LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5540'}
 . "$TEST_DIRECTORY"/lib-httpd.sh
+ROOT_PATH="$PWD"
 start_httpd
 
 test_expect_success 'setup remote repository' '
-- 
1.6.5.1.208.gd7b37

^ permalink raw reply related
* [PATCH 3/3] add autoupdate feature
From: Jeff King @ 2009-10-29  0:24 UTC (permalink / raw)
  To: git
In-Reply-To: <20091029002229.GA986@sigill.intra.peff.net>

Users can't be bothered to keep their software up to date, so
we must do it for them.  Whenever any git command is
invoked, this patch checks for new releases of git at
kernel.org, and automatically upgrades your version of git.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Nick Edelen <sirnot@gmail.com>
Signed-off-by: "J.H." <warthog9@kernel.org>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
 .gitignore          |    1 +
 Makefile            |    1 +
 git-autoupdate.perl |   58 +++++++++++++++++++++++++++++++++++++++++++++++++++
 git.c               |    9 +++++++-
 4 files changed, 68 insertions(+), 1 deletions(-)
 create mode 100644 git-autoupdate.perl

diff --git a/.gitignore b/.gitignore
index cf0d8b9..5a2703d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,6 +10,7 @@ git-annotate
 git-apply
 git-archimport
 git-archive
+git-autoupdate
 git-bisect
 git-bisect--helper
 git-blame
diff --git a/Makefile b/Makefile
index ae4b9fc..ba386a4 100644
--- a/Makefile
+++ b/Makefile
@@ -335,6 +335,7 @@ SCRIPT_SH += git-submodule.sh
 SCRIPT_SH += git-web--browse.sh
 
 SCRIPT_PERL += git-add--interactive.perl
+SCRIPT_PERL += git-autoupdate.perl
 SCRIPT_PERL += git-difftool.perl
 SCRIPT_PERL += git-archimport.perl
 SCRIPT_PERL += git-cvsexportcommit.perl
diff --git a/git-autoupdate.perl b/git-autoupdate.perl
new file mode 100644
index 0000000..c8ca10b
--- /dev/null
+++ b/git-autoupdate.perl
@@ -0,0 +1,58 @@
+#!/usr/bin/perl
+
+use LWP::Simple;
+use strict;
+
+my $ROOT = "http://kernel.org/pub/software/scm/git";
+
+my $us = our_git_version();
+my $them = latest_git_version();
+
+if (compare_versions($us, $them) < 0) {
+	print STDERR <<EOF;
+A new version of git is available! Auto-installing version $them.
+EOF
+}
+else {
+	exit 0;
+}
+
+upgrade($them);
+exit 42;
+
+sub our_git_version {
+	local $_ = `git version`;
+	/^git version (.*?)(\.\d+\.g[a-f0-9]+)?(\.dirty)?$/
+		or die "unable to read git version: $_";
+	return $1;
+}
+
+sub latest_git_version {
+	local $_ = get("$ROOT/");
+	my @versions = /git-([0-9.]+)\.tar\.gz/g
+		or die "unable to find any git versions at $ROOT";
+	# git version numbers have always sorted lexicographically so far,
+	# so let's just assume that will be the case forever
+	return (sort @versions)[-1];
+}
+
+sub compare_versions {
+	# let's assume lexicographical sorting again
+	return $_[0] cmp $_[1];
+}
+
+sub upgrade {
+	my $version = shift;
+	my $fn = "git-$version.tar.gz";
+	getstore("$ROOT/$fn", "/tmp/$fn") == 200
+		or die "unable to fetch $ROOT/$fn";
+	my $rc = system qq(
+		cd /tmp &&
+		gunzip -c $fn | tar xf - &&
+		cd git-$version &&
+		git config-mak >config.mak &&
+		make install
+	);
+	$rc == 0 or die "failed to upgrade git";
+	system("less /tmp/git-$version/RelNotes");
+}
diff --git a/git.c b/git.c
index 01ddf06..959ad52 100644
--- a/git.c
+++ b/git.c
@@ -462,10 +462,17 @@ int main(int argc, const char **argv)
 
 	if (!getenv("GIT_NOSPLASH") && !(argv[1] && !strcmp(argv[1], "splash"))) {
 		const char *a[] = { "splash", NULL };
-		const char *e[] = { "GIT_NOSPLASH=1", NULL };
+		const char *e[] = { "GIT_NOSPLASH=1", "GIT_NOAUTOUPDATE=1", NULL };
 		run_command_v_opt_cd_env(a, RUN_GIT_CMD, NULL, e);
 	}
 
+	if (!getenv("GIT_NOAUTOUPDATE")) {
+		const char *a[] = { "autoupdate", NULL };
+		const char *e[] = { "GIT_NOSPLASH=1", "GIT_NOAUTOUPDATE=1", NULL };
+		if (run_command_v_opt_cd_env(a, RUN_GIT_CMD, NULL, e) == 42)
+			exit(run_command_v_opt_cd_env(argv, 0, NULL, e));
+	}
+
 	/*
 	 * "git-xxxx" is the same as "git xxxx", but we obviously:
 	 *
-- 
1.6.5.1.3.g9d77a

^ permalink raw reply related
* [PATCH 2/3] add config-mak git command
From: Jeff King @ 2009-10-29  0:24 UTC (permalink / raw)
  To: git
In-Reply-To: <20091029002229.GA986@sigill.intra.peff.net>

This records the contents of your config.mak at build time
and prints them later.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Nick Edelen <sirnot@gmail.com>
Signed-off-by: "J.H." <warthog9@kernel.org>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
 .gitignore |    1 +
 Makefile   |    8 ++++++++
 builtin.h  |    1 +
 git.c      |    1 +
 help.c     |    7 +++++++
 5 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 1e547e7..cf0d8b9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -191,3 +191,4 @@ cscope*
 Debug/
 Release/
 git-splash
+config-mak.c
diff --git a/Makefile b/Makefile
index 36e1a61..ae4b9fc 100644
--- a/Makefile
+++ b/Makefile
@@ -480,6 +480,7 @@ LIB_OBJS += color.o
 LIB_OBJS += combine-diff.o
 LIB_OBJS += commit.o
 LIB_OBJS += config.o
+LIB_OBJS += config-mak.o
 LIB_OBJS += connect.o
 LIB_OBJS += convert.o
 LIB_OBJS += copy.o
@@ -1931,6 +1932,13 @@ coverage-clean:
 COVERAGE_CFLAGS = $(CFLAGS) -O0 -ftest-coverage -fprofile-arcs
 COVERAGE_LDFLAGS = $(CFLAGS)  -O0 -lgcov
 
+config-mak.c: config.mak
+	(echo 'const char *config_mak ='; \
+	 sed < config.mak -e 's/\\/\\\\/g; s/"/\\"/g; s/^/"/; s/$$/\\n"/'; \
+	 echo ';' \
+	) >$@+
+	mv $@+ $@
+
 coverage-build: coverage-clean
 	$(MAKE) CFLAGS="$(COVERAGE_CFLAGS)" LDFLAGS="$(COVERAGE_LDFLAGS)" all
 	$(MAKE) CFLAGS="$(COVERAGE_CFLAGS)" LDFLAGS="$(COVERAGE_LDFLAGS)" \
diff --git a/builtin.h b/builtin.h
index a2174dc..2ac8f3a 100644
--- a/builtin.h
+++ b/builtin.h
@@ -113,5 +113,6 @@ extern int cmd_verify_pack(int argc, const char **argv, const char *prefix);
 extern int cmd_show_ref(int argc, const char **argv, const char *prefix);
 extern int cmd_pack_refs(int argc, const char **argv, const char *prefix);
 extern int cmd_replace(int argc, const char **argv, const char *prefix);
+extern int cmd_config_mak(int argc, const char **argv, const char *prefix);
 
 #endif
diff --git a/git.c b/git.c
index 86dcfee..01ddf06 100644
--- a/git.c
+++ b/git.c
@@ -368,6 +368,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "verify-pack", cmd_verify_pack },
 		{ "show-ref", cmd_show_ref, RUN_SETUP },
 		{ "pack-refs", cmd_pack_refs, RUN_SETUP },
+		{ "config-mak", cmd_config_mak, },
 	};
 	int i;
 	static const char ext[] = STRIP_EXTENSION;
diff --git a/help.c b/help.c
index e8db31f..422259a 100644
--- a/help.c
+++ b/help.c
@@ -365,3 +365,10 @@ int cmd_version(int argc, const char **argv, const char *prefix)
 	printf("git version %s\n", git_version_string);
 	return 0;
 }
+
+extern const char *config_mak;
+int cmd_config_mak(int argc, const char **argv, const char *prefix)
+{
+	fputs(config_mak, stdout);
+	return 0;
+}
-- 
1.6.5.1.3.g9d77a

^ permalink raw reply related
* [PATCH 1/3] add splash screen
From: Jeff King @ 2009-10-29  0:24 UTC (permalink / raw)
  To: git
In-Reply-To: <20091029002229.GA986@sigill.intra.peff.net>

Because bash completion is so slow to start, we need to
entertain users with a splash screen, so reuse the one from
git-gui.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Nick Edelen <sirnot@gmail.com>
Signed-off-by: "J.H." <warthog9@kernel.org>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
 .gitignore    |    1 +
 Makefile      |    3 +++
 git-splash.sh |    4 ++++
 git.c         |    6 ++++++
 4 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 git-splash.sh

diff --git a/.gitignore b/.gitignore
index 51a37b1..1e547e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -190,3 +190,4 @@ cscope*
 *.pdb
 Debug/
 Release/
+git-splash
diff --git a/Makefile b/Makefile
index fea237b..36e1a61 100644
--- a/Makefile
+++ b/Makefile
@@ -329,6 +329,7 @@ SCRIPT_SH += git-rebase.sh
 SCRIPT_SH += git-repack.sh
 SCRIPT_SH += git-request-pull.sh
 SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-splash.sh
 SCRIPT_SH += git-stash.sh
 SCRIPT_SH += git-submodule.sh
 SCRIPT_SH += git-web--browse.sh
@@ -1352,6 +1353,7 @@ gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
 template_dir_SQ = $(subst ','\'',$(template_dir))
 htmldir_SQ = $(subst ','\'',$(htmldir))
 prefix_SQ = $(subst ','\'',$(prefix))
+sharedir_SQ = $(subst ','\'',$(sharedir))
 
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
 PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -1428,6 +1430,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
 	    -e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+	    -e 's|@@SHAREDIR@@|$(sharedir_SQ)|' \
 	    -e $(BROKEN_PATH_FIX) \
 	    $@.sh >$@+ && \
 	chmod +x $@+ && \
diff --git a/git-splash.sh b/git-splash.sh
new file mode 100644
index 0000000..fc2e6f7
--- /dev/null
+++ b/git-splash.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+echo 'source @@SHAREDIR@@/git-gui/lib/logo.tcl; pack [git_logo .logo]; after 3000 exit' |
+wish
diff --git a/git.c b/git.c
index 9883009..86dcfee 100644
--- a/git.c
+++ b/git.c
@@ -459,6 +459,12 @@ int main(int argc, const char **argv)
 	if (!cmd)
 		cmd = "git-help";
 
+	if (!getenv("GIT_NOSPLASH") && !(argv[1] && !strcmp(argv[1], "splash"))) {
+		const char *a[] = { "splash", NULL };
+		const char *e[] = { "GIT_NOSPLASH=1", NULL };
+		run_command_v_opt_cd_env(a, RUN_GIT_CMD, NULL, e);
+	}
+
 	/*
 	 * "git-xxxx" is the same as "git xxxx", but we obviously:
 	 *
-- 
1.6.5.1.3.g9d77a

^ permalink raw reply related
* [PATCH 0/3] increase user-friendliness
From: Jeff King @ 2009-10-29  0:22 UTC (permalink / raw)
  To: git

Git has a reputation as being unfriendly to users. Let's fix that by
adding some features implemented by more user-friendly programs.

-Peff

^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-29  0:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vhbtjo10s.fsf@alter.siamese.dyndns.org>

On Wed, 2009-10-28 at 10:56 -0700, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
> > Since this is only about warnings, maybe git 1.7.0 is the right time
> > frame to adjust this to the upcoming standard?
> 
> This does not look like "one group wants this way, but the others want
> differently.  We have to pick one and sacrifice the other because it is
> impossible to have it both ways"; there is no excuse to bring up 1.7.0 for
> something like this.
> 
> Doesn't inclusing "ssl.h" give us some indication whether "const" is
> needed to allow us to use #if/#else/#endif in order to compile with
> headers from either versions?  I.e. something like...
> 
> diff --git a/imap-send.c b/imap-send.c
> index 3847fd1..a199db8 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -273,7 +273,11 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
>  	fprintf(stderr, "SSL requested but SSL support not compiled in\n");
>  	return -1;
>  #else
> +#if (OPENSSL_VERSION_NUMBER >= 0x1000000fL)
> +	const SSL_METHOD *meth;
> +#else
>  	SSL_METHOD *meth;
> +#endif
>  	SSL_CTX *ctx;
>  	int ret;
>  

It's better than my patch, thanks.

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox