* Re: [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Junio C Hamano @ 2009-11-16 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091116160202.GB30777@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The "break" phase works by counting changes between two
> blobs with the same path. We do this by splitting the file
> into chunks (or lines for text oriented files) and then
> keeping a count of chunk hashes.
>
> The "rename" phase counts changes between blobs at two
> different paths. However, it uses the exact same set of
> chunk hashes (which are immutable for a given sha1).
>
> The rename phase can therefore use the same hash data as
> break. Unfortunately, we were throwing this data away after
> computing it in the break phase. This patch instead attaches
> it to the filespec and lets it live through the rename
> phase, working under the assumption that most of the time
> that breaks are being computed, renames will be too.
The change looks correct, but I initially got worried about your change
interacts badly with this part in estimate_similarity() around line 176:
if (!src->cnt_data && diff_populate_filespec(src, 0))
return 0;
if (!dst->cnt_data && diff_populate_filespec(dst, 0))
return 0;
I think the reason why it (not your patch but the original code) felt a
bit brittle is because the above if() statements know too much about the
internal of d-c-c (namely, it never looks at src->data when src->cnt_data
is already available, so it is safe to leave src->data NULL).
The same logic suggests that the loop to build the matrix in
diffcore_rename() could free two->data at the end of the innermost loop.
We currently loop this way (around ll. 505-530):
for each two (i.e. rename destination candidate):
for each one (i.e. rename source candidate):
compute and record how similar one and two are
free one->data
free two->data
After computing how similar "one" and something else is only once, we have
one->cnt_data so we won't need one->data (the same fact is exploited by
your patch for optimization), and that is why freeing one->data in the
innermost loop does not result in constant re-reading of the same blob
data when we iterate more than one rename destination. But the same logic
applies to "two" and we should be able to free the blob data early to
reduce the memory pressure.
I dunno if it would give us measurable performance benefit, though.
Here is the idea on top of your patch, but I think it can be applied
independently.
diffcore-rename.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 63ac998..875ca81 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -523,10 +523,13 @@ void diffcore_rename(struct diff_options *options)
this_src.dst = i;
this_src.src = j;
record_if_better(m, &this_src);
+ /*
+ * Once we run estimate_similarity,
+ * We do not need the text anymore.
+ */
diff_free_filespec_blob(one);
+ diff_free_filespec_blob(two);
}
- /* We do not need the text anymore */
- diff_free_filespec_blob(two);
dst_cnt++;
}
^ permalink raw reply related
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Johannes Schindelin @ 2009-11-16 21:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <7vpr7ip7ji.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 16 Nov 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 15 Nov 2009, Thomas Rast wrote:
> >
> >> Using the "ours" strategy with rebase just discards all changes,
> >> turning <branch> into <upstream> (or <newbase> if given). This is
> >> unlikely to be what the user wants, so simply refuse to do it.
>
> > Besides, I find it rather arbitrary that the "ours" strategy is
> > refused, but none of the user-provided merge strategies. IOW
> > disallowing "ours" may very well foster unreasonable expectations.
>
> I cannot read this quite clearly.
I meant the following: if "rebase -s ours" refuses to run, but my boss has
written this cunning merge strategy "superduper" which is equally unlikely
to yield a sensible result, "rebase -s superduper" should still refuse to
run, no?
Now, this scenario might be too rare to take care of, but maybe it shows
that we have a design flaw here?
Ciao,
Dscho
P.S.: Please note that I do not make a case against Thomas' patch series.
As gitzilla once said "I cannot provide alternative patches, so that's
that".
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Junio C Hamano @ 2009-11-16 21:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I meant the following: if "rebase -s ours" refuses to run, but my boss has
> written this cunning merge strategy "superduper" which is equally unlikely
> to yield a sensible result, "rebase -s superduper" should still refuse to
> run, no?
Why should it?
> Now, this scenario might be too rare to take care of, but maybe it shows
> that we have a design flaw here?
The decision is up to the user who is much more familiar with such a
custom 'superduper' strategy, and git itself is in no position to make
that decision for the user. It is none of our business to forbid users
from using what he wrote, when we do not know what it is.
I do not think the "rarity" is relevant.
What do you mean by a design flaw? In other words, how should things look
like in your ideal design?
Certainly you are not talking about a design that enforces users who want
to use custom strategy to first submit the strategy implementation to us
for a review and have our blessings (perhaps we digitally sign approved
strategy implementations) before being able to use it in "merge -s" and
"rebase -s".
I can _guess_ what you are _not_ talking about but I cannot tell what you
_are_ talking about; sorry.
^ permalink raw reply
* Manipulating existing revisions by push or pull?
From: Lasse Kliemann @ 2009-11-16 21:49 UTC (permalink / raw)
To: git
I've got a conceptual question.
I know that one can change history in a local repository with the
'rebase' command, e.g., using the interactive mode.
Is there any way to modify existing revisions in a local
repository by a pull (and merge, whatever) from a remote one? Or
is there any way to modify existing revisions in a remote
repository by a push (or whatever) from a local one?
Put a different way: consider there is a hostile entity from
which I pull or which I allow to push to me. Can this entity
fiddle with my history? Can it change the data in existing
revisions in my repository? Or can it only make new revisions
grow on my side?
Thank you
Lasse
^ permalink raw reply
* Re: Manipulating existing revisions by push or pull?
From: Junio C Hamano @ 2009-11-16 21:53 UTC (permalink / raw)
To: Lasse Kliemann; +Cc: git
In-Reply-To: <hdshcm$c06$1@ger.gmane.org>
"Lasse Kliemann" <lasse-gmane-git-2009@mail.plastictree.net> writes:
> Put a different way: consider there is a hostile entity from
> which I pull or which I allow to push to me. Can this entity
> fiddle with my history? Can it change the data in existing
> revisions in my repository? Or can it only make new revisions
> grow on my side?
If you allow your ref to get updated to an arbitrary value, you are lost,
unless you have signed tags that anchor things in place, in which case you
can trust the part of history that is reachable from them.
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Sverre Rabbelier @ 2009-11-16 22:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Thomas Rast, git, Nicolas Sebrecht, Baz,
Peter Krefting, Björn Steinbrink
In-Reply-To: <7viqdannxo.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 16, 2009 at 22:45, Junio C Hamano <gitster@pobox.com> wrote:
> I can _guess_ what you are _not_ talking about but I cannot tell what you
> _are_ talking about; sorry.
I would hazard a way for the merge strategy to indicate whether it is
fit to be used as rebase strategy?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* serf causing "temp file with moniker 'svn_delta' already in use"?
From: Blair Zajac @ 2009-11-16 21:55 UTC (permalink / raw)
To: git
I've seen some reports of the following error using git svn and encountered it
myself with git 1.6.5.2 with Subversion 1.6.5:
Temp file with moniker 'svn_delta' already in use at
/opt/local/lib/perl5/site_perl/5.8.9/Git.pm line 1022.
In Googling around I seen other people discussing the issue but with no real
root cause.
I'm guessing that it may be due to an API violation of the Subversion RA editors
when Serf is used:
http://subversion.tigris.org/issues/show_bug.cgi?id=2932
http://n2.nabble.com/git-svn-fails-to-fetch-repository-td2151475.html
I can generate the above error on demand with Serf but if I switch to Neon then
everything works fine. People may be using Serf because they compiled
Subversion with Serf and without Neon or instructed Subversion to use Serf
instead by this setting in their ~/.subversion/servers:
[global]
http-library = serf
I haven't looked at this issue beyond being able to reproduce it with Serf and
without Neon, but hope this gives some direction to the issue.
This bug may get fixed in Subversion as we want to move to Serf as the default
HTTP client away from Neon and this is one of the outstanding issues before
making that switch.
Regards,
Blair
^ permalink raw reply
* Re: Advice/help needed
From: Ian Hobson @ 2009-11-16 22:46 UTC (permalink / raw)
To: Yann Simon; +Cc: git
In-Reply-To: <551f769b0911160840k6ea274e9q33de777fac7cec70@mail.gmail.com>
Yann Simon wrote:
> 2009/11/16 Ian Hobson <ian@ianhobson.co.uk>:
>
>> My thoughts are to have 4 branches, one for each customer. 99% of all
>> changes will be needed by all (or at least most)
>> of the customers (P,W,S and E). How can I make a change to master and then
>> use git to apply those changes to the four branches, without losing the
>> differences between branches?
>>
>> For example (if this is the best way) go from this
>> O-----O-----A-----B-----C (master)
>> \----P
>> \---W
>> \--S
>> \-E
>>
>> to first this, where D is the net effect of A B and C (this is for ease of
>> reading logs, and commit messages),
>> O-----O-----D (head) \----P
>> \---W
>> \--S
>> \-E
>>
>> and then to this, (without editing all the files four times?)
>> O-----O-----D (head)
>> \----P-----D'
>> \---W----D''
>> \--S-----D'''
>> \-E-----D''''
>>
>
> What I would do is:
> - one branch for the common
> - one branch for each customer, which contains the specific
> differences compare to the common branch
>
> You could program on the common branch.
> When you are ready, you can checkout each specific branch and rebase
> on the common branch.
> For example:
> $ git checkout common
> edit, test, commit
> $ git checkout client1
> $ git rebase common
> $ git checkout client2
> $ git rebase common
>
>
Hi Yann,
I'll use master for common, unless I have a large chunk of development
to do, and see how it goes.
Many thanks.
Ian
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-16 22:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> My version is made a bit simpler by using strbuf for string
> manipulation in expand_user_path.
Nice to see people keeping track of issues that we tried to address but
didn't complete.
> I'm not sure I fully adressed Junio's point here:
We'll see ;-)
> I'm just copying back into the static buffer to let enter_repo() do
> the same string manipulation as it used to do (concatenate with .git
> suffixes). I think the whole enter_repo could use strbuf instead of
> static buffers, but that's a different point (probably made easier by
> my patch).
> diff --git a/config.c b/config.c
> index c644061..0fcc4ce 100644
> --- a/config.c
> +++ b/config.c
> @@ -351,6 +351,15 @@ int git_config_string(const char **dest, const char *var, const char *value)
> return 0;
> }
>
> +int git_config_pathname(const char **dest, const char *var, const char *value) {
> + if (!value)
> + return config_error_nonbool(var);
> + *dest = expand_user_path(value);
> + if (!*dest)
> + die("Failed to expand user dir in: '%s'", value);
> + return 0;
> +}
> +
> @@ -207,43 +208,49 @@ int validate_headref(const char *path)
> return -1;
> }
>
> -static char *user_path(char *buf, char *path, int sz)
> +static inline struct passwd *getpw_str(const char *username, size_t len)
> {
> + if (len == 0)
> + return getpwuid(getuid());
> +
> struct passwd *pw;
Decl-after-statement.
Do you need this special case of passing a zero-length string (not NULL
pointer as a string) to getpw_str() to grab the current user? Which
codepath is this needed?
> + char *username_z = xmalloc(len + 1);
> + memcpy(username_z, username, len);
> + username_z[len] = '\0';
> + pw = getpwnam(username_z);
> + free(username_z);
> + return pw;
> +}
> +/*
> + * Return a string with ~ and ~user expanded via getpw*. If buf != NULL, then
> + * it is a newly allocated string. Returns NULL on getpw failure or if
> + * path is NULL.
> + */
> +char *expand_user_path(const char *path)
> +{
> + struct strbuf user_path = STRBUF_INIT;
> + char * first_slash = strchrnul(path, '/');
> + char * to_copy;
Style: "char *first_slash"
Should't "to_copy" be initialized to "path" here? What do you copy when
path[0] is '/'?
> + if (path == NULL)
> + goto return_null;
> +
> + if (path[0] == '~') {
> + const char *username = path + 1;
> + size_t username_len = first_slash - username;
> + struct passwd *pw = getpw_str(username, username_len);
> + if (!pw)
> + goto return_null;
> + strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
> + to_copy = first_slash;
> + } else if (path[0] != '/') {
> + to_copy = path;
> }
> - return buf;
> + strbuf_add(&user_path, to_copy, strlen(to_copy));
> + return strbuf_detach(&user_path, NULL);
> +return_null:
> + strbuf_release(&user_path);
> + return NULL;
> }
> /*
> @@ -291,8 +298,17 @@ char *enter_repo(char *path, int strict)
> if (PATH_MAX <= len)
> return NULL;
> if (path[0] == '~') {
> - if (!user_path(used_path, path, PATH_MAX))
> + char *newpath = expand_user_path(path);
> + if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
> + if (path != newpath)
> + free(newpath);
Your expand_user_path() never returns the original, no?
> return NULL;
> + }
> + /* Copy back into the static buffer. A pity
> + since newpath was not bounded, but other
> + branches of the if are limited by PATH_MAX
> + anyway. */
> + strcpy(used_path, newpath); free(newpath);
> strcpy(validated_path, path);
> path = used_path;
> }
Heh, in a sense you _did_ address my point by punting, but that is Ok. As
you said earlier that would be a good topic of a separate patch.
/*
* By the way, we write our
* multi-line comments like
* this.
*/
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-16 22:52 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Michael J Gruber, Jonathan Nieder, Junio C Hamano, git,
J. Bruce Fields, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <20091114060600.6117@nanako3.lavabit.com>
On Fri, Nov 13, 2009 at 11:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Michael J Gruber <git@drmicha.warpmail.net>
>> If you care to go back to that discussion you see that there is good
>> reason for having both --cached and --index. They are different. "git
>> help cli" explains this nicely.
>
> The need to support both options in the same command (eg. apply) means
> that anybody who says "I don't like 'index' nor 'cache'; why don't we
> change them all to 'stage'" doesn't understand the issue.
>
> But that doesn't mean "apply --cached" vs "apply --index" is the best
> way to let the users specify which operation is requested. I don't
> think Felipe seriously wants to change them to --gogo vs --dance, but
> if he made a more constructive proposal, instead of making such a
> comment whose intended effect is only to annoy people, we may see
> an improved UI at the end. Proposing "--index-only" vs "--index-too"
> or even "--stage-only" vs "--stage-too" would have helped him appear
> to be more serious and constructive and I think your expression
> "mismatching participants" was a great way to say this.
Right, your explanation is more clear: the fact that we need both
doesn't mean we cannot use the term "stage". As to "constructive
proposal" I deliberately tried to avoid them in case somebody tried to
disregard it as bike-shedding, and move on. What I'm trying to do is
bring up the issue that the stage is not user friendly.
> There was a similar discussion about "diff --cached". The command
> compares two things and the current syntax relies on counting the
> number of treeish on the command line to specify what these two things
> are, and sometimes people are confused which way the comparison occurs.
>
> * If you have two treeish, it compares the two treeish. Specifically,
> it shows the change to make one treeish into the other treeish.
>
> * If you have one treeish, it compares the treeish with working tree
> or the index (it shows the change to make the treeish into working
> tree or the index). You need --cached to choose the "index", and
> this can safely be aliased to --staged.
>
> * If you have zero treeish, it compares the index with working tree
> (it shows the change to make the index into working tree).
>
> But it is also possible to have an alternate syntax to explicitly say
> what you are comparing with what. Perhaps these may make it unnecessary
> to remember which way the comparison occurs:
>
> git diff --tree-vs-staged HEAD
> same as "git diff --cached HEAD"
> git diff --staged-vs-tree HEAD
> same as "git diff -R --cached HEAD"
>
> git diff --staged-vs-working
> same as "git diff"
> git diff --working-vs-staged
> same as "git diff -R"
>
> git diff --tree-vs-working HEAD
> same as "git diff HEAD"
> git diff --working-vs-tree HEAD
> same as "git diff -R HEAD"
I like David Kågedal's suggestion more:
http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: A Large Angry SCM @ 2009-11-16 23:04 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Junio C Hamano, Thomas Rast,
Nicolas Sebrecht, Baz, Peter Krefting, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
[...]
> As gitzilla once said "I cannot provide alternative patches, so that's
> that".
I'm not sure I actually said that [*1*] but I did point out that when
there is an active discussion about which of multiple ways a feature can
be implemented, the party that produces code usually gets their way.
[*1*] There was beer involved and I was jet-lagged so maybe I did say
that when I meant what I wrote above.
^ permalink raw reply
* Re: git gc - out of memory
From: Alejandro Riveira @ 2009-11-16 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <df1390cc0911151033h2825053fxafe5bb2bb788fbb2@mail.gmail.com>
El Sun, 15 Nov 2009 19:33:27 +0100, Simon Strandgaard escribió:
>>
>> run « git repack -adf --window=memory » on the repo where memory is
>> escaled apropiately for your machine ?
>
> Thank you Alejandro, it now works!
ell glad it does becouse i mad a typo ...
>
> I think the default is 10, so I tried with window=5 and it completed a
> full repack.
I was trying to make you use --window-memory=[memory] not --window= ;P
>
>
> Now that it works..
> Should I report the original issue as a bug somewhere? e.g. malloc
> failed sounds like a bug.
This is the right place. Just wait for someone more knowledgeable than
me ...
>
>
>
> Kind regards
> Simon Strandgaard - http://gdtoolbox.com/
^ permalink raw reply
* Re: [PATCH] Document git-svn's first-parent rule
From: Eric Wong @ 2009-11-16 23:14 UTC (permalink / raw)
To: Junio C Hamano, Thomas Rast; +Cc: git
In-Reply-To: <ea845c8757a629d692bb6cd3827887f0e811c044.1258366486.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> git-svn has the following rule to detect the SVN base for its
> operations: find the first git-svn-id line reachable through
> first-parent ancestry. IOW,
>
> git log --grep=^git-svn-id: --first-parent -1
>
> Document this, as it is very important when using merges with git-svn.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Thanks Thomas,
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> Documentation/git-svn.txt | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 1812890..6da4151 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -735,6 +735,16 @@ merges you've made. Furthermore, if you merge or pull from a git branch
> that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
> branch.
>
> +If you do merge, note the following rule: 'git svn dcommit' will
> +attempt to commit on top of the SVN commit named in
> +------------------------------------------------------------------------
> +git log --grep=^git-svn-id: --first-parent -1
> +------------------------------------------------------------------------
> +You 'must' therefore ensure that the most recent commit of the branch
> +you want to dcommit to is the 'first' parent of the merge. Chaos will
> +ensue otherwise, especially if the first parent is an older commit on
> +the same SVN branch.
> +
> 'git clone' does not clone branches under the refs/remotes/ hierarchy or
> any 'git svn' metadata, or config. So repositories created and managed with
> using 'git svn' should use 'rsync' for cloning, if cloning is to be done
> --
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Junio C Hamano @ 2009-11-16 23:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Brian Collins, Jeff King
In-Reply-To: <20091116195050.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Brian Collins <bricollins@gmail.com>
>
>> You will have to excuse me, this is my first patch and I don't know if
>> this is the right place to post this. Apologies in advance if I'm in
>> the wrong place.
>>
>> git-grep currently throws an error when you combine the -F and -i
>> flags. This isn't in line with how GNU grep handles it. This patch
>> allows the simultaneous use of those flags.
>
> Junio, may I ask what happened to this patch?
We got sidetracked into a larger picture issues of how to allow platform
ports to selectively call out to external grep depending on the feature
set supported by the external grep implementations.
Later I looked at the original patch, the patch text looked fine (except
that I would have called the field "ignorecase", not "caseless"), but it
wasn't signed off and did not have usable log message.
And then I forgot ;-)
Thanks for a reminder, and thanks Jeff for a resend.
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jakub Narebski @ 2009-11-16 23:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> These config variables are parsed to substitute ~ and ~user with getpw
> entries.
>
> user_path() refactored into new function expand_user_path(), to allow
> dynamically allocating the return buffer.
>
> Original patch by Karl Chen, modified by Matthieu Moy.
>
> Signed-off-by: Karl Chen <quarl@quarl.org>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d1e2120..c37b51d 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
> core.excludesfile::
> In addition to '.gitignore' (per-directory) and
> '.git/info/exclude', git looks into this file for patterns
> - of files which are not meant to be tracked. See
> + of files which are not meant to be tracked. "~" and "~user"
> + are expanded to the user's home directory. See
> linkgit:gitignore[5].
>
> core.editor::
It would be nice to have an option to git-config which would do such
expansion, as a separate type similar to --int and --bool, e.g.:
git config --path section.key
so that not only core.excludesfile could use this new feature, but for
example also core.worktree, commit.template, gitcvs.logfile,
mailmap.file, and perhaps also *.receivepack and *.uploadpack
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Philippe Bruhat (BooK) @ 2009-11-16 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v639cqhh6.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 01:12:37AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Nov 10, 2009 at 11:46:51AM +0100, Philippe Bruhat (BooK) wrote:
> > (snip)
> > Will this work if I just have PERL_PATH in my config.mak in the root
> > directory? Should we be adding PERL_PATH to the generated
> > GIT-BUILD-OPTIONS file in the root, which gets sourced by test-lib?
> >
> > Something like the following (completely untested) patch?
>
> Philippe, could you please help getting this topic unstuck with a "it
> works" or "it doesn't and here is a better solution"?
>
I took Jeff's patch the main Makefile, removed my patch to test-lib.sh,
and it worked. That is to say, the test suite failed on the perl tests
when the first perl in the PATH was my local perl without Error.pm
installed. With the changes, the test suite passed, even with my local
perl first in the PATH.
Patch with a reworked commit message follows.
--
Philippe Bruhat (BooK)
The truly stupid always find a way to create disaster.
(Moral from Groo #10 (Image))
^ permalink raw reply
* [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Philippe Bruhat (BooK) @ 2009-11-16 23:53 UTC (permalink / raw)
To: git; +Cc: Philippe Bruhat (BooK)
In-Reply-To: <20091116234849.GA3608@plop>
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
---
Makefile | 1 +
t/t9400-git-cvsserver-server.sh | 2 +-
t/t9401-git-cvsserver-crlf.sh | 2 +-
t/t9700-perl-git.sh | 4 ++--
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 35f5294..8e8f981 100644
--- a/Makefile
+++ b/Makefile
@@ -1633,6 +1633,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# and the first level quoting from the shell that runs "echo".
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
+ @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 64f947d..dc710f8 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -20,7 +20,7 @@ then
say 'skipping git-cvsserver tests, cvs not found'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index aca40c1..c9e3dba 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -57,7 +57,7 @@ then
say 'skipping git-cvsserver tests, perl not available'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 4eb7d3f..3354e18 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -11,7 +11,7 @@ if ! test_have_prereq PERL; then
test_done
fi
-perl -MTest::More -e 0 2>/dev/null || {
+$PERL_PATH -MTest::More -e 0 2>/dev/null || {
say "Perl Test::More unavailable, skipping test"
test_done
}
@@ -48,6 +48,6 @@ test_expect_success \
test_external_without_stderr \
'Perl API' \
- perl "$TEST_DIRECTORY"/t9700/test.pl
+ $PERL_PATH "$TEST_DIRECTORY"/t9700/test.pl
test_done
--
1.6.0.3.517.g759a
^ permalink raw reply related
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Junio C Hamano @ 2009-11-17 0:06 UTC (permalink / raw)
To: Brian Collins, Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vocn2m48d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We got sidetracked into a larger picture issues of how to allow platform
> ports to selectively call out to external grep depending on the feature
> set supported by the external grep implementations.
>
> Later I looked at the original patch, the patch text looked fine (except
> that I would have called the field "ignorecase", not "caseless"), but it
> wasn't signed off and did not have usable log message.
>
> And then I forgot ;-)
>
> Thanks for a reminder, and thanks Jeff for a resend.
By the way, I would suggest updating the test like the attached.
By looking for rEtUrN, you will catch a bug that breaks "-i"-ness
of the grep, but your test does not catch breakages in "-F"-ness.
I am also tempted to add --no-ext-grep to this test, but that would be a
separate fix when it becomes necessary, I guess.
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index 87b47dd..35a1e7a 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -14,6 +14,7 @@ int main(int argc, const char **argv)
{
printf("Hello world.\n");
return 0;
+ /* char ?? */
}
EOF
@@ -346,11 +347,11 @@ test_expect_success 'grep from a subdirectory to search wider area (2)' '
'
cat >expected <<EOF
-hello.c: return 0;
+hello.c:int main(int argc, const char **argv)
EOF
test_expect_success 'grep -Fi' '
- git grep -Fi rEtUrN >actual &&
+ git grep -Fi "CHAR *" >actual &&
test_cmp expected actual
'
^ permalink raw reply related
* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Junio C Hamano @ 2009-11-17 0:10 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <1258415600-4656-1-git-send-email-book@cpan.org>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
> diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
> index 64f947d..dc710f8 100755
> --- a/t/t9400-git-cvsserver-server.sh
> +++ b/t/t9400-git-cvsserver-server.sh
> @@ -20,7 +20,7 @@ then
> say 'skipping git-cvsserver tests, cvs not found'
> test_done
> fi
> -perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> +$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
> test_done
> }
Shouldn't these $PERL_PATH all be quoted inside double-quotes?
^ permalink raw reply
* Re: git multisite setup
From: Nicolas Sebrecht @ 2009-11-17 0:13 UTC (permalink / raw)
To: Matt Di Pasquale; +Cc: git, Nicolas Sebrecht
In-Reply-To: <13f0168a0911161018r6fc67d29n781cca670a66815b@mail.gmail.com>
The 16/11/09, Matt Di Pasquale wrote:
> In my sites folder i have folders for different sites of mine:
> example.com example2.com, and i also have generic files like an
> includes dir and a .htaccess file that all sites use. what is the best
> way to track the generic files and the different sites?
>
> i was thinking each site has its own .git repo. and then make a .git
> repo for my sites folder but ignore the individual sites dirs.
> actually that's what i'm doing now.
This looks good to me. Why would you like to change?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Philippe Bruhat (BooK) @ 2009-11-17 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philippe Bruhat (BooK), git
In-Reply-To: <7v1vjym2oq.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 04:10:13PM -0800, Junio C Hamano wrote:
> "Philippe Bruhat (BooK)" <book@cpan.org> writes:
>
> > diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
> > index 64f947d..dc710f8 100755
> > --- a/t/t9400-git-cvsserver-server.sh
> > +++ b/t/t9400-git-cvsserver-server.sh
> > @@ -20,7 +20,7 @@ then
> > say 'skipping git-cvsserver tests, cvs not found'
> > test_done
> > fi
> > -perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> > +$PERL_PATH -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> > say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
> > test_done
> > }
>
> Shouldn't these $PERL_PATH all be quoted inside double-quotes?
I have no idea. I assume it's to protect against paths with a space in
them, so yes, probably.
Amending my patch and sending again.
--
Philippe Bruhat (BooK)
When you double-cross a friend, you triple-cross yourself.
(Moral from Groo The Wanderer #8 (Epic))
^ permalink raw reply
* Re: git multisite setup
From: Matt Di Pasquale @ 2009-11-17 0:17 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20091117001320.GA13074@vidovic>
yeah. i guess it's fine. :) just that the specific git repos aren't
coordinated to the generic one. but that's fine so far since i haven't
had to jump around to different commits and the generic has stayed
pretty much the same.
On Mon, Nov 16, 2009 at 7:13 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> The 16/11/09, Matt Di Pasquale wrote:
>
>> In my sites folder i have folders for different sites of mine:
>> example.com example2.com, and i also have generic files like an
>> includes dir and a .htaccess file that all sites use. what is the best
>> way to track the generic files and the different sites?
>>
>> i was thinking each site has its own .git repo. and then make a .git
>> repo for my sites folder but ignore the individual sites dirs.
>> actually that's what i'm doing now.
>
> This looks good to me. Why would you like to change?
>
> --
> Nicolas Sebrecht
>
^ permalink raw reply
* [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Philippe Bruhat (BooK) @ 2009-11-17 0:20 UTC (permalink / raw)
To: git; +Cc: Philippe Bruhat (BooK)
In-Reply-To: <7v1vjym2oq.fsf@alter.siamese.dyndns.org>
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
---
Makefile | 1 +
t/t9400-git-cvsserver-server.sh | 2 +-
t/t9401-git-cvsserver-crlf.sh | 2 +-
t/t9700-perl-git.sh | 4 ++--
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 35f5294..8e8f981 100644
--- a/Makefile
+++ b/Makefile
@@ -1633,6 +1633,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# and the first level quoting from the shell that runs "echo".
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
+ @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 64f947d..c2ec3cb 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -20,7 +20,7 @@ then
say 'skipping git-cvsserver tests, cvs not found'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index aca40c1..40637d6 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -57,7 +57,7 @@ then
say 'skipping git-cvsserver tests, perl not available'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 4eb7d3f..96a2e55 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -11,7 +11,7 @@ if ! test_have_prereq PERL; then
test_done
fi
-perl -MTest::More -e 0 2>/dev/null || {
+"$PERL_PATH" -MTest::More -e 0 2>/dev/null || {
say "Perl Test::More unavailable, skipping test"
test_done
}
@@ -48,6 +48,6 @@ test_expect_success \
test_external_without_stderr \
'Perl API' \
- perl "$TEST_DIRECTORY"/t9700/test.pl
+ $PERL_PATH "$TEST_DIRECTORY"/t9700/test.pl
test_done
--
1.6.0.3.517.g759a
^ permalink raw reply related
* Re: git multisite setup
From: Nicolas Sebrecht @ 2009-11-17 0:50 UTC (permalink / raw)
To: Matt Di Pasquale; +Cc: Nicolas Sebrecht, git
In-Reply-To: <13f0168a0911161617o56757488n45328714fb1d3bea@mail.gmail.com>
[ Please, don't top-post nor whole quote. ]
The 16/11/09, Matt Di Pasquale wrote:
> the specific git repos aren't
> coordinated to the generic one. but that's fine so far since i haven't
> had to jump around to different commits and the generic has stayed
> pretty much the same.
I'm not sure to understand exactly what kind of coordination you expect
exactly (because you don't describe what you'd like that much), but
submodule could be what you need, yes.
FMHO, the best way to check if you need it is to try it. For a good
start, I guess you'll need to change your approach on "what depends of
what". I think you should consider the _common_ part to be the
_dependency_; as a consequence, it should be the submodule used in the
other repositories. AFAIR, submodule was originaly designed to make our
life easier with libraries. It may fit to your needs too but again, the
best thing to do is to try.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH RFC v2] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-17 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This is a resend -- v1 had line wrap issues. Sorry for the noise.
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage string arrays have been created for each subcommand.
Does this look like a sane way to structure the code?
builtin-remote.c | 57 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..ec65a4b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [-v | --verbose]"
+#define REMOTE_ADD_USAGE "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
+#define REMOTE_SHOW_USAGE "git remote show [-n] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [-n | --dry-run] <name>"
+#define REMOTE_UPDATE_USAGE "git remote [-v | --verbose] update [-p | --prune] [group]"
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = { REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = { REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = { REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = { REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = { REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = { REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = { REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -984,7 +1000,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1088,7 +1104,7 @@ static int set_head(int argc, const char **argv)
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1130,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1154,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1243,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1348,6 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
OPT_END()
};
int result;
-- 1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
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