Re: [PATCH v2 12/19] mingw: skip test in t1508 that fails due to path conversion
Hi Junio, On Wed, 27 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Tue, 26 Jan 2016, Junio C Hamano wrote: > > > >> Johannes Schindelin writes: > >> > >> > -git checkout -b @/at-test && > >> > +if ! test_have_prereq MINGW > >> > +then > >> > +git checkout -b @/at-slash > >> > >> I presume that this is meant to be "@/at-test", not "@/at-slash". > > > > Oh my. That's what you get for redoing patches from scratch. Sorry about > > that! > > Heh. That is why it makes me feel uneasy, after asking you to fetch > from me and fix it up, to hear that you will send in a new reroll. I should have mentioned that I did rebase what your pu carries onto my changes locally and found that the only differences were the consistency tweaks (such as not adding the empty line pointed out by Eric, and such as using !MINGW through-out). Ciao, Dscho -- 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 1/2] merge-file: let conflict markers match end-of-line style of the context
Hi Junio, On Wed, 27 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > [administrivia: I finally managed to correct e-mail address of peff@, > which has been giving me bounces for all the previous messages in > the thread] Oops! I got those bounces myself, but wrote them off to Eric's account without checking (because I consistently had problems sending emails to him in the past). Sorry about that. > > Your response is also an indicator to me that future myself will find the > > same code just as confusing as you did, though. > > > > Maybe need_cr -> eol_is_crlf? > > The crucial question is how well the variable conveys its meaning > when it has -1 as its value. "need_cr? -- I don't know yet" is as > clear as "eol_is_crlf? -- I don't know yet", if not clearer. I > personally do not think "eol_is_crlf" is an improvement. Okay, then. Let's keep the "needs_cr" name. Ciao, Dscho > it unclear _whose_ eol the variable is talking about. It can be > misread as talking about one or more of the files that are being > merged and mistaken as a statement of a fact (i.e. "we inspected > and know the input file's eol is CRLF"). > > Compared to that, it is clear that "need_cr" is talking about what > the EOL convention the resulting file should be. > > I briefly wondered if the if/if (need_cr)/... cascade that inspects > (conditionally up to) three variants might become cleaner if the > polarity of that variable is flipped (we are allowed to use CRLF > only when we know that among all of the three variants that we can > determine the line termination convention used, all of them use > CRLF), but I didn't think it through seriously. > > > > > -- > 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: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest
On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > I wonder what would break if we ask this question instead: > > > > We do not know if the working tree file and the indexed data > > match. Let's see if "git checkout" of that path would leave the > > same data as what currently is in the working tree file. If we do this, then git diff should show the diff between convert_to_worktree(index state) and the worktree state. That would be nice, because the diff would actually show what we have in the worktree. It keeps confusing me that with eol conversion enabled, git diff does not actually show me the worktree state. However, even if the file is clean in that direction, there could be a mismatch between convert_to_git(worktree state) and the index state. This will happen for example in t0025.4, where we have a CRLF file in the index and the worktree, but convert_to_git converts it to a file with LF line endings. Still, I do not see a problem if we also provide a command like git add --fix-index, which will force normalization of all files. > > If we did this, "reset --hard HEAD" followed by "diff HEAD" will by > > definition always report "is clean" as long as nobody changes files > > in the working tree, even with the inconsistent data in the index. Yes, this is a more elegant and a more complete solution to the problem which prompted me to submit the GIT_ATTRIBUTES_DISABLED patch. > > This still requires that convert_to_working_tree(), i.e. your smudge > > filter, is deterministic, though, but I think that is a sensible > > assumption for sane people, even for those with inconsistent data in > > the index. Deterministic, yes. But not unchanging. When a smudge filter is added, or modified, or if the filter program changes, we still have to remove the index before we can trust git diff again. The only way to avoid this would be to somehow detect if the conversion itself changes. One could hash the attributes, but changes to the filter configuration or the filter itself are hard to detect. So I think we have to live with this. > [...] Doing the other check will have to > inflate the blob data and apply the convert_to_working_tree() > processing, and also read the whole thing from the filesystem and > compare, which is more work at runtime. If we assume that the smudge filter is deterministic, then we could also hash the output of convert_to_working_tree, and store the hash in the index. With this optimization, the comparision would be less work, because we do not have to apply a filter again, whereas currently we have to apply convert_to_git. > IOW, I am saying that the "add --fix-index" lunchbreak patch I sent > earlier in the thread that has to hold the data in-core while > processing is not a production quality patch ;-) Ok. The existing implementation in renormalize_buffer (convert.c) works for me, 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: eol round trip Was: [PATCH] travis-ci: run previously failed ....
On 01/27/2016 08:05 PM, Junio C Hamano wrote: (Changed the topic, 2 notes inside) Clemens Buchacher writes: Coming back to "[PATCH] optionally disable gitattributes": The topics are related, because they both deal with the situation where the work tree has files which are not normalized according to gitattributes. But my patch is more about saying: ok, I know I may have files which need to be normalized, but I want to ignore this issue for now. Please disable gitattributes for now, because I want to work with the files as they are committed. Conversely, the discussion here is about how to reliably detect and fix files which are not normalized. git ls-files --eol can detect that (as Junio pointed out) I primarily wanted to make sure that you understood the underlying issue, so that I do not have to go back to the basics in the other thread. And it is clear that you obviously do, which is good. Here, you seem to think that what t0025 wants to see happen is sensible, judging by the fact that you call "rm .git/index && git reset" a "fix". My take on this is quite different. After a "reset --hard HEAD", we should be able to trust the cached stat information and have "diff HEAD" say "no changes". That is what you essentially want in the other thread, if I understand you correctly, and in an ideal world where the filesystem timestamp has infinite precision, that is what would happen in t0025, always "breaking" its expectation. The real world has much coarser timestamp granularity than ideal, and that is why the test appear to be "flaky", failing to give "correct" outcome some of the time--but I'd say that it is expecting a wrong thing. An index entry that has data that does not round-trip when it goes through convert_to_working_tree() and then convert_to_git() "breaks" this arrangement, and I'd view it as the user having an inconsistent data. It is like you are in a repository that still has an unmerged paths--you cannot proceed before you resolve them. This is actually bringing some light to me: the round-trip test. There are this "well known but less well document" situations where we break that rule: - files are checked in with CRLF into the repo. - .gittatributes is set to "text" later. 2 different ways to handle it: - keep the eol at checkout, normalize at checkin -> roundtrip broken - keep the eol at checkout and checkin -> roundtrip OK - files with mixed line endings in the repo: Same here: 2 different ways to handle it: - keep the eol at checkout, normalize at checkin -> roundtrip broken - keep the eol at checkout and checkin -> roundtrip OK - files with CRCRLF line endings in the repo: Same here: 2 different ways to handle it: - keep the eol at checkout, normalize at checkin -> roundtrip broken - keep the eol at checkout and checkin -> roundtrip OK My feeling is that we should simply say: You user set attribute to "text" and by doing that, you promised to have files with LF only in the index. If you break that promise, Git does not know, what you really want. - It may be a situation where you write a shell script which for some reasons needs a '\015' at the end of a line, and Git may treat it wrong by assuming that this is a CRLF line ending (end converts it into LF) - It may be that you want CRLF because you added a Windows .BAT file. It may be that you use git.git and another implementation of Git, which doesn't support attributes at all, so that a save way to do this is to just commit CRLF. - It may be that this is a historical issue. Everybody using the project uses git that understands .gitattributes, so someone may fix it some day. Can Git make this decision ? When core.autocrlf is true (and no attributes are set), then the conversion of line ending is disabled. On 01/27/2016 08:05 PM, Junio C Hamano wrote: (Changed the topic, 2 notes inside) Clemens Buchacher writes: Coming back to "[PATCH] optionally disable gitattributes": The topics are related, because they both deal with the situation where the work tree has files which are not normalized according to gitattributes. But my patch is more about saying: ok, I know I may have files which need to be normalized, but I want to ignore this issue for now. Please disable gitattributes for now, because I want to work with the files as they are committed. Conversely, the discussion here is about how to reliably detect and fix files which are not normalized. git ls-files --eol can detect that (as Junio pointed out) I primarily wanted to make sure that you understood the underlying issue, so that I do not have to go back to the basics in the other thread. And it is clear that you obviously do, which is good. Here, you seem to think that what t0025 wants to see happen is sensible, judging by the fact that you call "rm .git/index && git reset" a "fix". My take on this is quite different. After a "reset --hard HEAD", we should be able to trust the cached stat information and have "diff HEAD" say "no ch
Re: Starting on a microproject for GSoC
On 28 January 2016 at 11:40, Moritz Neeb wrote: > I suppose just fixing/revising this would be kind > of a too low hanging fruit? I am in no way qualified to speak to the majority of your post, but I can't imagine anyone refusing your work because it was 'too low hanging fruit'. Indeed, the general gist of getting people to start with a microproject has always appeared to help potential applicants understand what it takes to get a patch accepted in git. As long as the low hanging fruit is useful (your example of polishing a patchset to get it into master is definitely useful, assuming the patchset is useful) then I'd say go for it. In the worst case, if you feel your contribution was not 'meaty' enough, there is nothing to stop you working on some other problem, or extending the first further. That said, I do remember previous applicants trying to do as many microprojects as possible, leaving few for other people. Regards, Andrew Ardill -- 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] contrib/subtree: Split history with empty trees correctly
On 01/28/2016 03:56 AM, David A. Greene wrote: Marcus Brinkmann writes: With my patch, "git subtree split -P" produces the same result (for my data set) as "git filter-branch --subdirectory-filter", which is much faster, because it selects the revisions to rewrite before rewriting. As I am not using any of the advanced features of "git subtree", I will just use "git filter-branch" instead. Heh. :) I hope to replace all that ugly split code with filter-branch as you describe but there are some cases where it differs. It may be that your changes fix some of that. Are you still able to do a re-roll on this? I have to admit that my interest has declined steeply since discovering that subtree-split and filter-branch --subtree-filter give different results from "git svn" on the subdirectory. The reason is that git-svn includes all commits for revisions that regular "svn log" gives on that directory, which includes commits that serve as branch points only or that are empty except for unhandled properties. While empty commits for unhandled properties wouldn't be fatal, missing branch points make "git svn" really unhappy when asked to rebuild .git/svn. As migration from SVN is my main motivation at this point to use a subtree filter at this point (git-svn is just very slow - about one week on our repository), I am somewhat stuck and back to using git-svn. Although hacking up something with filter-branch seems like a remote option, it's probably nothing that generalizes. It didn't help that "make test" in contrib/subtree gives me 27 out of 29 failed tests (with no indication how to figure out what exactly failed). Oh well :) Marcus -- 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
NEW ARRIVALS, CISCO,CPU's,Memory, LAPTOP AND AVAYA
Dear Sir/Madam, Clean tested working pulls CPUs and QTYs in stock. 115 X X5650 65 X E5410 75 X X5660 145 X E5530 100 X E5645 40 X X5680 75 X X5690 Brand new sealed IP phones and QTYs in stock. 55 x CP-7937G 77 x CP-7942G 54 x CP-7945G 75 x CP-7962G .. 45 x Avaya 9630 65 x Avaya 9641 55 x Avaya 9640 All NIB. Here is our current stock list. SSD drives and 750 gig 2.5" sata drives We also have 250 x i5 dell 133 x HP 360 x Lenevo all grade A Here is the qty in stock for laptops 150 x E6500 Dell Latitude E6500 Core 2 Duo 2.80GHz T9600 4GB 160GB DVD+/-RW Win 7 60 x E6510 Dell Ltitude E6510. 15.6" Intel Core i5- M520 @ 2.40GHz. 4GB. 320GB DVD+/-RW Win 7 30 X 8530P HP EliteBook 8530p 15.4" Laptop 2.53GHz Core 2 Duo T9400, 4GB RAM, 160GB HDD, Win 100 x 8740W HP EliteBook 8740w 17" 2.4Ghz Core i5 6GB 250GB Win 7 Pr 45 x 8760W HP EliteBook 8760W 17.3" 2nd Gen Intel Core i7 2.70GHz 8GB 320GB Windows 7 Pro 50 x DELL 6520Dell latitude e6520 15.6" i5-2520M 2.5Ghz, 8GB Ram, 500GB HD Win 7 @ $115 120 x DELL 6420 Laptop Dell Latitude E6420 14" Intel Core i5 2.4Ghz 4GB RAM 250GB HDD DVD Win 7 150 x T410 Lenovo ThinkPad Laptop T410s 14.1" 2.40GHz Core i5 4GB RAM 160GB Win 7 180 x 8440P HP EliteBook 8440p 14" M520 Core i5 2.4GHz 4GB 250GB Win 7 Let me know if you're interested. We are very open to offers and willing to work with you to make sure that we have a deal. Thank You Barbara Johnson Laison Computech Inc 210 N Scoring Ave, Rialto California, 92376 Tel: +1-657-232-7047 Fax: +1-347-214-047 -- 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] contrib/subtree: Split history with empty trees correctly
Marcus Brinkmann writes: > With my patch, "git subtree split -P" produces the same result (for my > data set) as "git filter-branch --subdirectory-filter", which is much > faster, because it selects the revisions to rewrite before rewriting. > As I am not using any of the advanced features of "git subtree", I will > just use "git filter-branch" instead. Heh. :) I hope to replace all that ugly split code with filter-branch as you describe but there are some cases where it differs. It may be that your changes fix some of that. Are you still able to do a re-roll on this? -David -- 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] contrib/subtree: Split history with empty trees correctly
[ Sorry it took a few days to reply. I am absolutely slammed at work and will be for the next few weeks at least. The good news is that it's resulting in some nice work on git-subtree! :) ] Marcus Brinkmann writes: > On 01/20/2016 05:05 AM, David A. Greene wrote: >> Marcus Brinkmann writes: >> >>> 'git subtree split' will fail if the history of the subtree has empty >>> tree commits (or trees that are considered empty, such as submodules). >>> This fix keeps track of this condition and correctly follows the history >>> over such commits. >> >> Thanks for working on this! Please add a test to t7900-subtree.sh. > > I couldn't get the tests to run and I couldn't find documentation on how > to run it. If you enlighten me I can add a test :) Just run "make test" in contrib/subtree. You have to build git first. >> Can you explain the logic here? The old code appears to be using the >> lack of a tree to filter out "mainline" commits from the subtree history >> when splitting. If that test is only done before seeing a proper >> subtree commit and never after, then any commit mainline commit >> following the first subtree commit in the rev list will miss being >> marked with set_notree and the cache will not have the identity entry >> added. >> >> Test #36 in t7900-subtree.sh has a mainline commit listed after the >> first subtree commit in the rev list, I believe. >> >> I'm not positive your change is wrong, I'd just like to understand it >> better. I'd also like a comment explaining why it works so future >> developers don't get confused. Overall, I am trying to better comment >> the code as I make my own changes. > > It's possible the patch does not work for some cases. For example, I > don't know how the rejoin variant of splits work. I'm not so much worried about catching all cases of the bug you identified, though it would be good if the patch did. I'm much more concerned about not causing a regression in existing functionality. > Some observations: > > 1) The notree list is never actually used except to identify which > commits have been visited in check_parents. It's really verifying that we visited parents before children in the split code, I think. That seems like a good check to keep. Let me make sure I understand your fix too. Are you essentially skipping empty commits when splitting? You original patch said that split failed but didn't say how. Did git-subtree spit out an error message, or did the failure manifest in some other way? If I knew the failure mode it might help me understand your changes better. I see you explain the proble below (thanks!) but I'd still like to know how you discovered it. It will help in constructing a test. > 2) I have no idea what use case is covered by the "if [ -n "$newparents" > ]; then cache_set $rev $rev; fi". I left it in purely for traditional > reasons. So, clarifying that would go a long way in understanding the > code, and if there is a test for that, I will figure it out. As far as I understand things, $newparents being non-empty means that the commits parents were split out and $newparents contains the hashes of the split commits, so that when this commit is split it can set up the proper parent links. If the commit doesn't have a tree in the subdirectory, then I *think* the split codesimply sets the identity entry in the cache so that any future commit that has this (empty) one as a parent will see it in the $newparents list. Since copy_or_skip checks for parents with empty trees and does not link split commits to them, I don't understand the purpose of including these commits in $newparents. So you may very well be right that it just doesn't matter if we skip these altogether. > 3a) The bug happens because on the first commit that deletes the subdir, > newparents will not be empty, and the "cache_set $rev $rev" will kick in > and subsequently (when the subdir is added again) the history will > divert into the $rev commit which is not rewritten, but part of the > unsplit tree. This seems very wrong to me! See 2). Ah, so the problem isn't empty commits per se, it's the fact that a subdirectory was deleted and re-added. That makes sense. I didn't understand that from your original commit message though I now remember you discussed it in the first e-mail you sent. It would be good to clarify this in the final commit. I agree that the behavior you describe is wrong. So the fix basically relies on the fact that there is some tree in the subdirectory, which later gets deleted, but since "found_first_commit" triggered, we'll just skip those empty commits and never see them in the cache so that when a tree appears again we won't link to mainline commits. Have I got it right? Currently the split code is all-or-nothing. You split the whole history or none of it. Eventually I want to make it flexible enough to allow splitting ranges of commits or individual commits. I'm wondering how your code will work if the sp
[PATCHv4 0/2] Port `git submodule init` from shell to C
Hi,
I looked at this patch series again and fixed all memory leaks as found by
coverity scan.
This applies on top of sb/submodule-parallel-update
Thanks,
Stefan
Interdiff to v3:
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index c9b0c05..dd8b2a5 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -35,7 +35,7 @@ static char *get_default_remote(void)
if (git_config_get_string(sb.buf, &dest))
ret = xstrdup("origin");
else
- ret = xstrdup(dest);
+ ret = dest;
strbuf_release(&sb);
return ret;
@@ -188,6 +188,7 @@ static int resolve_relative_url(int argc, const char
**argv, const char *prefix)
res = relative_url(remoteurl, url, up_path);
puts(res);
free(res);
+ free(remoteurl);
return 0;
}
@@ -209,6 +210,7 @@ static int resolve_relative_url_test(int argc, const char
**argv, const char *pr
res = relative_url(remoteurl, url, up_path);
puts(res);
free(res);
+ free(remoteurl);
return 0;
}
@@ -222,8 +224,9 @@ static void init_submodule(const char *path, const char
*prefix, int quiet)
const struct submodule *sub;
struct strbuf sb = STRBUF_INIT;
char *url = NULL;
- const char *upd = NULL;
- const char *displaypath = relative_path(xgetcwd(), prefix, &sb);
+ char *upd = NULL;
+ char *cwd = xgetcwd();
+ const char *displaypath = relative_path(cwd, prefix, &sb);
/* Only loads from .gitmodules, no overlay with .git/config */
gitmodules_config();
@@ -261,6 +264,7 @@ static void init_submodule(const char *path, const char
*prefix, int quiet)
remoteurl = xgetcwd();
url = relative_url(remoteurl, url, NULL);
strbuf_release(&remotesb);
+ free(remoteurl);
}
if (git_config_set(sb.buf, url))
@@ -269,26 +273,27 @@ static void init_submodule(const char *path, const char
*prefix, int quiet)
if (!quiet)
printf(_("Submodule '%s' (%s) registered for path
'%s'\n"),
sub->name, url, displaypath);
- free(url);
}
/* Copy "update" setting when it is not set yet */
strbuf_reset(&sb);
strbuf_addf(&sb, "submodule.%s.update", sub->name);
- if (git_config_get_string_const(sb.buf, &upd) && sub->update) {
- upd = sub->update;
+ if (git_config_get_string(sb.buf, &upd) && sub->update) {
+ upd = xstrdup(sub->update);
if (strcmp(sub->update, "checkout") &&
strcmp(sub->update, "rebase") &&
strcmp(sub->update, "merge") &&
strcmp(sub->update, "none")) {
fprintf(stderr, _("warning: unknown update mode '%s'
suggested for submodule '%s'\n"),
upd, sub->name);
- upd = "none";
+ upd = xstrdup("none");
}
if (git_config_set(sb.buf, upd))
die(_("Failed to register update mode for submodule
path '%s'"), displaypath);
}
strbuf_release(&sb);
+ free(cwd);
+ free(upd);
+ free(url);
}
static int module_init(int argc, const char **argv, const char *prefix)
Stefan Beller (2):
submodule: port resolve_relative_url from shell to C
submodule: port init from shell to C
builtin/submodule--helper.c | 326 +++-
git-submodule.sh| 118 +---
t/t0060-path-utils.sh | 42 ++
3 files changed, 366 insertions(+), 120 deletions(-)
--
2.7.0.rc0.42.ge5f5e2d
--
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
[PATCHv4 1/2] submodule: port resolve_relative_url from shell to C
Later on we want to automatically call `git submodule init` from
other commands, such that the users don't have to initialize the
submodule themselves. As these other commands are written in C
already, we'd need the init functionality in C, too. The
`resolve_relative_url` function is a large part of that init
functionality, so start by porting this function to C.
To create the tests in t0060, the function `resolve_relative_url`
was temporarily enhanced to write all inputs and output to disk
when running the test suite. The added tests in this patch are
a small selection thereof.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 208 +++-
git-submodule.sh| 81 +
t/t0060-path-utils.sh | 42 +
3 files changed, 253 insertions(+), 78 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 8002187..13583d9 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -9,6 +9,210 @@
#include "submodule-config.h"
#include "string-list.h"
#include "run-command.h"
+#include "remote.h"
+#include "refs.h"
+#include "connect.h"
+
+static char *get_default_remote(void)
+{
+ char *dest = NULL, *ret;
+ unsigned char sha1[20];
+ int flag = 0;
+ struct strbuf sb = STRBUF_INIT;
+ const char *refname = resolve_ref_unsafe("HEAD", 0, sha1, &flag);
+
+ if (!refname)
+ die("No such ref: HEAD");
+
+ /* detached HEAD */
+ if (!strcmp(refname, "HEAD"))
+ return xstrdup("origin");
+
+ if (!skip_prefix(refname, "refs/heads/", &refname))
+ die(_("Expecting a full ref name, got %s"), refname);
+
+ strbuf_addf(&sb, "branch.%s.remote", refname);
+ if (git_config_get_string(sb.buf, &dest))
+ ret = xstrdup("origin");
+ else
+ ret = dest;
+
+ strbuf_release(&sb);
+ return ret;
+}
+
+static int starts_with_dot_slash(const char *str)
+{
+ return str[0] == '.' && is_dir_sep(str[1]);
+}
+
+static int starts_with_dot_dot_slash(const char *str)
+{
+ return str[0] == '.' && str[1] == '.' && is_dir_sep(str[2]);
+}
+
+/*
+ * Returns 1 if it was the last chop before ':'.
+ */
+static int chop_last_dir(char **remoteurl, int is_relative)
+{
+ char *rfind = find_last_dir_sep(*remoteurl);
+ if (rfind) {
+ *rfind = '\0';
+ return 0;
+ }
+
+ rfind = strrchr(*remoteurl, ':');
+ if (rfind) {
+ *rfind = '\0';
+ return 1;
+ }
+
+ if (is_relative || !strcmp(".", *remoteurl))
+ die(_("cannot strip one component off url '%s'"),
+ *remoteurl);
+
+ free(*remoteurl);
+ *remoteurl = xstrdup(".");
+ return 0;
+}
+
+/*
+ * The `url` argument is the URL that navigates to the submodule origin
+ * repo. When relative, this URL is relative to the superproject origin
+ * URL repo. The `up_path` argument, if specified, is the relative
+ * path that navigates from the submodule working tree to the superproject
+ * working tree. Returns the origin URL of the submodule.
+ *
+ * Return either an absolute URL or filesystem path (if the superproject
+ * origin URL is an absolute URL or filesystem path, respectively) or a
+ * relative file system path (if the superproject origin URL is a relative
+ * file system path).
+ *
+ * When the output is a relative file system path, the path is either
+ * relative to the submodule working tree, if up_path is specified, or to
+ * the superproject working tree otherwise.
+ *
+ * NEEDSWORK: This works incorrectly on the domain and protocol part.
+ * remote_url url outcome correct
+ * http://a.com/b ../c http://a.com/c yes
+ * http://a.com/b ../../c http://c no (domain should be kept)
+ * http://a.com/b ../../../c http:/c no
+ * http://a.com/b ../../../../chttp:c no
+ * http://a.com/b ../../../../../c.:c no
+ */
+static char *relative_url(const char *remote_url,
+ const char *url,
+ const char *up_path)
+{
+ int is_relative = 0;
+ int colonsep = 0;
+ char *out;
+ char *remoteurl = xstrdup(remote_url);
+ struct strbuf sb = STRBUF_INIT;
+ size_t len = strlen(remoteurl);
+
+ if (is_dir_sep(remoteurl[len]))
+ remoteurl[len] = '\0';
+
+ if (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))
+ is_relative = 0;
+ else {
+ is_relative = 1;
+ /*
+* Prepend a './' to ensure all relative
+* remoteurls start with './' or '../'
+*/
+ if (!starts_with_dot_slash(remoteurl) &&
+ !starts_with_dot_dot_sl
[PATCHv4 2/2] submodule: port init from shell to C
By having the `init` functionality in C, we can reference it easier
from other parts in the code.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 119 ++--
git-submodule.sh| 39 +--
2 files changed, 115 insertions(+), 43 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 13583d9..689c354 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -214,6 +214,119 @@ static int resolve_relative_url_test(int argc, const char
**argv, const char *pr
return 0;
}
+static int git_submodule_config(const char *var, const char *value, void *cb)
+{
+ return parse_submodule_config_option(var, value);
+}
+
+static void init_submodule(const char *path, const char *prefix, int quiet)
+{
+ const struct submodule *sub;
+ struct strbuf sb = STRBUF_INIT;
+ char *url = NULL;
+ char *upd = NULL;
+ char *cwd = xgetcwd();
+ const char *displaypath = relative_path(cwd, prefix, &sb);
+
+ /* Only loads from .gitmodules, no overlay with .git/config */
+ gitmodules_config();
+
+ sub = submodule_from_path(null_sha1, path);
+
+ /*
+* Copy url setting when it is not set yet.
+* To look up the url in .git/config, we must not fall back to
+* .gitmodules, so look it up directly.
+*/
+ strbuf_reset(&sb);
+ strbuf_addf(&sb, "submodule.%s.url", sub->name);
+ if (git_config_get_string(sb.buf, &url)) {
+ url = xstrdup(sub->url);
+
+ if (!url)
+ die(_("No url found for submodule path '%s' in
.gitmodules"),
+ displaypath);
+
+ /* Possibly a url relative to parent */
+ if (starts_with_dot_dot_slash(url) ||
+ starts_with_dot_slash(url)) {
+ char *remoteurl;
+ char *remote = get_default_remote();
+ struct strbuf remotesb = STRBUF_INIT;
+ strbuf_addf(&remotesb, "remote.%s.url", remote);
+ free(remote);
+
+ if (git_config_get_string(remotesb.buf, &remoteurl))
+ /*
+* The repository is its own
+* authoritative upstream
+*/
+ remoteurl = xgetcwd();
+ url = relative_url(remoteurl, url, NULL);
+ strbuf_release(&remotesb);
+ free(remoteurl);
+ }
+
+ if (git_config_set(sb.buf, url))
+ die(_("Failed to register url for submodule path '%s'"),
+ displaypath);
+ if (!quiet)
+ printf(_("Submodule '%s' (%s) registered for path
'%s'\n"),
+ sub->name, url, displaypath);
+ }
+
+ /* Copy "update" setting when it is not set yet */
+ strbuf_reset(&sb);
+ strbuf_addf(&sb, "submodule.%s.update", sub->name);
+ if (git_config_get_string(sb.buf, &upd) && sub->update) {
+ upd = xstrdup(sub->update);
+ if (strcmp(sub->update, "checkout") &&
+ strcmp(sub->update, "rebase") &&
+ strcmp(sub->update, "merge") &&
+ strcmp(sub->update, "none")) {
+ fprintf(stderr, _("warning: unknown update mode '%s'
suggested for submodule '%s'\n"),
+ upd, sub->name);
+ upd = xstrdup("none");
+ }
+ if (git_config_set(sb.buf, upd))
+ die(_("Failed to register update mode for submodule
path '%s'"), displaypath);
+ }
+ strbuf_release(&sb);
+ free(cwd);
+ free(upd);
+ free(url);
+}
+
+static int module_init(int argc, const char **argv, const char *prefix)
+{
+ int quiet = 0;
+ int i;
+
+ struct option module_init_options[] = {
+ OPT_STRING(0, "prefix", &prefix,
+ N_("path"),
+ N_("alternative anchor for relative paths")),
+ OPT__QUIET(&quiet, "Suppress output for initialzing a
submodule"),
+ OPT_END()
+ };
+
+ const char *const git_submodule_helper_usage[] = {
+ N_("git submodule--helper init []"),
+ NULL
+ };
+
+ argc = parse_options(argc, argv, prefix, module_init_options,
+git_submodule_helper_usage, 0);
+
+ if (argc == 0)
+ die(_("Pass at least one submodule"));
+
+ for (i = 0; i < argc; i++)
+ init_submodule(argv[i], prefix, quiet);
+
+ return 0;
+}
+
struct module_list {
const struct ca
Re: Starting on a microproject for GSoC
On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb wrote:
> Hi git developers,
>
> the next Google Summer of Code is not too far away. I expect git to
> apply for it and hopefully have some student spots which in turn I plan
> to apply. It was recommended elsewhere and on this list as well, that it
> is beneficial to engage with the community early, that's why I am
> writing to you already now, before all this formal stuff has begun.
>
> Before I may introduce myself: I'm a Computer Science student in
> Germany, coming towards the end of my Masters. I am an enthusiastic git
> user that's why I'd like to give something back.
Giving back is a noble thing. To have most fun at it, you need to ask yourself:
What is the most obnoxious part of Git that you personally use? What was
the latest problem you had, which you'd want to fix? If you identified
that, is that the right size to fix it? (Usually it is way bigger than thought,
but you can ask around if there are approaches for solving that problem ;)
> This would be my first
> time to actually contribute to a FOSS project and I am quite excited
> (also a bit frightened ;)).
Each FLOSS project is run differently. So in case your fright
was the right instinct, go for some other project, it will be totally different.
>
> As the list of available microprojects 2016 is still to be created, I
> might need your help in finding a project to work on. I started to dig
> through the archives along items of the list of 2015 [0] and so far
> found out the following:
Some smaller starter projects may be found at
http://git-blame.blogspot.com/p/leftover-bits.html
The size and difficulty of these projects may vary
a bit more than the micro projects for GSoC though.
>
> The first task, to make "git -C '' cmd" not to barf seems to be solved.
> I tried it with "git -C '' status" at least. I could not find the
> related patch, maybe it did use other keywords. I would be interested.
>
> The second task, to allow "-" as a short-hand for "@{-1}" in more places
> seems to be still open for reset, although someone almost finished it
> (cf. $gmane/265417). I suppose just fixing/revising this would be kind
> of a too low hanging fruit? More interesting (also because I am a bit
> earlier) might be to unify everything, as suggested by Junio in
> $gmane/265260. Or implementing it for another branch command, e.g. rebase.
>
> The other tasks I did not yet dig into.
>
> If all of that is considered as not relevant, I might just go for a
> newer idea, like converting strbuf_getline_lf() callers to
> strbuf_getline(), as suggested in $gmane/284104.
>
> Any thoughts?
>
> A question regarding the process of "taking a task (or bug)" in general:
> Is it solely organized through the mailing list?
Yes, I'd say 95% of the discussion is done on the mailing list.
(The remaining 5% is done on conferences,
or privately for security related stuff I'd assume)
> Suppose I start to work
> on something, should I announce it to not risk work duplication?
[In the context of fighting procrastination,] I recently read that announcing
that you are going to work on $FOO is not necessarily helpful
for actually doing it. Chances are lower that you actually finish a
thing which you announced.
However feel free to announce what you work on. Usually people don't.
> Does it
> happen often that more people accidentally work on the same task?
It happens rarely for larger goals. For the GSoc micro projects however
some students did the same thing with slight differences. (2015 we only
had 2 spots to fill but a few more applicants (3-5?), but seeing
how students approached the same problem helped on deciding whom
to mentor. (Given different problems it would have been harder.)
>
> Best,
> Moritz
>
> [0] http://git.github.io/SoC-2015-Microprojects.html
I just realized there are some micro projects on the 2014 page
as well which haven't been solved yet. (maybe, they are not
striked through)
Thanks,
Stefan
--
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
Starting on a microproject for GSoC
Hi git developers,
the next Google Summer of Code is not too far away. I expect git to
apply for it and hopefully have some student spots which in turn I plan
to apply. It was recommended elsewhere and on this list as well, that it
is beneficial to engage with the community early, that's why I am
writing to you already now, before all this formal stuff has begun.
Before I may introduce myself: I'm a Computer Science student in
Germany, coming towards the end of my Masters. I am an enthusiastic git
user that's why I'd like to give something back. This would be my first
time to actually contribute to a FOSS project and I am quite excited
(also a bit frightened ;)).
As the list of available microprojects 2016 is still to be created, I
might need your help in finding a project to work on. I started to dig
through the archives along items of the list of 2015 [0] and so far
found out the following:
The first task, to make "git -C '' cmd" not to barf seems to be solved.
I tried it with "git -C '' status" at least. I could not find the
related patch, maybe it did use other keywords. I would be interested.
The second task, to allow "-" as a short-hand for "@{-1}" in more places
seems to be still open for reset, although someone almost finished it
(cf. $gmane/265417). I suppose just fixing/revising this would be kind
of a too low hanging fruit? More interesting (also because I am a bit
earlier) might be to unify everything, as suggested by Junio in
$gmane/265260. Or implementing it for another branch command, e.g. rebase.
The other tasks I did not yet dig into.
If all of that is considered as not relevant, I might just go for a
newer idea, like converting strbuf_getline_lf() callers to
strbuf_getline(), as suggested in $gmane/284104.
Any thoughts?
A question regarding the process of "taking a task (or bug)" in general:
Is it solely organized through the mailing list? Suppose I start to work
on something, should I announce it to not risk work duplication? Does it
happen often that more people accidentally work on the same task?
Best,
Moritz
[0] http://git.github.io/SoC-2015-Microprojects.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: GPL v2 authoritative answer on stored code as a derived work
From: "Junio C Hamano" Jonathan Smith writes: It's pretty clear that code stored in a Git repository isn't considered a derived work of Git, regardless of whether it is used in a commercial context or otherwise. I'm guessing here, but I suspect that while its 'pretty clear' to Jonathan, that he has met others who aren't so clear or trusting, and it's that distrustful community that would need convincing. However, I'm unable to find this stated in any authoritative and unambiguous manner. The GPL2 FAQ's (search for 'data') http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#TOCGPLOutput (should link to "Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free?") and http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#IfInterpreterIsGPL both cover the fact that the repo (data) is not a derived work, and thus not subject to GPL2. Is it reasonable to ask for such a statement? I doubt it, especially if "It's pretty clear". (Rhet) If there were to be such a statement, where should it be placed, and who could issue it? It couldn't be part of the COPYING licence file (because it's not supposed to be modified). It could be in the User Manual, but that wouldn't carry much weight with the already worried, or perhaps the git(1) man page [E.g. 'discusssion' section maybe], or even in the git-scm.com 'book', but really it would need Jonathan (and others with similar FUD issues) to suggest what they'd need. Without such a statement, I think we have already seen that the commercial adoption is already appealing. Hopefully the links can help Jonathan if he is having any local difficulties. -- Philip -- 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 3/3] git: simplify environment save/restore logic
Junio C Hamano writes: > @@ -598,9 +597,9 @@ static int run_argv(int *argcp, const char ***argv) >*/ > if (done_alias) > break; > + done_alias = 1; > if (!handle_alias(argcp, argv)) > break; > - done_alias = 1; > } > > return done_alias; This hunk shouldn't be there; it changes the return value from this function and breaks the whole thing. What I will push out as part of 'pu' will have this fixed. -- 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 archive should use vendor extension in pax header
Hallo René, On Wed, Jan 27, 2016 at 09:31:15PM +0100, René Scharfe wrote: > Hello Robert, > > it's customary to discuss in the open by copying the list. Unless > there are secrets involved, but I don't see any below. I kept it > private anyway in case I missed any, but please cc: > git@vger.kernel.org on your reply if possible. I'm sorry for miss-sending the last mail, I sent it to the list again. > >>This is only a problem if you don't know how a given tar files was > >>created (or modified later). How did you get into this situation? > >>Or in other words: Please tell me more about your use case. > > > >My situation is that I'm interested in knowing if an archive was created > >by git so I can find out where the corresponding repository is and find > >out which commit this archive was created from. Right now the only way > >is to open a hex editor or as archiving software is instructed to ignore > >the content of comment headers. This is clearly a suboptimal situation. > > There is git get-tar-commit-id, which prints the commit ID if it > finds a comment entry which looks like a hexadecimal SHA-1 hash. > It's better than a hex editor at least. :) This is incredibly fuzzy and can get wrong for a pleothora of reasons. I hope you agree though that the situation is suboptimal, git is doing the equivalent of using a custom file format without an easily recognizable magic number. > But I'm still interested how you got a collection of tar files with > unknown origin. Just curious. Easy: Just download the (source) distribution archives of a distribution of choice and try to verify that the tarballs they use to compile their packages actually come from the project's public git repositories. There are other reasons why an easily detectable git hash might be useful. For example, file(1) could show that the archive comes from git. Other utilities could use this to work around git-specific bugs. An unpacker could add corresponding meta-data when unpacking the file. > >>>It would be much more useful if git created a > >>>custom key. As per POSIX suggestions, something like this would be > >>>appropriate: > >>> > >>> GIT.commit=57ca140635bf157354124e4e4b3c8e1bde2832f1 > >> > >>This would be included in addition to the comment in order to avoid > >>breaking existing users, I guess. > > > >Good point. I'm not sure how many user use the comment header at all. > > Apart from git get-tar-commit-id I don't know any program for > extracting pax comments. And I don't know how widely used that is, > but I assume there is *someone* out there, extracting commit IDs > with it. Neither do I. But remember, POSIX explicitly specifies that programs that parse pax file must ignore pax comments so an unpacker that interpretes the content of such a comment in any way is in violation of the pax specification. > >>If you have a random archive and want to know if it was generated by > >>git then your next question might be which options and substitutions > >>were used. That reminds me of this thread regarding verifiable > >>archives: > >> > >> http://article.gmane.org/gmane.comp.version-control.git/240244 > > > >Good point. Something like this should be enough to be enough to have > >reproducable archives if archives with a tree ID were to have a time > >stamp of 0 (1970-01-01) instead of the current date: > > > > comment=...(for compatibility) > > GIT.commit=... (like comment) > > GIT.umask=... (tar.umask) > > GIT.prefix=... (--prefix=) > > GIT.path=... (see below > > GIT.export-subst=1 (in extended header instead of global header) > > > >A different key such as GIT.treeish might be appropriate. The > >GIT.export-subst key should be set only for those files where a > >substitution has taken place. > > What would GIT.export-subst contain? There can be multiple > replacements in a file. GIT.export-subst would only contain a 1 if substitution is turned on. The goal is to have reproduceable archives, not the ability to turn an archive back into a git repository. > >Maybe there should also be an > >GIT.original-name key. > > What would it be used for? In case an export substition changes the file name so the implementation can verify that the original file could plausibly have been substituted into the current name. Also for the case where multiple files substitute into the same name to tell which file git should check equivalency with. > >An option GIT.export-ignore is not required. Instead it would be more > >useful to have a special file type G (for git) with the convention that > >the file name .gitattributes means “attributes that apply to this git > >archive.” > > That would be a non-standard extension. Archivers would extract > these as regular files. Storing a list of excluded paths (in > GIT.exclude or so) might be a better idea. No, that's not a good idea as pax headers are interpreted as “attributes pertaining to a file.” A file doesn't have the attribute
[PATCH v2 3/3] git: simplify environment save/restore logic
The only code that cares about the value of the global variable
saved_env_before_alias after the previous fix is handle_builtin()
that turns into a glorified no-op when the variable is true, so the
logic could safely be lifted to its caller, i.e. the caller can
refrain from calling it when the variable is set.
This variable tells us if save_env_before_alias() was called (with
or without matching restore_env()), but the sole caller of the
function, handle_alias(), always calls it as the first thing, so we
can consider that the variable essentially keeps track of the fact
that handle_alias() has ever been called.
It turns out that handle_builtin() and handle_alias() are called
only from one function in a way that the value of the variable
matters, which is run_argv(), and it already keeps track of the
fact that it already called handle_alias().
So we can simplify the whole thing by:
- Change handle_builtin() to always make a direct call to the
builtin implementation it finds, and make sure the caller
refrains from calling it if handle_alias() has ever been
called;
- Remove saved_env_before_alias variable, and instead use the
local "done_alias" variable maintained inside run_argv() to
make the same decision.
Signed-off-by: Junio C Hamano
---
* Patches 2 and 3 are with updated log messages; their patch text
did not change.
git.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/git.c b/git.c
index e39b972..c8d7b56 100644
--- a/git.c
+++ b/git.c
@@ -25,13 +25,11 @@ static const char *env_names[] = {
GIT_PREFIX_ENVIRONMENT
};
static char *orig_env[4];
-static int saved_env_before_alias;
static int save_restore_env_balance;
static void save_env_before_alias(void)
{
int i;
- saved_env_before_alias = 1;
assert(save_restore_env_balance == 0);
save_restore_env_balance = 1;
@@ -533,16 +531,8 @@ static void handle_builtin(int argc, const char **argv)
}
builtin = get_builtin(cmd);
- if (builtin) {
- /*
-* XXX: if we can figure out cases where it is _safe_
-* to do, we can avoid spawning a new process when
-* saved_env_before_alias is true
-* (i.e. setup_git_dir* has been run once)
-*/
- if (!saved_env_before_alias)
- exit(run_builtin(builtin, argc, argv));
- }
+ if (builtin)
+ exit(run_builtin(builtin, argc, argv));
}
static void execv_dashed_external(const char **argv)
@@ -586,8 +576,17 @@ static int run_argv(int *argcp, const char ***argv)
int done_alias = 0;
while (1) {
- /* See if it's a builtin */
- handle_builtin(*argcp, *argv);
+ /*
+* If we tried alias and futzed with our environment,
+* it no longer is safe to invoke builtins directly in
+* general. We have to spawn them as dashed externals.
+*
+* NEEDSWORK: if we can figure out cases
+* where it is safe to do, we can avoid spawning a new
+* process.
+*/
+ if (!done_alias)
+ handle_builtin(*argcp, *argv);
/* .. then try the external ones */
execv_dashed_external(*argv);
@@ -598,9 +597,9 @@ static int run_argv(int *argcp, const char ***argv)
*/
if (done_alias)
break;
+ done_alias = 1;
if (!handle_alias(argcp, argv))
break;
- done_alias = 1;
}
return done_alias;
--
2.7.0-368-gb6e04f9
--
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 archive should use vendor extension in pax header
On Tue, Jan 26, 2016 at 11:06:25PM +0100, René Scharfe wrote: > Am 24.01.2016 um 16:59 schrieb f...@fuz.su: > >Right now, git archive creates a pax global header of the form > > > > comment=57ca140635bf157354124e4e4b3c8e1bde2832f1 > > > >in tar archives it creates. This is suboptimal as as comments are > >specified to be ignored by extraction software. It is impossible to > >find out in an automatic way (short of guessing) that this is supposed > >to be a commit hash. > > This is only a problem if you don't know how a given tar files was > created (or modified later). How did you get into this situation? > Or in other words: Please tell me more about your use case. My situation is that I'm interested in knowing if an archive was created by git so I can find out where the corresponding repository is and find out which commit this archive was created from. Right now the only way is to open a hex editor or as archiving software is instructed to ignore the content of comment headers. This is clearly a suboptimal situation. > >It would be much more useful if git created a > >custom key. As per POSIX suggestions, something like this would be > >appropriate: > > > > GIT.commit=57ca140635bf157354124e4e4b3c8e1bde2832f1 > > This would be included in addition to the comment in order to avoid > breaking existing users, I guess. Good point. I'm not sure how many user use the comment header at all. > If you have a random archive and want to know if it was generated by > git then your next question might be which options and substitutions > were used. That reminds me of this thread regarding verifiable > archives: > > http://article.gmane.org/gmane.comp.version-control.git/240244 Good point. Something like this should be enough to be enough to have reproducable archives if archives with a tree ID were to have a time stamp of 0 (1970-01-01) instead of the current date: comment=...(for compatibility) GIT.commit=... (like comment) GIT.umask=... (tar.umask) GIT.prefix=... (--prefix=) GIT.path=... (see below GIT.export-subst=1 (in extended header instead of global header) A different key such as GIT.treeish might be appropriate. The GIT.export-subst key should be set only for those files where a substitution has taken place. Maybe there should also be an GIT.original-name key. An option GIT.export-ignore is not required. Instead it would be more useful to have a special file type G (for git) with the convention that the file name .gitattributes means “attributes that apply to this git archive.” The GIT.path option holds the paths that are being archived. It is a bit tricky to get right. The intent of POSIX pax headers is that each key is an attribute that applies to a series of files. In the case of a global header, each key applies until it is overridden with a new header or with a local header. A GIT.path key should only apply to the files that correspond to this path operant to git archive. Thus, a new GIT.path should be written frequently. There should always be at least one GIT.path. It might be a good idea to be able to control the kind of metadata git adds to the archive as to be able to not leak any confidential information with git archive. If you are interested I can try to make a specification for these headers. Yours sincerely, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments -- 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 v2 2/3] git: protect against unbalanced calls to {save,restore}_env()
We made sure that save_env_before_alias() does not skip saving the
environment when asked to (which led to use-after-free of orig_cwd
in restore_env() in the buggy version) with the previous step.
Protect against future breakage where somebody adds new callers of
these functions in an unbalanced fashion.
Signed-off-by: Junio C Hamano
---
git.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/git.c b/git.c
index a57a4cb..e39b972 100644
--- a/git.c
+++ b/git.c
@@ -26,11 +26,15 @@ static const char *env_names[] = {
};
static char *orig_env[4];
static int saved_env_before_alias;
+static int save_restore_env_balance;
static void save_env_before_alias(void)
{
int i;
saved_env_before_alias = 1;
+
+ assert(save_restore_env_balance == 0);
+ save_restore_env_balance = 1;
orig_cwd = xgetcwd();
for (i = 0; i < ARRAY_SIZE(env_names); i++) {
orig_env[i] = getenv(env_names[i]);
@@ -42,6 +46,9 @@ static void save_env_before_alias(void)
static void restore_env(int external_alias)
{
int i;
+
+ assert(save_restore_env_balance == 1);
+ save_restore_env_balance = 0;
if (!external_alias && orig_cwd && chdir(orig_cwd))
die_errno("could not move to %s", orig_cwd);
free(orig_cwd);
--
2.7.0-368-gb6e04f9
--
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 v2 1/3] git: remove an early return from save_env_before_alias()
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano wrote:
>>> Junio C Hamano writes:
>>>
I spoke too soon, I am afraid.
...
I wonder if this would be better done as a multi-part series that
goes like this:
...
>>>
>>> So here is the first of the three-patch series to replace it.
>>
>> This is much better (the whole series, not just the first patch). We
>> probably should add a test about help.autocorrect though, maybe in the
>> first patch, because it's not tested at all in the test suite.
>
> Patches welcome. Thanks.
Here is an updated 1/3; this feature does not fit very well to any
category (it is certainly not basic, or command that is primarily
about objects or worktree; I just picked "Git tools" t9xxx as that
is the closest thing to "direct end user support").
-- >8 --
When help.autocorrect is in effect, an attempt to auto-execute an
uniquely corrected result of a misspelt alias will result in an
irrelevant error message. The codepath that causes this calls
save_env_before_alias() and restore_env() in handle_alias(), and
that happens twice. A global variable orig_cwd is allocated to hold
the return value of getcwd() in save_env_before_alias(), which is
then used in restore_env() to go back to that directory and finally
free(3)'d there.
However, save_env_before_alias() is not prepared to be called twice.
It returns early when it knows it has already been called, leaving
orig_cwd undefined, which is then checked in the second call to
restore_env(), and by that time, the memory that used to hold the
contents of orig_cwd is either freed or reused to hold something
else, and this is fed to chdir(2), causing it to fail. Even if it
did not fail (i.e. reading of the already free'd piece of memory
yielded a directory path that we can chdir(2) to), it then gets
free(3)'d.
Fix this by making sure save_env() does do the saving when called.
While at it, add a minimal test for help.autocorrect facility.
Signed-off-by: Junio C Hamano
---
git.c | 2 --
t/t9003-help-autocorrect.sh | 52 +
2 files changed, 52 insertions(+), 2 deletions(-)
create mode 100755 t/t9003-help-autocorrect.sh
diff --git a/git.c b/git.c
index 98d4412..a57a4cb 100644
--- a/git.c
+++ b/git.c
@@ -30,8 +30,6 @@ static int saved_env_before_alias;
static void save_env_before_alias(void)
{
int i;
- if (saved_env_before_alias)
- return;
saved_env_before_alias = 1;
orig_cwd = xgetcwd();
for (i = 0; i < ARRAY_SIZE(env_names); i++) {
diff --git a/t/t9003-help-autocorrect.sh b/t/t9003-help-autocorrect.sh
new file mode 100755
index 000..dfe95c9
--- /dev/null
+++ b/t/t9003-help-autocorrect.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='help.autocorrect finding a match'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ # An alias
+ git config alias.lgf "log --format=%s --first-parent" &&
+
+ # A random user-defined command
+ write_script git-distimdistim <<-EOF &&
+ echo distimdistim was called
+ EOF
+
+ PATH="$PATH:." &&
+ export PATH &&
+
+ git commit --allow-empty -m "a single log entry" &&
+
+ # Sanity check
+ git lgf >actual &&
+ echo "a single log entry" >expect &&
+ test_cmp expect actual &&
+
+ git distimdistim >actual &&
+ echo "distimdistim was called" >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'autocorrect showing candidates' '
+ git config help.autocorrect 0 &&
+
+ test_must_fail git lfg 2>actual &&
+ sed -e "1,/^Did you mean this/d" actual | grep lgf &&
+
+ test_must_fail git distimdist 2>actual &&
+ sed -e "1,/^Did you mean this/d" actual | grep distimdistim
+'
+
+test_expect_success 'autocorrect running commands' '
+ git config help.autocorrect -1 &&
+
+ git lfg >actual &&
+ echo "a single log entry" >expect &&
+ test_cmp expect actual &&
+
+ git distimdist >actual &&
+ echo "distimdistim was called" >expect &&
+ test_cmp expect actual
+'
+
+test_done
--
2.7.0-368-gb6e04f9
--
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: Need support with git credential storage
On Wed, Jan 27, 2016 at 09:49:38PM +, Charles Bélanger wrote: > Here's the git clone command launch by a .sh script file called from > ~/.profile: > git clone https://myusern...@bitbucket.org/CompanyName/ProjectName.git > ~/Projects/SubFolderName/ProjectName > > Here's the error from bash .profile: > Fatal: unable to access > 'https://myusern...@bitbucket.org/CompanyName/ProjectName.git/': > Could not resolve host: bitbucket.org I don't think this is related to credentials. The credential code should never do a network hostname lookup. It looks more like git-clone is failing to contact the host in the first place. Try "ping bitbucket.org", which would presumably yield the same error. If so, you need to figure out why you cannot resolve the name, but that's beyond the scope of this list. > I followed the excellent Web page here: > https://git-scm.com/book/be/v2/Git-Tools-Credential-Storage > > Here's what I use as commands: > git credential-store --file ~/git.store store > protocol=https > host=bitbucket.org/CompanyName/ProjectName.git > username=MyUserName > password=MyPassword > (type enter on a blank line to exit) This comes from the "under the hood" section, I think. In normal use, you shouldn't need to run the credential-helper directly. Just configure it, via: git config credential.helper "store --file ~/git.store" The first time git needs a password, it will prompt you on the terminal, and then store the result in that file. If you do want to pre-seed the store, you can do so using a command like the one above. But as you noted later, the "host" field should be _just_ the hostname, not the rest of the url path. That would go in the "path" field if you want it, but typically git does not even bother to store paths, and just keys on whole domains (see "credential.useHttpPath" in "git help config" for more details). You can also specify a URL using the special key "url", which is then parsed into its components. So for example: $ git credential-store --file my-store store url=https://bitbucket.org/CompanyName/ProjectName.git username=foo password=bar [blank line to end] $ cat my-store https://foo:b...@bitbucket.org/CompanyName/ProjectName.git $ git credential-store --file my-store get url=https://bitbucket.org/ [blank line ends our input, the rest is output] username=foo password=bar > Here's what the ~/git.store file looks like: > > https://MyUserName:mypassw...@bitbucket.org%2fCompanyName%2fProjectName.git > > I tried changing the %2f by / inside the git.store file and also tried // but > it's still showing the same fatal error. > Perhaps I don't use the host= property correctly. Right. It should be: https://MyUserName:mypassw...@bitbucket.org/CompanyName/ProjectName.git Though as before, you can omit "CompanyName/ProjectName.git" completely, to cover the whole domain. -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 0/6] Split .git/config in multiple worktree setup
Nguyễn Thái Ngọc Duy writes: > For any worktree, the new file .git/common/config is read first, then > either .git/config or .git/worktrees/xxx/config is read after. There's > no special per-worktree var list any more. Which is great. You want to > add per-worktree config vars, use "git config --local". You want to > add per-repo config vars, use (new) "git config --repo". You put a > variable in a wrong file, you're punished for it (and it's the same > today, say if you put core.worktree to /etc/gitconfig). I think this is saner than the one before. -- 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 4/6] worktree: new config file hierarchy
Nguyễn Thái Ngọc Duy writes: > ($C stands for $GIT_COMMON_DIR for the rest of the message) > > In main worktree, we read these config files in this order: > > 1) system config > 2) XDG config > 3) user config > 4) $GIT_DIR/config > > Currently linked worktrees share the same config file at step 4 with > main worktree. The problem is, not all config variables can be > shared. We need per-repo vars and per-worktree ones. > > With this patch, since worktree v1, the repo config file (or worktree > config file in multi worktree context) is no longer shared. Main > worktree reads $C/config. Linked worktrees read $C/worktrees/xxx/config > and a new file, $C/worktrees/config. Sharing is done via this new > file. The read hierarchy for a worktree becomes > > 1) system config > 2) XDG config > 3) user config > 4) $C/common/config > 5) $C/worktrees/xxx/config (or $C/config for main worktree) > > Compare to an alternative scheme where $C/config contains both shared > variables and main-worktree-only ones, this is a cleaner design. > > * We do not have to check every single variable name to see if it's > shared or per-worktree when reading config files. > > * We do not enforce any particular variable split. If a variable > is in $C/worktrees/config, it is shared. Putting core.worktree in > $C/worktrees/config is punished the same way the variable is put in > $HOME/.gitconfig, for example. > > * We will provide a new "git config --repo" to access this new config > file. In single-worktree context, or worktree v0, --repo is an alias > of --local. > > There is one problem though. We store worktree version in config file > and expect that all worktrees must share the same version (i.e. read > the same config file). But the share-ness of per-repo config files is > changed based on worktree version. Where do we put extensions.worktree > then? I cannot see why it cannot live in $C/common/config, which would be read as the fourth alternative in your earlier enumeration. What I am missing? -- 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/6] path.c: new (identical) list for worktree v1
Nguyễn Thái Ngọc Duy writes:
> +static struct common_dir common_list_v1[] = {
> + ...
> +};
> +
> +static struct common_dir *get_common_list(void)
> +{
> + switch (repository_format_worktree_version) {
> + case 0: return common_list_v0;
> + case 1: return common_list_v1;
Why not an array whose elements are these common_list_v$N[]
instead of "switch"? I.e.
static struct common_dir **common_list_version[] = {
common_list_v0,
common_list_v1,
};
static struct common_dir *get_common_list(void)
{
int i = repository_format_worktree_version;
if (i < ARRAY_SIZE(common_list_version))
return common_list_version[i];
die("I dunno about version %d", i);
}
--
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/6] worktree: new repo extension to manage worktree behaviors
Nguyễn Thái Ngọc Duy writes: > Multiple worktree setup is still evolving and its behavior may be > changed in future. But we do not want to break existing worktree s/be changed/change/ > setups. A new set of extensions, worktree=X, is recognized to tell Git > what multiple worktree "version" is being used so that Git can > behavior accordingly. s/behavior/behave/ > +WORKTREE VERSIONS AND MIGRATION > +--- > +Multiple worktree is still an experimental feature and evolving. Every > +time the behavior is changed, the "worktree version" is stepped > +up. Worktree version is stored as a configuration variable > +extensions.worktree. s/stepped up/incremented/ More seriously, are we confident that the overall worktree support is mature enough by now that once we add an experimental feature X at version 1, we can promise to keep maintaining it forever at version N for any positive integer N? I hate to sound overly negative, but I am getting an impression that we are not quite there, and it is still not ready for production use. It would be beneficial both for us and our users if we can keep our hand untied for at least several more releases to allow us try various random experimental features, fully intending to drop any of them if the ideas do not pan out. -- 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
Need support with git credential storage
Hello Git Community, I'm working at AddEnergie at Quebec city in Canada and I'm currently working on making a Build Server in a Virtual Machine running Ubuntu. We are using git for our source code and I'm the first one here that need to use git store credentials for an Automated Build Server that would run overnight. I'm wondering if you could provide me support about it because I'm having issue making it works. The clue I have right now about my git store credential issue is when I'm doing a git clone of my project repo, I'm having following errors: Here's the git clone command launch by a .sh script file called from ~/.profile: git clone https://myusern...@bitbucket.org/CompanyName/ProjectName.git ~/Projects/SubFolderName/ProjectName Here's the error from bash .profile: Fatal: unable to access 'https://myusern...@bitbucket.org/CompanyName/ProjectName.git/': Could not resolve host: bitbucket.org I followed the excellent Web page here: https://git-scm.com/book/be/v2/Git-Tools-Credential-Storage Here's what I use as commands: git credential-store --file ~/git.store store protocol=https host=bitbucket.org/CompanyName/ProjectName.git username=MyUserName password=MyPassword (type enter on a blank line to exit) git credential-store --file ~/git.store get protocol=https host=bitbucket.org/CompanyName/ProjectName.git (type enter on a blank line to exit) Here's what the ~/git.store file looks like: https://MyUserName:mypassw...@bitbucket.org%2fCompanyName%2fProjectName.git I tried changing the %2f by / inside the git.store file and also tried // but it's still showing the same fatal error. Perhaps I don't use the host= property correctly. May I ask you helping me with this ? Best Regards, Charles Belanger -- 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] travis-ci: run previously failed tests first, then slowest to fastest
Junio C Hamano writes: > One way to solve (1) I can think of is to change the definition of > ce_compare_data(), which is called by the code that does not trust > the cached stat data (including but not limited to the Racy Git > codepath). The current semantics of that function asks this > question: > > We do not know if the working tree file and the indexed data > match. Let's see if "git add" of that path would record the > data that is identical to what is in the index. > > This definition was cast in stone by 29e4d363 (Racy GIT, 2005-12-20) > and has been with us since Git v1.0.0. But that does not have to be > the only sensible definition of this check. I wonder what would > break if we ask this question instead: > > We do not know if the working tree file and the indexed data > match. Let's see if "git checkout" of that path would leave the > same data as what currently is in the working tree file. > > If we did this, "reset --hard HEAD" followed by "diff HEAD" will by > definition always report "is clean" as long as nobody changes files > in the working tree, even with the inconsistent data in the index. > > This still requires that convert_to_working_tree(), i.e. your smudge > filter, is deterministic, though, but I think that is a sensible > assumption for sane people, even for those with inconsistent data in > the index. Just a few additional comments. The primary reason why I originally chose "does 'git add' of what is in the working tree give us the same blob in the index?" as opposed to "does 'git checkout' from the index again will give the same result in the working tree?" is because it is a lot less resource intensive and also is simpler. Back then I do not think we had a streaming interface to hash huge contents from a file in the working tree, but it requires us to read the entire file from the filesystem just once, apply the convert_to_git() processing and then hash the result, whether we keep the whole thing in core at once or process the data in streaming fashion. Doing the other check will have to inflate the blob data and apply the convert_to_working_tree() processing, and also read the whole thing from the filesystem and compare, which is more work at runtime. And for a sane set-up where the data in the index does not contradict with the clean/smudge filter and EOL settings, both would yield the same result. If we were to switch the semantics of ce_compare_data(), we would want a new sibling interface next to stream_blob_to_fd() that takes a file descriptor opened on the file in the working tree for reading (fd), the object name (sha1), and the output filter, and works very similarly to stream_blob_to_fd(). The difference would be that we would be reading from the fd (i.e. the file in the working tree) as we read from the istream (i.e. the contents of the blob in the index, after passing the convert_to_working_tree() filter) and comparing them in the main loop. The filter parameter to the function would be obtained by calling get_stream_filter() just like how write_entry() uses it to prepare the filter parameter to call streaming_write_entry() with. That way, we can rely on future improvement of the streaming interface to make sure we keep the data we have to keep in core to the minimum. IOW, I am saying that the "add --fix-index" lunchbreak patch I sent earlier in the thread that has to hold the data in-core while processing is not a production quality patch ;-) -- 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] git-svn: shorten glob error message
Eric Wong writes:
> Junio C Hamano wrote:
>> I am not sure if it is a good idea to show */*/* as an example in
>> the message (that is an anti-example of 'one set of wildcard' by
>> having three stars, isn't it?), but that is not a new issue this
>> change introduces.
>
> Actually, going back to commit 570d35c26dfbc40757da6032cdc96afb58cc0037
> ("git-svn: Allow deep branch names by supporting multi-globs"),
> having equal '*' on both sides is all that is required.
>
> Not sure how to improve the wording, though...
I dunno, either, and that is why "not a new issue", iow, the patch
is good as-is. The wording might be an area with possible future
improvement, but that does not have to block the improvement the
patch under discussion brings us.
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 00/19] Let Git's tests pass on Windows
Johannes Schindelin writes: > I made a couple of other adjustments anyway, so expect a new iteration > shortly. This time cross-checked on Linux. Thanks, will take a 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
Re: [PATCH v2 12/19] mingw: skip test in t1508 that fails due to path conversion
Johannes Schindelin writes: > Hi Junio, > > On Tue, 26 Jan 2016, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > @@ -35,7 +35,10 @@ test_expect_success 'setup' ' >> >git checkout -b upstream-branch && >> >test_commit upstream-one && >> >test_commit upstream-two && >> > - git checkout -b @/at-test && >> > + if ! test_have_prereq MINGW >> > + then >> > + git checkout -b @/at-slash >> >> I presume that this is meant to be "@/at-test", not "@/at-slash". > > Oh my. That's what you get for redoing patches from scratch. Sorry about > that! Heh. That is why it makes me feel uneasy, after asking you to fetch from me and fix it up, to hear that you will send in a new reroll. -- 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 0/2] Let merge-file write out conflict markers with correct EOLs
Thanks, will queue after looking at the interdiff since v4. -- 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] tag-ref and tag object binding
On Wed, Jan 27, 2016 at 09:09:31PM +0100, Michael J Gruber wrote: > "subkey" and "uid" are different things. You bind a subkey to your > primary key with that self-signature. subkeys don't carry any other > signatures. > > A primary key "carries" the uids, and whenever someone "signs your key" > they in fact sign a specific uid - usually all, resulting in multiple > signatures, one for each uid of the (primary) key. > > A key is usually considered trusted if it carries "a" signature from a > trusted key. > > So, assuming my key carries a signature from a trusted key to at least > one uid, it would be trusted no matter what (fake) uids I add to it later. Right. I think I didn't do a good job of explaining myself earlier, so let me try to rephrase. When we look at the v2.7 tag, GPG sees that we are signed by Junio's subkey, 96AFE6CB. It then knows that belongs to the main public key 713660A7, because the main key signed the subkey. And then it sees that there are several uids for that main key, each with their own signatures by other people. So of the three uids that I have for that key: pub 4096R/713660A7 2011-10-01 uid Junio C Hamano uid Junio C Hamano uid Junio C Hamano it reports back to git only one (the pobox.com), which we relay to the user via --raw. If we wanted to check that the key matches the "tagger" header, that works. But why did gpg return that first uid, and not any of the others? We would ideally see all of them, and consider it OK if it matches any uid (assuming that uid is sufficiently signed for gpg to consider it valid). Weirder, if you _don't_ use "--raw", the human-readable output gives us all of the uids as "aka" lines: $ git verify-tag v2.7.0 $ git verify-tag v2.7.0 gpg: Signature made Mon 04 Jan 2016 05:08:12 PM EST using RSA key ID 96AFE6CB gpg: Good signature from "Junio C Hamano " gpg: aka "Junio C Hamano " gpg: aka "Junio C Hamano " $ git verify-tag --raw v2.7.0 [GNUPG:] SIG_ID xFANmHj+QJ1gwIcoRuT5BF/y8H4 2016-01-04 1451945292 [GNUPG:] GOODSIG B0B5E88696AFE6CB Junio C Hamano [GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2016-01-04 1451945292 0 4 0 1 2 00 96E07AF25771955980DAD10020D04E5A713660A7 [GNUPG:] TRUST_FULLY It seems like we should be able to get the raw-output to tell us all of those uids. I guess it is not the end of the world to go back to gpg and say "give me all of the valid uids that match this signing key", but it seems silly to have to do so. -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: [RFC] tag-ref and tag object binding
Junio C Hamano venit, vidit, dixit 27.01.2016 19:10: > Michael J Gruber writes: > >> Jeff King venit, vidit, dixit 27.01.2016 09:09: >> >>> The bigger issue is that gpg seems to give us only _one_ uid, when there >>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a >>> sub-key that has several uids associated with it. The one that "git >>> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good, >>> but I think that's just because it happens to be the first uid. Or maybe >>> there is some gpg arcana going on that I don't know about. >> >> You do not sign with a uid, you sign with a (sub)key, and the tag is >> signed with Junio's primary key. His subkey is encryption only. > > Hmm, actually I meant to sign my tags with signing subkey, not the > primary one, but I may have made a mistake. Oops, I needed to refresh my copy of your key, sorry. You did sign 2.7.0 with the subkey 0xB0B5E88696AFE6CB >> You do sign a uid. >> >> So, if you want to be sure that a tag is signed "with a specific uid" by >> relying on signatures from a set of signers, you would really need to >> check that the key that signed the tag has a signature on the correct >> uid. Having a signed key with the right uid in it doesn't mean much >> unlss the right uid is signed. >> >> E.g., I have a key with many signatures, and I could have Junio's uid on >> it in a minute without invalidating any of those signatures. > > I have signatures on my primary key from others, and my signing key > is signed by my primary key and by no other keys. Here is an > abbreviated output from running "gpg --list-sigs 96AFE6CB": > > pub 4096R/713660A7 2011-10-01 > uid Junio C Hamano > sig 3713660A7 2011-10-01 Junio C Hamano > sig 3713660A7 2011-10-01 Junio C Hamano > sig F3119B9A 2011-10-01 Junio C Hamano > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) > sig 93674C40 2011-10-04 Theodore Y. Ts'o > sig 00411886 2012-07-20 Linus Torvalds > > sig C11804F0 2011-10-04 Theodore Ts'o > sig 02A80207 2011-10-05 Andrew Morton (akpm) > > uid Junio C Hamano > sig 3713660A7 2011-10-01 Junio C Hamano > sig F3119B9A 2011-10-01 Junio C Hamano > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) > sig 00411886 2012-07-20 Linus Torvalds > > sig C11804F0 2011-10-04 Theodore Ts'o > uid Junio C Hamano > sig 3713660A7 2011-10-01 Junio C Hamano > sig F3119B9A 2011-10-01 Junio C Hamano > sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) > sig 00411886 2012-07-20 Linus Torvalds > > sub 4096R/833262C4 2011-10-01 > sig 713660A7 2011-10-01 Junio C Hamano > sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20] > sig 713660A7 2015-09-21 Junio C Hamano > sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19] > sig 713660A7 2014-09-20 Junio C Hamano > > So I understand that the way you trust 96AFE6CB has to be indirect. > You may have somebody's key you know belongs to that somebody you > trust (say, Linus) in the list of signers of 713660A7 (my primary), > and you know 96AFE6CB is a key I use because it is signed by my > primary key. > > You can add a subkey to your keyring a uid that says "Junio", but > the signature on that subkey would not have a signature by me you > can verify by following the web of trust. You are correct to point > out that "this key claims to be by somebody, and it has some > signature" is not a sufficient reason for you to trust it. "subkey" and "uid" are different things. You bind a subkey to your primary key with that self-signature. subkeys don't carry any other signatures. A primary key "carries" the uids, and whenever someone "signs your key" they in fact sign a specific uid - usually all, resulting in multiple signatures, one for each uid of the (primary) key. A key is usually considered trusted if it carries "a" signature from a trusted key. So, assuming my key carries a signature from a trusted key to at least one uid, it would be trusted no matter what (fake) uids I add to it later. >> That one is easy already by setting "GNUPGHOME" to a special dir with a >> small keyring and tight trust settings (or having a dedicated account on >> the incoming side in the first place). > > Yes, I understand that the above is how automated services per > project should be set up, with a dedicated verification keyring that > holds keys the project trusts. Michael -- 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 1/2] merge-file: let conflict markers match end-of-line style of the context
Johannes Schindelin writes: [administrivia: I finally managed to correct e-mail address of peff@, which has been giving me bounces for all the previous messages in the thread] > Your response is also an indicator to me that future myself will find the > same code just as confusing as you did, though. > > Maybe need_cr -> eol_is_crlf? The crucial question is how well the variable conveys its meaning when it has -1 as its value. "need_cr? -- I don't know yet" is as clear as "eol_is_crlf? -- I don't know yet", if not clearer. I personally do not think "eol_is_crlf" is an improvement. It makes it unclear _whose_ eol the variable is talking about. It can be misread as talking about one or more of the files that are being merged and mistaken as a statement of a fact (i.e. "we inspected and know the input file's eol is CRLF"). Compared to that, it is clear that "need_cr" is talking about what the EOL convention the resulting file should be. I briefly wondered if the if/if (need_cr)/... cascade that inspects (conditionally up to) three variants might become cleaner if the polarity of that variable is flipped (we are allowed to use CRLF only when we know that among all of the three variants that we can determine the line termination convention used, all of them use CRLF), but I didn't think it through seriously. -- 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 1/2] merge-file: let conflict markers match end-of-line style of the context
Hi Junio, On Wed, 27 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> Just in case it was unclear, none of the comment above means I want > >> any part of the patch redone--I am happy with this patch as-is. > > > > Thanks for saying that... I was about to try to make things clearer, but I > > could not think of a better term than "needs_cr". > > I don't, either ;-). > > The primary reason I respond with the "I find this a bit confusing > but it probably is just me" (not just to this patch) is to give an > example of a review comment that demonstrates to the others that the > reviewer understood what is in the patch and the issues around the > change better than a mere unsubstantiated "These look OK to me.", > which does not tell us how carefully the proposed change was > reviewed by the reviewer--such a review does not allow me to "trust > the review that is already done by others" and apply the patches > with minimum cursory scanning and I end up having to carefully read > them myself. Your response is also an indicator to me that future myself will find the same code just as confusing as you did, though. Maybe need_cr -> eol_is_crlf? Ciao, Dscho -- 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] travis-ci: run previously failed tests first, then slowest to fastest
Clemens Buchacher writes: > Coming back to "[PATCH] optionally disable gitattributes": The topics > are related, because they both deal with the situation where the work > tree has files which are not normalized according to gitattributes. But > my patch is more about saying: ok, I know I may have files which need to > be normalized, but I want to ignore this issue for now. Please disable > gitattributes for now, because I want to work with the files as they are > committed. Conversely, the discussion here is about how to reliably > detect and fix files which are not normalized. I primarily wanted to make sure that you understood the underlying issue, so that I do not have to go back to the basics in the other thread. And it is clear that you obviously do, which is good. Here, you seem to think that what t0025 wants to see happen is sensible, judging by the fact that you call "rm .git/index && git reset" a "fix". My take on this is quite different. After a "reset --hard HEAD", we should be able to trust the cached stat information and have "diff HEAD" say "no changes". That is what you essentially want in the other thread, if I understand you correctly, and in an ideal world where the filesystem timestamp has infinite precision, that is what would happen in t0025, always "breaking" its expectation. The real world has much coarser timestamp granularity than ideal, and that is why the test appear to be "flaky", failing to give "correct" outcome some of the time--but I'd say that it is expecting a wrong thing. An index entry that has data that does not round-trip when it goes through convert_to_working_tree() and then convert_to_git() "breaks" this arrangement, and I'd view it as the user having an inconsistent data. It is like you are in a repository that still has an unmerged paths--you cannot proceed before you resolve them. Anyway. As to your patch in the other thread, here is what I think: (1) When you know (or perhaps your CI knows) that the working tree has never been modified since you did "reset --hard HEAD" (or its equivalent, like "git checkout $branch" from a clean state), these paths with inconsistent data would break the usual check to ask "is the working tree clean?" That is a problem and we need a way to ensure that the working tree is always judged to be clean immediately after "reset --hard HEAD". IOW, I agree with you that the issue you are trying to solve is worth solving. (2) Regardless of the "inconsistent data breaking the cleanliness check" issue, it may be handy to have a way to temporarily disable the attributes, i.e. allow us to ask "what happens if there is no attributes defined?" IOW, I am saying that the change in the patch is not without merit. In addition to (1), I further think that this sequence should not report that the path F is modified: # Write F from HEAD to the working tree, after passing it # through convert_to_working_tree() $ git reset --hard HEAD # Force the re-reading, without changing the contents at all $ cp F F.new $ mv F.new F $ git diff HEAD which is broken by paths with inconsistent data. Your CI would want a way to make that happen. However, I do not think disabling attributes (i.e. (2)) is a solution to the issue (i.e. (1)), which we just agreed to be an issue that is worth solving, for at least two reasons. * Even without any attributes, core.autocrlf setting can get the data in your index (whose lines can be terminated with CRLF) into the same "inconsistent data" situation. Disabling attribute handling would not have any effect on that codepath, I think. * The indexed data and the contents in the working tree file may match only because the clean/smudge transformation is done. If you disable attributes, re-checking by passing the working tree contents through convert_to_git() and comparing the result with what is in the index would tell you that they are different, even if the clean/smudge filter pair implements round-trip operations correctly. One way to solve (1) I can think of is to change the definition of ce_compare_data(), which is called by the code that does not trust the cached stat data (including but not limited to the Racy Git codepath). The current semantics of that function asks this question: We do not know if the working tree file and the indexed data match. Let's see if "git add" of that path would record the data that is identical to what is in the index. This definition was cast in stone by 29e4d363 (Racy GIT, 2005-12-20) and has been with us since Git v1.0.0. But that does not have to be the only sensible definition of this check. I wonder what would break if we ask this question instead: We do not know if the working tree file and the indexed data match. Let's see if "git checkout" of that path would leave the same data as what currently is in the w
Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context
Johannes Schindelin writes: >> Just in case it was unclear, none of the comment above means I want >> any part of the patch redone--I am happy with this patch as-is. > > Thanks for saying that... I was about to try to make things clearer, but I > could not think of a better term than "needs_cr". I don't, either ;-). The primary reason I respond with the "I find this a bit confusing but it probably is just me" (not just to this patch) is to give an example of a review comment that demonstrates to the others that the reviewer understood what is in the patch and the issues around the change better than a mere unsubstantiated "These look OK to me.", which does not tell us how carefully the proposed change was reviewed by the reviewer--such a review does not allow me to "trust the review that is already done by others" and apply the patches with minimum cursory scanning and I end up having to carefully read them myself. -- 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] tag-ref and tag object binding
Michael J Gruber writes: > Jeff King venit, vidit, dixit 27.01.2016 09:09: > >> The bigger issue is that gpg seems to give us only _one_ uid, when there >> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a >> sub-key that has several uids associated with it. The one that "git >> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good, >> but I think that's just because it happens to be the first uid. Or maybe >> there is some gpg arcana going on that I don't know about. > > You do not sign with a uid, you sign with a (sub)key, and the tag is > signed with Junio's primary key. His subkey is encryption only. Hmm, actually I meant to sign my tags with signing subkey, not the primary one, but I may have made a mistake. > You do sign a uid. > > So, if you want to be sure that a tag is signed "with a specific uid" by > relying on signatures from a set of signers, you would really need to > check that the key that signed the tag has a signature on the correct > uid. Having a signed key with the right uid in it doesn't mean much > unlss the right uid is signed. > > E.g., I have a key with many signatures, and I could have Junio's uid on > it in a minute without invalidating any of those signatures. I have signatures on my primary key from others, and my signing key is signed by my primary key and by no other keys. Here is an abbreviated output from running "gpg --list-sigs 96AFE6CB": pub 4096R/713660A7 2011-10-01 uid Junio C Hamano sig 3713660A7 2011-10-01 Junio C Hamano sig 3713660A7 2011-10-01 Junio C Hamano sig F3119B9A 2011-10-01 Junio C Hamano sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) sig 93674C40 2011-10-04 Theodore Y. Ts'o sig 00411886 2012-07-20 Linus Torvalds sig C11804F0 2011-10-04 Theodore Ts'o sig 02A80207 2011-10-05 Andrew Morton (akpm) uid Junio C Hamano sig 3713660A7 2011-10-01 Junio C Hamano sig F3119B9A 2011-10-01 Junio C Hamano sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) sig 00411886 2012-07-20 Linus Torvalds sig C11804F0 2011-10-04 Theodore Ts'o uid Junio C Hamano sig 3713660A7 2011-10-01 Junio C Hamano sig F3119B9A 2011-10-01 Junio C Hamano sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) sig 00411886 2012-07-20 Linus Torvalds sub 4096R/833262C4 2011-10-01 sig 713660A7 2011-10-01 Junio C Hamano sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20] sig 713660A7 2015-09-21 Junio C Hamano sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19] sig 713660A7 2014-09-20 Junio C Hamano So I understand that the way you trust 96AFE6CB has to be indirect. You may have somebody's key you know belongs to that somebody you trust (say, Linus) in the list of signers of 713660A7 (my primary), and you know 96AFE6CB is a key I use because it is signed by my primary key. You can add a subkey to your keyring a uid that says "Junio", but the signature on that subkey would not have a signature by me you can verify by following the web of trust. You are correct to point out that "this key claims to be by somebody, and it has some signature" is not a sufficient reason for you to trust it. > That one is easy already by setting "GNUPGHOME" to a special dir with a > small keyring and tight trust settings (or having a dedicated account on > the incoming side in the first place). Yes, I understand that the above is how automated services per project should be set up, with a dedicated verification keyring that holds keys the project trusts. -- 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 (Jan 2016, #04; Wed, 20)
On Wed, Jan 27, 2016 at 12:46 AM, Lars Schneider wrote: > > On 26 Jan 2016, at 23:58, Junio C Hamano wrote: > >> Lars Schneider writes: >> >>> Hi Junio, >>> >>> Did you miss the topic "submodule: extend die message on failed >>> checkout with depth argument" or do you not agree with it >>> ($gmane/282779)? Stefan Beller reviewed the commits ($gmane/283666 >>> and $gmane/283851). >> >> No, these three are still in my inbox. >> >> Quite honestly, "test to demonstrate breakage" alone is not all that >> interesting to me unless I get a firm impression that somebody is >> (or will soon be) working on fixing the breakage--which would make >> it worth keeping track of it in my tree, to allow the eventual fix >> to be more easily verified and protected from getting broken again. >> Also "these look good to me" without much explanation is not much of >> a review, and such a comment on a "demonstrate breakage" did not add >> to the sense of urgency to the issue, either. >> >> That was why it has been sitting near the bottom of the pile. > > OK, I get your point. I got the impression that Stefan is on to a fix > ($gmane/281260). Looks like he is not and I need to learn more about Git to > tackle fixes of this scope. I was on it and I put it on hold as I wanted to prioritize sb/submodule-parallel-update, sb/submodule-init and the upcoming sb/submodule-groups (maybe that's called sb/submodule-autoInit, its scope is still being bikehedded) Coming back to $gmane/281260 with a fresh mind, I think this is what we want on the client side: 1) fetch as we always did. During this fetch we learn from the servers capabilities list, if it supports fetching direct sha1s. 2) if the needed sha1 has been fetched in step 1, stop. 3) fetch the needed sha1 directly if the server supports it. 4) if the server doesn't support it, display a message like: "Please ask your Git server admin, to run at least Git 2.4.0 and enable uploadpack.allowReachableSHA1InWant to have submodules working properly" Currently we only perform step 1 and this yields the error when fetching too shallow to have the needed sha1 included. The server side should be ok as soon as uploadpack.allowReachableSHA1InWant is enabled. I thought we would need to add another option, but it looks like that option is exactly what we need here. If you want to give it a try, I'll be happy to review patches! (with more than "these look good to me" ;) Thanks, Stefan > Would it be an option for you to just drop patch 1/3 from this series and > look at the remaining ones? 2/3 fixes an "&& chain issue" ($gmane/282776) and > 3/3 prints a explanatory user warning instead of an incomprehensible error > ($gmane/282777). > > Thanks, > Lars -- 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 1/2] merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin
---
t/t6023-merge-file.sh | 12 ++
xdiff/xmerge.c| 61 +++
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 190ee90..a082116 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -346,4 +346,16 @@ test_expect_success 'conflict at EOF without LF resolved
by --union' \
printf "line1\nline2\nline3x\nline3y" >expect.txt &&
test_cmp expect.txt output.txt'
+test_expect_success 'conflict markers match existing line endings' '
+ printf "1\\r\\n2\\r\\n3" >crlf-orig.txt &&
+ printf "1\\r\\n2\\r\\n4" >crlf-diff1.txt &&
+ printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt &&
+ test_must_fail git -c core.eol=crlf merge-file -p \
+ crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt &&
+ test $(tr "\015" Q ].*Q$" | wc -l) = 3 &&
+ test_must_fail git -c core.eol=crlf merge-file -p \
+ nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >nolf.txt &&
+ test $(tr "\015" Q ].*Q$" | wc -l) = 0
+'
+
test_done
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 625198e..7b21a6b 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -143,6 +143,50 @@ static int xdl_orig_copy(xdfenv_t *xe, int i, int count,
int add_nl, char *dest)
return xdl_recs_copy_0(1, xe, i, count, add_nl, dest);
}
+/*
+ * Returns 1 if the i'th line ends in CR/LF (if it is the last line and
+ * has no eol, the preceding line, if any), 0 if it ends in LF-only, and
+ * -1 if the line ending cannot be determined.
+ */
+static int is_eol_crlf(xdfile_t *file, int i)
+{
+ long size;
+
+ if (i < file->nrec - 1)
+ /* All lines before the last *must* end in LF */
+ return (size = file->recs[i]->size) > 1 &&
+ file->recs[i]->ptr[size - 2] == '\r';
+ if (!file->nrec)
+ /* Cannot determine eol style from empty file */
+ return -1;
+ if ((size = file->recs[i]->size) &&
+ file->recs[i]->ptr[size - 1] == '\n')
+ /* Last line; ends in LF; Is it CR/LF? */
+ return size > 1 &&
+ file->recs[i]->ptr[size - 2] == '\r';
+ if (!i)
+ /* The only line has no eol */
+ return -1;
+ /* Determine eol from second-to-last line */
+ return (size = file->recs[i - 1]->size) > 1 &&
+ file->recs[i - 1]->ptr[size - 2] == '\r';
+}
+
+static int is_cr_needed(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m)
+{
+ int needs_cr;
+
+ /* Match post-images' preceding, or first, lines' end-of-line style */
+ needs_cr = is_eol_crlf(&xe1->xdf2, m->i1 ? m->i1 - 1 : 0);
+ if (needs_cr)
+ needs_cr = is_eol_crlf(&xe2->xdf2, m->i2 ? m->i2 - 1 : 0);
+ /* Look at pre-image's first line, unless we already settled o
[PATCH v5 0/2] Let merge-file write out conflict markers with correct EOLs
The original patch was sent by Beat Bolli in http://thread.gmane.org/gmane.comp.version-control.git/281600 My suggestion to extend it to respect gitattributes led to changes that broke the original patch. And they were misguided to begin with (see below). Since there have been a couple of "What's cooking" mails containing unheard calls for updates on this patch, I took it on myself to fix things. Junio's comment that we might look at blobs containing CR/LF line endings made me rethink the entire approach, and I am now convinced that we need to abandon the entire idea to make the conflict markers depend on config settings or attributes: after all, I introduced `git merge-file` as a replacement for GNU merge that can be used *outside* of any repository, by design. The crucial idea hit me yesterday when I took a step back: all we need to do is to ensure that the end-of-line style is matched when *all* input files are LF-only, or when they are all CR/LF. In all other cases, we have mixed line endings anyway. And to do that, it is sufficient to look at *one single line ending* in the context. Technically, it does not even have to be the context, but the first line endings of the first file would be enough, however it is so much more pleasant if the conflict marker's eol matches the one of the preceding line. To prevent my future self from repeating mistakes, I added a little bit of background to the first commit message. Triggered by a comment by Junio, I realized that a second patch is needed: we need to make sure that the conflicting sections are also augmented by the appropriate line endings if they lack any. The change relative to v4 is that I now test the correct conflict markers: the merge-file call we add to t6023 actually produces four conflict markers because a previous test switched the conflict style to `diff3` mode. This is only a side effect, though, therefore I really wanted to avoid testing for it. However, I managed to test an *incorrect* subset of three, but this is now fixed. Thanks go to Ramsay Jones for poking my nose onto that issue. Johannes Schindelin (2): merge-file: let conflict markers match end-of-line style of the context merge-file: ensure that conflict sections match eol style t/t6023-merge-file.sh | 13 +++ xdiff/xmerge.c| 98 +-- 2 files changed, 93 insertions(+), 18 deletions(-) Interdiff vs v4: diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh index 1390548..20aee43 100755 --- a/t/t6023-merge-file.sh +++ b/t/t6023-merge-file.sh @@ -352,11 +352,11 @@ test_expect_success 'conflict sections match existing line endings' ' printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt && test_must_fail git -c core.eol=crlf merge-file -p \ crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt && - test $(tr "\015" Q ].*Q$" | wc -l) = 3 && test $(tr "\015" Q nolf.txt && - test $(tr "\015" Q ].*Q$" | wc -l) = 0 ' test_done -- 2.7.0.windows.1.7.g55a05c8 -- 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 2/2] merge-file: ensure that conflict sections match eol style
In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.
Signed-off-by: Johannes Schindelin
---
t/t6023-merge-file.sh | 3 ++-
xdiff/xmerge.c| 37 +++--
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index a082116..20aee43 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -346,13 +346,14 @@ test_expect_success 'conflict at EOF without LF resolved
by --union' \
printf "line1\nline2\nline3x\nline3y" >expect.txt &&
test_cmp expect.txt output.txt'
-test_expect_success 'conflict markers match existing line endings' '
+test_expect_success 'conflict sections match existing line endings' '
printf "1\\r\\n2\\r\\n3" >crlf-orig.txt &&
printf "1\\r\\n2\\r\\n4" >crlf-diff1.txt &&
printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt &&
test_must_fail git -c core.eol=crlf merge-file -p \
crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt &&
test $(tr "\015" Q ].*Q$" | wc -l) = 3 &&
+ test $(tr "\015" Q nolf.txt &&
test $(tr "\015" Q ].*Q$" | wc -l) = 0
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 7b21a6b..d98f430 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -109,7 +109,7 @@ static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1,
xdfenv_t *xe2, int i2,
return 0;
}
-static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int i, int count, int
add_nl, char *dest)
+static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int i, int count, int
needs_cr, int add_nl, char *dest)
{
xrecord_t **recs;
int size = 0;
@@ -125,6 +125,12 @@ static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int
i, int count, int add
if (add_nl) {
i = recs[count - 1]->size;
if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
+ if (needs_cr) {
+ if (dest)
+ dest[size] = '\r';
+ size++;
+ }
+
if (dest)
dest[size] = '\n';
size++;
@@ -133,14 +139,14 @@ static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe,
int i, int count, int add
return size;
}
-static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char
*dest)
+static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int needs_cr, int
add_nl, char *dest)
{
- return xdl_recs_copy_0(0, xe, i, count, add_nl, dest);
+ return xdl_recs_copy_0(0, xe, i, count, needs_cr, add_nl, dest);
}
-static int xdl_orig_copy(xdfenv_t *xe, int i, int count, int add_nl, char
*dest)
+static int xdl_orig_copy(xdfenv_t *xe, int i, int count, int needs_cr, int
add_nl, char *dest)
{
- return xdl_recs_copy_0(1, xe, i, count, add_nl, dest);
+ return xdl_recs_copy_0(1, xe, i, count, needs_cr, add_nl, dest);
}
/*
@@ -202,7 +208,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
/* Before conflicting part */
- size += xdl_recs_copy(xe1, i, m->i1 - i, 0,
+ size += xdl_recs_copy(xe1, i, m->i1 - i, 0, 0,
dest ? dest + size : NULL);
if (!dest) {
@@ -221,7 +227,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
}
/* Postimage from side #1 */
- size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
+ size += xdl_recs_copy(xe1, m->i1, m->chg1, needs_cr, 1,
dest ? dest + size : NULL);
if (style == XDL_MERGE_DIFF3) {
@@ -240,7 +246,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
dest[size++] = '\r';
dest[size++] = '\n';
}
- size += xdl_orig_copy(xe1, m->i0, m->chg0, 1,
+ size += xdl_orig_copy(xe1, m->i0, m->chg0, needs_cr, 1,
dest ? dest + size : NULL);
}
@@ -255,7 +261,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
}
/* Postimage from side #2 */
- size += xdl_recs_copy(xe2, m->i2, m->chg2, 1,
+ size += xdl_recs_copy(xe2, m->i2, m->chg2, needs_cr, 1,
dest ? dest + size : NULL);
if (!dest) {
size += marker_size + 1 + needs_cr + marker2_size;
@@ -294,21 +300,24 @@ static int xdl_fill_merge_buffer(xdfenv_t *xe1, const
char *name1,
marker_size);
else if (m->mode & 3) {
/* Before conflicti
Re: [PATCH v3 16/20] mingw: mark t9100's test cases with appropriate prereqs
Hi Junio, On Wed, 27 Jan 2016, Johannes Schindelin wrote: > --8323329-1704809497-1453911609=:2964 > Content-Type: text/plain; charset=X-UNKNOWN Oh well. I guess I am really too stupid to get this right... Will change my script to call format-patch with the --add-header='Content-Type: text/plain; charset=UTF-8' option to prevent more misery in the future. Sorry, Dscho -- 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 v3 10/20] mingw: disable mkfifo-based tests
MSYS2 (the POSIX emulation layer used by Git for Windows' Bash) actually
has a working mkfifo. The only problem is that it is only emulating
named pipes through the MSYS2 runtime; The Win32 API has no idea about
named pipes, hence the Git executable cannot access those pipes either.
The symptom is that Git fails with a ': No such file or directory'
because MSYS2 emulates named pipes through special-crafted '.lnk' files.
The solution is to tell the test suite explicitly that we cannot use
named pipes when we want to test on Windows.
This lets t4056-diff-order.sh, t9010-svn-fe.sh and t9300-fast-import.sh
pass.
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bd4b02e..1470c8d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -998,7 +998,7 @@ test_i18ngrep () {
test_lazy_prereq PIPE '
# test whether the filesystem supports FIFOs
case $(uname -s) in
- CYGWIN*)
+ CYGWIN*|MINGW*)
false
;;
*)
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 01/20] mingw: let's use gettext with MSYS2
This solves two problems: - we now have proper localisation even on Windows - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)" message when running "git init" (which otherwise prevents the entire test suite from running) because libintl.h overrides vsnprintf() with libintl_vsnprintf() [*1*] The latter issue is rather crucial, as *no* test passes in Git for Windows without this fix. Footnote *1*: gettext_git=http://git.savannah.gnu.org/cgit/gettext.git $gettext_git/tree/gettext-runtime/intl/libgnuintl.in.h#n380 Signed-off-by: Johannes Schindelin --- config.mak.uname | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index 4b2e1b8..6b25661 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -560,7 +560,7 @@ else NO_R_TO_GCC_LINKER = YesPlease INTERNAL_QSORT = YesPlease HAVE_LIBCHARSET_H = YesPlease - NO_GETTEXT = YesPlease + NO_GETTEXT = USE_LIBPCRE= YesPlease NO_CURL = USE_NED_ALLOCATOR = YesPlease -- 2.7.0.windows.1.7.g55a05c8 -- 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 v3 13/20] mingw: fix t9700's assumption about directory separators
This test assumed that there is only one directory separator (the
forward slash), not two equivalent directory separators.
However, on Windows, the back slash and the forward slash *are*
equivalent.
Let's paper over this issue by converting the backward slashes to
forward ones in the test that fails with MSYS2 otherwise.
Signed-off-by: Johannes Schindelin
---
t/t9700/test.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 1140767..7e8c40b 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -33,7 +33,7 @@ is($r->config_int("test.int"), 2048, "config_int: integer");
is($r->config_int("test.nonexistent"), undef, "config_int: nonexistent");
ok($r->config_bool("test.booltrue"), "config_bool: true");
ok(!$r->config_bool("test.boolfalse"), "config_bool: false");
-is($r->config_path("test.path"), $r->config("test.pathexpanded"),
+is($r->config_path("test.path") =~ s/\\/\//gr, $r->config("test.pathexpanded"),
"config_path: ~/foo expansion");
is_deeply([$r->config_path("test.pathmulti")], ["foo", "bar"],
"config_path: multiple values");
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 07/20] mingw: let lstat() fail with errno == ENOTDIR when appropriate
POSIX semantics requires lstat() to fail with ENOTDIR when "[a]
component of the path prefix names an existing file that is neither a
directory nor a symbolic link to a directory".
See http://pubs.opengroup.org/onlinepubs/9699919799/functions/lstat.html
This behavior is expected by t1404-update-ref-df-conflicts now.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/compat/mingw.c b/compat/mingw.c
index f37f8d5..fbe69b8 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -454,6 +454,39 @@ static inline time_t filetime_to_time_t(const FILETIME *ft)
return (time_t)(filetime_to_hnsec(ft) / 1000);
}
+/**
+ * Verifies that safe_create_leading_directories() would succeed.
+ */
+static int has_valid_directory_prefix(wchar_t *wfilename)
+{
+ int n = wcslen(wfilename);
+
+ while (n > 0) {
+ wchar_t c = wfilename[--n];
+ DWORD attributes;
+
+ if (!is_dir_sep(c))
+ continue;
+
+ wfilename[n] = L'\0';
+ attributes = GetFileAttributesW(wfilename);
+ wfilename[n] = c;
+ if (attributes == FILE_ATTRIBUTE_DIRECTORY ||
+ attributes == FILE_ATTRIBUTE_DEVICE)
+ return 1;
+ if (attributes == INVALID_FILE_ATTRIBUTES)
+ switch (GetLastError()) {
+ case ERROR_PATH_NOT_FOUND:
+ continue;
+ case ERROR_FILE_NOT_FOUND:
+ /* This implies parent directory exists. */
+ return 1;
+ }
+ return 0;
+ }
+ return 1;
+}
+
/* We keep the do_lstat code in a separate function to avoid recursion.
* When a path ends with a slash, the stat will fail with ENOENT. In
* this case, we strip the trailing slashes and stat again.
@@ -514,6 +547,12 @@ static int do_lstat(int follow, const char *file_name,
struct stat *buf)
case ERROR_NOT_ENOUGH_MEMORY:
errno = ENOMEM;
break;
+ case ERROR_PATH_NOT_FOUND:
+ if (!has_valid_directory_prefix(wfilename)) {
+ errno = ENOTDIR;
+ break;
+ }
+ /* fallthru */
default:
errno = ENOENT;
break;
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 11/20] tests: turn off git-daemon tests if FIFOs are not available
The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.
This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that POSIX emulation layer and therefore blinks twice when it sees
MSYS2's emulated FIFOs and then just stares into space.
This lets t5570-git-daemon.sh and t5811-proto-disable-git.sh pass.
Signed-off-by: Stepan Kasal
Signed-off-by: Johannes Schindelin
---
t/lib-git-daemon.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index bc4b341..9b1271c 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -23,6 +23,11 @@ then
test_done
fi
+if ! test_have_prereq PIPE
+then
+ test_skip_or_die $GIT_TEST_GIT_DAEMON "file system does not support
FIFOs"
+fi
+
LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-${this_test#t}}
GIT_DAEMON_PID=
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 08/20] mingw: fix t5601-clone.sh
Since baaf233 (connect: improve check for plink to reduce false
positives, 2015-04-26), t5601 writes out a `plink.exe` for testing that
is actually a shell script. So the assumption that the `.exe` extension
implies that the file is *not* a shell script is now wrong.
Since there was no love for the idea of allowing `.exe` files to be
shell scripts on Windows, let's go the other way round: *make*
`plink.exe` a real `.exe`.
This fixes t5601-clone.sh in Git for Windows' SDK.
Signed-off-by: Johannes Schindelin
---
Makefile | 1 +
t/t5601-clone.sh | 18 --
test-fake-ssh.c | 30 ++
3 files changed, 39 insertions(+), 10 deletions(-)
create mode 100644 test-fake-ssh.c
diff --git a/Makefile b/Makefile
index fc2f1ab..10566d6 100644
--- a/Makefile
+++ b/Makefile
@@ -583,6 +583,7 @@ TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
TEST_PROGRAMS_NEED_X += test-dump-split-index
TEST_PROGRAMS_NEED_X += test-dump-untracked-cache
+TEST_PROGRAMS_NEED_X += test-fake-ssh
TEST_PROGRAMS_NEED_X += test-genrandom
TEST_PROGRAMS_NEED_X += test-hashmap
TEST_PROGRAMS_NEED_X += test-index-version
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 669ec9b..c1efb8e 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -4,6 +4,9 @@ test_description=clone
. ./test-lib.sh
+X=
+test_have_prereq !MINGW || X=.exe
+
test_expect_success setup '
rm -fr .git &&
@@ -305,14 +308,9 @@ test_expect_success 'clone checking out a tag' '
setup_ssh_wrapper () {
test_expect_success 'setup ssh wrapper' '
- write_script "$TRASH_DIRECTORY/ssh-wrapper" <<-\EOF &&
- echo >>"$TRASH_DIRECTORY/ssh-output" "ssh: $*" &&
- # throw away all but the last argument, which should be the
- # command
- while test $# -gt 1; do shift; done
- eval "$1"
- EOF
- GIT_SSH="$TRASH_DIRECTORY/ssh-wrapper" &&
+ cp "$GIT_BUILD_DIR/test-fake-ssh$X" \
+ "$TRASH_DIRECTORY/ssh-wrapper$X" &&
+ GIT_SSH="$TRASH_DIRECTORY/ssh-wrapper$X" &&
export GIT_SSH &&
export TRASH_DIRECTORY &&
>"$TRASH_DIRECTORY"/ssh-output
@@ -320,8 +318,8 @@ setup_ssh_wrapper () {
}
copy_ssh_wrapper_as () {
- cp "$TRASH_DIRECTORY/ssh-wrapper" "$1" &&
- GIT_SSH="$1" &&
+ cp "$TRASH_DIRECTORY/ssh-wrapper$X" "${1%$X}$X" &&
+ GIT_SSH="${1%$X}$X" &&
export GIT_SSH
}
diff --git a/test-fake-ssh.c b/test-fake-ssh.c
new file mode 100644
index 000..980de21
--- /dev/null
+++ b/test-fake-ssh.c
@@ -0,0 +1,30 @@
+#include "git-compat-util.h"
+#include "run-command.h"
+#include "strbuf.h"
+
+int main(int argc, char **argv)
+{
+ const char *trash_directory = getenv("TRASH_DIRECTORY");
+ struct strbuf buf = STRBUF_INIT;
+ FILE *f;
+ int i;
+ const char *child_argv[] = { NULL, NULL };
+
+ /* First, print all parameters into $TRASH_DIRECTORY/ssh-output */
+ if (!trash_directory)
+ die("Need a TRASH_DIRECTORY!");
+ strbuf_addf(&buf, "%s/ssh-output", trash_directory);
+ f = fopen(buf.buf, "w");
+ if (!f)
+ die("Could not write to %s", buf.buf);
+ for (i = 0; i < argc; i++)
+ fprintf(f, "%s%s", i > 0 ? " " : "", i > 0 ? argv[i] : "ssh:");
+ fprintf(f, "\n");
+ fclose(f);
+
+ /* Now, evaluate the *last* parameter */
+ if (argc < 2)
+ return 0;
+ child_argv[0] = argv[argc - 1];
+ return run_command_v_opt(child_argv, RUN_USING_SHELL);
+}
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 14/20] mingw: work around pwd issues in the tests
In Git for Windows' SDK, the tests are run using a Bash that relies on
the POSIX emulation layer MSYS2 (itself a friendly fork of Cygwin). As
such, paths in tests can be POSIX paths. As soon as those paths are
passed to git.exe (which does *not* use the POSIX emulation layer),
those paths are converted into Windows paths, though. This happens
for command-line parameters, but not when reading, say, config variables.
To help with that, the `pwd` command is overridden to return the Windows
path of the current working directory when testing Git on Windows.
However, when talking to anything using the POSIX emulation layer, it is
really much better to use POSIX paths because Windows paths contain a
colon after the drive letter that will easily be mistaken for the common
separator in path lists.
So let's just use the $PWD variable when the POSIX path is needed.
This lets t7800-difftool.sh, t9400-git-cvsserver-server.sh,
t9402-git-cvsserver-refs.sh and t9401-git-cvsserver-crlf.sh pass in Git
for Windows' SDK.
Note: the cvsserver tests require not only the `cvs` package (install
it into Git for Windows' SDK via `pacman -S cvs`) but also the Perl
SQLite bindings (install them into Git for Windows' SDK via
`cpan DBD::SQLite`).
This patch is based on earlier work by 마누엘 and Karsten Blees.
Signed-off-by: Johannes Schindelin
---
t/t7800-difftool.sh | 14 +++---
t/t9400-git-cvsserver-server.sh | 6 +++---
t/t9401-git-cvsserver-crlf.sh | 6 +++---
t/t9402-git-cvsserver-refs.sh | 6 +++---
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ec8bc8c..4e713f7 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -430,11 +430,11 @@ EOF
test_expect_success PERL,SYMLINKS 'difftool --dir-diff --symlink without
unstaged changes' '
cat >expect <<-EOF &&
file
- $(pwd)/file
+ $PWD/file
file2
- $(pwd)/file2
+ $PWD/file2
sub/sub
- $(pwd)/sub/sub
+ $PWD/sub/sub
EOF
git difftool --dir-diff --symlink \
--extcmd "./.git/CHECK_SYMLINKS" branch HEAD &&
@@ -448,14 +448,14 @@ EOF
run_dir_diff_test 'difftool --dir-diff syncs worktree with unstaged change' '
test_when_finished git reset --hard &&
echo "orig content" >file &&
- git difftool -d $symlinks --extcmd "$(pwd)/modify-right-file" branch &&
+ git difftool -d $symlinks --extcmd "$PWD/modify-right-file" branch &&
echo "new content" >expect &&
test_cmp expect file
'
run_dir_diff_test 'difftool --dir-diff syncs worktree without unstaged change'
'
test_when_finished git reset --hard &&
- git difftool -d $symlinks --extcmd "$(pwd)/modify-right-file" branch &&
+ git difftool -d $symlinks --extcmd "$PWD/modify-right-file" branch &&
echo "new content" >expect &&
test_cmp expect file
'
@@ -466,7 +466,7 @@ EOF
test_expect_success PERL 'difftool --no-symlinks does not overwrite working
tree file ' '
echo "orig content" >file &&
- git difftool --dir-diff --no-symlinks --extcmd "$(pwd)/modify-file"
branch &&
+ git difftool --dir-diff --no-symlinks --extcmd "$PWD/modify-file"
branch &&
echo "new content" >expect &&
test_cmp expect file
'
@@ -482,7 +482,7 @@ test_expect_success PERL 'difftool --no-symlinks detects
conflict ' '
TMPDIR=$TRASH_DIRECTORY &&
export TMPDIR &&
echo "orig content" >file &&
- test_must_fail git difftool --dir-diff --no-symlinks --extcmd
"$(pwd)/modify-both-files" branch &&
+ test_must_fail git difftool --dir-diff --no-symlinks --extcmd
"$PWD/modify-both-files" branch &&
echo "wt content" >expect &&
test_cmp expect file &&
echo "tmp content" >expect &&
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 6146c3f..d708cbf 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -25,11 +25,11 @@ perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
test_done
}
-WORKDIR=$(pwd)
-SERVERDIR=$(pwd)/gitcvs.git
+WORKDIR=$PWD
+SERVERDIR=$PWD/gitcvs.git
git_config="$SERVERDIR/config"
CVSROOT=":fork:$SERVERDIR"
-CVSWORK="$(pwd)/cvswork"
+CVSWORK="$PWD/cvswork"
CVS_SERVER=git-cvsserver
export CVSROOT CVS_SERVER
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index 5a4ed28..f324b9f 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -74,11 +74,11 @@ perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
}
unset GIT_DIR GIT_CONFIG
-WORKDIR=$(pwd)
-SERVERDIR=$(pwd)/gitcvs.git
+WORKDIR=$PWD
+SERVERDIR=$PWD/gitcvs.git
git_config="$SERVERDIR/config"
CVSROOT=":fork:$SERVERDIR"
-CVSWORK="$(pwd)/cvswork"
+CVSWORK="$PWD/cvswork"
CVS_SERVER=git-cvsserver
export CVSROOT CVS_SERVER
diff --git a/t/t9402-git-c
[PATCH v3 15/20] Avoid absolute path in t0008
From: Pat Thoyts
The colon is used by check-ignore to separate paths from other output
values. If we use an absolute path, however, on Windows it will be
converted into a Windows path that very much contains a colon.
It is actually not at all necessary to make the path of the global
excludes absolute, so let's just not even do that.
Based on suggestions by Karsten Blees and Junio Hamano.
Suggested-by: Karsten Blees
Signed-off-by: Pat Thoyts
Signed-off-by: Johannes Schindelin
---
t/t0008-ignores.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index 4ef5ed4..89544dd 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -5,7 +5,7 @@ test_description=check-ignore
. ./test-lib.sh
init_vars () {
- global_excludes="$(pwd)/global-excludes"
+ global_excludes="global-excludes"
}
enable_global_excludes () {
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 12/20] mingw: skip test in t1508 that fails due to path conversion
In Git for Windows, the MSYS2 POSIX emulation layer used by the Bash
converts command-line arguments that looks like they refer to a POSIX
path containing a file list (i.e. @) into a Windows path
equivalent when calling non-MSYS2 executables, such as git.exe.
Let's just skip the test that uses the parameter `@/at-test` that
confuses the MSYS2 runtime.
Signed-off-by: Johannes Schindelin
---
t/t1508-at-combinations.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 078e119..4a9964e 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -35,7 +35,10 @@ test_expect_success 'setup' '
git checkout -b upstream-branch &&
test_commit upstream-one &&
test_commit upstream-two &&
- git checkout -b @/at-test &&
+ if test_have_prereq !MINGW
+ then
+ git checkout -b @/at-test
+ fi &&
git checkout -b @@/at-test &&
git checkout -b @at-test &&
git checkout -b old-branch &&
@@ -64,6 +67,7 @@ check "@{-1}@{u}@{1}" commit master-one
check "@" commit new-two
check "@@{u}" ref refs/heads/upstream-branch
check "@@/at-test" ref refs/heads/@@/at-test
+test_have_prereq MINGW ||
check "@/at-test" ref refs/heads/@/at-test
check "@at-test" ref refs/heads/@at-test
nonsense "@{u}@{-1}"
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 03/20] Git.pm: stop assuming that absolute paths start with a slash
On Windows, absolute paths never start with a slash, unless a POSIX
emulation layer is used. The latter is the case for MSYS2's Perl that
Git for Windows leverages. However, in the tests we also go through
plain `git.exe`, which does *not* leverage the POSIX emulation layer,
and therefore the paths we pass to Perl may actually be DOS-style paths
such as C:/Program Files/Git.
So let's just use Perl's own way to test whether a given path is
absolute or not instead of home-brewing our own.
This patch partially fixes t7800 and t9700 when running in Git for
Windows' SDK.
Signed-off-by: Johannes Schindelin
---
perl/Git.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 19ef081..49eb88a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -188,7 +188,8 @@ sub repository {
};
if ($dir) {
- $dir =~ m#^/# or $dir = $opts{Directory} . '/' . $dir;
+ _verify_require();
+ File::Spec->file_name_is_absolute($dir) or $dir =
$opts{Directory} . '/' . $dir;
$opts{Repository} = abs_path($dir);
# If --git-dir went ok, this shouldn't die either.
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 05/20] mingw: prepare the TMPDIR environment variable for shell scripts
When shell scripts access a $TMPDIR variable containing backslashes,
they will be mistaken for escape characters. Let's not let that happen
by converting them to forward slashes.
This partially fixes t7800 with MSYS2.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 8d52c73..ba5cb1c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2049,13 +2049,28 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t
utflen)
static void setup_windows_environment()
{
+ char *tmp = getenv("TMPDIR");
+
/* on Windows it is TMP and TEMP */
- if (!getenv("TMPDIR")) {
- const char *tmp = getenv("TMP");
- if (!tmp)
+ if (!tmp) {
+ if (!(tmp = getenv("TMP")))
tmp = getenv("TEMP");
- if (tmp)
+ if (tmp) {
setenv("TMPDIR", tmp, 1);
+ tmp = getenv("TMPDIR");
+ }
+ }
+
+ if (tmp) {
+ /*
+* Convert all dir separators to forward slashes,
+* to help shell commands called from the Git
+* executable (by not mistaking the dir separators
+* for escape characters).
+*/
+ for (; *tmp; tmp++)
+ if (*tmp == '\\')
+ *tmp = '/';
}
/* simulate TERM to enable auto-color (see color.c) */
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 02/20] mingw: do not trust MSYS2's MinGW gettext.sh
It does not quite work because it produces DOS line endings which the shell does not like at all. This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh, t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh, t7401-submodule-summary.sh, t7406-submodule-update.sh and t7407-submodule-foreach.sh pass in Git for Windows' SDK. Signed-off-by: Johannes Schindelin --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 6b25661..d6f7980 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -561,6 +561,7 @@ else INTERNAL_QSORT = YesPlease HAVE_LIBCHARSET_H = YesPlease NO_GETTEXT = + USE_GETTEXT_SCHEME = fallthrough USE_LIBPCRE= YesPlease NO_CURL = USE_NED_ALLOCATOR = YesPlease -- 2.7.0.windows.1.7.g55a05c8 -- 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 v3 19/20] mingw: skip a test in t9130 that cannot pass on Windows
On Windows, Git itself has no clue about POSIX paths, but its shell scripts do. In this instance, we get mixed paths as a result, and when comparing the path of the author file, we get a mismatch that is entirely due to the POSIX path vs Windows path clash. Let's just skip this test so that t9130-git-svn-authors-file.sh passes in Git for Windows' SDK. Signed-off-by: Johannes Schindelin --- t/t9130-git-svn-authors-file.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9130-git-svn-authors-file.sh b/t/t9130-git-svn-authors-file.sh index d306b77..4126481 100755 --- a/t/t9130-git-svn-authors-file.sh +++ b/t/t9130-git-svn-authors-file.sh @@ -91,7 +91,7 @@ test_expect_success 'fetch continues after authors-file is fixed' ' ) ' -test_expect_success 'fresh clone with svn.authors-file in config' ' +test_expect_success !MINGW 'fresh clone with svn.authors-file in config' ' ( rm -r "$GIT_DIR" && test x = x"$(git config svn.authorsfile)" && -- 2.7.0.windows.1.7.g55a05c8 -- 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 v3 00/20] Let Git's tests pass on Windows
This is a big milestone. With these modifications, Git's source code does not only build without warnings in Git for Windows' SDK, but passes the entire regression test suite. The patch series contains three different types of patches. First, there are a couple of real fixes that were triggered by failures in the regression tests. Then there are a couple of fixes to the regression tests themselves. And finally, we have to disable a couple of tests because we simply cannot make them work on Windows. Relative to v2, this fixes stupid typos that made the tests fail on Linux, a stupid copy-paste error pointed out by Eric Sunshine, unnecessary 'printf ""' calls pointed out by Junio Hamano, and I now use `test_have_prereq !MINGW` consistently, as pointed out by both Eric and Junio. This time, I also send the patch series with the character set set (sic!) to UTF-8. Oh, and this time, I also made sure that the regression tests pass on Windows & Linux alike. Oh, and I also managed not to forget the fix for t9130 this time. Johannes Schindelin (17): mingw: let's use gettext with MSYS2 mingw: do not trust MSYS2's MinGW gettext.sh Git.pm: stop assuming that absolute paths start with a slash mingw: prepare the TMPDIR environment variable for shell scripts mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: fix t5601-clone.sh mingw: accomodate t0060-path-utils for MSYS2 mingw: disable mkfifo-based tests tests: turn off git-daemon tests if FIFOs are not available mingw: skip test in t1508 that fails due to path conversion mingw: fix t9700's assumption about directory separators mingw: work around pwd issues in the tests mingw: mark t9100's test cases with appropriate prereqs mingw: avoid illegal filename in t9118 mingw: handle the missing POSIXPERM prereq in t9124 mingw: skip a test in t9130 that cannot pass on Windows mingw: do not bother to test funny file names Karsten Blees (1): mingw: factor out Windows specific environment setup Pat Thoyts (1): Avoid absolute path in t0008 마누엘 (1): mingw: try to delete target directory before renaming Makefile | 1 + compat/mingw.c| 91 +-- config.mak.uname | 3 +- perl/Git.pm | 3 +- t/lib-git-daemon.sh | 5 ++ t/t0008-ignores.sh| 2 +- t/t0060-path-utils.sh | 9 t/t1508-at-combinations.sh| 6 ++- t/t3300-funny-names.sh| 1 + t/t3600-rm.sh | 2 +- t/t3703-add-magic-pathspec.sh | 2 +- t/t3902-quoted.sh | 1 + t/t4016-diff-quote.sh | 1 + t/t4135-apply-weird-filenames.sh | 3 +- t/t5601-clone.sh | 18 +++ t/t7800-difftool.sh | 14 +++--- t/t9100-git-svn-basic.sh | 18 +++ t/t9118-git-svn-funky-branch-names.sh | 12 +++-- t/t9124-git-svn-dcommit-auto-props.sh | 16 +++--- t/t9130-git-svn-authors-file.sh | 2 +- t/t9200-git-cvsexportcommit.sh| 2 +- t/t9400-git-cvsserver-server.sh | 6 +-- t/t9401-git-cvsserver-crlf.sh | 6 +-- t/t9402-git-cvsserver-refs.sh | 6 +-- t/t9700/test.pl | 2 +- t/t9903-bash-prompt.sh| 2 +- t/test-lib.sh | 2 +- test-fake-ssh.c | 30 28 files changed, 196 insertions(+), 70 deletions(-) create mode 100644 test-fake-ssh.c Interdiff vs v2: diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh index c59d554..4a9964e 100755 --- a/t/t1508-at-combinations.sh +++ b/t/t1508-at-combinations.sh @@ -35,9 +35,9 @@ test_expect_success 'setup' ' git checkout -b upstream-branch && test_commit upstream-one && test_commit upstream-two && - if ! test_have_prereq MINGW + if test_have_prereq !MINGW then - git checkout -b @/at-slash + git checkout -b @/at-test fi && git checkout -b @@/at-test && git checkout -b @at-test && diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 5232ee9..d046d98 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -14,8 +14,7 @@ test_expect_success \ git add -- foo bar baz 'space embedded' -q && git commit -m 'add normal files'" - -if ! test_have_prereq MINGW && touch -- 'tab embedded' 'newline +if test_have_prereq !MINGW && touch -- 'tab embedded' 'newline embedded' 2>/dev/null then test_set_prereq FUNNYNAMES diff --git a/t/t3703-add-magic-pathspec.sh b/t/t3703-add-magic-pathspec.sh index aaff784..3ef525a 100755 --- a/t/t3703-add-magic-pathspec.sh +++ b/t/t3703-add-magic-pathspec.sh @@ -38,7 +38,7 @@ cat >expected /dev/null then test_set_prereq COLON_DIR fi diff -
[PATCH v3 04/20] mingw: factor out Windows specific environment setup
From: Karsten Blees
We will add more environment-related code to that new function
in the next patch.
Signed-off-by: Karsten Blees
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 77a51d3..8d52c73 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2047,6 +2047,22 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t
utflen)
return -1;
}
+static void setup_windows_environment()
+{
+ /* on Windows it is TMP and TEMP */
+ if (!getenv("TMPDIR")) {
+ const char *tmp = getenv("TMP");
+ if (!tmp)
+ tmp = getenv("TEMP");
+ if (tmp)
+ setenv("TMPDIR", tmp, 1);
+ }
+
+ /* simulate TERM to enable auto-color (see color.c) */
+ if (!getenv("TERM"))
+ setenv("TERM", "cygwin", 1);
+}
+
/*
* Disable MSVCRT command line wildcard expansion (__getmainargs called from
* mingw startup code, see init.c in mingw runtime).
@@ -2125,19 +2141,7 @@ void mingw_startup()
qsort(environ, i, sizeof(char*), compareenv);
/* fix Windows specific environment settings */
-
- /* on Windows it is TMP and TEMP */
- if (!mingw_getenv("TMPDIR")) {
- const char *tmp = mingw_getenv("TMP");
- if (!tmp)
- tmp = mingw_getenv("TEMP");
- if (tmp)
- setenv("TMPDIR", tmp, 1);
- }
-
- /* simulate TERM to enable auto-color (see color.c) */
- if (!getenv("TERM"))
- setenv("TERM", "cygwin", 1);
+ setup_windows_environment();
/* initialize critical section for waitpid pinfo_t list */
InitializeCriticalSection(&pinfo_cs);
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 06/20] mingw: try to delete target directory before renaming
From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?=
When the rename() function tries to move a directory it fails if the
target directory exists. It should check if it can delete the (possibly
empty) target directory and then try again to move the directory.
This partially fixes t9100-git-svn-basic.sh.
Signed-off-by: 마누엘
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index ba5cb1c..f37f8d5 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1603,7 +1603,12 @@ repeat:
if (gle == ERROR_ACCESS_DENIED &&
(attrs = GetFileAttributesW(wpnew)) != INVALID_FILE_ATTRIBUTES) {
if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
- errno = EISDIR;
+ DWORD attrsold = GetFileAttributesW(wpold);
+ if (attrsold == INVALID_FILE_ATTRIBUTES ||
+ !(attrsold & FILE_ATTRIBUTE_DIRECTORY))
+ errno = EISDIR;
+ else if (!_wrmdir(wpnew))
+ goto repeat;
return -1;
}
if ((attrs & FILE_ATTRIBUTE_READONLY) &&
--
2.7.0.windows.1.7.g55a05c8
[PATCH v3 18/20] mingw: handle the missing POSIXPERM prereq in t9124
On Windows, the permission system works completely differently than expected by some of the tests. So let's make sure that we do not test POSIX functionality on Windows. This lets t9124-git-svn-dcommit-auto-props.sh pass in Git for Windows' SDK. Signed-off-by: Johannes Schindelin --- t/t9124-git-svn-dcommit-auto-props.sh | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/t/t9124-git-svn-dcommit-auto-props.sh b/t/t9124-git-svn-dcommit-auto-props.sh index aa841e1..9f7231d 100755 --- a/t/t9124-git-svn-dcommit-auto-props.sh +++ b/t/t9124-git-svn-dcommit-auto-props.sh @@ -34,8 +34,7 @@ test_expect_success 'enable auto-props config' ' ' test_expect_success 'add files matching auto-props' ' - echo "#!$SHELL_PATH" >exec1.sh && - chmod +x exec1.sh && + write_script exec1.sh hello.txt && echo bar >bar && git add exec1.sh hello.txt bar && @@ -48,8 +47,7 @@ test_expect_success 'disable auto-props config' ' ' test_expect_success 'add files matching disabled auto-props' ' - echo "#$SHELL_PATH" >exec2.sh && - chmod +x exec2.sh && + write_script exec2.sh world.txt && echo zot >zot && git add exec2.sh world.txt zot && @@ -65,7 +63,10 @@ test_expect_success 'check resulting svn repository' ' cd svnrepo && # Check properties from first commit. - test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" && + if test_have_prereq POSIXPERM + then + test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" + fi && test "x$(svn_cmd propget svn:mime-type exec1.sh)" = \ "xapplication/x-shellscript" && test "x$(svn_cmd propget svn:mime-type hello.txt)" = "xtext/plain" && @@ -73,7 +74,10 @@ test_expect_success 'check resulting svn repository' ' test "x$(svn_cmd propget svn:mime-type bar)" = "x" && # Check properties from second commit. - test "x$(svn_cmd propget svn:executable exec2.sh)" = "x*" && + if test_have_prereq POSIXPERM + then + test "x$(svn_cmd propget svn:executable exec2.sh)" = "x*" + fi && test "x$(svn_cmd propget svn:mime-type exec2.sh)" = "x" && test "x$(svn_cmd propget svn:mime-type world.txt)" = "x" && test "x$(svn_cmd propget svn:eol-style world.txt)" = "x" && -- 2.7.0.windows.1.7.g55a05c8 -- 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 v3 16/20] mingw: mark t9100's test cases with appropriate prereqs
Many a test requires either POSIXPERM (to change the executable bit) or
SYMLINKS, and neither are available on Windows.
This lets t9100-git-svn-basic.sh pass in Git for Windows' SDK.
Signed-off-by: Johannes Schindelin
---
t/t9100-git-svn-basic.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 258d9b8..56acc1e 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -30,8 +30,7 @@ test_expect_success \
echo "deep dir" >dir/a/b/c/d/e/file &&
mkdir bar &&
echo "zzz" >bar/zzz &&
- echo "#!/bin/sh" >exec.sh &&
- chmod +x exec.sh &&
+ write_script exec.sh /dev/null
) &&
rm -rf import &&
@@ -117,7 +116,7 @@ test_expect_success "$name" '
name='remove executable bit from a file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM "$name" '
rm -f "$GIT_DIR"/index &&
git checkout -f -b mybranch5 ${remotes_git_svn} &&
chmod -x exec.sh &&
@@ -130,7 +129,7 @@ test_expect_success "$name" '
name='add executable bit back file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM "$name" '
chmod +x exec.sh &&
git update-index exec.sh &&
git commit -m "$name" &&
@@ -141,7 +140,7 @@ test_expect_success "$name" '
name='executable file becomes a symlink to file'
-test_expect_success "$name" '
+test_expect_success SYMLINKS "$name" '
rm exec.sh &&
ln -s file exec.sh &&
git update-index exec.sh &&
@@ -153,7 +152,7 @@ test_expect_success "$name" '
name='new symlink is added to a file that was also just made executable'
-test_expect_success "$name" '
+test_expect_success POSIXPERM,SYMLINKS "$name" '
chmod +x file &&
ln -s file exec-2.sh &&
git update-index --add file exec-2.sh &&
@@ -165,7 +164,7 @@ test_expect_success "$name" '
test -h "$SVN_TREE"/exec-2.sh'
name='modify a symlink to become a file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM,SYMLINKS "$name" '
echo git help >help &&
rm exec-2.sh &&
cp help exec-2.sh &&
@@ -181,7 +180,8 @@ test_expect_success "$name" '
name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL"
LC_ALL="$GIT_SVN_LC_ALL"
export LC_ALL
-test_expect_success UTF8 "$name" "
+# This test relies on the previous test, hence requires POSIXPERM,SYMLINKS
+test_expect_success UTF8,POSIXPERM,SYMLINKS "$name" "
echo '# hello' >> exec-2.sh &&
git update-index exec-2.sh &&
git commit -m '???' &&
@@ -214,7 +214,7 @@ tree d667270a1f7b109f5eb3aaea21ede14b56bfdd6e
tree 8f51f74cf0163afc9ad68a4b1537288c4558b5a4
EOF
-test_expect_success "$name" "test_cmp a expected"
+test_expect_success POSIXPERM,SYMLINKS "$name" "test_cmp a expected"
test_expect_success 'exit if remote refs are ambigious' "
git config --add svn-remote.svn.fetch \
--
2.7.0.windows.1.7.g55a05c8
[PATCH v3 09/20] mingw: accomodate t0060-path-utils for MSYS2
On Windows, there are no POSIX paths, only Windows ones (an absolute
Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under
most circumstances, forward slashes are also allowed and synonymous to
backslashes).
So when a POSIX shell (such as MSYS2's Bash, which is used by Git for
Windows to execute all those shell scripts that are part of Git) passes
a POSIX path to test-path-utils.exe (which is not POSIX-aware), the path
is translated into a Windows path. For example, /etc/profile becomes
C:/Program Files/Git/etc/profile.
This path translation poses a problem when passing the root directory as
parameter to test-path-utils.exe, as it is not well defined whether the
translated root directory should end in a slash or not. MSys1 stripped
the trailing slash, but MSYS2 does not.
Originally, the Git for Windows project patched MSYS2's runtime to
accomodate Git's regression test, but we really should do it the other
way round.
To work with both of MSys1's and MSYS2's behaviors, we simply test what
the current system does in the beginning of t0060-path-utils.sh and then
adjust the expected longest ancestor length accordingly.
It looks quite a bit tricky what we actually do in this patch: first, we
adjust the expected length for the trailing slash we did not originally
expect (subtracting one). So far, so good.
But now comes the part where things work in a surprising way: when the
expected length was 0, the prefix to match is the root directory. If the
root directory is converted into a path with a trailing slash, however,
we know that the logic in longest_ancestor_length() cannot match: to
avoid partial matches of the last directory component, it verifies that
the character after the matching prefix is a slash (but because the
slash was part of the matching prefix, the next character cannot be a
slash). So the return value is -1. Alas, this is exactly what the
expected length is after subtracting the value of $rootslash! So we skip
adding the $rootoff value in that case (and only in that case).
Directories other than the root directory are handled fine (as they are
specified without a trailing slash, something not possible for the root
directory, and MSYS2 converts them into Windows paths that also lack
trailing slashes), therefore we do not need any more special handling.
Thanks to Ray Donnelly for his patient help with this issue.
Signed-off-by: Johannes Schindelin
---
t/t0060-path-utils.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index f0152a7..8532a02 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -36,12 +36,21 @@ if test $rootoff = 2; then
rootoff=# we are on Unix
else
rootoff=$(($rootoff-1))
+ # In MSYS2, the root directory "/" is translated into a Windows
+ # directory *with* trailing slash. Let's test for that and adjust
+ # our expected longest ancestor length accordingly.
+ case "$(test-path-utils print_path /)" in
+ */) rootslash=1;;
+ *) rootslash=0;;
+ esac
fi
ancestor() {
# We do some math with the expected ancestor length.
expected=$3
if test -n "$rootoff" && test "x$expected" != x-1; then
+ expected=$(($expected-$rootslash))
+ test $expected -lt 0 ||
expected=$(($expected+$rootoff))
fi
test_expect_success "longest ancestor: $1 $2 => $expected" \
--
2.7.0.windows.1.7.g55a05c8
--
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 v3 17/20] mingw: avoid illegal filename in t9118
On Windows' file systems, file names with trailing dots are forbidden. The POSIX emulation layer used by Git for Windows' Subversion emulates those file names, therefore the test adding the file would actually succeed, but when we would ask git.exe (which does not leverage the POSIX emulation layer) to check out the tree, it would fail. Let's just guard the test using a filename that is illegal on Windows by the MINGW prereq. This lets t9118-git-svn-funky-branch-names.sh pass in Git for Windows' SDK. Signed-off-by: Johannes Schindelin --- t/t9118-git-svn-funky-branch-names.sh | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/t/t9118-git-svn-funky-branch-names.sh b/t/t9118-git-svn-funky-branch-names.sh index a221915..ecb1fed 100755 --- a/t/t9118-git-svn-funky-branch-names.sh +++ b/t/t9118-git-svn-funky-branch-names.sh @@ -23,8 +23,11 @@ test_expect_success 'setup svnrepo' ' "$svnrepo/pr ject/branches/$scary_uri" && svn_cmd cp -m "leading dot" "$svnrepo/pr ject/trunk" \ "$svnrepo/pr ject/branches/.leading_dot" && - svn_cmd cp -m "trailing dot" "$svnrepo/pr ject/trunk" \ - "$svnrepo/pr ject/branches/trailing_dot." && + if test_have_prereq !MINGW + then + svn_cmd cp -m "trailing dot" "$svnrepo/pr ject/trunk" \ + "$svnrepo/pr ject/branches/trailing_dot." + fi && svn_cmd cp -m "trailing .lock" "$svnrepo/pr ject/trunk" \ "$svnrepo/pr ject/branches/trailing_dotlock.lock" && svn_cmd cp -m "reflog" "$svnrepo/pr ject/trunk" \ @@ -45,7 +48,10 @@ test_expect_success 'test clone with funky branch names' ' git rev-parse "refs/remotes/origin/more%20fun%20plugin!" && git rev-parse "refs/remotes/origin/$scary_ref" && git rev-parse "refs/remotes/origin/%2Eleading_dot" && - git rev-parse "refs/remotes/origin/trailing_dot%2E" && + if test_have_prereq !MINGW + then + git rev-parse "refs/remotes/origin/trailing_dot%2E" + fi && git rev-parse "refs/remotes/origin/trailing_dotlock%2Elock" && git rev-parse "refs/remotes/origin/$non_reflog" ) -- 2.7.0.windows.1.7.g55a05c8 -- 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 v3 20/20] mingw: do not bother to test funny file names
MSYS2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSYS2 bash to run the tests, such files or
directories are created successfully, but Git itself has no chance to
work with them because it is a regular Windows program, hence limited by
the Win32 API.
With this change, on Windows otherwise failing tests in
t3300-funny-names.sh, t3600-rm.sh, t3703-add-magic-pathspec.sh,
t3902-quoted.sh, t4016-diff-quote.sh, t4135-apply-weird-filenames.sh,
t9200-git-cvsexportcommit.sh, and t9903-bash-prompt.sh are skipped.
Signed-off-by: Johannes Schindelin
---
t/t3300-funny-names.sh | 1 +
t/t3600-rm.sh| 2 +-
t/t3703-add-magic-pathspec.sh| 2 +-
t/t3902-quoted.sh| 1 +
t/t4016-diff-quote.sh| 1 +
t/t4135-apply-weird-filenames.sh | 3 ++-
t/t9200-git-cvsexportcommit.sh | 2 +-
t/t9903-bash-prompt.sh | 2 +-
8 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 9a146f1..04de03c 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -13,6 +13,7 @@ tree, index, and tree objects.
HT=' '
+test_have_prereq MINGW ||
echo 2>/dev/null > "Name with an${HT}HT"
if ! test -f "Name with an${HT}HT"
then
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 2e47a2b..d046d98 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -14,7 +14,7 @@ test_expect_success \
git add -- foo bar baz 'space embedded' -q &&
git commit -m 'add normal files'"
-if touch -- 'tab embedded' 'newline
+if test_have_prereq !MINGW && touch -- 'tabembedded' 'newline
embedded' 2>/dev/null
then
test_set_prereq FUNNYNAMES
diff --git a/t/t3703-add-magic-pathspec.sh b/t/t3703-add-magic-pathspec.sh
index 5115de7..3ef525a 100755
--- a/t/t3703-add-magic-pathspec.sh
+++ b/t/t3703-add-magic-pathspec.sh
@@ -38,7 +38,7 @@ cat >expected /dev/null
then
test_set_prereq COLON_DIR
fi
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
index 892f567..f528008 100755
--- a/t/t3902-quoted.sh
+++ b/t/t3902-quoted.sh
@@ -12,6 +12,7 @@ GN='???'
HT=' '
DQ='"'
+test_have_prereq MINGW ||
echo foo 2>/dev/null > "Name and an${HT}HT"
if ! test -f "Name and an${HT}HT"
then
diff --git a/t/t4016-diff-quote.sh b/t/t4016-diff-quote.sh
index cd543ec..9c48e5c 100755
--- a/t/t4016-diff-quote.sh
+++ b/t/t4016-diff-quote.sh
@@ -13,6 +13,7 @@ P1='pathname with HT'
P2='pathname with SP'
P3='pathname
with LF'
+test_have_prereq !MINGW &&
echo 2>/dev/null >"$P1" && test -f "$P1" && rm -f "$P1" || {
skip_all='Your filesystem does not allow tabs in filenames'
test_done
diff --git a/t/t4135-apply-weird-filenames.sh b/t/t4135-apply-weird-filenames.sh
index bf5dc57..27cb000 100755
--- a/t/t4135-apply-weird-filenames.sh
+++ b/t/t4135-apply-weird-filenames.sh
@@ -19,7 +19,8 @@ test_expect_success 'setup' '
test_when_finished "rm -f \"tab embedded.txt\"" &&
test_when_finished "rm -f '\''\"quoteembedded\".txt'\''" &&
- if touch -- "tabembedded.txt" '\''"quoteembedded".txt'\''
+ if test_have_prereq !MINGW &&
+ touch -- "tab embedded.txt" '\''"quoteembedded".txt'\''
then
test_set_prereq FUNNYNAMES
fi
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 812c9cd..5cfb9cf 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -197,7 +197,7 @@ if
p="??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/??" &&
then
# This test contains UTF-8 characters
-test_expect_success \
+test_expect_success !MINGW \
'File with non-ascii file name' \
'mkdir -p
??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/?? &&
echo Foo
>??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/??/g??rdets??g??rdet.txt
&&
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index af82049..ffbfa0e 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -67,7 +67,7 @@ repo_with_newline='repo
with
newline'
-if mkdir "$repo_with_newline" 2>/dev/null
+if test_have_prereq !MINGW && mkdir "$repo_with_newline" 2>/dev/null
then
test_set_prereq FUNNYNAMES
else
--
2.7.0.windows.1.7.g55a05c8
Re: [PATCH v2 16/19] mingw: mark t9100's test cases with appropriate prereqs
Hi Junio, On Tue, 26 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > @@ -181,7 +180,8 @@ test_expect_success "$name" ' > > name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL" > > LC_ALL="$GIT_SVN_LC_ALL" > > export LC_ALL > > -test_expect_success UTF8 "$name" " > > +# This test relies on the previous test, hence requires POSIXPERM,SYMLINKS > > +test_expect_success UTF8,POSIXPERM,SYMLINKS "$name" " > > echo '# hello' >> exec-2.sh && > > git update-index exec-2.sh && > > git commit -m '???' && > > Hmph. "Content-Type: text/plain; charset=X-UNKNOWN" in the header > gives a hint to me, too. Bah. I recently upgraded to a newer Alpine and must have overlooked the unknown charset option. Sorry for that, I think I fixed it now (let me know if not). Ciao, Dscho -- 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 for windows
Hi Andrey, we never saw the two mails you were replying to, and please note that 1) the preferred place to report bugs in Git for Windows is https://github.com/git-for-windows/git/issues, as outlined in https://git-for-windows.github.io/#contribute, and that 2) top-posting will most likely result in less responses than you would want. > > On 1/27/2016 2:32 PM, Andrey Chernyshov wrote: > > > > > > I'm using PHP storm with git for windows. Once I do a push to the github > > > I get the following error > > Problem signature: > > Problem Event Name:APPCRASH > > Application Name:git-remote-https.exe > > Application Version:2.7.0.0 > > Application Timestamp:35316130 > > Fault Module Name:libidn-11.dll > > Fault Module Version:0.0.0.0 > > Fault Module Timestamp:00170158 > > Exception Code:c005 > > Exception Offset:46bc > > OS Version:6.3.9600.2.0.0.256.4 > > Locale ID:1033 > > Additional Information 1:a547 > > Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4 > > Additional Information 3:ac01 > > Additional Information 4:ac010ce737711604ec050156caebd625 > > > > Read our privacy statement online: > > http://go.microsoft.com/fwlink/?linkid=280262 > > > > If the online privacy statement is not available, please read our privacy > > statement offline: > > C:\windows\system32\en-US\erofflps.txt > > > > > If I try to push with Git GUI, it's the same, so not a PHPStorm issue... If you can come up with a minimal, complete & verifiable example (see http://stackoverflow.com/help/mcve), it is much more likely that I can help you than it is right now. My only guess is that you might be able to work around the issue by setting the environment variable `CHARSET` to something like `cp1252` before pushing. But that's the extent of the help I have to offer unless the time when I have a chance to reproduce this on my computer. Ciao, Johannes -- 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] optionally disable gitattributes
On Wed, Jan 27, 2016 at 04:04:39PM +0100, Torsten Bögershausen wrote: > > It feels like a workaround for something that could be fixable, or is already > ongoing. > Before going into more details, > could you tell us which attributes you are typically using (when having this > problems) ? > Is it > * text=auto > or > *.sh text > or something else? My concrete use case is the text attribute, as in your example: "*.sh text". But I think of the patch as a more general solution for cases where we want to work with the files as they are committed, without having to deal with not normalized files or other conversions due to gitattributes. Please note that you may also want to read my reply to the other thread that Junio mentioned: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest. -- 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] travis-ci: run previously failed tests first, then slowest to fastest
I think Junio pointed me to this thread from "[PATCH] optionally disable gitattributes". Since I am not sure I am following everything correctly in this thread, allow me to recapitulate what I understood so far. Firstly, I think the racy'ness of t0025 is understood. It is due to the is_racy_timestamp check in read-cache.c's ie_match_stat. But for the moment I would like to put this aside, because the issue can be reproduced reliably with this change to t0025: diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh index c164b46..e30e9b3 100755 --- a/t/t0025-crlf-auto.sh +++ b/t/t0025-crlf-auto.sh @@ -55,8 +55,11 @@ test_expect_success 'crlf=true causes a CRLF file to be normalized' ' test_expect_success 'text=true causes a CRLF file to be normalized' ' rm -f .gitattributes tmp LFonly CRLFonly LFwithNUL && - echo "CRLFonly text" > .gitattributes && git read-tree --reset -u HEAD && + sleep 1 && + rm .git/index && + git reset && + echo "CRLFonly text" > .gitattributes && # Note, "normalized" means that git will normalize it if added has_cr CRLFonly && I intentionally wait for one second and then I remove and re-read the index. Now the timestamps of CRLFonly and .git/index are different, so we avoid the is_racy_timestamp check. From now on Git will not read the contents of CRLFonly from disk again until either the index entry or the mtime of CRLFonly changes (maybe we also check the size, I am not sure). Now we add .gitattributes. This does not change the index entry, nor does it change the mtime of CRLFonly. Therefore the subsequent git diff turns out empty, and the test fails. I believe this behavior is expected. In gitattributes(5) we therefore recommend using rm .git/index and git reset to "force Git to rescan the working directory." The test should be fixed accordingly, something like: diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh index c164b46..2917591 100755 --- a/t/t0025-crlf-auto.sh +++ b/t/t0025-crlf-auto.sh @@ -57,6 +57,8 @@ test_expect_success 'text=true causes a CRLF file to be normalized' ' rm -f .gitattributes tmp LFonly CRLFonly LFwithNUL && echo "CRLFonly text" > .gitattributes && git read-tree --reset -u HEAD && + rm .git/index && + git reset && # Note, "normalized" means that git will normalize it if added has_cr CRLFonly && On Mon, Jan 25, 2016 at 01:52:18PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > I do not think there is a canned command to help dealing with these > > broken paths right now. I think (rm .git/index && git reset) works well enough in most cases, but not all: > We could go even fancier and attempt the round-trip twice or more. > It is possible that the in-index representation will not converge > when you use a misconfigured pair of clean/smudge filters This can also happen with eol conversion, for example if you have files with CRCRLF line endings. The eol conversion will remove only one CR. Two conversions would be needed to achieve a normalized format. But iterating (rm .git/index && git reset) does not help. Since we do not touch the file on disk, after the first round, we have CRCRLF on disk and CRLF in the index. During the second round, Git reads CRCRLF from disk again, converts it to CRLF, which matches the index. Even git reset --hard will not checkout the CRLF version to the worktree. A possible solution is to iterate (rm -r * && git checkout -- . && git add -u) until the work tree is clean. Quite ugly. A command like git add --fix-index would make this conversion less painful. It should be ok if the user has to run it several times in corner cases like CRCRLF, but it would be nice to issue a warning if the index is still not normalized after running git add --fix-index. Regarding the name of the option, maybe git add --renormalize-index would be more consistent, since we also have the related merge option "renormalize", which is very similar. In fact possibly you can share some code with it. Your patch looks good to me otherwise. Coming back to "[PATCH] optionally disable gitattributes": The topics are related, because they both deal with the situation where the work tree has files which are not normalized according to gitattributes. But my patch is more about saying: ok, I know I may have files which need to be normalized, but I want to ignore this issue for now. Please disable gitattributes for now, because I want to work with the files as they are committed. Conversely, the discussion here is about how to reliably detect and fix files which are not normalized. -- 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 v1 1/6] t0027: Add tests for get_stream_filter()
From: Torsten Bögershausen
When a filter is configured, a different code-path is used in convert.c
and entry.c via get_stream_filter(), but there are no test cases yet.
Add tests for the filter API by configuring the ident filter.
The result of the SHA1 conversion is not checked, this is already
done in other TC.
Add a parameter to checkout_files() in t0027.
While changing the signature, add another parameter for the eol= attribute.
This is currently unused, tests for e.g.
"* text=auto eol=lf" will be added in a separate commit.
Signed-off-by: Torsten Bögershausen
---
t/t0027-auto-crlf.sh | 262 ---
1 file changed, 146 insertions(+), 116 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 504e5a0..08fe6a5 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -21,32 +21,45 @@ compare_ws_file () {
pfx=$1
exp=$2.expect
act=$pfx.actual.$3
- tr '\015\000' QN <"$2" >"$exp" &&
- tr '\015\000' QN <"$3" >"$act" &&
+ tr '\015\000abcdef01234567890' QN0 <"$2" >"$exp" &&
+ tr '\015\000abcdef01234567890' QN0 <"$3" >"$act" &&
test_cmp $exp $act &&
rm $exp $act
}
create_gitattributes () {
attr=$1
+ ident=$2
+ case "$2" in
+ "")
+ >.gitattributes
+ ;;
+ i)
+ echo "* ident" >.gitattributes
+ ;;
+ *)
+ echo >&2 invalid ident: $2
+ exit 1
+ esac
+
case "$attr" in
auto)
- echo "*.txt text=auto" >.gitattributes
+ echo "*.txt text=auto" >>.gitattributes
;;
text)
- echo "*.txt text" >.gitattributes
+ echo "*.txt text" >>.gitattributes
;;
-text)
- echo "*.txt -text" >.gitattributes
+ echo "*.txt -text" >>.gitattributes
;;
crlf)
- echo "*.txt eol=crlf" >.gitattributes
+ echo "*.txt eol=crlf" >>.gitattributes
;;
lf)
- echo "*.txt eol=lf" >.gitattributes
+ echo "*.txt eol=lf" >>.gitattributes
;;
"")
- echo >.gitattributes
+ #echo >.gitattributes
;;
*)
echo >&2 invalid attribute: $attr
@@ -90,7 +103,7 @@ commit_check_warn () {
lfmixcr=$6
crlfnul=$7
pfx=crlf_${crlf}_attr_${attr}
- create_gitattributes "$attr" &&
+ create_gitattributes "$attr" "" &&
for f in LF CRLF LF_mix_CR CRLF_mix_LF LF_nul CRLF_nul
do
fname=${pfx}_$f.txt &&
@@ -115,7 +128,7 @@ commit_chk_wrnNNO () {
crlfnul=$7
pfx=NNO_${crlf}_attr_${attr}
#Commit files on top of existing file
- create_gitattributes "$attr" &&
+ create_gitattributes "$attr" "" &&
for f in LF CRLF CRLF_mix_LF LF_mix_CR CRLF_nul
do
fname=${pfx}_$f.txt &&
@@ -208,28 +221,30 @@ check_in_repo_NNO () {
}
checkout_files () {
- eol=$1
- crlf=$2
- attr=$3
- lfname=$4
- crlfname=$5
- lfmixcrlf=$6
- lfmixcr=$7
- crlfnul=$8
- create_gitattributes $attr &&
+ attr=$1 ; shift
+ ident=$1; shift
+ aeol=$1 ; shift
+ crlf=$1 ; shift
+ ceol=$1 ; shift
+ lfname=$1 ; shift
+ crlfname=$1 ; shift
+ lfmixcrlf=$1 ; shift
+ lfmixcr=$1 ; shift
+ crlfnul=$1 ; shift
+ create_gitattributes "$attr" "$ident" &&
git config core.autocrlf $crlf &&
- pfx=eol_${eol}_crlf_${crlf}_attr_${attr}_ &&
+ pfx=eol_${ceol}_crlf_${crlf}_attr_${attr}_ &&
for f in LF CRLF LF_mix_CR CRLF_mix_LF LF_nul
do
rm crlf_false_attr__$f.txt &&
- if test -z "$eol"; then
+ if test -z "$ceol"; then
git checkout crlf_false_attr__$f.txt
else
- git -c core.eol=$eol checkout crlf_false_attr__$f.txt
+ git -c core.eol=$ceol checkout crlf_false_attr__$f.txt
fi
done
- test_expect_success "ls-files --eol $lfname ${pfx}LF.txt" '
+ test_expect_success "ls-files --eol attr=$attr i=$ident $aeol
core.autocrlf=$crlf core.eol=$ceol" '
test_when_finished "rm expect actual" &&
sort <<-EOF >expect &&
i/crlf w/$(stats_ascii $crlfname) crlf_false_attr__CRLF.txt
@@ -244,19 +259,19 @@ checkout_files () {
sort >actual &&
test_cmp expect actual
'
- test_expect_success "checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=LF" "
+
[ANNOUNCE] Git-backup - Backup set of Git repositories & just files; efficiently
https://lab.nexedi.com/kirr/git-backup.git This program backups files and set of bare Git repositories into one Git repository. Files are copied to blobs and then added to tree under certain place, and for Git repositories, all reachable objects are pulled in with maintaining index which remembers reference -> sha1 for all pulled repositories. This allows to leverage Git's good data deduplication ability, especially for cases when there are many hosted repositories which are forks of each other, and for backup to have history and be otherwise managed as a usual Git repository. In particular it is possible to use standard git pull/push to synchronize backups in several places. Backup workflow is: 1. create backup repository:: $ mkdir backup $ cd backup $ git init # both bare and non-bare possible 2. pull files and Git repositories into backup repository:: $ git-backup pull dir1:prefix1 dir2:prefix2 ... This will pull bare Git repositories & just files from `dir1` into backup under `prefix1`, from `dir2` into backup prefix `prefix2`, etc... 3. restore files and Git repositories from backup:: $ git-backup restore prefix1:dir1 Restore Git repositories & just files from backup `prefix1` into `dir1`, from backup `prefix2` into `dir2`, etc... Backup state to restore is taken from which is sha1 or ref pointing to backup repository state. 4. backup repository itself can be managed with Git. In particular it can be synchronized between several places with standard git pull/push, be repacked, etc:: $ git push ... $ git pull ... Technical overview of how it works -- After objects from backuped Git repositories are pulled in, we create new commit which references tree with changed backup index and files, and also has all head objects from pulled-in repositories in its parents(*). This way backup has history and all pulled objects become reachable from single head commit in backup repository. In particular that means that the whole state of backup can be described with only single sha1, and that backup repository itself could be synchronized via standard git pull/push, be repacked, etc. Restoration process is the opposite - from a particular backup state, files are extracted at a proper place, and for Git repositories a pack with all objects reachable from that repository heads is prepared and extracted from backup repository object database. Data for all backuped files and repositories can be accessed if one has access to backup repository, so either they all should be in the same security domain, or extra care has to be taken to protect access to backup repository. File permissions are not managed with strict details due to inherent nature of Git. This aspect can be improved with e.g. etckeeper-like (http://etckeeper.branchable.com/) approach if needed. NOTE the idea of pulling all refs together is similar to git-namespaces http://git-scm.com/docs/gitnamespaces (*) Tag objects are handled specially - because in a lot of places Git insists and assumes commit parents can only be commit objects. We encode tag objects in specially-crafted commit object on pull, and decode back on backup restore. We do likewise if a ref points to tree or blob, which is valid in Git. -- 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] optionally disable gitattributes
On 27.01.16 12:59, Junio C Hamano wrote: > Clemens Buchacher writes: > >> If committed files are not normalized, adding gitattributes has the >> side effect that such files are shown as modified, even though they >> were not actually modified by the user, and the work tree matches >> the committed file. This is because with gitattributes, the file is >> modified on the fly when git reads it from disk, before it compares >> with the index contents. >> >> This is desirable in most situations, because it makes the user >> aware that files should be normalized. However, it can become an >> issue for automation. Since Git considers the work tree to be >> dirty, some operations such as git rebase or git cherry-pick refuse >> to operate. Those commands offer no flag to force overwrite work >> tree changes. The only options are to commit the changes, or to >> remove gitattributes, but that changes the repository state, which >> may be undesirable in a scripted context. It feels like a workaround for something that could be fixable, or is already ongoing. Before going into more details, could you tell us which attributes you are typically using (when having this problems) ? Is it * text=auto or *.sh text or something else? >> >> Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if >> set makes Git ignore any gitattributes. >> >> Signed-off-by: Clemens Buchacher >> --- > > Is the problem you are trying to solve related to the issue we > discussed recently in a nearby thread? It seems that I missed the thread ? > > That is, even after "reset --hard", if the result of converting the > contents in the index to the working tree representation and then > converting that result back to the normalized representation does > not match what is in the index, Git would sometimes say that the > working tree contents differ from the index? > > I think the change in this patch has some uses, and I think the > issue we discussed recently in a nearby thread indeed is a problem, > but I do not think there is an impedance mismatch beween the two, so > I'd like to first make sure you are trying to solve the problem I > think you are trying to solve. -- 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 for windows
Additional note - when I use the command line git push doesn't display any errors but no updates on github... git status says : On branch master Your branch is ahead of 'origin/master' by 3 commits. On 1/27/2016 2:51 PM, Andrey Chernyshov wrote: On 1/27/2016 2:35 PM, Andrey Chernyshov wrote: On 1/27/2016 2:32 PM, Andrey Chernyshov wrote: Hi I'm using PHP storm with git for windows. Once I do a push to the github I get the following error Problem signature: Problem Event Name:APPCRASH Application Name:git-remote-https.exe Application Version:2.7.0.0 Application Timestamp:35316130 Fault Module Name:libidn-11.dll Fault Module Version:0.0.0.0 Fault Module Timestamp:00170158 Exception Code:c005 Exception Offset:46bc OS Version:6.3.9600.2.0.0.256.4 Locale ID:1033 Additional Information 1:a547 Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4 Additional Information 3:ac01 Additional Information 4:ac010ce737711604ec050156caebd625 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=280262 If the online privacy statement is not available, please read our privacy statement offline: C:\windows\system32\en-US\erofflps.txt If I try to push with Git GUI, it's the same, so not a PHPStorm issue... -- Thanks, Andrey. -- Thanks, Andrey. -- Thanks, Andrey. -- 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] git.c: fix help.autocorrect after 57ea712 breaks it
Duy Nguyen writes: > On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> I spoke too soon, I am afraid. >>> ... >>> I wonder if this would be better done as a multi-part series that >>> goes like this: >>> ... >> >> So here is the first of the three-patch series to replace it. > > This is much better (the whole series, not just the first patch). We > probably should add a test about help.autocorrect though, maybe in the > first patch, because it's not tested at all in the test suite. Patches welcome. 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] optionally disable gitattributes
Clemens Buchacher writes: > If committed files are not normalized, adding gitattributes has the > side effect that such files are shown as modified, even though they > were not actually modified by the user, and the work tree matches > the committed file. This is because with gitattributes, the file is > modified on the fly when git reads it from disk, before it compares > with the index contents. > > This is desirable in most situations, because it makes the user > aware that files should be normalized. However, it can become an > issue for automation. Since Git considers the work tree to be > dirty, some operations such as git rebase or git cherry-pick refuse > to operate. Those commands offer no flag to force overwrite work > tree changes. The only options are to commit the changes, or to > remove gitattributes, but that changes the repository state, which > may be undesirable in a scripted context. > > Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if > set makes Git ignore any gitattributes. > > Signed-off-by: Clemens Buchacher > --- Is the problem you are trying to solve related to the issue we discussed recently in a nearby thread? That is, even after "reset --hard", if the result of converting the contents in the index to the working tree representation and then converting that result back to the normalized representation does not match what is in the index, Git would sometimes say that the working tree contents differ from the index? I think the change in this patch has some uses, and I think the issue we discussed recently in a nearby thread indeed is a problem, but I do not think there is an impedance mismatch beween the two, so I'd like to first make sure you are trying to solve the problem I think you are trying to solve. -- 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 for windows
On 1/27/2016 2:35 PM, Andrey Chernyshov wrote: On 1/27/2016 2:32 PM, Andrey Chernyshov wrote: Hi I'm using PHP storm with git for windows. Once I do a push to the github I get the following error Problem signature: Problem Event Name:APPCRASH Application Name:git-remote-https.exe Application Version:2.7.0.0 Application Timestamp:35316130 Fault Module Name:libidn-11.dll Fault Module Version:0.0.0.0 Fault Module Timestamp:00170158 Exception Code:c005 Exception Offset:46bc OS Version:6.3.9600.2.0.0.256.4 Locale ID:1033 Additional Information 1:a547 Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4 Additional Information 3:ac01 Additional Information 4:ac010ce737711604ec050156caebd625 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=280262 If the online privacy statement is not available, please read our privacy statement offline: C:\windows\system32\en-US\erofflps.txt If I try to push with Git GUI, it's the same, so not a PHPStorm issue... -- Thanks, Andrey. -- Thanks, Andrey. -- Thanks, Andrey. -- 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 (Jan 2016, #05; Tue, 26)
Hi Junio, On Tue, 26 Jan 2016, Junio C Hamano wrote: > * js/mingw-tests (2016-01-26) 20 commits > - mingw: skip a test in t9130 that cannot pass on Windows > - mingw: do not bother to test funny file names > - mingw: handle the missing POSIXPERM prereq in t9124 > - mingw: avoid illegal filename in t9118 > - mingw: mark t9100's test cases with appropriate prereqs > - Avoid absolute path in t0008 > - mingw: work around pwd issues in the tests > - mingw: fix t9700's assumption about directory separators > - mingw: skip test in t1508 that fails due to path conversion > - tests: turn off git-daemon tests if FIFOs are not available > - mingw: disable mkfifo-based tests > - mingw: accomodate t0060-path-utils for MSYS2 > - mingw: fix t5601-clone.sh > - mingw: let lstat() fail with errno == ENOTDIR when appropriate > - mingw: try to delete target directory before renaming > - mingw: prepare the TMPDIR environment variable for shell scripts > - mingw: factor out Windows specific environment setup > - Git.pm: stop assuming that absolute paths start with a slash > - mingw: do not trust MSYS2's MinGW gettext.sh > - mingw: let's use gettext with MSYS2 > (this branch uses js/msys2.) > > Updates test scripts to remove assumptions that are not portable > between Git for POSIX and Git for Windows, or to skip ones with > expectations that are not satisfiable on Git for Windows. > > Looks mostly done, but I had to tweak a few things, so > Waiting for re-test. Will re-submit with additional tweaks. > * js/xmerge-maker-eol (2016-01-26) 2 commits > - merge-file: ensure that conflict sections match eol style > - merge-file: let conflict markers match end-of-line style of the context > > The low-level merge machinery has been taught to use CRLF line > termination when inserting conflict markers to merged contents that > are themselves CRLF line-terminated. > > Will merge to 'next'. There is one more tweak I introduced, and will resubmit: the test case did not test the intended 3 out of the 4 conflict markers. Ciao, Dscho -- 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
Dear Sir or Madam! - please help our site - пожалуйста, помогите нашему сайту - будь ласка, допоможіть нашому сайту http://petition.kiev.ua/
Dear Sir or Madam! please at the top of any page of site click once on the advertising banner, so that we could pay for hosting our site, Thank you ad...@petition.kiev.ua http://petition.kiev.ua/ добрий день, просимо на будь-якій сторінці вгорі один раз натиснути на рекламний банер, щоб ми змогли оплатити хостинг нашого сайту, Дякуємо добрый день, просим на любой странице вверху один раз нажать на рекламный баннер, чтобы мы смогли оплатить хостинг нашего сайта, спасибо Sorry if this letter has caused you inconvenience. Your address is taken from public sources. To unsubscribe, please send us a a message to our email address. ad...@petition.kiev.ua http://petition.kiev.ua/ -- 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] optionally disable gitattributes
If committed files are not normalized, adding gitattributes has the
side effect that such files are shown as modified, even though they
were not actually modified by the user, and the work tree matches
the committed file. This is because with gitattributes, the file is
modified on the fly when git reads it from disk, before it compares
with the index contents.
This is desirable in most situations, because it makes the user
aware that files should be normalized. However, it can become an
issue for automation. Since Git considers the work tree to be
dirty, some operations such as git rebase or git cherry-pick refuse
to operate. Those commands offer no flag to force overwrite work
tree changes. The only options are to commit the changes, or to
remove gitattributes, but that changes the repository state, which
may be undesirable in a scripted context.
Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if
set makes Git ignore any gitattributes.
Signed-off-by: Clemens Buchacher
---
Documentation/git.txt | 4
Documentation/gitattributes.txt | 6 ++
attr.c | 3 +++
t/t0003-attributes.sh | 43 +
4 files changed, 56 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index bff6302..00f4e3b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -1132,6 +1132,10 @@ of clones and fetches.
- any external helpers are named by their protocol (e.g., use
`hg` to allow the `git-remote-hg` helper)
+'GIT_ATTRIBUTES_DISABLED'::
+ If set, attributes are disabled for all paths. See
+ linkgit:gitattributes[1] for more details on attributes.
+
Discussion[[Discussion]]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..f6a2b1d 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -996,6 +996,12 @@ frotz unspecified
+ENVIRONMENT
+---
+
+GIT_ATTRIBUTES_DISABLED::
+ If set, attributes are disabled for all paths.
+
SEE ALSO
linkgit:git-check-attr[1].
diff --git a/attr.c b/attr.c
index 086c08d..0fa2f1a 100644
--- a/attr.c
+++ b/attr.c
@@ -547,6 +547,9 @@ static void prepare_attr_stack(const char *path, int dirlen)
int len;
const char *cp;
+ if (getenv("GIT_ATTRIBUTES_DISABLED"))
+ return;
+
/*
* At the bottom of the attribute stack is the built-in
* set of attribute definitions, followed by the contents
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f0fbb42..26e6766 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -13,6 +13,14 @@ attr_check () {
test_line_count = 0 err
}
+attr_check_disabled () {
+ (
+ GIT_ATTRIBUTES_DISABLED=t
+ export GIT_ATTRIBUTES_DISABLED
+ attr_check "$@" unspecified
+ )
+}
+
test_expect_success 'setup' '
mkdir -p a/b/d a/c b &&
(
@@ -84,6 +92,41 @@ test_expect_success 'attribute test' '
attr_check a/b/d/yes unspecified
'
+test_expect_success 'gitattributes disabled' '
+ attr_check_disabled f &&
+ attr_check_disabled a/f &&
+ attr_check_disabled a/c/f &&
+ attr_check_disabled a/g &&
+ attr_check_disabled a/b/g &&
+ attr_check_disabled b/g &&
+ attr_check_disabled a/b/h &&
+ attr_check_disabled a/b/d/g &&
+ attr_check_disabled onoff &&
+ attr_check_disabled offon &&
+ attr_check_disabled no &&
+ attr_check_disabled a/b/d/no &&
+ attr_check_disabled a/b/d/yes
+'
+
+test_expect_success 'no changes if gitattributes disabled' '
+ mkdir clean &&
+ git init clean &&
+ (
+ cd clean &&
+ printf "foo\r\n" >dos.txt &&
+ git add dos.txt &&
+ test_tick &&
+ git commit -q -m dos.txt &&
+ echo "*.txt text eol=lf" >.gitattributes &&
+ git add .gitattributes &&
+ test_tick &&
+ git commit -q -m .gitattributes &&
+ rm -f .git/index &&
+ git reset &&
+ GIT_ATTRIBUTES_DISABLED=t git diff --exit-code
+ )
+'
+
test_expect_success 'attribute matching is case sensitive when
core.ignorecase=0' '
test_must_fail attr_check F f "-c core.ignorecase=0" &&
--
2.7.0
--
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] convert: legitimately disable clean/smudge filter with an empty override
On 24 Jan 2016, at 22:45, Jeff King wrote:
> On Sun, Jan 24, 2016 at 01:22:50PM +0100, larsxschnei...@gmail.com wrote:
>
>> From: Lars Schneider
>>
>> A clean/smudge filter can be disabled if set to an empty string. However,
>> Git will try to run the empty string as command which results in a error
>> message per processed file.
>>
>> Teach Git to consider an empty clean/smudge filter as legitimately disabled
>> and do not print an error message.
>
> That makes sense to me, as I do not think the empty filter name can
> possibly do anything useful. You omitted the real motivation here, but I
> know what it is from past discussions: you want to be able to
> temporarily disable a filter with "git -c filter.foo.clean= ...". Which
> I think makes it more immediately obvious that this is a useful thing to
> have, and not just user error.
>
>> diff --git a/convert.c b/convert.c
>> index 814e814..58af965 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src,
>> size_t len,
>> struct conv_attrs ca;
>>
>> convert_attrs(&ca, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
>> filter = ca.drv->clean;
>> required = ca.drv->required;
>> }
>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char
>> *path, const char *src,
>> struct conv_attrs ca;
>>
>> convert_attrs(&ca, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
>> filter = ca.drv->smudge;
>> required = ca.drv->required;
>> }
>
> This catches two calls, but I think there are others. What about
> would_convert_to_git_filter_fd and convert_to_git_filter_fd?
>
> Would it make more sense for apply_filter() to treat the empty string as
> a noop, just as it does for NULL?
Yes :-)
Thanks,
Lars
>
> I.e.:
>
>
> diff --git a/convert.c b/convert.c
> index 814e814..02d5f1e 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -395,7 +395,7 @@ static int apply_filter(const char *path, const char
> *src, size_t len, int fd,
> struct async async;
> struct filter_params params;
>
> - if (!cmd)
> + if (!cmd || !*cmd)
> return 0;
>
> if (!dst)
>
> which I think would cover all callers?
>
> -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] convert: legitimately disable clean/smudge filter with an empty override
On 24 Jan 2016, at 22:35, Eric Sunshine wrote:
> On Sun, Jan 24, 2016 at 10:06 AM, Torsten Bögershausen wrote:
>> On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider
>>> diff --git a/convert.c b/convert.c
>>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src,
>>> size_t len,
>>> struct conv_attrs ca;
>>>
>>> convert_attrs(&ca, path);
>>> - if (ca.drv) {
>>> + if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
>
> More idiomatic:
>
>if (ca.drv && ca.drv->clean && *ca.drv->clean) {
Agreed! Although I will go with Jeff's suggestion to implement that
logic in apply_filter.
>
>>> filter = ca.drv->clean;
>>> required = ca.drv->required;
>>> }
>>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char
>>> *path, const char *src,
>>> struct conv_attrs ca;
>>>
>>> convert_attrs(&ca, path);
>>> - if (ca.drv) {
>>> + if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
>
> Ditto.
>
>>> filter = ca.drv->smudge;
>>> required = ca.drv->required;
>>> }
>>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>>> @@ -252,4 +252,18 @@ test_expect_success "filter: smudge empty file" '
>>> +test_expect_success 'disable filter with empty override' '
>>> + git config filter.disable.smudge false &&
>>> + git config filter.disable.clean false &&
>
> test_config perhaps?
I was wondering about that, too. Especially because I could also use
test_config_global.
Why does no test in t0021 use these functions? Should that be fixed?
>
>>> + echo "*.disable filter=disable" >.gitattributes &&
>>> +
>>> + echo test >test.disable &&
>>> + git -c filter.disable.clean= add test.disable 2>err &&
>>> + ! test -s err &&
>> How about
>> test_cmp /dev/null err
>> to make debugging easier ?
>
> Even better:
>
>test_must_be_empty err &&
True! I will use that.
Thanks,
Lars
--
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] convert: legitimately disable clean/smudge filter with an empty override
On 24 Jan 2016, at 16:06, Torsten Bögershausen wrote:
> On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
> Some minor nits inside:
>>
>> A clean/smudge filter can be disabled if set to an empty string.
> "set to an empty string" refers to "git config" (in opposite to the
> filter as such, which is specified in .gitattributes.
> Does it make sense to write
> "git config filter.XXX.smudge ''" or so ?
I am not sure I get what you want here. Would this work for you?
The clean/smudge filter commands (filter.XYZ.smudge and filter.XYZ.clean)
can be disabled if set to an empty string. However, Git will still consider the
empty string as command which results in a error message per processed
file.
>
>> However,
>> Git will try to run the empty string as command which results in a error
>> message per processed file.
>>
>> Teach Git to consider an empty clean/smudge filter as legitimately disabled
>> and do not print an error message.
>>
>> Signed-off-by: Lars Schneider
>> ---
>> convert.c | 4 ++--
>> t/t0021-conversion.sh | 14 ++
>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/convert.c b/convert.c
>> index 814e814..58af965 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src,
>> size_t len,
>> struct conv_attrs ca;
>>
>> convert_attrs(&ca, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
>> filter = ca.drv->clean;
>> required = ca.drv->required;
>> }
>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char
>> *path, const char *src,
>> struct conv_attrs ca;
>>
>> convert_attrs(&ca, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
>> filter = ca.drv->smudge;
>> required = ca.drv->required;
>> }
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 718efa0..56e385c 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -252,4 +252,18 @@ test_expect_success "filter: smudge empty file" '
>> test_cmp expected filtered-empty-in-repo
>> '
>>
>> +test_expect_success 'disable filter with empty override' '
>> +git config filter.disable.smudge false &&
>> +git config filter.disable.clean false &&
>> +
>> +echo "*.disable filter=disable" >.gitattributes &&
>> +
>> +echo test >test.disable &&
>> +git -c filter.disable.clean= add test.disable 2>err &&
>> +! test -s err &&
> How about
> test_cmp /dev/null err
> to make debugging easier ?
Right. Although I would probably go with Eric's suggestion and use
"test_must_be_empty".
That being said, I copied "! test -s" from the "filter large file" test in this
file (added with 0b6806b).
How does the list handle these cases? Should I add another commit to replace "!
test -s" there,
too?
Thanks,
Lars--
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/19] mingw: handle the missing POSIXPERM prereq in t9124
Hi Junio, On Tue, 26 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Windows, the permission system works completely differently than > > expected by some of the tests. So let's make sure that we do not test > > POSIX functionality on Windows. > > > > This lets t9124-git-svn-dcommit-auto-props.sh pass in Git for Windows' > > SDK. > > > > Signed-off-by: Johannes Schindelin > > --- > > t/t9124-git-svn-dcommit-auto-props.sh | 16 ++-- > > 1 file changed, 10 insertions(+), 6 deletions(-) > > > > diff --git a/t/t9124-git-svn-dcommit-auto-props.sh > > b/t/t9124-git-svn-dcommit-auto-props.sh > > index aa841e1..2be0805 100755 > > --- a/t/t9124-git-svn-dcommit-auto-props.sh > > +++ b/t/t9124-git-svn-dcommit-auto-props.sh > > @@ -34,8 +34,7 @@ test_expect_success 'enable auto-props config' ' > > ' > > > > test_expect_success 'add files matching auto-props' ' > > - echo "#!$SHELL_PATH" >exec1.sh && > > - chmod +x exec1.sh && > > + printf "" | write_script exec1.sh && > > That looks like a useless use of printf. Why not > > write_script exec1.sh > echo "hello" >hello.txt && > > echo bar >bar && > > git add exec1.sh hello.txt bar && > > @@ -48,8 +47,7 @@ test_expect_success 'disable auto-props config' ' > > ' > > > > test_expect_success 'add files matching disabled auto-props' ' > > - echo "#$SHELL_PATH" >exec2.sh && > > - chmod +x exec2.sh && > > + printf "" | write_script exec2.sh && > > echo "world" >world.txt && > > echo zot >zot && > > git add exec2.sh world.txt zot && > > @@ -65,7 +63,10 @@ test_expect_success 'check resulting svn repository' ' > > cd svnrepo && > > > > # Check properties from first commit. > > - test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" && > > + if test_have_prereq POSIXPERM > > + then > > + test -z "$(svn_cmd propget svn:executable exec1.sh)" > > Why this change? > > test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" && > > means "propget command gives a literal string that consists of a > single asterisk". Oh wow... I blame it on lack of sleep. Would you believe that I totally overlooked the asterisk, in both cases? Wow. Sorry for the mess, cleaned it up locally and will resubmit as soon as the tests passed on both Windows & Linux, and as soon as I figure out how to change my charset to something else than unknown. My apologies, Dscho P.S.: Would you believe that the reason the tests passed on Linux was that I forgot to install Subversion? ;-) -- 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] git.c: fix help.autocorrect after 57ea712 breaks it
On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I spoke too soon, I am afraid. >> ... >> I wonder if this would be better done as a multi-part series that >> goes like this: >> ... > > So here is the first of the three-patch series to replace it. This is much better (the whole series, not just the first patch). We probably should add a test about help.autocorrect though, maybe in the first patch, because it's not tested at all in the test suite. -- 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
Re: [RFC] tag-ref and tag object binding
Jeff King venit, vidit, dixit 27.01.2016 09:09:
> On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
>
>>> Yeah, definitely. My thinking was that `verify-tag` could learn a series
>>> of optional consistency checks, enabled by command line options, and
>>> verifying programs (or humans) could turn them on to avoid having to
>>> replicate them manually. So something like:
>>>
>>> git verify-tag \
>>> --verify-tagger-matches-key \
>>> --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0
>>> v2.0.0
>>>
>>> or to implement more specific policy, maybe an option to check for a
>>> _specific_ tagger, either by email (as provided by gpg) or even key-id.
>>>
>>> Those are all things that are not _too_ hard to do if you're willing to
>>> parse gpg or git output, but we could make life easier for our callers.
>>> And hopefully by asking for specific, concrete checks, it doesn't
>>> introduce a false sense of security. I.e., we're not making a foolproof
>>> tool; we're making building blocks that one could use for a more
>>> foolproof tool.
>>
>> OK, let's make a tool that helps fooling as well as proofing :)
>>
>> I'll look into the tag header check. Maybe "--check-tagname"? "check"
>> seems to imply less than "verify".
>
> Yeah, I think that is fine (I actually wrote --check originally; I'm not
> quite sure why I decided to change it).
>
>> As for the gpg related stuff: We provide the full diagnostic output from
>> gpg on request. But I think a mismatch between the signing key's uid and
>> the taggers' name/email is more common than not,
>
> Is it? I'd think if you are using that name with a signed tag, you would
> bother to issue (and get people to sign) the matching uid. Certainly it
> is the case for git and linux signatures, but I admit that it a pretty
> small sampling size.
>
> The bigger issue is that gpg seems to give us only _one_ uid, when there
> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
> sub-key that has several uids associated with it. The one that "git
> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good,
> but I think that's just because it happens to be the first uid. Or maybe
> there is some gpg arcana going on that I don't know about.
You do not sign with a uid, you sign with a (sub)key, and the tag is
signed with Junio's primary key. His subkey is encryption only.
uids do not identify keys, you can add and delete them at will without
changing the primary key id. To help recognize ("identify") a key, gpg
displays the uid with the most recent self-signature, which is usually
the most "recent uid".
You do sign a uid.
So, if you want to be sure that a tag is signed "with a specific uid" by
relying on signatures from a set of signers, you would really need to
check that the key that signed the tag has a signature on the correct
uid. Having a signed key with the right uid in it doesn't mean much
unlss the right uid is signed.
E.g., I have a key with many signatures, and I could have Junio's uid on
it in a minute without invalidating any of those signatures.
>> and on the other hand a
>> signature by a key identified by its uid is meaningless unless you keep
>> your keyring tidy... We could punt on that and let users identify the
>> key by any means that gpg allows, of course, and check that the
>> signature comes from whatever "gpg --list-key " gives as
>> long as it's unique.
>
> Right, I think it's an open question whether people actually participate
> in the web of trust. I don't have a good signature path to Junio's key,
> but I happen to know what it is based on past interaction.
>
> But then, I also do not really verify tags. Why would I? I routinely
> fetch and run "make" on the result, and there is no cryptographic
> protection there at all. Verifying tag signatures after a release seems
> all but pointless. :)
No signature protects us from our own dogfood :)
> I think for any of this to be useful, it has to be part of some tool
> that is very opinionated on policy. E.g., imagine a post-fetch hook that
> validated that each incoming commit was signed, and that the signer was
> part of a whitelisted group of keys that you "somehow" got hold of
> out-of-band for your project. That is not that useful for an open-source
> project, but I could see the appeal for a proprietary development
> environment.
That one is easy already by setting "GNUPGHOME" to a special dir with a
small keyring and tight trust settings (or having a dedicated account on
the incoming side in the first place).
Michael
--
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] t0027: Add tests for get_stream_filter()
- This needs to go on top of tb/ls-files-eol With missing "separate commit", I am having a hard time to decide if this is something I should pick up at this moment, or I should wait until that separate commit materializes. What is your intention? I send a serious including this patch the next days. If there are more review comments, they are welcome. -- 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 12/19] mingw: skip test in t1508 that fails due to path conversion
Hi Junio, On Tue, 26 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > @@ -35,7 +35,10 @@ test_expect_success 'setup' ' > > git checkout -b upstream-branch && > > test_commit upstream-one && > > test_commit upstream-two && > > - git checkout -b @/at-test && > > + if ! test_have_prereq MINGW > > + then > > + git checkout -b @/at-slash > > I presume that this is meant to be "@/at-test", not "@/at-slash". Oh my. That's what you get for redoing patches from scratch. Sorry about that! Ciao, Dscho -- 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 (Jan 2016, #04; Wed, 20)
On 26 Jan 2016, at 23:58, Junio C Hamano wrote: > Lars Schneider writes: > >> Hi Junio, >> >> Did you miss the topic "submodule: extend die message on failed >> checkout with depth argument" or do you not agree with it >> ($gmane/282779)? Stefan Beller reviewed the commits ($gmane/283666 >> and $gmane/283851). > > No, these three are still in my inbox. > > Quite honestly, "test to demonstrate breakage" alone is not all that > interesting to me unless I get a firm impression that somebody is > (or will soon be) working on fixing the breakage--which would make > it worth keeping track of it in my tree, to allow the eventual fix > to be more easily verified and protected from getting broken again. > Also "these look good to me" without much explanation is not much of > a review, and such a comment on a "demonstrate breakage" did not add > to the sense of urgency to the issue, either. > > That was why it has been sitting near the bottom of the pile. OK, I get your point. I got the impression that Stefan is on to a fix ($gmane/281260). Looks like he is not and I need to learn more about Git to tackle fixes of this scope. Would it be an option for you to just drop patch 1/3 from this series and look at the remaining ones? 2/3 fixes an "&& chain issue" ($gmane/282776) and 3/3 prints a explanatory user warning instead of an incomprehensible error ($gmane/282777). Thanks, Lars-- 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 00/19] Let Git's tests pass on Windows
Hi Junio, On Tue, 26 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This is a big milestone. With these modifications, Git's source code > > does not only build without warnings in Git for Windows' SDK, but > > passes the entire regression test suite. > > Thanks. > > Without a few fixups, the result of applying these patches made > tests fail for me (so presumably for everybody !MINGW) Drats! I got lazy and did not re-test everything on Linux after a while (it really slwed me down and for a good while the tests all succeeded, so those regressions were incurred from working on this very patch series...) > which I think I fixed all, but I may have broken things on MINGW while > doing so. Please re-fetch from my tree when I pushed the integration > result out with this merged somewhere on the 'pu' branch, retest, and if > I broke something please re-fix them ;-) I made a couple of other adjustments anyway, so expect a new iteration shortly. This time cross-checked on Linux. Ciao, Dscho -- 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 19/19] mingw: do not bother to test funny file names
Hi Eric, On Tue, 26 Jan 2016, Eric Sunshine wrote: > On Tue, Jan 26, 2016 at 9:35 AM, Johannes Schindelin > wrote: > > MSYS2 actually allows to create files or directories whose names contain > > tabs, newlines or colors, even if plain Win32 API cannot access them. > > As we are using an MSYS2 bash to run the tests, such files or > > directories are created successfully, but Git itself has no chance to > > work with them because it is a regular Windows program, hence limited by > > the Win32 API. > > [...] > > Signed-off-by: Johannes Schindelin > > --- > > diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh > > @@ -14,7 +14,8 @@ test_expect_success \ > > -if touch -- 'tab embedded' 'newline > > + > > Is this new blank line intentional? Absolutely not! ;-) Fixed. > > +if ! test_have_prereq MINGW && touch -- 'tab embedded' 'newline > > [...] > > +test_have_prereq !MINGW && > > Where negation is concerned, is there a non-obvious reason that this > patch sometimes says: > > ! test_have_prereq MINGW > > and sometimes: > > test_have_prereq !MINGW > > ? Is one form preferred over the other? Hysterical raisins. I changed all of them to the latter form, as suggested by Junio. Ciao, Dscho -- 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] tag-ref and tag object binding
On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote: > > Yeah, definitely. My thinking was that `verify-tag` could learn a series > > of optional consistency checks, enabled by command line options, and > > verifying programs (or humans) could turn them on to avoid having to > > replicate them manually. So something like: > > > > git verify-tag \ > > --verify-tagger-matches-key \ > > --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0 > > v2.0.0 > > > > or to implement more specific policy, maybe an option to check for a > > _specific_ tagger, either by email (as provided by gpg) or even key-id. > > > > Those are all things that are not _too_ hard to do if you're willing to > > parse gpg or git output, but we could make life easier for our callers. > > And hopefully by asking for specific, concrete checks, it doesn't > > introduce a false sense of security. I.e., we're not making a foolproof > > tool; we're making building blocks that one could use for a more > > foolproof tool. > > OK, let's make a tool that helps fooling as well as proofing :) > > I'll look into the tag header check. Maybe "--check-tagname"? "check" > seems to imply less than "verify". Yeah, I think that is fine (I actually wrote --check originally; I'm not quite sure why I decided to change it). > As for the gpg related stuff: We provide the full diagnostic output from > gpg on request. But I think a mismatch between the signing key's uid and > the taggers' name/email is more common than not, Is it? I'd think if you are using that name with a signed tag, you would bother to issue (and get people to sign) the matching uid. Certainly it is the case for git and linux signatures, but I admit that it a pretty small sampling size. The bigger issue is that gpg seems to give us only _one_ uid, when there may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a sub-key that has several uids associated with it. The one that "git verify-tag --raw" shows from gpg is gits...@pobox.com, which is good, but I think that's just because it happens to be the first uid. Or maybe there is some gpg arcana going on that I don't know about. > and on the other hand a > signature by a key identified by its uid is meaningless unless you keep > your keyring tidy... We could punt on that and let users identify the > key by any means that gpg allows, of course, and check that the > signature comes from whatever "gpg --list-key " gives as > long as it's unique. Right, I think it's an open question whether people actually participate in the web of trust. I don't have a good signature path to Junio's key, but I happen to know what it is based on past interaction. But then, I also do not really verify tags. Why would I? I routinely fetch and run "make" on the result, and there is no cryptographic protection there at all. Verifying tag signatures after a release seems all but pointless. :) I think for any of this to be useful, it has to be part of some tool that is very opinionated on policy. E.g., imagine a post-fetch hook that validated that each incoming commit was signed, and that the signer was part of a whitelisted group of keys that you "somehow" got hold of out-of-band for your project. That is not that useful for an open-source project, but I could see the appeal for a proprietary development environment. -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
