* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Junio C Hamano @ 2006-05-09 21:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060510000826.1a708c03.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Better to support only -x=y or -x y, not both.
Didn't I just say -x=y where x is a single letter _is_ odd?
It is either -xy or -x y, not -x=y.
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Timo Hirvonen @ 2006-05-09 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, normalperson
In-Reply-To: <7vlktb2ayy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > I think optional arguments are still confusing. We could support both
> > -C (no args) and -C=20 syntax.
>
> Actually, optional numeric arguments are the norm not exception.
> Think of "diff -u" vs "diff -u20" for example. Also I think it
> is conventional not to use = for single-letter single-dash
> options, so -C (no args -- use the default number of the
> implementation whatever it is) and -C20 (the same behaviour in
> principle as -C, but use my number instead of the default) are
> sane, while -C=20 _is_ odd.
OK, if we don't support bundling flags at all then -x=y and -xy would do
the same thing and pickaxe's -Stext would work too. But we could not
make option flag parsing global then (-S=value -> search "=value" or
"value"?).
Maybe we should just change -Stext to -S=text or -S text.
Better to support only -x=y or -x y, not both.
> Having said that, I think abbreviating -u20 -n -r to -u20nr
> going too far
Yes
> (-nru20 would be palatable perhaps),
No :)
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Junio C Hamano @ 2006-05-09 20:35 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, Eric Wong
In-Reply-To: <20060509231031.b62576da.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> I think optional arguments are still confusing. We could support both
> -C (no args) and -C=20 syntax.
Actually, optional numeric arguments are the norm not exception.
Think of "diff -u" vs "diff -u20" for example. Also I think it
is conventional not to use = for single-letter single-dash
options, so -C (no args -- use the default number of the
implementation whatever it is) and -C20 (the same behaviour in
principle as -C, but use my number instead of the default) are
sane, while -C=20 _is_ odd.
Having said that, I think abbreviating -u20 -n -r to -u20nr
going too far (-nru20 would be palatable perhaps), even if the
implementation allows such, unless you are entering "obfusucated
command line parameters" contest.
^ permalink raw reply
* Re: [PATCH/RFC] gitopt - command-line parsing enhancements
From: Junio C Hamano @ 2006-05-09 20:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060509194825.GC3676@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
>> And scary, especially the "eat" macros are very scary.
>
> They look weird at first, but I think they help readability and
> maintainability once you get used to them. They let you focus on the
> important part of the function while hiding the boring parts from you.
> Quite elegant, imho.
Sorry, there is no elegance to it as far as I can see. A macro
invocation that creates a private function while it does not
look like a function definition is already bad, you cannot have
a comma in the stmt part, and the bare semicolons in the
parenthesised text look insane.
If your patch were like this, it would have been a bit easier
for me to understand what was going on during my first pass:
static struct exec_args *ui_optparse
(struct opt_spec *s, int ac, char **av, int *ac_p, int what)
{
struct exec_args *ea = one_arg(s, ac, av, ac_p);
if (!ea) return NULL;
switch (what) {
case IGNORE_MISSING:
not_new = 1; break;
case VERBOSE:
verbose = 1; break;
case HELP:
usage(update_index_usage); break;
}
return nil_exec_args(ea);
}
instead of
gitopt_eat(opt_ignore_missing, not_new = 1;)
gitopt_eat(opt_verbose, verbose = 1;)
gitopt_eat(opt_h, usage(update_index_usage);)
Then, you would give an extra element in the table, and your
argument parsing/splitting routine passes that one to the
handler function:
static const struct opt_spec update_index_ost[] = {
...
{ "ignore-missing", 0, 0, 0, ui_optparse, IGNORE_MISSING },
{ "verbose", 0, 0, 0, ui_optparse, VERBOSE },
{ "help", 'h', 0, 0, ui_optparse, HELP },
{ 0, 0 }
Another thing is I do not think we would want to make the
argument parsing into callback style interface like you did. It
actively encourages the option variables to be global (you could
make it file scoped static but they are global nevertheless).
If you can make it an iterator style, it would be a lot easier
to see what is going on, I suspect. Then you would not even
need the callback function pointers and small functions created
by magic eat() macros.
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605091215340.3718@g5.osdl.org>
On Tue, 9 May 2006 12:24:02 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> NOTE! This patch could be applied right now, and to all the branches (to
> make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing
> actually uses it.
>
> It just makes the syntax be
>
> [section<space>+"<randomstring>"]
>
> where the only rule for "randomstring" is that it can't contain a newline,
> and if you really want to insert a double-quote, you do it with \".
Lightly tested here. Looks good.
Sean
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Timo Hirvonen @ 2006-05-09 20:10 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060509191803.GA3676@localdomain>
Eric Wong <normalperson@yhbt.net> wrote:
> I'm striving for backwards compatibility with existing usage. That
> means as a diff option, -C alone works, as does -C20. I've made -C 20
> _not_ work because it breaks existing usage (where 20 could be a
> filename, or a tree-ish). -C=20 would mean something
> else,
I think optional arguments are still confusing. We could support both
-C (no args) and -C=20 syntax.
> since I wanted to make pickaxe work exactly as it did before:
> -S=var would search for '=var', not 'var'.
Some other options use -x=y syntax so this would be confusing. Pickaxe's
-Stext syntax is a bit strange. I think -S text or -S=text would be
more logical.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH/RFC] gitopt - command-line parsing enhancements
From: Eric Wong @ 2006-05-09 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmhr7fys.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Here's my take at a new command-line option parser to reduce wear on my
> > fingers. It handles both long and short options, permuting, automatic
> > abbreviations, required arguments, optional arguments, and bundling.
>
> Taken a superficial look at it.
>
> Sounds nice, might be a tad too ambitious though. Looks
> intrusive at places.
I wasn't overly happy with the addition of global variables to existing
files and the way they're set (setup_revisions). But at least they're
static. Of course, I'm not yet certain that I haven't introduced new
bugs. All the tests pass, at least...
> And scary, especially the "eat" macros are very scary.
They look weird at first, but I think they help readability and
maintainability once you get used to them. They let you focus on the
important part of the function while hiding the boring parts from you.
Quite elegant, imho.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Eric Wong @ 2006-05-09 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
In-Reply-To: <7v8xpb73sq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > Eric Wong <normalperson@yhbt.net> wrote:
> >
> >> * unbundling of short options: -uC20n20z => -u -C20 -n20 -z
> >
> > Does anyone ever use this? I think this makes sense only for flags that
> > don't have parameters but that would create an ugly special case. Is it
> > too hard to type "-u -C=20 -n=20 -z"?
>
> I can already hear in my head that people would start talking
> about "git understands insane abbeviations of options". It
> might be unambiguous, but that does not change it is a bit on
> the insane side. People would probably expect -nuz can be split
> into -n -u -z, and the current handcrafted mess (although it is
> more obvious and easy to work with when reading and maintaining
> the existing code) is not abbreviation friendly, which we would
> want to do something about. But I think squashing options with
> parameters together is going a bit too far.
I think numeric parameters are unambiguous when bundled.
I'm used to things like `diff -ru10p` working, *shrug*
Non-numeric parameters can only be used if the option is at the end of the
bundled string:
git commit -sam'this is my commit message' would work
git commit -m'say hello' would also work
but git commit -mas'this is my commit message' would not work as intended
(where user wanted -a -s, too)
> > --with-r => --patch-with-raw works great
>
> I personally think this also is too much.
There are (currently) two types of abbreviations, one is the prefix one used
commonly in shell scripts: -e|--e|--ed|--edi|--edit. I think this should
always be supported as most of our shell scripts already do.
The other one tokenizes on '-' first and looks for a prefix match after
each '-'. I'd like to make that at least optional:
diff --git a/gitopt.c b/gitopt.c
index 056e163..9ca6025 100644
--- a/gitopt.c
+++ b/gitopt.c
gitopt.c
@@ -427,7 +427,7 @@ static void fallback_long(const struct o
}
/* ok, try harder, based on tokenization on '-' */
- if (found < 0) {
+ if (found < 0 && getenv("GIT_ABBREV_HARDER")) {
for (i = 0; ost[i].l || ost[i].s; i++) {
s = &(ost[i]);
if (s->l && opt_token_match(s,cur)) {
--
Eric Wong
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzmhr3wje.fsf@assigned-by-dhcp.cox.net>
On Tue, 9 May 2006, Junio C Hamano wrote:
>
> If we are shooting for "let's not do this again", I do not think
> (4) without some quoting convention is good enough. Today, we
> are talking about branch names so we could give them artificial
> limits, which could be weaker than what we already have on the
> branch names, but we would later regret that, when we start
> wanting to have other names in the configuration (e.g. people's
> names).
Here's my suggestion as a patch.
NOTE! This patch could be applied right now, and to all the branches (to
make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing
actually uses it.
It just makes the syntax be
[section<space>+"<randomstring>"]
where the only rule for "randomstring" is that it can't contain a newline,
and if you really want to insert a double-quote, you do it with \".
It turns that into the section name "secion.randomstring".
So you could use this for things like
[email "torvalds@osdl.org"]
name = Linus Torvalds
if you wanted to do the "email->name" conversion as part of the config
file format (I'm not claiming that is sensible, I'm just giving it as an
insane example). That would show up as the association
email.torvalds@osdl.org.name -> Linus Torvalds
which is easy to parse (the "." in the email _looks_ ambiguous, but it
isn't: you know that there will always be a single key-name, so you find
the key name with "strrchr(name, '.')" and things are entirely
unambiguous).
Now, it doesn't do any repo-config stuff, since the whole point of this is
to make this a legal syntax, not actually start _using_ it yet. If people
think this is an acceptable syntax, then pls apply to everything, and
worry about usage later.
Linus
---
diff --git a/config.c b/config.c
index 0f518c9..f3b74e0 100644
--- a/config.c
+++ b/config.c
@@ -134,6 +134,41 @@ static int get_value(config_fn_t fn, cha
return fn(name, value);
}
+static int get_extended_base_var(char *name, int baselen, int c)
+{
+ do {
+ if (c == '\n')
+ return -1;
+ c = get_next_char();
+ } while (isspace(c));
+
+ /* We require the format to be '[base "extension"]' */
+ if (c != '"')
+ return -1;
+ name[baselen++] = '.';
+
+ for (;;) {
+ int c = get_next_char();
+ if (c == '\n')
+ return -1;
+ if (c == '"')
+ break;
+ if (c == '\\') {
+ c = get_next_char();
+ if (c == '\n')
+ return -1;
+ }
+ name[baselen++] = c;
+ if (baselen > MAXNAME / 2)
+ return -1;
+ }
+
+ /* Final ']' */
+ if (get_next_char() != ']')
+ return -1;
+ return baselen;
+}
+
static int get_base_var(char *name)
{
int baselen = 0;
@@ -144,6 +179,8 @@ static int get_base_var(char *name)
return -1;
if (c == ']')
return baselen;
+ if (isspace(c))
+ return get_extended_base_var(name, baselen, c);
if (!isalnum(c) && c != '.')
return -1;
if (baselen > MAXNAME / 2)
^ permalink raw reply related
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Eric Wong @ 2006-05-09 19:18 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060509120809.4d9494b9.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>
> > * unbundling of short options: -uC20n20z => -u -C20 -n20 -z
>
> Does anyone ever use this? I think this makes sense only for flags that
> don't have parameters but that would create an ugly special case. Is it
> too hard to type "-u -C=20 -n=20 -z"?
It is more for me. Many programs that I use already accept bundled
switches, and '=' and '-' are relatively far away and requires me
to stretch my hand uncomfortably (I have very small hands, and have
limited mobility in several fingers).
> > * optional argument handling (-C<num>, -M<num>)
> > -C <num> (with a space between them) has not changed,
> > however, <num> can be a sha1, or a path
>
> IMO optional arguments are usually bad idea.
>
> -C 2 (is "2" argument?)
> -C2 (-C=2 or -C -2?)
>
> Better to make it obvious there's an argument
>
> -C=2
>
> or not support optional arguments at all and "-C 2" becomes unambiguous.
git has always supported optional argument handling like this.
I'm striving for backwards compatibility with existing usage. That
means as a diff option, -C alone works, as does -C20. I've made -C 20
_not_ work because it breaks existing usage (where 20 could be a
filename, or a tree-ish). -C=20 would mean something
else, since I wanted to make pickaxe work exactly as it did before:
-S=var would search for '=var', not 'var'.
--
Eric Wong
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 18:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605091321350.7652@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, to summarize what people proposed (and that I remember):
>
> 1) [branch."AnY+String"]
>
> 2) multiple [branch]
>
> 3) magic <space>+<quoted>
>
> 4) [branch.just/allow-slashes/and-dashes]
>
> 5) the " for " notation
Thanks for a nice summary.
> Now, for the ease of use:
>
> (1), (3) and (4) are in the same league of easiness (except maybe that you
> have to keep in mind to extra-quote in shell scripts with (1) and (3)),
> (2) is especially good for people with a database mindset, and (5) is
> annoying as hell.
One thing you might want to consider is variable types and
default values (eh, that makes two).
When Linus first introduced the config mechanism, he made it so
that a loosely coupled set of programs can take the "Why should
I care about other programs configuration" attitude, and
actively encouraged to do so by allowing custom config parsers
inherit from the default parser, like the way git_diff_config()
falls back on git_default_config() when it does not recognize
the variable.
It is quite a good design for most uses, except that it made it
inconvenient to implement things like "git-repo-config -l" and
"git-var -l". The point of this design _is_ that they cannot
know what the set of possible variables, their types and the
default values when missing are, so by design the script that
used "git-var -l | grep" to read the configuration needed to
know that a boolean can be denoted by existence, value set to
zero or non-zero integer, or string "true"/"false" (i.e.
"filemode", "filemode=1", and "filemode = true" mean the same
thing; BTW I think we would probably want to add "yes"/"no"
here).
Later it was made easier to use by Pasky with "repo-config --type"
option. The caller supplies the name of the variable and the
type and repo-config gets the value -- the caller knows what it
wants to use, so having it to know what type of things it is
interested in is not so bad, so the type problem was practically
solved. But it still feels somewhat hacky.
With (2) and (5), we have a bound set of "se.ct.ion.variable";
we could enumerate the variables we care about, define what they
mean and what their types and default values are (we need to do
that for Documentation/config.txt anyway). With many parts of
the standalone git plumbing programs migrating into builtins, I
think it is not a bad idea to have a central table of all the
configuration variables that the core knows about. Porcelains
and scripts could define customized tables that describe the
sections/variables they also want to see and act on in the
configuration file, and call git-repo-config with that table as
an optional parameter.
> Now, for the ease of implementation:
>
> (1) and (3) are in the same league, they have to change the way the config
> is parsed as well as make downcasing conditional in repo-config. (2) is
> obviously hardest of all. (4) is very easy (one line in config.c), and (5)
> easiest (nothing to do).
>
> Now, for the versatility, i.e. what you can express with the syntax:
>...
> Obviously, I deem (4) the best solution ATM, because it has all the
> expressability needed, while being the simplest.
If we are shooting for "let's not do this again", I do not think
(4) without some quoting convention is good enough. Today, we
are talking about branch names so we could give them artificial
limits, which could be weaker than what we already have on the
branch names, but we would later regret that, when we start
wanting to have other names in the configuration (e.g. people's
names).
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-09 15:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0605091321350.7652@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 9 May 2006, Johannes Schindelin wrote:
>
> Okay, to summarize what people proposed (and that I remember):
>
> 1) [branch."AnY+String"]
If we really change the syntax, I would oppose the ".". I realize I may
have used it myself, and I think it would be good _internally_, but I
think the syntax would be
[branch "Any+String"]
which looks a lot more readable. Ie just a space (or, perhaps, "any
combination of spaces and tabs").
> 4) [branch.just/allow-slashes/and-dashes]
Same here. If we break old parsers anyway, the "." has no redeeming
value. You'd use it when _scripting_ stuff, but not anywhere else.
So in both cases, the above would turn into the _variable_ called
"branch.Any+String/and-dashes.<key>" internally, and things that used "git
repo-config" would say it that way, but the config file format should be
human-readable.
We already do that human-readability thing. We say
[core]
name = Linus Torvalds
email = random
but we turn it internally into
core.name -> "Linus Torvalds"
core.email -> "random"
and that's also the format you use for "git repo-config". Similarly,
having
[branch "master"]
remote = git://....
in the config file should - for exactly the same reasons - be turned
_internally_ into the association
branch.master.remote -> git://...
and for exactly the same reason you'd just use
git repo-config set branch.master.remote "git://..."
on the command line.
IOW, we _already_ do not match the internal and command line with the
actal human-readable syntax.
Linus
^ permalink raw reply
* Re: (patch) calloc->xaclloc in read-cache.c
From: Junio C Hamano @ 2006-05-09 13:26 UTC (permalink / raw)
To: iler.ml; +Cc: git
In-Reply-To: <0IZ000KI11YCKL10@mxout4.netvision.net.il>
iler.ml@gmail.com writes:
> How about this.
Looks good, thanks. If you needed some MUA trick that other
people might benefit from please feel free to send a patch to
Documentation/SubmittingPatches "MUA specific hints" section.
Except "Subject: [PATCH] blah", commit log message (in this case
what you would have on the Subject line is to the point and you
would not need any extra log message), "Signed-off-by: whom",
and perhaps "---\n". Material that you do not want to have in
the final commit message, like "How about this" and diffstat if
you have one, would come after the "---\n" line.
Your message formatted in the preferred way becomes like this:
Subject: [PATCH] read-cache.c: use xcalloc() not calloc()
Elsewhere we use xcalloc(); we should consistently do so.
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
---
* How about this?
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--- read-cache.c.000 2006-05-09 15:27:56.000000000 +0000
+++ read-cache.c 2006-05-09 15:28:10.000000000 +0000
@@ -552,7 +552,7 @@
active_nr = ntohl(hdr->hdr_entries);
...
^ permalink raw reply
* Re: (patch) calloc->xaclloc in read-cache.c
From: iler.ml @ 2006-05-09 16:14 UTC (permalink / raw)
To: git
How about this.
--- read-cache.c.000 2006-05-09 15:27:56.000000000 +0000
+++ read-cache.c 2006-05-09 15:28:10.000000000 +0000
@@ -552,7 +552,7 @@
active_nr = ntohl(hdr->hdr_entries);
active_alloc = alloc_nr(active_nr);
- active_cache = calloc(active_alloc, sizeof(struct cache_entry *));
+ active_cache = xcalloc(active_alloc, sizeof(struct cache_entry *));
offset = sizeof(*hdr);
for (i = 0; i < active_nr; i++) {
^ permalink raw reply
* Re: Unresolved issues #2
From: Nicolas Pitre @ 2006-05-09 13:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147174809.2794.12.camel@pmac.infradead.org>
On Tue, 9 May 2006, David Woodhouse wrote:
> I'm not sure about that. The payload is patches, isn't it? That's just
> text, too -- we aren't going to deal with diffs of binary content very
> well _anyway_, are we?
Yes we do. GIT now has its own email friendly binary patch format.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Junio C Hamano @ 2006-05-09 12:58 UTC (permalink / raw)
To: Timo Hirvonen, Eric Wong; +Cc: git
In-Reply-To: <20060509120809.4d9494b9.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Eric Wong <normalperson@yhbt.net> wrote:
>
>> * unbundling of short options: -uC20n20z => -u -C20 -n20 -z
>
> Does anyone ever use this? I think this makes sense only for flags that
> don't have parameters but that would create an ugly special case. Is it
> too hard to type "-u -C=20 -n=20 -z"?
I can already hear in my head that people would start talking
about "git understands insane abbeviations of options". It
might be unambiguous, but that does not change it is a bit on
the insane side. People would probably expect -nuz can be split
into -n -u -z, and the current handcrafted mess (although it is
more obvious and easy to work with when reading and maintaining
the existing code) is not abbreviation friendly, which we would
want to do something about. But I think squashing options with
parameters together is going a bit too far.
> --with-r => --patch-with-raw works great
I personally think this also is too much.
^ permalink raw reply
* Re: Unresolved issues #2
From: Bertrand Jacquin @ 2006-05-09 11:53 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1147174809.2794.12.camel@pmac.infradead.org>
On 5/9/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2006-05-04 at 01:15 -0700, Junio C Hamano wrote:
> >
> > * Message-ID:
> > <4fb292fa0604290630r19edd7ejf88642e33b350d1d@mail.gmail.com>
>
> > David Woodhouse did a patch to allow specifying charset on the
> > command line (and default to UTF-8) which is a move in the
> > right direction, but Bertrand's system seems to have trouble
> > with it.
>
> I thought Bertrand then confirmed that he was having trouble _before_
> applying my patch, too? His response when I asked it it appears without
> my patch was "[it] appear without in 1.3.1 and I can't seed mail with
> too. Also, 1.2.4 work fine here (without patch)."
Ok, to make short :
git-send-email 1.2.4 :
No EOF error on my smtp server.
git-send-email 1.3.1 :
EOF error on my smtp server.
I upgraded to 1.3.1 when I received patch from you, don't test 1.3.1
and then applied your patch, you test. And so test failed.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Unresolved issues #2
From: David Woodhouse @ 2006-05-09 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-05-04 at 01:15 -0700, Junio C Hamano wrote:
>
> * Message-ID:
> <4fb292fa0604290630r19edd7ejf88642e33b350d1d@mail.gmail.com>
> Content-type charset for send-email (Bertrand Jacquin)
>
> The output from format-patch by default is unmarked, which
> means the commit message part is UTF-8 (by strong convention),
> and the contents of the diff is whatever the contents of the
> file is encoded in.
Email without a Content-Type: header is supposed to be ASCII. If it
contains 8-bit characters, it's invalid. It'll be interpreted by
different systems in different ways -- not necessarily as UTF-8. Some
may even just reject it, on grounds of RFC non-compliance.
> David Woodhouse did a patch to allow specifying charset on the
> command line (and default to UTF-8) which is a move in the
> right direction, but Bertrand's system seems to have trouble
> with it.
I thought Bertrand then confirmed that he was having trouble _before_
applying my patch, too? His response when I asked it it appears without
my patch was "[it] appear without in 1.3.1 and I can't seed mail with
too. Also, 1.2.4 work fine here (without patch)."
> I think if we were to do this we probably need to teach
> format-patch to optionally do multi-part. We may not
> necessarily want to mark the payload to be in the same
> encoding as the commit message (not that git-apply cares -- to
> it, the payload is just 8-bit unencoded text, but we would
> want to protect it from getting mangled by e-mail transport).
I'm not sure about that. The payload is patches, isn't it? That's just
text, too -- we aren't going to deal with diffs of binary content very
well _anyway_, are we?
Obviously, there's nothing to stop people from storing binary blobs in
GIT, but unless you want to start sending actual _blobs_ as attachments
instead of sending patches, I think there's no need to play with MIME
multipart stuff.
I've no particular objection to it, but it's a separate issue to
Bertanrd's. That's a bug-fix, while multipart is an RFE without much
point, IMO.
--
dwmw2
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-09 11:34 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, sean, junkio, git
In-Reply-To: <20060509112641.GB3228@admingilde.org>
Hi,
On Tue, 9 May 2006, Martin Waitz wrote:
> So why is everybody trying to munch all branch related data into
> one .ini style config file?
>
> why not simply use the mechanisms we use elsewhere and build something
> like our remotes or the new HEAD file?
Because it is good to have one consistent tool to query/update what makes
up the configuration. Of course, we really could go about it like M$ who
invent a hundred an twenty three ways to do the same thing, all with their
own set of bugs.
I admit that repo-config has not been as stable as it could have been.
That was my fault, certainly. But with the help of the list, it has become
more stable.
Now, if we decide upon a totally different config format, okay, that's
what it takes. But please let's not have several different formats
*again*.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Martin Waitz @ 2006-05-09 11:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, junkio, git
In-Reply-To: <Pine.LNX.4.64.0605082007100.3718@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
hoi :)
On Mon, May 08, 2006 at 08:08:41PM -0700, Linus Torvalds wrote:
> > What's the advantage of section quotation marks over just allowing these
> > characters in regular section names? To be specific, what is wrong with:
> >
> > [jc/show-branch-dense]
>
> This would _suck_
>
> What if you have a branch called "core"? Not all all unlikely.
>
> Think about what a section like
>
> [core]
>
> really means.
>
> Plus I really want to not be case sensitive by default. Case sensitivity
> really is _not_ normal for this kind of config file syntax.
So why is everybody trying to munch all branch related data into
one .ini style config file?
why not simply use the mechanisms we use elsewhere and build something
like our remotes or the new HEAD file?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-09 11:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3p5om$djs$1@sea.gmane.org>
Hi,
On Tue, 9 May 2006, Jakub Narebski wrote:
> Linus Torvalds wrote:
>
> > I would suggest a much more readable format:
> >
> > [core]
> > ...
> >
> > [branch "core"]
> > ...
> >
> > [remote "core"]
> > ...
> >
> > and yes, enforce the <space>+<quoted name> format. We'd turn it internally
> > into some random internal string format (probably replacing the space with
> > a dot, and removing the quotes, so it would become "remote.core.<key>").
>
> I'm all for it. Nice compromise of [branch."miXedCaps"] and ["miXedCaps"],
> human readable end editable, and easy parsable.
Okay, to summarize what people proposed (and that I remember):
1) [branch."AnY+String"]
2) multiple [branch]
3) magic <space>+<quoted>
4) [branch.just/allow-slashes/and-dashes]
5) the " for " notation
Of all these, only (5) is backwards compatible, but it is also the only
one where you have to type the branch name over and over again.
However, the old gits do not really know what to do with the [branch]
section anyway, so you could consider (2) (and (4), if you do not have
branch names with slashes and/or dashes) backwards-compatible, because git
will continue to work -- ignoring the funny entries.
(1) and (3) definitely would make an old git choke.
Now, for the ease of use:
(1), (3) and (4) are in the same league of easiness (except maybe that you
have to keep in mind to extra-quote in shell scripts with (1) and (3)),
(2) is especially good for people with a database mindset, and (5) is
annoying as hell.
Now, for the ease of implementation:
(1) and (3) are in the same league, they have to change the way the config
is parsed as well as make downcasing conditional in repo-config. (2) is
obviously hardest of all. (4) is very easy (one line in config.c), and (5)
easiest (nothing to do).
Now, for the versatility, i.e. what you can express with the syntax:
The same for all (except for (4) which has very weak restrictions on the
branch name).
Oh, I completely forgot about another proposal: (6) subkeys (something
like "url[branchname] = blablabla"). It has about the same effects as (1)
or (3).
Another thing: I completely ignored the case sensitivity. Because it is
irrelevant. Why? Because you do not have two branches which are only
different by case-ness. It is confusing, and that's why. And you don't
need to handle the case specially, because the comparison is done by
downcasing anyway.
Obviously, I deem (4) the best solution ATM, because it has all the
expressability needed, while being the simplest.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Timo Hirvonen @ 2006-05-09 9:08 UTC (permalink / raw)
To: normalperson; +Cc: git
In-Reply-To: <11471512103526-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> * unbundling of short options: -uC20n20z => -u -C20 -n20 -z
Does anyone ever use this? I think this makes sense only for flags that
don't have parameters but that would create an ugly special case. Is it
too hard to type "-u -C=20 -n=20 -z"?
> * optional argument handling (-C<num>, -M<num>)
> -C <num> (with a space between them) has not changed,
> however, <num> can be a sha1, or a path
IMO optional arguments are usually bad idea.
-C 2 (is "2" argument?)
-C2 (-C=2 or -C -2?)
Better to make it obvious there's an argument
-C=2
or not support optional arguments at all and "-C 2" becomes unambiguous.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH/RFC] gitopt - command-line parsing enhancements
From: Junio C Hamano @ 2006-05-09 8:35 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1147151209168-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Here's my take at a new command-line option parser to reduce wear on my
> fingers. It handles both long and short options, permuting, automatic
> abbreviations, required arguments, optional arguments, and bundling.
Taken a superficial look at it.
Sounds nice, might be a tad too ambitious though. Looks
intrusive at places.
And scary, especially the "eat" macros are very scary.
I have to think about it a bit.
^ permalink raw reply
* [PATCH] apply: fix infinite loop with multiple patches with --index
From: Eric Wong @ 2006-05-09 8:08 UTC (permalink / raw)
To: junkio, git; +Cc: Eric Wong
When multiple patches are passed to git-apply, it will attempt
to open multiple file descriptors to an index, which means
multiple entries will be in the circular cache_file_list.
This change makes git-apply only open the index once and
write the index at exit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
apply.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
1d0b15a178abaf7ba61085f0acc70521bd71a961
diff --git a/apply.c b/apply.c
index 269210a..ca36391 100644
--- a/apply.c
+++ b/apply.c
@@ -19,6 +19,7 @@ #include "blob.h"
//
static const char *prefix;
static int prefix_length = -1;
+static int newfd = -1;
static int p_value = 1;
static int allow_binary_replacement = 0;
@@ -1873,7 +1874,6 @@ static int use_patch(struct patch *p)
static int apply_patch(int fd, const char *filename)
{
- int newfd;
unsigned long offset, size;
char *buffer = read_patch_file(fd, &size);
struct patch *list = NULL, **listp = &list;
@@ -1904,12 +1904,11 @@ static int apply_patch(int fd, const cha
size -= nr;
}
- newfd = -1;
if (whitespace_error && (new_whitespace == error_on_whitespace))
apply = 0;
write_index = check_index && apply;
- if (write_index)
+ if (write_index && newfd < 0)
newfd = hold_index_file_for_update(&cache_file, get_index_file());
if (check_index) {
if (read_cache() < 0)
@@ -1922,12 +1921,6 @@ static int apply_patch(int fd, const cha
if (apply)
write_out_results(list, skipped_patch);
- if (write_index) {
- if (write_cache(newfd, active_cache, active_nr) ||
- commit_index_file(&cache_file))
- die("Unable to write new cachefile");
- }
-
if (show_index_info)
show_index_list(list);
@@ -2085,5 +2078,12 @@ int main(int argc, char **argv)
whitespace_error == 1 ? "" : "s",
whitespace_error == 1 ? "s" : "");
}
+
+ if (write_index) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
+ die("Unable to write new cachefile");
+ }
+
return 0;
}
--
1.3.2.g45f7-dirty
^ permalink raw reply related
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-09 7:32 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0605081951390.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> But if you want to get it for any random merges, you can always just do
>
> git log -11 --pretty=oneline ^$commit^ $commit^@ |
> sed 's/[0-9a-f]* // ; 11 s/.*/\.\.\./'
>
> which will show up to the ten first commits that were merged (and turn the
> eleventh one, if it exists, into "..." - that's a pretty disgusting trick
> to make it show when you left things out).
>
> That "^$commit^ $commit^@" part is important. It may look like some
> deranged git smiley, but it does exactly what you want it to do: take all
> the parents of the commit, but ignore any commit reachable from the first
> one (the "mainline" of the person who did the commit).
>
> The ^@ syntax is obviously pretty new, so it requires a modern git.
It is indeed very quite new. Merged into "master" branch at the
beginning of this month.
I often wish we had a straightforward way to tell when a given
feature went into the mainline, not just appeared on a topic
branch. In this case, I said:
$ git whatchanged -p -S'"^@"' master -- revision.c
to find ea4a19 commit (Apr 30 00:54:29 2006 -0700). But that
was when the feature was first made on one of my topic branches,
which is not what I was looking for.
By looking at gitk, I can then tell 83262e (May 1 01:54:27)
merged it to "next", and 746437 (May 1 22:55:40) merged it to
"master".
In general this is an unsolvable question, because I can have a
topic branch forked off of the tip of "master", cook it for a
few days without advancing "master" at all, and merge it to
"master" after that. But such a merge will be a fast-forward.
^ 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