* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
@ 2009-09-08 6:31 ` Nanako Shiraishi
2009-09-08 6:48 ` Junio C Hamano
2009-09-08 13:10 ` Jakub Narebski
` (6 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Nanako Shiraishi @ 2009-09-08 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Quoting Junio C Hamano <gitster@pobox.com>
> I tagged and pushed out 1.6.5-rc0. There are still some topics cooking in
> 'next' I would rather not leave out, but I've been hoping to keep this
> cycle short, and I'm also hoping to tag the real 1.6.5 before I vanish for
> about a week and half later in the month. so in the worst case there may
> have to be a 1.6.6 to include the leftover topics.
Are you coming to Japan to promote your book, perhaps giving autographs at bookstores?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 6:31 ` Nanako Shiraishi
@ 2009-09-08 6:48 ` Junio C Hamano
0 siblings, 0 replies; 24+ messages in thread
From: Junio C Hamano @ 2009-09-08 6:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> ... I'm also hoping to tag the real 1.6.5 before I vanish for
>> about a week and half later in the month....
>
> Are you coming to Japan to promote your book, perhaps giving autographs at bookstores?
It will come out around 19th if things go as planned, but I'll be arriving
the week after that so I'll be too late for that kind of thing.
Besides, who would want an autographed copy of a technical book?
I should start asking the usual suspect to take things over while I'm
offline...
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
2009-09-08 6:31 ` Nanako Shiraishi
@ 2009-09-08 13:10 ` Jakub Narebski
2009-09-08 13:17 ` Sverre Rabbelier
` (5 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Jakub Narebski @ 2009-09-08 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-show-size (2009-09-07) 1 commit
> - gitweb: Add 'show-sizes' feature to show blob sizes in tree view
This is an RFC, because of a) feature naming, and b) tests.
It does work correctly, though.
> * jn/gitweb-blame (2009-09-01) 5 commits
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-09-07 at 3622199)
I plan on reverting the order of those two patches, as JSMIN patch is
more ready than 'blame_incremental' linking.
With JSMIN there is perhaps question of documenting it, and whether
git-instaweb.sh should use minified JavaScript or not (curently it
does not). With 'blame_incremental' linking there are quite a few
issues:
1. When to do JavaScript detection
a. on load (current solution)
b. on click (via event handler)
2. How to invoke actions requiring JavaScript
a. add 'js=1' parameter (perhaps limiting URLs, as not to
add it e.g. to http://git-scm.com/ $home_link)
b. rewrite action parameter, e.g. from 'blame' to
'blame_incremental' (troubles with path_info URLs)
c. use cookies
Current solution works, but I think is suboptimal.
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame.
I'd very much like for others to check if it works with other browsers
(Internet Explorer 6, 7, 8; Opera 9, 10; Safari; Firefox 2, 3, 3.5)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
2009-09-08 6:31 ` Nanako Shiraishi
2009-09-08 13:10 ` Jakub Narebski
@ 2009-09-08 13:17 ` Sverre Rabbelier
2009-09-09 11:59 ` jk/1.7.0-status, was: " Jeff King
` (4 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Sverre Rabbelier @ 2009-09-08 13:17 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: git
Heya,
On Tue, Sep 8, 2009 at 02:56, Junio C Hamano<gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure.
Shawn, what's your opinion of v7? I think it handles pretty much
everything we need for at least a draft and is good for 1.6.5, but
it's up to you of course :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 24+ messages in thread* jk/1.7.0-status, was: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
` (2 preceding siblings ...)
2009-09-08 13:17 ` Sverre Rabbelier
@ 2009-09-09 11:59 ` Jeff King
2009-09-10 16:18 ` Daniel Barkalow
` (3 subsequent siblings)
7 siblings, 0 replies; 24+ messages in thread
From: Jeff King @ 2009-09-09 11:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:
> * jk/1.7.0-status (2009-09-05) 5 commits
> - docs: note that status configuration affects only long format
> (merged to 'next' on 2009-09-07 at 8a7c563)
> + commit: support alternate status formats
> + status: add --porcelain output format
> + status: refactor format option parsing
> + status: refactor short-mode printing to its own function
> (this branch uses jc/1.7.0-status.)
>
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
>
> It might be a good idea to make the --short format part of 1.6.6 without
> waiting for 1.7.0; it would require some branch shuffling to bring the
> short-status patch earlier than the one that makes "status" different from
> "commit --dry-run", though.
It looks like the short-status patch is already right before "commit
--dry-run", but it is of course part of "git stat". So we could get by
with branching from jc/1.7.0-status^, and do one of:
1. develop as if we were a totally separate topic, refactoring, adding
--porcelain mode, etc.
2. just support "--short" from "git status" with as small a change as
possible, and let the rest of the enhancements stay where they are,
for 1.7.0
Option (1) is what I would usually do, but I think in this case it is
just going to end up with me re-doing lots of work as the
almost-duplicated refactoring happening in the two branches is going to
make a gigantic conflict.
And of course option (3) is to just let --short rest until 1.7.0.
-Peff
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
` (3 preceding siblings ...)
2009-09-09 11:59 ` jk/1.7.0-status, was: " Jeff King
@ 2009-09-10 16:18 ` Daniel Barkalow
2009-09-10 16:53 ` Johannes Schindelin
2009-09-11 0:09 ` scissors definition and documentation Nicolas Sebrecht
` (2 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: Daniel Barkalow @ 2009-09-10 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, 7 Sep 2009, Junio C Hamano wrote:
> * db/vcs-helper (2009-09-03) 16 commits
> - Allow helpers to report in "list" command that the ref is unchanged
> - Add support for "import" helper command
> - Add a config option for remotes to specify a foreign vcs
> - Allow programs to not depend on remotes having urls
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Use a clearer style to issue commands to remote helpers
> - Make the "traditionally-supported" URLs a special case
> (merged to 'next' on 2009-08-07 at f3533ba)
> + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
> + Makefile: do not link three copies of git-remote-* programs
> + Makefile: git-http-fetch does not need expat
> (merged to 'next' on 2009-08-06 at 15da79d)
> + http-fetch: Fix Makefile dependancies
> + Add transport native helper executables to .gitignore
> (merged to 'next' on 2009-08-05 at 33d491e)
> + git-http-fetch: not a builtin
> + Use an external program to implement fetching with curl
> + Add support for external programs for handling native fetches
> (this branch is used by jh/cvs-helper.)
>
> I'd really want to have this in 1.6.5 so that we can eject -lcurl from the
> main "git" binary. The patches in 'pu' got some review comments, and I
> thought Daniel's responses were sensible. Comments?
I'm pretty sure that there were no objections to 'Make the
"traditonally-supported"...' patch, and directly after that is a
reasonable stopping point (everything that used to work works the same,
nothing new and user-visible is introduced, the implementation is
reasonably straightforward and tidy, and the git binary doesn't
link against -lcurl). I'd suggest putting everything up to that point into
master and debating the rest of the series on its own merits (and likely
deferring it to post-1.6.5, since it doesn't have an in-tree user to
exercise it yet).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-10 16:18 ` Daniel Barkalow
@ 2009-09-10 16:53 ` Johannes Schindelin
2009-09-10 17:55 ` Daniel Barkalow
2009-09-10 18:41 ` Junio C Hamano
0 siblings, 2 replies; 24+ messages in thread
From: Johannes Schindelin @ 2009-09-10 16:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
Hi,
On Thu, 10 Sep 2009, Daniel Barkalow wrote:
> I'm pretty sure that there were no objections to 'Make the
> "traditonally-supported"...' patch,
Well, there were. By me.
There is a reason why you call the series "foreign" vcs helpers. And
that's because it would be very wrong to pretend that they are the rule,
and the current URL schemes the exception. Very wrong, indeed.
Thankyouvermuch,
Dscho
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-10 16:53 ` Johannes Schindelin
@ 2009-09-10 17:55 ` Daniel Barkalow
2009-09-10 18:41 ` Junio C Hamano
1 sibling, 0 replies; 24+ messages in thread
From: Daniel Barkalow @ 2009-09-10 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On Thu, 10 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Sep 2009, Daniel Barkalow wrote:
>
> > I'm pretty sure that there were no objections to 'Make the
> > "traditonally-supported"...' patch,
>
> Well, there were. By me.
>
> There is a reason why you call the series "foreign" vcs helpers. And
> that's because it would be very wrong to pretend that they are the rule,
> and the current URL schemes the exception. Very wrong, indeed.
The current URL scheme *is* an "exception" to the "rule" that all remotes
are foreign, or the current "rule" that all remotes are ssh-style. Any
patterns that we currently support are handled by recognizing a particular
pattern (starts with "git://", starts with "rsync://", starts with
"https://", is a local file, is a local directory, etc), so they're all
special cases. They're further special cases by virtue of the fact that
the code to handle them is in the git distribution.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-10 16:53 ` Johannes Schindelin
2009-09-10 17:55 ` Daniel Barkalow
@ 2009-09-10 18:41 ` Junio C Hamano
1 sibling, 0 replies; 24+ messages in thread
From: Junio C Hamano @ 2009-09-10 18:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> There is a reason why you call the series "foreign" vcs helpers. And
> that's because it would be very wrong to pretend that they are the rule,
> and the current URL schemes the exception. Very wrong, indeed.
I do not know what you mean by "very wrong".
If the name bothers you, you can think of the earlier part of the series
cleaning up the transport code so that it makes easier to choose which
transport, either internal or external, and ports the native transport
support to use the mechanism. Then the rest of the series builds on it to
add further support for "foreign" vcs helpers.
^ permalink raw reply [flat|nested] 24+ messages in thread
* scissors definition and documentation
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
` (4 preceding siblings ...)
2009-09-10 16:18 ` Daniel Barkalow
@ 2009-09-11 0:09 ` Nicolas Sebrecht
2009-09-11 0:09 ` [PATCH 1/2] mailinfo: add '--scissors' to usage message Nicolas Sebrecht
2009-09-12 0:33 ` What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
7 siblings, 0 replies; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
The 07/09/09, Junio C Hamano wrote:
>
> * jc/mailinfo-scissors (2009-08-26) 5 commits
> (merged to 'next' on 2009-08-30 at 5fc6248)
> + mailinfo.scissors: new configuration
> + am/mailinfo: Disable scissors processing by default
> + Documentation: describe the scissors mark support of "git am"
> + Teach mailinfo to ignore everything before -- >8 -- mark
> + builtin-mailinfo.c: fix confusing internal API to mailinfo()
>
> I didn't pick up the patch to simplify the definition of scissors. I do
> not have strong opinion on it either way, and nobody on the list seemed to
> care too much either.
Since --scissors is an option instead of the default behaviour, I believe that
the definition of scissors is much less critical.
The following two patches is only about documentation.
The last patch mixes documentation of both mailinfo.scissors and --no--scissors
because I think they are very tied from the user POV.
[PATCH 1/2] mailinfo: add '--scissors' to usage message
[PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'
---
Documentation/git-am.txt | 2 +-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 1/2] mailinfo: add '--scissors' to usage message
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
` (5 preceding siblings ...)
2009-09-11 0:09 ` scissors definition and documentation Nicolas Sebrecht
@ 2009-09-11 0:09 ` Nicolas Sebrecht
2009-09-11 0:09 ` [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors' Nicolas Sebrecht
2009-09-12 0:33 ` What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
7 siblings, 1 reply; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
builtin-mailinfo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 03cbcad..7d22fd7 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] msg patch <mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 0:09 ` [PATCH 1/2] mailinfo: add '--scissors' to usage message Nicolas Sebrecht
@ 2009-09-11 0:09 ` Nicolas Sebrecht
2009-09-11 0:29 ` [PATCH v2] " Nicolas Sebrecht
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
Documentation/git-am.txt | 2 +-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..8b2897b 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors]
+ [--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+ enabled (see --scissors).
<msg>::
The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
c,scissors strip everything before a scissors line
+no-scissors don't obey to a scissors line (default)
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 0:09 ` [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors' Nicolas Sebrecht
@ 2009-09-11 0:29 ` Nicolas Sebrecht
2009-09-11 7:19 ` Junio C Hamano
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
I've missed the documentation of --no-scissors in git-am.txt in the previous
round (second hunks here).
Sorry for inconvenience.
Documentation/git-am.txt | 5 ++++-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..14ae3a5 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors]
+ [--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
@@ -44,6 +44,9 @@ OPTIONS
Remove everything in body before a scissors line (see
linkgit:git-mailinfo[1]).
+---no-scissors::
+ Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
+
-q::
--quiet::
Be quiet. Only print error messages.
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+ enabled (see --scissors).
<msg>::
The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
c,scissors strip everything before a scissors line
+no-scissors don't obey to a scissors line (default)
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
--
1.6.5.rc0.168.gdcd6e
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 0:29 ` [PATCH v2] " Nicolas Sebrecht
@ 2009-09-11 7:19 ` Junio C Hamano
2009-09-11 13:41 ` [PATCH v2] " Nicolas Sebrecht
[not found] ` <682ef47420f36d8c53e42981370d377b621d7b86.1252698215.git.nicolas.s.dev@gmx.fr>
0 siblings, 2 replies; 24+ messages in thread
From: Junio C Hamano @ 2009-09-11 7:19 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Junio C Hamano, Nanako Shiraishi, git
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> +---no-scissors::
> + Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
> +
obey is v.t. so "do not obey a scissors line" would be grammatical; I
think "ignore scissors lines" would be better.
> +--no-scissors::
> + Do not obey to a scissors line. This is only useful if mailinfo.scissors is
> + enabled (see --scissors).
Ditto; also it is useful in general if you do not know which way it is
configured. Saying "_only_" is misleading.
Ignore scissors lines; useful for overriding mailinfo.scissors
settings.
> diff --git a/git-am.sh b/git-am.sh
> index 26ffe70..f242d1a 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> u,utf8 recode into utf8 (default)
> k,keep pass -k flag to git-mailinfo
> c,scissors strip everything before a scissors line
> +no-scissors don't obey to a scissors line (default)
> whitespace= pass it through git-apply
> ignore-space-change pass it through git-apply
> ignore-whitespace pass it through git-apply
Do we want it to allow --no-no-scissors? I do not think this hunk is
necessary at all.
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 7:19 ` Junio C Hamano
@ 2009-09-11 13:41 ` Nicolas Sebrecht
2009-09-11 18:53 ` Junio C Hamano
[not found] ` <682ef47420f36d8c53e42981370d377b621d7b86.1252698215.git.nicolas.s.dev@gmx.fr>
1 sibling, 1 reply; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Nanako Shiraishi, git
[ Thank you for this review. ]
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> > diff --git a/git-am.sh b/git-am.sh
> > index 26ffe70..f242d1a 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> > u,utf8 recode into utf8 (default)
> > k,keep pass -k flag to git-mailinfo
> > c,scissors strip everything before a scissors line
> > +no-scissors don't obey to a scissors line (default)
> > whitespace= pass it through git-apply
> > ignore-space-change pass it through git-apply
> > ignore-whitespace pass it through git-apply
>
> Do we want it to allow --no-no-scissors? I do not think this hunk is
> necessary at all.
I don't understand your point here. This hunk doesn't allow
--no-no-scissors but add --no-scissors to usage of 'git am', no?
Do I miss something around $OPTIONS_SPEC?
--
Nicolas Sebrecht
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 13:41 ` [PATCH v2] " Nicolas Sebrecht
@ 2009-09-11 18:53 ` Junio C Hamano
2009-09-11 20:08 ` Nicolas Sebrecht
0 siblings, 1 reply; 24+ messages in thread
From: Junio C Hamano @ 2009-09-11 18:53 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, git
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> I don't understand your point here. This hunk doesn't allow
> --no-no-scissors but add --no-scissors to usage of 'git am', no?
>
> Do I miss something around $OPTIONS_SPEC?
You missed two thirds of the issue and I missed the other one third ;-)
As scissors is not marked with ! (see PARSEOPT section in the rev-parse
documentation), no-scissors is already available without that hunk, and
that is why your patch is unnecessary.
Your patch did not mark no-scissors with ! either, so it makes the call to
rev-parse --parseopt to process your OPTIONS_SPEC pass --no-no-scissors.
However, you did not add --no-no-scissors arm to the case statement that
processes rev-parse --parseopt output, so the command as the whole still
rejects --no-no-scissors as invalid (this is the last third I missed).
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 18:53 ` Junio C Hamano
@ 2009-09-11 20:08 ` Nicolas Sebrecht
2009-09-11 21:00 ` Junio C Hamano
0 siblings, 1 reply; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Nanako Shiraishi, git
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> As scissors is not marked with ! (see PARSEOPT section in the rev-parse
> documentation), no-scissors is already available without that hunk, and
> that is why your patch is unnecessary.
>
> Your patch did not mark no-scissors with ! either, so it makes the call to
> rev-parse --parseopt to process your OPTIONS_SPEC pass --no-no-scissors.
Ok. So, the fact that the usage of git-am doesn't tell about
--no-scissors is the expected behaviour?
Without changing the current implementation of rev-parse, I can't see a
smart way to add --no-scissors in the 'git am' usage. Yes, there's still
the possibility to negate both "c,scissors" and "no-scissors" but this
would defeate some of the PARSE_OPT_NONEG purpose, right?
Oh, and I still feel a bit disoriented by this "rev-parse --parseopt"
thing. I guess I need to read the code. :-)
--
Nicolas Sebrecht
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 20:08 ` Nicolas Sebrecht
@ 2009-09-11 21:00 ` Junio C Hamano
2009-09-12 3:03 ` Nicolas Sebrecht
0 siblings, 1 reply; 24+ messages in thread
From: Junio C Hamano @ 2009-09-11 21:00 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, git, Pierre Habouzit
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> Ok. So, the fact that the usage of git-am doesn't tell about
> --no-scissors is the expected behaviour?
You _could_ argue that we _could_ describe a long option "frotz" that
lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by
changing the rev-parse --parseopt, if you really want to.
However, I think that is not done deliberately to avoid cluttering the
output. I Cc'ed the primary guilty party ;-) of the parse-options
infrastructure.
Currently, non-bool options are not marked with '!'. Nobody sane would
say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such
a nonsense input, and it is up to the calling script to catch it and barf.
But "rev-parse --parseopt" will start saying "--[no-]directory=" with such
a change, which is not good.
And --no-scissors is not that special. We could add --no-signoff to say
"I do not want to sign-off this one time" explicitly, and it is crazy if
we had to add another line in OPTIONS_SPEC when we want to do so, when it
is clear "signoff" option is a boolean.
As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but
have that taken care of by "rev-parse --parseopt" to keep our sanity. The
only existing offender is "no-verify" in "rebase -i". Let's solve it (if
there is anything to solve, which I doubt) without adding new ones.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
2009-09-11 21:00 ` Junio C Hamano
@ 2009-09-12 3:03 ` Nicolas Sebrecht
0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-12 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Nanako Shiraishi, git, Pierre Habouzit
[ Thank you (again) for this very good explanation. ]
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> > Ok. So, the fact that the usage of git-am doesn't tell about
> > --no-scissors is the expected behaviour?
>
> You _could_ argue that we _could_ describe a long option "frotz" that
> lacks the '!' flag in OPTIONS_SPEC as "--[no-]frotz" in the output by
> changing the rev-parse --parseopt, if you really want to.
>
> However, I think that is not done deliberately to avoid cluttering the
> output. I Cc'ed the primary guilty party ;-) of the parse-options
> infrastructure.
Well, if it is expected to not have the "--[no-]frotz" in usage where
applicable I'll be fine with that (even if it may sounds a bit odd for a
sane user). Otherwise, I believe it could be a (small) improvement for
the UI.
> Currently, non-bool options are not marked with '!'. Nobody sane would
> say "git am --no-directory foo", but "rev-parse --parseopt" acccepts such
> a nonsense input, and it is up to the calling script to catch it and barf.
> But "rev-parse --parseopt" will start saying "--[no-]directory=" with such
> a change, which is not good.
>
> And --no-scissors is not that special. We could add --no-signoff to say
> "I do not want to sign-off this one time" explicitly, and it is crazy if
> we had to add another line in OPTIONS_SPEC when we want to do so, when it
> is clear "signoff" option is a boolean.
>
> As a long term direction, I'd rather not to see "no-" in OPTIONS_SPEC, but
> have that taken care of by "rev-parse --parseopt" to keep our sanity. The
> only existing offender is "no-verify" in "rebase -i". Let's solve it (if
> there is anything to solve, which I doubt) without adding new ones.
Now (with all this background in mind), I agree that the "no-" in
OPTIONS_SPEC looks ugly.
<If there were something to change>
As you say, we can't blindly rely on the "is a boolean" and "option name
begin with 'no-'" things altogether. Perhaps a new magic character
('-'?) beside the current flags of PARSEOPT could smartly do the trick?
</>
Pierre, opinion?
--
Nicolas Sebrecht
^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <682ef47420f36d8c53e42981370d377b621d7b86.1252698215.git.nicolas.s.dev@gmx.fr>]
* [PATCH v3 2/2] add documentation for mailinfo.scissors and '--no-scissors'
[not found] ` <682ef47420f36d8c53e42981370d377b621d7b86.1252698215.git.nicolas.s.dev@gmx.fr>
@ 2009-09-11 19:50 ` Nicolas Sebrecht
0 siblings, 0 replies; 24+ messages in thread
From: Nicolas Sebrecht @ 2009-09-11 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> > +---no-scissors::
> > + Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
> > +
>
> obey is v.t. so "do not obey a scissors line" would be grammatical; I
> think "ignore scissors lines" would be better.
>
> > +--no-scissors::
> > + Do not obey to a scissors line. This is only useful if mailinfo.scissors is
> > + enabled (see --scissors).
>
> Ditto; also it is useful in general if you do not know which way it is
> configured. Saying "_only_" is misleading.
>
> Ignore scissors lines; useful for overriding mailinfo.scissors
> settings.
>
> > diff --git a/git-am.sh b/git-am.sh
> > index 26ffe70..f242d1a 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> > u,utf8 recode into utf8 (default)
> > k,keep pass -k flag to git-mailinfo
> > c,scissors strip everything before a scissors line
> > +no-scissors don't obey to a scissors line (default)
> > whitespace= pass it through git-apply
> > ignore-space-change pass it through git-apply
> > ignore-whitespace pass it through git-apply
>
> Do we want it to allow --no-no-scissors? I do not think this hunk is
> necessary at all.
This version includes the above comments.
Thanks,
-- >8 --
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
Documentation/git-am.txt | 5 ++++-
Documentation/git-mailinfo.txt | 5 +++++
builtin-mailinfo.c | 2 +-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..06e6ea6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors]
+ [--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
@@ -44,6 +44,9 @@ OPTIONS
Remove everything in body before a scissors line (see
linkgit:git-mailinfo[1]).
+---no-scissors::
+ ignore scissors lines (see linkgit:git-mailinfo[1]).
+
-q::
--quiet::
Be quiet. Only print error messages.
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..d1f9cb8 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,11 @@ This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ ignore scissors lines; useful for overriding mailinfo.scissors settings.
<msg>::
The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
--
1.6.5.rc0.166.g46a82
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-08 0:56 What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
` (6 preceding siblings ...)
2009-09-11 0:09 ` [PATCH 1/2] mailinfo: add '--scissors' to usage message Nicolas Sebrecht
@ 2009-09-12 0:33 ` Junio C Hamano
2009-09-12 4:38 ` Junio C Hamano
2009-09-12 11:46 ` Sverre Rabbelier
7 siblings, 2 replies; 24+ messages in thread
From: Junio C Hamano @ 2009-09-12 0:33 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Sverre Rabbelier, Jeff King,
Johannes Schindelin, Daniel Barkalow, Jan Engelhardt,
Johan Herland, Linus Torvalds
This is an abbreviated preview of issue #03 for this month; the message
primarily covers potential 1.6.5 material and omits topics without much
urgency for the purpose of pushing 1.6.5-rc1 out.
--------------------------------------------------
[New Topics]
* jc/merge-saner-messages (2009-09-07) 1 commit
(merged to 'next' on 2009-09-11 at 4efab98)
+ merge-recursive: give less scary messages when merge did not start
I think this should be safe for 1.6.5.
* rc/maint-http-no-head-pack-check (2009-09-09) 1 commit.
- http.c: remove verification of remote packs
This is the response to infamous "github sometimes gives status 500
error for a HEAD request even when GET request for the same URL happily
serves the content error-free." problem.
I am hoping this is safe for 1.6.5, but will wait for a response to my
inquiry earlier.
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
The reroll was discussed on the list; unfortunately it did not quite apply
to any of my branches. I do not think this has to be in 1.6.5, but I just
want to get us unstuck if Johan was waiting for me to apply the current
series before making his next move.
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
It would be a good change for 1.6.5 when done properly, but this does not
honor --confirm=never but talks to the terminal. Nor it honors any
existing sendemail.confirm configuration settings.
--------------------------------------------------
[Cooking]
* db/vcs-helper (2009-09-03) 16 commits
- ...
(merged to 'next' on 2009-09-11 at a275aa3)
+ Use a clearer style to issue commands to remote helpers
+ Make the "traditionally-supported" URLs a special case
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
Up to the part that eject -lcurl from the main "git" binary cleanly are
now in 'next' and is ready for 1.6.5.
* cb/maint-1.6.3-grep-relative-up (2009-09-05) 2 commits.
(merged to 'next' on 2009-09-07 at f9b5b48)
+ grep: accept relative paths outside current working directory
+ grep: fix exit status if external_grep() punts
1.6.5 material.
* jk/unwanted-advices (2009-09-06) 2 commits
- status: make "how to stage" messages optional
- push: make non-fast-forward help message configurable
If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and
please let me know. At least the first one should be in 1.6.5, I think,
and probably both.
* jt/pushinsteadof (2009-09-07) 2 commits
(merged to 'next' on 2009-09-11 at cf3eb57)
+ Add url.<base>.pushInsteadOf: URL rewriting for push only
+ Wrap rewrite globals in a struct in preparation for adding another set
Probably 1.6.5 material.
* pk/fast-import-tars (2009-09-03) 1 commit
(merged to 'next' on 2009-09-07 at 8fbf027)
+ import-tars: Allow per-tar author and commit message.
* pk/fast-import-dirs (2009-09-03) 1 commit
(merged to 'next' on 2009-09-07 at 836cba2)
+ Add script for importing bits-and-pieces to Git.
I have to wonder if there are standard libraries to do this sort of thing
without having to hand-roll these logic every time, but I decided not to
be picky about contrib/ material. Both will be in 1.6.5
* jc/maint-1.6.0-blank-at-eof (2009-09-05) 10 commits.
(merged to 'next' on 2009-09-07 at 165dc3c)
Possibly a 1.6.5 material, but it started rather late in the cycle so we
might want to cook it for a while in 'next' and do 1.6.5 without it.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
Perhaps 1.6.5 material but I wasn't sure. I saw Sverre asking Shawn for
opinion but I may have missed the response.
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
- Prepare 'traverse_trees()' for D/F conflict lookahead
Beginning of the fix to a rather nasty longstanding issue of merging trees
with ("a" "a-b"), ("a/b" "a-b") and just ("a-b"), but my reading of it is
that it is just the first step to demonstrate one-entry lookahead and not
a full solution yet.
This is a good problem to tackle but the bug has been there from the
beginning of unpack_trees(), i.e. lacks urgency, and the full solution is
expected to be much larger. I am tempted to say that 1.6.5 shouldn't wait
for this series.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-12 0:33 ` What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
@ 2009-09-12 4:38 ` Junio C Hamano
2009-09-12 11:46 ` Sverre Rabbelier
1 sibling, 0 replies; 24+ messages in thread
From: Junio C Hamano @ 2009-09-12 4:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Jeff King,
Johannes Schindelin, Daniel Barkalow, Jan Engelhardt,
Johan Herland, Linus Torvalds
Junio C Hamano <gitster@pobox.com> writes:
> * jk/unwanted-advices (2009-09-06) 2 commits
> - status: make "how to stage" messages optional
> - push: make non-fast-forward help message configurable
>
> If I missed the v2 or later that uses 'advice.*" instead, I am sorry, and
> please let me know.
Found them; thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
2009-09-12 0:33 ` What's cooking in git.git (Sep 2009, #02; Mon, 07) Junio C Hamano
2009-09-12 4:38 ` Junio C Hamano
@ 2009-09-12 11:46 ` Sverre Rabbelier
1 sibling, 0 replies; 24+ messages in thread
From: Sverre Rabbelier @ 2009-09-12 11:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Shawn O. Pearce, Jeff King, Johannes Schindelin,
Daniel Barkalow, Jan Engelhardt, Johan Herland, Linus Torvalds
Heya,
On Sat, Sep 12, 2009 at 02:33, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure. I saw Sverre asking Shawn for
> opinion but I may have missed the response.
No response from Shawn so far, I assume he's short on Git budget :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 24+ messages in thread