Re: Python extension commands in git - request for policy change
On Wed, Dec 12, 2012 at 02:03:56AM -0500, Patrick Donnelly wrote: > On Wed, Dec 12, 2012 at 1:32 AM, Jeff King wrote: > > It would take a lot of effort to expose git-core's internals in a clean > > way; you'd probably be better off starting from scratch and rewriting > > large parts in a friendly library-like manner. Fortunately, there is > > already a project underway to do so: libgit2. It does not yet have > > feature parity with git, but it can do quite a bit. And there are > > already ruby and python bindings. > > Of course, this comes back to the issue of whether it's a good idea to > use perl/ruby/python as a front-end to regular git commands > (pull/push/etc.). Yeah, I think that is a separate issue, though. I cannot see us ever writing core commands like "git pull" in any scripting language besides POSIX shell due to dependency issues. So language bindings are really for things that are not going to go into git-core, or are ancillary commands that people can live without (e.g., git-add--interactive, remote helpers, etc). > While, yes, bindings can be made for these languages, you are now > making git depend on the presence of one of these languages in order > for git to function. With Lua, the (static) dependence is very small > yet brings much to git in terms of extensibility and maintainability. And I would include Lua in my list of "I cannot see..." above. It can be statically linked, so it is not a run-time dependency, but it would still be a build-time dependency. The community has historically been pretty resistant to dependencies (I do not care too much myself, though). I think doing anything significant in Lua would have the same problem as doing anything significant in Python: there would need to be substantial internal cleanup to make sane bindings. And again, that is what libgit2 is doing (and yes, there are Lua bindings for it already). Using libgit2 bindings would introduce a new dependency, of course, but that is on par with a Lua dependency. > As for Lua's suitability for your (2) point, I admit I'm not familiar > with how much "interacting with the outside world" the git commands > do; however, I would suspect that it is not significant enough to rule > Lua out? I did not mean to rule it out for point (2); I only meant that it is probably the only reasonable thing for point (1), whereas for point (2), we have many more options. I suspect Lua would do just fine given the right set of modules, though I tend to prefer other languages myself when embeddedness is not an issue. As for "interacting with the outside world", I was specifically thinking of stuff like git-send-email (currently in perl) and git-imap-send (written in C). They need to open network sockets and speak standard protocols. I suspect Lua would need a module or custom bindings to do the former at all, and certainly the code would be much simpler if we re-used standard modules for speaking SMTP and IMAP (which of course increases our dependencies again...). -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: [BUG] Cannot push some grafted branches
On Tue, 11 Dec 2012 10:15:23 -0800 Junio C Hamano wrote: > Yann Dirson writes: > > > There seems to be some bad interactions between git-push and grafts. > > The problem seems to occur when a commit that exists in the remote > > repo is subject to a graft in the local repo, and we try to push one > > of the fake parents. > > History tweaking by grafts is only visible inside your local > repository and objects are not rewritten, and grafts are not > transferred across repositories. They were invented to be used as a > stop-gap measure until you filter-branch the history before > publishing (or if you do not publish, then you can keep using your > local grafts). > > Isn't this well known? Perhaps we would need to document it better. I am well aware of that, and did not intend to push any grafted commit. I am attempting to push a well-formed commit, which happens to be used as a grafted commit's fake parent, and my interpretation is that git reacts as if it was considering that the remote already had that commit, possibly because it would not ignore grafts when deciding which commits are already known to the remote. > What you can do is to use "replace" instead and publish the replace > refs, I think. Object transfer will then follow the true parenthood > connectivity and people who choose to use the same replacement as > you do can fetch the replace ref from you (this will grab objects > necessary to complete the alternative history) and install it. I am only using grafts as a temporary and lightweight drafting area, before setting the results in stone - although in my case it will be with filter-branch rather than replace, but the idea is the same. I just got bitten when attempting to push a valid branch while the grafts were in effect, when in fact they should have had no influence at all. In fact, I even looked for a way to specify an alternate (or supplementary) grafts file for this drafting work, so only well-controlled git invocations would see them, whereas the others would just ignore them, and could not find any - nor could I identify an existing way of disabling the use of grafts by other means than moving it out of the way. In this respect, they seem to be lacking a few features, when compared to "replace" refs, but they have different uses, and just using the latter as a drafting area is just not adequate. I thought about adding support for a GIT_GRAFTS_FILE envvar, which would default to $GITDIR/info/grafts, or maybe with a more general addition of a GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful. -- Yann Dirson - Bertin Technologies -- 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-prompt.sh vs leading white space in __git_ps1()::printf_format
Hi Junio This removes most of the ambiguities :-) Ack from me! I still have some minor nits, but I'll leave that for another time when I'm less busy. BTW, I haven't tried this yet, but if you pass 2 arguments to __git_ps1 when called from command-substition mode, I suppose it will think it's in PC mode and overwrite the PS1! At some point, I'd like to see this code split off into "pc" and "cs" functions which call a common function to get the git status. But that's a major rewrite and it may involve more overhead, since each function should process the output of the common function in a different way. Cheers Simon * Junio C Hamano [2012-12-11 16:03:36 -0800]: > Junio C Hamano writes: > > > Perhaps like this? > > OK, this time with a log message. > > -- >8 -- > Subject: [PATCH] git-prompt.sh: update PROMPT_COMMAND documentation > > The description of __git_ps1 function operating in two-arg mode was > not very clear. It said "set PROMPT_COMMAND=__git_ps1" which is not > the right usage for this mode, followed by "To customize the prompt, > do this", giving a false impression that those who do not want to > customize it can get away with no-arg form, which was incorrect. > > Make it clear that this mode always takes two arguments, pre and > post, with an example. > > The straight-forward one should be listed as the primary usage, and > the confusing one should be an alternate for advanced users. Swap > the order of these two. > > Signed-off-by: Junio C Hamano > --- > contrib/completion/git-prompt.sh | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/contrib/completion/git-prompt.sh > b/contrib/completion/git-prompt.sh > index a8b53ba..9b074e1 100644 > --- a/contrib/completion/git-prompt.sh > +++ b/contrib/completion/git-prompt.sh > @@ -10,14 +10,20 @@ > #1) Copy this file to somewhere (e.g. ~/.git-prompt.sh). > #2) Add the following line to your .bashrc/.zshrc: > #source ~/.git-prompt.sh > -#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1 > -#To customize the prompt, provide start/end arguments > -#PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "' > -#3b) Alternatively change your PS1 to call __git_ps1 as > +#3a) Change your PS1 to call __git_ps1 as > #command-substitution: > #Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ ' > #ZSH: PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ ' > -#the optional argument will be used as format string > +#the optional argument will be used as format string. > +#3b) Alternatively, if you are using bash, __git_ps1 can be > +#used for PROMPT_COMMAND with two parameters, and > +#, which are strings you would put in $PS1 before > +#and after the status string generated by the git-prompt > +#machinery. e.g. > +# PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "' > +#will show username, at-sign, host, colon, cwd, then > +#various status string, followed by dollar and SP, as > +#your prompt. > # > # The argument to __git_ps1 will be displayed only if you are currently > # in a git repository. The %s token will be the name of the current > -- > 1.8.1.rc1.128.gd8d1528 > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Wed, 12 Dec 2012 09:44:32 +0100 Yann Dirson wrote: > In fact, I even looked for a way to specify an alternate (or supplementary) > grafts file for this drafting work, so only well-controlled git invocations > would see them, whereas the others would just ignore them, and could not find > any - nor could I identify an existing way of disabling the use of grafts by > other means than moving it out of the way. In this respect, they seem to be > lacking a few features, when compared to "replace" refs, but they have > different > uses, and just using the latter as a drafting area is just not adequate. > > I thought about adding support for a GIT_GRAFTS_FILE envvar, which would > default to $GITDIR/info/grafts, or maybe with a more general addition of a > GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that > useful. My bad on this point: there *is* a GIT_GRAFT_FILE envvar, it is just undocumented. In fact it is not the only one: git.git$ for v in $(git grep define.*_ENVIRONMENT master -- cache.h | cut -d'"' -f2|grep ^GIT_); do git grep -q $v master -- Documentation || echo "missing $v"; done missing GIT_GRAFT_FILE missing GIT_CONFIG_PARAMETERS -- Yann Dirson - Bertin Technologies -- 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 0/2] mailmap from blobs
I noticed recently that the GitHub contributions page for git.git did not seem very accurate. The problem is that while it uses shortlog, it does not respect .mailmap, because we do not have a working tree from which to read the .mailmap. This series adds a config option analogous to mailmap.file, but which reads from a blob in the repository (so the obvious thing to set it to is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you frequently want to traverse while on unrelated branches). The obvious alternative is to checkout a temporary file of .mailmap and point mailmap.file at it, but this is a bit more convenient. A config option is perhaps not the most flexible way to access this. For example, one could in theory want to pull the mailmap from the tip of the history being traversed (e.g., because you have multiple unrelated DAGs in a single repo). But that could also produce the _wrong_ results, if you are looking at the shortlog of older history (e.g., when doing "git shortlog v1.5.0..v1.5.5", you would still want to be using the modern mailmap from "master"). By making it a config option, the simple, common case does the right thing, and people with complex cases can use "git -c mailmap.blob=..." to feed the appropriate map for the history they are traversing. If somebody wants to do something fancier (like --mailmap-from-tip or something), it would be easy to build on top later. [1/2]: mailmap: refactor mailmap parsing for non-file sources [2/2]: mailmap: support reading mailmap from blobs -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
[PATCH 1/2] mailmap: refactor mailmap parsing for non-file sources
The read_single_mailmap function opens a mailmap file and
parses each line. In preparation for having non-file
mailmaps, let's pull out the line-parsing logic into its own
function (read_mailmap_line), and rename the file-parsing
function to match (read_mailmap_file).
Signed-off-by: Jeff King
---
Cleanup for the next patch. It's mostly indentation changes, so "diff
-w" is much easier to review.
mailmap.c | 74 ++-
1 file changed, 40 insertions(+), 34 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..89bc318 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -129,44 +129,50 @@ static int read_single_mailmap(struct string_list *map,
const char *filename, ch
return (*right == '\0' ? NULL : right);
}
-static int read_single_mailmap(struct string_list *map, const char *filename,
char **repo_abbrev)
+static void read_mailmap_line(struct string_list *map, char *buffer,
+ char **repo_abbrev)
+{
+ char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 = NULL;
+ if (buffer[0] == '#') {
+ static const char abbrev[] = "# repo-abbrev:";
+ int abblen = sizeof(abbrev) - 1;
+ int len = strlen(buffer);
+
+ if (!repo_abbrev)
+ return;
+
+ if (len && buffer[len - 1] == '\n')
+ buffer[--len] = 0;
+ if (!strncmp(buffer, abbrev, abblen)) {
+ char *cp;
+
+ if (repo_abbrev)
+ free(*repo_abbrev);
+ *repo_abbrev = xmalloc(len);
+
+ for (cp = buffer + abblen; isspace(*cp); cp++)
+ ; /* nothing */
+ strcpy(*repo_abbrev, cp);
+ }
+ return;
+ }
+ if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)
+ parse_name_and_email(name2, &name2, &email2, 1);
+
+ if (email1)
+ add_mapping(map, name1, email1, name2, email2);
+}
+
+static int read_mailmap_file(struct string_list *map, const char *filename,
+char **repo_abbrev)
{
char buffer[1024];
FILE *f = (filename == NULL ? NULL : fopen(filename, "r"));
if (f == NULL)
return 1;
- while (fgets(buffer, sizeof(buffer), f) != NULL) {
- char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 =
NULL;
- if (buffer[0] == '#') {
- static const char abbrev[] = "# repo-abbrev:";
- int abblen = sizeof(abbrev) - 1;
- int len = strlen(buffer);
-
- if (!repo_abbrev)
- continue;
-
- if (len && buffer[len - 1] == '\n')
- buffer[--len] = 0;
- if (!strncmp(buffer, abbrev, abblen)) {
- char *cp;
-
- if (repo_abbrev)
- free(*repo_abbrev);
- *repo_abbrev = xmalloc(len);
-
- for (cp = buffer + abblen; isspace(*cp); cp++)
- ; /* nothing */
- strcpy(*repo_abbrev, cp);
- }
- continue;
- }
- if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0))
!= NULL)
- parse_name_and_email(name2, &name2, &email2, 1);
-
- if (email1)
- add_mapping(map, name1, email1, name2, email2);
- }
+ while (fgets(buffer, sizeof(buffer), f) != NULL)
+ read_mailmap_line(map, buffer, repo_abbrev);
fclose(f);
return 0;
}
@@ -175,8 +181,8 @@ int read_mailmap(struct string_list *map, char
**repo_abbrev)
{
map->strdup_strings = 1;
/* each failure returns 1, so >1 means both calls failed */
- return read_single_mailmap(map, ".mailmap", repo_abbrev) +
- read_single_mailmap(map, git_mailmap_file, repo_abbrev) > 1;
+ return read_mailmap_file(map, ".mailmap", repo_abbrev) +
+ read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 1;
}
void clear_mailmap(struct string_list *map)
--
1.8.0.2.4.g59402aa
--
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 2/2] mailmap: support reading mailmap from blobs
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.
Signed-off-by: Jeff King
---
The error-return convention from read_mailmap is really wonky, but I
didn't change it here. It will return "1" for error, and will do so only
if no mailmap sources could be read (including if they simply don't
exist). But it's perfectly OK not to have a mailmap at all. However,
nobody actually seems to check the return code, so nobody has cared.
A more sane convention would probably be:
1. If ENOENT (or no such blob), silently return success.
2. Otherwise, return -1 and print a message to stderr indicating that
there is a mailmap file, but it is broken or otherwise could not be
opened.
Documentation/config.txt | 6
cache.h | 1 +
config.c | 2 ++
mailmap.c| 49 ++--
t/t4203-mailmap.sh | 73
5 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..3760077 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1517,6 +1517,12 @@ mailmap.file::
subdirectory, or somewhere outside of the repository itself.
See linkgit:git-shortlog[1] and linkgit:git-blame[1].
+mailmap.blob::
+ Like `mailmap.file`, but consider the value as a reference to a
+ blob in the repository (e.g., `HEAD:.mailmap`). If both
+ `mailmap.file` and `mailmap.blob` are given, both are parsed,
+ with entries from `mailmap.file` taking precedence.
+
man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
diff --git a/cache.h b/cache.h
index 18fdd18..a65f6d1 100644
--- a/cache.h
+++ b/cache.h
@@ -1155,6 +1155,7 @@ extern const char *git_mailmap_file;
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
extern const char *git_mailmap_file;
+extern const char *git_mailmap_blob;
/* IO helper functions */
extern void maybe_flush_or_die(FILE *, const char *);
diff --git a/config.c b/config.c
index fb3f868..97364c0 100644
--- a/config.c
+++ b/config.c
@@ -839,6 +839,8 @@ static int git_default_mailmap_config(const char *var,
const char *value)
{
if (!strcmp(var, "mailmap.file"))
return git_config_string(&git_mailmap_file, var, value);
+ if (!strcmp(var, "mailmap.blob"))
+ return git_config_string(&git_mailmap_blob, var, value);
/* Add other config variables here and to Documentation/config.txt. */
return 0;
diff --git a/mailmap.c b/mailmap.c
index 89bc318..2f9c691 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -10,6 +10,7 @@ const char *git_mailmap_file;
#endif
const char *git_mailmap_file;
+const char *git_mailmap_blob;
struct mailmap_info {
char *name;
@@ -177,12 +178,56 @@ int read_mailmap(struct string_list *map, char
**repo_abbrev)
return 0;
}
+static void read_mailmap_buf(struct string_list *map,
+const char *buf, unsigned long len,
+char **repo_abbrev)
+{
+ while (len) {
+ const char *end = strchrnul(buf, '\n');
+ unsigned long linelen = end - buf + 1;
+ char *line = xmemdupz(buf, linelen);
+
+ read_mailmap_line(map, line, repo_abbrev);
+
+ free(line);
+ buf += linelen;
+ len -= linelen;
+ }
+}
+
+static int read_mailmap_blob(struct string_list *map,
+const char *name,
+char **repo_abbrev)
+{
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ enum object_type type;
+
+ if (!name)
+ return 1;
+ if (get_sha1(name, sha1) < 0)
+ return 1;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return 1;
+ if (type != OBJ_BLOB)
+ return 1;
+
+ read_mailmap_buf(map, buf, size, repo_abbrev);
+
+ free(buf);
+ return 0;
+}
+
int read_mailmap(struct string_list *map, char **repo_abbrev)
{
map->strdup_strings = 1;
- /* each failure returns 1, so >1 means both calls failed */
+ /* each failure returns 1, so >2 means all calls failed */
return read_mailmap_file(map, ".mailmap", repo_abbrev) +
- read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 1;
+ read_mailmap_blob(map, git_mailmap_blob, repo_abbrev) +
+ read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 2;
}
void clear_mailmap(struct string_list *map)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6.
[PATCH 3/2] mailmap: clean up read_mailmap error handling
On Wed, Dec 12, 2012 at 06:04:04AM -0500, Jeff King wrote:
> The error-return convention from read_mailmap is really wonky, but I
> didn't change it here. It will return "1" for error, and will do so only
> if no mailmap sources could be read (including if they simply don't
> exist). But it's perfectly OK not to have a mailmap at all. However,
> nobody actually seems to check the return code, so nobody has cared.
>
> A more sane convention would probably be:
>
> 1. If ENOENT (or no such blob), silently return success.
>
> 2. Otherwise, return -1 and print a message to stderr indicating that
> there is a mailmap file, but it is broken or otherwise could not be
> opened.
Maybe like this:
-- >8 --
Subject: [PATCH] mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King
---
mailmap.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index 2f9c691..5ffe48a 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -168,10 +168,19 @@ static int read_mailmap_file(struct string_list *map,
const char *filename,
char **repo_abbrev)
{
char buffer[1024];
- FILE *f = (filename == NULL ? NULL : fopen(filename, "r"));
+ FILE *f;
+
+ if (!filename)
+ return 0;
+
+ f = fopen(filename, "r");
+ if (!f) {
+ if (errno == ENOENT)
+ return 0;
+ return error("unable to open mailmap at %s: %s",
+filename, strerror(errno));
+ }
- if (f == NULL)
- return 1;
while (fgets(buffer, sizeof(buffer), f) != NULL)
read_mailmap_line(map, buffer, repo_abbrev);
fclose(f);
@@ -205,15 +214,15 @@ static int read_mailmap_blob(struct string_list *map,
enum object_type type;
if (!name)
- return 1;
+ return 0;
if (get_sha1(name, sha1) < 0)
- return 1;
+ return 0;
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
- return 1;
+ return error("unable to read mailmap object at %s", name);
if (type != OBJ_BLOB)
- return 1;
+ return error("mailmap is not a blob: %s", name);
read_mailmap_buf(map, buf, size, repo_abbrev);
@@ -223,11 +232,12 @@ int read_mailmap(struct string_list *map, char
**repo_abbrev)
int read_mailmap(struct string_list *map, char **repo_abbrev)
{
+ int err = 0;
map->strdup_strings = 1;
- /* each failure returns 1, so >2 means all calls failed */
- return read_mailmap_file(map, ".mailmap", repo_abbrev) +
- read_mailmap_blob(map, git_mailmap_blob, repo_abbrev) +
- read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 2;
+ err |= read_mailmap_file(map, ".mailmap", repo_abbrev);
+ err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);
+ err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);
+ return err;
}
void clear_mailmap(struct string_list *map)
--
1.8.0.2.4.g59402aa
--
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 0/5] git.git .mailmap cleanups
I noticed a few obvious problems in the output of "git shortlog -nse" on git.git. So I wrote an analysis script to find more, and of course there were lots. This series tries to clean up the low-hanging fruit. The first two commits fix multiple names matching a single email. Hopefully not too contentious, but I'll cc all involved parties to confirm. The second has a different root cause, so I've broken it out into its own commit. [1/5]: .mailmap: match up some obvious names/emails [2/5]: .mailmap: fix broken entry for Martin Langhoff Next up are multiple emails which match a single name. There are over a hundred of these, and they are much less obvious to fix. They really need individuals to post patches to fix their own identities (and some may not want fixing at all, if they used different emails to have meaningful different identities). So I've left these untouched except for: [3/5]: .mailmap: normalize emails for Jeff King I am allowed to fix my own. :) [4/5]: .mailmap: normalize emails for Linus Torvalds As the benevolent dictator, Linus has underlings to fix such things for him. Also, his entry was the original reason I started looking at the data. He fares quite poorly in "shortlog -nse" because his commits are scattered across many addresses. [5/5]: contrib: update stats/mailmap script This replaces the current mailmap script in contrib, which has a bug and lacks some of the features of my new script. -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
[PATCH 1/5] .mailmap: match up some obvious names/emails
This patch updates git's .mailmap in cases where multiple names are matched to a single email. The "master" name for each email was chosen by: 1. If the only difference is in the presence or absence of accented characters, the accented form is chosen (under the assumption that it is the natural spelling, and accents are sometimes stripped in email). 2. Otherwise, the most commonly used name is chosen. 3. If all names are equally common, the most recently used name is chosen. Signed-off-by: Jeff King --- I'm cc-ing all involved authors. If you object or want to normalize your name in some other way, please let me know. .mailmap | 10 ++ 1 file changed, 10 insertions(+) diff --git a/.mailmap b/.mailmap index bcf4f87..69301bd 100644 --- a/.mailmap +++ b/.mailmap @@ -9,7 +9,9 @@ Chris Shoemaker Alexander Gavrilov Aneesh Kumar K.V Brian M. Carlson +Cheng Renquan Chris Shoemaker +Dan Johnson Dana L. How Dana L. How Daniel Barkalow @@ -18,13 +20,16 @@ Horst H. von Brand David S. Miller Deskin Miller Dirk Süsserott +Eric S. Raymond Erik Faye-Lund Fredrik Kuivinen +Frédéric Heitzmann H. Peter Anvin H. Peter Anvin H. Peter Anvin Horst H. von Brand İsmail Dönmez +Jakub Narębski Jay Soffian Joachim Berdal Haga Johannes Sixt @@ -41,11 +46,14 @@ Lukas Sandström Junio C Hamano Junio C Hamano Karl Hasselström +Kevin Leung Kent Engstrom Lars Doelle Lars Doelle Li Hong Lukas Sandström +Marc-André Lureau +Mark Rada Martin Langhoff Martin von Zweigbergk Michael Coleman @@ -63,11 +71,13 @@ Steven Grimm Ramsay Allan Jones René Scharfe Robert Fitzsimons +Robert Zeh Sam Vilain Santi Béjar Sean Estabrooks Shawn O. Pearce Steven Grimm +Tay Ray Chuan Theodore Ts'o Thomas Rast Tony Luck -- 1.8.0.2.4.g59402aa -- 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 2/5] .mailmap: fix broken entry for Martin Langhoff
Commit adc3192 (Martin Langhoff has a new e-mail address, 2010-10-05) added a mailmap entry, but forgot that both the old and new email addresses need to appear for one to be mapped to the other (i.e., we do not key mailmap emails by name). Signed-off-by: Jeff King --- .mailmap | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index 69301bd..e370e86 100644 --- a/.mailmap +++ b/.mailmap @@ -54,7 +54,7 @@ Mark Rada Lukas Sandström Marc-André Lureau Mark Rada -Martin Langhoff +Martin Langhoff Martin von Zweigbergk Michael Coleman Michael J Gruber -- 1.8.0.2.4.g59402aa -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] .mailmap: normalize emails for Jeff King
I never meant anything special by using my @github.com address; it is merely a mistake that it has sometimes bled through to patches. Signed-off-by: Jeff King --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index e370e86..4a27b7f 100644 --- a/.mailmap +++ b/.mailmap @@ -31,6 +31,7 @@ Jay Soffian İsmail Dönmez Jakub Narębski Jay Soffian +Jeff King Joachim Berdal Haga Johannes Sixt Johannes Sixt -- 1.8.0.2.4.g59402aa -- 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 4/5] .mailmap: normalize emails for Linus Torvalds
Linus used a lot of different per-machine email addresses in the early days. This means that "git shortlog -nse" does not aggregate his counts, and he is listed well below where he should be (8th instead of 3rd). Signed-off-by: Jeff King --- Linus, I recall you considered "email ident from random machine" as a feature very early on in git's history, but you seem to have settled on using the linux-foundation address pretty consistently these days. Please let me know if you object to normalizing your entries in this way. .mailmap | 6 ++ 1 file changed, 6 insertions(+) diff --git a/.mailmap b/.mailmap index 4a27b7f..c7e8618 100644 --- a/.mailmap +++ b/.mailmap @@ -52,6 +52,12 @@ Li Hong Lars Doelle Lars Doelle Li Hong +Linus Torvalds +Linus Torvalds +Linus Torvalds +Linus Torvalds +Linus Torvalds +Linus Torvalds Lukas Sandström Marc-André Lureau Mark Rada -- 1.8.0.2.4.g59402aa -- 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 5/5] contrib: update stats/mailmap script
This version changes quite a few things:
1. The original parsed the mailmap file itself, and it did
it wrong (it did not understand entries with an extra
email key).
Instead, this version uses git's "%aE" and "%aN"
formats to have git perform the mapping, meaning we do
not have to read .mailmap at all, but still operate on
the current state that git sees (and it also works
properly from subdirs).
2. The original would find multiple names for an email,
but not the other way around.
This version can do either or both. If we find multiple
emails for a name, the resolution is less obvious than
the other way around. However, it can still be a
starting point for a human to investigate.
3. The original would order only by count, not by recency.
This version can do either. Combined with showing the
counts, it can be easier to decide how to resolve.
4. This version shows similar entries in a blank-delimited
stanza, which makes it more clear which options you are
picking from.
Signed-off-by: Jeff King
---
contrib/stats/mailmap.pl | 108 ++-
1 file changed, 70 insertions(+), 38 deletions(-)
rewrite contrib/stats/mailmap.pl (97%)
diff --git a/contrib/stats/mailmap.pl b/contrib/stats/mailmap.pl
dissimilarity index 97%
index 4b852e2..9513f5e 100755
--- a/contrib/stats/mailmap.pl
+++ b/contrib/stats/mailmap.pl
@@ -1,38 +1,70 @@
-#!/usr/bin/perl -w
-my %mailmap = ();
-open I, "<", ".mailmap";
-while () {
- chomp;
- next if /^#/;
- if (my ($author, $mail) = /^(.*?)\s+<(.+)>$/) {
- $mailmap{$mail} = $author;
- }
-}
-close I;
-
-my %mail2author = ();
-open I, "git log --pretty='format:%ae %an' |";
-while () {
- chomp;
- my ($mail, $author) = split(/\t/, $_);
- next if exists $mailmap{$mail};
- $mail2author{$mail} ||= {};
- $mail2author{$mail}{$author} ||= 0;
- $mail2author{$mail}{$author}++;
-}
-close I;
-
-while (my ($mail, $authorcount) = each %mail2author) {
- # %$authorcount is ($author => $count);
- # sort and show the names from the most frequent ones.
- my @names = (map { $_->[0] }
- sort { $b->[1] <=> $a->[1] }
- map { [$_, $authorcount->{$_}] }
- keys %$authorcount);
- if (1 < @names) {
- for (@names) {
- print "$_ <$mail>\n";
- }
- }
-}
-
+#!/usr/bin/perl
+
+use warnings 'all';
+use strict;
+use Getopt::Long;
+
+my $match_emails;
+my $match_names;
+my $order_by = 'count';
+Getopt::Long::Configure(qw(bundling));
+GetOptions(
+ 'emails|e!' => \$match_emails,
+ 'names|n!' => \$match_names,
+ 'count|c' => sub { $order_by = 'count' },
+ 'time|t'=> sub { $order_by = 'stamp' },
+) or exit 1;
+$match_emails = 1 unless $match_names;
+
+my $email = {};
+my $name = {};
+
+open(my $fh, '-|', "git log --format='%at <%aE> %aN'");
+while(<$fh>) {
+ my ($t, $e, $n) = /(\S+) <(\S+)> (.*)/;
+ mark($email, $e, $n, $t);
+ mark($name, $n, $e, $t);
+}
+close($fh);
+
+if ($match_emails) {
+ foreach my $e (dups($email)) {
+ foreach my $n (vals($email->{$e})) {
+ show($n, $e, $email->{$e}->{$n});
+ }
+ print "\n";
+ }
+}
+if ($match_names) {
+ foreach my $n (dups($name)) {
+ foreach my $e (vals($name->{$n})) {
+ show($n, $e, $name->{$n}->{$e});
+ }
+ print "\n";
+ }
+}
+exit 0;
+
+sub mark {
+ my ($h, $k, $v, $t) = @_;
+ my $e = $h->{$k}->{$v} ||= { count => 0, stamp => 0 };
+ $e->{count}++;
+ $e->{stamp} = $t unless $t < $e->{stamp};
+}
+
+sub dups {
+ my $h = shift;
+ return grep { keys($h->{$_}) > 1 } keys($h);
+}
+
+sub vals {
+ my $h = shift;
+ return sort {
+ $h->{$b}->{$order_by} <=> $h->{$a}->{$order_by}
+ } keys($h);
+}
+
+sub show {
+ my ($n, $e, $h) = @_;
+ print "$n <$e> ($h->{$order_by})\n";
+}
--
1.8.0.2.4.g59402aa
--
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 5/5] log: Add --use-mailmap option
On Tue, Dec 11, 2012 at 11:21 PM, Antoine Pelisse wrote: > Add the --use-mailmap option to log commands. It allows > to display names from mailmap file when displaying logs, > whatever the format used. The question is which log commands actually ? Shouldn't we put the option in revision.c::handle_revision_opt instead ? My opinion is that it belongs to 'Commit Formatting'. It would also make sense to be able to use '--use-mailmap' when running format-patch for example. Also, I've noticed that my series break some tests (linked with format-patch BTW). I fixed that and re-ran all tests successfully. I will resubmit it later. -- 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: Python extension commands in git - request for policy change
Joshua Jensen : > Anyway, my preference is to allow scripts to run in-process within > Git, because it is far, far faster on Windows. I imagine it is > faster than forking processes on non-Windows machines, too, but I > have no statistics to back that up. > > Python, Perl, or Ruby can be embedded, too, but Lua probably embeds > the easiest and smallest out of those other 3 languages. > > And shell scripts tend to be the slowest on Windows due to the > excessive numbers of process invocations needed to get anything > reasonable done. I don't think there's *any* dimension along which lua is not clearly better than shell for this sort of thing, so no argument there. -- http://www.catb.org/~esr/";>Eric S. Raymond -- 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(1): remove a defunct link to "list of authors"
On Mon, Dec 10, 2012 at 07:04:40PM +0700, Nguyen Thai Ngoc Duy wrote: > > With or without "--no-merges", the big picture you can get out of > > "git shortlog -s -n --since=1.year" does not change very much, but > > the headline numbers give a wrong impression. > > These numbers are approximate anyway. Commit counts or the number of > changed lines do not accurately reflect the effort in many cases. And > about merges, in this particular case of Git where the maintainer imo > has done an excellent job as a guard, I'd say it's the credit for > reviewing, not simply merging. I agree that commit count is approximate. But counting merges is really quite a large factor of error (in git.git, it more than doubles Junio's count, and represents over 20% of the total number of commits). The GitHub contributors page counts merges _and_ fails to use mailmap. Yuck. I'm working on fixing that now. > But not using the link is fine too. We can wait for Jeff's patch to be > merged. After the discussion in the PR, I am inclined to think the site (and possibly the manpage) should just point to some decent contributors graph (either GitHub, ohloh, or something else; suggestions welcome). Anything else is just recreating a crappy static version of something that could be much more dynamic and explorable. I find the ohloh one a little more informative than the GitHub graph. I couldn't find any others (Google Code does not seem to have one, kernel.org and other gitweb sites do not, and I can't think of anywhere else that hosts a mirror). -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: Python extension commands in git - request for policy change
Jeff King : > I think there are really two separate use cases to consider: > > 1. Providing snippets of script to Git to get Turing-complete behavior > for existing Git features. For example, selecting commits during a > traversal (e.g., a better "log --grep"), formatting output (e.g., a > better "log --format" or "for-each-ref --format"). > > 2. Writing whole new git commands in a language that is quicker or > easier to develop in than C. That's good analysis. I agree with your use-case split, I guess I'm just not very aware of the places in git where (1) is important. -- http://www.catb.org/~esr/";>Eric S. Raymond -- 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: Python extension commands in git - request for policy change
On Wed, Dec 12, 2012 at 07:26:25AM -0500, Eric S. Raymond wrote: > Jeff King : > > I think there are really two separate use cases to consider: > > > > 1. Providing snippets of script to Git to get Turing-complete behavior > > for existing Git features. For example, selecting commits during a > > traversal (e.g., a better "log --grep"), formatting output (e.g., a > > better "log --format" or "for-each-ref --format"). > > > > 2. Writing whole new git commands in a language that is quicker or > > easier to develop in than C. > > That's good analysis. I agree with your use-case split, I guess I'm just not > very aware of the places in git where (1) is important. Yeah, I don't think (1) is your use case at all. But when people talk about "Jeff's lua experiment", they are talking about some patches I had to do (1), which covered "log --format" (but ultimately would need more cleanup to be acceptable upstream). Maybe that clears up the discussion a little bit. -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: Python extension commands in git - request for policy change
Patrick Donnelly : > On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond wrote: > > It might be a good fit for extending git; I wouldn't be very surprised if > > that worked. However, I do have concerns about the "Oh, we'll just > > lash together a binding to C" attitude common among lua programmers; I > > foresee maintainability problems and the possibility of slow death by > > low-level details as that strategy tries to scale up. > > I think this is quite a prediction? Could you give an example > scenario? Everything old is new again. I'm going by experience with Tcl back in the day. >How would another language (e.g. Python) mitigate this? The way you mitigate this sort of problem is to have a good set of high-level bindings for standard services (like socket I/O) built in your extension language and using its abstractions, so you don't get a proliferation of low-level semi-custom APIs for doing the same stuff. I have elsewhere referred to this as "the harsh lesson of Perl", which I do not love but which was the first scripting language to get this right. There is a reason Tcl and a couple of earlier designs like csh that we would now call "scripting languages" were displaced by Python and Perl; this is it. My favorite present-day example of getting this right is the Python bindings for GTK. They're lovely. A work of art. > I don't see how these languages are more appropriate based on your concerns. Your previous exchange with Jeff King indicates that you don't understand glue scripting very well. Your puzzlement here just confirms that. Trust both of us on this, it's important. And reread my previous three paragraphs. -- http://www.catb.org/~esr/";>Eric S. Raymond -- 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] index-format.txt: be more liberal on what can represent invalid cache tree
We have been writing -1 as "invalid" since day 1. On that same day we accept all negative entry counts as "invalid". So in theory all C Git versions out there would be happy to accept any negative numbers. JGit seems to do exactly the same. Correct the document to reflect the fact that -1 is not the only magic number. At least one implementation, libgit2, is found to treat -1 this way. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/technical/index-format.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..2028a49 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -161,8 +161,8 @@ GIT index format this span of index as a tree. An entry can be in an invalidated state and is represented by having - -1 in the entry_count field. In this case, there is no object name - and the next entry starts immediately after the newline. + a negative number in the entry_count field. In this case, there is no + object name and the next entry starts immediately after the newline. The entries are written out in the top-down, depth-first order. The first entry represents the root level of the repository, followed by the -- 1.8.0.rc2.23.g1fb49df -- 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 4/5] pretty: Use mailmap to display username and email
> Or it might be better to make those two strbufs output-only > parameter, e.g. > > map_user(struct string_list *mailmap, > const char *name, size_t namelen, > const char *mail, size_t maillen, > struct strbuf *name_out, struct strbuf *mail_out); > > then after split_ident_line(), this caller could feed two pointers > into the original "line" as name and mail parameter, without making > any copies (the callee has to make a copy but it has to be done > anyway when the name/mail is mapped). I suspect it would make this > caller simpler, but I do not know how invasive such changes are for > other callers of map_user(). It makes a lot of sense. blame.c::get_commit_info() hard code the length shortlog.c::insert_one_record() hard code the length pretty.c::format_person_part() hard code the length I don't think it will be invasive. > Such an update can be left outside of this series, of course. I will try to make it at the beginning of the series. It will avoid unnecessary conflicts. >> + strbuf_addch(sb, ' '); >> + strbuf_addch(sb, '<'); >> + strbuf_add(sb, person_mail, strlen(person_mail)); >> + strbuf_addch(sb, '>'); >> strbuf_addch(sb, '\n'); > > Is that strbuf_addf(sb, " <%s>\n", person_mail)? Of couse ;) 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: Bad URL passed to RA layer ('https')
Here I. Come gmail.com> writes: > --8<--- > $ git svn clone https://host/svn/myrepo > Initialized empty Git repository in /tmp/myrepo/.git/ > Bad URL passed to RA layer: Unrecognized URL scheme for > 'https://host/svn/myrepo' at /usr/libexec/git-core/git-svn line 1770 > --8<--- Hi, I have faced with the same problem. Did you find out who to resolve it? -- 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] RFC Optionally handle symbolic links as copies
Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23: > > > - Ursprungligt meddelande - >> Robin Rosenberg writes: >> >>> If core.symlinks is set to copy then symbolic links in a git >>> repository >>> will be checked out as copies of the file it points to. >> >> That all sounds nice on surface when the primary thing you care >> about is to fetch and check out other people's code and extract it >> to the working tree, but how well would that work on the checkin >> side? What happens if I check out a symlink that points at a file >> (either in-tree or out-of-tree), make some changes that do not >> involve the symlink, and before I make the commit, an unrelated >> change is made to the file the symlink is pointing at? >> >>> - git status - when do we report a diff. >>> - After checkout we should probably not >>> - if the "linked" files change? >> >> Yeah, exactly. >> >>> - if a change in the copied directory chsnges >> >> That, too. >> >>> - if a file in the copied diretory is added/removed >>> - update, should we update the copied structure automatically >>> when the link target changes > > Some of the questions have proposals in the includes test script. A > little more dangerous than having real symlinks ofcourse, but regardless > of what one does with or without copied symlinks one can make mistakes > and I feel letting Git do the copying is way better than having real > copies in the git repository. Another crappy scm which the users are > converting from does this and it works. A difference to git is that > it (ok clearcase) makes all files read-only so there are fewer mays > of making mistakes with the copies. > >> I personally do not think this is worth it. It would be very useful >> on the export/checkout side, so it may make sense to add it to "git >> archive", though. > > It makes sense, but it does not solve the problem at hand. > > -- robin > Well, what is the problem at hand? Your commit message begins in present tense as if it described the current state of git, when in fact it describes what the patch is about to achieve. This is confusing enough already, I don't see any mention of the purpose, other than "content may be used", which would be served perfectly by a copy-on-link feature on the export side, as mentioned by Junio. Is git-archive|tar an option? 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: How to avoid the ^M induced by Meld and Git
Karl Brand venit, vidit, dixit 11.12.2012 13:33: > Esteemed Git users, > > What i do: > > 1. Create a script.r using Emacs/ESS. > 2. Make some modifications to script.r with the nice diff gui, Meld > 3. Commit these modifications using git commit -am "my message" > 4. Reopen script.r in Emacs/ESS to continue working. > > The lines added (&/edited ?) using Meld all end with ^M which i > certainly don't want. Lines not added/edited with Meld do NOT end with ^M. What happens if you leave out step 3? If the same happens then Meld is the culprit. (Unless you've set some special options, git does not modify your file on commit, so this can't be git related.) > There are plenty of posts around about these being line endings used for > windows which can appear when working on a script under a *nix OS which > has previously been edited in a Windows OS. This is not the case here - > everything is taking place on Ubuntu 12.04. > > FWIW: the directory is being synced by dropbox; and in Meld, Preferences > > Encoding tab, "utf8" is entered in the text box. > > Current work around is running in a terminal: dos2unix /path/to/script.r > which strips the ^M's > > But this just shouldn't be necessary and I'd really appreciate the > reflections & advice on how to stop inducing these ^M's ! > > With thanks, > > Karl > > (re)posted here as suggested off topic at SO: > http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m > -- 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] submodule: add 'deinit' command
Jens Lehmann venit, vidit, dixit 04.12.2012 22:48: > With "git submodule init" the user is able to tell git he cares about one > or more submodules and wants to have it populated on the next call to "git > submodule update". But currently there is no easy way he could tell git he > does not care about a submodule anymore and wants to get rid of his local > work tree (except he knows a lot about submodule internals and removes the > "submodule.$name.url" setting from .git/config himself). > > Help those users by providing a 'deinit' command. This removes the whole > submodule. section from .git/config either for the given > submodule(s) or for all those which have been initialized if none were > given. Complain only when for a submodule given on the command line the > url setting can't be found in .git/config. Whoaaa, so why not have "git rm" remove everything unless I specify a file to be removed? I know I'm exaggerating a bit, but defaulting to "--all" for a destructive operation seems to be a bit harsh, especially when the command is targeted at "those" users that you mention. > Add tests and link the man pages of "git submodule deinit" and "git rm" > to assist the user in deciding whether removing or unregistering the > submodule is the right thing to do for him. > > Signed-off-by: Jens Lehmann > --- > > Am 03.12.2012 08:58, schrieb Junio C Hamano: >> Jens Lehmann writes: >> >>> Maybe the principle of least surprise is better followed when we >>> nuke the whole section, as it might surprise the user more to have >>> a setting resurrected he customized in the last life cycle of the >>> submodule than seeing that after an deinit followed by an init all >>> former customizations are consistently gone. So I tend to think now >>> that removing the whole section would be the better solution here. >> >> I tend to agree; I suspect that a "deinit" would be mostly done >> either to >> >> (1) correct mistakes the user made during a recent "init" and >> perhaps "sync"; or >> >> (2) tell Git that the user has finished woing with this particular >> submodule and does not intend to use it for quite a while. >> >> For both (1) and (2), I think it would be easier to users if we gave >> them a clean slate, the same state as the one the user who never had >> ran "init" on it would be in. A user in situation (1) is asking for >> a clean slate, and a user in situation (2) is better served if he >> does not have to worry about leftover entries in $GIT_DIR/config he >> has long forgotten from many months ago (during which time the way >> the project uses the particular submodule may well have changed) >> giving non-standard experience different from what other project >> participants would get. > > Changes in v2: > - Remove the whole submodule section instead of only removing the > "url" setting and explain why we do that in a comment > - Reworded commit message and git-submodule.txt to reflect that > - Extend the test to check that a custom settings are removed > > > Documentation/git-rm.txt| 4 > Documentation/git-submodule.txt | 12 ++ > git-submodule.sh| 52 > - > t/t7400-submodule-basic.sh | 12 ++ > 4 files changed, 79 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt > index 262436b..ec42bf5 100644 > --- a/Documentation/git-rm.txt > +++ b/Documentation/git-rm.txt > @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules > work tree. > Ignored files are deemed expendable and won't stop a submodule's work > tree from being removed. > > +If you only want to remove the local checkout of a submodule from your > +work tree without committing that use `git submodule deinit` instead > +(see linkgit:git-submodule[1]). > + > EXAMPLES > > `git rm Documentation/\*.txt`:: > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt > index b1de3ba..08b55a7 100644 > --- a/Documentation/git-submodule.txt > +++ b/Documentation/git-submodule.txt > @@ -13,6 +13,7 @@ SYNOPSIS > [--reference ] [--] [] > 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...] > 'git submodule' [--quiet] init [--] [...] > +'git submodule' [--quiet] deinit [--] [...] > 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] > [--reference ] [--merge] [--recursive] [--] > [...] > 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) > ] > @@ -134,6 +135,17 @@ init:: > the explicit 'init' step if you do not intend to customize > any submodule locations. > > +deinit:: > + Unregister the submodules, i.e. remove the whole `submodule.$name` > + section from .git/config. Further calls to `git submodule update`, > + `git submodule foreach` and `git submodule sync` will skip any > + unregistered submodules until they are initialized again, s
Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote: > What branch did you base this series on? Every version of this series has been based on v1.8.0. > The preimage of git-submodule.sh in [2/3] does not seem to match > anything I have (I could wiggle the patch, but in general I would > rather prefer not having to). From patch 1/3: diff --git a/git-submodule.sh b/git-submodule.sh index ab6b110..f969f28 100755 And from patch 2/3: diff --git a/git-submodule.sh b/git-submodule.sh index f969f28..1395079 100755 ab6b110 is in v1.8.0: $ git ls-tree v1.8.0 git-submodule.sh 100755 blob ab6b1107b6090494f192f361471ed5748ffa7dc1git-submodule.sh I can reroll if necessary, but I'm not sure what I've done wrong… Cheers, Trevor signature.asc Description: OpenPGP digital signature
Re: How to avoid the ^M induced by Meld and Git
On 12/12/12 15:57, Michael J Gruber wrote: Karl Brand venit, vidit, dixit 11.12.2012 13:33: Esteemed Git users, What i do: 1. Create a script.r using Emacs/ESS. 2. Make some modifications to script.r with the nice diff gui, Meld 3. Commit these modifications using git commit -am "my message" 4. Reopen script.r in Emacs/ESS to continue working. The lines added (&/edited ?) using Meld all end with ^M which i certainly don't want. Lines not added/edited with Meld do NOT end with ^M. What happens if you leave out step 3? If the same happens then Meld is the culprit. (Unless you've set some special options, git does not modify your file on commit, so this can't be git related.) Leaving out step 3. results in exactly the same thing. Thus Git doesn't appear to be responsible for the ^M's. Thanks a lot for your effort on this and my apologies for not taking the care to dissect this more carefully as you suggested. Over to the Meld mailing list... There are plenty of posts around about these being line endings used for windows which can appear when working on a script under a *nix OS which has previously been edited in a Windows OS. This is not the case here - everything is taking place on Ubuntu 12.04. FWIW: the directory is being synced by dropbox; and in Meld, Preferences > Encoding tab, "utf8" is entered in the text box. Current work around is running in a terminal: dos2unix /path/to/script.r which strips the ^M's But this just shouldn't be necessary and I'd really appreciate the reflections & advice on how to stop inducing these ^M's ! With thanks, Karl (re)posted here as suggested off topic at SO: http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m -- Karl Brand Dept of Cardiology and Dept of Bioinformatics Erasmus MC Dr Molewaterplein 50 3015 GE Rotterdam T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bug?) Inconsistent workdir file timestamps after initial clone.
On 12-12-11 05:30 PM, Junio C Hamano wrote: > Marc Branchaud writes: > >> My point is that the initial checkout into an empty working directory should >> create all files with the same timestamp. >> >> Or, to be a bit more precise, whenever git-checkout *creates* files in the >> work dir, *all* the created files should have the *same* timestamp (i.e. the >> current time measured at the start of the checkout's execution, not some >> bizarro other time specified by some arcane heuristic). > > My knee-jerk reaction is that it is insane to do so, but what other > SCM does such a thing? I'm lucky enough to just care about git these days. > Even "tar xf" wouldn't do that, I think. "tar xf" uses the timestamps that are stored in the tar file. I see this as an argument against git's exact-current-time-per-file approach: even the tar guys understand that it's insane. >>> While not including files that can be rebuilt from the source may be >>> the ideal solution, I've seen projects hide rules to rebuild such a >>> "generated but needs special tools to build" and/or a "generated but >>> normal developers do not have any business rebuilding" file (in your >>> case, Makefile.in) in their Makefiles from the normal targets (like >>> "make all") for this exact reason, when they choose to distribute >>> such files by including in their commits. >> >> I prefer to use the third-party code as-is, without hacking it, to have >> smooth upgrades in the future. > > Then perhaps take the complaints to that third-party upstream, not > here? Well, I thought that while I wait for some dozen-or-so projects to accept changes to their builds, it might be nice for git to solve this problem for me. It is, after all, an effect of the way git operates. M. -- 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: How to avoid the ^M induced by Meld and Git
Karl Brand venit, vidit, dixit 12.12.2012 16:34: > > > On 12/12/12 15:57, Michael J Gruber wrote: >> Karl Brand venit, vidit, dixit 11.12.2012 13:33: >>> Esteemed Git users, >>> >>> What i do: >>> >>> 1. Create a script.r using Emacs/ESS. >>> 2. Make some modifications to script.r with the nice diff gui, Meld >>> 3. Commit these modifications using git commit -am "my message" >>> 4. Reopen script.r in Emacs/ESS to continue working. >>> >>> The lines added (&/edited ?) using Meld all end with ^M which i >>> certainly don't want. Lines not added/edited with Meld do NOT end with ^M. >> >> What happens if you leave out step 3? If the same happens then Meld is >> the culprit. (Unless you've set some special options, git does not >> modify your file on commit, so this can't be git related.) >> > > Leaving out step 3. results in exactly the same thing. Thus Git doesn't > appear to be responsible for the ^M's. Thanks a lot for your effort on > this and my apologies for not taking the care to dissect this more > carefully as you suggested. Over to the Meld mailing list... I didn't mean to shy you away ;) Could it be that there is a ^M very early in the file (or rather something else which isn't covered by dos2unix) so that Meld thinks it's DOS and inserts line endings as DOS? At least that's what vim would do. In any case, Meld people over there should know (or get to know) that effect. >>> There are plenty of posts around about these being line endings used for >>> windows which can appear when working on a script under a *nix OS which >>> has previously been edited in a Windows OS. This is not the case here - >>> everything is taking place on Ubuntu 12.04. >>> >>> FWIW: the directory is being synced by dropbox; and in Meld, Preferences >>> > Encoding tab, "utf8" is entered in the text box. >>> >>> Current work around is running in a terminal: dos2unix /path/to/script.r >>> which strips the ^M's >>> >>> But this just shouldn't be necessary and I'd really appreciate the >>> reflections & advice on how to stop inducing these ^M's ! >>> >>> With thanks, >>> >>> Karl >>> >>> (re)posted here as suggested off topic at SO: >>> http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m >>> >> > -- 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] RFC Optionally handle symbolic links as copies
- Ursprungligt meddelande - > Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23: > > > > > > - Ursprungligt meddelande - > >> Robin Rosenberg writes: > >> > >>> If core.symlinks is set to copy then symbolic links in a git > >>> repository > >>> will be checked out as copies of the file it points to. > >> > >> That all sounds nice on surface when the primary thing you care > >> about is to fetch and check out other people's code and extract it > >> to the working tree, but how well would that work on the checkin > >> side? What happens if I check out a symlink that points at a file > >> (either in-tree or out-of-tree), make some changes that do not > >> involve the symlink, and before I make the commit, an unrelated > >> change is made to the file the symlink is pointing at? > >> > >>> - git status - when do we report a diff. > >>> - After checkout we should probably not > >>> - if the "linked" files change? > >> > >> Yeah, exactly. > >> > >>> - if a change in the copied directory chsnges > >> > >> That, too. > >> > >>> - if a file in the copied diretory is added/removed > >>> - update, should we update the copied structure automatically > >>> when the link target changes > > > > Some of the questions have proposals in the includes test script. A > > little more dangerous than having real symlinks ofcourse, but > > regardless > > of what one does with or without copied symlinks one can make > > mistakes > > and I feel letting Git do the copying is way better than having > > real > > copies in the git repository. Another crappy scm which the users > > are > > converting from does this and it works. A difference to git is that > > it (ok clearcase) makes all files read-only so there are fewer mays > > of making mistakes with the copies. > > > >> I personally do not think this is worth it. It would be very > >> useful > >> on the export/checkout side, so it may make sense to add it to > >> "git > >> archive", though. > > > > It makes sense, but it does not solve the problem at hand. > > > > -- robin > > > > Well, what is the problem at hand? The problem is that I'm converting a repo from clearcase to git and there are lots of symbolic links. Symbolic links in clearcase on Windows is treated as file copy in snapshot views which means that you get a copy of the linked file when you update the view. If the link target changes you can update your view to refersh your copies. > Your commit message begins in present tense as if it described the > current state of git, when in fact it describes what the patch is > about > to achieve. This is confusing enough already, You're right. > I don't see any mention of the purpose, other than "content may be > used", which would be served perfectly by a copy-on-link feature on > the > export side, as mentioned by Junio. Is git-archive|tar an option? I want the copy on checkout. The intent is to change things and then commit. Perhaps I can convince people to let a script copy stuff instead. -- robin -- 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: How to avoid the ^M induced by Meld and Git
On 12/12/12 17:08, Michael J Gruber wrote: Karl Brand venit, vidit, dixit 12.12.2012 16:34: On 12/12/12 15:57, Michael J Gruber wrote: Karl Brand venit, vidit, dixit 11.12.2012 13:33: Esteemed Git users, What i do: 1. Create a script.r using Emacs/ESS. 2. Make some modifications to script.r with the nice diff gui, Meld 3. Commit these modifications using git commit -am "my message" 4. Reopen script.r in Emacs/ESS to continue working. The lines added (&/edited ?) using Meld all end with ^M which i certainly don't want. Lines not added/edited with Meld do NOT end with ^M. What happens if you leave out step 3? If the same happens then Meld is the culprit. (Unless you've set some special options, git does not modify your file on commit, so this can't be git related.) Leaving out step 3. results in exactly the same thing. Thus Git doesn't appear to be responsible for the ^M's. Thanks a lot for your effort on this and my apologies for not taking the care to dissect this more carefully as you suggested. Over to the Meld mailing list... I didn't mean to shy you away ;) Applying recent lessons form StackO'flow :P Could it be that there is a ^M very early in the file (or rather something else which isn't covered by dos2unix) so that Meld thinks it's DOS and inserts line endings as DOS? At least that's what vim would do. If there is i don't find it using Emacs, but Emacs may only show what dos2unix sees... Will post back the Meld insights (here's hoping!) In any case, Meld people over there should know (or get to know) that effect. There are plenty of posts around about these being line endings used for windows which can appear when working on a script under a *nix OS which has previously been edited in a Windows OS. This is not the case here - everything is taking place on Ubuntu 12.04. FWIW: the directory is being synced by dropbox; and in Meld, Preferences > Encoding tab, "utf8" is entered in the text box. Current work around is running in a terminal: dos2unix /path/to/script.r which strips the ^M's But this just shouldn't be necessary and I'd really appreciate the reflections & advice on how to stop inducing these ^M's ! With thanks, Karl (re)posted here as suggested off topic at SO: http://stackoverflow.com/questions/13799631/create-script-r-in-emacs-modify-with-meld-git-commit-reopen-in-emacs-m -- Karl Brand Dept of Cardiology and Dept of Bioinformatics Erasmus MC Dr Molewaterplein 50 3015 GE Rotterdam T +31 (0)10 703 2460 |M +31 (0)642 777 268 |F +31 (0)10 704 4161 -- 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] Documentation/git: add missing info about --git-dir command-line option
The Documentation/git.txt file, in the GIT_DIR environment variable section, did not mentioned that this value can also be set using the --git-dir command line option. --- Documentation/git.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/git.txt b/Documentation/git.txt index e643683..60db292 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -650,6 +650,7 @@ git so take care if using Cogito etc. If the 'GIT_DIR' environment variable is set then it specifies a path to use instead of the default `.git` for the base of the repository. + The '--git-dir' command-line option also sets this value. 'GIT_WORK_TREE':: Set the path to the working tree. The value will not be -- 1.8.0.1.347.gf94c325.dirty -- 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] fetch: ignore wildcarded refspecs that update local symbolic refs
On Tue, Dec 11, 2012 at 5:32 PM, Junio C Hamano wrote: > In a repository cloned from somewhere else, you typically have a > [...] > * This time with minimal tests and an updated log message. Sorry I haven't been reading the list much lately, so I don't know the context which motivated this patch beyond the commit message. But, this message is quite clear. So: Acked-by: Jay Soffian > diff --git a/remote.c b/remote.c > index 04fd9ea..a72748c 100644 > --- a/remote.c > +++ b/remote.c > @@ -1370,6 +1370,16 @@ int branch_merge_matches(struct branch *branch, > return refname_match(branch->merge[i]->src, refname, ref_fetch_rules); > } > > +static int ignore_symref_update(const char *refname) s/ignore_symref_update/is_existing_symref/ ? j. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (bug?) Inconsistent workdir file timestamps after initial clone.
On 11.12.12 23:30, Junio C Hamano wrote: > Marc Branchaud writes: > >> My point is that the initial checkout into an empty working directory should >> create all files with the same timestamp. >> >> Or, to be a bit more precise, whenever git-checkout *creates* files in the >> work dir, *all* the created files should have the *same* timestamp (i.e. the >> current time measured at the start of the checkout's execution, not some >> bizarro other time specified by some arcane heuristic). > > My knee-jerk reaction is that it is insane to do so, but what other > SCM does such a thing? Even "tar xf" wouldn't do that, I think. > ClearCase is doing such a thing. You need to check out a file to make it writable: "cleartool checkout main.c" [hack hack] If you after some hacking don't like your changes at all, you run "cleartool unco main.c" (Undo checkout) (In git we just use "git checkout") While in ClearCase the timestamp of your file jumps back to where it was before the checkout, it gets the current timestamp in git. One consequence is that ClearCase users may wish to use "ClearMake" rather then make. A better make (which records all timestamps somewhere) would be helpful. >>> While not including files that can be rebuilt from the source may be >>> the ideal solution, I've seen projects hide rules to rebuild such a >>> "generated but needs special tools to build" and/or a "generated but >>> normal developers do not have any business rebuilding" file (in your >>> case, Makefile.in) in their Makefiles from the normal targets (like >>> "make all") for this exact reason, when they choose to distribute >>> such files by including in their commits. >> >> I prefer to use the third-party code as-is, without hacking it, to have >> smooth upgrades in the future. > > Then perhaps take the complaints to that third-party upstream, not > 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 > -- 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] submodule: add 'deinit' command
Am 12.12.2012 16:08, schrieb Michael J Gruber: > Jens Lehmann venit, vidit, dixit 04.12.2012 22:48: >> With "git submodule init" the user is able to tell git he cares about one >> or more submodules and wants to have it populated on the next call to "git >> submodule update". But currently there is no easy way he could tell git he >> does not care about a submodule anymore and wants to get rid of his local >> work tree (except he knows a lot about submodule internals and removes the >> "submodule.$name.url" setting from .git/config himself). >> >> Help those users by providing a 'deinit' command. This removes the whole >> submodule. section from .git/config either for the given >> submodule(s) or for all those which have been initialized if none were >> given. Complain only when for a submodule given on the command line the >> url setting can't be found in .git/config. > > Whoaaa, so why not have "git rm" remove everything unless I specify a > file to be removed? Because "git add" doesn't add any file in that case either? > I know I'm exaggerating a bit, but defaulting to "--all" for a > destructive operation seems to be a bit harsh, especially when the > command is targeted at "those" users that you mention. All other submodule commands (except add, which only operates on a single submodule to be) iterate over all submodules if none were explicitly given on the command line. So I made deinit just behave like all the others - and especially init - do. But if people really are surprised by being consistent here I won't argue against adding such a "--all" option, but currently I'm not convinced it is worth it. Especially as I suspect the number of submodule users having customized those in .git/config is not that high ... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: (bug?) Inconsistent workdir file timestamps after initial clone.
> -Original Message- > From: Torsten Bögershausen > Sent: Wednesday, December 12, 2012 12:19 PM > > > > On 11.12.12 23:30, Junio C Hamano wrote: > > Marc Branchaud writes: > > > >> My point is that the initial checkout into an empty working > directory should > >> create all files with the same timestamp. > >> > >> Or, to be a bit more precise, whenever git-checkout *creates* files > in the > >> work dir, *all* the created files should have the *same* timestamp > (i.e. the > >> current time measured at the start of the checkout's execution, not > some > >> bizarro other time specified by some arcane heuristic). > > > > My knee-jerk reaction is that it is insane to do so, but what other > > SCM does such a thing? Even "tar xf" wouldn't do that, I think. > > > > > ClearCase is doing such a thing. > > You need to check out a file to make it writable: > "cleartool checkout main.c" > [hack hack] > If you after some hacking don't like your changes at all, > you run > "cleartool unco main.c" (Undo checkout) > (In git we just use "git checkout") > > While in ClearCase the timestamp of your file jumps back to where > it was before the checkout, it gets the current timestamp in git. I do think that a user preference should decide if git uses metadata timestamps or current timestamp on file operations. I dont think that the current time is proper as a default operation. > > One consequence is that ClearCase users may wish to use "ClearMake" > rather then make. > > A better make (which records all timestamps somewhere) would be > helpful. That is why I always do "make clean" after a rollback. Do you really expect build managers to handle a bi-directional, with regards to time, SDLC? Build managers have worked hard to ensure incremental builds, it is silly to think that they should be re worked. > > >>> While not including files that can be rebuilt from the source may > be > >>> the ideal solution, I've seen projects hide rules to rebuild such a > >>> "generated but needs special tools to build" and/or a "generated > but > >>> normal developers do not have any business rebuilding" file (in > your > >>> case, Makefile.in) in their Makefiles from the normal targets (like > >>> "make all") for this exact reason, when they choose to distribute > >>> such files by including in their commits. > >> > >> I prefer to use the third-party code as-is, without hacking it, to > have > >> smooth upgrades in the future. > > > > Then perhaps take the complaints to that third-party upstream, not > > 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 > > > > -- > 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 smime.p7s Description: S/MIME cryptographic signature
FW: Git log --graph doesn't output color when redirected
Unlike --pretty-format, --graph doesn’t output colors when the git log output is redirected. Tested on Ubuntu 12.04 and msys on Windows 8. Is there a setting somewhere in config to change this? Thanks, Michal -- 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 v7 2/3] submodule update: add --remote for submodule's upstream changes
Thanks for looking after this. On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King wrote: > From: "W. Trevor King" > > The current `update` command incorporates the superproject's gitlinked > SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the > options you use, it may checkout $sha1, rebase the $subsha1 onto > $sha1, or merge $sha1 into $subsha1. This helps you keep up with > changes in the upstream superproject. > > However, it's also useful to stay up to date with changes in the > upstream subproject. Previous workflows for incorporating such > changes include the ungainly: > > $ git submodule foreach 'git checkout $(git config --file > $toplevel/.gitmodules submodule.$name.branch) && git pull' > > With this patch, all of the useful functionality for incorporating > superproject changes can be reused to incorporate upstream subproject > updates. When you specify --remote, the target $sha1 is replaced with > a $sha1 of the submodule's origin/master tracking branch. If you want > to merge a different tracking branch, you can configure the > `submodule..branch` option in `.gitmodules`. You can override > the `.gitmodules` configuration setting for a particular superproject > by configuring the option in that superproject's default configuration > (using the usual configuration hierarchy, e.g. `.git/config`, > `~/.gitconfig`, etc.). > > Previous use of submodule..branch > === > > Because we're adding a new configuration option, it's a good idea to > check if anyone else is already using the option. The foreach-pull > example above was described by Ævar in > > commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f > Author: Ævar Arnfjörð Bjarmason > Date: Fri May 21 16:10:10 2010 + > > git-submodule foreach: Add $toplevel variable > > Gerrit uses the same interpretation for the setting, but because > Gerrit has direct access to the subproject repositories, it updates > the superproject repositories automatically when a subproject changes. > Gerrit also accepts the special value '.', which it expands into the > superproject's branch name. > > Although the --remote functionality is using `submodule..branch` > slightly differently, the effect is the same. The foreach-pull > example uses the option to record the name of the local branch to > checkout before pulls. The tracking branch to be pulled is recorded > in `.git/modules//config`, which was initialized by the module > clone during `submodule add` or `submodule init`. Because the branch > name stored in `submodule..branch` was likely the same as the > branch name used during the initial `submodule add`, the same branch > will be pulled in each workflow. > > Implementation details > == > > In order to ensure a current tracking branch state, `update --remote` > fetches the submodule's remote repository before calculating the > SHA-1. However, I didn't change the logic guarding the existing fetch: > > if test -z "$nofetch" > then > # Run fetch only if $sha1 isn't present or it > # is not reachable from a ref. > (clear_local_git_env; cd "$path" && > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && >test -z "$rev") || git-fetch)) || > die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" > fi > > There will not be a double-fetch, because the new $sha1 determined > after the `--remote` triggered fetch should always exist in the > repository. If it doesn't, it's because some racy process removed it > from the submodule's repository and we *should* be re-fetching. > > Signed-off-by: W. Trevor King > --- > Documentation/config.txt| 7 ++- > Documentation/git-submodule.txt | 25 - > Documentation/gitmodules.txt| 5 + > git-submodule.sh| 22 +- > t/t7406-submodule-update.sh | 31 +++ > 5 files changed, 87 insertions(+), 3 deletions(-) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 11f320b..6f4663c 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -1998,7 +1998,12 @@ submodule..update:: > for a submodule. These variables are initially populated > by 'git submodule init'; edit them to override the > URL and other values found in the `.gitmodules` file. See > - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. > + > +submodule..branch:: > + The remote branch name for a submodule, used by `git submodule > + update --remote`. Set this option to override the value found in > + the `.gitmodules` file. See linkgit:git-submodule[1] and > + linkgit:gitmodules[5] for details. > > submodule..fetchRecurseSubmodules:: > This option can be used to control recursive fetching of this > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt > index b4683bb..
Re: Python extension commands in git - request for policy change
Jeff King writes: > I think there are really two separate use cases to consider: > > 1. Providing snippets of script to Git to get Turing-complete behavior > for existing Git features. For example, selecting commits during a > traversal (e.g., a better "log --grep"), formatting output (e.g., a > better "log --format" or "for-each-ref --format"). > > 2. Writing whole new git commands in a language that is quicker or > easier to develop in than C. > > I think (1) is a good match for lua > > But for (2), you are going to care a lot more about the language and its > ecosystem (because you'll be interacting more with the world outside of > git), and about having bindings to lots of different parts of git > (because you'll want to do more interesting things than just examine a > few data structures). Good summary. We also need to realize that adding a native subcommand written in C has become much easier over time as our internal API has evolved and matured. These days, we still do a whole new command in scripts (and we have whole commands still in scripts) not because "quicker or easier to develop" (that is still true for throw-away experiments) but primarily because that is easier to modify and experiment over time until we find a solid design. Among the more important subcommands that are still scripts, I think "add -i", "repack", "pull", "stash" and possibly "rebase" have interfaces facing to both the end users and to the core part solidified enough that they can now be ported to C. Others either are not important enough or still have rooms to improve the interfaces in either direction that it would still be better to leave them in scripts (e.g. "bisect" with " vs " issue unsettled, "submodule" with "floating" issue unsettled, etc.). -- 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-prompt.sh vs leading white space in __git_ps1()::printf_format
Simon Oosthoek writes: > This removes most of the ambiguities :-) > Ack from me! OK, as this is a low-impact finishing touch for a new feature, I'll fast-track this to 'master' before the final release. 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 0/2] mailmap from blobs
Jeff King writes: > I noticed recently that the GitHub contributions page for git.git did > not seem very accurate. The problem is that while it uses shortlog, it > does not respect .mailmap, because we do not have a working tree from > which to read the .mailmap. > > This series adds a config option analogous to mailmap.file, but which > reads from a blob in the repository (so the obvious thing to set it to > is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you > frequently want to traverse while on unrelated branches). The obvious > alternative is to checkout a temporary file of .mailmap and point > mailmap.file at it, but this is a bit more convenient. Yeah, I think this is sane. Have you considered defaulting to read from HEAD:.mailmap even when this new configuration is not there if core.bare is set? I would imagine that it would be the most convenient and match people's expectations. -- 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 5/5] log: Add --use-mailmap option
Antoine Pelisse writes: > On Tue, Dec 11, 2012 at 11:21 PM, Antoine Pelisse wrote: >> Add the --use-mailmap option to log commands. It allows >> to display names from mailmap file when displaying logs, >> whatever the format used. > > The question is which log commands actually ? > Shouldn't we put the option in revision.c::handle_revision_opt instead ? I was trying to avoid that to make it harder to trigger the "feature" by mistake. The rewriting with mailmap is for human consumption and when we replay the history (e.g. format-patch used as input for am or rebase), we should never be applying it. -- 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 0/2] mailmap from blobs
On Wed, Dec 12, 2012 at 09:54:23AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I noticed recently that the GitHub contributions page for git.git did > > not seem very accurate. The problem is that while it uses shortlog, it > > does not respect .mailmap, because we do not have a working tree from > > which to read the .mailmap. > > > > This series adds a config option analogous to mailmap.file, but which > > reads from a blob in the repository (so the obvious thing to set it to > > is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you > > frequently want to traverse while on unrelated branches). The obvious > > alternative is to checkout a temporary file of .mailmap and point > > mailmap.file at it, but this is a bit more convenient. > > Yeah, I think this is sane. > > Have you considered defaulting to read from HEAD:.mailmap even when > this new configuration is not there if core.bare is set? I would > imagine that it would be the most convenient and match people's > expectations. Yeah, I almost suggested that, but I figured it could wait for the feature to prove itself in the real world before turning it on by default. It _should_ be pretty harmless, though, so I don't mind turning it on by default. -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] git(1): remove a defunct link to "list of authors"
Jeff King writes: > I find the ohloh one a little more informative than the GitHub graph. I > couldn't find any others (Google Code does not seem to have one, > kernel.org and other gitweb sites do not, and I can't think of anywhere > else that hosts a mirror). Then let's do this. -- >8 -- Subject: git(1): show link to contributor summary page We earlier removed a link to list of contributors that pointed to a defunct page; let's use a working one from Ohloh.net to replace it instead. Signed-off-by: Junio C Hamano --- Documentation/git.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git c/Documentation/git.txt w/Documentation/git.txt index e643683..25e2f3a 100644 --- c/Documentation/git.txt +++ w/Documentation/git.txt @@ -869,7 +869,10 @@ Authors --- Git was started by Linus Torvalds, and is currently maintained by Junio C Hamano. Numerous contributions have come from the git mailing list -. If you have a clone of git.git itself, the +. http://www.ohloh.net/p/git/contributors/summary +gives you a more complete list of contributors. + +If you have a clone of git.git itself, the output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you the authors for specific parts of the project. -- 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] index-format.txt: be more liberal on what can represent invalid cache tree
Nguyễn Thái Ngọc Duy writes: > We have been writing -1 as "invalid" since day 1. On that same day we > accept all negative entry counts as "invalid". So in theory all C Git > versions out there would be happy to accept any negative numbers. JGit > seems to do exactly the same. I am of two minds here. The existing code is being more lenient than specified when they read stuff others wrote, but it still adheres to -1 when writing. Allowing random implementations to write random negative values will close the door for us to later update the specification to encode more informatin about these invalid entries by using negative value other than -1 here. I am OK with a reword to say "negative means invalid, and writers should write -1 for invalid entries", but without the latter half, this change is not justified. > diff --git a/Documentation/technical/index-format.txt > b/Documentation/technical/index-format.txt > index 9d25b30..2028a49 100644 > --- a/Documentation/technical/index-format.txt > +++ b/Documentation/technical/index-format.txt > @@ -161,8 +161,8 @@ GIT index format > this span of index as a tree. > >An entry can be in an invalidated state and is represented by having > - -1 in the entry_count field. In this case, there is no object name > - and the next entry starts immediately after the newline. > + a negative number in the entry_count field. In this case, there is no > + object name and the next entry starts immediately after the newline. > >The entries are written out in the top-down, depth-first order. The >first entry represents the root level of the repository, followed by the -- 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 v7 0/3] submodule update: add --remote for submodule's upstream changes
"W. Trevor King" writes: > On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote: >> What branch did you base this series on? > > Every version of this series has been based on v1.8.0. Thanks. There were quite a few changes to git-submodule.sh since then to 'master' and I had to either wiggle the patch or know which exact one 1/3 needs to be applied to in order to allow 2/3 to apply (try applying these three to 'master' yourself---you will likely to see that 2/3 will stop with conflicts). In any case, I ended up applying them by editing the patches, and I should have a good copy in 'pu'. Please double check the result. 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: Fwd: possible Improving diff algoritm
Kevin writes:
> Regularly I notice that the diffs that are provided (through diff, or
> add -p) tend to disconnect changes that belong to each other and
> report lines being changed that are not changed.
>
> An example for this is:
>
> /**
> + * Default parent
> + *
> + * @var int
> + * @access protected
> + * @index
> + */
> +protected $defaultParent;
> +
> +/**
>
> I understand this is a valid view of what is changed, but not a very
> logical view from the point of the user.
>
> I wondered if there is a way to improve this, or would that have other
> consequences.
I think your example shows a case where the end of the pre-context
matches the end of the added text in the hunk, and it appears it may
produce a better result if you shift the hunk up. But I think that
works only half the time. Imagine:
@@ -K,L +M,N @@
}
+void new_function(void)
+{
+ printf("hello, world.\n");
+}
+
void existing_one(void)
{
printf("goodbye, world.\n");
Here the end of the pre-context matches the end of the added lines,
but it will produce worse result if you blindly apply the "shift the
hunk up" trick:
... what was before the } we saw in the precontext ...
+}
+
+void new_function(void)
+{
+ printf("hello, world.\n");
}
void existing_one(void)
So I think with s/Regularly/About half the time/, your observation
above is correct.
I think the reason you perceived this as "Regularly" is that you do
not notice nor appreciate it when things go right (half the time),
but you tend to notice and remember only when a wrong side happened
to have been picked (the other half).
--
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: Fwd: possible Improving diff algoritm
On 12-12-12 01:29 PM, Junio C Hamano wrote: > > Here the end of the pre-context matches the end of the added lines, > but it will produce worse result if you blindly apply the "shift the > hunk up" trick: Yeah. I would not think a blind shift would be appropriate. But I wonder if diff can take whitespace hints about when to shift and when not to. It would still never be perfect but might be more accurate than it is now. Can't imagine it would be any worse. b. signature.asc Description: OpenPGP digital signature
Re: Weird problem with git-submodule.sh
Marc Branchaud writes: > It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to > upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash. Dash has been the default '/bin/sh' for Ubuntu for quite a long time now[1] in spite of repeated reports of compatibility problems[2]. Phil [1] https://wiki.ubuntu.com/DashAsBinSh [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 -- 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/PATCH] ignoring a fetch that overwrites local symref
On Tue, Dec 11, 2012 at 11:46 AM, Junio C Hamano wrote: > This is a companion to an ancient thread > > http://thread.gmane.org/gmane.comp.version-control.git/145311/focus=145337 > > in which an error was dealt with while pushing into a "mirror" > repository that has a symbolic reference refs/remotes/origin/HEAD > pointing at refs/remotes/origin/master with "git push --mirror". > The issue was that the receiving end was told to update origin/HEAD > and origin/master separately; if origin/HEAD is updated, that would > update origin/master at the same time, and then when attempting to > update origin/master, it would notice that it no longer has the > expected old value and barf. After the series, we started ignoring > such pushes to HEAD on the receiving end. > > But you can suffer from a similar issue transferring objects in the > opposite direction. If you run "fetch --mirror" in to such a > "mirror" repository, the other side would advertise both 'master' > and 'HEAD' under refs/remotes/origin/ hierarchy, and refs/*:refs/* > wildcard would try to grab both of them. > > Work it around by noticing a wildcard match that attempts to update > a local symbolic ref and ignoring it. At what point should we just support symrefs on the protocol? :-( -- 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: Fwd: possible Improving diff algoritm
Yeah, I didn't mention it, but I didn't think it was doing this wrong
in a systematic way. I only wondered if there was some kind of
heuristic that could improve the cases where it goes wrong, without
affecting the cases where it would do it right.
I know this is not an easy problem, lest it would already been fixed.
On Wed, Dec 12, 2012 at 7:29 PM, Junio C Hamano wrote:
> Kevin writes:
>
>> Regularly I notice that the diffs that are provided (through diff, or
>> add -p) tend to disconnect changes that belong to each other and
>> report lines being changed that are not changed.
>>
>> An example for this is:
>>
>> /**
>> + * Default parent
>> + *
>> + * @var int
>> + * @access protected
>> + * @index
>> + */
>> +protected $defaultParent;
>> +
>> +/**
>>
>> I understand this is a valid view of what is changed, but not a very
>> logical view from the point of the user.
>>
>> I wondered if there is a way to improve this, or would that have other
>> consequences.
>
> I think your example shows a case where the end of the pre-context
> matches the end of the added text in the hunk, and it appears it may
> produce a better result if you shift the hunk up. But I think that
> works only half the time. Imagine:
>
>@@ -K,L +M,N @@
> }
>
>+void new_function(void)
>+{
>+ printf("hello, world.\n");
>+}
>+
> void existing_one(void)
> {
> printf("goodbye, world.\n");
>
> Here the end of the pre-context matches the end of the added lines,
> but it will produce worse result if you blindly apply the "shift the
> hunk up" trick:
>
> ... what was before the } we saw in the precontext ...
>+}
>+
>+void new_function(void)
>+{
>+ printf("hello, world.\n");
> }
>
> void existing_one(void)
>
> So I think with s/Regularly/About half the time/, your observation
> above is correct.
>
> I think the reason you perceived this as "Regularly" is that you do
> not notice nor appreciate it when things go right (half the time),
> but you tend to notice and remember only when a wrong side happened
> to have been picked (the other half).
--
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] submodule: add 'deinit' command
Jens Lehmann writes: > Especially as I suspect the number of submodule users having > customized those in .git/config is not that high ... I thought the point of "deinit" was to say "I am not interested in having a checkout of these submodules in my working tree anymore". The user could do "rm -fr submodule && mkdir submodule" to remove it locally and keep "diff" and "status" from noticing the removal, but the primary reason the user needs an explicit "deinit" is because many subcommands of "git submodule" are documented to operate on all submodules that have been "init"ed when given no explicit submodule names [*1*]. Your "deinit" is documented not to actually remove the submodule checkout, but that very much goes against my intuition. What is the justification behind that choice? "We'll remove the configuration, you remove the tree yourself" will invite the mistake of running "git rm" on it, which you wanted to avoid with the addition to the "git rm" documentation, no? [Footnote] *1* In reality, the code looks at presense of .git in the submodule path to decide if it has been "init"ed (cf. cmd_update), but this implementation of "deinit" does not seem to cause that .git to be removed, leaving the submodule in "init"ed state from these other command's perspective. -- 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] Documentation/git: add missing info about --git-dir command-line option
Manlio Perillo writes: > The Documentation/git.txt file, in the GIT_DIR environment variable > section, did not mentioned that this value can also be set using the > --git-dir command line option. > --- s/mentioned/mention/; Also it may help to say Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), somewhere in the description. Please sign-off your patch (see Documentation/SubmittingPatches). Thanks. > Documentation/git.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/git.txt b/Documentation/git.txt > index e643683..60db292 100644 > --- a/Documentation/git.txt > +++ b/Documentation/git.txt > @@ -650,6 +650,7 @@ git so take care if using Cogito etc. > If the 'GIT_DIR' environment variable is set then it > specifies a path to use instead of the default `.git` > for the base of the repository. > + The '--git-dir' command-line option also sets this value. > 'GIT_WORK_TREE':: > Set the path to the working tree. The value will not be -- 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/PATCH] ignoring a fetch that overwrites local symref
Shawn Pearce writes: >> Work it around by noticing a wildcard match that attempts to update >> a local symbolic ref and ignoring it. > > At what point should we just support symrefs on the protocol? :-( I think it is entirely an orthogonal matter. When we learn that the other side now has this ref as a symref pointing to this other ref, an update of the local ref on the RHS of the refspec that has such a symref on its LHS will not be using the current codepath to call update_ref() to write the object name thru an existing symref. -- 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: Weird problem with git-submodule.sh
Phil Hord writes: > Marc Branchaud writes: >> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to >> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash. > > Dash has been the default '/bin/sh' for Ubuntu for quite a long time > now[1] in spite of repeated reports of compatibility problems[2]. Wasn't the ancestry more like BSD ash (buggy) came before dash and Marc is running a BSD ash decendant that shared common ancestor with, not a decendant of, dash? In any case, I do not think that is relevant; does does not seem to have this IFS bug. > [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 None of the ones listed seems to me a bug. Rather, I see it as a sign that the reporter does not know POSIX shell well and only learned his/her shell through bash. -- 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 v7 2/3] submodule update: add --remote for submodule's upstream changes
Phil Hord writes:
>> + if test -n "$remote"
>> + then
>> + if test -z "$nofetch"
>> + then
>> + # Fetch remote before determining tracking
>> $sha1
>> + (clear_local_git_env; cd "$sm_path" &&
>> git-fetch) ||
>
> You should 'git fetch $remote_name' here, and of course, initialize
> remote_name before this. But how can we know the remote_name in the
> first place? Is it safe to assume the submodule remote names will
> match those in the superproject?
>
>> + die "$(eval_gettext "Unable to fetch in
>> submodule path '\$sm_path'")"
>> + fi
>> + remote_name=$(get_default_remote)
>
> This get_default_remote finds the remote for the remote-tracking
> branch for HEAD in the superproject. It is possible that HEAD !=
> $branch, so we have very few clues to go on here to get a more
> reasonable answer, so I do not have any good suggestions to improve
> this.
>
> One option would be to find the remote given for
> submodule."$branch".merge, but this would suppose there is some
> remote-tracking branch configured in the submodule, and that is not
> likely to be the case.
>
>> + sha1=$(clear_local_git_env; cd "$sm_path" &&
>> + git rev-parse --verify
>> "${remote_name}/${branch}") ||
>
> This does assume the submodule remote names will match those in the
> superproject. Is this safe?
All good points. Thanks for reviewing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
Yann Dirson writes: > In this respect, they seem to be > lacking a few features, when compared to "replace" refs, but they have > different > uses, ... Not reallyl; grafts were old hack whose use is still supported with its original limitations; replace is meant to replace all uses of grafts while removing grafts' largest warts. -- 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] RFC Optionally handle symbolic links as copies
Robin Rosenberg writes: > I want the copy on checkout. The intent is to change things and > then commit. That largely depends on what purpose each symlink is used for in the project. Suppose you have a symlink A and another symlink X in the project, where A points at another path B inside the working tree, and X points at a path outside, say, /etc/motd. Upon checkout, you make regular files A and X that store the contents of the files they point at, and then you edit A and X. Now, what should happen on the next "git add A X"? * Perhaps it (or any step before "git add", or something even outside git) should notice that you modified A that is supposed to represent a copy of B but their contents have drifted. It should raise a red flag, or take a remedial action, no? * Perhaps it should copy the updated contents in A to B and run "git add" on that one instead, without changing anything else? * Imagine a project with many template files B, C, ..., where A points at "the default template". You may be designating a different template file as the new default. On a symlink-capable system you would just do "rm -f A && ln -s C A", but because you chose to make a copy of B and store it as a regular file in A, a natural way to update it may be to do "cp C A". Would you find another file C in the working tree that may be different from B that has the same contents as A, and update the symbolic link A to point at C instead? Do so only with the contents of A and all the other files in the working tree? What if there is another template file identical to C? I didn't even touched the cases where you have to deal with your updates to X. This is looking more and more outside the scope of Git to me. -- 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-prompt.sh vs leading white space in __git_ps1()::printf_format
On 12/12/12 18:50, Junio C Hamano wrote: > Simon Oosthoek writes: > >> This removes most of the ambiguities :-) >> Ack from me! > > OK, as this is a low-impact finishing touch for a new feature, I'll > fast-track this to 'master' before the final release. > Ok, wonderful! BTW, I tried the thing I mentioned and it was safe to do: PS1='blabla$(__git_ps1 x y)blabla' will not eat your prompt, although I'd recommend putting something useful instead of blabla ;-) Cheers Simon -- 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: Fwd: possible Improving diff algoritm
Junio C Hamano writes: > Kevin writes: > >> Regularly I notice that the diffs that are provided (through diff, or >> add -p) tend to disconnect changes that belong to each other and >> report lines being changed that are not changed. >> >> An example for this is: >> >> /** >> + * Default parent >> + * >> + * @var int >> + * @access protected >> + * @index >> + */ >> +protected $defaultParent; >> + >> +/** >> >> I understand this is a valid view of what is changed, but not a very >> logical view from the point of the user. >> >> I wondered if there is a way to improve this, or would that have other >> consequences. I forgot to mention consequences. Changing it obviously changes the shape of the diff, hence changes the patch id. Anything that caches output from "git cherry" to match up "identical patches" will need to discard and repopulate its cache. Your "rerere" database will go stale. Also "kup" tool used at k.org allows an uploader to pretend to upload an incremental diff between two known commits by only sending the GPG signature of the diff the uploader generates. The actual diff is generated on the k.org machine locally and deposited next to the GPG signature file, with the expectation that the signture matches the diff. Changing the output from diff between two versions will break the optimization and force the uploader to upload the diff over the wire. -- 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: Fwd: possible Improving diff algoritm
> So I think with s/Regularly/About half the time/, your observation > above is correct. > > I think the reason you perceived this as "Regularly" is that you do > not notice nor appreciate it when things go right (half the time), > but you tend to notice and remember only when a wrong side happened > to have been picked (the other half). Is there a reason why picking among the choices in a sliding window must be contents neutral? I see these "illogical" (== stylistically not matching user intent) diffs quite often. C comments (as in the example given) and #ifdef blocks are typical cases. Purely anecdotically, I have seen more trouble applying "illogical" diffs than I would have expected from the corresponding "logical" diffs. Morten -- 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: Fwd: possible Improving diff algoritm
Morten Welinder writes: > Is there a reason why picking among the choices in a sliding window > must be contents neutral? Sorry, you might be getting at something interesting but I do not understand the question. I have no idea what you mean by "contents neutral". Picking between these two choices /** +/** + * Default parent + * Default parent + * + * + * @var int + * @var int + * @access protected+ * @access protected + * @index + * @index + */ + */ +protected $defaultParent; +protected $defaultParent; ++ +/** /** would not affect the correctness of the patch. You may pick whatever you deem the most desirable, but your answer must be a correct patch (the definition of "correct" here is "applying that patch to the preimage produces the intended postimage"). And I think if you inserted a block of text B after a context C where the tail of B matches the tail of C like the above, you can shift what you treat as "inserted" up and still come up with a correct patch. The output being "a correct patch" is not the only thing we need to consider, though, as I mentioned in another response to Kevin regarding the "consequences". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
On Tue, Nov 27, 2012 at 5:03 PM, Max Horn wrote: > index 5ce4cda..9a7e583 100644 > --- a/Documentation/git-remote-helpers.txt > +++ b/Documentation/git-remote-helpers.txt > @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', > 'git-remote-https', > 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities > 'fetch', 'option', and 'push'. > > +INVOCATION > +-- > + > +Remote helper programs are invoked with one or (optionally) two > +arguments. The first argument specifies a remote repository as in git; > +it is either the name of a configured remote or a URL. The second > +argument specifies a URL; it is usually of the form > +'://', but any arbitrary string is possible. > +The 'GIT_DIR' environment variable is set up for the remote helper > +and can be used to determine where to store additional data or from > +which directory to invoke auxiliary git commands. > + > +When git encounters a URL of the form '://', where > +'' is a protocol that it cannot handle natively, it > +automatically invokes 'git remote-' with the full URL as > +the second argument. If such a URL is encountered directly on the > +command line, the first argument is the same as the second, and if it > +is encountered in a configured remote, the first argument is the name > +of that remote. Maybe it's worth mentioning that if the alias of the remote is not specified, the URL is used instead. > +A URL of the form '::' explicitly instructs git to > +invoke 'git remote-' with '' as the second > +argument. If such a URL is encountered directly on the command line, > +the first argument is '', and if it is encountered in a > +configured remote, the first argument is the name of that remote. > + > +Additionally, when a configured remote has 'remote..vcs' set to > +'', git explicitly invokes 'git remote-' with > +'' as the first argument. If set, the second argument is > +'remote..url'; otherwise, the second argument is omitted. I find all this text a bit confusing. First argument, second argument, etc. Personally, I would describe everything in the terms of alias (1st arg), and URL (2nd arg). -- Felipe Contreras -- 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 0/6] Improve remote helper documentation
On Fri, Dec 7, 2012 at 1:09 PM, Junio C Hamano wrote: > Max Horn writes: > >> Various remote helper capabilities and commands were not >> documented, in particular 'export', or documented in a misleading >> way (e.g. 'for-push' was listed as a ref attribute understood by >> git, which is not the case). This patch series changes that, and >> also address some other things in the remote helper documentation >> that I found jarring when reading through it. >> >> Note that the description of export and (im|ex)port-marks probably can be >> improved, and I hope that somebody who knows more about them >> than me and/or is better at writing documentation will do just that. >> But I felt it was better to provide something than to do nothing >> and only complain, as I did previously on this subject ;-). > > A second ping to people who have touched transport-helper.c, > remote-testsvn.c, git-remote-testgit, and contrib/remote-helpers/ in > the past 18 months for comments. I've re-read the documentation > updates myself and didn't find anything majorly objectionable. > > Except for a minor nit in 6/6; I think "defined options" should be > "defined attributes". I think the wording in 1/6 can be improved. Other than that I don't have any comments, what I'm familiar with looks good to me. -- Felipe Contreras -- 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] submodule: add 'deinit' command
Am 12.12.2012 20:32, schrieb Junio C Hamano: > Jens Lehmann writes: > >> Especially as I suspect the number of submodule users having >> customized those in .git/config is not that high ... > > I thought the point of "deinit" was to say "I am not interested in > having a checkout of these submodules in my working tree anymore". Yes. (But I'm not sure users expect that command to also remove the work tree) > The user could do "rm -fr submodule && mkdir submodule" to remove it > locally and keep "diff" and "status" from noticing the removal, but > the primary reason the user needs an explicit "deinit" is because > many subcommands of "git submodule" are documented to operate on all > submodules that have been "init"ed when given no explicit submodule > names [*1*]. The real reason we need deinit is that the next run of "submodule update" will otherwise happily recreate the submodule checkout you just removed as long as it finds the url setting in .git/config. > Your "deinit" is documented not to actually remove the submodule > checkout, but that very much goes against my intuition. What is the > justification behind that choice? I thought it should match what "submodule init" does, which is to do nothing to the work tree until the next "submodule update" is run. (But I agree that analogy is somewhat flawed until we teach "update" to remove a deinitialized submodule - or maybe teach it the --deinit option which could do both). On the other hand with current git submodule work trees always stay around anyway until you remove them by hand (e.g. when you switch to a branch that doesn't have it), so I'm not sure what would surprise people more here. So I just left the work tree unchanged. > "We'll remove the configuration, > you remove the tree yourself" will invite the mistake of running > "git rm" on it, which you wanted to avoid with the addition to the > "git rm" documentation, no? I think that'll happen only if git would remind them that they still have a populated work tree, which I believe it shouldn't. > [Footnote] > > *1* In reality, the code looks at presense of .git in the submodule > path to decide if it has been "init"ed (cf. cmd_update), but this > implementation of "deinit" does not seem to cause that .git to be > removed, leaving the submodule in "init"ed state from these other > command's perspective. Nope, cmd_update() checks first if the url is found in .git/config and skips the submodule if not. I rechecked and only "summary" and "foreach" still recurse into a deinitialized submodule, which they shouldn't. But a quick test shows that "git status" and "git diff" also still inspect a deinitialized submodule, so there's some work left to do to handle the case where the work tree is not removed. So unless people agree that deinit should also remove the work tree I'll prepare some patches teaching all git commands to consistently ignore deinitialized submodules. Opinions? -- 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] completion: add option --recurse-submodules to "git push"
On Fri, Dec 7, 2012 at 11:21 AM, Junio C Hamano wrote:
> Steffen Jaeckel writes:
>
>> Signed-off-by: Steffen Jaeckel
>> ---
>> contrib/completion/git-completion.bash | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index 0b77eb1..5b4d2e1 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1434,6 +1434,10 @@ _git_pull ()
>> __git_complete_remote_or_refspec
>> }
>>
>> +__git_push_recurse_submodules_options="
>> + check on-demand
>> +"
>
> Most of the existing completion functions do not seem to define
> separate variables like this; instead, they literally embed their
> choices at the point of use.
>
> Is it expected that the same set of choices will appear in the
> completion of many other subcommand options? [jc: Cc'ed Heiko so
> that we can sanity check the answer to this question]. If so, the
> variable may be justified; otherwise, not.
>
>> _git_push ()
>> {
>> case "$prev" in
>> @@ -1446,10 +1450,15 @@ _git_push ()
>> __gitcomp_nl "$(__git_remotes)" "" "${cur##--repo=}"
>> return
>> ;;
>> + --recurse-submodules=*)
>> + __gitcomp "$__git_push_recurse_submodules_options" ""
>> "${cur##--recurse-submodules=}"
>> + return
>> + ;;
>
> Owners of the completion script, does this look reasonable?
> [jc: Cc'ed Felipe for this]
>
> This is a tangent, but why is it a double-hash "##" not a
> single-hash "#", other than "because all others use ##"?
Seems OK by me, but I agree, the options should be inline.
--
Felipe Contreras
--
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] If `egrep` is aliased, temporary disable it in bash.completion
On Thu, Dec 6, 2012 at 12:01 PM, Junio C Hamano wrote: > Adam Tkac writes: > >> On Thu, Nov 29, 2012 at 09:33:53AM -0800, Junio C Hamano wrote: >> ... >>> IOW, something along this line? >> >> This won't work, unfortunately, because shopt settings aren't inherited by >> subshell (and for example egrep is called in subshell). >> >> I discussed this issue with colleagues and we found basically two "fixes": >> >> 1. Tell people "do not use aliases which breaks completion script" >> 2. Prefix all commands with "command", i.e. `command egrep` etc. >> >> In my opinion "2." is better long time solution, what do you think? > > Judging from what is in /etc/bash_completion.d/ (I am on Debian), I > think that others are divided. Many but not all prefix "command" in > front of "grep", but nobody does the same for "egrep", "cut", "tr", > "sed", etc. > > If it were up to me, I would say we pick #1, but I cc'ed the people > who have been more involved in our bash-completion code because they > are in a better position to argue between the two than I am. Why not both? I do prefer #1, but I don't see why we wouldn't prefix some commonly problematic ones (\egrep), prefixing all of them seems overkill for me. -- Felipe Contreras -- 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] submodule: add 'deinit' command
Jens Lehmann writes: > So unless people agree that deinit should also remove the work > tree I'll prepare some patches teaching all git commands to > consistently ignore deinitialized submodules. Opinions? While I agree that consistency is good, "deinit" that does not remove the working tree of the submodule the user explicitly said he no longer wants to have the checkout for is a bug, and I think these two are orthogonal issues. In other words, "Ignore deinitialized submodules even when an earlier bug in deinit failed to remove the working tree" is a robustness issue for the other recursing commands, not an excuse for "deinit" to have such a bug in the first place, I think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
Andrew Ardill writes: > On 13 December 2012 04:49, Junio C Hamano wrote: >> "bisect" with " vs >> " issue unsettled > > Would you want to see this issue resolved in-script before a porting > attempt was started? Honestly, I do not care too much either way, but for the people who want to work either on the rewrite-to-C or on the semantics issue, it would be easier to manage it that way. And that "issue resolved in-script" does not have to be "implemented in-script". The resolution could be to declare that it is not worth it and a promise to call the two states and with no other names. It would give a semantics for the rewriters-to-C can start working on that is stable enough ;-). -- 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 v7 0/3] submodule update: add --remote for submodule's upstream changes
On Wed, Dec 12, 2012 at 10:19:32AM -0800, Junio C Hamano wrote: > In any case, I ended up applying them by editing the patches, and I > should have a good copy in 'pu'. Please double check the result. Your 'pu' branch looks good to me. Most of the differences with my initial patch are due to irrelevant context lines. I would change patch 3 (commit 2f507f9a in 'pu') to use git config -f .gitmodules submodule."$sm_name".branch "$branch" ^ instead of git config -f .gitmodules submodule."$sm_path".branch "$branch" ^ to match the nearby changes from 73b0898d. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
On 12.12.2012, at 23:14, Felipe Contreras wrote: > On Tue, Nov 27, 2012 at 5:03 PM, Max Horn wrote: > >> index 5ce4cda..9a7e583 100644 >> --- a/Documentation/git-remote-helpers.txt >> +++ b/Documentation/git-remote-helpers.txt >> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', >> 'git-remote-https', >> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities >> 'fetch', 'option', and 'push'. >> >> +INVOCATION >> +-- >> + >> +Remote helper programs are invoked with one or (optionally) two >> +arguments. The first argument specifies a remote repository as in git; >> +it is either the name of a configured remote or a URL. The second >> +argument specifies a URL; it is usually of the form >> +'://', but any arbitrary string is possible. >> +The 'GIT_DIR' environment variable is set up for the remote helper >> +and can be used to determine where to store additional data or from >> +which directory to invoke auxiliary git commands. >> + >> +When git encounters a URL of the form '://', where >> +'' is a protocol that it cannot handle natively, it >> +automatically invokes 'git remote-' with the full URL as >> +the second argument. If such a URL is encountered directly on the >> +command line, the first argument is the same as the second, and if it >> +is encountered in a configured remote, the first argument is the name >> +of that remote. > > Maybe it's worth mentioning that if the alias of the remote is not > specified, the URL is used instead. Worth a thought yeah -- but beyond the scope of this patch: I merely moved this text around, but did not touch it otherwise. > >> +A URL of the form '::' explicitly instructs git to >> +invoke 'git remote-' with '' as the second >> +argument. If such a URL is encountered directly on the command line, >> +the first argument is '', and if it is encountered in a >> +configured remote, the first argument is the name of that remote. >> + >> +Additionally, when a configured remote has 'remote..vcs' set to >> +'', git explicitly invokes 'git remote-' with >> +'' as the first argument. If set, the second argument is >> +'remote..url'; otherwise, the second argument is omitted. > > I find all this text a bit confusing. First argument, second argument, > etc. Personally, I would describe everything in the terms of alias > (1st arg), and URL (2nd arg). Yeah, I also thought about that, but as above, deliberately did not touch it here, but only moved it around. I'll be happy to revisit this on a future date, though. Thanks for the feedback, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Hardcoded python and install on solaris
Hi; When compiling git-1.8.0.2 on a moderately old OpenIndiana machine, I had to install a few things (m4, autoconf, coreutils, xz, python). Even though I started the configuration fresh (make distclean; configure), the makefile still wanted to use /usr/bin/python (instead of /usr/local/bin/python) and /usr/usb/install (instead of /usr/local/bin/install). Thanks for a great SCM! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
On Wed, Dec 12, 2012 at 4:58 PM, Max Horn wrote: > > On 12.12.2012, at 23:14, Felipe Contreras wrote: > >> On Tue, Nov 27, 2012 at 5:03 PM, Max Horn wrote: >> >>> index 5ce4cda..9a7e583 100644 >>> --- a/Documentation/git-remote-helpers.txt >>> +++ b/Documentation/git-remote-helpers.txt >>> @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', >>> 'git-remote-https', >>> 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities >>> 'fetch', 'option', and 'push'. >>> >>> +INVOCATION >>> +-- >>> + >>> +Remote helper programs are invoked with one or (optionally) two >>> +arguments. The first argument specifies a remote repository as in git; >>> +it is either the name of a configured remote or a URL. The second >>> +argument specifies a URL; it is usually of the form >>> +'://', but any arbitrary string is possible. >>> +The 'GIT_DIR' environment variable is set up for the remote helper >>> +and can be used to determine where to store additional data or from >>> +which directory to invoke auxiliary git commands. >>> + >>> +When git encounters a URL of the form '://', where >>> +'' is a protocol that it cannot handle natively, it >>> +automatically invokes 'git remote-' with the full URL as >>> +the second argument. If such a URL is encountered directly on the >>> +command line, the first argument is the same as the second, and if it >>> +is encountered in a configured remote, the first argument is the name >>> +of that remote. >> >> Maybe it's worth mentioning that if the alias of the remote is not >> specified, the URL is used instead. > > Worth a thought yeah -- but beyond the scope of this patch: I merely moved > this text around, but did not touch it otherwise. > >> >>> +A URL of the form '::' explicitly instructs git to >>> +invoke 'git remote-' with '' as the second >>> +argument. If such a URL is encountered directly on the command line, >>> +the first argument is '', and if it is encountered in a >>> +configured remote, the first argument is the name of that remote. >>> + >>> +Additionally, when a configured remote has 'remote..vcs' set to >>> +'', git explicitly invokes 'git remote-' with >>> +'' as the first argument. If set, the second argument is >>> +'remote..url'; otherwise, the second argument is omitted. >> >> I find all this text a bit confusing. First argument, second argument, >> etc. Personally, I would describe everything in the terms of alias >> (1st arg), and URL (2nd arg). > > Yeah, I also thought about that, but as above, deliberately did not touch it > here, but only moved it around. I'll be happy to revisit this on a future > date, though. Oh, in that case it's fine, but I would have named it "move invocation before input format", or something that has *move*, or *shuffle*. -- Felipe Contreras -- 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 v7 2/3] submodule update: add --remote for submodule's upstream changes
On Wed, Dec 12, 2012 at 12:43:23PM -0500, Phil Hord wrote:
> On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King wrote:
> > diff --git a/Documentation/git-submodule.txt
> > b/Documentation/git-submodule.txt
> > …
> > +--remote::
> > [snip some --remote documentation]
> > +In order to ensure a current tracking branch state, `update --remote`
> > +fetches the submodule's remote repository before calculating the
> > +SHA-1. This makes `submodule update --remote --merge` similar to
> > +running `git pull` in the submodule. If you don't want to fetch (for
> > +something closer to `git merge`), you should use `submodule update
> > +--remote --no-fetch --merge`.
>
> I assume the same can be said for 'submodue update --remote --rebase',
> right?
Yes.
> I wonder if this can be made merge/rebase-agnostic. Is it still
> true if I word it like this?:
>
>In order to ensure a current tracking branch state, `update --remote`
>fetches the submodule's remote repository before calculating the
>SHA-1. If you don't want to fetch, you should use `submodule update
> --remote --no-fetch`.
Works for me. Will change in v8 (which I'll base on 'master').
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index f969f28..1395079 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> > USAGE="[--quiet] add [-b branch] [-f|--force] [--reference ]
> > [--] []
> > or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
> > or: $dashless [--quiet] init [--] [...]
> > - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
> > [--rebase] [--reference ] [--merge] [--recursive] [--]
> > [...]
> > + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
> > [-f|--force] [--rebase] [--reference ] [--merge] [--recursive]
> > [--] [...]
> > +ges
>
> I think there's an unintentionally added line here with "ges".
That is embarrassing :p. Will fix in v8.
> > + if test -n "$remote"
> > + then
> > + if test -z "$nofetch"
> > + then
> > + # Fetch remote before determining tracking
> > $sha1
> > + (clear_local_git_env; cd "$sm_path" &&
> > git-fetch) ||
>
> You should 'git fetch $remote_name' here, and of course, initialize
> remote_name before this. But how can we know the remote_name in the
> first place? Is it safe to assume the submodule remote names will
> match those in the superproject?
The other git-fetch call from git-submodule.sh is also bare (i.e. no
specified remote). When the remote needs to be specified, other
portions of git-submodule.sh use $(get_default_remote), which is (I
think) what the user should expect. v6 of this series had a
configurable remote name, but Junio wasn't keen on the additional
configuration option. I don't really mind either way.
>
> > + die "$(eval_gettext "Unable to fetch in
> > submodule path '\$sm_path'")"
> > + fi
> > + remote_name=$(get_default_remote)
>
> This get_default_remote finds the remote for the remote-tracking
> branch for HEAD in the superproject. It is possible that HEAD !=
> $branch, so we have very few clues to go on here to get a more
> reasonable answer, so I do not have any good suggestions to improve
> this.
For detached HEADs, get_default_remote should fall back to 'origin',
which seems sane. If the user wants a different default, they've
likely checkout out a branch in the submodule, setup that branch's
remote, and will be using --merge or --rebase. If anyone expects
users who will be using detached heads to *want* to specify a
different remote than 'origin', that would be a good argument for
reinstating my submodule..remote patch from v6.
> > + sha1=$(clear_local_git_env; cd "$sm_path" &&
> > + git rev-parse --verify
> > "${remote_name}/${branch}") ||
>
> This does assume the submodule remote names will match those in the
> superproject. Is this safe?
Another good catch. I should be calling get_default_remote after
cd-ing into the submodule. Will change in v8.
Thanks for the feedback :)
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
Max Horn writes: > Worth a thought yeah -- but beyond the scope of this patch: I > merely moved this text around, but did not touch it otherwise. > ... > Yeah, I also thought about that, but as above, deliberately did > not touch it here, but only moved it around. I'll be happy to > revisit this on a future date, though. That sounds like a sensible approach. So what's been cooking on 'next' is OK, it seems. As this is merely a doc update, I may be tempted to merge it down to the 'master' branch before the next -rc. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
On 13.12.2012, at 00:00, Felipe Contreras wrote: [...] >>> >>> I find all this text a bit confusing. First argument, second argument, >>> etc. Personally, I would describe everything in the terms of alias >>> (1st arg), and URL (2nd arg). >> >> Yeah, I also thought about that, but as above, deliberately did not touch it >> here, but only moved it around. I'll be happy to revisit this on a future >> date, though. > > Oh, in that case it's fine, but I would have named it "move invocation > before input format", or something that has *move*, or *shuffle*. Agreed. It explicit says move in the body of the commit message, but not in the summary line.. That would be an improvement, I gueess. Junio, if you want, feel free to reword the summary line of the patch accordingly, e.g. changing it from git-remote-helpers.txt: document invocation before input format to something like git-remote-helpers.txt: move 'invocation' section before 'input format' Of course I can also re-roll, if that is necessary/preferred. Cheers, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Hardcoded python and install on solaris
"P Fudd" writes: > When compiling git-1.8.0.2 on a moderately old OpenIndiana machine, I had > to install a few things (m4, autoconf, coreutils, xz, python). > > Even though I started the configuration fresh (make distclean; configure), > the makefile still wanted to use /usr/bin/python (instead of > /usr/local/bin/python) and /usr/usb/install (instead of > /usr/local/bin/install). You need to specify PYTHON_PATH on the build command line, something like: $ make PYTHON_PATH=/usr/local/bin/python $ make PYTHON_PATH=/usr/local/bin/python install We don't really rely on configure, and it sometimes is the case where ./configure output does not know some knobs you can tweak in the Makefile, but this one is not. I think you can use --with-python=/usr/local/bin/python when running the ./configure script. ./configure --help may tell you more about what you can tweak. -- 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] submodule: add 'deinit' command
On Wed, Dec 12, 2012 at 02:34:47PM -0800, Junio C Hamano wrote: > Jens Lehmann writes: > > > So unless people agree that deinit should also remove the work > > tree I'll prepare some patches teaching all git commands to > > consistently ignore deinitialized submodules. Opinions? > > While I agree that consistency is good, "deinit" that does not > remove the working tree of the submodule the user explicitly said he > no longer wants to have the checkout for is a bug, and I think these > two are orthogonal issues. Should `deinit` remove the submodule checkout, replace it with the original gitlink, and clear the .git/config information then? That would restore the user to the state they'd be in if they were never interested in the submodule. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
Max Horn writes: > Of course I can also re-roll, if that is necessary/preferred. No, you can't. The topic has been cooking in 'next' for some days now already. -- 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: Weird problem with git-submodule.sh
On Wed, Dec 12, 2012 at 2:44 PM, Junio C Hamano wrote: > Phil Hord writes: >> [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 > > None of the ones listed seems to me a bug. Rather, I see it as a > sign that the reporter does not know POSIX shell well and only > learned his/her shell through bash. You're probably right. I run into enough problems with 'dash' as /bin/sh that I always have to disable it early after a new install. In particular, an third-party embedded linux kernel build script fails in cryptic ways with dash. But it is probably the third-party's poor understanding of POSIX shell which is to blame. I think git's 'make test' previously would also fail under dash, but it seems to be happy with it atm. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
On 13.12.2012, at 00:13, Junio C Hamano wrote: > Max Horn writes: > >> Of course I can also re-roll, if that is necessary/preferred. > > No, you can't. The topic has been cooking in 'next' for some days > now already. Ah, right, I somehow missed that :-/. Well, I guess it's at most a tiny minor cleanup anyway and thus not important :-). Cheers, Max-- 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: Fwd: possible Improving diff algoritm
I must say it is _quite_ helpfull having the diffs well done (natural diffs as here named), just because when you want to review a patch on the fly, this sort of things are annoying. I just wanted to say my opinion. No idea on how to fix that, nor why does it happen. Javier Domingo 2012/12/12 Andrew Ardill : > On 13 December 2012 08:53, Junio C Hamano wrote: >> The output being "a correct patch" is not the only thing we need to >> consider, though, as I mentioned in another response to Kevin >> regarding the "consequences". > > The main benefit of picking a more 'natural' diff is a usability one. > I know that when a chunk begins and ends one line after the logical > break point (typically with braces in my experience) mentally parsing > the diff becomes significantly harder. If there was a way to teach git > where it should try and break out a chunk (potentially per filetype?) > this is a good thing for readability, and I think would outweigh any > temporary pain with regards to cached rerere and diff data. > > 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 -- 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] submodule: add 'deinit' command
"W. Trevor King" writes: > Should `deinit` remove the submodule checkout, replace it with the > original gitlink, and clear the .git/config information then? That > would restore the user to the state they'd be in if they were never > interested in the submodule. AFAIU, "restore the user to the state" is the goal. I am not sure what you meant by "replace it with the original gitlink", though. A checkout with a submodule that the user is not interested in would have an empty directory at that path, no? -- 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: Fwd: possible Improving diff algoritm
Javier Domingo writes: > I must say it is _quite_ helpfull having the diffs well done (natural > diffs as here named), just because when you want to review a patch on > the fly, this sort of things are annoying. I do not think anybody is arguing that it would not help the human users to shift the hunk boundaries in the case Kevin's original message demonstrated. -- 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
directory permissions on AFS
Hi, We have a shared bare git repository on AFS, which our developers pull from and push to from their local repositories. Some developers access the bare repository directly over AFS and others use ssh. Every couple of months, all of the two-character directories under the objects directory disappear. Afterwards, most pushes fail with an error like this: error: unable to create temporary sha1 filename ./objects/fb: Permission denied Stracing git revealed that it successfully recreated the ./objects/fb and then failed to chmod() it. It failed because it tried to set the S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating all of these directories solves the problem. I took a quick look at the git source and it appears git always tries to set the S_ISGID on a new directory if core.sharedrepository is enabled in the config. I don't know what other effects would result from setting core.sharedrepository to 0. Would it be feasible to allow the setting of S_ISGID to disabled, apart from modifying core.sharedrepository? Possibly a new config parameter or detecting if the directory is on AFS? -- Jaime Frey -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2012, #03; Wed, 12)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. A new maintenance release 1.8.0.2 was tagged with accumulated fixes we have already been using on the 'master' front for a while. The tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are getting into good shape in 'next', hopefully ready to be merged soon after the 1.8.1 final. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * sp/shortlog-missing-lf (2012-12-11) 2 commits (merged to 'next' on 2012-12-11 at 64b8429) + strbuf_add_wrapped*(): Remove unused return value + shortlog: fix wrapping lines of wraplen When a line to be wrapped has a solid run of non space characters whose length exactly is the wrap width, "git shortlog -w" failed to add a newline after such a line. Will cook in 'next'. * ap/log-mailmap (2012-12-11) 6 commits - [DO NOT MERGE] seems to break t4013 & t4014 among other things - log: Add --use-mailmap option - pretty: Use mailmap to display username and email - mailmap: Add mailmap structure to rev_info and pp - mailmap: Remove buffer length limit in map_user - Use split_ident_line to parse author and committer Clean up various codepaths around mailmap and teach the "log" machinery to use it. * jc/fetch-ignore-symref (2012-12-11) 1 commit - fetch: ignore wildcarded refspecs that update local symbolic refs Avoid false error from an attempt to update local symbolic ref via fetch. * md/gitweb-sort-by-age (2012-12-11) 1 commit - gitweb: Sort projects with undefined ages last Will merge to 'next'. * ss/nedmalloc-compilation (2012-12-11) 1 commit - nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2 Will merge to 'next'. * wk/submodule-update-remote (2012-12-12) 3 commits - submodule add: If --branch is given, record it in .gitmodules - submodule update: add --remote for submodule's upstream changes - submodule: add get_submodule_config helper funtion Expecting a re-roll. -- [Graduated to "master"] * ef/mingw-rmdir (2012-12-10) 1 commit + mingw_rmdir: do not prompt for retry when non-empty MinGW has a workaround when rmdir unnecessarily fails to retry with a prompt, but the logic was kicking in when the rmdir failed with ENOTEMPTY, i.e. was expected to fail and there is no point retrying. * ef/mingw-tty-getpass (2012-12-04) 6 commits (merged to 'next' on 2012-12-07 at 1737ff1) + mingw: get rid of getpass implementation + mingw: reuse tty-version of git_terminal_prompt + compat/terminal: separate input and output handles + compat/terminal: factor out echo-disabling + mingw: make fgetc raise SIGINT if apropriate + mingw: correct exit-code for SIGALRM's SIG_DFL Update getpass() emulation for MinGW. * jc/prompt-command-doc (2012-12-11) 1 commit - git-prompt.sh: update PROMPT_COMMAND documentation Recently graduated git-prompt topic to use PROMPT_COMMAND was confusingly documented. With a quick review, it may be a good idea to fast-track this to the 'master branch. -- [Stalled] * fc/remote-bzr (2012-11-28) 10 commits - (fixup) test-bzr.sh: fix multi-line string assignment - remote-bzr: detect local repositories - remote-bzr: add support for older versions of bzr - remote-bzr: add support to push special modes - remote-bzr: add support for fecthing special modes - remote-bzr: add simple tests - remote-bzr: update working tree - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - Add new remote-bzr transport helper New remote helper for bzr (v3). With minor fixes, this may be ready for 'next'. * mo/cvs-server-updates (2012-12-09) 18 commits - t9402: Use TABs for indentation - t9402: Rename check.cvsCount and check.list - t9402: Simplify git ls-tree - t9402: Add missing &&; Code style - t9402: No space after IO-redirection - t9402: Dont use test_must_fail cvs - t9402: improve check_end_tree() and check_end_full_tree() - t9402: sed -i is not portable - cvsserver Documentation: new cvs ... -r support - cvsserver: add t9402 to test branch and tag refs - cvsserver: support -r and sticky tags for most operations - cvsserver: Add version awareness to argsfromdir - cvsserver: generalize getmeta() to recognize commit refs - cvsserver: implement req_Sticky and related utilities - cvsserver: add misc commit lookup, file meta data, and file listing functions - cvsserver: define a tag name character escape mechanism - cvsserver: cleanup extra slashes in filename arguments - cvsserver: factor out git-log parsing logic Needs review by folks interested in cvsserver. * as/check-ignore (2012-11-08) 14 commits - t0007: f
Re: Fwd: possible Improving diff algoritm
On 12/12/2012 10:53 PM, Junio C Hamano wrote: > Morten Welinder writes: > >> Is there a reason why picking among the choices in a sliding window >> must be contents neutral? > > Sorry, you might be getting at something interesting but I do not > understand the question. I have no idea what you mean by "contents > neutral". > > Picking between these two choices > > /** +/** > + * Default parent + * Default parent > + * + * > + * @var int + * @var int > + * @access protected+ * @access protected > + * @index + * @index > + */ + */ > +protected $defaultParent; +protected $defaultParent; > ++ > +/** /** > > would not affect the correctness of the patch. You may pick > whatever you deem the most desirable, but your answer must be a > correct patch (the definition of "correct" here is "applying that > patch to the preimage produces the intended postimage"). > > And I think if you inserted a block of text B after a context C > where the tail of B matches the tail of C like the above, you can > shift what you treat as "inserted" up and still come up with a > correct patch. I have the feeling that a few crude heuristics would go a long way towards improving diffs like this. For example: * Prefer to have an add/remove block that has balanced begin/end pairs (where begin/end pairs might be opening and closing parentheses, brackets, braces, and angle brackets, "/*" and "*/", and perhaps a couple of other things. For SGML-like text begin and end tags could be matched up. It would be possible to read these begin/end pairs from a filetype-specific table or configuration setting, though this would add complication and would also make it possible that diffs generated by two different people are not identical if their configurations differ. * Prefer to have a block where the first non-blank line of the block and the first non-blank line after the block are indented by the same amount. * Prefer to have a block with trailing (as opposed to leading or embedded) blank lines--the more the better. The beautiful thing is that even if the heuristics sometimes fail, the correctness of the patch (in the sense that you have defined) is not compromised. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: directory permissions on AFS
Jaime Frey writes: > Stracing git revealed that it successfully recreated the ./objects/fb > and then failed to chmod() it. It failed because it tried to set the > S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating > all of these directories solves the problem. We fix directory permissions after creating any directory under .git with the same code, so that in a repository shared by group, new subdirectories created by a random somebody who belongs to that group will belong to that group (we also chmod to g+wx in case such a random somebody has overly strict umask). Instead of running chown(2) on every new file created by us, we let the filesystem to take care of it by telling the directories we create that new files in them should inherit their group ownership. What we were worried about back when we decided to use S_ISGID was a scenario like this: * A repository is shared by group "src". * A user belongs to the group "src". That group may or may not be his primary group (i.e. "mkdir foo" done at random place by him may not belong to the "src" group). * The user attempts to create a new branch "foo/bar" by pushing from outside. There is no other branch whose name is "foo/anything" when this happens. * An equivalent of "mkdir -p .git/refs/heads/foo" needs to be done before an equivalent of "echo $sha >.git/refs/heads/foo/bar" happens to accept this push. We want "foo" and "bar" to belong to "src" group and they get appropriate permission bits suitable to be accessed by the members of the "src" group. The story is the same for loose objects and their fan-out directory. Storing a commit object fb/012345... may need to create the leading fan-out ".git/objects/fb" and we want that directory and any future files created in it to belong to the "src" group. Any alternative implementation that achieves the same result that works on AFS can be substituted with the current code, or made conditionally activated on AFS. -- 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] submodule: add 'deinit' command
On Wed, Dec 12, 2012 at 03:35:59PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > Should `deinit` remove the submodule checkout, replace it with the > > original gitlink, and clear the .git/config information then? That > > would restore the user to the state they'd be in if they were never > > interested in the submodule. > > AFAIU, "restore the user to the state" is the goal. I am not sure > what you meant by "replace it with the original gitlink", though. A > checkout with a submodule that the user is not interested in would > have an empty directory at that path, no? Ah yes, the gitlink is only in the index. Sorry for the noise. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree
We have been writing -1 as "invalid" since day 1. On that same day we accept all negative entry counts as "invalid". So in theory all C Git versions out there would be happy to accept any negative numbers. JGit seems to do exactly the same. Correct the document to reflect the fact that -1 is not the only magic number. At least one implementation, libgit2, is found to treat -1 this way. Signed-off-by: Nguyễn Thái Ngọc Duy --- On Thu, Dec 13, 2012 at 1:14 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> We have been writing -1 as "invalid" since day 1. On that same day we >> accept all negative entry counts as "invalid". So in theory all C Git >> versions out there would be happy to accept any negative numbers. JGit >> seems to do exactly the same. > > I am of two minds here. > > The existing code is being more lenient than specified when they > read stuff others wrote, but it still adheres to -1 when writing. > Allowing random implementations to write random negative values will > close the door for us to later update the specification to encode > more informatin about these invalid entries by using negative value > other than -1 here. How would that work with existing versions? If you write -2 in cache-tree, the next time 1.8.0 updates cache tree it writes -1 back. That loses whatever information you attach to -2. A new cache-tree extension is probably better. > I am OK with a reword to say "negative means invalid, and writers > should write -1 for invalid entries", but without the latter half, > this change is not justified. Done. Documentation/technical/index-format.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..ce28a7a 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -161,8 +161,9 @@ GIT index format this span of index as a tree. An entry can be in an invalidated state and is represented by having - -1 in the entry_count field. In this case, there is no object name - and the next entry starts immediately after the newline. + a negative number in the entry_count field. In this case, there is no + object name and the next entry starts immediately after the newline. + When writing an invalid entry, -1 should always be used as entry_count. The entries are written out in the top-down, depth-first order. The first entry represents the root level of the repository, followed by the -- 1.8.0.rc2.23.g1fb49df -- 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 1/2] cache-tree: invalidate i-t-a paths after generating trees
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), we can generate trees from an index
with i-t-a entries.
However, the commit forgets to invalidate all paths leading to i-t-a
entries. With fully valid cache-tree (e.g. after commit or
write-tree), diff operations may prefer cache-tree to index and not
see i-t-a entries in the index, because cache-tree does not have them.
Reported-by: Jonathon Mah
Signed-off-by: Nguyễn Thái Ngọc Duy
---
This version ensures that entry_count can only be >= -1 after
update_one returns. Not ideal but good enough.
cache-tree.c | 40
t/t2203-add-intent.sh | 20
2 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 28ed657..1fbc81a 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
int missing_ok = flags & WRITE_TREE_MISSING_OK;
int dryrun = flags & WRITE_TREE_DRY_RUN;
int i;
+ int to_invalidate = 0;
if (0 <= it->entry_count && has_sha1_file(it->sha1))
return it->entry_count;
@@ -324,7 +325,14 @@ static int update_one(struct cache_tree *it,
if (!sub)
die("cache-tree.c: '%.*s' in '%s' not found",
entlen, path + baselen, path);
- i += sub->cache_tree->entry_count - 1;
+ i--; /* this entry is already counted in "sub" */
+ if (sub->cache_tree->entry_count < 0) {
+ i -= sub->cache_tree->entry_count;
+ sub->cache_tree->entry_count = -1;
+ to_invalidate = 1;
+ }
+ else
+ i += sub->cache_tree->entry_count;
sha1 = sub->cache_tree->sha1;
mode = S_IFDIR;
}
@@ -339,8 +347,23 @@ static int update_one(struct cache_tree *it,
mode, sha1_to_hex(sha1), entlen+baselen, path);
}
- if (ce->ce_flags & (CE_REMOVE | CE_INTENT_TO_ADD))
- continue; /* entry being removed or placeholder */
+ /*
+* CE_REMOVE entries are removed before the index is
+* written to disk. Skip them to remain consistent
+* with the future on-disk index.
+*/
+ if (ce->ce_flags & CE_REMOVE)
+ continue;
+
+ /*
+* CE_INTENT_TO_ADD entries exist on on-disk index but
+* they are not part of generated trees. Invalidate up
+* to root to force cache-tree users to read elsewhere.
+*/
+ if (ce->ce_flags & CE_INTENT_TO_ADD) {
+ to_invalidate = 1;
+ continue;
+ }
strbuf_grow(&buffer, entlen + 100);
strbuf_addf(&buffer, "%o %.*s%c", mode, entlen, path + baselen,
'\0');
@@ -360,7 +383,7 @@ static int update_one(struct cache_tree *it,
}
strbuf_release(&buffer);
- it->entry_count = i;
+ it->entry_count = to_invalidate ? -i : i;
#if DEBUG
fprintf(stderr, "cache-tree update-one (%d ent, %d subtree) %s\n",
it->entry_count, it->subtree_nr,
@@ -381,6 +404,15 @@ int cache_tree_update(struct cache_tree *it,
i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
+ /*
+* update_one() uses negative entry_count as a way to mark an
+* entry invalid _and_ pass the number of entries back to
+* itself at the parent level. This is for internal use and
+* should not be leaked out after the top-level update_one
+* exits.
+*/
+ if (it->entry_count < 0)
+ it->entry_count = -1;
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..2a4a749 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'cache-tree invalidates i-t-a paths' '
+ git reset --hard &&
+ mkdir dir &&
+ : >dir/foo &&
+ git add dir/foo &&
+ git commit -m foo &&
+
+ : >dir/bar &&
+ git add -N dir/bar &&
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual &&
+
+ git write-tree >/dev/null &&
+
+ git diff --cached --name-only >actual &&
+ echo dir/bar >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.0.rc2.23.
[PATCH v3 2/2] cache-tree: remove dead i-t-a code in verify_cache()
This code is added in 331fcb5 (git add --intent-to-add: do not let an empty blob be committed by accident - 2008-11-28) to forbid committing when i-t-a entries are present. When we allow that, we forgot to remove this unreachable code. Noticed-by: Junio C Hamano Signed-off-by: Nguyễn Thái Ngọc Duy --- cache-tree.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index 1fbc81a..3e79e27 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -166,12 +166,8 @@ static int verify_cache(struct cache_entry **cache, fprintf(stderr, "...\n"); break; } - if (ce_stage(ce)) - fprintf(stderr, "%s: unmerged (%s)\n", - ce->name, sha1_to_hex(ce->sha1)); - else - fprintf(stderr, "%s: not added yet\n", - ce->name); + fprintf(stderr, "%s: unmerged (%s)\n", + ce->name, sha1_to_hex(ce->sha1)); } } if (funny) -- 1.8.0.rc2.23.g1fb49df -- 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] index-format.txt: be more liberal on what can represent invalid cache tree
Nguyễn Thái Ngọc Duy writes: > How would that work with existing versions? If you write -2 in > cache-tree, the next time 1.8.0 updates cache tree it writes -1 back. > That loses whatever information you attach to -2. A new cache-tree > extension is probably better. You can easily imagine a definition like this: - If non-negative, the entry is valid and it is the number of index entries that are covered by this subtree; - If -1, the cached-tree does not know the object name of the tree object, and nothing else is known. The caller needs to walk the index to skip the entries that could have been covered by this subtree, if the cached tree information were valid; - If less than -1, the cached-tree does not know the object name of the tree object, but we know the number of index entries that are covered by this subtree. The caller, instead of walking the index, can subtract the count from -1 and skip that many entries to find the index entry after the part that is inside this directory. Newer Git may write -201 and newer Git may be able to take advantage of the new information encoded there, saving 200 calls to prefixcmp(), while given the same index, older Git will operate just as correctly as before. An older Git may write that part of the cache-tree back with -1, defeating the optimization when a newer Git reads it back, but by definition the older Git does not know what to write to help that optimization that did not exist when it was done, and writing -1 will not confuse the newer 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: Fwd: possible Improving diff algoritm
>> Is there a reason why picking among the choices in a sliding window
>> must be contents neutral?
>
> Sorry, you might be getting at something interesting but I do not
> understand the question. I have no idea what you mean by "contents
> neutral".
I was merely asking if an algorithm to pick between the
2+ choices was allowed to look at the contents of the
lines.
I.e., an algorithm would look at the C comment
example and determine that the choice starting containing
a full inserted comment is preferable over the one that
appears to close one comment and open a new.
And the in inserted-function case it would prefer the one
where the matching { and } are in correct order.
Morten
--
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/2] cache-tree: invalidate i-t-a paths after generating trees
Nguyễn Thái Ngọc Duy writes:
> Intent-to-add entries used to forbid writing trees so it was not a
> problem. After commit 3f6d56d (commit: ignore intent-to-add entries
> instead of refusing - 2012-02-07), we can generate trees from an index
> with i-t-a entries.
>
> However, the commit forgets to invalidate all paths leading to i-t-a
> entries. With fully valid cache-tree (e.g. after commit or
> write-tree), diff operations may prefer cache-tree to index and not
> see i-t-a entries in the index, because cache-tree does not have them.
>
> Reported-by: Jonathon Mah
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> This version ensures that entry_count can only be >= -1 after
> update_one returns. Not ideal but good enough.
>
> cache-tree.c | 40
> t/t2203-add-intent.sh | 20
> 2 files changed, 56 insertions(+), 4 deletions(-)
>
> diff --git a/cache-tree.c b/cache-tree.c
> index 28ed657..1fbc81a 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
> int missing_ok = flags & WRITE_TREE_MISSING_OK;
> int dryrun = flags & WRITE_TREE_DRY_RUN;
> int i;
> + int to_invalidate = 0;
>
> if (0 <= it->entry_count && has_sha1_file(it->sha1))
> return it->entry_count;
> @@ -324,7 +325,14 @@ static int update_one(struct cache_tree *it,
> if (!sub)
> die("cache-tree.c: '%.*s' in '%s' not found",
> entlen, path + baselen, path);
> - i += sub->cache_tree->entry_count - 1;
> + i--; /* this entry is already counted in "sub" */
Huh?
The "-1" in the original is the bog-standard compensation for the
for(;;i++) loop.
> + if (sub->cache_tree->entry_count < 0) {
> + i -= sub->cache_tree->entry_count;
> + sub->cache_tree->entry_count = -1;
> + to_invalidate = 1;
> + }
> + else
> + i += sub->cache_tree->entry_count;
While the rewritten version is not *wrong* per-se, I have a feeling
that it may be much easier to read if written like this:
if (sub->cache_tree_entry_count < 0) {
to_invalidate = 1;
to_skip = 0 - sub->cache_tree_entry_count;
sub->cache_tree_entry_count = -1;
} else {
to_skip = sub->cache_tree_entry_count;
}
i += to_skip - 1;
> @@ -360,7 +383,7 @@ static int update_one(struct cache_tree *it,
> }
>
> strbuf_release(&buffer);
> - it->entry_count = i;
> + it->entry_count = to_invalidate ? -i : i;
> #if DEBUG
> fprintf(stderr, "cache-tree update-one (%d ent, %d subtree) %s\n",
> it->entry_count, it->subtree_nr,
> @@ -381,6 +404,15 @@ int cache_tree_update(struct cache_tree *it,
> i = update_one(it, cache, entries, "", 0, flags);
> if (i < 0)
> return i;
> + /*
> + * update_one() uses negative entry_count as a way to mark an
> + * entry invalid _and_ pass the number of entries back to
> + * itself at the parent level. This is for internal use and
> + * should not be leaked out after the top-level update_one
> + * exits.
> + */
> + if (it->entry_count < 0)
> + it->entry_count = -1;
Nice. I think what entry_count means immediately after update_one()
returned should be commented near the beginning of that function,
too, though.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: possible Improving diff algoritm
On Dec 12, 2012, at 20:55, Morten Welinder wrote:
> I was merely asking if an algorithm to pick between the
> 2+ choices was allowed to look at the contents of the
> lines.
>
> I.e., an algorithm would look at the C comment
> example and determine that the choice starting containing
> a full inserted comment is preferable over the one that
> appears to close one comment and open a new.
>
> And the in inserted-function case it would prefer the one
> where the matching { and } are in correct order.
/** +/**
+ * Default parent + * Default parent
+ * + *
+ * @var int + * @var int
+ * @access protected+ * @access protected
+ * @index + * @index
+ */ + */
+protected $defaultParent; +protected $defaultParent;
++
+/** /**
It would seem that just looking at the line length (stripped) of
the last line, might be sufficient for cost function to minimize.
Here the some would be 3 vs 0. In case of ties, use the last
possibility with minimum cost.
I think it would be nice if the cost function we choose does not
depend on file type, as that is something that is very dependent
on the exact local configuration and might hinder comparison of
patches. If something really simple gets us 90% there, that would
be preferable over extra complexity.
-Geert
Junio's other example:
}
+void new_function(void)
+{
+ printf("hello, world.\n");
+}
+
void existing_one(void)
{
printf("goodbye, world.\n");
=> Cost 0
+}
+
+void new_function(void)
+{
+ printf("hello, world.\n");
}
=> Cost 27
Kevin's example:
/**
+ * Default parent
+ *
+ * @var int
+ * @access protected
+ * @index
+ */
+protected $defaultParent;
+
+/**
=> Cost 3
+ /**
+ * Default parent
+ *
+ * @var int
+ * @access protected
+ * @index
+ */
+protected $defaultParent;
+
/**
=> cost 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
Submodule not updated automatically on merge conflict
Hi, If there are merge conflict files, then changed submodules are not updated automatically. Why not submodules? Files do try to merge / update. Regards, ch3cooli -- 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 (Dec 2012, #03; Wed, 12)
On Wed, Dec 12, 2012 at 5:58 PM, Junio C Hamano wrote: > [Stalled] > > * fc/remote-bzr (2012-11-28) 10 commits > - (fixup) test-bzr.sh: fix multi-line string assignment > - remote-bzr: detect local repositories > - remote-bzr: add support for older versions of bzr > - remote-bzr: add support to push special modes > - remote-bzr: add support for fecthing special modes > - remote-bzr: add simple tests > - remote-bzr: update working tree > - remote-bzr: add support for remote repositories > - remote-bzr: add support for pushing > - Add new remote-bzr transport helper > > New remote helper for bzr (v3). With minor fixes, this may be ready > for 'next'. What minor fixes? -- Felipe Contreras -- 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: possible Improving diff algoritm
Geert Bosch writes: > It would seem that just looking at the line length (stripped) of > the last line, might be sufficient for cost function to minimize. > Here the some would be 3 vs 0. In case of ties, use the last > possibility with minimum cost. -- 8< -- #ifdef A some stuff about A #endif #ifdef Z some more stuff about Z #endif -- >8 -- If you insert a block for M following the existing formatting convention in the middle, your heuristics will pick the blank line after "about A" as having minimum cost, no? You inherently have to know the nature of the payload, as your eyes that judge the result use that knowledge when doing so, I am afraid. I think your "define a function that gives a good score to lines that are likely to be good breaking points" idea has merit, but I think that should be tied to the content type, most likely via the attribute mechanism. In any case, I consider this as a low-impact (as Michael Haggerty noted, it is impossible to introduce a bug that subtly break the output; your result is either totally borked or is correct) and low-hanging fruit (it can be done as a postprocessing phase after the xdiff machinery has done the heavy-lifting of computing LCA), if somebody wants to experiment and implement one. As long as the new heuristics is hidden behind an explicit command line option to avoid other "consequences", I wouldn't discourage interested parties from working on it. It is not just my itch, 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
