GIT_DIR vs. --git-dir
[mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel /home/mjg [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel fatal: Not a git repository: '~/.githome' Huh? Ok, so most users probably would not try further and blame git, but: [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse --show-toplevel /home/mjg (All this is with core.worktree set to /home/mjg.) So, while I do understand that we don't expand '~' in any of these cases and it's only a matter of bash tilde expansion kicking in or not, we might want to do something about it. (--git-dir=$HOME/.githome gets expanded, as well, and --git-dir=.githome works from the appropriate cwd only). 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: Message from 'git-rebase'; German translation
Sascha Cunz venit, vidit, dixit 22.09.2012 23:57: As I know how hard translations can be, esp. with that much technical terms inside, I'm usually expecting _not_ to yield the same result when translating a software's translation back to English. However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to confuse me (even the original text) - and now I feel like I don't understand the meaning of the last sentence at all; neither in English nor in the German translation: After removing the directory with all rebase-information inside it, WHERE should something valuable still be left over? Is it referring to my working tree? So, for completeness, the full English message: It seems that there is already a rebase-merge directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr /work/lg2/src/.git/rebase-merge and run me again. I am stopping in case you still have something valuable there. Sascha Both translations are completely wrong on two accounts: They are a wrong translation of the English original into German (making typical mistakes like false friends [wonder != wundern] etc.), and they convey a completely wrong idea about what git is doing and about to do (by translating a message without knowing when and why it is given). Unfortunately, neither comes to me as a surprise. I'm sorry I'm too frustrated by the German l10n community to try to help again (and the ensuing thread just reinforces that feeling), but to end on a positive note let me just point out: 'in case ...' = 'für den Fall dass ...' (attributiv) 'in the case ...' = 'im Fall dass ...' (konditional) 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: GIT_DIR vs. --git-dir
Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 09:41: On Mon, Sep 24, 2012 at 2:19 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel /home/mjg [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel fatal: Not a git repository: '~/.githome' Huh? The message looks pretty clear to me that ~ is not expanded. ...to you and me, of course, but the point is whether we can be more helpful to most users. Ok, so most users probably would not try further and blame git, but: [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse --show-toplevel /home/mjg (All this is with core.worktree set to /home/mjg.) So, while I do understand that we don't expand '~' in any of these cases and it's only a matter of bash tilde expansion kicking in or not, we might want to do something about it. (--git-dir=$HOME/.githome gets expanded, as well, and --git-dir=.githome works from the appropriate cwd only). ~ is a shell feature. Know your shell. If we make an exception for --git-dir, we might have to support --blahblah=~/somewhere. That's a lot of changes and we might mistakenly over-expand something. Users running git on cmd.exe may get surprised that ~ is expanded. We could print an advice did you mean $HOME/.githome?. That could still be a lot of changes, but it's no-op so less worries of breaking something. I prefer doing nothing in this case. First of all, we expand '~' in other cases (basically all config vars) ta) where it's unambiguously a path. And --git-dir really is the sensible version of core.gitdir (which would make no sense, of course). Then, we refuse to make ~2 a shorthand for HEAD~2 in the revision parser because ~2 has a meaning for certain shells in certain situations (depending on your dirstack) and would need to be quoted, so we certainly take into account how the shell behaves. It might be difficult to implement, but I'm sorry I can't follow the argumentation above at all; it's not based on what we do in other places and other cases. 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: GIT_DIR vs. --git-dir
On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: It might be difficult to implement, but I'm sorry I can't follow the argumentation above at all; it's not based on what we do in other places and other cases. My point is, what's so special about --git-dir? what about --work-tree, or commit -F path? It's hard to draw a line there. Config files are a special case, because git is the only one that reads the file. ~ expansion depends on shell setting. If users turn it off, they may be surprised that ~foo is turned to /home/foo while they really mean ~foo. Warning is the only sensible thing we could do. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] tig-1.0
Yes it works great, thanks! 2012/9/16 Jonas Fonseca fons...@diku.dk: On Tue, Sep 11, 2012 at 3:24 PM, Jean-Baptiste Quenot j...@caraldi.com wrote: 2012/9/7 Jonas Fonseca fons...@diku.dk: [snip] I suggest to support something like the following: tig --no-walk --stdin tmp-file Would that cover your use case? That would be great! I would then feed tig with all commits I want to see in the main view. When you have time, please test the main-view-with-stdin branch in git://github.com/jonas/tig.git -- Jonas Fonseca -- Jean-Baptiste Quenot -- 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?] Path limiting in git log when run from another subdir
The following works in the git.git repo: $ cd t $ git log -- /Documentation [...] but the following does not: $ cd t $ git log -- /Documentation/RelNotes fatal: Could not switch to '/Documentation': No such file or directory Is this the intended behavior? ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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?] Path limiting in git log when run from another subdir
On Mon, Sep 24, 2012 at 6:59 PM, Johan Herland jo...@herland.net wrote: The following works in the git.git repo: $ cd t $ git log -- /Documentation [...] What version? Mine (recent master) does not work ~/w/git/t $ ../git log -- /Documentation fatal: '/Documentation' is outside repository but the following does not: $ cd t $ git log -- /Documentation/RelNotes fatal: Could not switch to '/Documentation': No such file or directory Is this the intended behavior? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Ralf Thielow ralf.thie...@gmail.com writes: On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz sascha...@babbelbox.org wrote: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. Perhaps the English wording should be made more clear; the fact that translation is difficult is a clue that it may be hard to understand, particularly for non-native-English-Speakers (albeit an ambiguous one; I realize translation is hard). We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, because it's very unusual in German messages of computer programs. Translators should have the freedom to reword It's unusual in English too :-) pgpyhJYu3up07.pgp Description: PGP signature
Re: GIT_DIR vs. --git-dir
Nguyen Thai Ngoc Duy venit, vidit, dixit 24.09.2012 11:53: On Mon, Sep 24, 2012 at 2:57 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: It might be difficult to implement, but I'm sorry I can't follow the argumentation above at all; it's not based on what we do in other places and other cases. My point is, what's so special about --git-dir? what about --work-tree, or commit -F path? It's hard to draw a line there. Sure those should follow, especially work-tree. Config files are a special case, because git is the only one that reads the file. ~ expansion depends on shell setting. If users turn it off, they may be surprised that ~foo is turned to /home/foo while they really mean ~foo. Warning is the only sensible thing we could do. But that argument applies to config files in exactly the same way as it applies to command line arguments. Git is the only one reading them. So why not leave it up to Git to decide about expansion? On the other hand: If Git expanding arguments is surprising, why is it unsurprising if Git expands config values? You know the implementation, so there are no surprises for you. But once in a while we can pretend to design Git for those who just use it. 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
[RFC/PATCH] git: expand user path in --git-dir
Currently, all paths in the config file are subject to tilde expansion
for user paths while the argument to --git-dir is not expanded, and
neither are paths in the environment such as GIT_DIR. From the user
perspective, though, the two commands
GIT_DIR=~user/foo git command
git --git-dir=~user/foo command
currently behave differently because in the first case the shell would
perform tilde expansion, but not in the second. Also, one may argue that
specifying '--git-dir=' is like specifying a config variable (which
cannot exist for this purpose).
Thus, make arguments to '--git-dir' undergo tilde expansion.
---
So, here's a simple patch implementing tilde expansion for --git-dir. It passes
all tests. It's done doing the expansion on the setting side.
Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR,
so that paths passed directly through the environment undergo tilde expansion
as well. We don't do this for any environment variable yet, so I didn't go
that far.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
git.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 8788b32..35e8011 100644
--- a/git.c
+++ b/git.c
@@ -64,6 +64,22 @@ static void commit_pager_choice(void) {
}
}
+static int expand_path_setenv(const char *name, const char *value, int
overwrite)
+{
+ int ret;
+ const char *expanded;
+
+ if (!value)
+ return setenv(name, value, overwrite);
+
+ expanded = expand_user_path(value);
+ if (!expanded)
+ die(Failed to expand user dir in: '%s', value);
+ ret = setenv(name, expanded, overwrite);
+ free((void *)expanded);
+ return ret;
+}
+
static int handle_options(const char ***argv, int *argc, int *envchanged)
{
const char **orig_argv = *argv;
@@ -117,13 +133,13 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
fprintf(stderr, No directory given for
--git-dir.\n );
usage(git_usage_string);
}
- setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
+ expand_path_setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
if (envchanged)
*envchanged = 1;
(*argv)++;
(*argc)--;
} else if (!prefixcmp(cmd, --git-dir=)) {
- setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
+ expand_path_setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
if (envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, --namespace)) {
--
1.7.12.1.580.gb9ed689
--
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?] Path limiting in git log when run from another subdir
On Mon, Sep 24, 2012 at 8:16 PM, Johan Herland jo...@herland.net wrote: On Mon, Sep 24, 2012 at 2:22 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Mon, Sep 24, 2012 at 6:59 PM, Johan Herland jo...@herland.net wrote: The following works in the git.git repo: $ cd t $ git log -- /Documentation [...] What version? Mine (recent master) does not work ~/w/git/t $ ../git log -- /Documentation fatal: '/Documentation' is outside repository We initially found it on 1.7.9.5, and conrfirmed it on various 1.7.10 versions. A bisect reveals that this behavior changed in v1.7.11.5-35-gf4c21e8 (Michael Haggerty: real_path(): properly handle nonexistent top-level paths). OK checking. I still don't know why it does not happen to me. Any special in gitdir/worktree setting? That commit is in master. Does this mean that git log -- /Documentation never should have worked in the first place (and was fixed by this commit), or that it should work (but was broken by this commit)? I think that should mean Documentation at root. git log -- `chdir ../Documentation;pwd` works and that clearly conflicts with interpreting /Documentation as the directory at worktree's root. In any case, what is the _preferred_ way to path-limit git log to Documentation/RelNotes, when my cwd is t/? If you want worktree root no matter where you stand, use git log -- :/Documentation/RelNotes. The idea is : starts some magic in path handling, but for now there is only :/. Or if you don't like magic, `git rev-parse --git-dir` should give you worktree's root to start with. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT_DIR vs. --git-dir
Michael J Gruber g...@drmicha.warpmail.net writes: But that argument applies to config files in exactly the same way as it applies to command line arguments. Git is the only one reading them. So why not leave it up to Git to decide about expansion? Command line arguments are first processed by the shell, handling expansions like $HOME. It is part of the Unix philosophy that expansion of command lines is left to the shell. On the other hand: If Git expanding arguments is surprising, why is it unsurprising if Git expands config values? The config file is not processed by the shell. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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?] Path limiting in git log when run from another subdir
On Mon, Sep 24, 2012 at 8:30 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: Any special in gitdir/worktree setting? What does GIT_TRACE_SETUP=1 git log -- /Documentation show? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG?] Path limiting in git log when run from another subdir
On Mon, Sep 24, 2012 at 3:30 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: In any case, what is the _preferred_ way to path-limit git log to Documentation/RelNotes, when my cwd is t/? If you want worktree root no matter where you stand, use git log -- :/Documentation/RelNotes. The idea is : starts some magic in path handling, but for now there is only :/. Or if you don't like magic, `git rev-parse --git-dir` should give you worktree's root to start with. Ah, ok, that's exactly what I wanted. Then I guess cd t git log -- /Documentation should have never worked in the first place, and I question about git log -- /Documentation/RelNotes was misguided. Thanks for clearing up my confusion. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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: [ANNOUNCE] tig-1.0
There's a small glitch however: when some git command returns an error (for example when typing 'M' for merge in main view) the main view displays the tip of the current branch, instead of the list of revisions passed in stdin. 2012/9/24 Jean-Baptiste Quenot j...@caraldi.com: Yes it works great, thanks! 2012/9/16 Jonas Fonseca fons...@diku.dk: On Tue, Sep 11, 2012 at 3:24 PM, Jean-Baptiste Quenot j...@caraldi.com wrote: 2012/9/7 Jonas Fonseca fons...@diku.dk: [snip] I suggest to support something like the following: tig --no-walk --stdin tmp-file Would that cover your use case? That would be great! I would then feed tig with all commits I want to see in the main view. When you have time, please test the main-view-with-stdin branch in git://github.com/jonas/tig.git -- Jonas Fonseca -- Jean-Baptiste Quenot -- Jean-Baptiste Quenot -- 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] Questions for Git User's Survey 2011
On Mon, Sep 24, 2012 at 3:23 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: [...] Other version control systems: I think the list needs to be sorted alphabetically, it's really long. I have split this list in two: other centralized VCS and other distributed VCS; both have other field. (You could also reduce and offer a text field other.) I tried to include all important VCS. There is always problem with analyzing responses from other field... Resources: I wouldn't put git-scm.com and the pro-git book into the same item. git-scm.com was supposed to be the git community website (and also the reference on git), and the fact that it looks like a pro-git book sales platform is a different matter. Good catch. Originally there was Git Community Book on Git Homepage, and Pro Git had its own homepage; now they are folded together. I have slightly rewritten the description to account for this. An interesting question would be: What is the first source you consider Git?, or even: What is the Git homepage?... Really, getting input on what the Git homepage should be like would be nice, but not comparable to previous surveys. As you can see this year survey is [almost] bereft of essay free-form questions. It is because of difficulties and time needed to analyze such responses. So I don't think such question will be included this year. I think it is better discussion for git mailing list or something... -- Jakub Narebski -- 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_DIR vs. --git-dir
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: ~ is a shell feature. Know your shell. If we make an exception for --git-dir, we might have to support --blahblah=~/somewhere. Correct but not entirely true. When we know --git-dir=path must name a path, we should be able to do better. See OPT_FILENAME in parse-optios.h, for inspiration. MJG's patch later in this thread is conceptually OK but I do not think it should introduce a expand and then setenv helper that won't be useful unless the variable is GIT_DIR. That pattern does not appear that often, and smells like a bad API design taste. -- 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_DIR vs. --git-dir
Junio C Hamano venit, vidit, dixit 24.09.2012 16:36: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: ~ is a shell feature. Know your shell. If we make an exception for --git-dir, we might have to support --blahblah=~/somewhere. Correct but not entirely true. When we know --git-dir=path must name a path, we should be able to do better. See OPT_FILENAME in parse-optios.h, for inspiration. MJG's patch later in this thread is conceptually OK but I do not think it should introduce a expand and then setenv helper that won't be useful unless the variable is GIT_DIR. That pattern does not appear that often, and smells like a bad API design taste. I can't quite parse. My little helper can be used for any path environment variable, not just GIT_DIR. Granted, there aren't that many in use. Do you suggest tilde expansion right in fix_filename() (i.e. for all OPT_FILE options), or some OPT_FILENAME_EXPANDED which may or may not be used by some config? There's git_config_pathname() already which does expansion, of course. 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: [RFC/PATCH] git: expand user path in --git-dir
On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote: Currently, all paths in the config file are subject to tilde expansion for user paths while the argument to --git-dir is not expanded, and neither are paths in the environment such as GIT_DIR. From the user perspective, though, the two commands GIT_DIR=~user/foo git command git --git-dir=~user/foo command currently behave differently because in the first case the shell would perform tilde expansion, but not in the second. Also, one may argue that specifying '--git-dir=' is like specifying a config variable (which cannot exist for this purpose). Thus, make arguments to '--git-dir' undergo tilde expansion. --- So, here's a simple patch implementing tilde expansion for --git-dir. It passes all tests. It's done doing the expansion on the setting side. Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR, so that paths passed directly through the environment undergo tilde expansion as well. We don't do this for any environment variable yet, so I didn't go that far. Keep in mind that every layer of expansion you add is a layer of quoting somebody else must do in order to pass through certain paths. I will admit that putting a ~ into a path is relatively uncommon, but this patch is a regression for anybody who does so with --git-dir (they will now need to quote the ~ against not just their shell, but against git). Expanding environment variables like GIT_DIR means that we would also need to quote things we put into GIT_DIR. -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: GIT_DIR vs. --git-dir
Jeff King venit, vidit, dixit 24.09.2012 16:49: On Mon, Sep 24, 2012 at 09:19:27AM +0200, Michael J Gruber wrote: [mjg@localhost ~]$ GIT_DIR=~/.githome git rev-parse --show-toplevel /home/mjg [mjg@localhost ~]$ git --git-dir=~/.githome rev-parse --show-toplevel fatal: Not a git repository: '~/.githome' Huh? Ok, so most users probably would not try further and blame git, but: [mjg@localhost ~]$ git --git-dir=/home/mjg/.githome rev-parse --show-toplevel /home/mjg (All this is with core.worktree set to /home/mjg.) So, while I do understand that we don't expand '~' in any of these cases and it's only a matter of bash tilde expansion kicking in or not, we might want to do something about it. (--git-dir=$HOME/.githome gets expanded, as well, and --git-dir=.githome works from the appropriate cwd only). Bash is even weirder than you might think. Try this: $ echo ~/foo /home/peff/foo $ echo arg=~/foo arg=/home/peff/foo $ echo --arg=~/foo --arg=~/foo That is, it expands on the right-hand side of an = (which, from my reading of the bash manual, means it considers it a word split), but refuses to expand after an = that is part of a long option. The first one is definitely correct. It would be convenient for your use case to expand the third one, and it logically follows from the second one. However, dash does not expand the second one. I'm not sure if this is a bug in bash, or simply a grey area where the two shells do not agree. But it makes me wonder if the world would be better served by a bash option to always enable tilde expansion after an =. That would solve your issue, and it would make the same feature work for every other git long option, as well as for other programs. Yes, in some sense this is working around a bash feature. I don't really care too much personally. Note that we also have git -c config.var=value which, again works because we expand config vars. So, technically there are no surprises if you know the shell's expansion rules. But still... 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: [ANNOUNCE] tig-1.0
This actually happens everytime I run a git command with a key binding, be it successful or not. The main view is restored to the tip of the current branch. 2012/9/24 Jean-Baptiste Quenot j...@caraldi.com: There's a small glitch however: when some git command returns an error (for example when typing 'M' for merge in main view) the main view displays the tip of the current branch, instead of the list of revisions passed in stdin. 2012/9/24 Jean-Baptiste Quenot j...@caraldi.com: Yes it works great, thanks! 2012/9/16 Jonas Fonseca fons...@diku.dk: On Tue, Sep 11, 2012 at 3:24 PM, Jean-Baptiste Quenot j...@caraldi.com wrote: 2012/9/7 Jonas Fonseca fons...@diku.dk: [snip] I suggest to support something like the following: tig --no-walk --stdin tmp-file Would that cover your use case? That would be great! I would then feed tig with all commits I want to see in the main view. When you have time, please test the main-view-with-stdin branch in git://github.com/jonas/tig.git -- Jonas Fonseca -- Jean-Baptiste Quenot -- Jean-Baptiste Quenot -- Jean-Baptiste Quenot -- 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] git: expand user path in --git-dir
Jeff King venit, vidit, dixit 24.09.2012 16:52: On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote: Currently, all paths in the config file are subject to tilde expansion for user paths while the argument to --git-dir is not expanded, and neither are paths in the environment such as GIT_DIR. From the user perspective, though, the two commands GIT_DIR=~user/foo git command git --git-dir=~user/foo command currently behave differently because in the first case the shell would perform tilde expansion, but not in the second. Also, one may argue that specifying '--git-dir=' is like specifying a config variable (which cannot exist for this purpose). Thus, make arguments to '--git-dir' undergo tilde expansion. --- So, here's a simple patch implementing tilde expansion for --git-dir. It passes all tests. It's done doing the expansion on the setting side. Alternatively, one might do it on the getting side, i.e. when reading GIT_DIR, so that paths passed directly through the environment undergo tilde expansion as well. We don't do this for any environment variable yet, so I didn't go that far. Keep in mind that every layer of expansion you add is a layer of quoting somebody else must do in order to pass through certain paths. I will admit that putting a ~ into a path is relatively uncommon, but this patch is a regression for anybody who does so with --git-dir (they will now need to quote the ~ against not just their shell, but against git). Expanding environment variables like GIT_DIR means that we would also need to quote things we put into GIT_DIR. ...as far as ~ is concerned, yes. We don't do a full expansion like the shell does (or doesn't). Probably --git-dir is hidden well enough to be for the initiated only. As for the other path options, we can always blame bash. It's got its name for a reason ;) 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: submodule: if $command was not matched, don't parse other args
On 12-09-23 01:36 PM, Jens Lehmann wrote: Am 22.09.2012 22:31, schrieb Junio C Hamano: Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/git-submodule.sh b/git-submodule.sh index a7e933e..dfec45d 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1108,7 +1108,15 @@ do done # No command word defaults to status -test -n $command || command=status +if test -z $command +then +if test $# = 0 +then + command=status +else + usage +fi +fi I personally feel no command means this default is a mistake for git submodule, even if there is no pathspec or other arguments, but I am not a heavy user of submodules, so others should discuss this. The commit message of 97a5d8cce9 (git-submodule: re-enable 'status' as the default subcommand) back from 2007 indicates that Lars did back then think that status is a sane default. I agree with Junio that this is not optimal, but I'd rather tend to not change that behavior which has been there from day one for backward compatibility reasons. But if many others see that as an improvement too I won't object against changing it the way Ramkumar proposes (but he'd have to change the documentation too ;-). Since diff and status learned to display submodule status information (except for a submodule being uninitialized) I almost never use this option myself, so I'd be interested to hear what submodule users who do use git submodule [status] frequently think. I also almost never use git submodule [status], and I also agree that git-submodule shouldn't have a default sub-command. (Honestly, submodule's status sub-command has always felt more like plumbing to me than something a user would work with directly. Maybe it's just the full-length SHA's that put me off...) 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: [ANNOUNCE] tig-1.0
On Mon, Sep 24, 2012 at 10:57 AM, Jean-Baptiste Quenot j...@caraldi.com wrote: This actually happens everytime I run a git command with a key binding, be it successful or not. The main view is restored to the tip of the current branch. If I have understood the problem correctly, you have a keybinding mapping 'M' to `git merge %(commit)` or something like that and when you type 'M', tig will list the commits in the master branch after executing the external command. I didn't account for this in the patch, and I will have to figure out a way to disable the current behavior of reloading the main view after executing an external command. -- Jonas Fonseca -- 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] Questions for Git User's Survey 2011
Jakub Narębski jna...@gmail.com writes: I have created short (well, at least shorter than previous ones) Git User's Survey 2012 on Survs.com. The test channel is https://www.survs.com/survey/J87I3PDBU4 If it's still time, it would be nice to add a question on the kind of workflow people use. E.g. Which workflow do you use? (never / rarely / often / always) Centralized workflow (everyone pushes and pulls to the same shared repository). One-repository per developer (people push to their own public repository, and pull from other user's public repository) (and perhaps intermediates). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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_DIR vs. --git-dir
Jeff King p...@peff.net writes: Bash is even weirder than you might think. Try this: $ echo ~/foo /home/peff/foo $ echo arg=~/foo arg=/home/peff/foo $ echo --arg=~/foo --arg=~/foo Bash expands all arguments that look like variable assignments. That lets you write export arg=~/foo even though a POSIX shell wouldn't tilde expand it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git archive --format zip utf-8 issues
Hi,
I found a way to make unzip respect the UTF-8 flag in ZIP files:
Apparently (from looking at the source) an extended field needs to be
present in order for it to even look at general purpose flag 11. I sent
a patch to add an extended timestamp field that fits the bill.
Here are new numbers on ZIP international filename compatibility:
7-Zip PeaZip builtin unzip unzip unzip 7z
Windows Windows Windows Linux mingw Windows Linux
git Linux 1 1 1 7 1 1 1
git 1 Linux 37 37 1 7 1 1 37
git 2 Linux 37 37 1 37 1 1 37
git 3 Linux 37 37 1 37 15 15 37
git mingw 1 1 1 7 1 1 1
git 1 mingw 37 37 1 7 1 1 37
git 2 mingw 37 37 1 37 1 1 37
git 3 mingw 37 37 1 37 15 15 37
7-Zip Windows 37 37 14 24 15 15 24
PeaZip Windows 37 37 14 24 15 15 24
zip Linux 37 37 1 37 15 15 37
zip Windows 14 14 0 37 15 15 1
builtin Windows 14 14 14 1 14 14 1
The test corpus still consists of 37 files based on the pangrams on the
following web page:
http://www.columbia.edu/~fdc/utf8/index.html#quickbrownfox
The files can be created using the attached script. It also provides a
check command to count the files with correct names, and the results of
that for different ZIP extractors are give in the table. The built-in
ZIP functionality on Windows was only able to pack 14 of the 37 files,
which explains the low score across the board for this packer.
git 1 is the patch archive-zip: support UTF-8 paths added, which
let's archive-zip make use of the UTF-8 flag. git 2 is git 1 plus
the patch archive-zip: declare creator to be Unix for UTF-8 paths.
Both have been posted before. git 3 is git 1 plus the new patch
archive-zip: write extended timestamp.
Let's drop patch 2 (Unix as creator) and keep patches 1 (UTF-8 flag) and
3 (mtime field) to make archive-zip record non-ASCII filenames in a
portable way. It's not perfect, but I don't know how to do any better
given that Windows' built-in ZIP functionality expects filenames in the
local code page and with an international audience for projects
distributing ZIP files.
René
#!/bin/sh
files() {
cat EOF
pangrams/ã‚�ã�Œã‚ˆã�Ÿã‚Œã�žã€€ã�¤ã�ã�ªã‚‰ã‚€
pangrams/�����や�　�����
pangrams/�������　�り�るを
pangrams/���ゆ���　ゑ�も��
pangrams/An ḃfuil do Ä‹roà ag bualaḋ ó ḟaitÃos an Ä¡rá a á¹�eall
pangrams/Ã�rvÃztűrÅ‘ tükörfúrógép
pangrams/Blåbærsyltetøy
pangrams/D'ḟuascail �osa Úr�ac na hÓiġe Beannaiṫe pór
pangrams/d'œufs abîmés
pangrams/Éava agus �ḋai�
pangrams/EÄ¥oÅ�anÄ�o ĉiuĵaÅde
pangrams/El pingüino Wenceslao hizo kilómetros bajo exhaustiva
pangrams/Falsches Üben von Xylophonmusik quält
pangrams/Flygande bäckasiner söka strax hwila på mjuka tuvor
pangrams/Høj bly gom vandt fræk sexquiz på wc
pangrams/jeden größeren Zwerg
pangrams/lena ṗóg éada ó ṡlà do leasa ṫú
pangrams/Les naïfs ægithales hâtifs pondant à Noël où il gèle
pangrams/lluvia y frÃo añoraba a su querido cachorro
pangrams/na stĺpe sa �ateľ u�à kvákať novú ódu o živote
pangrams/O próximo vôo à noite sobre o Atlântico
pangrams/Pa's wijze lynx bezag vroom het fikse aquaduct
pangrams/Pchnąć w tę łódź jeża lub osiem skrzyń fig
pangrams/põe freqüentemente o único médico
pangrams/PÅ™ÃliÅ¡ žluÅ¥ouÄ�ký kůň úpÄ›l Ä�ábelské kódy
pangrams/Sævör grét áðan þvà úlpan var ónýt
pangrams/sont sûrs d'être déçus en voyant leurs drôles
pangrams/Starý kôň na hÅ•be knÃh žuje tÃÅ¡ko povädnuté ruže
pangrams/The quick brown fox jumps over the lazy dog
pangrams/Törkylempijävongahdus
pangrams/Vuol Ruoŧa geđggiid leat máŋga luosa ja �uovžža
pangrams/×–×” ×›×™×£ סת×� לשמוע ×�יך ×ª× ×¦×— קרפד ×¢×¥ טוב
בגן
pangrams/ξεσκεπάζω την ψυχοφθό�α βδελυγμία
pangrams/ξεσκεπάζω τὴν ψυχοφθό�α βδελυγμία
pangrams/Жълтата дюл� беше ща�тлива
pangrams/Съешь же ещё �тих м�гких француз�ких
булок да выпей чаю
pangrams/че пухът, който цъфна, замръзна като
гьон
EOF
}
case $1 in
create)
mkdir -p pangrams
files | while read file
do
touch $file
done
;;
check)
files | while read file
do
test -f $file echo $file
done | wc -l
;;
*)
echo Usage: $0 create | check
Re: [RFC] Questions for Git User's Survey 2011
On Mon, Sep 24, 2012 at 5:37 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: I have created short (well, at least shorter than previous ones) Git User's Survey 2012 on Survs.com. The test channel is https://www.survs.com/survey/J87I3PDBU4 If it's still time, it would be nice to add a question on the kind of workflow people use. E.g. Which workflow do you use? (never / rarely / often / always) Centralized workflow (everyone pushes and pulls to the same shared repository). One-repository per developer (people push to their own public repository, and pull from other user's public repository) You were not the only one to ask for question about workflows used; Junio also asked for something similar. I have therefore added the following multiple-choice question: #19. What git workflow(s) is used by projects in which development you participate? [ ] single developer, only private repository (no interaction) [ ] centralized workflow (push to common repository) [ ] branched centralized (push to different branches in common repository) [ ] peer-to-peer workflow (all repositories roughly equal) [ ] integration-manager workflow (maintainer pulls/applies patches to blessed repository)) [ ] dictator and lieutenants workflow (hierarchical workflow) [ ] using collaborative code review tool, e.g. Gerrit [ ] other workflow, please explai I was also thinking about adding merge vs rebase question, but it is direction orthogonal to above, so maybe as separate question... -- Jakub Narebski -- 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: submodule: if $command was not matched, don't parse other args
Marc Branchaud mbranch...@xiplink.com writes: On 12-09-23 01:36 PM, Jens Lehmann wrote: Am 22.09.2012 22:31, schrieb Junio C Hamano: Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/git-submodule.sh b/git-submodule.sh index a7e933e..dfec45d 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1108,7 +1108,15 @@ do done # No command word defaults to status -test -n $command || command=status +if test -z $command +then +if test $# = 0 +then + command=status +else + usage +fi +fi I personally feel no command means this default is a mistake for git submodule, even if there is no pathspec or other arguments, but I am not a heavy user of submodules, so others should discuss this. ... but I'd rather tend to not change that behavior which has been there from day one for backward compatibility reasons. But if many others see that as an improvement too I won't object against changing it the way Ramkumar proposes (but he'd have to change the documentation too ;-). Since diff and status learned to display submodule status information (except for a submodule being uninitialized) I almost never use this option myself, so I'd be interested to hear what submodule users who do use git submodule [status] frequently think. I also almost never use git submodule [status], and I also agree that git-submodule shouldn't have a default sub-command. OK, I do not think Ramkumar's patch hurts anybody, but dropping the nothing on the command line defaults to 'status' action could. So let's queue the patch as-is at least for now and leave the default discussion to a separarte thread if needed. 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: [RFC] Questions for Git User's Survey 2011
On Mon, Sep 24, 2012 at 6:18 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: I have therefore added the following multiple-choice question: #19. What git workflow(s) is used by projects in which development you participate? If we want to have an idea of which workflows are the most commonly used, just a binary answer may be insufficient. We can't distinguish between X% people use workflow W all the time, and X% people use workflow W from time to time. The problem is that those workflows are used by _projects_ not _people_, so never/rarely/sometimes/often would be IMHO inappropriate. Besides matrix type question cannot have (on Survs.com) other, explain... -- Jakub Narebski -- 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
[Ad] SubGit 1.0 is released
Hello All, Our team is proud and delighted to announce SubGit 1.0 release! New version is available for download at SubGit web site at http://subgit.com/ SubGit is a server-side tool for a smooth, stress-free SVN to Git migration. SubGit lets one to set up a bidirectional Subversion to Git replication (writable mirror) and thus it allows users to choose freely between Subversion and Git version control systems. SubGit is a closed source Java application, which is free for use in Open Source and Academic projects, as well as in any repository with up to 10 committers. Besides, there are no limitations on the time you may evaluate SubGit in commercial or closed source projects. A few useful links: SubGit Web Site: http://subgit.com/ SubGit Book: http://subgit.com/book/ - nice illustrated guide that would help you to install, configure and use SubGit SubGit Issues Tracker: http://issues.tmatesoft.com/issues/SGT We tweet at @subgit and blog at http://blog.subgit.com/ With best regards, Semyon Vadishev, TMate Software, http://subgit.com/ - git-svn bridge! http://svnkit.com/ - Java [Sub]Versioning Library! http://hg4j.com/ - Java Mercurial Library! http://sqljet.com/ - Java SQLite Library! -- 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] Questions for Git User's Survey 2011
Jakub Narębski jna...@gmail.com writes: I have therefore added the following multiple-choice question: #19. What git workflow(s) is used by projects in which development you participate? If we want to have an idea of which workflows are the most commonly used, just a binary answer may be insufficient. We can't distinguish between X% people use workflow W all the time, and X% people use workflow W from time to time. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] commit: configure submodules
Junio C Hamano gits...@pobox.com writes: Jens Lehmann jens.lehm...@web.de writes: Jens, what do you think? I see no reason for anybody other than submodule init to call gitmodules_config() that reads from the in-tree .gitmodules file. I think the copying on init is not what we should do here because it sets the user's customization to what ever happened to be in .gitmodules at the time he initialized the submodule. Hrm, why does the user have submodule.$name.$whatever customized before saying submodule init $whategver for that copying to be problematic? So I think Orgad's change is sane and should go in. Matching what cmd_commit() does to what cmd_status() does, i.e. grab submodule.$name.ignore from somewhere, is not something I questioned. The patch is a good change to make them consistent. What I was wondering was if that is a consistently wrong thing to do to read from .gitmodules not $GIT_DIR/config. In any case, the log message I suggested in the review needs to be updated in the reroll to make it clear that this is about reading from .gitmodules, not configuration. AFAICS, gitmodule_config() does not even read from $GIT_DIR/config, right? OK. gitmodule_config() does not read $GIT_DIR/config, but cmd_status() and cmd_commit() call git_diff_basic_config() that is called from git_diff_ui_config() to read submodule.$name.ignore from it. So Orgad's patch is _only_ about submodule.$name.ignore that is in in-tree .gitmodule; the log message shouldn't mention config, as setting configuration variables work for both status and commit just fine. -- 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
[RFC/PATCH] l10n: de.po: correct translation of a 'rebase' message
Noticed-by: Sascha Cunz sascha...@babbelbox.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- It turns out that one of the 'rebase' messages has a wrong translation. Please review this fix. Thanks The English original is: It seems that there is already a $state_dir_base directory, and\n I wonder if you are in the middle of another rebase. If that is the\n case, please try\n \t$cmd_live_rebase\n If that is not the case, please\n \t$cmd_clear_stale_rebase\n and run me again. I am stopping in case you still have something\n valuable there. po/de.po | 10 +- 1 Datei geändert, 5 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-) diff --git a/po/de.po b/po/de.po index 2739bc0..9e721c0 100644 --- a/po/de.po +++ b/po/de.po @@ -5750,14 +5750,14 @@ msgid and run me again. I am stopping in case you still have something\n valuable there. msgstr -Es scheint so, als gäbe es das Verzeichnis $state_dir_base bereits, und\n -es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. Wenn das\n -der Fall ist, probiere bitte\n +Es sieht so aus, als gibt es das Verzeichnis $state_dir_base bereits\n +und es könnte ein anderer Neuaufbau im Gange sein. Wenn das der Fall ist,\n +probiere bitte\n \t$cmd_live_rebase\n Wenn das nicht der Fall ist, probiere bitte\n \t$cmd_clear_stale_rebase\n -und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n -etwas Nützliches vorhanden ist. +und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n +etwas Schützenswertes vorhanden ist. #: git-rebase.sh:395 #, sh-format -- 1.7.12.396.g7954078 -- 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] Improve the description of GIT_PS1_SHOWUPSTREAM
From: Jonathan \Duke\ Leto jonat...@leto.net Describe what '=' means in the output of __git_ps1 when using GIT_PS1_SHOWUPSTREAM, which was not previously described. Signed-off-by: Jonathan Duke Leto jonat...@leto.net --- contrib/completion/git-prompt.sh | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index 29b1ec9..bf20491 100644 --- a/contrib/completion/git-prompt.sh +++ b/contrib/completion/git-prompt.sh @@ -34,9 +34,10 @@ # # If you would like to see the difference between HEAD and its upstream, # set GIT_PS1_SHOWUPSTREAM=auto. A indicates you are behind, -# indicates you are ahead, and indicates you have diverged. You -# can further control behaviour by setting GIT_PS1_SHOWUPSTREAM to a -# space-separated list of values: +# indicates you are ahead, indicates you have diverged and = +# indicates that there is no difference. You can further control +# behaviour by setting GIT_PS1_SHOWUPSTREAM to a space-separated list +# of values: # # verbose show number of commits ahead/behind (+/-) upstream # legacydon't use the '--count' option available in recent -- 1.7.12.1.397.gbdf37ee -- 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] commit: configure submodules
Am 24.09.2012 18:27, schrieb Junio C Hamano: Junio C Hamano gits...@pobox.com writes: In any case, the log message I suggested in the review needs to be updated in the reroll to make it clear that this is about reading from .gitmodules, not configuration. AFAICS, gitmodule_config() does not even read from $GIT_DIR/config, right? OK. gitmodule_config() does not read $GIT_DIR/config, but cmd_status() and cmd_commit() call git_diff_basic_config() that is called from git_diff_ui_config() to read submodule.$name.ignore from it. So Orgad's patch is _only_ about submodule.$name.ignore that is in in-tree .gitmodule; the log message shouldn't mention config, as setting configuration variables work for both status and commit just fine. Yes, I was just checking that call path too to make sure the user settings from $GIT_DIR/config really override those found in .gitmodules. And of course you are right, while the change to the code is sane the commit message still needs some work. -- 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: submodule: if $command was not matched, don't parse other args
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: OK, I do not think Ramkumar's patch hurts anybody, but dropping the nothing on the command line defaults to 'status' action could. So let's queue the patch as-is at least for now and leave the default discussion to a separarte thread if needed. Please don't do that, because it breaks test 41 in t7400-submodule-bash. I'll add a hunk to remove the test and send a patch tomorrow. I personally see no need waiting for something trivial like this. Isn't it sufficient to squash the following in? Is anything else needed? Documentation/git-submodule.txt | 1 - t/t7400-submodule-basic.sh | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git i/Documentation/git-submodule.txt w/Documentation/git-submodule.txt index 2de7bf0..b4683bb 100644 --- i/Documentation/git-submodule.txt +++ w/Documentation/git-submodule.txt @@ -112,7 +112,6 @@ status:: initialized, `+` if the currently checked out submodule commit does not match the SHA-1 found in the index of the containing repository and `U` if the submodule has merge conflicts. - This command is the default command for 'git submodule'. + If `--recursive` is specified, this command will recurse into nested submodules, and show their status as well. diff --git i/t/t7400-submodule-basic.sh w/t/t7400-submodule-basic.sh index 0278f48..442dc44 100755 --- i/t/t7400-submodule-basic.sh +++ w/t/t7400-submodule-basic.sh @@ -438,8 +438,8 @@ test_expect_success 'moving to a commit without submodule does not leave empty d git checkout second ' -test_expect_success 'submodule invalid-path warns' ' - test_failure_with_unknown_submodule +test_expect_success 'submodule invalid-subcommand fails' ' + test_must_fail git submodule no-such-subcommand ' test_expect_success 'add submodules without specifying an explicit path' ' -- 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] commit: configure submodules
On Mon, Sep 24, 2012 at 8:34 PM, Junio C Hamano gits...@pobox.com wrote: Jens Lehmann jens.lehm...@web.de writes: Am 24.09.2012 18:27, schrieb Junio C Hamano: Junio C Hamano gits...@pobox.com writes: In any case, the log message I suggested in the review needs to be updated in the reroll to make it clear that this is about reading from .gitmodules, not configuration. AFAICS, gitmodule_config() does not even read from $GIT_DIR/config, right? OK. gitmodule_config() does not read $GIT_DIR/config, but cmd_status() and cmd_commit() call git_diff_basic_config() that is called from git_diff_ui_config() to read submodule.$name.ignore from it. So Orgad's patch is _only_ about submodule.$name.ignore that is in in-tree .gitmodule; the log message shouldn't mention config, as setting configuration variables work for both status and commit just fine. Yes, I was just checking that call path too to make sure the user settings from $GIT_DIR/config really override those found in .gitmodules. And of course you are right, while the change to the code is sane the commit message still needs some work. Here is what I tentatively queued on 'pu' (not pushed out yet). -- 8 -- From: Orgad Shaneh org...@gmail.com Date: Sun, 23 Sep 2012 09:37:47 +0200 Subject: [PATCH] commit: pay attention to submodule.$name.ignore in .gitmodules git status does not list a submodule with uncommitted working tree files as modified when submodule.$name.ignore is set to dirty in in-tree .gitmodules file. Both status and commit honor the setting in $GIT_DIR/config, but commit does not pick it up from .gitmodules, which is inconsistent. Teach git commit to pay attention to the setting in .gitmodules as well. Signed-off-by: Orgad Shaneh org...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/commit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/commit.c b/builtin/commit.c index 66fdd22..3cb1ef7 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1256,6 +1256,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix) struct wt_status s; wt_status_prepare(s); + gitmodules_config(); git_config(git_commit_config, s); in_merge = file_exists(git_path(MERGE_HEAD)); s.in_merge = in_merge; -- 1.7.12.1.441.g794a63b That is not correct. git-config is ignored as well for commit. Maybe another fix is needed? - Orgad -- 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 pull transfers useless files
Angelo Borsotti angelo.borso...@gmail.com writes: When it executes the git pull it spends on my computer some 30 seconds, obviously transferring the pdf file, that then it disregards because of the merge=binary attribute. When a commit contains many binary files, the command spends a lot of time needlessly. That is hardly needless nor useless. Unless you are saying that having a large pdf file as binary is useless in your history, that is. After such a merge or squash merge, you still need to be able to say git checkout remote to check out their version to inspect, and you did not have that version of the blob before that git pull. -- 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] commit: configure submodules
Orgad Shaneh org...@gmail.com writes: That is not correct. git-config is ignored as well for commit. What do you mean? As far as I can tell, if you have [submodule var] path = var ignore = dirty in $GIT_DIR/config, a work-tree-dirty submodule var is not reported by git status and git commit without your patch, and your patch does not seem to break that. The only difference your patch makes is that if you had the above three-line block in the .gitmodules file and not in $GIT_DIR/config, git status ignored the dirtyness in the working tree, but git commit did notice and report it. What am I missing? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: configure submodules
On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote: Orgad Shaneh org...@gmail.com writes: That is not correct. git-config is ignored as well for commit. What do you mean? As far as I can tell, if you have [submodule var] path = var ignore = dirty in $GIT_DIR/config, a work-tree-dirty submodule var is not reported by git status and git commit without your patch, and your patch does not seem to break that. The only difference your patch makes is that if you had the above three-line block in the .gitmodules file and not in $GIT_DIR/config, git status ignored the dirtyness in the working tree, but git commit did notice and report it. What am I missing? I have: [submodule mod] url = [...] ignore = dirty in .git/config, and I removed the ignore part from .gitmodules to be even. I made a change inside mod, git status doesn't report its dirtiness, while git commit does. git status: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: .gitmodules # git commit: # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: .gitmodules # modified: mod (modified content) # Now I get it! That's because I don't have submodule.mod.path! config_name_for_path only gets initialized if path exists. Apparently git submodule init doesn't configure 'path', so it stays uninitialized. - Orgad -- 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] submodule: configure submodule.name.path on add and init
In order to read diff options for a submodule, its path must be configured --- git-submodule.sh |2 ++ 1 file changed, 2 insertions(+) diff --git a/git-submodule.sh b/git-submodule.sh index 3e2045e..f97bb62 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -359,6 +359,7 @@ Use -f if you really want to add it. 2 esac ) || die $(eval_gettext Unable to checkout submodule '\$sm_path') fi + git config submodule.$sm_path.path $sm_path git config submodule.$sm_path.url $realrepo git add $force $sm_path || @@ -476,6 +477,7 @@ cmd_init() url=$(resolve_relative_url $url) || exit ;; esac + git config submodule.$name.path $name || git config submodule.$name.url $url || die $(eval_gettext Failed to register url for submodule path '\$sm_path') -- 1.7.10.4 -- 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] submodule: configure submodule.name.path on add and init
On Mon, Sep 24, 2012 at 9:30 PM, Orgad Shaneh org...@gmail.com wrote: In order to read diff options for a submodule, its path must be configured --- git-submodule.sh |2 ++ 1 file changed, 2 insertions(+) diff --git a/git-submodule.sh b/git-submodule.sh index 3e2045e..f97bb62 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -359,6 +359,7 @@ Use -f if you really want to add it. 2 esac ) || die $(eval_gettext Unable to checkout submodule '\$sm_path') fi + git config submodule.$sm_path.path $sm_path git config submodule.$sm_path.url $realrepo git add $force $sm_path || @@ -476,6 +477,7 @@ cmd_init() url=$(resolve_relative_url $url) || exit ;; esac + git config submodule.$name.path $name || git config submodule.$name.url $url || die $(eval_gettext Failed to register url for submodule path '\$sm_path') -- 1.7.10.4 Oops, || should have been - Orgad -- 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] Questions for Git User's Survey 2011
Jakub Narębski jna...@gmail.com writes: On Mon, Sep 24, 2012 at 6:18 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: I have therefore added the following multiple-choice question: #19. What git workflow(s) is used by projects in which development you participate? If we want to have an idea of which workflows are the most commonly used, just a binary answer may be insufficient. We can't distinguish between X% people use workflow W all the time, and X% people use workflow W from time to time. The problem is that those workflows are used by _projects_ not _people_, Yes, but people are usually involved in multiple projects. Someone involved in 10 different distributed projects and sometimes contributing to 1 centralized would count 1 for each. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] Questions for Git User's Survey 2011
On Mon, Sep 24, 2012 at 9:35 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: On Mon, Sep 24, 2012 at 6:18 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jakub Narębski jna...@gmail.com writes: I have therefore added the following multiple-choice question: #19. What git workflow(s) is used by projects in which development you participate? If we want to have an idea of which workflows are the most commonly used, just a binary answer may be insufficient. We can't distinguish between X% people use workflow W all the time, and X% people use workflow W from time to time. The problem is that those workflows are used by _projects_ not _people_, Yes, but people are usually involved in multiple projects. Someone involved in 10 different distributed projects and sometimes contributing to 1 centralized would count 1 for each. , True. So responses wouldn't tell us the full story. But first, never/rarely/sometimes/often/always doesn't fit IMHO here. Second, the situation is more complicated: one can be actively involved in 1 distributed project with 200+ contributors via Gerrit, often contribute to 1 centralized project with 15-25 contributors, and rarely interact with distributed project using blessed repository workflow where number of contributors range from few to few hundred. Too complicated for survey IMHO. Third, no other in matrix form. -- Jakub Narebski -- 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] commit: configure submodules
Am 24.09.2012 21:16, schrieb Orgad Shaneh: On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote: Orgad Shaneh org...@gmail.com writes: That is not correct. git-config is ignored as well for commit. What do you mean? As far as I can tell, if you have [submodule var] path = var ignore = dirty in $GIT_DIR/config, a work-tree-dirty submodule var is not reported by git status and git commit without your patch, and your patch does not seem to break that. The only difference your patch makes is that if you had the above three-line block in the .gitmodules file and not in $GIT_DIR/config, git status ignored the dirtyness in the working tree, but git commit did notice and report it. What am I missing? I have: [submodule mod] url = [...] ignore = dirty in .git/config, and I removed the ignore part from .gitmodules to be even. I made a change inside mod, git status doesn't report its dirtiness, while git commit does. git status: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: .gitmodules # git commit: # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: .gitmodules # modified: mod (modified content) # Now I get it! That's because I don't have submodule.mod.path! config_name_for_path only gets initialized if path exists. Apparently git submodule init doesn't configure 'path', so it stays uninitialized. But submodule.mod.path should only be set in .gitmodules, not in $GIT_DIR/config. Did you just remove the ignore setting from .gitmodules or the path too? -- 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] submodule: configure submodule.name.path on add and init
Am 24.09.2012 21:30, schrieb Orgad Shaneh: In order to read diff options for a submodule, its path must be configured --- git-submodule.sh |2 ++ 1 file changed, 2 insertions(+) diff --git a/git-submodule.sh b/git-submodule.sh index 3e2045e..f97bb62 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -359,6 +359,7 @@ Use -f if you really want to add it. 2 esac ) || die $(eval_gettext Unable to checkout submodule '\$sm_path') fi + git config submodule.$sm_path.path $sm_path git config submodule.$sm_path.url $realrepo git add $force $sm_path || @@ -476,6 +477,7 @@ cmd_init() url=$(resolve_relative_url $url) || exit ;; esac + git config submodule.$name.path $name || git config submodule.$name.url $url || die $(eval_gettext Failed to register url for submodule path '\$sm_path') Nack. The path must only be configured in .gitmodules or we'll never be able to rename the submodule directory. -- 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] commit: configure submodules
On Mon, Sep 24, 2012 at 9:56 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 24.09.2012 21:16, schrieb Orgad Shaneh: On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote: Orgad Shaneh org...@gmail.com writes: That is not correct. git-config is ignored as well for commit. What do you mean? As far as I can tell, if you have [submodule var] path = var ignore = dirty in $GIT_DIR/config, a work-tree-dirty submodule var is not reported by git status and git commit without your patch, and your patch does not seem to break that. The only difference your patch makes is that if you had the above three-line block in the .gitmodules file and not in $GIT_DIR/config, git status ignored the dirtyness in the working tree, but git commit did notice and report it. What am I missing? I have: [submodule mod] url = [...] ignore = dirty in .git/config, and I removed the ignore part from .gitmodules to be even. I made a change inside mod, git status doesn't report its dirtiness, while git commit does. git status: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: .gitmodules # git commit: # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: .gitmodules # modified: mod (modified content) # Now I get it! That's because I don't have submodule.mod.path! config_name_for_path only gets initialized if path exists. Apparently git submodule init doesn't configure 'path', so it stays uninitialized. But submodule.mod.path should only be set in .gitmodules, not in $GIT_DIR/config. Did you just remove the ignore setting from .gitmodules or the path too? Just the ignore, and my patch of course. If it is not set in $GIT_DIR/config, then config_name_for_path is not initialized, and if it is not initialized, then set_diffopt_flags_from_submodule_config does nothing (handle_ignore_submodules_arg is not called). That is the main problem. - Orgad -- 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: Message from 'git-rebase'; German translation
Ralf Thielow schrieb: We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, I wonder if ... is not ich wundere mich (that's a false friend), but Ich frage mich ... and I wonder if you are in the middle of another rebase does not mean ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist, but offenbar / möglicherweise / vermutlich ist ein Neuaufbau bereits im Gange or something like that. Exactly the opposite of the translation, that is. -thh -- 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] commit: configure submodules
Am 24.09.2012 21:59, schrieb Orgad Shaneh: On Mon, Sep 24, 2012 at 9:56 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 24.09.2012 21:16, schrieb Orgad Shaneh: On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote: Orgad Shaneh org...@gmail.com writes: That is not correct. git-config is ignored as well for commit. What do you mean? As far as I can tell, if you have [submodule var] path = var ignore = dirty in $GIT_DIR/config, a work-tree-dirty submodule var is not reported by git status and git commit without your patch, and your patch does not seem to break that. The only difference your patch makes is that if you had the above three-line block in the .gitmodules file and not in $GIT_DIR/config, git status ignored the dirtyness in the working tree, but git commit did notice and report it. What am I missing? I have: [submodule mod] url = [...] ignore = dirty in .git/config, and I removed the ignore part from .gitmodules to be even. I made a change inside mod, git status doesn't report its dirtiness, while git commit does. git status: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: .gitmodules # git commit: # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: .gitmodules # modified: mod (modified content) # Now I get it! That's because I don't have submodule.mod.path! config_name_for_path only gets initialized if path exists. Apparently git submodule init doesn't configure 'path', so it stays uninitialized. But submodule.mod.path should only be set in .gitmodules, not in $GIT_DIR/config. Did you just remove the ignore setting from .gitmodules or the path too? Just the ignore, and my patch of course. If it is not set in $GIT_DIR/config, then config_name_for_path is not initialized, and if it is not initialized, then set_diffopt_flags_from_submodule_config does nothing (handle_ignore_submodules_arg is not called). That is the main problem. But config_name_for_path can only be set via .gitmodules. It is set in parse_submodule_config_option() called by submodule_config() which is called from gitmodules_config() ... but only if .gitmodules doesn't have a merge conflict. So either your .gitmodules has a merge conflict or the logic setting gitmodules_is_unmerged in gitmodules_config() is buggy. -- 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] l10n: de.po: correct translation of a 'rebase' message
Ralf Thielow ralf.thie...@gmail.com writes:
Noticed-by: Sascha Cunz sascha...@babbelbox.org
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
[...]
The English original is:
It seems that there is already a $state_dir_base directory, and\n
I wonder if you are in the middle of another rebase. If that is the\n
case, please try\n
\t$cmd_live_rebase\n
If that is not the case, please\n
\t$cmd_clear_stale_rebase\n
and run me again. I am stopping in case you still have something\n
valuable there.
[...]
-Es scheint so, als gäbe es das Verzeichnis $state_dir_base bereits, und\n
-es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. Wenn das\n
-der Fall ist, probiere bitte\n
+Es sieht so aus, als gibt es das Verzeichnis $state_dir_base bereits\n
Not very elegant yet, shouldn't it say something like
als ob es das Verzeichnis ... bereits {gibt,gäbe}
?
+und es könnte ein anderer Neuaufbau im Gange sein. Wenn das der Fall ist,\n
+probiere bitte\n
\t$cmd_live_rebase\n
Wenn das nicht der Fall ist, probiere bitte\n
\t$cmd_clear_stale_rebase\n
-und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n
-etwas Nützliches vorhanden ist.
+und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n
+etwas Schützenswertes vorhanden ist.
Thanks Ralf and Sascha.
Please don't see this as a reason to fight the (i.e. Ralf's, for the
most part) translation. It is definitely a mistake, but not any more so
than any other bug. In fact, it went through review here
http://thread.gmane.org/gmane.comp.version-control.git/202784
where I too (sorry) missed this, even as I pointed out several other
things. Then it went into the pull request
http://thread.gmane.org/gmane.comp.version-control.git/203153
So for me the main take-away is that just like with code, review helps
catch some things early but bugs still get through. More eyeballs would
certainly be appreciated.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] commit: configure submodules
Jens Lehmann jens.lehm...@web.de writes: But submodule.mod.path should only be set in .gitmodules, not in $GIT_DIR/config. Did you just remove the ignore setting from .gitmodules or the path too? Without that in $GIT_DIR/config, how would path-name mapping correctly work??? Confused... -- 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
[PATCHv2] l10n: de.po: correct translation of one 'rebase' message
Noticed-by: Sascha Cunz sascha...@babbelbox.org
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Not very elegant yet, shouldn't it say something like
als ob es das Verzeichnis ... bereits {gibt,gäbe}
?
Yes, thanks.
po/de.po | 10 +-
1 Datei geändert, 5 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/po/de.po b/po/de.po
index 2739bc0..a3cf695 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5750,14 +5750,14 @@ msgid
and run me again. I am stopping in case you still have something\n
valuable there.
msgstr
-Es scheint so, als gäbe es das Verzeichnis $state_dir_base bereits, und\n
-es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. Wenn das\n
-der Fall ist, probiere bitte\n
+Es sieht so aus, als ob es das Verzeichnis $state_dir_base bereits gibt\n
+und es könnte ein anderer Neuaufbau im Gange sein. Wenn das der Fall ist,\n
+probiere bitte\n
\t$cmd_live_rebase\n
Wenn das nicht der Fall ist, probiere bitte\n
\t$cmd_clear_stale_rebase\n
-und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n
-etwas Nützliches vorhanden ist.
+und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n
+etwas Schützenswertes vorhanden ist.
#: git-rebase.sh:395
#, sh-format
--
1.7.12.396.g7954078
--
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] silence git gc --auto --quiet output
Tobias Ulmer tobi...@tmux.org writes: When --quiet is requested, gc --auto should not display messages unless there is an error. Signed-off-by: Tobias Ulmer tobi...@tmux.org --- builtin/gc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/builtin/gc.c b/builtin/gc.c index 6d46608..6be6c8d 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -217,9 +217,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix) */ if (!need_to_gc()) return 0; - if (quiet) - fprintf(stderr, _(Auto packing the repository for optimum performance.\n)); - else + if (!quiet) fprintf(stderr, _(Auto packing the repository for optimum performance. You may also\n run \git gc\ manually. See This patch will break t5400; the test needs to be updated in the same patch to check auto-gc kicks in when it should in some other way. The test currently _relies_ on this message to see the gc is triggered. -- 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] silence git gc --auto --quiet output
Junio C Hamano gits...@pobox.com writes: Tobias Ulmer tobi...@tmux.org writes: When --quiet is requested, gc --auto should not display messages unless there is an error. Signed-off-by: Tobias Ulmer tobi...@tmux.org --- builtin/gc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/builtin/gc.c b/builtin/gc.c index 6d46608..6be6c8d 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -217,9 +217,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix) */ if (!need_to_gc()) return 0; -if (quiet) -fprintf(stderr, _(Auto packing the repository for optimum performance.\n)); -else +if (!quiet) fprintf(stderr, _(Auto packing the repository for optimum performance. You may also\n run \git gc\ manually. See This patch will break t5400; the test needs to be updated in the same patch to check auto-gc kicks in when it should in some other way. The test currently _relies_ on this message to see the gc is triggered. I suspect that the following may be sufficient. The test prepares a stale garbage file in the repository an auto-gc is expected to happen, and makes sure the garbage file is removed after the operation that expects to trigger an auto-gc. The detection of the message is more or less superfluous. t/t5400-send-pack.sh | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git i/t/t5400-send-pack.sh w/t/t5400-send-pack.sh index 250c720..78ab177 100755 --- i/t/t5400-send-pack.sh +++ w/t/t5400-send-pack.sh @@ -174,8 +174,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' ' cd parent echo Even more text file.txt git commit -a -m Third commit - git send-pack ../child HEAD:refs/heads/test_auto_gc output 21 - grep Auto packing the repository for optimum performance. output + git send-pack ../child HEAD:refs/heads/test_auto_gc ) test ! -e child/.git/objects/tmp_test_object ' -- 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
[RFC/PATCH 0/3] git log --pretty=lua
We've talked off and on about extending the --pretty=format specifiers to something more flexible. There's also been talk recently of more flexible commit-filtering (e.g., grepping individual notes). Rather than invent a new Turing-complete language, I thought I'd try building on somebody else's work by embedding an existing language. Why Lua? I don't especially like it as a language. But it's designed for this purpose, which makes it very lightweight and relatively simple to embed. Here are timing results for a few log commands (best-of-five, warm cache): $ git log --oneline /dev/null real0m1.042s user0m0.660s sys 0m0.372s $ git log --tformat:%h %s /dev/null real0m1.039s user0m0.624s sys 0m0.396s $ git log --pretty=lua:'return abbrev(hash()) .. .. subject()' real0m1.112s user0m0.716s sys 0m0.388s So you can see that we're a little bit slower than the existing format, but not too much. There may well be some optimizations we can do, too. This is the first time I've ever played with embedding Lua, so I would not be surprised if I got something wrong or suboptimal. The syntax, on the other hand...yuck. One thing that makes Lua horrible for this use is that it does not have interpolated strings. However, there are template libraries for Lua, so maybe there's something there. The patches are: [1/3]: pretty: make some commit-parsing helpers more public [2/3]: add basic lua infrastructure [3/3]: add a lua pretty format And a 4/3 patch would probably add --lua-filter as a revision option for limiting commits. The patches are very rough and not meant to be applied. For me, this was a bit of an experiment. I'm not sure if I like it or not. It seems like a cool direction to go, but to be perfectly honest, I do not generally feel like git's existing filtering or output are inadequate (sure, it's slower to pipe --pretty=raw out to a separate perl filter and then do fancy formatting, but it's usually fast enough, and it's very flexible). So I don't have plans to work on it more any time soon, but I thought I'd share in case anybody is interested. And if somebody wants to pick up the topic and run with it, I'd be happy to help. -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/3] pretty: make some commit-parsing helpers more public
This is a quick hack to make these functions available for
the lua code. It would be way cleaner to move all of the
incremental parsing bits to format-commit.[ch] and clean up
the names (e.g., struct chunk is not nearly descriptive
enough for a global).
Signed-off-by: Jeff King p...@peff.net
---
commit.h | 36
pretty.c | 38 ++
2 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/commit.h b/commit.h
index 9f21313..71cd4af 100644
--- a/commit.h
+++ b/commit.h
@@ -126,6 +126,42 @@ void pp_remainder(const struct pretty_print_context *pp,
struct strbuf *sb,
int indent);
+struct chunk {
+ size_t off;
+ size_t len;
+};
+
+struct format_commit_context {
+ const struct commit *commit;
+ const struct pretty_print_context *pretty_ctx;
+ unsigned commit_header_parsed:1;
+ unsigned commit_message_parsed:1;
+ unsigned commit_signature_parsed:1;
+ struct {
+ char *gpg_output;
+ char good_bad;
+ char *signer;
+ } signature;
+ char *message;
+ size_t width, indent1, indent2;
+
+ /* These offsets are relative to the start of the commit message. */
+ struct chunk author;
+ struct chunk committer;
+ struct chunk encoding;
+ size_t message_off;
+ size_t subject_off;
+ size_t body_off;
+
+ /* The following ones are relative to the result struct strbuf. */
+ struct chunk abbrev_commit_hash;
+ struct chunk abbrev_tree_hash;
+ struct chunk abbrev_parent_hashes;
+ size_t wrap_start;
+};
+
+void parse_commit_header(struct format_commit_context *);
+void parse_commit_message(struct format_commit_context *);
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..0d4eb3d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -612,40 +612,6 @@ skip:
return 0; /* unknown placeholder */
}
-struct chunk {
- size_t off;
- size_t len;
-};
-
-struct format_commit_context {
- const struct commit *commit;
- const struct pretty_print_context *pretty_ctx;
- unsigned commit_header_parsed:1;
- unsigned commit_message_parsed:1;
- unsigned commit_signature_parsed:1;
- struct {
- char *gpg_output;
- char good_bad;
- char *signer;
- } signature;
- char *message;
- size_t width, indent1, indent2;
-
- /* These offsets are relative to the start of the commit message. */
- struct chunk author;
- struct chunk committer;
- struct chunk encoding;
- size_t message_off;
- size_t subject_off;
- size_t body_off;
-
- /* The following ones are relative to the result struct strbuf. */
- struct chunk abbrev_commit_hash;
- struct chunk abbrev_tree_hash;
- struct chunk abbrev_parent_hashes;
- size_t wrap_start;
-};
-
static int add_again(struct strbuf *sb, struct chunk *chunk)
{
if (chunk-len) {
@@ -663,7 +629,7 @@ static int add_again(struct strbuf *sb, struct chunk *chunk)
return 0;
}
-static void parse_commit_header(struct format_commit_context *context)
+void parse_commit_header(struct format_commit_context *context)
{
const char *msg = context-message;
int i;
@@ -749,7 +715,7 @@ const char *format_subject(struct strbuf *sb, const char
*msg,
return msg;
}
-static void parse_commit_message(struct format_commit_context *c)
+void parse_commit_message(struct format_commit_context *c)
{
const char *msg = c-message + c-message_off;
const char *start = c-message;
--
1.7.12.1.10.g6537447
--
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/3] add basic lua infrastructure
This adds a small module for examining parts of a commit
from inside a lua interpreter. Eventually you'll be able to
do grep-like filtering and --pretty formatting.
The most naive presentation would be to parse the whole
commit and put it in a lua table. However, instead we build
upon the incremental parsing used by the --format parser,
and lazily parse bits of the commit as the lua code requests
them.
Signed-off-by: Jeff King p...@peff.net
---
Set USE_LUA in your Makefile to turn it on.
Makefile | 7 +++
lua-commit.c | 166 +++
lua-commit.h | 9
3 files changed, 182 insertions(+)
create mode 100644 lua-commit.c
create mode 100644 lua-commit.h
diff --git a/Makefile b/Makefile
index a49d1db..54473e2 100644
--- a/Makefile
+++ b/Makefile
@@ -636,6 +636,7 @@ LIB_H += log-tree.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
+LIB_H += lua-commit.h
LIB_H += mailmap.h
LIB_H += merge-file.h
LIB_H += merge-recursive.h
@@ -749,6 +750,7 @@ LIB_OBJS += log-tree.o
LIB_OBJS += ll-merge.o
LIB_OBJS += lockfile.o
LIB_OBJS += log-tree.o
+LIB_OBJS += lua-commit.o
LIB_OBJS += mailmap.o
LIB_OBJS += match-trees.o
LIB_OBJS += merge-file.o
@@ -1818,6 +1820,11 @@ endif
COMPAT_OBJS += compat/nedmalloc/nedmalloc.o
endif
+ifdef USE_LUA
+ BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2`
+ EXTLIBS += `pkg-config --libs lua5.2`
+endif
+
ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT
export GIT_TEST_CMP_USE_COPIED_CONTEXT
endif
diff --git a/lua-commit.c b/lua-commit.c
new file mode 100644
index 000..ce1eeeb
--- /dev/null
+++ b/lua-commit.c
@@ -0,0 +1,166 @@
+#include cache.h
+#include lua-commit.h
+#include commit.h
+
+#ifndef USE_LUA
+
+static const char msg[] = git was built without lua support;
+
+void lua_commit_init(const char *)
+{
+ die(msg);
+}
+
+void lua_commit_format(struct strbuf *,
+ struct format_commit_context *)
+{
+ die(msg);
+}
+
+#else
+
+#include lua.h
+#include lauxlib.h
+#include lualib.h
+
+static lua_State *lua;
+
+/* XXX
+ * We need to access this from functions called from inside lua. Probably it
+ * would be cleaner use a lua register to let each function access it, but I
+ * haven't looked into it.
+ */
+static struct format_commit_context *c;
+
+static int lua_fun_hash(lua_State *lua)
+{
+ lua_pushstring(lua, sha1_to_hex(c-commit-object.sha1));
+ return 1;
+}
+
+static int lua_fun_abbrev(lua_State *lua)
+{
+ const char *hex;
+ unsigned char sha1[20];
+
+ hex = lua_tostring(lua, -1);
+ if (!hex || get_sha1_hex(hex, sha1)) {
+ lua_pushstring(lua, abbrev requires a sha1);
+ lua_error(lua);
+ }
+
+ lua_pushstring(lua, find_unique_abbrev(sha1, c-pretty_ctx-abbrev));
+ return 1;
+}
+
+static int get_ident(lua_State *lua, const char *line, int len)
+{
+ struct ident_split s;
+
+ if (split_ident_line(s, line, len) 0) {
+ lua_pushstring(lua, unable to parse ident line);
+ lua_error(lua);
+ }
+
+ lua_createtable(lua, 0, 2);
+ lua_pushstring(lua, name);
+ lua_pushlstring(lua, s.name_begin, s.name_end - s.name_begin);
+ lua_settable(lua, -3);
+ lua_pushstring(lua, email);
+ lua_pushlstring(lua, s.mail_begin, s.mail_end - s.mail_begin);
+ lua_settable(lua, -3);
+
+ /* XXX should also put date in the table */
+
+ return 1;
+}
+
+static int lua_fun_author(lua_State *lua)
+{
+ if (!c-commit_header_parsed)
+ parse_commit_header(c);
+ return get_ident(lua, c-message + c-author.off, c-author.len);
+}
+
+static int lua_fun_committer(lua_State *lua)
+{
+ if (!c-commit_header_parsed)
+ parse_commit_header(c);
+ return get_ident(lua, c-message + c-committer.off, c-committer.len);
+}
+
+static int lua_fun_message(lua_State *lua)
+{
+ lua_pushstring(lua, c-message + c-message_off + 1);
+ return 1;
+}
+
+static int lua_fun_subject(lua_State *lua)
+{
+ struct strbuf tmp = STRBUF_INIT;
+
+ if (!c-commit_header_parsed)
+ parse_commit_header(c);
+ if (!c-commit_message_parsed)
+ parse_commit_message(c);
+
+ format_subject(tmp, c-message + c-subject_off, );
+ lua_pushlstring(lua, tmp.buf, tmp.len);
+ return 1;
+}
+
+static int lua_fun_body(lua_State *lua)
+{
+ if (!c-commit_header_parsed)
+ parse_commit_header(c);
+ if (!c-commit_message_parsed)
+ parse_commit_message(c);
+
+ lua_pushstring(lua, c-message + c-body_off);
+ return 1;
+}
+
+void lua_commit_init(const char *snippet)
+{
+ if (!lua) {
+ lua = luaL_newstate();
+ if (!lua)
+ die(unable to open lua interpreter);
+ luaL_openlibs(lua);
+
+#define REG(name) do { \
+
[PATCH 3/3] add a lua pretty format
With this patch, you can do:
git log --pretty=lua:'
return abbrev(hash()) .. ( .. author().email .. ) .. subject()
'
Signed-off-by: Jeff King p...@peff.net
---
commit.h | 1 +
log-tree.c | 3 ++-
pretty.c | 21 +++--
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/commit.h b/commit.h
index 71cd4af..8865a36 100644
--- a/commit.h
+++ b/commit.h
@@ -73,6 +73,7 @@ enum cmit_fmt {
CMIT_FMT_ONELINE,
CMIT_FMT_EMAIL,
CMIT_FMT_USERFORMAT,
+ CMIT_FMT_LUA,
CMIT_FMT_UNSPECIFIED
};
diff --git a/log-tree.c b/log-tree.c
index c894930..c8274d1 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -599,7 +599,8 @@ void show_log(struct rev_info *opt)
if (opt-commit_format == CMIT_FMT_EMAIL) {
log_write_email_headers(opt, commit, ctx.subject,
extra_headers,
ctx.need_8bit_cte);
- } else if (opt-commit_format != CMIT_FMT_USERFORMAT) {
+ } else if (opt-commit_format != CMIT_FMT_USERFORMAT
+ opt-commit_format != CMIT_FMT_LUA) {
fputs(diff_get_color_opt(opt-diffopt, DIFF_COMMIT), stdout);
if (opt-commit_format != CMIT_FMT_ONELINE)
fputs(commit , stdout);
diff --git a/pretty.c b/pretty.c
index 0d4eb3d..fdd4258 100644
--- a/pretty.c
+++ b/pretty.c
@@ -10,6 +10,7 @@
#include color.h
#include reflog-walk.h
#include gpg-interface.h
+#include lua-commit.h
static char *user_format;
static struct cmt_fmt_map {
@@ -33,6 +34,13 @@ static void save_user_format(struct rev_info *rev, const
char *cp, int is_tforma
rev-commit_format = CMIT_FMT_USERFORMAT;
}
+static void save_lua_format(struct rev_info *rev, const char *cp, int
is_tformat)
+{
+ lua_commit_init(cp);
+ save_user_format(rev, cp, is_tformat);
+ rev-commit_format = CMIT_FMT_LUA;
+}
+
static int git_pretty_formats_config(const char *var, const char *value, void
*cb)
{
struct cmt_fmt_map *commit_format = NULL;
@@ -155,6 +163,10 @@ void get_commit_format(const char *arg, struct rev_info
*rev)
save_user_format(rev, strchr(arg, ':') + 1, arg[0] == 't');
return;
}
+ if (!prefixcmp(arg, lua:)) {
+ save_lua_format(rev, arg + 4, 1);
+ return;
+ }
if (strchr(arg, '%')) {
save_user_format(rev, arg, 1);
@@ -1168,7 +1180,11 @@ void format_commit_message(const struct commit *commit,
free(enc);
}
- strbuf_expand(sb, format, format_commit_item, context);
+ if (pretty_ctx-fmt == CMIT_FMT_USERFORMAT)
+ strbuf_expand(sb, format, format_commit_item, context);
+ else if (pretty_ctx-fmt == CMIT_FMT_LUA)
+ lua_commit_format(sb, context);
+
rewrap_message_tail(sb, context, 0, 0, 0);
if (context.message != commit-buffer)
@@ -1328,7 +1344,8 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
const char *encoding;
int need_8bit_cte = pp-need_8bit_cte;
- if (pp-fmt == CMIT_FMT_USERFORMAT) {
+ if (pp-fmt == CMIT_FMT_USERFORMAT ||
+ pp-fmt == CMIT_FMT_LUA) {
format_commit_message(commit, user_format, sb, pp);
return;
}
--
1.7.12.1.10.g6537447
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/2] pretty: support right alignment
On Sun, Sep 23, 2012 at 01:17:43AM -0700, Junio C Hamano wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: ... On the other hand, I don't really wish to turn pretty format machinery into a full feature text layout engine (by ripping of links/lynx?). That is very true. We should restrain ourselves and avoid going overboard piling shiny new toys on a not-so-useful foundation that is not expressive enough. One feature that is probably much more needed on the foundation side would be some form of conditional output, without which built-in output elements like --show-notes cannot be emulated with --format option. The embedded lua patch series I just posted may interest (or horrify) the both of you: http://article.gmane.org/gmane.comp.version-control.git/206335 -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: Quickly searching for a note
On Sat, Sep 22, 2012 at 01:23:56PM -0700, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: On my mental scratch pad (yeah, that's where the bald spots are) I have the following more general idea to enhance the revision parser: --limit-run=script:: --run=script::: These options run the script `script` on each revision that is walked. The script is run in an environment which has the variables `GIT_SPECIFIER` exported, where `SPECIFIER` is any of the specifiers for the `--format` option in the long format (the same as for 'git for-each-ref'). In the case of `--limit-run`, the return code of `script` decides whether the commit is processed further (i.e. shown using the format in effect) or ignored. You could argue that the above is not an inpractical solution as long as the user of --run, which spawns a new process every time we need to check if a commit is worth showing in the log/rev-list stream, knows what she is doing and promises not to complain that it is no more performant than an external script that reads from rev-list output and does the equivalent filtering. I personally am not very enthused. Nor me. I experimented long ago with a perl pipeline that would parse commit messages and allow Turing-complete grepping. I recall it was noticeably slow. I cannot imagine what forking for each commit would be like. Actually, wait, I can imagine it. Git has ~33K commits. Doing 'sh -c exit' takes on the order of .002s. That's a minute of processing to look at each commit in git log, assuming the filtering itself takes 0 seconds. If we linked with an embeddable scripting language interpreter (e.g. lua, tcl, guile, ...), it may be a more practical enhancement, though. Agreed. I just posted a patch series that gives you --pretty lua support, though I haven't convinced myself it's all that exciting yet. I think it would be nicer for grepping, where the conditionals read more like regular code. Something like: git log --lua-filter=' return author().name.match(Junio) note(p4).match(1234567) ' reads OK to me. -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: Quickly searching for a note
On Sun, Sep 23, 2012 at 05:07:04PM +0200, Michael J Gruber wrote: If we linked with an embeddable scripting language interpreter (e.g. lua, tcl, guile, ...), it may be a more practical enhancement, though. Yes, the idea is extend, don't embed the other way round, so to say. I still think extending git log so that it can call a script with commit info already in the environment gives a more convenient approach then embedding git rev-list into your own script. It's not more performant, of course. I think Junio is going the other way than you think. That is, you still run rev-list, but rather than call a sub-program, you call a snippet of an embeddable script. Which is the same idea as yours, but theoretically way faster. I just see many more requests of the type grep notes coming, i.e. limitting based on other commit info, or in a different way then already possible. Just image you want to find out who's responsible for those commits in git.git with subject lengths 100 ;) Like this: git log --lua-filter='return subject().len 100' ? :) -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 2/3] add basic lua infrastructure
On Tue, Sep 25, 2012 at 7:25 AM, Jeff King p...@peff.net wrote: +ifdef USE_LUA + BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2` + EXTLIBS += `pkg-config --libs lua5.2` +endif + I remember we paid noticeable penalty when linking with libcurl to main git binary and Linus removed libcurl from main git, moving it to git-http-*. Do we pay similar penalty linking to liblua? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] add basic lua infrastructure
On Mon, Sep 24, 2012 at 08:25:12PM -0400, Jeff King wrote: +ifdef USE_LUA + BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2` + EXTLIBS += `pkg-config --libs lua5.2` +endif Can you please hoist the packagename out to a variable? It's just plain lua on Gentoo. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- 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] Revert completion: fix shell expansion of items
On Thu, Sep 20, 2012 at 08:11:52PM +0200, SZEDER Gábor wrote:
Solves the original problem for me.
Me too. Thanks.
While it solves the original problem, it seems to break refs
completion, as demonstrated by the following POC test:
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 92d7eb47..fab63b95 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -228,4 +228,11 @@ test_expect_success 'general options plus command' '
test_completion git --no-replace-objects check checkout
'
+test_expect_success 'basic refs completion' '
+ touch file
+ git add file
+ git commit -m initial
+ test_completion git branch m master
+'
+
Yeah, doing git checkout jk/tab is not working at all, and I noticed
the buggy commit is on the maint track, but has not yet been released.
I'm not sure of the solution, but I think we should do this in the
meantime:
-- 8 --
Subject: Revert completion: fix shell expansion of items
This reverts commit 25ae7cfd19c8f21721363c64163cd5d9d1135b20.
That patch does fix expansion of weird variables in some
simple tests, but it also seems to break other things, like
expansion of refs by git checkout.
While we're sorting out the correct solution, we are much
better with the original bug (people with metacharacters in
their completions occasionally see an error message) than
the current bug (ref completion does not work at all).
Signed-off-by: Jeff King p...@peff.net
---
contrib/completion/git-completion.bash | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5a5b5a0..d743e56 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,13 +225,6 @@ fi
fi
fi
-# Quotes the argument for shell reuse
-__git_quote()
-{
- local quoted=${1//\'/\'\\\'\'}
- printf '%s' $quoted
-}
-
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -268,7 +261,7 @@ __gitcomp_nl ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $(__git_quote $1) --
${3-$cur}))
+ COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
__git_heads ()
--
1.7.12.1.17.g7286916
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] add basic lua infrastructure
On Tue, Sep 25, 2012 at 08:55:23AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Sep 25, 2012 at 7:25 AM, Jeff King p...@peff.net wrote:
+ifdef USE_LUA
+ BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2`
+ EXTLIBS += `pkg-config --libs lua5.2`
+endif
+
I remember we paid noticeable penalty when linking with libcurl to
main git binary and Linus removed libcurl from main git, moving it to
git-http-*. Do we pay similar penalty linking to liblua?
I don't think so. The real problem with libcurl is that it brings in a
ton of other libraries:
$ ldd /usr/lib/x86_64-linux-gnu/libcurl.so | awk '{print $1}'
linux-vdso.so.1
libidn.so.11
libssh2.so.1
liblber-2.4.so.2
libldap_r-2.4.so.2
librt.so.1
libgssapi_krb5.so.2
libssl.so.1.0.0
libcrypto.so.1.0.0
librtmp.so.0
libz.so.1
libc.so.6
libgcrypt.so.11
libresolv.so.2
libsasl2.so.2
libgnutls.so.26
libpthread.so.0
/lib64/ld-linux-x86-64.so.2
libkrb5.so.3
libk5crypto.so.3
libcom_err.so.2
libkrb5support.so.0
libdl.so.2
libkeyutils.so.1
libgpg-error.so.0
libtasn1.so.3
libp11-kit.so.0
Compare with lua:
$ ldd /usr/lib/x86_64-linux-gnu/liblua5.2.so | awk '{print $1}'
linux-vdso.so.1
libm.so.6
libdl.so.2
libc.so.6
/lib64/ld-linux-x86-64.so.2
The original timings from Linus are here:
http://article.gmane.org/gmane.comp.version-control.git/123946
The main issue is really hitting all those libraries on a cold cache.
Here are before-and-after timings of:
echo 3 /proc/sys/vm/drop_caches git
which should basically just measure startup time. All times are
best-of-five.
[before]
real0m0.065s
user0m0.000s
sys 0m0.004s
[after]
real0m0.063s
user0m0.000s
sys 0m0.004s
So we actually did better, though the difference is well within the
run-to-run noise. I don't think it's a big deal.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git: expand user path in --git-dir
On Monday 2012-09-24 14:57, Michael J Gruber wrote: Currently, all paths in the config file are subject to tilde expansion for user paths while the argument to --git-dir is not expanded, and neither are paths in the environment such as GIT_DIR. From the user perspective, though, the two commands GIT_DIR=~user/foo git command git --git-dir=~user/foo command currently behave differently because in the first case the shell would perform tilde expansion, but not in the second. If git uses a standardized option logic (getopt-like) which accepts both '=' and (new argument) for long options, you could easily do git --git-dir ~user/foo command -- 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
