Re: Bug: .gitconfig folder
On Wed, May 27, 2015 at 3:18 PM, Jeff King p...@peff.net wrote: On Wed, May 27, 2015 at 01:30:29PM -0700, Junio C Hamano wrote: Jorge grif...@gmx.es writes: If you have a folder named ~/.gitconfig instead of a file with that name, when you try to run some global config editing command it will fail with a wrong error message: fatal: Out of memory? mmap failed: No such device That indeed is a funny error message. How about this patch? -- 8 -- We show that message with die_errno(), but the OS is ought to know why mmap(2) failed much better than we do. There is no reason for us to say Out of memory? here. Note that mmap(2) fails with ENODEV when the file you specify is not something that can be mmap'ed, so you still need to know that No such device can include cases like having a directory when a regular file is expected, but we can expect that a user who creates a directory to a location where a regular file is expected to be would know what s/he is doing, hopefully ;-) sha1_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index ccc6dac..551a9e9 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -720,7 +720,7 @@ void *xmmap(void *start, size_t length, release_pack_memory(length); ret = mmap(start, length, prot, flags, fd, offset); if (ret == MAP_FAILED) - die_errno(Out of memory? mmap failed); + die_errno(mmap failed); } This is definitely an improvement, but the real failing of that error message is that it does not tell us that ~/.gitconfig is the culprit. I don't think we can do much from xmmap, though; it does not have the filename. It would be nice if we got EISDIR from open() in the first place, but I don't think we can implement that efficiently (if we added an xopen that checked that, it would have to stat() every file we opened). What is our thinking for after-fact recovery attempts? Like we try the mmap first, if that fails we just use open to get the contents of the file. And when open fails, we can still print a nice error message? -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 -- 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] glossary: add remote and submodule
Stefan Beller sbel...@google.com writes: Noticed-by: Philip Oakley philipoak...@iee.org Signed-off-by: Stefan Beller sbel...@google.com --- Documentation/glossary-content.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index bf383c2..e303135 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -469,6 +469,11 @@ The most notable example is `HEAD`. def_push,push to describe the mapping between remote def_ref,ref and local ref. +[[def_remote]]remote repository:: + A def_repository,repository which is used to track the same + project but resides somewhere else. To communicate with remotes, + see def_fetch,fetch or def_push,push. + OK. @@ -515,6 +520,11 @@ The most notable example is `HEAD`. is created by giving the `--depth` option to linkgit:git-clone[1], and its history can be later deepened with linkgit:git-fetch[1]. +[[def_submodule]]submodule:: + A def_repository,repository inside another repository. The two + repositories have different history, though the outer repository + knows the commit of the inner repository. I'd stress that they are not just different histories (as the 'master' and the 'maint' branches of my project has different histories) but they are separate projects. Perhaps like this? A repository that holds the history of a separate project inside another repository (the latter of which is called superproject). The containing superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules. It is not like that it is strange or unintuitive that the superproject knows about some commits in its submodule. X, though Y however makes it sound as if Y is true despite X. I do not think there is any despite here. -- 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/4] showing existing ws breakage
On Tue, May 26, 2015 at 11:30:28PM -0700, Junio C Hamano wrote:
The fourth one in v2 used a new option --[no-]ws-check-deleted,
but in this round a new option --ws-error-highlight=kinds is
defined instead. With that, you can say
diff --ws-error-highlight=new,old
to say I want to see whitespace errors on new and old lines, and
diff --ws-error-highlight=new,old,context
diff --ws-error-highlight=all
can be used to also see whitespace errors on context lines. Being
able to see whitespace errors on context lines, i.e. the ones that
were there in the original and you left intact, would help you see
how prevalent whitespace errors are in the original and hopefully
would make it easier for you to decide if a separate preliminary
clean-up to only fix these whitespace errors is warranted.
That makes sense. Neat feature.
In color.diff.*, these are called new, old, and plain. I am of the
opinion that context is a far better name than plain, but perhaps we
should support both for consistency.
Here's a patch for the color.diff side, if we want to go that route.
-- 8 --
Subject: diff: accept color.diff.context as a synonym for plain
The term plain is a bit ambiguous; let's allow the more
specific context, but keep plain around for
compatibility.
Signed-off-by: Jeff King p...@peff.net
---
I didn't bother mentioning the historical plain in the documentation.
I don't know if it's better to (for people who find it in the wild and
wonder what it means) or if it simply clutters the description. It may
also be that people don't find plain as meaningless as I do, and would
rather leave it as the primary in the documentation (and accepting
context is just a nicety).
I also resisted the urge to refactor every internal variable and enum
mentioning plain into context. I guess whether that is a good idea
depends on how strongly you agree that plain is a bad name. :)
Documentation/config.txt | 2 +-
diff.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f76e8c..34ef9fe 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -914,7 +914,7 @@ command line with the `--color[=when]` option.
color.diff.slot::
Use customized color for diff colorization. `slot` specifies
which part of the patch to use the specified color, and is one
- of `plain` (context text), `meta` (metainformation), `frag`
+ of `context` (context text), `meta` (metainformation), `frag`
(hunk header), 'func' (function in hunk header), `old` (removed lines),
`new` (added lines), `commit` (commit headers), or `whitespace`
(highlighting whitespace errors).
diff --git a/diff.c b/diff.c
index 7500c55..27bd371 100644
--- a/diff.c
+++ b/diff.c
@@ -54,7 +54,7 @@ static char diff_colors[][COLOR_MAXLEN] = {
static int parse_diff_color_slot(const char *var)
{
- if (!strcasecmp(var, plain))
+ if (!strcasecmp(var, context) || !strcasecmp(var, plain))
return DIFF_PLAIN;
if (!strcasecmp(var, meta))
return DIFF_METAINFO;
--
2.4.1.552.g6de66a4
--
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: Staging commits with visual diff tools?
On Tue, May 26, 2015 at 09:50:49PM +0100, John Lee wrote: Does anybody have code to stage commits using a the visual diff/merge tools supported by git-difftool? Is there support in git itself somewhere, even? I'm looking for something functionally similar to git add -p Looking at the git-difftool source I can see how to write a command to do it, but wanted to check if it had already been implemented. Did I miss a way that already exists? git-gui has a visual staging tool, and I think some other git interfaces do, too (e.g., tig). But I don't think there is a way to interact with an arbitrary 3rd-party diff tool. I would think doing so would depend on the diff tool itself; what facility does it provide for picking lines or a hunk out of a diff and communicating it back to git to stage? If you are interested in looking further, see how the %patch_mode hash is defined in git-add--interactive.perl. Specifically, note that add -p is just one case: diff against the index and apply with apply --cached. But once you have a separate tool for picking hunks, you should be able to drop in the different DIFF/APPLY pairs to implement checkout -p, etc. -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: Staging commits with visual diff tools?
On Wed, 27 May 2015, Jeff King wrote: If you are interested in looking further, see how the %patch_mode hash is defined in git-add--interactive.perl. Specifically, note that add -p is just one case: diff against the index and apply with apply --cached. But once you have a separate tool for picking hunks, you should be able to drop in the different DIFF/APPLY pairs to implement checkout -p, etc. My plan was to use symlinks, checkout-index, and update-index --index-info, similar to how difftool does it. I verified on the command line that that seems to work. John -- 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
