* Re: [PATCH] rebase -i: fix has_action
From: Junio C Hamano @ 2011-08-05 16:59 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Noe Rubinstein, git
In-Reply-To: <CAGdFq_j2wRw-gB109VypZkG1u=fm7yynkn2-Gu8AzNpVOrun8w@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Thu, Aug 4, 2011 at 21:34, Junio C Hamano <gitster@pobox.com> wrote:
>> has_action () {
>> test -s "$1"
>> }
>
>> has_action () {
>> sane_grep -v -e '^#' -e '^[ ]*$' "$1" >/dev/null
>> }
>
> I think the former more correctly checks what the function name
> implies, is there any downside to that which makes you suggest this
> second approach?
I vaguely recall the original reason we didn't do the most straightforward
thing was something like what J6t said already.
As we are not interested in _adding_ new feature, I would say that,
strictly speaking, this *should* become a two-patch series whose first one
uses
sane_grep -v -e '^#' -e '^$' "$1" >/dev/null
that is, "do we have anything aside from comments and blanks?", which is
the original semantics, with Noe's "safety" change as the second patch in
the series that uses
sane_grep -v -e '^#' -e '^[ ]*$' "$1" >/dev/null
to say "let's count a line that solely consists of whitespaces also as a
blank".
But of course in practice it can and should be just a single patch that
squashes these two "conceptually separate" steps.
^ permalink raw reply
* Re: [PATCH] rebase -i: fix has_action
From: Junio C Hamano @ 2011-08-05 17:01 UTC (permalink / raw)
To: Andrew Wong; +Cc: Junio C Hamano, Noe Rubinstein, git
In-Reply-To: <4E3BFB86.4010408@sohovfx.com>
Andrew Wong <andrew.w@sohovfx.com> writes:
> On 08/04/2011 03:34 PM, Junio C Hamano wrote:
>> How about removing the unnecessary negation from the logic and directly
>> ask what we really want to know?
>>
>> That is, "Do we have a line that is _not_ comment?"
>>
>> has_action () {
>> sane_grep -v -e '^#' -e '^[ ]*$' "$1" >/dev/null
>> }
> How about also including comments that begins with spaces? i.e.
Not interested.
It would be _clear_ if you inserted extra space before '#'; Noe's issue is
that it is not clear if you have extra space on a blank line, which I am a
bit more sympathetic.
^ permalink raw reply
* Re: [PATCH 0/2] bisect: cleanup formatting of git-bisect.sh
From: Junio C Hamano @ 2011-08-05 17:09 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster
In-Reply-To: <1312543891-11079-1-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> This series is intended to be applied on top js/bisect-no-checkout.
Thanks; I wonder if we want to go a bit further.
-- >8 --
Subject: bisect: further style nitpicks
Fix a few remaining lines that indented with spaces.
Also simplify the logic of checking out the original branch and reporting
error during "bisect reset".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 1f3c46d..22c4da5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -94,9 +94,9 @@ bisect_start() {
die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
*)
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
- test $has_double_dash -eq 1 &&
- die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
- break
+ test $has_double_dash -eq 1 &&
+ die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
+ break
}
case $bad_seen in
0) state='bad' ; bad_seen=1 ;;
@@ -125,7 +125,7 @@ bisect_start() {
start_head=$(cat "$GIT_DIR/BISECT_START")
if test "z$mode" != "z--no-checkout"
then
- git checkout "$start_head" --
+ git checkout "$start_head" --
fi
else
# Get rev from where we start.
@@ -332,7 +332,7 @@ bisect_visualize() {
if test $# = 0
then
if test -n "${DISPLAY+set}${SESSIONNAME+set}${MSYSTEM+set}${SECURITYSESSIONID+set}" &&
- type gitk >/dev/null 2>&1
+ type gitk >/dev/null 2>&1
then
set gitk
else
@@ -364,13 +364,11 @@ bisect_reset() {
*)
usage ;;
esac
- if ! test -f "$GIT_DIR/BISECT_HEAD"
+
+ if ! test -f "$GIT_DIR/BISECT_HEAD" && ! git checkout "$branch" --
then
- if ! git checkout "$branch" --
- then
- die "$(eval_gettext "Could not check out original HEAD '\$branch'.
+ die "$(eval_gettext "Could not check out original HEAD '\$branch'.
Try 'git bisect reset <commit>'.")"
- fi
fi
bisect_clean_state
}
^ permalink raw reply related
* Re: [PATCH] misc-sh: fix up whitespace in some other .sh files.
From: Junio C Hamano @ 2011-08-05 17:26 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <1312551089-3753-1-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 962a93b..0d399aa 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -98,11 +98,11 @@ set_ident () {
> }
>
> USAGE="[--env-filter <command>] [--tree-filter <command>]
> - [--index-filter <command>] [--parent-filter <command>]
> - [--msg-filter <command>] [--commit-filter <command>]
> - [--tag-name-filter <command>] [--subdirectory-filter <directory>]
> - [--original <namespace>] [-d <directory>] [-f | --force]
> - [<rev-list options>...]"
> + [--index-filter <command>] [--parent-filter <command>]
> + [--msg-filter <command>] [--commit-filter <command>]
> + [--tag-name-filter <command>] [--subdirectory-filter <directory>]
> + [--original <namespace>] [-d <directory>] [-f | --force]
> + [<rev-list options>...]"
>
> OPTIONS_SPEC=
> . git-sh-setup
Everything other than this hunk is unquestionably fine. I think this one
also is Ok but I wonder where the "Indented by 12 columns" comes
from. "Usage: git filter-branch " that is prefixed to the first line is 25
columns long, so the "[--index-filter ..." on the second line would not
align with "[--env-filter ..." on the first line to begin with.
And I do not think they need to align --- the point is if the second and
subsequent lines do not aim to align with anything on the first line, it
is just fine to indent them with a single HT, I think.
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Erik Faye-Lund @ 2011-08-05 17:29 UTC (permalink / raw)
To: Pascal Obry; +Cc: git
In-Reply-To: <1312560614-20772-3-git-send-email-pascal@obry.net>
On Fri, Aug 5, 2011 at 6:10 PM, Pascal Obry <pascal@obry.net> wrote:
> In fact Cygwin supports both, so make Git agree with this.
> The failing case is when a file is committed in a sub-dir of the
> repository using a log message from a file specified with a DOS
> style path-name. To reproduce:
>
> $ cd src
> $ git commit -F c:\tmp\log.txt file.c
> fatal: could not read log file 'src/c:\tmp\log.txt': No such file \
> or directory.
Cygwin is a unix-layer on top of Windows, designed to play by the
POSIX-rules. So why would you want to support Windows-style paths on
Cygwin?
If you want a Git that handles Windows paths, use Git for Windows...
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Pascal Obry @ 2011-08-05 17:35 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <CABPQNSYSzsY-CQdi6iJQftsY1ufMpxkax=eQLgopVxMC6LoxfA@mail.gmail.com>
Le 05/08/2011 19:29, Erik Faye-Lund a écrit :
> Cygwin is a unix-layer on top of Windows, designed to play by the
> POSIX-rules. So why would you want to support Windows-style paths on
> Cygwin?
Because cygwin toolset does support \.
> If you want a Git that handles Windows paths, use Git for Windows...
Note that Windows is a special case as even the Win32 API does support \
and /, so every tool on Windows seems to handle nicely this. Why not
Git, be it Cygwin/Git. If it does not break anything else.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Erik Faye-Lund @ 2011-08-05 17:39 UTC (permalink / raw)
To: pascal; +Cc: git
In-Reply-To: <4E3C29D9.5060305@obry.net>
On Fri, Aug 5, 2011 at 7:35 PM, Pascal Obry <pascal@obry.net> wrote:
> Le 05/08/2011 19:29, Erik Faye-Lund a écrit :
>>
>> Cygwin is a unix-layer on top of Windows, designed to play by the
>> POSIX-rules. So why would you want to support Windows-style paths on
>> Cygwin?
>
> Because cygwin toolset does support \.
>
Are you saying that the built-in Cygwin tools (like ls etc) support
Windows-style paths (C:\path\to\file)? If that is the case, I
completely understand the desire to accept Windows-paths.
>> If you want a Git that handles Windows paths, use Git for Windows...
>
> Note that Windows is a special case as even the Win32 API does support \ and
> /, so every tool on Windows seems to handle nicely this. Why not Git, be it
> Cygwin/Git. If it does not break anything else.
If the Cygwin-tools does not support drive-prefixes (i.e "C:\") but
does support both slashes as path-separators, then I agree with the
patch but not with the commit message.
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Junio C Hamano @ 2011-08-05 17:48 UTC (permalink / raw)
To: Pascal Obry; +Cc: git, Theo Niessink
In-Reply-To: <1312560614-20772-3-git-send-email-pascal@obry.net>
Pascal Obry <pascal@obry.net> writes:
> In fact Cygwin supports both, so make Git agree with this.
> The failing case is when a file is committed in a sub-dir of the
> repository using a log message from a file specified with a DOS
> style path-name. To reproduce:
>
> $ cd src
> $ git commit -F c:\tmp\log.txt file.c
> fatal: could not read log file 'src/c:\tmp\log.txt': No such file \
> or directory.
>
> Signed-off-by: Pascal Obry <pascal@obry.net>
> ---
> compat/cygwin.h | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/compat/cygwin.h b/compat/cygwin.h
> index a3229f5..de9737c 100644
> --- a/compat/cygwin.h
> +++ b/compat/cygwin.h
> @@ -7,3 +7,6 @@ extern stat_fn_t cygwin_lstat_fn;
>
> #define stat(path, buf) (*cygwin_stat_fn)(path, buf)
> #define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
> +
> +#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
> +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
I wonder if these two that are the same as mingw should further be
consolidated into one implementation, something like below.
Note that I am just wondering, not suggesting, without knowing which is
better.
compat/cygwin.h | 5 ++---
compat/mingw.h | 3 +--
git-compat-util.h | 11 ++++-------
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/compat/cygwin.h b/compat/cygwin.h
index de9737c..ef0889b 100644
--- a/compat/cygwin.h
+++ b/compat/cygwin.h
@@ -1,12 +1,11 @@
#include <sys/types.h>
#include <sys/stat.h>
+#define DOS_STYLE_DIR_SEP 1
+
typedef int (*stat_fn_t)(const char*, struct stat*);
extern stat_fn_t cygwin_stat_fn;
extern stat_fn_t cygwin_lstat_fn;
#define stat(path, buf) (*cygwin_stat_fn)(path, buf)
#define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
-
-#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
-#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
diff --git a/compat/mingw.h b/compat/mingw.h
index 547568b..26ca0ef 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -298,8 +298,7 @@ int winansi_fprintf(FILE *stream, const char *format, ...) __attribute__((format
* git specific compatibility
*/
-#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
-#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
+#define DOS_STYLE_DIR_SEP 1
#define PATH_SEP ';'
#define PRIuMAX "I64u"
diff --git a/git-compat-util.h b/git-compat-util.h
index c2c94cd..133f331 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -211,7 +211,9 @@ extern char *gitbasename(char *);
#define has_dos_drive_prefix(path) 0
#endif
-#if !defined(find_last_dir_sep) && defined(is_dir_sep)
+#if defined(DOS_STYLE_DIR_SEP)
+#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
+#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
static inline char *compat_find_last_dir_sep(const char *path)
{
char *ret = NULL;
@@ -221,13 +223,8 @@ static inline char *compat_find_last_dir_sep(const char *path)
return ret;
}
#define find_last_dir_sep compat_find_last_dir_sep
-#endif
-
-#ifndef is_dir_sep
+#else
#define is_dir_sep(c) ((c) == '/')
-#endif
-
-#ifndef find_last_dir_sep
#define find_last_dir_sep(path) strrchr(path, '/')
#endif
^ permalink raw reply related
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Erik Faye-Lund @ 2011-08-05 17:51 UTC (permalink / raw)
To: pascal; +Cc: git
In-Reply-To: <CABPQNSYQ9D7NO5cx_o3csAe4bQ40kOd1f5gATUXDb7r4n3GhdA@mail.gmail.com>
On Fri, Aug 5, 2011 at 7:39 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 7:35 PM, Pascal Obry <pascal@obry.net> wrote:
>> Le 05/08/2011 19:29, Erik Faye-Lund a écrit :
>>>
>>> Cygwin is a unix-layer on top of Windows, designed to play by the
>>> POSIX-rules. So why would you want to support Windows-style paths on
>>> Cygwin?
>>
>> Because cygwin toolset does support \.
>>
>
> Are you saying that the built-in Cygwin tools (like ls etc) support
> Windows-style paths (C:\path\to\file)? If that is the case, I
> completely understand the desire to accept Windows-paths.
>
>>> If you want a Git that handles Windows paths, use Git for Windows...
>>
>> Note that Windows is a special case as even the Win32 API does support \ and
>> /, so every tool on Windows seems to handle nicely this. Why not Git, be it
>> Cygwin/Git. If it does not break anything else.
>
> If the Cygwin-tools does not support drive-prefixes (i.e "C:\") but
> does support both slashes as path-separators, then I agree with the
> patch but not with the commit message.
>
correction: if that is the case, I agree with the is_dir_sep-part, but
not the has_dos_drive_prefix-part of the patch (and also not the
example from the commit message)
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Erik Faye-Lund @ 2011-08-05 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pascal Obry, git, Theo Niessink
In-Reply-To: <7vipqb3g1w.fsf@alter.siamese.dyndns.org>
On Fri, Aug 5, 2011 at 7:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Pascal Obry <pascal@obry.net> writes:
>
>> In fact Cygwin supports both, so make Git agree with this.
>> The failing case is when a file is committed in a sub-dir of the
>> repository using a log message from a file specified with a DOS
>> style path-name. To reproduce:
>>
>> $ cd src
>> $ git commit -F c:\tmp\log.txt file.c
>> fatal: could not read log file 'src/c:\tmp\log.txt': No such file \
>> or directory.
>>
>> Signed-off-by: Pascal Obry <pascal@obry.net>
>> ---
>> compat/cygwin.h | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/compat/cygwin.h b/compat/cygwin.h
>> index a3229f5..de9737c 100644
>> --- a/compat/cygwin.h
>> +++ b/compat/cygwin.h
>> @@ -7,3 +7,6 @@ extern stat_fn_t cygwin_lstat_fn;
>>
>> #define stat(path, buf) (*cygwin_stat_fn)(path, buf)
>> #define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
>> +
>> +#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
>> +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
>
> I wonder if these two that are the same as mingw should further be
> consolidated into one implementation, something like below.
>
> Note that I am just wondering, not suggesting, without knowing which is
> better.
IMO this becomes a bit hard to read as you have to ping-pong between
sources to understand exactly what that flag does. We have
compat/win32.h, perhaps we should move the macros there and include it
from both compat/mingw.h and compat/cygwin.h instead (given that we're
going to do this, of course)?
^ permalink raw reply
* Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
From: Pascal Obry @ 2011-08-05 18:39 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <CABPQNSYQ9D7NO5cx_o3csAe4bQ40kOd1f5gATUXDb7r4n3GhdA@mail.gmail.com>
Le 05/08/2011 19:39, Erik Faye-Lund a écrit :
> Are you saying that the built-in Cygwin tools (like ls etc) support
> Windows-style paths (C:\path\to\file)? If that is the case, I
> completely understand the desire to accept Windows-paths.
Exactly.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* [RFC] helping smart-http/stateless-rpc fetch race
From: Junio C Hamano @ 2011-08-05 20:54 UTC (permalink / raw)
To: git
A request to fetch from a client over smart HTTP protocol is served in
multiple steps. In the first round, the server side shows the set of refs
it has and their values, and the client picks from them and sends "I want
to fetch the history leading to these commits".
When the server tries to respond to this second request, its refs may have
progressed by a push from elsewhere. By design, we do not allow fetching
objects that are not at the tip of an advertised ref, and the server
rejects such a request. The client needs to try again, which is not ideal
especially for a busy server.
Teach --allow-non-tip option to upload-pack (which is the workhorse driven
by git-daemon and smart http server interface) that lets it server commits
that are not at the tip of any advertised ref, as long as they are
reachable from advertised refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I'll leave it to interested parties who are more qualified than I am to
update remote-curl nor http-backend to actually ask upload-pack to use
this new logic ;-)
upload-pack.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 95 insertions(+), 9 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index ce5cbbe..76be9ff 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -10,6 +10,7 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "sigchain.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
@@ -42,6 +43,7 @@ static int use_sideband;
static int debug_fd;
static int advertise_refs;
static int stateless_rpc;
+static int allow_non_tip;
static void reset_timeout(void)
{
@@ -498,11 +500,87 @@ static int get_common_commits(void)
}
}
+static void check_non_tip(void)
+{
+ static const char *argv[] = {
+ "rev-list", "--stdin", NULL,
+ };
+ static struct child_process cmd;
+ int i;
+ char namebuf[42]; /* ^ + SHA-1 + LF */
+
+ if (!allow_non_tip)
+ goto error;
+
+ cmd.argv = argv;
+ cmd.git_cmd = 1;
+ cmd.no_stderr = 1;
+ cmd.in = -1;
+ cmd.out = -1;
+
+ if (start_command(&cmd))
+ goto error;
+
+ /*
+ * If rev-list --stdin encounters an unknown commit, it
+ * terminates, which will cause SIGPIPE in the write loop
+ * below.
+ */
+ sigchain_push(SIGPIPE, SIG_IGN);
+
+ namebuf[0] = '^';
+ namebuf[41] = '\n';
+ for (i = get_max_object_index(); 0 < i; ) {
+ struct object *o = get_indexed_object(--i);
+ if (!(o->flags & OUR_REF))
+ continue;
+ memcpy(namebuf + 1, sha1_to_hex(o->sha1), 40);
+ if (write_in_full(cmd.in, namebuf, 42) < 0)
+ goto error;
+ }
+ namebuf[40] = '\n';
+ for (i = 0; i < want_obj.nr; i++) {
+ struct object *o = want_obj.objects[i].item;
+ if (o->flags & OUR_REF)
+ continue;
+ memcpy(namebuf, sha1_to_hex(o->sha1), 40);
+ if (write_in_full(cmd.in, namebuf, 41) < 0)
+ goto error;
+ }
+ close(cmd.in);
+
+ sigchain_pop(SIGPIPE);
+
+ /*
+ * The commits out of the rev-list are not ancestors of
+ * our ref.
+ */
+ i = read_in_full(cmd.out, namebuf, 1);
+ if (i)
+ goto error;
+ close(cmd.out);
+
+ /*
+ * rev-list may have died by encountering a bad commit
+ * in the history, in which case we do want to bail out
+ * even when it showed no commit.
+ */
+ if (finish_command(&cmd))
+ goto error;
+
+ /* All the non-tip ones are ancestors of what we advertised */
+ return;
+
+error:
+ die("git upload-pack: not our ref");
+}
+
static void receive_needs(void)
{
struct object_array shallows = OBJECT_ARRAY_INIT;
static char line[1000];
int len, depth = 0;
+ int has_non_tip = 0;
shallow_nr = 0;
if (debug_fd)
@@ -559,26 +637,30 @@ static void receive_needs(void)
if (strstr(line+45, "include-tag"))
use_include_tag = 1;
- /* We have sent all our refs already, and the other end
- * should have chosen out of them; otherwise they are
- * asking for nonsense.
- *
- * Hmph. We may later want to allow "want" line that
- * asks for something like "master~10" (symbolic)...
- * would it make sense? I don't know.
- */
o = lookup_object(sha1_buf);
- if (!o || !(o->flags & OUR_REF))
+ if (!o)
die("git upload-pack: not our ref %s",
sha1_to_hex(sha1_buf));
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
+ if (!(o->flags & OUR_REF))
+ has_non_tip = 1;
add_object_array(o, NULL, &want_obj);
}
}
if (debug_fd)
write_str_in_full(debug_fd, "#E\n");
+ /*
+ * We have sent all our refs already, and the other end
+ * should have chosen out of them. When we are operating
+ * in the stateless RPC mode, however, their choice may
+ * have been based on the set of older refs advertised
+ * by another process that handled the initial request.
+ */
+ if (has_non_tip)
+ check_non_tip();
+
if (!use_sideband && daemon_mode)
no_progress = 1;
@@ -720,6 +802,10 @@ int main(int argc, char **argv)
stateless_rpc = 1;
continue;
}
+ if (!strcmp(arg, "--allow-non-tip")) {
+ allow_non_tip = 1;
+ continue;
+ }
if (!strcmp(arg, "--strict")) {
strict = 1;
continue;
^ permalink raw reply related
* Re: Cleaning up history with git rebase
From: pbegeland @ 2011-08-05 21:26 UTC (permalink / raw)
To: Michael Witten; +Cc: Ricky Egeland, git
In-Reply-To: <b3e1c29767984546a61e2d10fb180188-mfwitten@gmail.com>
On Thu, 04 Aug 2011 14:35:19 -0000, Michael Witten <mfwitten@gmail.com>
wrote:
> [Put your reply text below the quoted text.]
>
> On Wed, 03 Aug 2011 17:58:26 -0300, Patricia Egeland wrote:
>
>> On Mon, 01 Aug 2011 01:07:33 -0000, Michael Witten wrote:
>>
>>> Michael Witten wrote:
>>>
>>>> On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:
>>>>
>>>>> On Jul 31, 2011, at 6:33 PM, Michael Witten wrote:
>>>>>
>>>>>> On Sun, Jul 31, 2011 at 20:21, Michael Witten
>>>>>> <mfwitten@gmail.com>
>>>>>> wrote:
>>>>>>> Why are there conflicts anyway?
>>>>>>
>>>>>> Oh...
>>>>>>
>>>>>> I guess there were conflicts when the merge commit was made in
>>>>>> the original repository, and these conflicts were resolved by
>>>>>> the merge commit itself. Hence, when rebase tries to split up
>>>>>> a merge by dealing with just the non-merge parents, you end up
>>>>>> having to deal with the conflict again.
>>>>>
>>>>> Yes, I thought it was something like this going on, too. In the
>>>>> pre-rebase history, when there is a commit with "Conflict:" and
>>>>> listing file which is in the sub-repository history, this is a
>>>>> point where rebase stops with a conflict.
>>>>>
>>>>>> Shouldn't rebase take this into account?
>>>>>
>>>>> Not sure. Seems that it does not, it makes me resolve the
>>>>> conflict
>>>>> =
>>>>> again.
>>>>
>>>> I think git rebase should take this into account is what I'm
>>>> saying.
>>>>
>>>> The following implements what I think `git rebase' should be
>>>> doing;
>>>> run it instead of `git rebase' in your repo:
>>>>
>>>> git branch saved
>>>> git rev-list HEAD --reverse --first-parent --parents |
>>>> {
>>>> read root
>>>> git reset --hard $root
>>>> rebase_head=$root
>>>>
>>>> while read commit first_parent other_parents; do
>>>>
>>>> if [ -z "$other_parents" ]; then
>>>>
>>>> git cherry-pick $commit
>>>> rebase_head=$commit
>>>>
>>>> else
>>>>
>>>> for parent in $other_parents; do
>>>>
>>>> if ! git cherry-pick $parent; then
>>>>
>>>> git reset --hard $rebase_head
>>>> git merge $other_parents
>>>> git rm -rf .
>>>> git checkout -- $commit
>>>> git commit -aC $commit
>>>> break
>>>>
>>>> fi
>>>>
>>>> done
>>>>
>>>> rebase_head=$(git rev-parse HEAD)
>>>>
>>>> fi
>>>>
>>>> done
>>>> }
>>>
>>> Woops!
>>>
>>> This line:
>>>
>>> git checkout -- $commit
>>>
>>> should be:
>>>
>>> git checkout $commit -- .
>>
>> I tried to run the script in my repo. However, seems like the
>> 'git
>> merge $other_parents' process fails. In the script output I see some
>> lines saying that files were not able to be merged, ie:
>>
>> warning: Cannot merge binary files:
>> scienceportal/images/tabs/tabs-gray.png (HEAD vs.
>> 84f6fc283861aa7c5798f58769789dd0b91a5e9d)
>> warning: Cannot merge binary files: scienceportal/images/waiting.gif
>> (HEAD vs. e033cbbf1e9d24b66cb55a04701c059dc945c1c3)
>>
>> Do you have some suggestion?
>
> That's probably as expected; the script is coming across the
> conflict, but
> it should be taking care of the conflict automatically.
>
> Unfortunately, though, the results probably end up being almost
> completely
> similar to the original un-rebased branch because the original script
> actually has ANOTHER mistake (sorry!). See the updated version here
> (or
> in your inbox):
>
> http://marc.info/?l=git&m=131246773005168&w=2
> Message-ID: <d62225a3cc5740cda7cb163a94d55892-mfwitten@gmail.com>
Thanks for taking a look at it again.
I tried to run the script with that update, but in the end I got more
merge messages than I had originally. (71 additional merges. From those
71, I got 53 "Merge commit" messages. While in the saved repo I have 1
"Merge commit".). Do you see what may be causing that?
Another thing I noticed is that the auto-merging is still failing:
fatal: Commit b0596fce207735081b8aa9afdd9686b7d412f5d8 is a merge but
no -m option was given.
HEAD is now at ac5eaa2 *Continue Last Commit*
Auto-merging scienceportal/css/myprofile.css
CONFLICT (content): Merge conflict in scienceportal/css/myprofile.css
Auto-merging scienceportal/css/qc.css
Automatic merge failed; fix conflicts and then commit the result.
scienceportal/css/myprofile.css: needs merge
rm 'scienceportal/css/des.css'
Looking at this thread:
http://www.mail-archive.com/git-users@googlegroups.com/msg01046.html
I thought that the attempt of removing the files was the step first
facing the conflicts as the one shown above. So that, I tried to iterate
through the files and in case the removal of any file failed, I added
the steps as suggested in the thread:
git checkout --theirs $file
git add $file
git commit -m 'Fixing conflict during rebase'
But that didn't work either.
I'd be greatly appreciated if you are still willing to help.
Thanks,
Patricia
^ permalink raw reply
* Re: [PATCH] fast-export: quote paths in output
From: Jeff King @ 2011-08-05 22:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, James Gregory
In-Reply-To: <4E3BD006.6010005@viscovery.net>
On Fri, Aug 05, 2011 at 01:12:06PM +0200, Johannes Sixt wrote:
> Am 8/5/2011 12:55, schrieb Jeff King:
> > +test_expect_success 'fast-export quotes pathnames' '
> > + git init crazy-paths &&
> > + (cd crazy-paths &&
> > + >"$(printf "path with\\nnewline")" &&
> > + >"path with \"quote\"" &&
> > + >"path with \\backslash" &&
> > + >"path with space" &&
>
> Please construct the tree object using git-update-index's --cacheinfo or
> --index-info rather than using actual files and git add so that the test
> can pass on filesystems that do not allow newlines, quotes, or
> backslashes(!) in filenames.
Sorry, I should have thought of that myself. Here's an updated version.
-- >8 --
Subject: [PATCH] fast-export: quote paths in output
Many pathnames in a fast-import stream need to be quoted. In
particular:
1. Pathnames at the end of an "M" or "D" line need quoting
if they contain a LF or start with double-quote.
2. Pathnames on a "C" or "R" line need quoting as above,
but also if they contain spaces.
For (1), we weren't quoting at all. For (2), we put
double-quotes around the paths to handle spaces, but ignored
the possibility that they would need further quoting.
This patch checks whether each pathname needs c-style
quoting, and uses it. This is slightly overkill for (1),
which doesn't actually need to quote many characters that
vanilla c-style quoting does. However, it shouldn't hurt, as
any implementation needs to be ready to handle quoted
strings anyway.
In addition to adding a test, we have to tweak a test which
blindly assumed that case (2) would always use
double-quotes, whether it needed to or not.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/fast-export.c | 31 ++++++++++++++++++++++++-------
t/t9350-fast-export.sh | 28 +++++++++++++++++++++++++++-
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index becef85..9836e6b 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -16,6 +16,7 @@
#include "string-list.h"
#include "utf8.h"
#include "parse-options.h"
+#include "quote.h"
static const char *fast_export_usage[] = {
"git fast-export [rev-list-opts]",
@@ -179,6 +180,15 @@ static int depth_first(const void *a_, const void *b_)
return (a->status == 'R') - (b->status == 'R');
}
+static void print_path(const char *path)
+{
+ int need_quote = quote_c_style(path, NULL, NULL, 0);
+ if (need_quote)
+ quote_c_style(path, NULL, stdout, 0);
+ else
+ printf("%s", path);
+}
+
static void show_filemodify(struct diff_queue_struct *q,
struct diff_options *options, void *data)
{
@@ -196,13 +206,18 @@ static void show_filemodify(struct diff_queue_struct *q,
switch (q->queue[i]->status) {
case DIFF_STATUS_DELETED:
- printf("D %s\n", spec->path);
+ printf("D ");
+ print_path(spec->path);
+ putchar('\n');
break;
case DIFF_STATUS_COPIED:
case DIFF_STATUS_RENAMED:
- printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
- ospec->path, spec->path);
+ printf("%c ", q->queue[i]->status);
+ print_path(ospec->path);
+ putchar(' ');
+ print_path(spec->path);
+ putchar('\n');
if (!hashcmp(ospec->sha1, spec->sha1) &&
ospec->mode == spec->mode)
@@ -217,13 +232,15 @@ static void show_filemodify(struct diff_queue_struct *q,
* output the SHA-1 verbatim.
*/
if (no_data || S_ISGITLINK(spec->mode))
- printf("M %06o %s %s\n", spec->mode,
- sha1_to_hex(spec->sha1), spec->path);
+ printf("M %06o %s ", spec->mode,
+ sha1_to_hex(spec->sha1));
else {
struct object *object = lookup_object(spec->sha1);
- printf("M %06o :%d %s\n", spec->mode,
- get_object_mark(object), spec->path);
+ printf("M %06o :%d ", spec->mode,
+ get_object_mark(object));
}
+ print_path(spec->path);
+ putchar('\n');
break;
default:
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index f823c05..950d0ff 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -228,7 +228,7 @@ test_expect_success 'fast-export -C -C | fast-import' '
mkdir new &&
git --git-dir=new/.git init &&
git fast-export -C -C --signed-tags=strip --all > output &&
- grep "^C \"file6\" \"file7\"\$" output &&
+ grep "^C file6 file7\$" output &&
cat output |
(cd new &&
git fast-import &&
@@ -414,4 +414,30 @@ test_expect_success SYMLINKS 'directory becomes symlink' '
(cd result && git show master:foo)
'
+test_expect_success 'fast-export quotes pathnames' '
+ git init crazy-paths &&
+ (cd crazy-paths &&
+ blob=`echo foo | git hash-object -w --stdin` &&
+ git update-index --add \
+ --cacheinfo 100644 $blob "$(printf "path with\\nnewline")" \
+ --cacheinfo 100644 $blob "path with \"quote\"" \
+ --cacheinfo 100644 $blob "path with \\backslash" \
+ --cacheinfo 100644 $blob "path with space" &&
+ git commit -m addition &&
+ git ls-files -z -s | perl -0pe "s{\\t}{$&subdir/}" >index &&
+ git read-tree --empty &&
+ git update-index -z --index-info <index &&
+ git commit -m rename &&
+ git read-tree --empty &&
+ git commit -m deletion &&
+ git fast-export HEAD >export.out &&
+ git rev-list HEAD >expect &&
+ git init result &&
+ cd result &&
+ git fast-import <../export.out &&
+ git rev-list HEAD >actual &&
+ test_cmp ../expect actual
+ )
+'
+
test_done
--
1.7.6.rc0.36.gd385b.dirty
^ permalink raw reply related
* Re: [PATCH] fast-export: quote paths in output
From: Junio C Hamano @ 2011-08-05 22:55 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git, James Gregory
In-Reply-To: <20110805223622.GA5808@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> + git read-tree --empty &&
Hmmmm, this adds more work to the backporting of this fix.
^ permalink raw reply
* [PATCH] git-send-email: Add AUTH LOGIN support
From: Joe Perches @ 2011-08-06 0:40 UTC (permalink / raw)
To: git
The current perl Net::SMTP support will not use AUTH LOGIN
when other authentication options are available.
Add an option to force the use of AUTH LOGIN when necessary.
(Like when using my current hosted email server, grumble)
Signed-off-by: Joe Perches <joe@perches.com>
---
Documentation/git-send-email.txt | 3 +++
git-send-email.perl | 19 +++++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 327233c..9595773 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -198,6 +198,9 @@ must be used for each option.
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
+--smtp-auth=<authorization_type>::
+ Force the smtp authentication to use a particular type.
+ Currently supported forced style is "login"
Automating
~~~~~~~~~~
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..37dfbe7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -28,6 +28,7 @@ use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
use Error qw(:try);
use Git;
+use MIME::Base64;
Getopt::Long::Configure qw/ pass_through /;
@@ -193,7 +194,7 @@ sub do_edit {
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
my ($to_cmd, $cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
-my ($smtp_authuser, $smtp_encryption);
+my ($smtp_authuser, $smtp_encryption, $smtp_auth);
my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
my ($validate, $confirm);
my (@suppress_cc);
@@ -218,6 +219,7 @@ my %config_settings = (
"smtpserveroption" => \@smtp_server_options,
"smtpuser" => \$smtp_authuser,
"smtppass" => \$smtp_authpass,
+ "smtpauth" => \$smtp_auth,
"smtpdomain" => \$smtp_domain,
"to" => \@initial_to,
"tocmd" => \$to_cmd,
@@ -293,6 +295,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-pass:s" => \$smtp_authpass,
"smtp-ssl" => sub { $smtp_encryption = 'ssl' },
"smtp-encryption=s" => \$smtp_encryption,
+ "smtp-auth=s" => \$smtp_auth,
"smtp-debug:i" => \$debug_net_smtp,
"smtp-domain:s" => \$smtp_domain,
"identity=s" => \$identity,
@@ -1111,7 +1114,19 @@ X-Mailer: git-send-email $gitversion
system "stty echo";
}
- $auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ if (defined $smtp_auth && $smtp_auth =~ /^login$/i) {
+
+ $smtp->datasend("AUTH LOGIN\n");
+ $smtp->response();
+ $smtp->datasend(encode_base64("$smtp_authuser"));
+ $smtp->response();
+ $smtp->datasend(encode_base64("$smtp_authpass"));
+ $smtp->response();
+
+ } else {
+
+ $auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ }
}
$smtp->mail( $raw_from ) or die $smtp->message;
--
1.7.6.131.g99019
^ permalink raw reply related
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: David Barr @ 2011-08-06 1:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Tay Ray Chuan, Sverre Rabbelier
In-Reply-To: <CALUzUxpn-vCWpTQyB7z9dsu8a+UBL9MPjEycOfTmyws5ndz5kA@mail.gmail.com>
Hi Jonathan,
> On Wed, Aug 3, 2011 at 6:20 AM, David Barr <davidbarr@google.com> wrote:
>> Some web-based email clients prepend whitespace to raw message
>> transcripts to workaround content-sniffing in some browsers.
>> Adjust the patch format detection logic to ignore leading
>> whitespace.
>>
>> Signed-off-by: David Barr <davidbarr@google.com>
>> diff --git a/git-am.sh b/git-am.sh
>> index 463c741..19b2f0f 100755
>> --- a/git-am.sh
>> +++ b/git-am.sh
>> @@ -199,7 +199,11 @@ check_patch_format () {
>> # otherwise, check the first few lines of the first patch to try
>> # to detect its format
>> {
>> - read l1
>> + # Start from first line containing non-whitespace
>> + until [ -n "$l1" ]
>> + do
>> + read l1
>> + done
>> read l2
>> read l3
>> case "$l1" in
On Wed, Aug 3, 2011 at 10:28 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Finally, patches from GMail that play nice with git-am!
>
> Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Do you see any subtle issues in this tiny patch?
I failed to include a test, I'll add at least one to the next version.
I did check that it doesn't break any of the existing git-am tests.
--
David Barr
^ permalink raw reply
* Re: [PATCH] fast-export: quote paths in output
From: Jeff King @ 2011-08-06 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, James Gregory
In-Reply-To: <7v4o1v31uw.fsf@alter.siamese.dyndns.org>
On Fri, Aug 05, 2011 at 03:55:19PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > + git read-tree --empty &&
>
> Hmmmm, this adds more work to the backporting of this fix.
We can easily replace it with "rm -f .git/index". Or we can be fancy and
actually tell update-index to drop the entries individually, but they
are somewhat of a pain to manipulate, given that they have magic
characters.
-Peff
^ permalink raw reply
* Re: [PATCH] misc-sh: fix up whitespace in some other .sh files.
From: Jon Seymour @ 2011-08-06 3:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxfn3h2v.fsf@alter.siamese.dyndns.org>
On Sat, Aug 6, 2011 at 3:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>> index 962a93b..0d399aa 100755
>> --- a/git-filter-branch.sh
>> +++ b/git-filter-branch.sh
>> @@ -98,11 +98,11 @@ set_ident () {
>> }
>>
>> USAGE="[--env-filter <command>] [--tree-filter <command>]
>> - [--index-filter <command>] [--parent-filter <command>]
>> - [--msg-filter <command>] [--commit-filter <command>]
>> - [--tag-name-filter <command>] [--subdirectory-filter <directory>]
>> - [--original <namespace>] [-d <directory>] [-f | --force]
>> - [<rev-list options>...]"
>> + [--index-filter <command>] [--parent-filter <command>]
>> + [--msg-filter <command>] [--commit-filter <command>]
>> + [--tag-name-filter <command>] [--subdirectory-filter <directory>]
>> + [--original <namespace>] [-d <directory>] [-f | --force]
>> + [<rev-list options>...]"
>>
>> OPTIONS_SPEC=
>> . git-sh-setup
>
> Everything other than this hunk is unquestionably fine. I think this one
> also is Ok but I wonder where the "Indented by 12 columns" comes
> from. "Usage: git filter-branch " that is prefixed to the first line is 25
> columns long, so the "[--index-filter ..." on the second line would not
> align with "[--env-filter ..." on the first line to begin with.
>
> And I do not think they need to align --- the point is if the second and
> subsequent lines do not aim to align with anything on the first line, it
> is just fine to indent them with a single HT, I think
>
I double checked the actual output (e.g. with git filter-branch --X) and
on the screen the output looks identical, although there is still whitespace
difference. So, I think it is ok.
jon.
^ permalink raw reply
* Re: [PATCH 0/2] bisect: cleanup formatting of git-bisect.sh
From: Jon Seymour @ 2011-08-06 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjpf3hvg.fsf@alter.siamese.dyndns.org>
On Sat, Aug 6, 2011 at 3:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> This series is intended to be applied on top js/bisect-no-checkout.
>
> Thanks; I wonder if we want to go a bit further.
>
> -- >8 --
> Subject: bisect: further style nitpicks
>
> Fix a few remaining lines that indented with spaces.
>
> Also simplify the logic of checking out the original branch and reporting
> error during "bisect reset".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> git-bisect.sh | 18 ++++++++----------
> 1 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 1f3c46d..22c4da5 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -94,9 +94,9 @@ bisect_start() {
> die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
> *)
> rev=$(git rev-parse -q --verify "$arg^{commit}") || {
> - test $has_double_dash -eq 1 &&
> - die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
> - break
> + test $has_double_dash -eq 1 &&
> + die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
> + break
> }
> case $bad_seen in
> 0) state='bad' ; bad_seen=1 ;;
> @@ -125,7 +125,7 @@ bisect_start() {
> start_head=$(cat "$GIT_DIR/BISECT_START")
> if test "z$mode" != "z--no-checkout"
> then
> - git checkout "$start_head" --
> + git checkout "$start_head" --
> fi
> else
> # Get rev from where we start.
> @@ -332,7 +332,7 @@ bisect_visualize() {
> if test $# = 0
> then
> if test -n "${DISPLAY+set}${SESSIONNAME+set}${MSYSTEM+set}${SECURITYSESSIONID+set}" &&
> - type gitk >/dev/null 2>&1
> + type gitk >/dev/null 2>&1
> then
> set gitk
> else
> @@ -364,13 +364,11 @@ bisect_reset() {
> *)
> usage ;;
> esac
> - if ! test -f "$GIT_DIR/BISECT_HEAD"
> +
> + if ! test -f "$GIT_DIR/BISECT_HEAD" && ! git checkout "$branch" --
> then
> - if ! git checkout "$branch" --
> - then
> - die "$(eval_gettext "Could not check out original HEAD '\$branch'.
> + die "$(eval_gettext "Could not check out original HEAD '\$branch'.
> Try 'git bisect reset <commit>'.")"
> - fi
> fi
> bisect_clean_state
> }
>
Looks good, thanks.
jon.
^ permalink raw reply
* [RFC] gettext: add gettextln, eval_gettextln to encode common idiom
From: Jon Seymour @ 2011-08-06 4:16 UTC (permalink / raw)
To: git; +Cc: avarab, Jon Seymour
Currently, if you want to use gettext or eval_gettext to format a message
you may have to add a separate echo statement and a surrounding subshell
in order to interpolate the required trailing new line.
This patch introduces two new helper functions, gettextln and eval_gettextln
which append a trailing newline to the gettext output.
This allows constructions of the form:
if test -s "$GIT_DIR/BISECT_START"
then
(
gettext "You need to give me at least one good and one bad revisions.
(You can use \"git bisect bad\" and \"git bisect good\" for that.)" &&
echo
) >&2
else
...
to be expressed more concisely as:
if test -s "$GIT_DIR/BISECT_START"
then
gettextln "You need to give me at least one good and one bad revisions.
+(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
else
...
An example of its use in git-bisect.sh is given.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 49 ++++++++++++++-----------------------------------
git-sh-i18n.sh | 19 +++++++++++++++++++
2 files changed, 33 insertions(+), 35 deletions(-)
This patch applies on top of Junio's "bisect: further style nitpicks" currently in kernel/pu.
FWIW, I am not attached to the suggested names. I can split the changes to git-sh-i18n.sh into a separate commit if there is agreement in principle to take the change.
diff --git a/git-bisect.sh b/git-bisect.sh
index 22c4da5..22c0e28 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -46,10 +46,7 @@ bisect_head()
bisect_autostart() {
test -s "$GIT_DIR/BISECT_START" || {
- (
- gettext "You need to start by \"git bisect start\"" &&
- echo
- ) >&2
+ gettextln "You need to start by \"git bisect start\"" >&2
if test -t 0
then
# TRANSLATORS: Make sure to include [Y] and [n] in your
@@ -268,10 +265,7 @@ bisect_next_check() {
t,,good)
# have bad but not good. we could bisect although
# this is less optimum.
- (
- gettext "Warning: bisecting only with a bad commit." &&
- echo
- ) >&2
+ gettextln "Warning: bisecting only with a bad commit." >&2
if test -t 0
then
# TRANSLATORS: Make sure to include [Y] and [n] in your
@@ -287,18 +281,12 @@ bisect_next_check() {
if test -s "$GIT_DIR/BISECT_START"
then
- (
- gettext "You need to give me at least one good and one bad revisions.
-(You can use \"git bisect bad\" and \"git bisect good\" for that.)" &&
- echo
- ) >&2
+ gettextln "You need to give me at least one good and one bad revisions.
+(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
else
- (
- gettext "You need to start by \"git bisect start\".
+ gettextln "You need to start by \"git bisect start\".
You then need to give me at least one good and one bad revisions.
-(You can use \"git bisect bad\" and \"git bisect good\" for that.)" &&
- echo
- ) >&2
+(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
fi
exit 1 ;;
esac
@@ -351,7 +339,7 @@ bisect_visualize() {
bisect_reset() {
test -s "$GIT_DIR/BISECT_START" || {
- gettext "We are not bisecting."; echo
+ gettextln "We are not bisecting."
return
}
case "$#" in
@@ -424,18 +412,15 @@ bisect_run () {
while true
do
command="$@"
- eval_gettext "running \$command"; echo
+ eval_gettextln "running \$command"
"$@"
res=$?
# Check for really bad run error.
if [ $res -lt 0 -o $res -ge 128 ]
then
- (
- eval_gettext "bisect run failed:
-exit code \$res from '\$command' is < 0 or >= 128" &&
- echo
- ) >&2
+ eval_gettextln "bisect run failed:
+exit code \$res from '\$command' is < 0 or >= 128" >&2
exit $res
fi
@@ -460,26 +445,20 @@ exit code \$res from '\$command' is < 0 or >= 128" &&
if sane_grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
> /dev/null
then
- (
- gettext "bisect run cannot continue any more" &&
- echo
- ) >&2
+ gettextln "bisect run cannot continue any more" >&2
exit $res
fi
if [ $res -ne 0 ]
then
- (
- eval_gettext "bisect run failed:
-'bisect_state \$state' exited with error code \$res" &&
- echo
- ) >&2
+ eval_gettextln "bisect run failed:
+'bisect_state \$state' exited with error code \$res" >&2
exit $res
fi
if sane_grep "is the first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null
then
- gettext "bisect run success"; echo
+ gettextln "bisect run success"
exit 0;
fi
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index 32ca59d..e672366 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -11,19 +11,38 @@ then
printf "%s" "$1"
}
+ gettextln() {
+ printf "%s\n" "$1"
+ }
+
eval_gettext () {
printf "%s" "$1" | (
export PATH $(git sh-i18n--envsubst --variables "$1");
git sh-i18n--envsubst "$1"
)
}
+
+ eval_gettextln () {
+ printf "%s\n" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
else
gettext () {
printf "%s" "# GETTEXT POISON #"
}
+ gettextln () {
+ printf "%s\n" "# GETTEXT POISON #"
+ }
+
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
+
+ eval_gettextln () {
+ printf "%s\n" "# GETTEXT POISON #"
+ }
fi
--
1.7.6.362.gf0e6
^ permalink raw reply related
* Re: [PATCH] git-send-email: Add AUTH LOGIN support
From: Junio C Hamano @ 2011-08-06 4:54 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <c1be0c3bd05779897fdc92907fe65d84c88ac72b.1312591104.git.joe@perches.com>
Joe Perches <joe@perches.com> writes:
> The current perl Net::SMTP support will not use AUTH LOGIN
> when other authentication options are available.
Even after reading this excuse,...
> + if (defined $smtp_auth && $smtp_auth =~ /^login$/i) {
> +
> + $smtp->datasend("AUTH LOGIN\n");
> + $smtp->response();
> + $smtp->datasend(encode_base64("$smtp_authuser"));
> + $smtp->response();
> + $smtp->datasend(encode_base64("$smtp_authpass"));
> + $smtp->response();
> +
> + } else {
> +
> + $auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
> + }
... this makes me feel dirty X-(. Not the desire to force "AUTH LOGIN",
but the implementation to hand-roll the protocol exchange.
I'd rather want to know _why_ Net::SMTP does not support it in the first
place, and what it does for "other authentication options" that are
available. Does it try them in turn until it finds the one that works? Why
doesn't it fall back on "AUTH LOGIN" then?
Specifically, if there is a reason to avoid this plaintext authentication
method when other options are _available_ (which presumably would be the
reason why Net::SMTP chooses not to support it), and if there is a reason
on the user's side to _force_ this method even when people who wrote
Net::SMTP does not recommend it be used, wouldn't it be natural to expect
that there should be a way to configure the connection to use it, without
resorting to coding the protocol exchange by hand line this?
It probably is not as simple as installing Authen::SASL::*::LOGIN, but
still...
^ permalink raw reply
* Re: [RFC] gettext: add gettextln, eval_gettextln to encode common idiom
From: Jon Seymour @ 2011-08-06 4:58 UTC (permalink / raw)
To: git; +Cc: avarab, Jon Seymour
In-Reply-To: <1312604164-19980-1-git-send-email-jon.seymour@gmail.com>
On Sat, Aug 6, 2011 at 2:16 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>
> An example of its use in git-bisect.sh is given.
>
Other scripts which could benefit from such a function are:
git-am.sh
git-pull.sh
git-quiltimport.sh
git-stash.sh
git-submodule.sh
jon.
^ permalink raw reply
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: Junio C Hamano @ 2011-08-06 5:00 UTC (permalink / raw)
To: David Barr
Cc: Jonathan Nieder, Git Mailing List, Tay Ray Chuan,
Sverre Rabbelier
In-Reply-To: <CAFfmPPMY5FP8NbZ5Q15pW-NC_qs=i6FY7v6Pi8jkMAhkURFTmQ@mail.gmail.com>
David Barr <davidbarr@google.com> writes:
> Hi Jonathan,
> ...
>>> diff --git a/git-am.sh b/git-am.sh
>>> index 463c741..19b2f0f 100755
>>> --- a/git-am.sh
>>> +++ b/git-am.sh
>>> @@ -199,7 +199,11 @@ check_patch_format () {
>>> # otherwise, check the first few lines of the first patch to try
>>> # to detect its format
>>> {
>>> - read l1
>>> + # Start from first line containing non-whitespace
>>> + until [ -n "$l1" ]
>>> + do
>>> + read l1
>>> + done
> ...
> Do you see any subtle issues in this tiny patch?
> I failed to include a test, I'll add at least one to the next version.
> I did check that it doesn't break any of the existing git-am tests.
It no longer checks "the first few lines" but can read a lot more, so the
comment that precedes this block is now invalid.
Also we are rather old fashioned and we never say "until [ ... ]" anywhere
in our shell scripts.
$ git grep -e until -- '*.sh'
Personally to me this is a borderline "Meh", in the sense that I wouldn't
bother to waste too much effort rejecting it, as I do not see downsides
other than these minor points.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add AUTH LOGIN support
From: Joe Perches @ 2011-08-06 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Graham Barr
In-Reply-To: <7vzkjn16n6.fsf@alter.siamese.dyndns.org>
On Fri, 2011-08-05 at 21:54 -0700, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
> > The current perl Net::SMTP support will not use AUTH LOGIN
> > when other authentication options are available.
> Even after reading this excuse,...
> > + if (defined $smtp_auth && $smtp_auth =~ /^login$/i) {
> > +
> > + $smtp->datasend("AUTH LOGIN\n");
> > + $smtp->response();
> > + $smtp->datasend(encode_base64("$smtp_authuser"));
> > + $smtp->response();
> > + $smtp->datasend(encode_base64("$smtp_authpass"));
> > + $smtp->response();
> > +
> > + } else {
> > +
> > + $auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
> > + }
> ... this makes me feel dirty X-(. Not the desire to force "AUTH LOGIN",
> but the implementation to hand-roll the protocol exchange.
> I'd rather want to know _why_ Net::SMTP does not support it in the first
> place, and what it does for "other authentication options" that are
> available. Does it try them in turn until it finds the one that works? Why
> doesn't it fall back on "AUTH LOGIN" then?
> Specifically, if there is a reason to avoid this plaintext authentication
> method when other options are _available_ (which presumably would be the
> reason why Net::SMTP chooses not to support it), and if there is a reason
> on the user's side to _force_ this method even when people who wrote
> Net::SMTP does not recommend it be used, wouldn't it be natural to expect
> that there should be a way to configure the connection to use it, without
> resorting to coding the protocol exchange by hand line this?
I needed something now.
You are right but I believe it would take too long
to get updates to Net::SMTP in place. Doing this
admitted ugliness in git-send-email works for me and
seems to me to be appropriate for now.
I looked, there isn't a method to force a particular
AUTH type documented. I also didn't care to rewrite
Net::SMTP right now. This "works for me"...
> It probably is not as simple as installing Authen::SASL::*::LOGIN, but
> still...
cheers, Joe
^ 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