Re: [RFC][GSOC] Proposal Draft for GSoC, Suggest Changes
Hello, Now that i have already submitted my proposal to GSOC , i was wondering if there is any way where i could contribute to git via bug fixes or something similar to the microprojects which was available prior to GSOC application. Also wondering if any clarification was needed as per my proposal. Would be great to hear from you all . Thanks - Karthik -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git feature request: Option to force Git to abort a checkout if working directory is dirty (i.e. disregarding the check for conflicts)
Jonas Bang em...@jonasbang.dk writes: For some people it is also a norm to keep files that have been modified from HEAD and/or index without committing for a long time (e.g. earlier, Linus said that the version in Makefile is updated and kept modified in the working tree long before a new release is committed with that change). The default behaviour would cover their use case so your proposal would not hurt them, but I wonder if there are things you could do to help them as well, perhaps by allowing this new configuration to express something like local changes in these paths are except from this new check. Yes, those people would probably use the default 'false' behavior as it is already. If they however would like to use e.g. the 'true' or 'include-untracked' setting as a configuration variable, then they can use the command line option 'false' if they wish to do a 'git checkout' even with modified files in the working tree. So in short, you are saying that The added code necessary to implement this feature will not help them in any way, it is just that we will make sure it does not hurt them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] test-lib: '--run' to run only specific tests
Eric Sunshine sunsh...@sunshineco.com writes: Since the relational operators are fairly self-explanatory, you could drop the prose explanation, though that might make it too cryptic: A number prefixed with '', '=', '', or '=' matches test numbers meeting the specified relation. I would have to say that there is already an established pattern to pick ranges that normal people understand well and it would be silly to invent another more verbose way to express the same thing. You tell your Print Dialog which page to print with e.g. -4,7,9-12,15-, not =4 7 Would the same notation be insufficient for our purpose? You do not even have to worry about negation that way. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] commit: add --ignore-submodules[=when] parameter
Jens Lehmann jens.lehm...@web.de writes: Changes in add.c and cache.h (and related compilo fix in checkout.c) are needed to make it work for commit -a too. Looking good so far, but we definitely need tests for this new option. But I wonder if it would make more sense to start by teaching the --ignore-submodules option to git add. Then this patch could reuse that for commit -a. I am not sure about the code reuse, but from the usability and consistency point of view, they must go hand in hand, I would think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] parse-options: add cast to correct pointer type to OPT_SET_PTR
Marat Radchenko ma...@slonopotamus.org writes:
Do not force users of OPT_SET_PTR to cast pointer to correct
underlying pointer type by integrating cast into OPT_SET_PTR macro.
Cast is required to prevent 'initialization makes integer from pointer
without a cast' compiler warning.
---
Signed-off-by (and probably From: too): Junio C Hamano gits...@pobox.com
;-)
parse-options.h | 2 +-
test-parse-options.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/parse-options.h b/parse-options.h
index 8fa02dc..54099d9 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -129,7 +129,7 @@ struct option {
#define OPT_HIDDEN_BOOL(s, l, v, h) { OPTION_SET_INT, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG | PARSE_OPT_HIDDEN,
NULL, 1}
#define OPT_SET_PTR(s, l, v, h, p) { OPTION_SET_PTR, (s), (l), (v), NULL, \
- (h), PARSE_OPT_NOARG, NULL, (p) }
+ (h), PARSE_OPT_NOARG, NULL, (intptr_t)(p)
}
#define OPT_CMDMODE(s, l, v, h, i) { OPTION_CMDMODE, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG|PARSE_OPT_NONEG,
NULL, (i) }
#define OPT_INTEGER(s, l, v, h) { OPTION_INTEGER, (s), (l), (v),
N_(n), (h) }
diff --git a/test-parse-options.c b/test-parse-options.c
index 6f6c656..10da63e 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -60,7 +60,7 @@ int main(int argc, char **argv)
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, (intptr_t)default),
+ set string to default, default),
OPT_STRING_LIST(0, list, list, str, add str to list),
OPT_GROUP(Magic arguments),
OPT_ARGUMENT(quux, means --quux),
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues
Marat Radchenko ma...@slonopotamus.org writes: Patches summary: 1. Fix initial issue (incorrect cast causing crash on 64-bit MSVC) 2. Improve OPT_SET_PTR to prevent same errors in future 3. Purge OPT_SET_PTR away since nobody uses it *Optional* patch №3 is separated from №1 and №2 so that if someone someday decides to return OPT_SET_PTR back by reverting №3, it will be returned in a sane state. Decision of (not) merging №3 is left as an exercise to the reader due to my insufficient knowledge of accepted practices in Git project. SET_PTR() may not be used, but are there places where SET_INT() is abused with a cast-to-pointer for the same effect? I didn't check, but if there are such places, converting them to use SET_PTR() with their existing cast removed may be a better way to go. My suspicion is that there would be none, as switching the behaviour based on a small integer flag value is far easier than swapping the pointer to a pointee to be operated on, when responding to a command line option. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Don't rely on strerror text when testing rmdir failure
Jens Lehmann jens.lehm...@web.de writes: Am 29.03.2014 16:39, schrieb Charles Bailey: AIX doesn't make a distiction between EEXIST and ENOTEMPTY so relying on the strerror string for the rmdir failure is fragile. Just test that the start of the string matches the Git controlled failed to rmdir... error. The exact text of the OS generated error string isn't important to the test. Makes sense. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- t/t3600-rm.sh | 5 ++--- t/t7001-mv.sh | 3 +-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 3d30581..23eed17 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -709,10 +709,9 @@ test_expect_success 'checking out a commit after submodule removal needs manual git commit -m submodule removal submod git checkout HEAD^ git submodule update -git checkout -q HEAD^ 2actual +git checkout -q HEAD^ 2/dev/null Isn't this unrelated to the strerror issue you are fixing here? Why not just drop the redirection completely? But maybe I'm just being to pedantic here ;-) No, that sounds like a very reasonable suggestion. Especially given that the redirection destination is overwritten immediately after. In general tests should not have to squelch their standard error output with 2/dev/null; that is a job for the test harness, and they will be shown in the output of ./t3600-rm -v to serve as anchor point while finding where a test goes wrong, which is a good thing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #07; Fri, 28)
(now without HTML formatting)
I am new to git, so sorry If I overlooked something.
I think there might be a race in ref_transaction_commit() when
deleting references.
/* Perform deletes now that updates are safely completed */
for (i = 0; i n; i++) {
struct ref_update *update = updates[i];
if (update-lock) {
delnames[delnum++] = update-lock-ref_name;
ret |= delete_ref_loose(update-lock, update-type);
}
}
ret |= repack_without_refs(delnames, delnum);
for (i = 0; i delnum; i++)
unlink_or_warn(git_path(logs/%s, delnames[i]));
These two blocks should be reordered so that you first delete the
actual refs first, while holding the lock and then release the lock
afterward ?
On Fri, Mar 28, 2014 at 4:23 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 03/28/2014 11:21 PM, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Junio,
Have you overlooked my ref-transactions series [1], or just not gotten
to it yet?
If you would like a version of the series that already addresses Brad
King's comments, you can get it from my GitHub fork [2], the
ref-transactions branch. I'd be happy to post a v3 to the list if you
prefer, but the only changes since v2 were to a commit message and a
comment so it seems like overkill.
Michael
[1] http://thread.gmane.org/gmane.comp.version-control.git/244857
[2] https://github.com/mhagger/git
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid
On Mon, Mar 31, 2014 at 07:19:09PM +0200, Siggi wrote: here are the two outputs you wanted to see. The interesting bit is at the end... HTTP/1.1 200 OK Date: Mon, 31 Mar 2014 17:04:57 GMT * Server Apache/2.2.22 (Ubuntu) is not blacklisted Server: Apache/2.2.22 (Ubuntu) X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.19 ETag: 2ab570112563de50022189f0a2ffcdd4 Pragma: no-cache Expires: Fri, 01 Jan 1980 00:00:00 GMT X-Runtime: 72 Cache-Control: no-cache, max-age=0, must-revalidate Content-Length: 1047 Status: 200 Content-Type: application/x-git-upload-pack-advertisement; charset=utf-8 This content-type is the problem. There should not be a charset parameter (it is meaningless, and it throws off git's content-type check). So your web server configuration (or the redmine git plugin) should be fixed, but you'll have to talk to redmine folks to figure that part out. That being said, git _could_ be more liberal in accepting a content-type with parameters (even though it does not know about any parameters, and charset here is completely meaningless). I have mixed feelings on that. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Odd git diff breakage
I hit this oddity when not remembering the right syntax for --color-words.. Try this (outside of a git repository): touch a b git diff -u --color=words a b and watch it scroll (infinitely) printing out error: option `color' expects always, auto, or never forever. I haven't tried to root-cause it, since I'm supposed to be merging stuff.. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid
Jeff King p...@peff.net writes: That being said, git _could_ be more liberal in accepting a content-type with parameters (even though it does not know about any parameters, and charset here is completely meaningless). I have mixed feelings on that. It may be just a matter of replacing strbuf_cmp() with the initial part must be this string followed by it could have an optional whitespaces and semicolon after that, but I share the mixed feelings. I am not sure if it is a right thing to follow be liberal to accept dictum in this case. It may be liberal in accepting blindly, but if the other end is asking a behaviour that is not standard (but perhaps in future versions of Git such an enhanced service may be implemented by the client), by ignoring the parameter we do not even know about how to handle, we would be giving surprises to the overall protocol exchange. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd git diff breakage
Linus Torvalds torva...@linux-foundation.org writes: I hit this oddity when not remembering the right syntax for --color-words.. Try this (outside of a git repository): touch a b git diff -u --color=words a b and watch it scroll (infinitely) printing out error: option `color' expects always, auto, or never forever. I haven't tried to root-cause it, since I'm supposed to be merging stuff.. Linus Hmph, interesting. outside a repository is the key, it seems. And I can see it all the way down to 1.7.3 (at least). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd git diff breakage
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano gits...@pobox.com wrote: Hmph, interesting. outside a repository is the key, it seems. Well, you can do it inside a repository too, but then you need to use the --no-index flag to get the diff two files behavior. It will result in the same infinite error messages. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd git diff breakage
Junio C Hamano gits...@pobox.com writes:
Linus Torvalds torva...@linux-foundation.org writes:
I hit this oddity when not remembering the right syntax for --color-words..
Try this (outside of a git repository):
touch a b
git diff -u --color=words a b
and watch it scroll (infinitely) printing out
error: option `color' expects always, auto, or never
forever.
I haven't tried to root-cause it, since I'm supposed to be merging stuff..
Linus
Hmph, interesting. outside a repository is the key, it seems.
And I can see it all the way down to 1.7.3 (at least).
diff_opt_parse() returns the number of options parsed, or often
returns error() which is defined to return -1. Yes, return value
of 0 is I don't understand that option, which should cause the
caller to say that, but negative return should not be forgotten.
diff-no-index.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index c554691..265709b 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -198,7 +198,7 @@ void diff_no_index(struct rev_info *revs,
i++;
else {
j = diff_opt_parse(revs-diffopt, argv + i, argc - i);
- if (!j)
+ if (j = 0)
die(invalid diff option/value: %s, argv[i]);
i += j;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] diff-no-index: correctly diagnose error return from diff_opt_parse()
diff_opt_parse() returns the number of options parsed, or often
returns error() which is defined to return -1. Yes, return value of
0 is I did not process that option at all, which should cause the
caller to say that, but negative return should not be forgotten.
This bug the caused it to infinitely show the same error message
because the returned value was used to decrement the loop control
variable, e.g.
$ git diff --no-index --color=words a b
error: option `color' expects always, auto, or never
error: option `color' expects always, auto, or never
...
Instead, make it act like so:
$ git diff --no-index --color=words a b
error: option `color' expects always, auto, or never
fatal: invalid diff option/value: --color=words
Reported-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The other callchain to this function comes from rev-list.c, and
the caller does handle it correctly.
diff-no-index.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 00a8eef..ecf9293 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -244,7 +244,7 @@ void diff_no_index(struct rev_info *revs,
i++;
else {
j = diff_opt_parse(revs-diffopt, argv + i, argc - i);
- if (!j)
+ if (j = 0)
die(invalid diff option/value: %s, argv[i]);
i += j;
}
--
1.9.1-513-gce53123
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid
On Mon, Mar 31, 2014 at 11:27:53AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That being said, git _could_ be more liberal in accepting a content-type
with parameters (even though it does not know about any parameters, and
charset here is completely meaningless). I have mixed feelings on that.
It may be just a matter of replacing strbuf_cmp() with the initial
part must be this string followed by it could have an optional
whitespaces and semicolon after that, but I share the mixed
feelings.
Yeah, I think something like this is probably enough:
diff --git a/remote-curl.c b/remote-curl.c
index 52c2d96..be21fb6 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -221,6 +221,13 @@ static int show_http_message(struct strbuf *type, struct
strbuf *msg)
return 0;
}
+static int match_content_type(struct strbuf *have, struct strbuf *want)
+{
+ if (!starts_with(have-buf, want-buf))
+ return 0;
+ return have-len == want-len || have-buf[want-len] == ';';
+}
+
static struct discovery* discover_refs(const char *service, int for_push)
{
struct strbuf exp = STRBUF_INIT;
@@ -277,7 +284,7 @@ static struct discovery* discover_refs(const char *service,
int for_push)
strbuf_addf(exp, application/x-%s-advertisement, service);
if (maybe_smart
(5 = last-len last-buf[4] == '#')
- !strbuf_cmp(exp, type)) {
+ match_content_type(type.buf, exp.buf)) {
char *line;
/*
though perhaps there are exotic whitespace rules that we would also need
to allow. Either way, I do not think it is the implementation that is
the problem, but rather the semantics.
I am not sure if it is a right thing to follow be liberal to
accept dictum in this case. It may be liberal in accepting
blindly, but if the other end is asking a behaviour that is not
standard (but perhaps in future versions of Git such an enhanced
service may be implemented by the client), by ignoring the parameter
we do not even know about how to handle, we would be giving surprises
to the overall protocol exchange.
I actually think ignoring them could provide room for future expansion
in git (i.e., we could add new c-t parameters with the knowledge that
existing git would ignore them). So there is a potential upside. But
current git does _not_ ignore them. Git v1.10 (or 2.0, or whatever)
could, but we would have to wait for old versions to die out before
making that assumption anyway.
It's also possible that we would want to intentionally break
compatibility (to say if you do not understand foo=bar, then do not
even process this). But I don't think that is a big deal, as we could
already switch the content-type itself (x-upload-pack-advertisement2
or something). And if we really wanted to dump extra optional data into
the http conversation, we can already do so with http headers.
So really, I do not see us ever realistically expanding into
content-type parameters. This would _just_ be about handling odd
implementations. And there I can see it as us being nice (I do not think
charset is doing anything here), or us being careful about broken
implementations (why would one add a charset parameter at all? If the
implementation is blindly re-encoding to utf8 or something, it could
very well be corrupting the data in rare cases).
Given that there is only one implementation known to this in the first
place, I'd be inclined to say fix that implementation. If it becomes
a widespread problem, then we can think about loosening the check after
reviewing exactly what each implementation is doing.
I think all of that is to say I'm violently agreeing with you. But
having tried to think it through, I felt it was worth posting the more
detailed thought process.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1] commit: add --ignore-submodules[=when] parameter
Am 31.03.2014 02:07, schrieb Ronald Weiss:
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but didn't allow to override it from command line, like other commands do.
Useful when values for commit are 'all' (default) or 'none'. The others
('dirty' and 'untracked') have same effect as 'none', as commit is only
interested in whether the submodule's HEAD differs from what is commited
in the superproject.
Changes in add.c and cache.h (and related compilo fix in checkout.c) are
needed to make it work for commit -a too.
Signed-off-by: Ronald Weiss weiss.ron...@gmail.com
---
The previous patch version (v2) contained bug in the test, by mistake I
have sent older version than I was testing with, sorry for that.
On 30. 3. 2014 21:48, Jens Lehmann wrote:
Looking good so far, but we definitely need tests for this new option.
I added two simple tests (one for --ignore-submodules=all, another one
for =none). But I am sure the tests could be written better, by someone
more proficient in Git than I am.
The tests immediately revealed, that the patch was not complete. It
didn't work with commit message given on command line (-m). To make
that work, I had to also patch the index_differs_from function in
diff-lib.c.
Which is exactly the same function I have to tweak to make my
status/commit: always show staged submodules regardless of
ignore config patch work for git commit -m too ;-)
I was doing that slightly differently but it seems that your way
of adding the ignore_submodules_arg parameter could serve us
both. Will update my upcoming patch accordingly.
But I wonder if it would make more sense to start by teaching the
--ignore-submodules option to git add. Then this patch could reuse
that for commit -a.
That sounds reasonable, however I don't think that any code from my
patch would be affected, or would it? IOW, would commit really reuse
anything? If not (or not much), there is probably no point in
postponing this patch, support for git add may be added later.
You might be right as I didn't really check the actual codepaths. I
was deducing this from the observation that most changes were made
to builtin/add.c. And seeing a function like add_files_to_cache()
being modified made me expect that plain add would use the same
function to stage the files.
As Junio mentioned it would be great if you could teach the add
command also honor the --ignore-submodule command line option in
a companion patch. In the course of doing so you'll easily see if
I was right or not, then please just order them in the most logical
way.
Thanks for digging into this!
Documentation/git-commit.txt| 6 ++
builtin/add.c | 16 +++
builtin/checkout.c | 2 +-
builtin/commit.c| 10 --
cache.h | 2 +-
diff-lib.c | 7 ++-
diff.h | 3 ++-
sequencer.c | 4 ++--
t/t7513-commit-ignore-submodules.sh | 39
+
9 files changed, 77 insertions(+), 12 deletions(-)
create mode 100644 t/t7513-commit-ignore-submodules.sh
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..c8839c8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[-F file | -m msg] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=author]
[--date=date] [--cleanup=mode] [--[no-]status]
+[--ignore-submodules[=when]]
[-i | -o] [-S[keyid]] [--] [file...]
DESCRIPTION
@@ -271,6 +272,11 @@ The possible options are:
The default can be changed using the status.showUntrackedFiles
configuration variable documented in linkgit:git-config[1].
+--ignore-submodules[=when]::
+ Can be used to override any settings of the 'ignore' option
+ in linkgit:git-config[1] or linkgit:gitmodules[5].
+ when can be either none or all, which is the default.
+
-v::
--verbose::
Show unified diff between the HEAD commit and what
diff --git a/builtin/add.c b/builtin/add.c
index 672adc0..1086294 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -168,7 +168,8 @@ static void update_callback(struct diff_queue_struct *q,
static void update_files_in_cache(const char *prefix,
const struct pathspec *pathspec,
- struct update_callback_data *data)
+ struct update_callback_data *data,
+ const char *ignore_submodules_arg)
{
struct rev_info rev;
@@ -180,17 +181,24 @@ static void update_files_in_cache(const char *prefix,
rev.diffopt.format_callback = update_callback;
rev.diffopt.format_callback_data = data;
rev.max_count = 0; /* do not compare
Re: [PATCH v3 1/3] patch-id: make it stable against hunk reordering
On Mon, Mar 31, 2014 at 10:59:50AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: Patch id changes if users 1. reorder file diffs that make up a patch or 2. split a patch up to multiple diffs that touch the same path (keeping hunks within a single diff ordered to make patch valid). As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Change patch-id behaviour making it stable against these two kinds of patch change: 1. calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id 2. hash the file-level headers together with each hunk (not just the first hunk) We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). Add a new flag --unstable to get the historical behaviour. Add --stable which is a nop, for symmetry. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- changes from v2: several bugfixes changes from v1: hanges from v1: documented motivation for supporting diff splitting (and not just file reordering). No code changes. builtin/patch-id.c | 72 ++ 1 file changed, 56 insertions(+), 16 deletions(-) Does this have to interact or be consistent with patch-ids.c which is the real patch-id machinery used to filter like-changes out by cherry-pick and log --cherry-pick? I don't know off-hand. Specifically, this is diff_flush_patch_id and in diff.c, isn't it? This series opens a very interesting opportunity by making it possible to introduce the equivalence between two patches that touch the same file and a single patch that concatenates hunks from these two patches. One example I am wondering about is perhaps this could be used to detect two branches, both sides with many patches cherry-picked from the same source, but some patches squashed together on one branch but not on the other. It would be very nice if you can detect that two sets of patches are equivalent taken as a whole in such a situation while rebasing one on top of the other. Another example is that another mode that gives a set of broken-up patch-ids for each hunk contained in the input. Suppose there is a patch that is only meant to be used on the proprietary fork of an open source project, and the project releases the open source portion by cherry-picking topics from the development tree used for the proprietary trunk. The integration service of such a project used to prepare the open source branch may want to have a pre-receive hook that says do not merge any commit to cause this this hunk appear in the result, no matter what other changes the patches in the commit may bring in, and broken-down patch-ids (e.g. diff HEAD...$commit | patch-id --individual) may be an ingredient to implement such a hook. There may be interesting applications other than such a broken-down patch-ids that can be based on the enhancement you are presenting here. OK sure, I can tweak that to use the same algorithm if desired, though it does look like an unrelated enhancement to me. Agree? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] patch-id: document new behaviour
Michael S. Tsirkin m...@redhat.com writes: Clarify that patch ID is now a sum of hashes, not a hash. Document --stable and --unstable flags. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- changes from v2: explicitly list the kinds of changes against which patch ID is stable Documentation/git-patch-id.txt | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt index 312c3b1..30923e0 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -8,14 +8,14 @@ git-patch-id - Compute unique ID for a patch SYNOPSIS [verse] -'git patch-id' patch +'git patch-id' [--stable | --unstable] patch Thanks. It seems taht we are fairly inconsistent when writing alternatives on the SYNOPSIS line. A small minority seems to spell the above as [--stable|--unstable], which may want to be fixed (outside the context of this series, of course). DESCRIPTION --- -A patch ID is nothing but a SHA-1 of the diff associated with a patch, with -whitespace and line numbers ignored. As such, it's reasonably stable, but at -the same time also reasonably unique, i.e., two patches that have the same patch -ID are almost guaranteed to be the same thing. +A patch ID is nothing but a sum of SHA-1 of the diff hunks associated with a +patch, with whitespace and line numbers ignored. As such, it's reasonably +stable, but at the same time also reasonably unique, i.e., two patches that +have the same patch ID are almost guaranteed to be the same thing. Perhaps nothing but can go by now? IOW, you can use this thing to look for likely duplicate commits. @@ -27,6 +27,19 @@ This can be used to make a mapping from patch ID to commit ID. OPTIONS --- + +--stable:: + Use a symmetrical sum of hashes as the patch ID. + With this option, reordering file diffs that make up a patch or + splitting a diff up to multiple diffs that touch the same path + does not affect the ID. + This is the default. + +--unstable:: + Use a non-symmetrical sum of hashes, such that reordering + or splitting the patch does affect the ID. + This was the default value for git 1.9 and older. I am not sure if swapping the default in this series is a wise decision. We typically introduce a new shiny toy to play with in a release and then later when the shiny toy proves to be useful, start to think about changing the default, but not before. patch:: The diff to create the ID of. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-no-index: correctly diagnose error return from diff_opt_parse()
On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano gits...@pobox.com wrote: Instead, make it act like so: $ git diff --no-index --color=words a b error: option `color' expects always, auto, or never fatal: invalid diff option/value: --color=words Thanks, Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] patch-id-test: test --stable and --unstable flags
Michael S. Tsirkin m...@redhat.com writes:
Verify that patch ID is now stable against diff split and reordering.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Changes from v2:
added test to verify patch ID is stable against diff splitting
t/t4204-patch-id.sh | 117
1 file changed, 109 insertions(+), 8 deletions(-)
diff --git a/t/t4204-patch-id.sh b/t/t4204-patch-id.sh
index d2c930d..1679714 100755
--- a/t/t4204-patch-id.sh
+++ b/t/t4204-patch-id.sh
@@ -5,12 +5,46 @@ test_description='git patch-id'
. ./test-lib.sh
test_expect_success 'setup' '
- test_commit initial foo a
- test_commit first foo b
- git checkout -b same HEAD^
- test_commit same-msg foo b
- git checkout -b notsame HEAD^
- test_commit notsame-msg foo c
+ cat a -\EOF
Please do not add an extra space between the redirection operator
(e.g. , 2, etc.) and its operand. The same style violations
everywhere in this patch.
+ a
+ a
+ a
+ a
+ a
+ a
+ a
+ a
+ EOF
Please align EOF with the cat that receives it, and pretend that the
column the head of the cat is at is the leftmost column for the
payload, when writing - here-document, e.g.
cat a -\EOF
a
EOF
+ (cat a; echo b) ab
+ (echo d; cat a; echo b) dab
+ cp a foo
+ cp a bar
Probably a helper function would make it more apparent what is going
on?
as=a a a a a a a a # eight a
test_write_lines $as b ab
test_write_lines d $as b dab
test_write_lines $as foo
test_write_lines $as bar
Or even better, use test_write_lines in places you do use the result
to overwrite foo/bar and get rid of ab and dab?
That helper can also be used to prepare bar-then-foo.
test_expect_success 'patch-id output is well-formed' '
@@ -23,11 +57,33 @@ calc_patch_id () {
sed s# .*## patch-id_$1
}
+calc_patch_id_unstable () {
+ git patch-id --unstable |
+ sed s# .*## patch-id_$1
Not a new problem, but can you align git patch-id and sed to the
same column? Also, not using / when there is no slash involved in
the pattern makes readers waste their time wondering why the script
avoids it.
+}
+
+calc_patch_id_stable () {
+ git patch-id --stable |
+ sed s# .*## patch-id_$1
+}
+
+
Extra blank line.
get_patch_id () {
- git log -p -1 $1 | git patch-id |
+ git log -p -1 $1 -O bar-then-foo -- | git patch-id |
sed s# .*## patch-id_$1
}
+get_patch_id_stable () {
+ git log -p -1 $1 -O bar-then-foo | git patch-id --stable |
+ sed s# .*## patch-id_$1
Why doesn't it use calc_patch_id_stable?
+}
+
+get_patch_id_unstable () {
+ git log -p -1 $1 -O bar-then-foo | git patch-id --unstable |
+ sed s# .*## patch-id_$1
Ditto.
+}
+
+
Extra blank line.
test_expect_success 'patch-id detects equality' '
get_patch_id master
get_patch_id same
@@ -52,10 +108,55 @@ test_expect_success 'patch-id supports git-format-patch
output' '
test_expect_success 'whitespace is irrelevant in footer' '
get_patch_id master
git checkout same
- git format-patch -1 --stdout | sed s/ \$// | calc_patch_id same
+ git format-patch -1 --stdout | sed s/ \$// |
+ calc_patch_id same
What is this change about?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Am 28.03.2014 18:10, schrieb W. Trevor King: On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote: Am 28.03.2014 04:58, schrieb W. Trevor King: On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote: No the remote branch is in the upstream subproject. I suppose I meant “the submodule's remote-tracking branch following the upstream subproject's HEAD which we just fetched so it's fairly current” ;). Hmm, maybe we should change the existing “upstream submodule” to “upstream subproject” for consistency? For me it's still an upstream submodule ... We have a few existing “[upstream] subproject” references though. I prefer subproject, because the submodule's upstream repository is likely a bare repo and not a submodule itself. It's also possible (likely?) that the upstream repository is a stand-alone project, and not designed to always be a submodule. However, “upstream submodule” and “submodule's upstream” are both clear enough, and if they're the consensus phrasing, I'd rather standardize on them than jump back and forth between phrasings in the docs. I can write up a patch that shifts us to consistently use one form, once we decide what that should be (although I'm happy to let someone else write the patch too ;). Apart from the RelNotes there are only seven places in the Documentation directory where the term subproject is used: - Two in git-submodule.txt (which are those you recently added in the series that introduced the regression and would be gone if we revert that) - One in git-write-tree.txt (but as I understand it the --prefix option can be used to record tree objects for other tools too, so the more generic term subproject looks OK to me there) - Four occurrences in user-manual.txt describing the diff format for submodules (which I assume will always stay [+-]Subproject for backwards compatibility reasons) If we do not revert your series I'll be happy to write up a patch replacing the two usages of subproject in git-submodule.txt ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Am 28.03.2014 04:36, schrieb W. Trevor King:
gitmodule(5) mentioned 'master' as the default remote branch, but
folks using checkout-style updates are unlikely to care which upstream
branch their commit comes from (they only care that the clone fetches
that commit). If they haven't set submodule.name.branch, it makes
more sense to mirror 'git clone' and use the subproject's HEAD than to
default to 'master' (which may not even exist).
After the initial clone, subsequent updates may be local or remote.
Local updates (integrating gitlink changes) have no need to fetch a
specific remote branch, and get along just fine without
submodule.name.branch. Remote updates do need a remote branch, but
HEAD works as well here as it did for the initial clone.
Reported-by: Johan Herland jo...@herland.net
Signed-off-by: W. Trevor King wk...@tremily.us
---
This still needs tests, but it gets through the following fine:
rm -rf superproject subproject
mkdir subproject
(cd subproject
git init
echo 'Subproject' README
git add README
git commit -m 'Subproject commit'
git branch -m master next
)
mkdir superproject
(cd superproject
git init
git submodule add ../subproject submod
git commit -am 'Add submod'
)
(cd subproject
echo 'work work work' README
git commit -am 'Subproject commit 2'
)
(cd superproject
git submodule update --remote
git commit -am 'Add submod'
)
The main drawback to this approach is that we're changing a default,
but I agree with John's:
On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:
I expect in most cases where origin/master happens to be the Right
Answer, using the submodule's upstream's HEAD will yield the same
result.
so the default-change may not be particularly intrusive.
I'd prefer a solution that doesn't change any defaults for the
checkout use case (again). Maybe it is a better route to revert
this series, then add tests describing the current behavior for
checkout submodules as a next step before adding the branch mode
for rebase and merge users again?
Cheers,
Trevor
Documentation/git-submodule.txt | 2 +-
Documentation/gitmodules.txt| 5 +++--
git-submodule.sh| 11 ---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 46c1eeb..c485a17 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -284,7 +284,7 @@ OPTIONS
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote-tracking branch. The remote used
is branch's remote (`branch.name.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
+ The remote branch used defaults to `HEAD`, but the branch name may
be overridden by setting the `submodule.name.branch` option in
either `.gitmodules` or `.git/config` (with `.git/config` taking
precedence).
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f539e3f..1aecce9 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,8 +53,9 @@ submodule.name.update::
submodule.name.branch::
A remote branch name for tracking updates in the upstream submodule.
- If the option is not specified, it defaults to 'master'. See the
- `--remote` documentation in linkgit:git-submodule[1] for details.
+ If the option is not specified, it defaults to the subproject's
+ HEAD. See the `--remote` documentation in linkgit:git-submodule[1]
+ for details.
+
This branch name is also used for the local branch created by
non-checkout cloning updates. See the `update` documentation in
diff --git a/git-submodule.sh b/git-submodule.sh
index 6135cfa..5f08e6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -819,8 +819,8 @@ cmd_update()
name=$(module_name $sm_path) || exit
url=$(git config submodule.$name.url)
config_branch=$(get_submodule_config $name branch)
- branch=${config_branch:-master}
- local_branch=$branch
+ branch=${config_branch:-HEAD}
+ local_branch=$config_branch
if ! test -z $update
then
update_module=$update
@@ -860,7 +860,12 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- start_point=origin/${branch}
+ if test -n $config_branch
+ then
+ start_point=origin/$branch
+ else
+ start_point=
+ fi
module_clone $sm_path $name $url $reference
$depth
Re: [PATCH 3/3] test-lib: '--run' to run only specific tests
Junio C Hamano gitster at pobox.com writes: I would have to say that there is already an established pattern to pick ranges that normal people understand well and it would be silly to invent another more verbose way to express the same thing. You tell your Print Dialog which page to print with e.g. -4,7,9-12,15-, not =4 7 Would the same notation be insufficient for our purpose? You do not even have to worry about negation that way. That will do, especially if the numbers are in ascending order. We won't have the odd cases of including a test and removing it later on. I think we won't need a --neg flag to take the negation of the tests in that range? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] patch-id: make it stable against hunk reordering
Michael S. Tsirkin m...@redhat.com writes: though it does look like an unrelated enhancement to me. Agree? Yes, that is exactly why I said opens interesting opportunity and making it possible ;-) They are all very related, but they do not have to graduate as parts of the same series. The important thing is that the basic infrastructure of the new codepath is designed in such a way that it later allows us to reuse it in these changes. I'm queuing these three patches almost as-is (I think I tweaked the sizeof thing) on 'pu', without fixing the test styles and other issues I may have pointed out in my reviews myself, expecting further clean-ups. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] patch-id: document new behaviour
Michael S. Tsirkin m...@redhat.com writes: The hash used is mostly an internal implementation detail, isn't it? Yes, but that does not mean we can break people who keep an external database indexed with the patch-id by changing the default under them, and they can give --unstable option to work it around is a workaround, not a fix. Without this change, they did not have to do anything. I would imagine that most of these people will be using the plain vanilla git show output without any ordering or hunk splitting when coming up with such a key. A possible way forward to allow the configuration that corresponds to -Oorderfile while not breaking the existing users could be to make the patch-id --stable kick in automatically (of course, do this only when the user did not give the --unstable command line option to override) when we see the orderfile configuration in the repository, or when we see that the incoming patch looks like reordered (e.g. has multiple diff --git header lines that refer to the same path, or the set of files mentioned by the diff --git lines are not in ascending order), perhaps? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Fix misuses of nor in comments. (v3)
On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar jle...@google.com wrote: This version applies successfully to master, maint, next, and pu. The other patches in the previous version of this queue apply successfully without any changes. Signed-off-by: Justin Lebar jle...@google.com --- Makefile| 2 +- builtin/apply.c | 2 +- builtin/checkout.c | 2 +- builtin/log.c | 2 +- builtin/pack-objects.c | 2 +- column.c| 4 ++-- contrib/examples/git-checkout.sh| 2 +- contrib/examples/git-reset.sh | 4 ++-- contrib/fast-import/import-directories.perl | 4 ++-- delta.h | 2 +- diff.c | 2 +- git-am.sh | 2 +- gitweb/gitweb.perl | 2 +- http.h | 4 ++-- perl/Git/SVN.pm | 2 +- perl/Git/SVN/Migration.pm | 2 +- pkt-line.h | 8 remote.c| 2 +- sha1_file.c | 2 +- test-chmtime.c | 2 +- 20 files changed, 27 insertions(+), 27 deletions(-) snip diff --git a/http.h b/http.h index cd37d58..0a7d286 100644 --- a/http.h +++ b/http.h @@ -13,8 +13,8 @@ /* * We detect based on the cURL version if multi-transfer is * usable in this implementation and define this symbol accordingly. - * This is not something Makefile should set nor users should pass - * via CFLAGS. + * This shouldn't be be set by the Makefile or by the user (e.g. via + * CFLAGS). */ #undef USE_CURL_MULTI There's a rather minor typo here: be be Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #07; Fri, 28)
On 03/31/2014 07:56 PM, Ronnie Sahlberg wrote:
I am new to git, so sorry If I overlooked something.
I think there might be a race in ref_transaction_commit() when
deleting references.
/* Perform deletes now that updates are safely completed */
for (i = 0; i n; i++) {
struct ref_update *update = updates[i];
if (update-lock) {
delnames[delnum++] = update-lock-ref_name;
ret |= delete_ref_loose(update-lock, update-type);
}
}
ret |= repack_without_refs(delnames, delnum);
for (i = 0; i delnum; i++)
unlink_or_warn(git_path(logs/%s, delnames[i]));
These two blocks should be reordered so that you first delete the
actual refs first, while holding the lock and then release the lock
afterward ?
I think what you suggest is what is already being done. The locks of
references that are being deleted are not released until a few lines
after the code that you quoted:
for (i = 0; i n; i++)
if (updates[i]-lock)
unlock_ref(updates[i]-lock);
Before the code that you quoted, some locks are released, but only for
references being updated (not those being deleted).
But maybe I misunderstand your critique.
By the way, there *is* a race here, but it is a subtler one involving
the interaction between packed and loose references when references are
deleted.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1] commit: add --ignore-submodules[=when] parameter
Am 31.03.2014 20:58, schrieb Jens Lehmann:
Am 31.03.2014 02:07, schrieb Ronald Weiss:
The tests immediately revealed, that the patch was not complete. It
didn't work with commit message given on command line (-m). To make
that work, I had to also patch the index_differs_from function in
diff-lib.c.
Which is exactly the same function I have to tweak to make my
status/commit: always show staged submodules regardless of
ignore config patch work for git commit -m too ;-)
I was doing that slightly differently but it seems that your way
of adding the ignore_submodules_arg parameter could serve us
both. Will update my upcoming patch accordingly.
I've been hacking on that some more (I'll post it as soon as I
have all new tests up and running) and think we might be able to
handle that even easier. Please see below:
diff --git a/diff-lib.c b/diff-lib.c
index 2eddc66..fec5ad4 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -508,7 +508,8 @@ int do_diff_cache(const unsigned char *tree_sha1, struct
diff_options *opt)
return 0;
}
-int index_differs_from(const char *def, int diff_flags)
+int index_differs_from(const char *def, int diff_flags,
+ const char *ignore_submodules_arg)
{
struct rev_info rev;
struct setup_revision_opt opt;
@@ -520,6 +521,10 @@ int index_differs_from(const char *def, int diff_flags)
DIFF_OPT_SET(rev.diffopt, QUICK);
DIFF_OPT_SET(rev.diffopt, EXIT_WITH_STATUS);
rev.diffopt.flags |= diff_flags;
+if (ignore_submodules_arg) {
+DIFF_OPT_SET(rev.diffopt, OVERRIDE_SUBMODULE_CONFIG);
You'll have to do this unconditionally, as this option tells the
diff machinery to ignore any submodule configurations, which is
what we want in either case. But ...
+handle_ignore_submodules_arg(rev.diffopt,
ignore_submodules_arg);
+}
run_diff_index(rev, 1);
if (rev.pending.alloc)
free(rev.pending.objects);
... maybe the best way is to leave index_differs_from() unchanged
and call that function with the correct diff_flags instead:
+ int diff_flags = DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG;
+ if (ignore_submodule_arg
+ !strcmp(ignore_submodule_arg, all))
+ diff_flags |= DIFF_OPT_IGNORE_SUBMODULES;
+ commitable = index_differs_from(parent, diff_flags);
Not thoroughly tested yet, but that'd also prevent any fallout for
the two callsites of index_differs_from() in sequencer.c.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote: Am 28.03.2014 04:36, schrieb W. Trevor King: The main drawback to this approach is that we're changing a default, but I agree with John's: On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote: I expect in most cases where origin/master happens to be the Right Answer, using the submodule's upstream's HEAD will yield the same result. so the default-change may not be particularly intrusive. I'd prefer a solution that doesn't change any defaults for the checkout use case (again). Maybe it is a better route to revert this series, then add tests describing the current behavior for checkout submodules as a next step before adding the branch mode for rebase and merge users again? The change in defaults should only adversely effect users who: * don't configure submodule.name.branch, * use --remote updates, * expect them to pull the master branch of the submodule's upstream, and * have an upstream whose HEAD doesn't point at master. Since 23d25e4 (submodule: explicit local branch creation in module_clone, 2014-01-26), we adversely effects users (regardless of update strategy) who: * don't configure submodule.name.branch, and * update-clone from a submodule upstream that doesn't have a master branch. But with this patch we'll fix that. Before 23d25e4, we adversly affected users who: * used non-checkout update strategies, and * wanted an attached HEAD after update-clones. All of these were easy to work around, with either: $ git config submodule.$name.branch $branch or: $ cd $submod $ git checkout $branch I'm fine reverting 23d25e4 if we want to kick it around some more, but I have trouble imagining a future UI that works for both: * users that want --remote to pull master even though upstream's HEAD points elsewhere, and * users that want --remote to pull HEAD because upstream doesn't have a master branch, if neither of those users are willing to configure an explicit submodule.name.branch. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 2/3] patch-id: document new behaviour
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: The hash used is mostly an internal implementation detail, isn't it? Yes, but that does not mean we can break people who keep an external database indexed with the patch-id by changing the default under them, and they can give --unstable option to work it around is a workaround, not a fix. Without this change, they did not have to do anything. I would imagine that most of these people will be using the plain vanilla git show output without any ordering or hunk splitting when coming up with such a key. A possible way forward to allow the configuration that corresponds to -Oorderfile while not breaking the existing users could be to make the patch-id --stable kick in automatically (of course, do this only when the user did not give the --unstable command line option to override) when we see the orderfile configuration in the repository, or when we see that the incoming patch looks like reordered (e.g. has multiple diff --git header lines that refer to the same path, This would require us to track affected files in memory. Issue? or the set of files mentioned by the diff --git lines are not in ascending order), perhaps? I hope a patch-id configuration flag plus maybe checking the orderfile if not specified together should be good enough. -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] submodule: change submodule.name.branch default from master to HEAD
Jens Lehmann jens.lehm...@web.de writes: I'd prefer a solution that doesn't change any defaults for the checkout use case (again). Maybe it is a better route to revert this series, then add tests describing the current behavior for checkout submodules as a next step before adding the branch mode for rebase and merge users again? Sounds like a good idea to revert the entire series, as that would give us longer to think the whole thing through. It would certainly avoid unexpected fallout in 2.0 where we already have other changes, all of which are known/designed to be backward incompatible with a set of carefully planned transition plans. This submodule change may have meant well, but does not seem to sit well together with these other changes. Perhaps in 2.1 or 2.2. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: socket_perror() bug?
Thiago Farina tfrans...@gmail.com writes: In imap-send.c:socket_perror() we pass |func| as a parameter, which I think it is the name of the function that called socket_perror, or the name of the function which generated an error. But at line 184 and 187 it always assume it was SSL_connect. Should we instead call perror() and ssl_socket_error() with func? Looks that way to me, at least from a cursory look. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] Fix misuses of nor in comments.
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
column.c| 4 ++--
contrib/examples/git-checkout.sh| 2 +-
contrib/examples/git-reset.sh | 4 ++--
contrib/fast-import/import-directories.perl | 4 ++--
delta.h | 2 +-
diff.c | 2 +-
git-am.sh | 2 +-
gitweb/gitweb.perl | 2 +-
http.h | 3 +--
perl/Git/SVN.pm | 2 +-
perl/Git/SVN/Migration.pm | 2 +-
pkt-line.h | 8
remote.c| 2 +-
sha1_file.c | 2 +-
test-chmtime.c | 2 +-
20 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/Makefile b/Makefile
index dddaf4f..fc02788 100644
--- a/Makefile
+++ b/Makefile
@@ -159,7 +159,7 @@ all::
#
# Define NEEDS_LIBINTL_BEFORE_LIBICONV if you need libintl before libiconv.
#
-# Define NO_INTPTR_T if you don't have intptr_t nor uintptr_t.
+# Define NO_INTPTR_T if you don't have intptr_t or uintptr_t.
#
# Define NO_UINTMAX_T if you don't have uintmax_t.
#
diff --git a/builtin/apply.c b/builtin/apply.c
index b0d0986..6013e19 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -4061,7 +4061,7 @@ static int write_out_one_reject(struct patch *patch)
return error(_(cannot open %s: %s), namebuf, strerror(errno));
/* Normal git tools never deal with .rej, so do not pretend
-* this is a git patch by saying --git nor give extended
+* this is a git patch by saying --git or giving extended
* headers. While at it, maybe please kompare that wants
* the trailing TAB and some garbage at the end of line ;-).
*/
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ada51fa..7f37d1a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -895,7 +895,7 @@ static int parse_branchname_arg(int argc, const char **argv,
* between A and B, A...B names that merge base.
*
* (b) If something is _not_ a commit, either -- is present
-* or something is not a path, no -t nor -b was given, and
+* or something is not a path, no -t or -b was given, and
* and there is a tracking branch whose name is something
* in one and only one remote, then this is a short-hand to
* fork local something from that remote-tracking branch.
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..39e8836 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -503,7 +503,7 @@ static void show_rev_tweak_rev(struct rev_info *rev, struct
setup_revision_opt *
/* There was no -m on the command line */
rev-ignore_merges = 0;
if (!rev-first_parent_only !rev-combine_merges) {
- /* No --first-parent, -c, nor --cc */
+ /* No --first-parent, -c, or --cc */
rev-combine_merges = 1;
rev-dense_combined_merges = 1;
}
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 541667f..ef1f20e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -999,7 +999,7 @@ static int pbase_tree_cache_ix_incr(int ix)
static struct pbase_tree {
struct pbase_tree *next;
/* This is a phony cache entry; we are not
-* going to evict it nor find it through _get()
+* going to evict it or find it through _get()
* mechanism -- this is for the toplevel node that
* would almost always change with any commit.
*/
diff --git a/column.c b/column.c
index 9367ba5..8d1ce88 100644
--- a/column.c
+++ b/column.c
@@ -311,8 +311,8 @@ static int parse_config(unsigned int *colopts, const char
*value)
value += strspn(value, sep);
}
/*
-* Setting layout implies always if neither always, never
-* nor auto is specified.
+* If none of always, never, and auto is specified, then setting
+* layout implies always.
*
* Current value in COL_ENABLE_MASK is disregarded. This means if
* you set column.ui = auto and pass --column=row, then auto
diff --git a/contrib/examples/git-checkout.sh b/contrib/examples/git-checkout.sh
index 1a7689a..d2c1f98 100755
--- a/contrib/examples/git-checkout.sh
+++ b/contrib/examples/git-checkout.sh
@@ -168,7 +168,7 @@ cd_to_toplevel
# branch. However, if git checkout HEAD detaches the HEAD
# from the current branch, even
Re: [PATCH 3/4] Fix misuses of nor in comments. (v3)
Thanks; fixed in v4 (just sent out). On Mon, Mar 31, 2014 at 12:54 PM, Jason St. John jstj...@purdue.edu wrote: On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar jle...@google.com wrote: This version applies successfully to master, maint, next, and pu. The other patches in the previous version of this queue apply successfully without any changes. Signed-off-by: Justin Lebar jle...@google.com --- Makefile| 2 +- builtin/apply.c | 2 +- builtin/checkout.c | 2 +- builtin/log.c | 2 +- builtin/pack-objects.c | 2 +- column.c| 4 ++-- contrib/examples/git-checkout.sh| 2 +- contrib/examples/git-reset.sh | 4 ++-- contrib/fast-import/import-directories.perl | 4 ++-- delta.h | 2 +- diff.c | 2 +- git-am.sh | 2 +- gitweb/gitweb.perl | 2 +- http.h | 4 ++-- perl/Git/SVN.pm | 2 +- perl/Git/SVN/Migration.pm | 2 +- pkt-line.h | 8 remote.c| 2 +- sha1_file.c | 2 +- test-chmtime.c | 2 +- 20 files changed, 27 insertions(+), 27 deletions(-) snip diff --git a/http.h b/http.h index cd37d58..0a7d286 100644 --- a/http.h +++ b/http.h @@ -13,8 +13,8 @@ /* * We detect based on the cURL version if multi-transfer is * usable in this implementation and define this symbol accordingly. - * This is not something Makefile should set nor users should pass - * via CFLAGS. + * This shouldn't be be set by the Makefile or by the user (e.g. via + * CFLAGS). */ #undef USE_CURL_MULTI There's a rather minor typo here: be be Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Fix misuses of nor in comments.
Sorry, still figuring out the right workflow here: The subject should
say v4, and it should say patch 3/4.
On Mon, Mar 31, 2014 at 2:04 PM, Justin Lebar jle...@google.com wrote:
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
column.c| 4 ++--
contrib/examples/git-checkout.sh| 2 +-
contrib/examples/git-reset.sh | 4 ++--
contrib/fast-import/import-directories.perl | 4 ++--
delta.h | 2 +-
diff.c | 2 +-
git-am.sh | 2 +-
gitweb/gitweb.perl | 2 +-
http.h | 3 +--
perl/Git/SVN.pm | 2 +-
perl/Git/SVN/Migration.pm | 2 +-
pkt-line.h | 8
remote.c| 2 +-
sha1_file.c | 2 +-
test-chmtime.c | 2 +-
20 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/Makefile b/Makefile
index dddaf4f..fc02788 100644
--- a/Makefile
+++ b/Makefile
@@ -159,7 +159,7 @@ all::
#
# Define NEEDS_LIBINTL_BEFORE_LIBICONV if you need libintl before libiconv.
#
-# Define NO_INTPTR_T if you don't have intptr_t nor uintptr_t.
+# Define NO_INTPTR_T if you don't have intptr_t or uintptr_t.
#
# Define NO_UINTMAX_T if you don't have uintmax_t.
#
diff --git a/builtin/apply.c b/builtin/apply.c
index b0d0986..6013e19 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -4061,7 +4061,7 @@ static int write_out_one_reject(struct patch *patch)
return error(_(cannot open %s: %s), namebuf,
strerror(errno));
/* Normal git tools never deal with .rej, so do not pretend
-* this is a git patch by saying --git nor give extended
+* this is a git patch by saying --git or giving extended
* headers. While at it, maybe please kompare that wants
* the trailing TAB and some garbage at the end of line ;-).
*/
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ada51fa..7f37d1a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -895,7 +895,7 @@ static int parse_branchname_arg(int argc, const char
**argv,
* between A and B, A...B names that merge base.
*
* (b) If something is _not_ a commit, either -- is present
-* or something is not a path, no -t nor -b was given, and
+* or something is not a path, no -t or -b was given, and
* and there is a tracking branch whose name is something
* in one and only one remote, then this is a short-hand to
* fork local something from that remote-tracking branch.
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..39e8836 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -503,7 +503,7 @@ static void show_rev_tweak_rev(struct rev_info *rev,
struct setup_revision_opt *
/* There was no -m on the command line */
rev-ignore_merges = 0;
if (!rev-first_parent_only !rev-combine_merges) {
- /* No --first-parent, -c, nor --cc */
+ /* No --first-parent, -c, or --cc */
rev-combine_merges = 1;
rev-dense_combined_merges = 1;
}
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 541667f..ef1f20e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -999,7 +999,7 @@ static int pbase_tree_cache_ix_incr(int ix)
static struct pbase_tree {
struct pbase_tree *next;
/* This is a phony cache entry; we are not
-* going to evict it nor find it through _get()
+* going to evict it or find it through _get()
* mechanism -- this is for the toplevel node that
* would almost always change with any commit.
*/
diff --git a/column.c b/column.c
index 9367ba5..8d1ce88 100644
--- a/column.c
+++ b/column.c
@@ -311,8 +311,8 @@ static int parse_config(unsigned int *colopts, const char
*value)
value += strspn(value, sep);
}
/*
-* Setting layout implies always if neither always, never
-* nor auto is specified.
+* If none of always, never, and auto is specified, then setting
+* layout implies always.
*
* Current value in COL_ENABLE_MASK is disregarded. This means if
* you set column.ui = auto and pass --column=row, then auto
diff --git
Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues
On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote: SET_PTR() may not be used, but are there places where SET_INT() is abused with a cast-to-pointer for the same effect? I didn't check, but if there are such places, converting them to use SET_PTR() with their existing cast removed may be a better way to go. Anyone doing that should be beaten with a clue stick. Fortunately, I grepped through and I did not see any cases. My clue stick remains untouched. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] MSVC: fix t0040-parse-options crash
On Sun, Mar 30, 2014 at 10:29:04AM +0200, Andreas Schwab wrote: Junio C Hamano gits...@pobox.com writes: As OPT_SET_PTR() is about setting the pointer value to intptr_t defval, a follow-up patch on top of this fix (see attached) may not be a bad thing to have, but that patch alone will not fix this issue without dropping the unneeded and unwanted cast to unsigned long. Wouldn't it make sense to change defval into a union to avoid the cast? (The intptr_t type may be too narrow for other values to be put there.) The primary function of these structs is to capture the information found in brace initializers. Is it possible in C89 to initialize the second member of a union (I think in C99, you can use named initializers). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug report: git add . -p Argument list too long
Hi there, since a while when I want to stage diffs in one of my big repos with git add . -p” I get this error: Can't exec git: Argument list too long at /usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--interactive line 180. Died at /usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--interactive line 180. Mac OS X 10.9.2 git 1.9.1 (installed via homebrew) I’ve also tried the latest versions of the 1.7 and 1.8 branches which also yielded the same error in that repo. git add . -p works fine in other (smaller) repos. Unfortunately I’m not able to share this private repo. I found this rather old posting in the mailing list archive, unfortunately the link to the quick and easy fix” looks dead: http://article.gmane.org/gmane.comp.version-control.git/142863/match=argument+list+too+long+git+add Anybody can help? Thanks, Dieter -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/27] t1400: Provide more usual input to the command
Michael Haggerty mhag...@alum.mit.edu writes:
Subject: Re: [PATCH v2 02/27] t1400: Provide more usual input to the command
This applies to the patches throughout the series, but during the
microproject reviews, Eric pointed out that we seem to start the
summary after area: on the subject with lowercase and omit the full
stop at the end, so I'll try to tweak the subjects while queueing to
read patches in the series.
The old version was passing (among other things)
update SP refs/heads/c NUL NUL 0{40} NUL
to git update-ref -z --stdin to test whether the old-value check for
c is working. But the newvalue is empty, which is a bit off the
beaten track.
So, to be sure that we are testing what we want to test, provide an
actual newvalue on the update line.
Interesting. So the test used to expect failure, but we couldn't
tell if that was due to giving a Please update to this value which
is malformed, or I am giving 0{40} as the old value, telling you
that you have to make sure the ref does not exist which does not
hold because we already have that ref?
That would mean that the test may not have been testing the right
thing. A good change.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
t/t1400-update-ref.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index fa927d2..29391c6 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -912,7 +912,7 @@ test_expect_success 'stdin -z update refs works with
identity updates' '
test_expect_success 'stdin -z update refs fails with wrong old value' '
git update-ref $c $m
- printf $F update $a $m $m update $b $m $m update $c
$Z stdin
+ printf $F update $a $m $m update $b $m $m update $c $m
$Z stdin
test_must_fail git update-ref -z --stdin stdin 2err
grep fatal: Cannot lock the ref '''$c''' err
git rev-parse $m expect
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/27] t1400: Fix name and expected result of one test
Michael Haggerty mhag...@alum.mit.edu writes: The test stdin -z create ref fails with zero new value actually passes an empty new value, not a zero new value. So rename the test s/zero/empty/, and change the expected error from fatal: create $c given zero new value to fatal: create $c missing newvalue I have a feeling that zero new value might have been done by a non-native (like me) to say no new value; missing newvalue sounds like a good phrasing to use. Of course, this makes the test fail now, so mark it test_expect_failure. The failure will be fixed later in this patch series. That sounds somewhat strange. Why not just give a single-liner to update-ref.c instead? Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- t/t1400-update-ref.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh index 6ffd82f..fa927d2 100755 --- a/t/t1400-update-ref.sh +++ b/t/t1400-update-ref.sh @@ -827,10 +827,10 @@ test_expect_success 'stdin -z create ref fails with bad new value' ' test_must_fail git rev-parse --verify -q $c ' -test_expect_success 'stdin -z create ref fails with zero new value' ' +test_expect_failure 'stdin -z create ref fails with empty new value' ' printf $F create $c stdin test_must_fail git update-ref -z --stdin stdin 2err - grep fatal: create $c given zero new value err + grep fatal: create $c missing newvalue err test_must_fail git rev-parse --verify -q $c ' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/27] parse_arg(): Really test that argument is properly terminated
Michael Haggerty mhag...@alum.mit.edu writes:
Test that the argument is properly terminated by either whitespace or
a NUL character, even if it is quoted, to be consistent with the
non-quoted case. Adjust the tests to expect the new error message.
Add a docstring to the function, incorporating the comments that were
formerly within the function plus some added information.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/update-ref.c | 20 +++-
t/t1400-update-ref.sh | 4 ++--
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 1292cfe..02b5f95 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -62,16 +62,26 @@ static void update_store_old_sha1(struct ref_update
*update,
update-have_old = *oldvalue || line_termination;
}
+/*
+ * Parse one whitespace- or NUL-terminated, possibly C-quoted argument
+ * and append the result to arg. Return a pointer to the terminator.
+ * Die if there is an error in how the argument is C-quoted. This
+ * function is only used if not -z.
+ */
static const char *parse_arg(const char *next, struct strbuf *arg)
{
- /* Parse SP-terminated, possibly C-quoted argument */
- if (*next != '')
+ if (*next == '') {
+ const char *orig = next;
+
+ if (unquote_c_style(arg, next, next))
+ die(badly quoted argument: %s, orig);
+ if (*next !isspace(*next))
+ die(unexpected character after quoted argument: %s,
orig);
+ } else {
while (*next !isspace(*next))
strbuf_addch(arg, *next++);
- else if (unquote_c_style(arg, next, next))
- die(badly quoted argument: %s, next);
+ }
- /* Return position after the argument */
return next;
}
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 29391c6..774f8c5 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -356,10 +356,10 @@ test_expect_success 'stdin fails on badly quoted input'
'
grep fatal: badly quoted argument: \\\master err
'
-test_expect_success 'stdin fails on arguments not separated by space' '
+test_expect_success 'stdin fails on junk after quoted argument' '
echo create \$a\master stdin
test_must_fail git update-ref --stdin stdin 2err
- grep fatal: expected SP but got: master err
+ grep fatal: unexpected character after quoted argument:
\\\$a\\\master err
'
Interesting.
I would have expected that We used to check only one of the two
codepaths and the other was loose, fix it to be accompanied by So
here is an _addition_ to the test suite to validate the other case
that used to be loose, now tightened, not We update one existing
case. The test before and after the patch is about a c-quoted
string, so I am not sure if we are still testing the right thing.
The code in update-ref.c after the patch does look reasonable,
though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report: git add . -p Argument list too long
- Original Message - From: Dieter Komendera die...@komendera.com To: git@vger.kernel.org Sent: Monday, March 31, 2014 10:04 PM Subject: Bug report: git add . -p Argument list too long Hi there, since a while when I want to stage diffs in one of my big repos with git add . -p” I get this error: Can't exec git: Argument list too long at /usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--interactive line 180. Died at /usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--interactive line 180. Mac OS X 10.9.2 git 1.9.1 (installed via homebrew) I’ve also tried the latest versions of the 1.7 and 1.8 branches which also yielded the same error in that repo. git add . -p works fine in other (smaller) repos. Unfortunately I’m not able to share this private repo. I found this rather old posting in the mailing list archive, unfortunately the link to the quick and easy fix” looks dead: http://article.gmane.org/gmane.comp.version-control.git/142863/match=argument+list+too+long+git+add Anybody can help? Thanks, Dieter http://article.gmane.org/gmane.comp.version-control.git/136157 maybe? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/27] update_refs(): Fix constness
Michael Haggerty mhag...@alum.mit.edu writes:
Since full const correctness is beyond the ability of C's type system,
just put the const where it doesn't do any harm. A (struct ref_update
**) can be passed to a (struct ref_update * const *) argument, but not
to a (const struct ref_update **) argument.
Sounds good, but next time please try not to break lines inside a
single typename, which is somewhat unreadable ;-)
I'd suggest rewording s/Fix/tighten/. Because a patch that
changes constness can loosen constness to make things more correct,
git shortlog output that says if it is tightening or loosening
would be more informative than the one that says that it is fixing.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/update-ref.c | 2 +-
refs.c | 2 +-
refs.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index f6345e5..a8a68e8 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -14,7 +14,7 @@ static const char * const git_update_ref_usage[] = {
static int updates_alloc;
static int updates_count;
-static const struct ref_update **updates;
+static struct ref_update **updates;
static char line_termination = '\n';
static int update_flags;
diff --git a/refs.c b/refs.c
index 196984e..1305eb1 100644
--- a/refs.c
+++ b/refs.c
@@ -3306,7 +3306,7 @@ static int ref_update_reject_duplicates(struct
ref_update **updates, int n,
return 0;
}
-int update_refs(const char *action, const struct ref_update **updates_orig,
+int update_refs(const char *action, struct ref_update * const *updates_orig,
int n, enum action_on_err onerr)
{
int ret = 0, delnum = 0, i;
diff --git a/refs.h b/refs.h
index a713b34..08e60ac 100644
--- a/refs.h
+++ b/refs.h
@@ -228,7 +228,7 @@ int update_ref(const char *action, const char *refname,
/**
* Lock all refs and then perform all modifications.
*/
-int update_refs(const char *action, const struct ref_update **updates,
+int update_refs(const char *action, struct ref_update * const *updates,
int n, enum action_on_err onerr);
extern int parse_hide_refs_config(const char *var, const char *value, const
char *);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1] commit: add --ignore-submodules[=when] parameter
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de wrote: As Junio mentioned it would be great if you could teach the add command also honor the --ignore-submodule command line option in a companion patch. In the course of doing so you'll easily see if I was right or not, then please just order them in the most logical way. Well, if You (or Junio) really don't want my patch without another one for git add, I may try to do it. However, git add does not even honor the submodules' ignore setting from .gitmodules (just tested with git 1.9.1: git add -u doesn't honor it, while git commit -a does). So teaching git add the --ignore-submodules switch in current state doesn't seem right to me. You might propose to add also support for the ignore setting, to make add -u and commit -a more consistent. That seems like a good idea, but the effort needed is getting bigger, and nobody actually complains about lack of submodule ignoring facility in git add, while I know that the current behavior of commit really causes trouble. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add `ignore_missing_links` mode to revwalk
On 03/28/2014 03:00 AM, Jeff King wrote:
From: Vicent Marti tan...@gmail.com
When pack-objects is computing the reachability bitmap to
serve a fetch request, it can erroneously die() if some of
the UNINTERESTING objects are not present. Upload-pack
throws away HAVE lines from the client for objects we do not
have, but we may have a tip object without all of its
ancestors (e.g., if the tip is no longer reachable and was
new enough to survive a `git prune`, but some of its
reachable objects did get pruned).
Thanks for this patch. It looks pretty sensible.
Unfortunately, I can't provide feedback on running it in production
because we've decided to set aside experimenting with bitmaps for a bit.
I hope to get back to it in a couple of months.
In the non-bitmap case, we do a revision walk with the HAVE
objects marked as UNINTERESTING. The revision walker
explicitly ignores errors in accessing UNINTERESTING commits
to handle this case (and we do not bother looking at
UNINTERESTING trees or blobs at all).
When we have bitmaps, however, the process is quite
different. The bitmap index for a pack-objects run is
calculated in two separate steps:
First, we perform an extensive walk from all the HAVEs to
find the full set of objects reachable from them. This walk
is usually optimized away because we are expected to hit an
object with a bitmap during the traversal, which allows us
to terminate early.
Secondly, we perform an extensive walk from all the WANTs,
which usually also terminates early because we hit a commit
with an existing bitmap.
Once we have the resulting bitmaps from the two walks, we
AND-NOT them together to obtain the resulting set of objects
we need to pack.
When we are walking the HAVE objects, the revision walker
does not know that we are walking it only to mark the
results as uninteresting. We strip out the UNINTERESTING flag,
because those objects _are_ interesting to us during the
first walk. We want to keep going to get a complete set of
reachable objects if we can.
We need some way to tell the revision walker that it's OK to
silently truncate the HAVE walk, just like it does for the
UNINTERESTING case. This patch introduces a new
`ignore_missing_links` flag to the `rev_info` struct, which
we set only for the HAVE walk.
It also adds tests to cover UNINTERESTING objects missing
from several positions: a missing blob, a missing tree, and
a missing parent commit. The missing blob already worked (as
we do not care about its contents at all), but the other two
cases caused us to die().
Note that there are a few cases we do not need to test:
1. We do not need to test a missing tree, with the blob
still present. Without the tree that refers to it, we
would not know that the blob is relevant to our walk.
2. We do not need to test a tip commit that is missing.
Upload-pack omits these for us (and in fact, we
complain even in the non-bitmap case if it fails to do
so).
Reported-by: Siddharth Agarwal s...@fb.com
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
I believe this should solve the problem you're seeing, and I think any
solution is going to be along these lines.
This covers all code paths that can be triggered by pack-objects. But
it does not necessarily cover all code paths that a revision walker
might use (e.g., it is still possible to die in try_to_simplify_commit,
but we would never hit that in pack-objects, because we do not do
pathspec limiting).
So it's a tradeoff. On the one hand, leaving it like this creates a flag
in rev_info that may surprise somebody later by not being as generally
useful. On the other hand, covering every die() is extra code churn, and
creates complexity for cases that cannot actually be triggered in
practice (complexity because each site has to decide how to handle a
failure to access the object).
list-objects.c | 5 -
pack-bitmap.c | 2 ++
revision.c | 8 +---
revision.h | 3 ++-
t/t5310-pack-bitmaps.sh | 31 +++
5 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index 206816f..3595ee7 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -81,8 +81,11 @@ static void process_tree(struct rev_info *revs,
die(bad tree object);
if (obj-flags (UNINTERESTING | SEEN))
return;
- if (parse_tree(tree) 0)
+ if (parse_tree(tree) 0) {
+ if (revs-ignore_missing_links)
+ return;
die(bad tree object %s, sha1_to_hex(obj-sha1));
+ }
obj-flags |= SEEN;
show(obj, path, name, cb_data);
me.up = path;
diff --git a/pack-bitmap.c b/pack-bitmap.c
index ae0b57b..91e4101 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -727,8 +727,10 @@ int prepare_bitmap_walk(struct rev_info *revs)
revs-pending.objects = NULL;
Re: [PATCH v2 13/27] t1400: Test that stdin -z update treats empty newvalue as zeros
Michael Haggerty mhag...@alum.mit.edu writes:
This is the (slightly inconsistent) status quo; make sure it doesn't
change by accident.
Interesting. So oldvalue being empty is we do not care what it
is (as opposed to we know it must not exist yet aka 0{40}), and
newvalue being empty is the same as delete it aka 0{40}.
That is unfortunate, but I agree it is a good idea to add a test for
it, so that we will notice when we decide to fix it.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
t/t1400-update-ref.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index a2015d0..208f56e 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -730,6 +730,13 @@ test_expect_success 'stdin -z fails update with bad ref
name' '
grep fatal: invalid ref format: ~a err
'
+test_expect_success 'stdin -z treats empty new value as zeros' '
+ git update-ref $a $m
+ printf $F update $a stdin
+ git update-ref -z --stdin stdin
+ test_must_fail git rev-parse --verify -q $a
+'
+
test_expect_success 'stdin -z fails update with no new value' '
printf $F update $a stdin
test_must_fail git update-ref -z --stdin stdin 2err
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/27] t1400: Fix name and expected result of one test
On 03/31/2014 11:30 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The test
stdin -z create ref fails with zero new value
actually passes an empty new value, not a zero new value. So rename
the test s/zero/empty/, and change the expected error from
fatal: create $c given zero new value
to
fatal: create $c missing newvalue
I have a feeling that zero new value might have been done by a
non-native (like me) to say no new value; missing newvalue
sounds like a good phrasing to use.
Of course, this makes the test fail now, so mark it
test_expect_failure. The failure will be fixed later in this patch
series.
That sounds somewhat strange. Why not just give a single-liner to
update-ref.c instead?
This is because there really is a difference between the two errors, and
git update-ref tries to emit distinct error messages for them:
* zero new value means that the new value was 0{40}
* missing newvalue means that the new value was absent
The problem is that it is not distinguishing between these two cases
correctly, and fixing *that* is more than a one-liner.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/27] update-ref --stdin -z: Deprecate interpreting the empty string as zeros
Michael Haggerty mhag...@alum.mit.edu writes:
In the original version of this command, for the single case of the
update command's newvalue, the empty string was interpreted as
being equivalent to 40 0s. This shorthand is unnecessary (binary
input will usually be generated programmatically anyway), and it
complicates the parser and the documentation.
Nice.
So gently deprecate this usage: remove its description from the
documentation and emit a warning if it is found. But for reasons of
backwards compatibility, continue to accept it.
Helped-by: Brad King brad.k...@kitware.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-update-ref.txt | 18 --
builtin/update-ref.c | 2 ++
t/t1400-update-ref.sh| 5 +++--
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-update-ref.txt
b/Documentation/git-update-ref.txt
index 0a0a551..c8f5ae5 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -68,7 +68,12 @@ performs all modifications together. Specify commands of
the form:
option SP opt LF
Quote fields containing whitespace as if they were strings in C source
-code. Alternatively, use `-z` to specify commands without quoting:
+code; i.e., surrounded by double-quotes and with backslash escapes.
+Use 40 0 characters or the empty string to specify a zero value. To
+specify a missing value, omit the value and its preceding SP entirely.
+
+Alternatively, use `-z` to specify in NUL-terminated format, without
+quoting:
update SP ref NUL newvalue NUL [oldvalue] NUL
create SP ref NUL newvalue NUL
@@ -76,8 +81,12 @@ code. Alternatively, use `-z` to specify commands without
quoting:
verify SP ref NUL [oldvalue] NUL
option SP opt NUL
-Lines of any other format or a repeated ref produce an error.
-Command meanings are:
+In this format, use 40 0 to specify a zero value, and use the empty
+string to specify a missing value.
+
+In either format, values can be specified in any form that Git
+recognizes as an object name. Commands in any other format or a
+repeated ref produce an error. Command meanings are:
update::
Set ref to newvalue after verifying oldvalue, if given.
@@ -102,9 +111,6 @@ option::
The only valid option is `no-deref` to avoid dereferencing
a symbolic ref.
-Use 40 0 or the empty string to specify a zero value, except that
-with `-z` an empty oldvalue is considered missing.
-
If all refs can be locked with matching oldvalues
simultaneously, all modifications are performed. Otherwise, no
modifications are performed. Note that while each individual
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 6462b2f..eef7537 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -154,6 +154,8 @@ static int parse_next_sha1(struct strbuf *input, const
char **next,
goto invalid;
} else if (flags PARSE_SHA1_ALLOW_EMPTY) {
/* With -z, treat an empty value as all zeros: */
+ warning(%s %s: missing newvalue, treating as zero,
+ command, refname);
hashclr(sha1);
} else {
/*
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 15f5bfd..2d61cce 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -730,10 +730,11 @@ test_expect_success 'stdin -z fails update with bad ref
name' '
grep fatal: invalid ref format: ~a err
'
-test_expect_success 'stdin -z treats empty new value as zeros' '
+test_expect_success 'stdin -z emits warning with empty new value' '
git update-ref $a $m
printf $F update $a stdin
- git update-ref -z --stdin stdin
+ git update-ref -z --stdin stdin 2err
+ grep warning: update $a: missing newvalue, treating as zero err
test_must_fail git rev-parse --verify -q $a
'
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 18/27] update-ref --stdin: Harmonize error messages
Michael Haggerty mhag...@alum.mit.edu writes:
Make (most of) the error messages for invalid input have the same
format [1]:
$COMMAND [SP $REFNAME]: $MESSAGE
Update the tests accordingly.
[1] A few error messages are left with their old form, because
$COMMAND and $REFNAME aren't passed all the way down the call
stack. Maybe those sites should be changed some day, too.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Up to this point, modulo nits that have been pointed out separately,
the series looked reasonably well done.
Thanks.
builtin/update-ref.c | 24
t/t1400-update-ref.sh | 32
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index b49a5b0..bbc04b2 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -202,19 +202,19 @@ static const char *parse_cmd_update(struct strbuf
*input, const char *next)
update-ref_name = parse_refname(input, next);
if (!update-ref_name)
- die(update line missing ref);
+ die(update: missing ref);
if (parse_next_sha1(input, next, update-new_sha1,
update, update-ref_name,
PARSE_SHA1_ALLOW_EMPTY))
- die(update %s missing newvalue, update-ref_name);
+ die(update %s: missing newvalue, update-ref_name);
update-have_old = !parse_next_sha1(input, next, update-old_sha1,
update, update-ref_name,
PARSE_SHA1_OLD);
if (*next != line_termination)
- die(update %s has extra input: %s, update-ref_name, next);
+ die(update %s: extra input: %s, update-ref_name, next);
return next;
}
@@ -227,17 +227,17 @@ static const char *parse_cmd_create(struct strbuf
*input, const char *next)
update-ref_name = parse_refname(input, next);
if (!update-ref_name)
- die(create line missing ref);
+ die(create: missing ref);
if (parse_next_sha1(input, next, update-new_sha1,
create, update-ref_name, 0))
- die(create %s missing newvalue, update-ref_name);
+ die(create %s: missing newvalue, update-ref_name);
if (is_null_sha1(update-new_sha1))
- die(create %s given zero newvalue, update-ref_name);
+ die(create %s: zero newvalue, update-ref_name);
if (*next != line_termination)
- die(create %s has extra input: %s, update-ref_name, next);
+ die(create %s: extra input: %s, update-ref_name, next);
return next;
}
@@ -250,19 +250,19 @@ static const char *parse_cmd_delete(struct strbuf
*input, const char *next)
update-ref_name = parse_refname(input, next);
if (!update-ref_name)
- die(delete line missing ref);
+ die(delete: missing ref);
if (parse_next_sha1(input, next, update-old_sha1,
delete, update-ref_name, PARSE_SHA1_OLD)) {
update-have_old = 0;
} else {
if (is_null_sha1(update-old_sha1))
- die(delete %s given zero oldvalue,
update-ref_name);
+ die(delete %s: zero oldvalue, update-ref_name);
update-have_old = 1;
}
if (*next != line_termination)
- die(delete %s has extra input: %s, update-ref_name, next);
+ die(delete %s: extra input: %s, update-ref_name, next);
return next;
}
@@ -275,7 +275,7 @@ static const char *parse_cmd_verify(struct strbuf *input,
const char *next)
update-ref_name = parse_refname(input, next);
if (!update-ref_name)
- die(verify line missing ref);
+ die(verify: missing ref);
if (parse_next_sha1(input, next, update-old_sha1,
verify, update-ref_name, PARSE_SHA1_OLD)) {
@@ -286,7 +286,7 @@ static const char *parse_cmd_verify(struct strbuf *input,
const char *next)
}
if (*next != line_termination)
- die(verify %s has extra input: %s, update-ref_name, next);
+ die(verify %s: extra input: %s, update-ref_name, next);
return next;
}
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 1db0689..48ccc4d 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -371,7 +371,7 @@ test_expect_success 'stdin fails on junk after quoted
argument' '
test_expect_success 'stdin fails create with no ref' '
echo create stdin
test_must_fail git update-ref --stdin stdin 2err
- grep fatal: create line missing ref err
+ grep fatal: create: missing ref err
'
test_expect_success 'stdin fails create with bad ref name' '
@@ -383,19 +383,19 @@ test_expect_success
git am oddity
Hi, I noticed something very odd with git am, and have been able to narrow it down to a minimal example. git init tmp cd tmp mkdir -p foo/bar/baz cd foo/bar/baz echo file file git add file git commit -m 1 echo other other echo more file git add file other git commit -m my test git format-patch HEAD~.. git reset --hard HEAD~ # apply the patch in the current directory, chop off the leading directories git am -3 -p 3 0001-my-test.patch cd ../../.. git ls-files Expected output: foo/bar/baz/file foo/bar/baz/other Actual output: baz/other # the file addition was applied to the root of the repository, instead of the current directory foo/bar/baz/file # the file modification was correctly applied, yay Is this expected behavior? -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Fix misuses of nor in comments. (v3)
Justin Lebar jle...@google.com writes:
Thanks; fixed in v4 (just sent out).
I only saw [3/4] that was marked with (v3) at the end, without
[{1,2,4}/4]. As you seem to be renumbering from the very original
(which had l10n at number 3), only sending out what you changed,
expecting that everybody else knows what you are doing, is not very
friendly to anybody who is trying not to lose patches in all the
other activities on the list. Also people who haven't seen the
older iterations do not have to fish them from the archive if you
repost the whole thing.
Please use format-patch -v5 (or whatever numbering) so that the
series iteration number is inside, e.g. [PATCH v5 1/6].
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #07; Fri, 28)
Duy Nguyen pclo...@gmail.com writes: On Sat, Mar 29, 2014 at 5:21 AM, Junio C Hamano gits...@pobox.com wrote: * nd/gc-aggressive (2014-03-17) 4 commits - gc --aggressive: three phase repacking - gc --aggressive: make --depth configurable - pack-objects: support --keep - environment.c: fix constness for odb_pack_keep() Using --before=1.year.ago my way does not keep all recent chains short because commit time is unreliable. But even with better recent object selection, the performance gain is still within noise level. I suggest we keep gc --aggressive: make --depth configurable and drop the rest. I think the three-phase thing may not be so well conceived or cooked, but the other three looked like reasonable changes, although it would have been easier to say so if pack-objects --keep were done without a new buffer of size PATH_MAX ;-) Let's do the const and --depth and discard the other two. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] patch-id: make it stable against hunk reordering
Michael S. Tsirkin m...@redhat.com writes:
+ memcpy(ctx, header_ctx,
sizeof ctx);
+ } else {
+ /* Save header ctx for next
hunk. */
+ memcpy(header_ctx, ctx,
sizeof ctx);
I'll fix these to sizeof(ctx) when queuing.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] Fix misuses of nor in comments
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
column.c| 4 ++--
contrib/examples/git-checkout.sh| 2 +-
contrib/examples/git-reset.sh | 4 ++--
contrib/fast-import/import-directories.perl | 4 ++--
delta.h | 2 +-
diff.c | 2 +-
git-am.sh | 2 +-
gitweb/gitweb.perl | 2 +-
http.h | 3 +--
perl/Git/SVN.pm | 2 +-
perl/Git/SVN/Migration.pm | 2 +-
pkt-line.h | 8
remote.c| 2 +-
sha1_file.c | 2 +-
test-chmtime.c | 2 +-
20 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/Makefile b/Makefile
index dddaf4f..fc02788 100644
--- a/Makefile
+++ b/Makefile
@@ -159,7 +159,7 @@ all::
#
# Define NEEDS_LIBINTL_BEFORE_LIBICONV if you need libintl before libiconv.
#
-# Define NO_INTPTR_T if you don't have intptr_t nor uintptr_t.
+# Define NO_INTPTR_T if you don't have intptr_t or uintptr_t.
#
# Define NO_UINTMAX_T if you don't have uintmax_t.
#
diff --git a/builtin/apply.c b/builtin/apply.c
index b0d0986..6013e19 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -4061,7 +4061,7 @@ static int write_out_one_reject(struct patch *patch)
return error(_(cannot open %s: %s), namebuf, strerror(errno));
/* Normal git tools never deal with .rej, so do not pretend
-* this is a git patch by saying --git nor give extended
+* this is a git patch by saying --git or giving extended
* headers. While at it, maybe please kompare that wants
* the trailing TAB and some garbage at the end of line ;-).
*/
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ada51fa..7f37d1a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -895,7 +895,7 @@ static int parse_branchname_arg(int argc, const char **argv,
* between A and B, A...B names that merge base.
*
* (b) If something is _not_ a commit, either -- is present
-* or something is not a path, no -t nor -b was given, and
+* or something is not a path, no -t or -b was given, and
* and there is a tracking branch whose name is something
* in one and only one remote, then this is a short-hand to
* fork local something from that remote-tracking branch.
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..39e8836 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -503,7 +503,7 @@ static void show_rev_tweak_rev(struct rev_info *rev, struct
setup_revision_opt *
/* There was no -m on the command line */
rev-ignore_merges = 0;
if (!rev-first_parent_only !rev-combine_merges) {
- /* No --first-parent, -c, nor --cc */
+ /* No --first-parent, -c, or --cc */
rev-combine_merges = 1;
rev-dense_combined_merges = 1;
}
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 541667f..ef1f20e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -999,7 +999,7 @@ static int pbase_tree_cache_ix_incr(int ix)
static struct pbase_tree {
struct pbase_tree *next;
/* This is a phony cache entry; we are not
-* going to evict it nor find it through _get()
+* going to evict it or find it through _get()
* mechanism -- this is for the toplevel node that
* would almost always change with any commit.
*/
diff --git a/column.c b/column.c
index 9367ba5..8d1ce88 100644
--- a/column.c
+++ b/column.c
@@ -311,8 +311,8 @@ static int parse_config(unsigned int *colopts, const char
*value)
value += strspn(value, sep);
}
/*
-* Setting layout implies always if neither always, never
-* nor auto is specified.
+* If none of always, never, and auto is specified, then setting
+* layout implies always.
*
* Current value in COL_ENABLE_MASK is disregarded. This means if
* you set column.ui = auto and pass --column=row, then auto
diff --git a/contrib/examples/git-checkout.sh b/contrib/examples/git-checkout.sh
index 1a7689a..d2c1f98 100755
--- a/contrib/examples/git-checkout.sh
+++ b/contrib/examples/git-checkout.sh
@@ -168,7 +168,7 @@ cd_to_toplevel
# branch. However, if git checkout HEAD detaches the HEAD
# from the current branch, even
Re: [PATCH v2 13/27] t1400: Test that stdin -z update treats empty newvalue as zeros
On 03/31/2014 11:48 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This is the (slightly inconsistent) status quo; make sure it doesn't
change by accident.
Interesting. So oldvalue being empty is we do not care what it
is (as opposed to we know it must not exist yet aka 0{40}), and
newvalue being empty is the same as delete it aka 0{40}.
That is unfortunate, but I agree it is a good idea to add a test for
it, so that we will notice when we decide to fix it.
Correct. This was discussed at some more length here [1]. In v1 of
this patch series I incorrectly changed this behavior, thinking it to
have been an accident.
Michael
[1]
http://thread.gmane.org/gmane.comp.version-control.git/243731/focus=243773
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/4] Fix misuses of nor outside comments and in tests
Justin Lebar jle...@google.com writes:
diff --git a/builtin/clean.c b/builtin/clean.c
index 5502957..977a068 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -903,11 +903,11 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (!interactive !dry_run !force) {
if (config_set)
- die(_(clean.requireForce set to true and neither -i,
-n nor -f given;
+ die(_(clean.requireForce set to true and neither -i,
-n, nor -f given;
Encouraging Oxford/Harvard comma may or may not be desirable; it
does not seem to be a good idea to mix it in a patch to fix the
misuse of nor, I would think.
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 62f3293..a59564f 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -480,8 +480,8 @@ sub refname {
# It cannot end with a slash /, we'll throw up on this because
# SVN can't have directories with a slash in their name, either:
if ($refname =~ m{/$}) {
- die ref: '$refname' ends with a trailing slash, this is ,
- not permitted by git nor Subversion\n;
+ die ref: '$refname' ends with a trailing slash; this is ,
+ not permitted by git or Subversion\n;
This s/,/;/ is a good change that would not be controversial.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/27] t1400: Test one mistake at a time
On 03/31/2014 11:50 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: This case wants to test passing a bad refname to the update command. But it also passes too few arguments to update, which muddles the situation: which error should be diagnosed? So split this test into two: * One that passes too few arguments to update * One that passes all three arguments to update, but with a bad refname. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu t1400: Add a test of update with too few arguments Signed-off-by: Michael Haggerty mhag...@alum.mit.edu What's happening here? That was a squashing accident, also pointed out by Brad [1]. The last three lines should be deleted. This and an error in a comment in patch 14/27 that was also pointed out by Brad are both fixed in my GitHub repo [2]. I haven't sent the fixed version to the list, though; let me know if I should. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/245205 [2] Branch ref-transactions at https://github.com/mhagger/git -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/27] update_refs(): Fix constness
Michael Haggerty mhag...@alum.mit.edu writes: On 03/31/2014 11:40 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Since full const correctness is beyond the ability of C's type system, just put the const where it doesn't do any harm. A (struct ref_update **) can be passed to a (struct ref_update * const *) argument, but not to a (const struct ref_update **) argument. Sounds good, but next time please try not to break lines inside a single typename, which is somewhat unreadable ;-) I'd suggest rewording s/Fix/tighten/. Because a patch that changes constness can loosen constness to make things more correct, git shortlog output that says if it is tightening or loosening would be more informative than the one that says that it is fixing. It is not a strict tightening, because I add a const in one place but remove it from another: const struct ref_update ** becomes struct ref_update * const * in the update_refs() signature. In fact, the old declaration was too strict for some changes later in the patch series, which is why I needed to loosen (one aspect) of it. Interesting. Then that _is_ a fix. Thanks for explaining it to me. As always, I would prefer it be explained to the proposed commit log, not to me over an e-mail ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git am oddity
On Mon, Mar 31, 2014 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote: As you are doing -3 (not the -p3), it would have: * noticed that the patch is trying to update baz/file; * noticed that there is no baz/file but it could salvage the patch by doing a three-way merge, in case that the patch was prepared against a tree that moved path foo/bar/baz to baz; and * such a three-way merge succeeds cleanly for a path whose movement was detected correctly. So it does not look odd at all to me (the use of -p 3 does look odd, but I know this is an effort to come up with a minimum example, so it is understandable that it may look contribed ;-). Ah, we were thinking that 'git am' (when run from a subdirectory), would apply the patches from the current directory. So the right solution was to instead do: $ git am --directory=foo/bar/baz -p 3 0001-my-test.patch Thank you, -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1] commit: add --ignore-submodules[=when] parameter
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de wrote:
As Junio mentioned it would be great if you could teach the add
command also honor the --ignore-submodule command line option in
a companion patch. In the course of doing so you'll easily see if
I was right or not, then please just order them in the most logical
way.
Well, if You (or Junio) really don't want my patch without another one
for git add, I may try to do it. However, git add does not even honor
the submodules' ignore setting from .gitmodules (just tested with git
1.9.1: git add -u doesn't honor it, while git commit -a does). So
teaching git add the --ignore-submodules switch in current state
doesn't seem right to me. You might propose to add also support for
the ignore setting, to make add -u and commit -a more consistent.
That seems like a good idea, but the effort needed is getting bigger,
Well, now I actually looked at it, and it was pretty easy after all.
The changes below seem to enable support for both ignore setting in
.gitmodules, and also --ignore-submodules switch, for git add, on top
of my patch for commit.
So I'm going to do some more testing, write tests for git add with
ignoring submodules the various ways, and then post two patches
rearranged, one for git add, and second for git commit on top of that,
as you guys suggested. Including the change suggested by Jens, to not
mess with index_differs_from() in diff-lib.c, that works fine too.
diff --git a/builtin/add.c b/builtin/add.c
index 1086294..9f70327 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -350,6 +350,8 @@ static int ignore_add_errors, intent_to_add, ignore_missing;
static int addremove = ADDREMOVE_DEFAULT;
static int addremove_explicit = -1; /* unspecified */
+static char *ignore_submodule_arg;
+
static int ignore_removal_cb(const struct option *opt, const char *arg, int
unset)
{
/* if we are told to ignore, we are not adding removals */
@@ -375,6 +377,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL( 0 , refresh, refresh_only, N_(don't add, only refresh the
index)),
OPT_BOOL( 0 , ignore-errors, ignore_add_errors, N_(just skip files
which cannot be added because of errors)),
OPT_BOOL( 0 , ignore-missing, ignore_missing, N_(check if - even
missing - files are ignored in dry run)),
+ { OPTION_STRING, 0, ignore-submodules, ignore_submodule_arg,
N_(when),
+ N_(ignore changes to submodules, optional when: all, none. (Default:
all)),
+ PARSE_OPT_OPTARG, NULL, (intptr_t)all },
OPT_END(),
};
@@ -422,6 +427,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int implicit_dot = 0;
struct update_callback_data update_data;
+ gitmodules_config();
git_config(add_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_add_options,
@@ -584,7 +590,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
memset(pathspec, 0, sizeof(pathspec));
}
update_data.flags = flags ~ADD_CACHE_IMPLICIT_DOT;
- update_files_in_cache(prefix, pathspec, update_data, NULL);
+ update_files_in_cache(prefix, pathspec, update_data,
ignore_submodule_arg);
exit_status |= !!update_data.add_errors;
if (add_new_files)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] Take four on fixing OPT_SET_PTR issues
Jeff King p...@peff.net writes: On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote: SET_PTR() may not be used, but are there places where SET_INT() is abused with a cast-to-pointer for the same effect? I didn't check, but if there are such places, converting them to use SET_PTR() with their existing cast removed may be a better way to go. Anyone doing that should be beaten with a clue stick. Fortunately, I grepped through and I did not see any cases. My clue stick remains untouched. Yeah, I quickly did the same after sending the message out. Perhaps instead of taking all these three patches, it may be a good idea to just queue a single patch to remove both the feature and the string (unset) bit from the test. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] Documentation: Fix misuses of nor
Four patches queued on 'pu' as-is (but retitled). I didn't read everything very carefully, though. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1] commit: add --ignore-submodules[=when] parameter
On 1. 4. 2014 0:50, Ronald Weiss wrote:
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de wrote:
As Junio mentioned it would be great if you could teach the add
command also honor the --ignore-submodule command line option in
a companion patch. In the course of doing so you'll easily see if
I was right or not, then please just order them in the most logical
way.
Well, if You (or Junio) really don't want my patch without another one
for git add, I may try to do it. However, git add does not even honor
the submodules' ignore setting from .gitmodules (just tested with git
1.9.1: git add -u doesn't honor it, while git commit -a does). So
teaching git add the --ignore-submodules switch in current state
doesn't seem right to me. You might propose to add also support for
the ignore setting, to make add -u and commit -a more consistent.
That seems like a good idea, but the effort needed is getting bigger,
Well, now I actually looked at it, and it was pretty easy after all.
The changes below seem to enable support for both ignore setting in
.gitmodules, and also --ignore-submodules switch, for git add, on top
of my patch for commit.
There is a catch. With the changes below, submodules are ignored by add
even if explitely named on command line (eg. git add x does nothing if
x is submodule with new commits, but with ignore=all in .gitmodules).
That doesn't seem right.
Any ideas, what to do about that? When exactly should such submodule be
actually ignored?
So I'm going to do some more testing, write tests for git add with
ignoring submodules the various ways, and then post two patches
rearranged, one for git add, and second for git commit on top of that,
as you guys suggested. Including the change suggested by Jens, to not
mess with index_differs_from() in diff-lib.c, that works fine too.
diff --git a/builtin/add.c b/builtin/add.c
index 1086294..9f70327 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -350,6 +350,8 @@ static int ignore_add_errors, intent_to_add, ignore_missing;
static int addremove = ADDREMOVE_DEFAULT;
static int addremove_explicit = -1; /* unspecified */
+static char *ignore_submodule_arg;
+
static int ignore_removal_cb(const struct option *opt, const char *arg, int
unset)
{
/* if we are told to ignore, we are not adding removals */
@@ -375,6 +377,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL( 0 , refresh, refresh_only, N_(don't add, only refresh the
index)),
OPT_BOOL( 0 , ignore-errors, ignore_add_errors, N_(just skip files
which cannot be added because of errors)),
OPT_BOOL( 0 , ignore-missing, ignore_missing, N_(check if - even
missing - files are ignored in dry run)),
+ { OPTION_STRING, 0, ignore-submodules, ignore_submodule_arg,
N_(when),
+ N_(ignore changes to submodules, optional when: all, none. (Default:
all)),
+ PARSE_OPT_OPTARG, NULL, (intptr_t)all },
OPT_END(),
};
@@ -422,6 +427,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int implicit_dot = 0;
struct update_callback_data update_data;
+ gitmodules_config();
git_config(add_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_add_options,
@@ -584,7 +590,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
memset(pathspec, 0, sizeof(pathspec));
}
update_data.flags = flags ~ADD_CACHE_IMPLICIT_DOT;
- update_files_in_cache(prefix, pathspec, update_data, NULL);
+ update_files_in_cache(prefix, pathspec, update_data,
ignore_submodule_arg);
exit_status |= !!update_data.add_errors;
if (add_new_files)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Mar 2014, #08; Mon, 31)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. More topics merged to 'master', some of which are fallouts from GSoC microprojects, some are updates to docs. C/C++ funcname pattern update is now in. I haven't reverted the merge of that submodule update topic yet; I should do that soonish. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * an/branch-config-message (2014-03-24) 1 commit (merged to 'next' on 2014-03-26 at 26f9741) + branch.c: install_branch_config: simplify if chain * ca/doc-config-third-party (2014-03-21) 1 commit (merged to 'next' on 2014-03-25 at 731e011) + config.txt: third-party tools may and do use their own variables * dp/makefile-charset-lib-doc (2014-03-23) 1 commit (merged to 'next' on 2014-03-25 at b32e3ad) + Makefile: describe CHARSET_LIB better * dt/tests-with-env-not-subshell (2014-03-19) 1 commit (merged to 'next' on 2014-03-25 at 19fe25f) + tests: use env to run commands with temporary env-var settings (this branch is used by jk/tests-cleanup.) * dw/doc-status-no-longer-shows-pound-prefix (2014-03-21) 1 commit (merged to 'next' on 2014-03-25 at 2683eb6) + doc: status, remove leftover statement about '#' prefix * hs/simplify-bit-setting-in-fsck-tree (2014-03-20) 1 commit (merged to 'next' on 2014-03-25 at 08efd68) + fsck: use bitwise-or assignment operator to set flag * ib/rev-parse-parseopt-argh (2014-03-23) 2 commits (merged to 'next' on 2014-03-25 at d9083ed) + t1502: protect runs of SPs used in the indentation + rev-parse --parseopt: option argument name hints (this branch is used by jc/rev-parse-argh-dashed-multi-words.) Teaches the rev-parse --parseopt mechanism used by scripted Porcelains to parse command line options and give help text how to supply argv-help (the placeholder string for an option parameter, e.g. key-id in --gpg-sign=key-id). * jk/tests-cleanup (2014-03-21) 12 commits (merged to 'next' on 2014-03-26 at 4a72b49) + t0001: drop subshells just for cd + t0001: drop useless subshells + t0001: use test_must_fail + t0001: use test_config_global + t0001: use test_path_is_* + t0001: make symlink reinit test more careful + t: prefer git config --file to GIT_CONFIG + t: prefer git config --file to GIT_CONFIG with test_must_fail + t: stop using GIT_CONFIG to cross repo boundaries + t: drop useless sane_unset GIT_* calls + t/test-lib: drop redundant unset of GIT_CONFIG + t/Makefile: stop setting GIT_CONFIG (this branch uses dt/tests-with-env-not-subshell.) * js/userdiff-cc (2014-03-21) 10 commits (merged to 'next' on 2014-03-25 at 8c0e585) + userdiff: have 'cpp' hunk header pattern catch more C++ anchor points + t4018: test cases showing that the cpp pattern misses many anchor points + t4018: test cases for the built-in cpp pattern + t4018: reduce test files for pattern compilation tests + t4018: convert custom pattern test to the new infrastructure + t4018: convert java pattern test to the new infrastructure + t4018: convert perl pattern tests to the new infrastructure + t4018: an infrastructure to test hunk headers + userdiff: support unsigned and long long suffixes of integer constants + userdiff: support C++ -* and .* operators in the word regexp Improves the pattern to match the hunk-header for C/C++. * mm/status-porcelain-format-i18n-fix (2014-03-26) 1 commit (merged to 'next' on 2014-03-26 at 41680fc) + status: disable translation when --porcelain is used * mr/msvc-link-with-lcurl (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at 3281dab) + MSVC: allow linking with the cURL library * wt/doc-submodule-name-path-confusion-1 (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at 225f241) + doc: submodule.* config are keyed by submodule names * wt/doc-submodule-name-path-confusion-2 (2014-03-27) 1 commit (merged to 'next' on 2014-03-28 at ec5bcf3) + doc: submodule.*.branch config is keyed by name -- [New Topics] * cb/aix (2014-03-31) 2 commits - tests: don't rely on strerror text when testing rmdir failure - dir.c: make git_fnmatch() not inline Will merge to 'next'. * jc/fix-diff-no-index-diff-opt-parse (2014-03-31) 1 commit - diff-no-index: correctly diagnose error return from diff_opt_parse() diff --no-index -Mq a b fell into an infinite loop. Will merge to 'next'. * mr/opt-set-ptr (2014-03-31) 3 commits - parse-options: remove unused OPT_SET_PTR - parse-options: add cast to correct pointer type to OPT_SET_PTR - MSVC: fix t0040-parse-options crash OPT_SET_PTR() implementation was broken on IL32P64 platforms. We may just want directly to go to the endgame of removing OPT_SET_PTR macro, which nobody
Re: What's cooking in git.git (Mar 2014, #08; Mon, 31)
On Tue, Apr 1, 2014 at 7:29 AM, Junio C Hamano gits...@pobox.com wrote: * nd/multiple-work-trees (2014-03-25) 28 commits - count-objects: report unused files in $GIT_DIR/repos/... - gc: support prune --repos - gc: style change -- no SP before closing bracket - prune: strategies for linked checkouts - checkout: detach if the branch is already checked out elsewhere - checkout: clean up half-prepared directories in --to mode - checkout: support checking out into a new working directory - use new wrapper write_file() for simple file writing - wrapper.c: wrapper to open a file, fprintf then close - setup.c: support multi-checkout repo setup - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() - setup.c: convert check_repository_format_gently to use strbuf - setup.c: detect $GIT_COMMON_DIR in is_git_directory() - setup.c: convert is_git_directory() to use strbuf - git-stash: avoid hardcoding $GIT_DIR/logs/ - *.sh: avoid hardcoding $GIT_DIR/hooks/... - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects - $GIT_COMMON_DIR: a new environment variable - commit: use SEQ_DIR instead of hardcoding sequencer - fast-import: use git_path() for accessing .git dir instead of get_git_dir() - reflog: avoid constructing .lock path with git_path - *.sh: respect $GIT_INDEX_FILE - git_path(): be aware of file relocation in $GIT_DIR - path.c: group git_path(), git_pathdup() and strbuf_git_path() together - path.c: rename vsnpath() to do_git_path() - git_snpath(): retire and replace with strbuf_git_path() - path.c: make get_pathname() call sites return const char * - path.c: make get_pathname() return strbuf instead of static buffer A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. What is the doneness of this thing? I remember reading it through once and sent review comments on earlier parts, but have there been a lot of discussions on this topic? The basic support is there. Some bells and whistles (e.g. listing checkouts) are not, but we can add them when we see the needs. Eric and Torsten helped review but no, there hasn't much discussion about it, which may be because it's already perfect, or people are not interested. Unfortunately, this multiple checkout thing conflicts with how I use emacs (--daemon) so I'm not one of its heavy users either. I only occastionally make new, short-lived checkouts to test things. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
