* [PATCH 3/3] apply: use OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <4E835CFE.7020501@lsrfire.ath.cx>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/apply.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index f2edc52..872e40a 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3831,7 +3831,6 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)
int i;
int errs = 0;
int is_not_gitdir = !startup_info->have_repository;
- int binary;
int force_apply = 0;
const char *whitespace_option = NULL;
@@ -3850,12 +3849,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)
"ignore additions made by the patch"),
OPT_BOOLEAN(0, "stat", &diffstat,
"instead of applying the patch, output diffstat for the input"),
- { OPTION_BOOLEAN, 0, "allow-binary-replacement", &binary,
- NULL, "old option, now no-op",
- PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
- { OPTION_BOOLEAN, 0, "binary", &binary,
- NULL, "old option, now no-op",
- PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
+ OPT_NOOP_NOARG(0, "allow-binary-replacement"),
+ OPT_NOOP_NOARG(0, "binary"),
OPT_BOOLEAN(0, "numstat", &numstat,
"shows number of added and deleted lines in decimal notation"),
OPT_BOOLEAN(0, "summary", &summary,
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH 2/3] revert: use OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <4E835CFE.7020501@lsrfire.ath.cx>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/revert.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 3117776..db5b1d4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -72,12 +72,10 @@ static int option_parse_x(const struct option *opt,
static void parse_args(int argc, const char **argv)
{
const char * const * usage_str = revert_or_cherry_pick_usage();
- int noop;
struct option options[] = {
OPT_BOOLEAN('n', "no-commit", &no_commit, "don't automatically commit"),
OPT_BOOLEAN('e', "edit", &edit, "edit the commit message"),
- { OPTION_BOOLEAN, 'r', NULL, &noop, NULL, "no-op (backward compatibility)",
- PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 0 },
+ OPT_NOOP_NOARG('r', NULL),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_INTEGER('m', "mainline", &mainline, "parent number"),
OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
--
1.7.7.rc2
^ permalink raw reply related
* Re: SVN -> Git *but* with special changes
From: Matthieu Moy @ 2011-09-28 17:44 UTC (permalink / raw)
To: Stephen Bash; +Cc: Abscissa, git
In-Reply-To: <16808473.33899.1317229852319.JavaMail.root@mail.hq.genarts.com>
Stephen Bash <bash@genarts.com> writes:
>> 2. Keeping binary files in version control isn't a big deal because
>> the whole repo doesn't get copied to everyone's system or use up
>> people's GitHub storage space.
>
> I'd eliminate these on the SVN side before converting to Git. If you
> have svnadmin access to the SVN repo svnadmin dump, svndumpfilter,
> svnadmin load is a pretty easy process.
Otherwise, you can do it on the Git side with:
git filter-branch --tree-filter 'rm -f some-large-blob'
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 1/3] parseopt: add OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <7v39fhv8se.fsf@alter.siamese.dyndns.org>
Add OPT_NOOP_NOARG, a helper macro to define deprecated options in a
standard way. The help text is taken from the no-op option -r of
git revert.
The callback could be made to emit a (conditional?) warning later. And
we could also add OPT_NOOP (requiring an argument) etc. as needed.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Two follow-up patches use the new macro to replace OPTION_BOOLEAN in
three cases. Could be squashed in.
Documentation/technical/api-parse-options.txt | 5 +++++
parse-options-cb.c | 5 +++++
parse-options.h | 6 +++++-
t/t0040-parse-options.sh | 2 +-
test-parse-options.c | 1 +
5 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index f6a4a36..c209046 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -198,6 +198,11 @@ There are some macros to easily define options:
"auto", set `int_var` to 1 if stdout is a tty or a pager,
0 otherwise.
+`OPT_NOOP_NOARG(short, long)`::
+ Introduce an option that has no effect and takes no arguments.
+ Use it to hide deprecated options that are still to be recognized
+ and ignored silently.
+
The last element of the array must be `OPT_END()`.
diff --git a/parse-options-cb.c b/parse-options-cb.c
index 6db0921..0de5fb1 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -123,3 +123,8 @@ int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
string_list_append(v, xstrdup(arg));
return 0;
}
+
+int parse_opt_noop_cb(const struct option *opt, const char *arg, int unset)
+{
+ return 0;
+}
diff --git a/parse-options.h b/parse-options.h
index 59e0b52..47c11f3 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -148,7 +148,10 @@ struct option {
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), "when", (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)"always" }
-
+#define OPT_NOOP_NOARG(s, l) \
+ { OPTION_CALLBACK, (s), (l), NULL, NULL, \
+ "no-op (backward compatibility)", \
+ PARSE_OPT_HIDDEN | PARSE_OPT_NOARG, parse_opt_noop_cb }
/* parse_options() will filter out the processed options and leave the
* non-option arguments in argv[].
@@ -210,6 +213,7 @@ extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
extern int parse_opt_with_commit(const struct option *, const char *, int);
extern int parse_opt_tertiary(const struct option *, const char *, int);
extern int parse_opt_string_list(const struct option *, const char *, int);
+extern int parse_opt_noop_cb(const struct option *, const char *, int);
#define OPT__VERBOSE(var, h) OPT_BOOLEAN('v', "verbose", (var), (h))
#define OPT__QUIET(var, h) OPT_BOOLEAN('q', "quiet", (var), (h))
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 007f39d..a1e4616 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -87,7 +87,7 @@ EOF
test_expect_success 'long options' '
test-parse-options --boolean --integer 1729 --boolean --string2=321 \
--verbose --verbose --no-dry-run --abbrev=10 --file fi.le\
- > output 2> output.err &&
+ --obsolete > output 2> output.err &&
test ! -s output.err &&
test_cmp expect output
'
diff --git a/test-parse-options.c b/test-parse-options.c
index 91a5701..36487c4 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -54,6 +54,7 @@ int main(int argc, const char **argv)
OPT_STRING(0, "string2", &string, "str", "get another string"),
OPT_STRING(0, "st", &string, "st", "get another string (pervert ordering)"),
OPT_STRING('o', NULL, &string, "str", "get another string"),
+ OPT_NOOP_NOARG(0, "obsolete"),
OPT_SET_PTR(0, "default-string", &string,
"set string to default", (unsigned long)"default"),
OPT_STRING_LIST(0, "list", &list, "str", "add str to list"),
--
1.7.7.rc2
^ permalink raw reply related
* Re: SVN -> Git *but* with special changes
From: Stephen Bash @ 2011-09-28 17:10 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1317227849979-6840904.post@n2.nabble.com>
----- Original Message -----
> From: "Abscissa" <bus_nabble_git@semitwist.com>
> To: git@vger.kernel.org
> Sent: Wednesday, September 28, 2011 12:37:29 PM
> Subject: SVN -> Git *but* with special changes
>
> I have a couple big projects in SVN that I'd like to convert to Git.
> Being in SVN, they've operated under a couple assumptions that are
> not true under Git. These assumptions are:
>
> 1. Directories can exist even if there's nothing in them (just like
> any filesystem).
What requires the empty directories to exist? The build system? Can you just let them go away in Git and fix it downstream in the user's working copy?
> 2. Keeping binary files in version control isn't a big deal because
> the whole repo doesn't get copied to everyone's system or use up
> people's GitHub storage space.
I'd eliminate these on the SVN side before converting to Git. If you have svnadmin access to the SVN repo svnadmin dump, svndumpfilter, svnadmin load is a pretty easy process.
> The SVN repos have been relying on those, but both are false under
> Git, so I need to do a "modified" conversion, rather than just a
> straight one.
>
> So, how can I convert an SVN repo to Git, and have the conversion add
> dummy files to empty directories and exclude specific files? (Also,
> there are tags and branches to be converted too, in the SVN-standard
> "tags" and "branches" directories.)
To do the actual conversion, svn-fe and git fast-import are by far the quickest way to get the data into Git. Filtering into tags and branches is a bit of a trick though [1]. git-svn has (IMO) a good branching UI, but can be very slow for large repositories.
[1] http://thread.gmane.org/gmane.comp.version-control.git/158940/focus=159151 : note this thread is almost a year out of date now, and even I know much better ways to go about this now -- but the scripts are not written.
HTH,
Stephen
^ permalink raw reply
* RE: Lack of detached signatures
From: Ben Walton @ 2011-09-28 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com>
Excerpts from Olsen, Alan R's message of Wed Sep 28 00:17:54 -0400 2011:
Hi Alan,
> What I would like to see in git would be signed commits. I have
> looked at what it would take to make it work, but I don't have all
> the details worked out. (Certain merges and cherry-picks would not
> work very well.)
I'm presuming that your intent is an optional signature, not a forced
one, but for discussion, consider the monotone[1] dvcs that forces a
signature on every commit.
While interesting, it was quite heavy weight. Their design was
complicated by the fact that they used their own pki solution instead
of relying on gpg (although they did integrate with gpg-agent).
Granting access to a new user meant sharing monotone-specific keys,
etc. It's been my experience that ssh keys are challenging enough for
many people, and asking them to use gpg keys is just not going to fly
unless mandated from the higher-ups.
We used monotone here for about a year and the key requirements were
the biggest turn off to adoption. Maybe using standard (gpg) tools
would have been less so, but for the most part, I don't think so.
In my (very humble) opinion, signed tags (or possibly the new signed
push certificates) are a much better solution to this. They offer the
same guarantees as having every commit signed (trust of all commits
can be determined based on a signle signature) but leave daily
interactions much more light weight and flexible.
Thanks
-Ben
[1] http://monotone.ca
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: Lack of detached signatures
From: Matthieu Moy @ 2011-09-28 16:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Joseph Parmelee, Carlos Martín Nieto, Olsen, Alan R,
Michael Witten, git@vger.kernel.org
In-Reply-To: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The world is not so blank-and-white. Trust is ultimately among humans. If
> this message is not from the real Junio, don't you think you will hear
> something like "No, that c6ba05... is forgery, please don't use it!" from
> him, when he finds this message on the Git mailing list? If he does not
> exercise diligence to even do that much, does he deserve your trust in the
> first place?
This assumes you will see the message, so while it does solve simple
attacks like sending an email with a fake From: header to the actual
list, it does not solve more advanced attacks like compromising
kernel.org's mailing-list server to avoid delivering you the forged
email.
I know I'm being a little paranoid here, but given the recent events
with kernel.org, maybe we should be that paranoid :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Lack of detached signatures
From: Michael Witten @ 2011-09-28 16:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Joseph Parmelee, Carlos Martín Nieto, Olsen, Alan R,
git@vger.kernel.org
In-Reply-To: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 16:45, Junio C Hamano <gitster@pobox.com> wrote:
> The world is not so blank-and-white. Trust is ultimately among humans. If
> this message is not from the real Junio, don't you think you will hear
> something like "No, that c6ba05... is forgery, please don't use it!" from
> him, when he finds this message on the Git mailing list? If he does not
> exercise diligence to even do that much, does he deserve your trust in the
> first place?
You are parroting Linus's drivel.
If we get to the point where we need the real Junio yelling:
DO NOT USE IT!
then things went too far long before. In that case, my trust in you as
the maintainer would also take a hit; I expect you to use the
available technology to avoid such a situation.
Not everybody manages to read every [real] message of yours, so we
need to provide people with ways to check for themselves that the
sources that they have *locally* already are sound.
^ permalink raw reply
* Re: Lack of detached signatures
From: Junio C Hamano @ 2011-09-28 16:45 UTC (permalink / raw)
To: Joseph Parmelee
Cc: Carlos Martín Nieto, Olsen, Alan R, Michael Witten,
git@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1109280555460.25187@bruno>
Joseph Parmelee <jparmele@wildbear.com> writes:
> There is confusion here between the repository and the tarball. Once you
> have produced the tarball there is NO cryptographic protection against
> forgeries unless you sign it with GPG.
True.
If I give you a URL http://code.google.com/p/git-core/downloads/list with
checksums
$ sha1sum git-1.7.7.rc3.tar.gz
c6ba05a833cab49dd66dd1e252306e187effbf2b git-1.7.7.rc3.tar.gz
You either have to trust that code.google.com/ is not broken, or this
message is coming from real Junio (provided if you can trust him in the
first place).
BUT.
The world is not so blank-and-white. Trust is ultimately among humans. If
this message is not from the real Junio, don't you think you will hear
something like "No, that c6ba05... is forgery, please don't use it!" from
him, when he finds this message on the Git mailing list? If he does not
exercise diligence to even do that much, does he deserve your trust in the
first place?
GPG does add security (if you have the key) but you can do pretty well
even without it in practice.
> It is only because kernel.org exercised due diligence in the production of
> tags and signatures on all their tarballs that the kernel code itself
> withstood their recent intrusion....
I do not think that is true at all. Developers just dropped *.tar.gz on a
'master' machine, and left the rest to a cron job that reflates the
tarball into *.tar.bz2, sign both using a GPG key, and mirror them to the
public-facing machines 'www'.
Somebody who had access to the 'master' machine could add a new tarball
and have it go thru the same exact process, getting signed by the cron.
^ permalink raw reply
* [PATCH v3] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-28 16:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Carlos Martín Nieto, vra5107, Michael J Gruber, Matthieu Moy,
Eric Raible, Philip Oakley, Jeff King, Jay Soffian, git
In-Reply-To: <553B5FA1A43748B1ADD759572EADA6FF@PhilipOakley>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 65 +++++++++++++++++++++++++++------------
1 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..0b6e528 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,29 +125,54 @@ explicitly give a name with '-b' in such a case.
below for details.
---orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
-+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
-+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
-an open source branch of a project whose current tree is "clean", but
-whose full history contains proprietary or otherwise encumbered bits of
-code.
-+
-If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
-Afterwards you will be ready to prepare your new files, repopulating the
-working tree, by copying them from elsewhere, extracting a tarball, etc.
+--orphan::
+ Tell git to turn the next commit you create into a root commit
+ (that is, a commit without any parent); creating the next commit
+ is similar to creating the first commit after running "git{nbsp}init",
+ except that the new commit will be referenced by the branch head
+ <new_branch> rather than "master".
++
+Furthermore, the working tree and index are adjusted as if you ran
+"git{nbsp}checkout{nbsp}<start_point>"; thus, by just running
+"git{nbsp}commit", you can create a root commit with a tree that is
+exactly the same as the tree of <start_point>.
++
+Naturally, before creating the commit, you may manipulate the index
+in any way you want. For example, if you want to create a root commit
+with a tree that is totally different from the tree of <start_point>,
+then just clear the working tree and index first: From the top level
+of the working tree, run "git{nbsp}rm{nbsp}-rf{nbsp}.", and then
+prepare your new working tree and index as desired.
++
+There are two common uses for this option:
++
+--
+ Separate history::
+ Suppose that for convenience, you want to maintain
+ the website for your project in the same repository
+ as the project itself. In such a case, it may not
+ make much sense to interleave the history of the
+ website with the history of the project; you can use
+ the "--orphan" option in order to create these two
+ completely separate histories.
+
+ Hidden history::
+ Suppose you have a project that has proprietary
+ material that is never meant to be released to the
+ public, yet you now want to maintain an open source
+ history that may be published widely.
++
+In this case, it would not be enough just to remove the proprietary
+material from the working tree and then create a new commit, because
+the proprietary material would still be accessible through the new
+commit's ancestry; the proprietary history must be hidden from the new
+commit, and the "--orphan" option allows you to do so by ensuring that
+the new commit has no parent.
++
+However, removing proprietary material from ancestry is usually a task
+that is better performed by linkgit:git-filter-branch[1] and
+linkgit:git-rebase[1], especially when there are multiple commits that
+are already suitable for the open source history.
+--
-m::
--merge::
--
1.7.6.409.ge7a85
^ permalink raw reply related
* SVN -> Git *but* with special changes
From: Abscissa @ 2011-09-28 16:37 UTC (permalink / raw)
To: git
I have a couple big projects in SVN that I'd like to convert to Git. Being in
SVN, they've operated under a couple assumptions that are not true under
Git. These assumptions are:
1. Directories can exist even if there's nothing in them (just like any
filesystem).
2. Keeping binary files in version control isn't a big deal because the
whole repo doesn't get copied to everyone's system or use up people's GitHub
storage space.
The SVN repos have been relying on those, but both are false under Git, so I
need to do a "modified" conversion, rather than just a straight one.
So, how can I convert an SVN repo to Git, and have the conversion add dummy
files to empty directories and exclude specific files? (Also, there are tags
and branches to be converted too, in the SVN-standard "tags" and "branches"
directories.)
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p6840904.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Signed push progress?
From: Junio C Hamano @ 2011-09-28 16:35 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20110928075054.GA13727@orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> from CVS to Git (we're very close now), we've decided that the signed
> pushes will provide better security than our plan of previous plan of
> using signed notes, so we'd like to see signed pushes succeed.
Could you elaborate on your "previous plan" a bit? What is a signed note,
how would it help validate the authenticity, how do developers interact
using it and what do you perceive as weaknesses compared to the signed
push that we discussed a few weeks ago?
^ permalink raw reply
* 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Carlos Martín Nieto @ 2011-09-28 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
Hello,
Whilst trying to do some work related to fetch, I came across a
regression in the 'next' branch. Bisecting gave me this commit as
breaking point (and I tried with the parent and there it worked). When
doing 'git fetch', rev-list will complain about usage, and fetch will
say that we didn't receive enough, even though earlier versions of git
have no problems. This fails both on github and on git.or.cz and for git
and http transports:
$ ./git-fetch git://repo.or.cz/git
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
limiting output:
--max-count=<n>
--max-age=<epoch>
--min-age=<epoch>
--sparse
--no-merges
--min-parents=<n>
--no-min-parents
--max-parents=<n>
--no-max-parents
--remove-empty
--all
--branches
--tags
--remotes
--stdin
--quiet
ordering output:
--topo-order
--date-order
--reverse
formatting output:
--parents
--children
--objects | --objects-edge
--unpacked
--header | --pretty
--abbrev=<n> | --no-abbrev
--abbrev-commit
--left-right
special purpose:
--bisect
--bisect-vars
--bisect-all
error: git://repo.or.cz/git did not send all necessary objects
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-28 15:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Christian Couder, git
In-Reply-To: <201109281459.31689.jnareb@gmail.com>
Jakub Narebski schrieb:
> On Wed, 28 Sep 2011, Georg-Johann Lay wrote:
>> As far as I understand, alien-svn comes with SVN sources which it uses for its
>> own perl packages to provide svn stuff to perl, but don't install/build new svn
>> version.
>
> Step by step instruction.
>
> 1. Follow instructions on local::lib manpage
> http://search.cpan.org/perldoc?local::lib
>
> c.f. http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
>
> 2. (Optional). Follow instructions on cpanm manpage, e.g. http://cpanmin.us
> or http://search.cpan.org/perldoc?cpanm
>
> 3. Install Alien::SVN from CPAN using 'cpan' client or 'cpanm', e.g.
>
> $ cpanm Alien::SVN
>
> Now you are able to install Perl modules in your home directory.
Thank you very much, I never would have found the way through all that jungle
alone!
After steps 1-3 succeeded (as far as I can tell) I can run git svn (but not
git-svn) now.
With an SVN repo I can do
$ svn list http://repo/path
archive/
branches/
tags/
trunk/
and
$ svn checkout http://repo/path
but git svn complains:
$ git svn clone -s --username=georg http://repo/path
Initialized empty Git repository in /local/georg/path/.git/
Bad URL passed to RA layer: Unrecognized URL scheme for 'http://repo/path' at
/usr/local/libexec/git-core/git-svn line 1941
Does git svn not support http?
>From what I read in git svn --help this should suffice to checkout from SVN and
http is mentioned explicitly in an example.
So is my git-svn still broken/not functional or am I missing something from the
docs?
Johann
^ permalink raw reply
* Re: error: addinfo_cache failed during merge
From: Stephen Bash @ 2011-09-28 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vehz01yhx.fsf@alter.siamese.dyndns.org>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "git discussion list" <git@vger.kernel.org>
> Sent: Wednesday, September 28, 2011 11:24:10 AM
> Subject: Re: error: addinfo_cache failed during merge
>
> Stephen Bash <bash@genarts.com> writes:
>
> > ... I should caveat that my local git/git is a little out of date
> > because I haven't repointed it since k.org went down (I use it very
> > rarely), so there might be something newer in this area.
>
> Indeed there have been a few fixs in this area and it would be really
> nice if you can test this with the latest master branch before 1.7.7
> final ships.
The problem reproduces on master (8d714b1). Git builds really fast when I don't need docs ;) In case it's important, this is all on MacOS 10.6.8.
Thanks,
Stephen
^ permalink raw reply
* [PATCH/RFCv3 2/2] receive-pack: don't pass non-existent refs to post-{receive,update} hooks in push deletions
From: Pang Yan Han @ 2011-09-28 15:39 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Sitaram Chamarty, Shawn O. Pearce, Jeff King,
Johannes Schindelin
When a push specifies deletion of non-existent refs, the post post-receive and
post-update hooks receive as input/arguments the non-existent refs.
For instance, for the following push, where refs/heads/nonexistent is a ref
which does not exist on the remote side:
git push origin :refs/heads/nonexistent
the post-receive hook receives from standard input:
<null-sha1> SP <null-sha1> SP refs/heads/nonexistent
and the post-update hook receives as arguments:
refs/heads/nonexistent
which does not make sense since it is a no-op.
Teach receive-pack to not pass non-existent refs as input / arguments to the
post-receive and post-update hooks in the event of a push involving
non-existent ref deletion.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
builtin/receive-pack.c | 31 ++++++++-
t/t5516-fetch-push.sh | 170 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 197 insertions(+), 4 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ae164da..8a0a9d2 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -153,6 +153,26 @@ struct command {
char ref_name[FLEX_ARRAY]; /* more */
};
+/* For invalid refs */
+static struct command **invalid_delete;
+static size_t invalid_delete_nr;
+static size_t invalid_delete_alloc;
+
+static void invalid_delete_append(struct command *cmd)
+{
+ ALLOC_GROW(invalid_delete, invalid_delete_nr + 1, invalid_delete_alloc);
+ invalid_delete[invalid_delete_nr++] = cmd;
+}
+
+static int is_invalid_delete(struct command *cmd)
+{
+ size_t i;
+ for (i = 0; i < invalid_delete_nr; i++)
+ if (invalid_delete[i] == cmd)
+ return 1;
+ return 0;
+}
+
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
@@ -215,7 +235,7 @@ static int run_receive_hook(struct command *commands, const char *hook_name)
int have_input = 0, code;
for (cmd = commands; !have_input && cmd; cmd = cmd->next) {
- if (!cmd->error_string)
+ if (!cmd->error_string && !is_invalid_delete(cmd))
have_input = 1;
}
@@ -248,7 +268,7 @@ static int run_receive_hook(struct command *commands, const char *hook_name)
}
for (cmd = commands; cmd; cmd = cmd->next) {
- if (!cmd->error_string) {
+ if (!cmd->error_string && !is_invalid_delete(cmd)) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
sha1_to_hex(cmd->old_sha1),
sha1_to_hex(cmd->new_sha1),
@@ -447,6 +467,8 @@ static const char *update(struct command *cmd)
if (!parse_object(old_sha1)) {
rp_warning("Allowing deletion of corrupt ref.");
old_sha1 = NULL;
+ if (!ref_exists((char *) name))
+ invalid_delete_append(cmd);
}
if (delete_ref(namespaced_name, old_sha1, 0)) {
rp_error("failed to delete %s", name);
@@ -477,7 +499,7 @@ static void run_update_post_hook(struct command *commands)
struct child_process proc;
for (argc = 0, cmd = commands; cmd; cmd = cmd->next) {
- if (cmd->error_string)
+ if (cmd->error_string || is_invalid_delete(cmd))
continue;
argc++;
}
@@ -488,7 +510,7 @@ static void run_update_post_hook(struct command *commands)
for (argc = 1, cmd = commands; cmd; cmd = cmd->next) {
char *p;
- if (cmd->error_string)
+ if (cmd->error_string || is_invalid_delete(cmd))
continue;
p = xmalloc(strlen(cmd->ref_name) + 1);
strcpy(p, cmd->ref_name);
@@ -866,5 +888,6 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
}
if (use_sideband)
packet_flush(1);
+ free(invalid_delete);
return 0;
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 3abb290..c0d8a0e 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -40,6 +40,39 @@ mk_test () {
)
}
+mk_test_with_hooks() {
+ mk_test "$@" &&
+ (
+ cd testrepo &&
+ mkdir .git/hooks &&
+ cd .git/hooks &&
+
+ cat >pre-receive <<'EOF' &&
+#!/bin/sh
+cat - >>pre-receive.actual
+EOF
+
+ cat >update <<'EOF' &&
+#!/bin/sh
+printf "%s %s %s\n" "$@" >>update.actual
+EOF
+ cat >post-receive <<'EOF' &&
+#!/bin/sh
+cat - >>post-receive.actual
+EOF
+
+ cat >post-update <<'EOF' &&
+#!/bin/sh
+for ref in "$@"
+do
+ printf "%s\n" "$ref" >>post-update.actual
+done
+EOF
+
+ chmod u+x pre-receive update post-receive post-update
+ )
+}
+
mk_child() {
rm -rf "$1" &&
git clone testrepo "$1"
@@ -559,6 +592,143 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'pushing valid refs triggers post-receive and post-update hooks' '
+ mk_test_with_hooks heads/master heads/next &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
+ newnext=$_z40 &&
+ git push testrepo refs/heads/master:refs/heads/master :refs/heads/next &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/next $orgnext $newnext
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+refs/heads/next
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting dangling ref triggers hooks with correct args' '
+ mk_test_with_hooks heads/master &&
+ rm -f testrepo/.git/objects/??/* &&
+ git push testrepo :refs/heads/master &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/master
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/master
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting non-existent ref does not trigger post-receive and post-update hooks' '
+ mk_test_with_hooks heads/master &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ git push testrepo master :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'mixed ref updates, deletes, invalid deletes trigger hooks with correct input' '
+ mk_test_with_hooks heads/master heads/next heads/pu &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
+ newnext=$_z40 &&
+ orgpu=$(cd testrepo && git show-ref -s --verify refs/heads/pu) &&
+ newpu=$(git show-ref -s --verify refs/heads/master) &&
+ git push testrepo refs/heads/master:refs/heads/master refs/heads/master:refs/heads/pu :refs/heads/next :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+$orgpu $newpu refs/heads/pu
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/next $orgnext $newnext
+refs/heads/pu $orgpu $newpu
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+$orgpu $newpu refs/heads/pu
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+refs/heads/next
+refs/heads/pu
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
test_expect_success 'allow deleting a ref using --delete' '
mk_test heads/master &&
(cd testrepo && git config receive.denyDeleteCurrent warn) &&
--
1.7.7.rc3.2.g6bf07
^ permalink raw reply related
* Re: error: addinfo_cache failed during merge
From: Stephen Bash @ 2011-09-28 15:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vehz01yhx.fsf@alter.siamese.dyndns.org>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "git discussion list" <git@vger.kernel.org>
> Sent: Wednesday, September 28, 2011 11:24:10 AM
> Subject: Re: error: addinfo_cache failed during merge
>
> Stephen Bash <bash@genarts.com> writes:
>
> > ... I should caveat that my local git/git is a little out of date
> > because I haven't repointed it since k.org went down (I use it very
> > rarely), so there might be something newer in this area.
>
> Indeed there have been a few fixs in this area and it would be really
> nice if you can test this with the latest master branch before 1.7.7
> final ships.
Okay. Will do right now.
Thanks,
Stephen
^ permalink raw reply
* Re: Merge seems to overwrite unstaged local changes
From: Junio C Hamano @ 2011-09-28 15:25 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j5v9r7$fi1$1@dough.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> ... I'm seeing this on Linux and Windows, with versions 1.7.4.3 and 1.7.6.
There recently have been quite a change in merge-recursive implementation
and it would be really nice if you can try this again with the tip of
'master' before 1.7.7 final ships.
Thanks.
^ permalink raw reply
* Re: error: addinfo_cache failed during merge
From: Junio C Hamano @ 2011-09-28 15:24 UTC (permalink / raw)
To: Stephen Bash; +Cc: git discussion list
In-Reply-To: <26411548.33530.1317221043429.JavaMail.root@mail.hq.genarts.com>
Stephen Bash <bash@genarts.com> writes:
> ... I should caveat that my local git/git is a little out of date
> because I haven't repointed it since k.org went down (I use it very
> rarely), so there might be something newer in this area.
Indeed there have been a few fixs in this area and it would be really nice
if you can test this with the latest master branch before 1.7.7 final
ships.
^ permalink raw reply
* Re: error: addinfo_cache failed during merge
From: Stephen Bash @ 2011-09-28 15:24 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <26411548.33530.1317221043429.JavaMail.root@mail.hq.genarts.com>
----- Original Message -----
> From: "Stephen Bash" <bash@genarts.com>
> To: "git discussion list" <git@vger.kernel.org>
> Sent: Wednesday, September 28, 2011 10:44:03 AM
> Subject: error: addinfo_cache failed during merge
>
> Unfortunately, during the merge, I got a bunch of errors like
> this:
>
> error: addinfo_cache failed for path 'foo/bar.h'
>
> So first, is this important?
Well, to my uneducated eye, it looks like the error just left the conflicts in the working copy rather than resolving them. Running mergetool appears to have cleaned up the problems.
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-28 15:06 UTC (permalink / raw)
To: Matthieu Moy
Cc: Junio C Hamano, Jeff King, Philip Oakley, Eric Raible,
Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq39fglo8y.fsf@bauges.imag.fr>
On Wed, Sep 28, 2011 at 14:45, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>>> Even if you use it normally:
>>>
>>> # I want to create a new root commit with a different tree
>>> git checkout -b new-project
>>> # hack for a while
>>> git status
>>> # ?!? why are files shown as 'deleted', 'moved', 'modified', I said I
>>> # was creating a new project!
>>>
>>> Also, with your proposal, we would need to add two flags to "commit"
>>> (--no-parent and --force), which is one of the first command beginners
>>> learn, while in the current state we have just one for "checkout" to do
>>> the trick, and newbies do not use or read the doc for checkout, so it's
>>> not scary for them.
>>
>> Well, those are mildly interesting scenarios. I can only say that I don't
>> think we should cater to people who either have amnesia or work casually
>> on a repository for short bursts every few months or so.
>
> How is the "git status" issue above linked to any kind of amnesia?
>
> When hacking to create a rootless commit, it seems legitimate to me to
> run "git status", and it seems _very_ confusing that "git status" still
> refers to the commit you don't want as parent.
I think "confusing" is perhaps the wrong word. How about "annoying"?
I suppose it is true that neither "--orphan" nor "--no-parent" is good
enough alone. For instance:
# I want to create a new root commit with a slightly different tree
git checkout --orphan new-project
# hack just a bit here and there
git status
# ?!? My slight alterations are obscured by hundreds of these
# "new file" status notifications!
> (I don't get the relation between your reply and the paragraph right
> above it either)
Is that a passive aggressive French way to state that I didn't respond
to your concern?
I think it's moot now, anyway, given that both "--orphan" and
"--no-parent" quite possibly have their logical purposes. However,
perhaps:
git checkout --orphan
should be renamed:
git checkout --no-parent
in order to match:
git commit --no-parent
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-28 14:49 UTC (permalink / raw)
To: Thomas Rast
Cc: Ramkumar Ramachandra, Junio C Hamano, Francis Moreau,
Michael J Gruber, git
In-Reply-To: <201109261110.59940.trast@student.ethz.ch>
On Mon, Sep 26, 2011 at 5:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Martin von Zweigbergk wrote:
>>
>> If I understand correctly, [rebase --root] was introduced to solve
>> exactly the same reason problem that made Francis start this thread
>> -- to avoid re-applying patches that are already in $onto.
>
> Not quite; I wrote it because at the time, there was no way to
> transplant git history onto a git-svn "make empty subdir" commit for
> later dcommitting. So the main point was really
But that was only due to the bug/limitation in format-patch that you
(?) fixed a few days later, no?
> I still think it would be natural for a user to want a way to say "all
> the way back to the root commit". At least for me the "full" rebase
> invocation is
>
> git rebase --onto onto base branch
Sure, I can understand that. Still, it would just be an alternative
syntax and nothing else. So I think I should also update the
documentation after my other patches to make it clear that that is the
case. We also have to think about backwards compatibility, so I'm
obviously not suggesting that we should stop supporting the flag; I
just wanted to make sure that it is not technically needed.
>> I saw that
>> "--root" is also passed to the hook. Should that value be passed to
>> the hook also when the old base is not explicitly a root (by "rebase
>> --root"), but only implicitly so (by an $onto that is disjoint from
>> $branch)?
>
> I think I did it that way because if you use --root, the base/upstream
> argument is missing, and the hook needs to know that.
>
> If the user specifies an upstream that is disjoint from the branch
> itself, the hook gets the upstream argument and can presumably work it
> out from there. So you could perhaps save the hook some trouble if
> you *know* that it's a disjoint rebase, but I wouldn't spend too much
> time on that.
The hook would still have to be able to handle both cases (i.e.
getting the upstream argument as "--root" or simply a commit that
happens to be disjoint from the the branch-to-be-rebased). I believe
that has been the case since that bug in format-patch was fixed. So if
we were to change git-rebase so it no longer passes the --root flag to
the hook, I think any (correctly written) hooks should still work. I
don't see much reason to change it, though; if the user uses the
--root syntax, we can pass the flag, otherwise we don't.
Martin
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: expand filename of aliasesfile
From: Matthieu Moy @ 2011-09-28 14:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong
In-Reply-To: <20110928144057.GC12586@laptop>
Cord Seele <cowose@googlemail.com> writes:
> On Wed 28 Sep 2011 15:42:01 +0200, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> That'd be cleaner to use
>>
>> git config --path sendemail.aliasesfile
>>
>> to let Git do the right expansion, in a way consistant with other places
>> of Git.
>
> This means to expand it at 'git config' time?
Yes, but not the "git config" ran to set the value. The one ran
internally by "git send-email" through Git::config(). You may add --get
to my command line above.
> Wouldn't it be nicer to have it expanded when you run 'git
> send-email'? Then you could move your ~/.gitconfig (that's where I
> have my aliasesfile configured) between different accounts and it
> could still work.
That works with my proposal.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Matthieu Moy @ 2011-09-28 14:45 UTC (permalink / raw)
To: Michael Witten
Cc: Junio C Hamano, Jeff King, Philip Oakley, Eric Raible,
Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <CAMOZ1Btw7Bf3_ejZef_SdRojyVeM94knyz9Gw+SEqFtrrpBVsA@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
>> Even if you use it normally:
>>
>> # I want to create a new root commit with a different tree
>> git checkout -b new-project
>> # hack for a while
>> git status
>> # ?!? why are files shown as 'deleted', 'moved', 'modified', I said I
>> # was creating a new project!
>>
>> Also, with your proposal, we would need to add two flags to "commit"
>> (--no-parent and --force), which is one of the first command beginners
>> learn, while in the current state we have just one for "checkout" to do
>> the trick, and newbies do not use or read the doc for checkout, so it's
>> not scary for them.
>
> Well, those are mildly interesting scenarios. I can only say that I don't
> think we should cater to people who either have amnesia or work casually
> on a repository for short bursts every few months or so.
How is the "git status" issue above linked to any kind of amnesia?
When hacking to create a rootless commit, it seems legitimate to me to
run "git status", and it seems _very_ confusing that "git status" still
refers to the commit you don't want as parent.
(I don't get the relation between your reply and the paragraph right
above it either)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* error: addinfo_cache failed during merge
From: Stephen Bash @ 2011-09-28 14:44 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <8172019.33448.1317219409234.JavaMail.root@mail.hq.genarts.com>
Hi all-
I'm in the process of implementing whitespace and EOL normalization for our repo. Having completed the work on our oldest maintenance branch, I'm attempting to merge the changes recursively into newer branches.
My approach is to merge using '-s recursive -X ours --no-commit' since the only conflicts are whitespace/EOL changes and I have to renormalize the current branch before committing anyway (new files, etc.). Unfortunately, during the merge, I got a bunch of errors like this:
error: addinfo_cache failed for path 'foo/bar.h'
So first, is this important? Second, can that message be replaced with something more helpful? I'm not exactly a newbie, and I certainly can't grok that message...
Doing a bit of archeology, pickaxe shows it arose in 0424138 "Fix bogus error message from merge-recursive error path", but that was Junio cleaning up the message a bit. The original message is from the creation of merge-recursive.c in 6d297f8 "Status update on merge-recursive in C". I should caveat that my local git/git is a little out of date because I haven't repointed it since k.org went down (I use it very rarely), so there might be something newer in this area.
Thanks,
Stephen
^ 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