* 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 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 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 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: [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: [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] 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
* [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
* [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 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
* 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 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
* [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 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 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/2] Re: packaging vs default pager
From: Jonathan Nieder @ 2009-10-29 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, GIT List
In-Reply-To: <7vskd3o11t.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ben Walton <bwalton@artsci.utoronto.ca> writes:
>> Would it be completely out of line to provide a knob so that the
>> fallback $pager could be set to something more specific/appropriate
>> during the build?
>
> I think that is a sensible thing to do. Something like this?
>
> Makefile | 6 ++++++
> pager.c | 6 +++++-
> 2 files changed, 11 insertions(+), 1 deletions(-)
That looks good to me, but it’s missing a corresponding change to
git-svn. I think something like this could be useful for Debian to
avoid patching to comply with the distro policy of falling back to
generic "pager" and "editor" symlinks. How about the following two
patches?
Jonathan Nieder (1):
Provide a build time default-editor setting
Junio C Hamano (1):
Provide a build time default-pager setting
Makefile | 18 ++++++++++++++++++
editor.c | 2 +-
git-add--interactive.perl | 3 ++-
git-sh-setup.sh | 6 ++++--
git-svn.perl | 8 +++++---
pager.c | 2 +-
t/Makefile | 2 ++
t/t7005-editor.sh | 29 ++++++++++++++++++++++-------
8 files changed, 55 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Peter Baumann @ 2009-10-29 7:34 UTC (permalink / raw)
To: Jeff Epler; +Cc: Shawn O. Pearce, git
In-Reply-To: <1256160023-29629-1-git-send-email-jepler@unpythonic.net>
On Wed, Oct 21, 2009 at 04:20:21PM -0500, Jeff Epler wrote:
> Compared to the first version, I fixed a bug concerning staging line(s)
> when all following lines are deletions (a preexisting bug in git-gui).
> This version is made based off the master branch of git-gui.git, rather
> than the master branch of git.git.
>
> The first change fixes a long-standing git-gui bug in an area that the
> new feature is rewriting anyway. If there's interest in the new feature
> then maybe the two should just be squashed (using the message from the
> second). If not, it'd be nice to see the bugfix applied anyway.
>
>
> Jeff Epler (2):
> Fix applying a line when all following lines are deletions
> Make it possible to apply a range of changes at once
>
> git-gui.sh | 15 +++-
> lib/diff.tcl | 224 ++++++++++++++++++++++++++++++++--------------------------
> 2 files changed, 135 insertions(+), 104 deletions(-)
Cc ing Shawn as the git gui maintainer, as he might have missed this series
during his away time.
The original series including user comments can be found at
http://thread.gmane.org/gmane.comp.version-control.git/130732
whereas the newest version is here:
http://thread.gmane.org/gmane.comp.version-control.git/130968
--
Peter
^ permalink raw reply
* [PATCH 1/2] Provide a build time default-pager setting
From: Jonathan Nieder @ 2009-10-29 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, GIT List
In-Reply-To: <20091029073224.GA15403@progeny.tock>
From: Junio C Hamano <gitster@pobox.com>
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.
On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.
Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.
This puts the "less" default in the Makefile instead of pager.c,
since it is needed for git-svn, too. This means that the
DEFAULT_PAGER preprocessor token _has_ to be defined on the
command line for git to build. I was worried about this for a
moment, but GIT_VERSION already works this way without trouble.
Probably the DEFAULT_PAGER setting should be added to something
like TRACK_CFLAGS as well. Actually, some other settings that
can change without forcing files to be rebuilt (e.g. SHELL_PATH),
too. This should be probably be addressed separately.
Reported-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 8 ++++++++
git-svn.perl | 5 +++--
| 2 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 268aede..fc1a461 100644
--- a/Makefile
+++ b/Makefile
@@ -200,6 +200,9 @@ all::
# memory allocators with the nedmalloc allocator written by Niall Douglas.
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
+#
+# Define DEFAULT_PAGER to the path of a sensible pager (defaults to "less") if
+# you want to use something different.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1294,6 +1297,10 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
+ifndef DEFAULT_PAGER
+ DEFAULT_PAGER = less
+endif
+BASIC_CFLAGS += -DDEFAULT_PAGER='"$(DEFAULT_PAGER)"'
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -DUSE_NED_ALLOCATOR -DOVERRIDE_STRDUP -DNDEBUG -DREPLACE_SYSTEM_ALLOCATOR -Icompat/nedmalloc
@@ -1451,6 +1458,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@DEFAULT_PAGER@@/$(DEFAULT_PAGER)/g' \
$@.perl >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-svn.perl b/git-svn.perl
index 6a3b501..c270b23 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3,11 +3,12 @@
# License: GPL v2 or later
use warnings;
use strict;
-use vars qw/ $AUTHOR $VERSION
+use vars qw/ $AUTHOR $VERSION $DEFAULT_PAGER
$sha1 $sha1_short $_revision $_repository
$_q $_authors $_authors_prog %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
+$DEFAULT_PAGER = '@@DEFAULT_PAGER@@';
# From which subdir have we been invoked?
my $cmd_dir_prefix = eval {
@@ -5174,7 +5175,7 @@ sub git_svn_log_cmd {
sub config_pager {
$pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
if (!defined $pager) {
- $pager = 'less';
+ $pager = $DEFAULT_PAGER;
} elsif (length $pager == 0 || $pager eq 'cat') {
$pager = undef;
}
--git a/pager.c b/pager.c
index 86facec..416a796 100644
--- a/pager.c
+++ b/pager.c
@@ -58,7 +58,7 @@ void setup_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = DEFAULT_PAGER;
else if (!*pager || !strcmp(pager, "cat"))
return;
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH v3 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-10-29 7:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <6e01558f719f4bfcd12f3c6dc5657790e86c874d.1256770377.git.trast@student.ethz.ch>
Thomas Rast schrieb:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index a480d6f..da23b99 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -257,15 +257,23 @@ git read-tree || die "Could not seed the index"
> # map old->new commit ids for rewriting parents
> mkdir ../map || die "Could not create map/ directory"
>
> +dashdash=
> +test -z "$(git rev-parse --no-revs "$@")" && dashdash=--
Hmm, if the user runs
$ git filter-branch does-not-exist
then this would be the first call to rev-parse that fails with "fatal:
ambiguous argument 'does-not-exist': unknown revision or path...", but
this code wouldn't catch the failure. I suggest this instead:
# we need "--" only if there are no path arguments in $@
nonrevs=$(git rev-parse --no-revs "$@") || exit
dashdash=${nonrevs+"--"}
(including the comment; you can drop the dquotes in the dashdash
assignment if you think the result is still readable.)
I was to suggest to move these lines into the case arm below that is the
only user of $dashdash. But since this is a good error check of the
user-supplied arguments, I now prefer to keep the lines outside the case
statement.
> +ref_args=$(git rev-parse --revs-only "$@")
"ref_args"? Shouldn't it be "rev_args"? It's about "revisions", not
"references".
> case "$filter_subdir" in
> "")
> - git rev-list --reverse --topo-order --default HEAD \
> - --parents --simplify-merges "$@"
> + eval set -- "$(git rev-parse --sq --no-revs "$@")"
> ;;
> *)
> - git rev-list --reverse --topo-order --default HEAD \
> - --parents --simplify-merges "$@" -- "$filter_subdir"
> -esac > ../revs || die "Could not get the commits"
> + eval set -- "$(git rev-parse --sq --no-revs "$@")" \
> + $dashdash "$filter_subdir"
This is not correct: $filter_subdir undergoes an extra level of
evaluation. You must write it like this:
eval set -- "$(git rev-parse --sq --no-revs "$@" \
$dashdash "$filter_subdir")"
> + ;;
> +esac
> +
> +git rev-list --reverse --topo-order --default HEAD \
> + --parents --simplify-merges $ref_args "$@" \
> + > ../revs || die "Could not get the commits"
Personally, I would prefer to write this as
git rev-list --reverse --topo-order --default HEAD \
--parents --simplify-merges $ref_args "$@" > ../revs ||
die "Could not get the commits"
to avoid one backslash.
> @@ -356,8 +364,7 @@ then
> do
> sha1=$(git rev-parse "$ref"^0)
> test -f "$workdir"/../map/$sha1 && continue
> - ancestor=$(git rev-list --simplify-merges -1 \
> - $ref -- "$filter_subdir")
> + ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
You added dquotes around $ref: while not absolutely necessary, I agree
with this change.
> test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
> done < "$tempdir"/heads
> fi
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Johannes Sixt @ 2009-10-29 7:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <a11809cee976bb42102dbd9b2afb06b9e5b587bf.1256770377.git.trast@student.ethz.ch>
Thomas Rast schrieb:
> @@ -358,7 +365,7 @@ done <../revs
> # revision walker. Fix it by mapping these heads to the unique nearest
> # ancestor that survived the pruning.
>
> -if test "$filter_subdir"
> +if test "$remap_to_ancestor" = t
> then
The comment whose last lines are in the context of this hunk talks about
"subdirectory filter". You may want to revise it.
-- Hannes
^ permalink raw reply
* [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Jonathan Nieder @ 2009-10-29 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, GIT List
In-Reply-To: <20091029073224.GA15403@progeny.tock>
Provide a DEFAULT_EDITOR knob to allow the fallback editor (to
use instead of vi if VISUAL, EDITOR, and GIT_EDITOR are unset) to
be set at build time according to a system’s policy. For
example, on Debian systems, the default editor should be the
'editor' command.
The contrib/fast-import/git-p4 script still uses vi, since it is
not modified by the Makefile currently, and making it require
build-time modification would create too much trouble for people
deploying that script.
This change makes t7005-editor into a mess. Any ideas for fixing
this?
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 10 ++++++++++
editor.c | 2 +-
git-add--interactive.perl | 3 ++-
git-sh-setup.sh | 6 ++++--
git-svn.perl | 5 +++--
t/Makefile | 2 ++
t/t7005-editor.sh | 29 ++++++++++++++++++++++-------
7 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index fc1a461..fae8647 100644
--- a/Makefile
+++ b/Makefile
@@ -203,6 +203,9 @@ all::
#
# Define DEFAULT_PAGER to the path of a sensible pager (defaults to "less") if
# you want to use something different.
+#
+# Define DEFAULT_EDITOR to a sensible editor command (defaults to "vi") if you
+# want to use something different.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1301,6 +1304,11 @@ ifndef DEFAULT_PAGER
DEFAULT_PAGER = less
endif
BASIC_CFLAGS += -DDEFAULT_PAGER='"$(DEFAULT_PAGER)"'
+ifndef DEFAULT_EDITOR
+ DEFAULT_EDITOR = vi
+endif
+export DEFAULT_EDITOR
+BASIC_CFLAGS += -DDEFAULT_EDITOR='"$(DEFAULT_EDITOR)"'
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -DUSE_NED_ALLOCATOR -DOVERRIDE_STRDUP -DNDEBUG -DREPLACE_SYSTEM_ALLOCATOR -Icompat/nedmalloc
@@ -1435,6 +1443,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|DEFAULT_EDITOR:=vi|DEFAULT_EDITOR:=$(DEFAULT_EDITOR)|' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+ && \
chmod +x $@+ && \
@@ -1459,6 +1468,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@DEFAULT_PAGER@@/$(DEFAULT_PAGER)/g' \
+ -e 's/@@DEFAULT_EDITOR@@/$(DEFAULT_EDITOR)/g' \
$@.perl >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/editor.c b/editor.c
index 4d469d0..93b8cbb 100644
--- a/editor.c
+++ b/editor.c
@@ -19,7 +19,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
return error("Terminal is dumb but no VISUAL nor EDITOR defined.");
if (!editor)
- editor = "vi";
+ editor = DEFAULT_EDITOR;
if (strcmp(editor, ":")) {
size_t len = strlen(editor);
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 69aeaf0..c3d932c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,7 @@
#!/usr/bin/perl -w
use strict;
+use constant DEFAULT_EDITOR => '@@DEFAULT_EDITOR@@';
use Git;
binmode(STDOUT, ":raw");
@@ -988,7 +989,7 @@ EOF
close $fh;
my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
- || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+ || $ENV{VISUAL} || $ENV{EDITOR} || DEFAULT_EDITOR;
system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
if ($? != 0) {
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..d053d56 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -99,19 +99,21 @@ set_reflog_action() {
}
git_editor() {
+ : "${DEFAULT_EDITOR:=vi}"
: "${GIT_EDITOR:=$(git config core.editor)}"
: "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
case "$GIT_EDITOR,$TERM" in
,dumb)
echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
- echo >&2 "or EDITOR. Tried to fall back to vi but terminal is dumb."
+ echo >&2 "or EDITOR. Tried to fall back to $DEFAULT_EDITOR" \
+ "but terminal is dumb."
echo >&2 "Please set one of these variables to an appropriate"
echo >&2 "editor or run $0 with options that will not cause an"
echo >&2 "editor to be invoked (e.g., -m or -F for git-commit)."
exit 1
;;
esac
- eval "${GIT_EDITOR:=vi}" '"$@"'
+ eval "${GIT_EDITOR:=$DEFAULT_EDITOR}" '"$@"'
}
is_bare_repository () {
diff --git a/git-svn.perl b/git-svn.perl
index c270b23..b98d378 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3,12 +3,13 @@
# License: GPL v2 or later
use warnings;
use strict;
-use vars qw/ $AUTHOR $VERSION $DEFAULT_PAGER
+use vars qw/ $AUTHOR $VERSION $DEFAULT_PAGER $DEFAULT_EDITOR
$sha1 $sha1_short $_revision $_repository
$_q $_authors $_authors_prog %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
$DEFAULT_PAGER = '@@DEFAULT_PAGER@@';
+$DEFAULT_EDITOR = '@@DEFAULT_EDITOR@@';
# From which subdir have we been invoked?
my $cmd_dir_prefix = eval {
@@ -1322,7 +1323,7 @@ sub get_commit_entry {
close $log_fh or croak $!;
if ($_edit || ($type eq 'tree')) {
- my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
+ my $editor = $ENV{VISUAL} || $ENV{EDITOR} || $DEFAULT_EDITOR;
# TODO: strip out spaces, comments, like git-commit.sh
system($editor, $commit_editmsg);
}
diff --git a/t/Makefile b/t/Makefile
index bd09390..9174bbb 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -9,6 +9,8 @@
SHELL_PATH ?= $(SHELL)
TAR ?= $(TAR)
RM ?= rm -f
+DEFAULT_EDITOR ?= vi
+export DEFAULT_EDITOR
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index b647957..2b76f72 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -4,7 +4,18 @@ test_description='GIT_EDITOR, core.editor, and stuff'
. ./test-lib.sh
-for i in GIT_EDITOR core_editor EDITOR VISUAL vi
+: ${DEFAULT_EDITOR=vi}
+
+unset EDITOR VISUAL GIT_EDITOR
+
+case "$DEFAULT_EDITOR" in
+*/* | [A-Z]*)
+ DEFAULT_EDITOR=
+ ;;
+esac
+
+for i in GIT_EDITOR core_editor EDITOR VISUAL \
+ ${DEFAULT_EDITOR:+"$DEFAULT_EDITOR"}
do
cat >e-$i.sh <<-EOF
#!$SHELL_PATH
@@ -12,15 +23,17 @@ do
EOF
chmod +x e-$i.sh
done
-unset vi
-mv e-vi.sh vi
-unset EDITOR VISUAL GIT_EDITOR
+
+if test -n "$DEFAULT_EDITOR"
+then
+ mv "e-$DEFAULT_EDITOR.sh" "$DEFAULT_EDITOR"
+fi
test_expect_success setup '
msg="Hand edited" &&
echo "$msg" >expect &&
- git add vi &&
+ git add "e-VISUAL.sh" &&
test_tick &&
git commit -m "$msg" &&
git show -s --pretty=oneline |
@@ -44,7 +57,8 @@ test_expect_success 'dumb should error out when falling back on vi' '
TERM=vt100
export TERM
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in ${DEFAULT_EDITOR:+"$DEFAULT_EDITOR"} \
+ EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
unset EDITOR VISUAL GIT_EDITOR
@@ -68,7 +82,8 @@ done
unset EDITOR VISUAL GIT_EDITOR
git config --unset-all core.editor
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in ${DEFAULT_EDITOR:+"$DEFAULT_EDITOR"} \
+ EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
case "$i" in
--
1.6.5.2
^ permalink raw reply related
* translation help documentation
From: Laszlo Papp @ 2009-10-29 7:40 UTC (permalink / raw)
To: git
Hello,
Isn't there a translation help documentation ?
What's your 'policy' about it ? A lot of projects use such a
documentation, and sometimes translation helper script too. I can send
a sample if you feel so.
Best Regards,
Laszlo Papp
^ permalink raw reply
* [PATCH] clone: detect extra arguments
From: Jonathan Nieder @ 2009-10-29 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If git clone is given more than two non-option arguments, it
silently throws away all but the first one. Complain instead.
Discovered by comparing the new builtin clone to the old
git-clone.sh.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-clone.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 5762a6f..76ad581 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -377,6 +377,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, builtin_clone_options,
builtin_clone_usage, 0);
+ if (argc > 2)
+ die("Too many arguments.");
+
if (argc == 0)
die("You must specify a repository to clone.");
--
1.6.5.2
^ permalink raw reply related
* Re: [RFC PATCH v4 00/26] Return of smart HTTP
From: Jakub Narebski @ 2009-10-29 8:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I think this is the final spin of the smart HTTP series. I've
> collected patches from a few others (thanks folks!) and added
> tests specific to the smart variant of the HTTP transport.
>
> At this point, I think it is "next ready"... but would appreciate
> any additional feedback if folks identify something we should
> address before hitting next.
[...]
> .gitignore | 1 +
> Documentation/config.txt | 8 +
> Documentation/git-http-backend.txt | 170 ++++++++
> Documentation/git-remote-helpers.txt | 85 ++++-
> Makefile | 1 +
[...]
> 32 files changed, 2574 insertions(+), 223 deletions(-)
> create mode 100644 Documentation/git-http-backend.txt
> create mode 100644 http-backend.c
> create mode 100755 t/t5541-http-push.sh
> create mode 100755 t/t5551-http-fetch.sh
If it is a final spin, then what of missing RFC-like documentation of
Git HTTP protocol in Documentation/technical/http-protocol.txt
(it was present only in first version of new series)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH I18N filenames v2 3/3] Provide compatibility with MinGW
From: Peter Krefting @ 2009-10-29 9:01 UTC (permalink / raw)
To: Timur Sufiev; +Cc: Git Mailing List
In-Reply-To: <1256752900-2615-3-git-send-email-timur@iris-comp.ru>
Hi!
Timur Sufiev:
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 6b5b5b2..2a2ebcb 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -2,7 +2,7 @@
> #include "win32.h"
> #include <conio.h>
> #include "../strbuf.h"
> -
> +#include "../io-i18n.h"
> #include <shellapi.h>
>
> static int err_win_to_posix(DWORD winerr)
> @@ -132,7 +132,7 @@ int mingw_open (const char *filename, int oflags, ...)
> if (!strcmp(filename, "/dev/null"))
> filename = "nul";
>
> - fd = open(filename, oflags, mode);
> + fd = open_i18n(filename, oflags, mode);
>
> if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
> DWORD attrs = GetFileAttributes(filename);
Instead of calling the open_i18n() which converts from UTF-8 to a local
8-bit character set, this should probably call a version that converts from
UTF-8 to UTF-16 and uses _wopen().
Same thing for fopen_i18n() and _wfopen().
I created a small RFC patch for that that changed parts of the system
earlier this year - http://kerneltrap.org/mailarchive/git/2009/3/2/5350814
I did not address readdir() and friends, I'm not sure if they are available
in UTF-16 form or if they need to be rewritten using findfirst()/findnext().
--
\\// Peter - http://www.softwolves.pp.se/
^ 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