Re: Getting started contributing.
On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano gits...@pobox.com wrote: On the other hand, there probably still are many loose ends. A few other things - Mark more strings for translation (not as easy as it sounds, some strings can't be translated) - Color more in the output where it makes sense - Stop/Warn the user from updating HEAD (e.g. checkout another branch) while in the middle of a rebase (some makes sense, most is by mistake) PS. You are welcome to improve my two patches Junio mentioned. I don't think it overlaps much with git rebase --status though. Printing the remaining steps, or what patch being applied is not going to be done by git status. -- 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: What's cooking in git.git (Feb 2013, #01; Fri, 1)
On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Regarding these two topics * da/mergetool-docs (2013-01-30) 7 commits - doc: generate a list of valid merge tools - mergetool--lib: list user configured tools in '--tool-help' - fixup! doc: generate a list of valid merge tools - fixup! mergetool--lib: add functions for finding available tools - mergetool--lib: add functions for finding available tools - mergetool--lib: improve the help text in guess_merge_tool() - mergetool--lib: simplify command expressions (this branch uses jk/mergetool.) Build on top of the clean-up done by jk/mergetool and automatically generate the list of mergetool and difftool backends the build supports to be included in the documentation. Will merge to 'next', after squashing the fixup! commits from John Keeping. * jk/mergetool (2013-01-28) 8 commits - mergetools: simplify how we handle vim and defaults - mergetool--lib: don't call exit in setup_tool - mergetool--lib: improve show_tool_help() output - mergetools/vim: remove redundant diff command - git-difftool: use git-mergetool--lib for --tool-help - git-mergetool: don't hardcode 'mergetool' in show_tool_help - git-mergetool: remove redundant assignment - git-mergetool: move show_tool_help to mergetool--lib (this branch is used by da/mergetool-docs.) Cleans up mergetool/difftool combo. This is looking ready for 'next'. Do the tips of these two topics look reasonable to both of you, or are there anything you sent but I missed? It looks good to go. The additional || : in the makefile is a nice touchup that made it more robust too. -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote: On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Regarding these two topics * da/mergetool-docs (2013-01-30) 7 commits - doc: generate a list of valid merge tools - mergetool--lib: list user configured tools in '--tool-help' - fixup! doc: generate a list of valid merge tools - fixup! mergetool--lib: add functions for finding available tools - mergetool--lib: add functions for finding available tools - mergetool--lib: improve the help text in guess_merge_tool() - mergetool--lib: simplify command expressions (this branch uses jk/mergetool.) Build on top of the clean-up done by jk/mergetool and automatically generate the list of mergetool and difftool backends the build supports to be included in the documentation. Will merge to 'next', after squashing the fixup! commits from John Keeping. * jk/mergetool (2013-01-28) 8 commits - mergetools: simplify how we handle vim and defaults - mergetool--lib: don't call exit in setup_tool - mergetool--lib: improve show_tool_help() output - mergetools/vim: remove redundant diff command - git-difftool: use git-mergetool--lib for --tool-help - git-mergetool: don't hardcode 'mergetool' in show_tool_help - git-mergetool: remove redundant assignment - git-mergetool: move show_tool_help to mergetool--lib (this branch is used by da/mergetool-docs.) Cleans up mergetool/difftool combo. This is looking ready for 'next'. Do the tips of these two topics look reasonable to both of you, or are there anything you sent but I missed? It looks good to go. The additional || : in the makefile is a nice touchup that made it more robust too. Looks good to me as well. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started contributing.
From: Junio C Hamano gits...@pobox.com Sent: Sunday, February 03, 2013 7:49 AM adamfraser adamfras...@gmail.com writes: I've done a little searching and haven't been able to find an official bug tracker for git is there somewhere I can find some bugs to help fix? You came to the right place. A new bug or regression is reported to this list, and it often is fixed (or often diagnosed as pebcak) fairly quickly by list regulars. Nobody maintains a bugzilla that is not maintained and is full of stale/invalid bug reports. The best contribution a new person can make is to use the software regularly and find issues. It is very hard to find real bugs that can easily be fixed by somebody totally new to the codebase in Git these days. On the other hand, there probably still are many loose ends. When a command is supposed to take only two arguments because taking more than three does not make any sense, for example, it has not been unusual for us to document the two-argument form of the command, reject if the user gives only one argument with an error message, but we simply ignore the third argument if the user mistakenly runs the command with three arguments, instead of erroring out (i.e. the code does not bother to help insane or too inexperienced users). That kind of things are hard to find by users experienced with Git exactly because they know running such a command with three or more arguments is nonsense, and they do not even try to make such a mistake. Still, it would be very nice to find and fix such issues. A review of the git-user list https://groups.google.com/forum/?fromgroups#!forum/git-users is one place to discover some of the user issues and thinking about how to address them. Or resurrect issues from this Git list. E.g. There are a number of sub-module improvements available there. If you have any Windows experience the MSysGit team https://github.com/msysgit/msysgit is always looking for help on some of the compatibility issues, e.g. where the Linux optimisations conflict with the Windows approaches. Another area is picking out documentation issues you have seen and submitting patches for them, whether in the command man pages or in the guides. On my 'todo' list is to make the `help` command actually list the Help me (i.e. guides and articles) pages, not just the command man pages. I also had - * Bulk move detection (when folk change/move upper level directory names). * add a .gitnevermerge option to stop private files you don't want in 'master' (or any other branch) to be merged Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature request: Allow extracting revisions into directories
Hello! git currently has the archive command that allows to save an arbitrary revision into a tar or zip file. Sometimes it is useful to not save this revision into an archive but to directly put all files into an arbitrary directory. Currently this seems to be not possible to archive directly; the only way I found to do it is to run git archive and then directly unpack the archive into a directory. git --git-dir REPO archive REVISION | tar x It would be nice to have a command or simply a switch to git archive that allows the user to put the files of REVISION into a directory instead of making an archive. Thank you very much for your help. Yours, Robert Clausecker signature.asc Description: This is a digitally signed message part
[PATCH 0/3] Make Git compile warning-free with Clang
The first two patches here were sent to the list before but seem to have got lost in the noise [1][2]. The final one is new but was prompted by discussion in the same thread. After applying all of these patches, I don't see any warnings compiling Git with Clang 3.2. [1] http://article.gmane.org/gmane.comp.version-control.git/213817 [2] http://article.gmane.org/gmane.comp.version-control.git/213849 Antoine Pelisse (1): fix clang -Wtautological-compare with unsigned enum John Keeping (2): combine-diff: suppress a clang warning builtin/apply: tighten (dis)similarity index parsing builtin/apply.c | 10 ++ combine-diff.c | 2 +- grep.c | 3 ++- grep.h | 3 ++- 4 files changed, 11 insertions(+), 7 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] fix clang -Wtautological-compare with unsigned enum
From: Antoine Pelisse apeli...@gmail.com
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Clang warning happens because the enum is unsigned (this is
implementation-defined, and there is no negative fields) and the check
is then tautological.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
grep.c | 3 ++-
grep.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 4bd1b8b..bb548ca 100644
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
for (p = opt-header_list; p; p = p-next) {
if (p-token != GREP_PATTERN_HEAD)
die(bug: a non-header pattern in grep header list.);
- if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field)
+ if (p-field GREP_HEADER_FIELD_MIN ||
+ GREP_HEADER_FIELD_MAX = p-field)
die(bug: unknown header field %d, p-field);
compile_regexp(p, opt);
}
diff --git a/grep.h b/grep.h
index 8fc854f..e4a1df5 100644
--- a/grep.h
+++ b/grep.h
@@ -28,7 +28,8 @@ enum grep_context {
};
enum grep_header_field {
- GREP_HEADER_AUTHOR = 0,
+ GREP_HEADER_FIELD_MIN = 0,
+ GREP_HEADER_AUTHOR = GREP_HEADER_FIELD_MIN,
GREP_HEADER_COMMITTER,
GREP_HEADER_REFLOG,
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] combine-diff: suppress a clang warning
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~^~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
[ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = COLONS[offset];
/* Show the modes */
for (i = 0; i num_parent; i++) {
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing
This was prompted by an incorrect warning issued by clang [1], and a
suggestion by Linus to restrict the range to check for values greater
than INT_MAX since these will give bogus output after casting to int.
In fact the (dis)similarity index is a percentage, so reject values
greater than 100.
[1] http://article.gmane.org/gmane.comp.version-control.git/213857
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/apply.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 6c11e8b..4745e75 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1041,15 +1041,17 @@ static int gitdiff_renamedst(const char *line, struct
patch *patch)
static int gitdiff_similarity(const char *line, struct patch *patch)
{
- if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch-score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val = 100)
+ patch-score = val;
return 0;
}
static int gitdiff_dissimilarity(const char *line, struct patch *patch)
{
- if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch-score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val = 100)
+ patch-score = val;
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] send-email: ignore files ending with ~
It certainly happened to a lot of people already: you carefully prepare
your set of patches, export them using format-patch --cover-letter,
write your cover letter, and send the set like this:
$ git send-email --to=somerenowneddeveloper --to=myfutureemployer
--cc=thismailinglistiwanttoimpress 00*
And of course since you think you know what you are doing, you just
answer 'a' at the first prompt to send all emails at once.
The next day, all these people are laughing at you because the editor
you used to write your cover letter saved a backup of the previous
version and they received two versions of it, including one containing
the familiar *** BLURB HERE *** (or potentially more humiliating stuff
if you used the buffer as a temporary scratch).
Let's save people's reputations by ignoring files ending with '~' in
send-email. There should be no reason to send such a file anyways.
Signed-off-by: Alexandre Courbot gnu...@gmail.com
---
git-send-email.perl | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..4cc5855 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -548,7 +548,10 @@ while (defined(my $f = shift @ARGV)) {
sort readdir $dh;
closedir $dh;
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
- push @files, $f;
+ # Ignore backup files
+ if ($f !~ ~\$) {
+ push @files, $f;
+ }
} else {
push @rev_list_opts, $f;
}
--
1.8.1.1
--
To unsubscribe from this list: send the line 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 v2] CodingGuidelines: add Python coding guidelines
j...@keeping.me.uk wrote on Fri, 01 Feb 2013 11:16 +: On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote: On 01/30/2013 09:31 PM, John Keeping wrote: On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: [...] maybe we should establish a small Python library of compatibility utilities (like a small six). [...] But I haven't had time to think of where to put such a library, how to install it, etc. If we want to go that route, I think restructuring the git_remote_helpers directory and re-using its infrastructure for installing the Git Python modules would be the way to go. The directory structure would become something like this: git/ `-- python/ |-- Makefile# existing file pulled out of git_remote_helpers |-- some new utility library |-- git_remote_helpers | |-- __init__.py | |-- git | | |-- __init__.py | | |-- exporter.py | | |-- git.py | | |-- importer.py | | |-- non_local.py | | `-- repo.py | `-- util.py |-- setup.cfg # existing file pulled out of git_remote_helpers `-- setup.py# existing file pulled out of git_remote_helpers It looks like the GitPython project[1] as already taken the git module name, so perhaps we should use git_core if we do introduce a new module. [1] http://pypi.python.org/pypi/GitPython This sounds reasonable. But not all Python code will go under the python subdirectory, right? For example, I am working on a Python script that fits thematically under contrib/hooks. I was thinking of it as analagous with the perl directory that currently exists. So the python directory will contain library code but scripts can live wherever is most appropriate. One way of looking at it is: could the user want to have this installed for all available versions of Python? For a script, the answer is no because they will call it and it will just run. For libraries, you want them to be available with whatever Python interpreter you happen to be running (assuming that it is a version supported by the library). OTOH (I'm thinking aloud here) it is probably a bad idea for a hook script to depend on a Python module that is part of git itself. Doing so would make the hook script depend on a particular version of git (or at least a version with a compatible Python module). But users might be reluctant to upgrade git just to install a hook script. I don't think such a dependency is a bad idea in the longer term. If a Git Python library is developed, then at some point most people who have Git installed will have some version of that library - it becomes a case of perhaps wanting to limit yourself to some subset of the library rather than just not using it. In fact, git_remote_helpers has been available since Git 1.7.0 and contains a lot of functionality that is more generic than its name suggests. This library idea would be a great help; there are 100-odd calls to git in git-p4, and we've had to deal with getting the arguments and parsing correct. I'd happily switch to using git_core. Probably some elements of GitPython can be used too. I'm not so interested in the raw database manipulation, but the command wrappers look reasonable. -- Pete -- To unsubscribe from this list: send the line 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: Feature request: Allow extracting revisions into directories
On 02/03/2013 07:48 PM, Robert Clausecker wrote: Hello! git currently has the archive command that allows to save an arbitrary revision into a tar or zip file. Sometimes it is useful to not save this revision into an archive but to directly put all files into an arbitrary directory. Currently this seems to be not possible to archive directly; the only way I found to do it is to run git archive and then directly unpack the archive into a directory. git --git-dir REPO archive REVISION | tar x It would be nice to have a command or simply a switch to git archive that allows the user to put the files of REVISION into a directory instead of making an archive. Could you help me understand why piping it to tar (actually 'tar -C /dest/dir -x') is not sufficient to achieve what you want? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Make Git compile warning-free with Clang
Thanks John, I couldn't find any time to send that sum-up series. On Sun, Feb 3, 2013 at 3:37 PM, John Keeping j...@keeping.me.uk wrote: The first two patches here were sent to the list before but seem to have got lost in the noise [1][2]. The final one is new but was prompted by discussion in the same thread. -- To unsubscribe from this list: send the line 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] send-email: ignore files ending with ~
On Sun, Feb 3, 2013 at 3:55 PM, Alexandre Courbot gnu...@gmail.com wrote: It certainly happened to a lot of people already: you carefully prepare your set of patches, export them using format-patch --cover-letter, write your cover letter, and send the set like this: $ git send-email --to=somerenowneddeveloper --to=myfutureemployer --cc=thismailinglistiwanttoimpress 00* Why don't you use 00*.patch ? That seems dubious to me to ignore files specified on the command line. -- To unsubscribe from this list: send the line 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: Feature request: Allow extracting revisions into directories
Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty: Could you help me understand why piping it to tar (actually 'tar -C /dest/dir -x') is not sufficient to achieve what you want? Piping the output of git archive into tar is of course a possible solution; I just don't like the fact that you need to pipe the output into a separate program to do something that should be possible with a simple switch and not an extra command. It feels unintuitive and like a workaround to make an archive just to unpack it on-the-fly. Also, adding such a command (or at least documenting the way to do this using a pipe to tar somewhere in the man pages) is a small and simple change that improves usability. Yours, Robert Clausecker signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/3] combine-diff: suppress a clang warning
On Sun, Feb 3, 2013 at 10:37 PM, John Keeping j...@keeping.me.uk wrote:
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~^~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
[ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = COLONS[offset];
/* Show the modes */
for (i = 0; i num_parent; i++) {
--
Hmm, does
prefix = (const char *) COLONS + offset;
suppress the warning?
--
Cheers,
Ray Chuan
--
To unsubscribe from this list: send the line 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] gitk: Display the date of a tag in a human friendly way.
Hi Pau, I've not been able to find the canonical location of your gitk repository. I've tried kernel.org, samba.org and ozlabs.org; none of them to have it - nor does any amount of google searching I do reveal the location. I realise you've probably had a busy month with linux.conf.au but it would be nice to have some feedback. Could you let me know where gitk is hosted and I'll re-roll this patch against that (and update the docs so others don't need to go hunting). Thanks, Anand On 5 January 2013 19:38, Junio C Hamano gits...@pobox.com wrote: Anand Kumria wildf...@progsoc.org writes: Sorry, I didn't know that gitk had been split back out (and Documentation/gitk.txt still mentions it is part of the git suite). It is not split back at all, and it won't be. From git user's point of view it is part of the suite. Gitk however is still a viable freestanding project, so it would be selfish for me to take a patch to gitk-git/gitk directly to my tree, as the patch will not be able to flow back to the standalone gitk project. Hence we always let patches go through Paul's tree and then I pull from him. -- To unsubscribe from this list: send the line 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] combine-diff: suppress a clang warning
On Mon, Feb 04, 2013 at 02:20:06AM +0800, Tay Ray Chuan wrote:
On Sun, Feb 3, 2013 at 10:37 PM, John Keeping j...@keeping.me.uk wrote:
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~^~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
[ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping j...@keeping.me.uk
---
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path
*p, int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = COLONS[offset];
/* Show the modes */
for (i = 0; i num_parent; i++) {
Hmm, does
prefix = (const char *) COLONS + offset;
suppress the warning?
It does, but it turns out that the following also suppresses the
warning:
-- 8 --
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..a07d329 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -982,7 +982,7 @@ static void show_patch_diff(struct combine_diff_path *elem,
int num_parent,
free(sline);
}
-#define COLONS
+static const char COLONS[] = ;
static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct
rev_info *rev)
{
I think that's a nicer change than the original suggestion.
John
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum
John Keeping wrote:
From: Antoine Pelisse apeli...@gmail.com
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Thanks. Looks good to me.
[...]
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
for (p = opt-header_list; p; p = p-next) {
if (p-token != GREP_PATTERN_HEAD)
die(bug: a non-header pattern in grep header list.);
- if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field)
+ if (p-field GREP_HEADER_FIELD_MIN ||
+ GREP_HEADER_FIELD_MAX = p-field)
die(bug: unknown header field %d, p-field);
I also think it would be fine to drop this test or replace it with an
assert((unsigned) p-field ARRAY_SIZE(header_field));
because we know the test never trips.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: add ~/.authinfo parsing
On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
I wrote a Perl credential helper for netrc parsing which is pretty
robust, has built-in docs with -h, and doesn't depend on external
modules. The netrc parser regex was stolen from Net::Netrc.
It will by default use ~/.authinfo.gpg, ~/.netrc.gpg, ~/.authinfo, and
~/.netrc (whichever is found first) and this can be overridden with -f.
Cool, thanks for working on this.
If the file name ends with .gpg, it will run gpg --decrypt FILE and
use the output. So non-interactively, that could hang if GPG was
waiting for input. Does Git handle that, or should I check for a TTY?
No, git does not do anything special with respect to credential helpers
and ttys (nor should it, since one use of helpers is to get credentials
when there is no tty). I think it is GPG's problem to deal with, though.
We will invoke it, and it is up to it to decide whether it can acquire
the passphrase or not (either through the tty, or possibly from
gpg-agent). So it would be wrong to do the tty check yourself.
I haven't tested GPG, but I assume it properly tries to read from
/dev/tty and not stdin. Your helper's stdio is connected to git and
speaking the credential-helper protocol, so GPG reading from stdin would
either steal your input (if run before you read it), or just get EOF (if
you have read all of the pipe content already). If GPG isn't well
behaved, it may be worth redirecting its stdin from /dev/null as a
safety measure.
Take a look at the proposed patch and let me know if it's usable, if you
need a formal copyright assignment, etc.
Overall looks sane to me, though my knowledge of .netrc is not
especially good. Usually we try to send patches inline in the email
(i.e., as generated by git-format-patch), and include a Signed-off-by
line indicating that content is released to the project; see
Documentation/SubmittingPatches.
+use Data::Dumper;
I don't see it used here. Leftover from debugging?
+ print EOHIPPUS;
Cute, I haven't seen that one before.
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
I don't know if we have a particular policy for items in contrib/, but
this license may be too vague. In particular, it does not explicitly
allow redistribution, which would make Junio shipping a release with it
a copyright violation.
Any objection to just putting it under some well-known simple license
(GPL, BSD, or whatever)?
+if ($file =~ m/\.gpg$/)
+{
+ $file = gpg --decrypt $file|;
+}
Does this need to quote $file, since the result will get passed to the
shell? It might be easier to just use the list form of open(), like:
my @data = $file =~ /\.gpg$/ ?
load('-|', qw(gpg --decrypt), $file) :
load('', $file);
(and then obviously update load to just dump all of @_ to open()).
+die Sorry, we could not load data from [$file]
+ unless (scalar @data);
Probably not that interesting a corner case, but this means we die on an
empty .netrc, whereas it might be more sensible for it to behave as no
match.
For the same reason, it might be worth silently exiting when we don't
find a .netrc (or any of its variants). That lets people who share their
dot-files across machines configure git globally, even if they don't
necessarily have a netrc on every machine.
+# the query
+my %q;
+
+foreach my $v (values %{$options{tmap}})
+{
+ undef $q{$v};
+}
Just my personal style, but I find the intent more obvious with map (I
know some people find it unreadable, though):
my %q = map { $_ = undef } values(%{$options{tmap}});
+while (STDIN)
+{
+ next unless m/([a-z]+)=(.+)/;
We don't currently have any exotic tokens that this would not match, nor
do I plan to add them, but the credential documentation defines a valid
line as /^([^=]+)=(.+)/.
It's also possible for the value to be empty, but I do not think
off-hand that current git will ever send such an empty value.
[...]
The rest of it looks fine to me. I don't think any of my comments are
show-stoppers. Tests would be nice, but integrating contrib/ stuff with
the test harness is kind of a pain.
-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: What's cooking in git.git (Feb 2013, #01; Fri, 1)
John Keeping j...@keeping.me.uk writes: On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote: It looks good to go. The additional || : in the makefile is a nice touchup that made it more robust too. Looks good to me as well. Thanks, both. -- To unsubscribe from this list: send the line 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: Getting started contributing.
Duy Nguyen pclo...@gmail.com writes: On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano gits...@pobox.com wrote: On the other hand, there probably still are many loose ends. A few other things - Mark more strings for translation (not as easy as it sounds, some strings can't be translated) True, but not a good advice for somebody new, exactly for the reason you stated, i.e. some strings must not be translated. - Color more in the output where it makes sense Eeek. - Stop/Warn the user from updating HEAD (e.g. checkout another branch) while in the middle of a rebase (some makes sense, most is by mistake) Perhaps, but again probably not for somebody new who hasn't mastered various workflows and understood why it may make sense to allow it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] combine-diff: suppress a clang warning
John Keeping j...@keeping.me.uk writes: When compiling combine-diff.c, clang 3.2 says: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ [ ] Suppress this by making the suggested change. Signed-off-by: John Keeping j...@keeping.me.uk --- This was not lost in the noise. I thought that this wasn't a serious patch, but your attempt to demonstrate to others why patches trying to squelch clang warnings are not necessarily a good thing to do. Who is that compiler trying to help with such a warning message? After all, we are writing in C, and clang is supposed to be a C compiler. And adding integer to a pointer to (const) char is a straight-forward way to look at the trailing part of a given string. - prefix = COLONS + offset; + prefix = COLONS[offset]; In other words, both are perfectly valid C. Why should we make it less readable to avoid a stupid compiler warning? -- To unsubscribe from this list: send the line 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] Handle path completion and colon for tcsh script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/02/2013 21:10, Junio C Hamano ha scritto: Marc Khouzam marc.khou...@ericsson.com writes: Recent enhancements to git-completion.bash provide intelligent path completion for git commands. Such completions do not add the '/' at the end of directories for recent versions of bash. ... Here is the update for tcsh completion which is needed to handle the cool new path completion feature just pushed to 'next'. [...] But I have to wonder if this is sweeping a problem under the rug. Shouldn't the completion for bash users end completed directory name with '/', even if we didn't have to worry about tcsh? The problem is that when using the new `compopt -o filenames` command, Bash assumes COMPREPLY contains a list of filenames, and when it detects a directory name, it adds a slash. The problem is, if the directory name *already* has a slash, Bash adds another slash! I don't know if this can be considered a bug or a feature. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEOwaQACgkQscQJ24LbaUSjwgCfbgb1id5DcNG0Q75FWwgNPCqb qkUAnAmMzCahB745/BWeDJTHbJFXucxs =vf+P -END PGP SIGNATURE- -- To unsubscribe from this list: send the line 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] gitk: Display the date of a tag in a human friendly way.
Hi Anand, Anand Kumria wrote: I've not been able to find the canonical location of your gitk repository. Here's how I find it: $ git clone git://repo.or.cz/git.git [...] $ cd git $ git log -1 --oneline -- gitk-git ec3ae6ec Merge git://ozlabs.org/~paulus/gitk $ cd .. $ git clone git://ozlabs.org/~paulus/gitk.git Patches, including documentation patches, go to git@vger.kernel.org, cc-ing Paul Mackerras. Hope that helps, Jonathan -- To unsubscribe from this list: send the line 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] gitk: Display the date of a tag in a human friendly way.
Jonathan Nieder jrnie...@gmail.com writes: Anand Kumria wrote: I've not been able to find the canonical location of your gitk repository. Here's how I find it: $ git clone git://repo.or.cz/git.git [...] $ cd git $ git log -1 --oneline -- gitk-git ec3ae6ec Merge git://ozlabs.org/~paulus/gitk $ cd .. $ git clone git://ozlabs.org/~paulus/gitk.git Patches, including documentation patches, go to git@vger.kernel.org, cc-ing Paul Mackerras. Or look at A note from the maintainer posted here every few months. -- To unsubscribe from this list: send the line 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] combine-diff: suppress a clang warning
On Sun, Feb 03, 2013 at 11:58:15AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: When compiling combine-diff.c, clang 3.2 says: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ [ ] Suppress this by making the suggested change. Signed-off-by: John Keeping j...@keeping.me.uk --- This was not lost in the noise. I thought that this wasn't a serious patch, but your attempt to demonstrate to others why patches trying to squelch clang warnings are not necessarily a good thing to do. Who is that compiler trying to help with such a warning message? After all, we are writing in C, and clang is supposed to be a C compiler. And adding integer to a pointer to (const) char is a straight-forward way to look at the trailing part of a given string. A quick search turned up the original thread where this feature was added to Clang [1]. It seems that it does find genuine bugs where people try to log values by doing: log(failed to handle error: + errno); [1] http://thread.gmane.org/gmane.comp.compilers.clang.scm/47203 - prefix = COLONS + offset; + prefix = COLONS[offset]; In other words, both are perfectly valid C. Why should we make it less readable to avoid a stupid compiler warning? Are you happy to change COLONS to a const char[] instead of a #define? That also suppresses the warning. Since Git is warning-free on GCC and so close to being warning-free on recent Clang I think it is worthwhile to fix the remaining two issues which do seem to be intentional diagnostics rather than Clang bugs. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Handle path completion and colon for tcsh script
Manlio Perillo manlio.peri...@gmail.com writes: The problem is that when using the new `compopt -o filenames` command, Bash assumes COMPREPLY contains a list of filenames, and when it detects a directory name, it adds a slash. The problem is, if the directory name *already* has a slash, Bash adds another slash! So bash users do see the trailing slash because bash adds one to what we compute and return, which we do strip the trailing slash exactly because we know bash will add one. Because tcsh completion uses what we compute directly, without bash massaging our output to add the trailing slash, it needs some magic. OK, that makes sense. It was this part from the originally proposed log message: ... Such completions do not add the '/' at the end of directories for recent versions of bash. However, the '/' is needed by tcsh, ... with a large gap between the two sentences that fooled me, and the explanation in your message helped to fill the gap to understand the situation better. Perhaps ... for recent versions of bash, which will then add the trailing slash for paths that are directory to the result of our completion. The completion for tcsh however uses the result of our completion directly, so it either needs to add the necessary slash itself, or needs to ask us to keep the trailiing slash. This patch does the latter. or something? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing
John Keeping j...@keeping.me.uk writes:
diff --git a/builtin/apply.c b/builtin/apply.c
index 6c11e8b..4745e75 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1041,15 +1041,17 @@ static int gitdiff_renamedst(const char *line, struct
patch *patch)
static int gitdiff_similarity(const char *line, struct patch *patch)
{
- if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch-score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val = 100)
+ patch-score = val;
return 0;
}
static int gitdiff_dissimilarity(const char *line, struct patch *patch)
{
- if ((patch-score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch-score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val = 100)
+ patch-score = val;
return 0;
}
This makes sort of sense; .score is used only for display and not
for making any decision, so as long as you know it is initialized to
zero when the call to this function is made, it should be OK.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] combine-diff: suppress a clang warning
John Keeping j...@keeping.me.uk writes:
A quick search turned up the original thread where this feature was
added to Clang [1]. It seems that it does find genuine bugs where
people try to log values by doing:
log(failed to handle error: + errno);
To be perfectly honest, anybody who writes such a code should be
sent back to school before trying to touch out code ever again ;-).
It is not even valid Python, Perl nor Java, I would think.
Are you happy to change COLONS to a const char[] instead of a #define?
Happy? Not really.
It could be a good change for entirely different reason. We will
save space if we ever need to use it in multiple places. But the
entire COLONS + offset thing was a hack we did, knowing that it
will break when we end up showing a muiti-way diff for more than 32
blobs.
If we were to be touching that area of code, I'd rather see a change
to make it more robust against such a corner case. If it results in
squelching misguided clang warnings against programmers who should
not be writing in C, that is a nice side effect, but I loathe to see
any change whose primary purpose is to squelch pointless warnings.
combine-diff.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..7f6187f 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -982,14 +982,10 @@ static void show_patch_diff(struct combine_diff_path
*elem, int num_parent,
free(sline);
}
-#define COLONS
-
static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct
rev_info *rev)
{
struct diff_options *opt = rev-diffopt;
- int i, offset;
- const char *prefix;
- int line_termination, inter_name_termination;
+ int line_termination, inter_name_termination, i;
line_termination = opt-line_termination;
inter_name_termination = '\t';
@@ -1000,17 +996,14 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
show_log(rev);
if (opt-output_format DIFF_FORMAT_RAW) {
- offset = strlen(COLONS) - num_parent;
- if (offset 0)
- offset = 0;
- prefix = COLONS + offset;
+ /* As many colons as there are parents */
+ for (i = 0; i num_parent; i++)
+ putchar(':');
/* Show the modes */
- for (i = 0; i num_parent; i++) {
- printf(%s%06o, prefix, p-parent[i].mode);
- prefix = ;
- }
- printf(%s%06o, prefix, p-mode);
+ for (i = 0; i num_parent; i++)
+ printf(%06o , p-parent[i].mode);
+ printf(%06o, p-mode);
/* Show sha1's */
for (i = 0; i num_parent; i++)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] branch: show rebase/bisect info when possible instead of (no branch)
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: --- a/t/t6030-bisect-porcelain.sh +++ b/t/t6030-bisect-porcelain.sh @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing .git/BISECT_START not modified if cp .git/BISECT_START saved test_must_fail git bisect start $HASH4 foo -- git branch branch.output - test_i18ngrep * (no branch) branch.output /dev/null + test_i18ngrep * (bisecting other) branch.output /dev/null I'd have spelled it (no branch, bisecting other) to make it clear that we're on detached HEAD, and avoid confusing old-timers. But maybe your version is enough, I'm not sure. -- 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 v2] branch: show rebase/bisect info when possible instead of (no branch)
Matthieu Moy matthieu@grenoble-inp.fr writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: --- a/t/t6030-bisect-porcelain.sh +++ b/t/t6030-bisect-porcelain.sh @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing .git/BISECT_START not modified if cp .git/BISECT_START saved test_must_fail git bisect start $HASH4 foo -- git branch branch.output -test_i18ngrep * (no branch) branch.output /dev/null +test_i18ngrep * (bisecting other) branch.output /dev/null I'd have spelled it (no branch, bisecting other) to make it clear that we're on detached HEAD, and avoid confusing old-timers. But maybe your version is enough, I'm not sure. Yeah, I do not think bisecting other alone makes much sense. What does other refer to when you start your bisection at a detached head? I personally think other has _any_ value in that message, because (no branch, bisecting) gives the same amount of information, especially because other does not say which branch it refers to at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] branch: show rebase/bisect info when possible instead of (no branch)
Junio C Hamano gits...@pobox.com writes: Yeah, I do not think bisecting other alone makes much sense. What does other refer to when you start your bisection at a detached head? I personally think other has _any_ value in that s/_any_/_no_/; obviously ;-) message, because (no branch, bisecting) gives the same amount of information, especially because other does not say which branch it refers to at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[New Feature] git-submodule-move - Easily move submodules
I've recently had need to re-arrange more than ten submodules within a project and discovered there is apparently no easy way to do it. Using some suggestions I found on Stack Overflow I eventually figured out the steps required. Because the steps can be complex I thought it would be handy to have a tool to automate the functionality. I have put together a reasonably bullet-proof shell script git-submodule-move that does the job pretty well. I've put it through quite a bit of testing and trusted it with my own project and it has performed well. I've published to github so others can use and improve it. https://github.com/iam-TJ/git-submodule-move -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git p4: chdir resolves symlinks only for relative paths
mfaze...@szemafor.com wrote on Tue, 29 Jan 2013 09:37 +0100: If a p4 client is configured to /p/foo which is a symlink to /vol/bar/projects/foo, then resolving symlink, which is done by git-p4's chdir will confuse p4: Path /vol/bar/projects/foo/... is not under client root /p/foo While AltRoots in p4 client specification can be used as a workaround on p4 side, git-p4 should not resolve symlinks in client paths. chdir(dir) uses os.getcwd() after os.chdir(dir) to resolve relative paths, but as a side effect it resolves symlinks too. Now it checks if the dir is relative before resolving. Signed-off-by: Miklós Fazekas mfaze...@szemafor.com --- git-p4.py |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index 2da5649..5d74649 100755 --- a/git-p4.py +++ b/git-p4.py @@ -64,7 +64,10 @@ def chdir(dir): # not using the shell, we have to set it ourselves. This path could # be relative, so go there first, then figure out where we ended up. os.chdir(dir) -os.environ['PWD'] = os.getcwd() +if os.path.isabs(dir): +os.environ['PWD'] = dir +else: +os.environ['PWD'] = os.getcwd() def die(msg): if verbose: Thanks, this is indeed a bug and I have reproduced it with a test case. Your patch works, but I think it would be better to separate the callers of chdir(): those that know they are cd-ing to a path from a p4 client, and everybody else. The former should not use os.getcwd(), as you show. I'll whip something up soon, unless you beat me to it. -- Pete -- To unsubscribe from this list: send the line 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] combine-diff: suppress a clang warning
On Sun, Feb 03, 2013 at 01:07:48PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
A quick search turned up the original thread where this feature was
added to Clang [1]. It seems that it does find genuine bugs where
people try to log values by doing:
log(failed to handle error: + errno);
To be perfectly honest, anybody who writes such a code should be
sent back to school before trying to touch out code ever again ;-).
Yeah, I can't see that getting through review here :-).
It is not even valid Python, Perl nor Java, I would think.
It is valid Java, although I can't think of any other languages that let
you do that.
Are you happy to change COLONS to a const char[] instead of a #define?
Happy? Not really.
It could be a good change for entirely different reason. We will
save space if we ever need to use it in multiple places. But the
entire COLONS + offset thing was a hack we did, knowing that it
will break when we end up showing a muiti-way diff for more than 32
blobs.
If we were to be touching that area of code, I'd rather see a change
to make it more robust against such a corner case. If it results in
squelching misguided clang warnings against programmers who should
not be writing in C, that is a nice side effect, but I loathe to see
any change whose primary purpose is to squelch pointless warnings.
This seems like a sensible change.
I generally like to get rid of the pointless warnings so that the useful
ones can't hide in the noise. Perhaps CFLAGS += -Wno-string-plus-int
would be better for this particular warning, but when there's only one
bit of code that triggers it, tweaking that seemed simpler.
combine-diff.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..7f6187f 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -982,14 +982,10 @@ static void show_patch_diff(struct combine_diff_path
*elem, int num_parent,
free(sline);
}
-#define COLONS
-
static void show_raw_diff(struct combine_diff_path *p, int num_parent,
struct rev_info *rev)
{
struct diff_options *opt = rev-diffopt;
- int i, offset;
- const char *prefix;
- int line_termination, inter_name_termination;
+ int line_termination, inter_name_termination, i;
line_termination = opt-line_termination;
inter_name_termination = '\t';
@@ -1000,17 +996,14 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
show_log(rev);
if (opt-output_format DIFF_FORMAT_RAW) {
- offset = strlen(COLONS) - num_parent;
- if (offset 0)
- offset = 0;
- prefix = COLONS + offset;
+ /* As many colons as there are parents */
+ for (i = 0; i num_parent; i++)
+ putchar(':');
/* Show the modes */
- for (i = 0; i num_parent; i++) {
- printf(%s%06o, prefix, p-parent[i].mode);
- prefix = ;
- }
- printf(%s%06o, prefix, p-mode);
+ for (i = 0; i num_parent; i++)
+ printf(%06o , p-parent[i].mode);
+ printf(%06o, p-mode);
/* Show sha1's */
for (i = 0; i num_parent; i++)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: Allow extracting revisions into directories
On Sun, Feb 03, 2013 at 03:18:05PM +0100, Robert Clausecker wrote: git currently has the archive command that allows to save an arbitrary revision into a tar or zip file. Sometimes it is useful to not save this revision into an archive but to directly put all files into an arbitrary directory. Currently this seems to be not possible to archive directly; the only way I found to do it is to run git archive and then directly unpack the archive into a directory. git --git-dir REPO archive REVISION | tar x It would be nice to have a command or simply a switch to git archive that allows the user to put the files of REVISION into a directory instead of making an archive. You could use plumbing commands combined with a throwaway custom index file and a separate work tree which will receive the tree at REVISION: export GIT_WORK_TREE=/path/to/dest/directory export GIT_DIR=/path/to/repo/.git export GIT_INDEX_FILE=$GIT_WORK_TREE/.index git read-tree REVISION git checkout-index -a rm -f $GIT_INDEX_FILE -- To unsubscribe from this list: send the line 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: Moving (renaming) submodules, recipe/script
On Sun, Feb 03, 2013 at 10:36:17PM +, TJ wrote: I've recently had need to re-arrange more than ten submodules within a project and discovered there is apparently no easy way to do it. I ran into a similar problem last month, and wrote a similar script [1] ;). There are a few other related threads you might be interested in: On Sun, Jan 06, 2013 at 07:36:03PM -0500, W. Trevor King wrote: Today I had to move my first submodule, and I discovered that Git's support for this is pretty limited. There have been a few patch series attempting to address this [1,2], but none of them seems to have pushed through into master (although I can't put my finger on a reason for why). There are also some SO postings discussing this [3,4]. It would be nice if `git mv` worked out of the box on … [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720 [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250 [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository The long-term solution is probably Jens' branch: On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote: I´m currently working on teaching mv to move submodules and intend to send those patches to the list after finishing submodule deinit. Please see https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules for the current state of this series. Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/212861 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] combine-diff: suppress a clang warning
John Keeping j...@keeping.me.uk writes:
If we were to be touching that area of code, I'd rather see a change
to make it more robust against such a corner case. If it results in
squelching misguided clang warnings against programmers who should
not be writing in C, that is a nice side effect, but I loathe to see
any change whose primary purpose is to squelch pointless warnings.
This seems like a sensible change.
I generally like to get rid of the pointless warnings so that the useful
ones can't hide in the noise. Perhaps CFLAGS += -Wno-string-plus-int
would be better for this particular warning, but when there's only one
bit of code that triggers it, tweaking that seemed simpler.
Thanks for a sanity check. Ideally it should also have test cases
to show git diff --cc --raw blob1 blob2...blob$n for n=4 and n=40
(or any two values clearly below and above the old hardcoded limit)
behave sensibly, exposing the old breakage, which I'll leave as a
LHF (low-hanging-fruit). Hint, hint...
-- 8 --
Subject: [PATCH] combine-diff: lift 32-way limit of combined diff
The raw format of combine-diff output is supposed to have as many
colons as there are parents at the beginning, then blob modes for
these parents, and then object names for these parents.
We weren't however prepared to handle a more than 32-way merge and
did not show the correct number of colons in such a case.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
combine-diff.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..7f6187f 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -982,14 +982,10 @@ static void show_patch_diff(struct combine_diff_path
*elem, int num_parent,
free(sline);
}
-#define COLONS
-
static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct
rev_info *rev)
{
struct diff_options *opt = rev-diffopt;
- int i, offset;
- const char *prefix;
- int line_termination, inter_name_termination;
+ int line_termination, inter_name_termination, i;
line_termination = opt-line_termination;
inter_name_termination = '\t';
@@ -1000,17 +996,14 @@ static void show_raw_diff(struct combine_diff_path *p,
int num_parent, struct re
show_log(rev);
if (opt-output_format DIFF_FORMAT_RAW) {
- offset = strlen(COLONS) - num_parent;
- if (offset 0)
- offset = 0;
- prefix = COLONS + offset;
+ /* As many colons as there are parents */
+ for (i = 0; i num_parent; i++)
+ putchar(':');
/* Show the modes */
- for (i = 0; i num_parent; i++) {
- printf(%s%06o, prefix, p-parent[i].mode);
- prefix = ;
- }
- printf(%s%06o, prefix, p-mode);
+ for (i = 0; i num_parent; i++)
+ printf(%06o , p-parent[i].mode);
+ printf(%06o, p-mode);
/* Show sha1's */
for (i = 0; i num_parent; i++)
--
1.8.1.2.628.geb8a6d5
--
To unsubscribe from this list: send the line 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: Feature request: Allow extracting revisions into directories
On 02/03/2013 11:41 PM, Robert Clausecker wrote: Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty: Could you help me understand why piping it to tar (actually 'tar -C /dest/dir -x') is not sufficient to achieve what you want? Piping the output of git archive into tar is of course a possible solution; I just don't like the fact that you need to pipe the output into a separate program to do something that should be possible with a simple switch and not an extra command. It feels unintuitive and like a workaround to make an archive just to unpack it on-the-fly. Also, adding such a command (or at least documenting the way to do this using a pipe to tar somewhere in the man pages) is a small and simple change that improves usability. I realise it appears to be the fashion these days to get away from the Unix philosophy of having different tools do different things and combining them as needed. Ignoring the option-heavy GNU, and looking at the more traditional BSD tar manpage [1], I notice the following flags that could still be potentially needed by someone running 'git archive': '-t' (instead of '-x'), '-C dir', '--exclude/include', '-k', '-m', '--numeric-owner', -o, -P, -p, -q, -s, -T, -U, -v, -w, and -X. And I'm ignoring the esoteric ones like --chroot and -S (sparse mode). How many of these options would you like included in git? And if you say I don't need any of those; I just need '-x', that's not relevant. Someone else may need any or all of those flags, and if you accept -x you have to accept some of the others too. Also, I often want to deploy to a different host, and I might do that like so: git archive ... | ssh host tar -C /deploy/dir -x Why not put that ssh functionality into git also? What about computing a checksum and putting out a sha1sums.txt file? People do that also. How about a flag for that? Where does this end? [1]: http://www.unix.com/man-page/FreeBSD/1/tar/ -- To unsubscribe from this list: send the line 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: Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
Jonathan Nieder wrote: Jongman Heo wrote: But it doesn't stimulate any prerequisites in make, which is weird. What's in builtin/.depend/fetch.o.d? [...] please see below~. $ cat builtin/.depend/fetch.o.d fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \ That's the problem. See the following thread: http://thread.gmane.org/gmane.comp.version-control.git/185625/focus=185680 Currently when COMPUTE_HEADER_DEPENDENCIES=auto git tests for dependency generation support by checking the output and exit status from the following command: $(CC) $(ALL_CFLAGS) -c -MF /dev/null -MMD -MP \ -x c /dev/null -o /dev/null 21 Perhaps this can be improved? Even something as simple as a ccache version test could presumably help a lot. Hope that helps, Jonathan Hi, Unfortunately, the patch didn't help to me. Anyway, ccache is the culprit (I'm using ccache 2.4 version). If I disable ccache using CCACHE_DISABLE=1, then the issue doesn't happen. Thanks. Best regards, Jongman Heo.
Re: [PATCH] send-email: ignore files ending with ~
On Mon, Feb 4, 2013 at 2:16 AM, Antoine Pelisse apeli...@gmail.com wrote: On Sun, Feb 3, 2013 at 3:55 PM, Alexandre Courbot gnu...@gmail.com wrote: It certainly happened to a lot of people already: you carefully prepare your set of patches, export them using format-patch --cover-letter, write your cover letter, and send the set like this: $ git send-email --to=somerenowneddeveloper --to=myfutureemployer --cc=thismailinglistiwanttoimpress 00* Why don't you use 00*.patch ? That seems dubious to me to ignore files specified on the command line. For the same reason I do not list all the patches individually on the command line: laziness. The goal of this patch is in no way to argue that using send-email like this is a recommandable way. It just adds a safeguard on a use-case that is probably not so uncommon. Alex. -- To unsubscribe from this list: send the line 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] Handle path completion and colon for tcsh script
The problem is, if the directory name *already* has a slash, Bash adds another slash! So bash users do see the trailing slash because bash adds one to what we compute and return, which we do strip the trailing slash exactly because we know bash will add one. The problem is slightly more obscure than that, and I wonder if it should be documented somewhere in the bash script? Manlio explained in a previous exchange with me, that bash will properly deal with an existing trailing slash when doing the completion on the command-line, but will screw it up by adding a second slash when dealing with multiple possible completions and printing those for the user to choose from. For example: $ git status # On branch tcsh_next # Untracked files: # (use git add file... to include in what will be committed) # # fish/ # fishing/ nothing added to commit but untracked files present (use git add to track) $ git add fishtab fish//fishing// notice the double slashes $ git add fishitab # will complete the command line properly to the below, with a single slash. $ git add fishing/ Because tcsh completion uses what we compute directly, without bash massaging our output to add the trailing slash, it needs some magic. Yes, that is right. OK, that makes sense. It was this part from the originally proposed log message: ... Such completions do not add the '/' at the end of directories for recent versions of bash. However, the '/' is needed by tcsh, ... with a large gap between the two sentences that fooled me, and the explanation in your message helped to fill the gap to understand the situation better. Sorry about the lack of details. I'm see more and more the importance of these commit messages :) Perhaps ... for recent versions of bash, which will then add the trailing slash for paths that are directory to the result of our completion. The completion for tcsh however uses the result of our completion directly, so it either needs to add the necessary slash itself, or needs to ask us to keep the trailiing slash. This patch does the latter. or something? How about the following, which gives a little more detail about the solution for tcsh? I think it is worth putting the below extra details because I feel a mistake could easily be made about this trailing slash issue, which I had gotten wrong for my own version of the script for a couple of weeks, before figuring out the mistake. Handle path completion and colon for tcsh script Recent enhancements to git-completion.bash provide intelligent path completion for git commands. Such completions do not provide the '/' at the end of directories for recent versions of bash; instead, bash itself will add the trailing slash to directories to the result provided by git-completion.bash. However, the completion for tcsh uses the result of the bash completion script directly, so it either needs to add the necessary slash itself, or needs to ask the bash script to keep the trailing slash. Adding the slash itself is difficult because we cannot easily tell if an entry of the output of the bash script is a directory or something else. For example, assuming there is a directory named 'commit' in the current directory, then, when completing git add committab we would need to add a slash, but for git help committab we should not. Figuring out such differences would require adding much intelligence to the tcsh completion script. Instead, it is simpler to ask the bash script to keep the trailing slash. This patch does this. Also, tcsh does not handle the colon as a completion separator so we remove it from the list of separators. Signed-off-by: Marc Khouzam marc.khou...@ericsson.com Thanks Marc -- To unsubscribe from this list: send the line 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] Handle path completion and colon for tcsh script
Thanks for a detailed explanation. The two examples illustrating different interpretation of the same word were really good. Will replace and requeue. -- To unsubscribe from this list: send the line 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 archve --format=tar output changed from 1.8.1 to 1.8.2.1
On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote: Greg KH gre...@linuxfoundation.org writes: On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: How about fixing kup to teach the let's cheat and let the other end run 'git archive', if the resulting archive and GPG signature locally created does match, we do not have to transfer the tarball itself trick a fall-back mode that says but if the signature does not match, then transfer the bulk used to create the signature to the remote anyway. This fallback can and should of course be useful for the compressed patch transfer. Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up doing lots of kernel releases while traveling), would be a horrible change. I'd rather just keep using the same older version of git that kernel.org is running instead. Then how about fixing kup to try both versions of Git? There will be people who run different versions of Git anyway, and kup should not be preventing Git from helping people on other platforms, or improving its output in general. I think the combinations of different versions of git that would have to be installed on kernel.org to handle stuff like this as things change over time, wouldn't be worth it. The number of people this affects right now is only one (me), given that the offending file is not in Linus's tree right now, so he doesn't have issues with uploading new releases. So I'll just work to ensure I have the same version of git in place if I ever run into this problem again. Or just break down and do full-compressed tarballs instead, if I'm in a place where I have a good network connection. thanks, greg k-h -- To unsubscribe from this list: send the line 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 archve --format=tar output changed from 1.8.1 to 1.8.2.1
On Thu, Jan 31, 2013 at 07:33:52PM +0100, René Scharfe wrote: Am 31.01.2013 18:28, schrieb Greg KH: I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546 (archive-tar: split long paths more carefully). The diff of a hex dump of the tar archives shows the following difference: --- old_git_archive 2013-01-31 17:31:24.466343388 +0100 +++ new_git_archive 2013-01-31 17:32:21.509674417 +0100 @@ -19239998,8 +19239998,8 @@ 125943d0: 125943e0: 125943f0: -12594400: -12594410: +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3 +12594410:2d70 6e61 6e64 2d68 616c 2f00 -pnand-hal/. 12594420: 12594430: 12594440: @@ -19240025,8 +19240025,8 @@ 12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar 12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl 125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c map3-pnand-hal.. +125945b0:6467 6500 dge. +125945c0: 125945d0: 125945e0: 125945f0: This is the only directory in the repository whose path is long enough to make a difference with the patch, 105 characters in total: drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/ Five characters less and you wouldn't notice a thing. It contains westbridge thrice, so I think it's cheating just to reach that length, though. ;-) Yeah, that file path was bad, which is just one reason why it was deleted from the kernel in newer versions :) Interestingly, the output of uncompressing the tar archives is identical, so the data is correct, but the binary isn't. The path is split differently between two header fields, that's all. Ok, thanks for the explaination, I didn't realize that. Now keeping binary compatibility of tar archive files isn't really a big deal, but, the commit to git that causes this seems a bit odd, is it really needed? Or can we just fix the version of tar with NetBSD instead? :) Apart from Junio's suggestion, I can't think of a practical solution. You could downgrade your git to a version before the fix. A downside is that you won't be able to extract the archive on NetBSD without getting an error message (but the contents would be intact, except perhaps for permission bits of the directory above). You could upgrade the kernel.org version of git, but that might cause the same problem for other maintainers with long directory paths who in their repositories who still use git without the fix. You could make the path shorter. Won't help at all with the release you just did, of course. What I ended up doing was just to revert your patch, generating a tar archive that matches what the version on kernel.org. And originally I now recall that this was something we were worried about, but we put off dealing with it until it caused problems :) I don't know if other tar implementations freak out when they see an empty name field. NetBSD's tar might seem a bit too strict here, but overall I think it's right in complaining. Ok, thanks, I now agree. What makes the commit odd, by the way? Sorry, I was originally thinking that you were working around a bug in the NetBSD version of tar, not making it more correct, which is arguably the right thing to do here. So I'll work with Konstantine to ensure we both are using the same version of git in the future, it's our kernel.org infrastructure issue here, not a git one, sorry for the noise. greg k-h -- To unsubscribe from this list: send the line 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 archve --format=tar output changed from 1.8.1 to 1.8.2.1
On Thu, Jan 31, 2013 at 12:52:15PM -0500, Konstantin Ryabitsev wrote: On 31/01/13 12:41 PM, Greg KH wrote: Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up doing lots of kernel releases while traveling), would be a horrible change. I'd rather just keep using the same older version of git that kernel.org is running instead. Well, we do accept compressed archives, so you would be uploading about 80MB instead of 431MB, but that would still be a problem for anyone releasing large tarballs over unreliable connections. I know you routinely do 2-3 releases at once, so that would still mean uploading 120-180MB. That would mean I can't do kernel releases while on ferry rides, which is probably a good thing in the end :) I don't have immediate statistics on how many people release using kup --tar, but I know that at least you and Linus rely on that exclusively. What causes you to upgrade the version of git on the server? Are you relying on packages for a distro, or is this hand installed by yourself? As long as I stay in lock-step with your updates, all should be fine. Oh, maybe we can report back to the user, the version of git that is being used on the server, if the checksums don't match, so that I know to at least see if my version is different from yours? thanks, greg k-h -- To unsubscribe from this list: send the line 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: Segmentation fault with latest git (070c57df)
Jongman Heo wrote: Unfortunately, the patch didn't help to me. Thanks for testing. Did you apply the patch to the older version of git that generates builtin/.depend/fetch.o.d or the newer version that consumes it? Curious, Jonathan -- To unsubscribe from this list: send the line 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 archve --format=tar output changed from 1.8.1 to 1.8.2.1
Greg KH gre...@linuxfoundation.org writes: Then how about fixing kup to try both versions of Git? There will be people who run different versions of Git anyway, and kup should not be preventing Git from helping people on other platforms, or improving its output in general. I think the combinations of different versions of git that would have to be installed on kernel.org to handle stuff like this as things change over time, wouldn't be worth it. You make it sound as if you have to pick the right one among 47 different versions, but I think over the lifetime of Git there was only one time that output from diff would have affected the kup's trick to avoid the transmission of patch text, and another that output from tar-tree (aka archive --format=tar) would have afffected the transmission of tarballs. I do think it is feasible if kup wanted to. The number of people this affects right now is only one (me), given that the offending file is not in Linus's tree right now, so he doesn't have issues with uploading new releases. As a tree grows larger over time, it may be just a matter of time for somebody else to be hit by another deep path, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pandora charms initiated to provide a couple transfer internet business on 1982
This is often ones own all sorts of things to grasp around tutorial to help you Pandora expensive jewelry, as a result of Pandora bracelets and even pandora charms with the Pandora bangles and even Pandora rings including some past. [url=http://www.genuinepandoracharmssale.co.uk/] pandora charms[/url] expensive jewelry initiated to provide a couple transfer internet business on 1982. On many occasions they'd go Thailand as a result of Denmark in the hunt for just the right jewel boulders. Simply because ones own interest accelerated some people changed ones own totally focus to help you alot more to a large internet business in expensive jewelry. Introduced soon after some people approved their own individual manufacturing on Thailand and even preserved to somewhat of a tighter look at the design and style facet of that expensive jewelry that were there generated. At present, 20 quite a few years soon after, it small-scale precious time expensive jewelry browse has expanded inside a major international intercontinental branded,[url=http://www.genuinepandoracharmssale.co.uk/] pandora uk[/url], along with a power team in 20 many people centrally located within the nation's hq on Copenhagen, Denmark, an important power team in throughout 100 individuals examining that American community, and even 1, 000 workforce within Pandora Shows, the nation's manufacturing on Thailand. http://www.genuinepandoracharmssale.co.uk -- View this message in context: http://git.661346.n2.nabble.com/pandora-charms-initiated-to-provide-a-couple-transfer-internet-business-on-1982-tp7576889.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
Jens Lehmann jens.lehm...@web.de writes: Am 28.01.2013 21:34, schrieb Junio C Hamano: ... I was imagining that foreach --untracked could go something like this: * If you are inside an existing git repository, read its index to learn the gitlinks in the directory and its subdirectories. * Start from the current directory and recursively apply the procedure in this step: * Scan the directory and iterate over the ones that has .git in it: * If it is a gitlinked one, show it, but do not descend into it unless --recursive is given (e.g. you start from /home/jens, find /home/jens/proj/ directory that has /home/jens/proj/.git in it. /home/jens/.git/index knows that it is a submodule of the top-level superproject. proj is handled, and it is up to the --recursive option if its submodules are handled). * If it is _not_ a gitlinked one, show it and descend into it (e.g. /home/jens/ is not a repository or /home/jens/proj is not a tracked submodule) to apply this procedure recursively. Of course, without --untracked, we have no need to iterate over the readdir() return values; instead we just scan the index of the top-level superproject. Thanks for explaining, that makes tons of sense. There is a small thinko above, though, and I'd like to correct it before anybody takes the above too seriously as _the_ outline of the design and implements it to the letter. The --recursive option should govern both a tracked submodule and an untracked one. When asking to list both existing submodules and directories that could become submodules, you should be able to say $ git submodule foreach --untracked to list the direct submodules and the directories with .git in them that are not yet submodules of the top-level superproject, but the latter is limited to those with no parent directories with .git in them (other than the top-level of the working tree of the superproject). With $ git submodule foreach --untracked --recursive you would see submodules and their submodules recursively, and also directories with .git in them (i.e. candidates to become direct submodules of the superproject) and the directories with .git in them inside such submodule candidates (i.e. candidates to become direct submodules of the directories that could become direct submodules of the superproject) recursively. If we set things up this way: mkdir -p a/b c/d for d in . a a/b c c/d do git init $d ( cd $d git commit --allow-empty -m initial ) done git add a ( cd a git add b ) The expected results for various combinations are: * git submodule foreach would visit 'a' and nothing else; * git submodule foreach --recursive would visit 'a' and 'a/b'; * git submodule foreach --untracked would visit 'a' and 'c'; and * git submodule foreach --untracked --recursive would visit all four. -- To unsubscribe from this list: send the line 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: Re: Segmentation fault with latest git (070c57df)
Jonathan Nieder wrote: Jongman Heo wrote: Unfortunately, the patch didn't help to me. Thanks for testing. Did you apply the patch to the older version of git that generates builtin/.depend/fetch.o.d or the newer version that consumes it? Curious, Jonathan Hi, Jonathan, I applied the patch to newer version. This time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. Thanks~! Best regards, Jongman Heo
Re: Segmentation fault with latest git (070c57df)
Jongman Heo jongman@samsung.com writes: Jonathan Nieder wrote: Jongman Heo wrote: Unfortunately, the patch didn't help to me. Thanks for testing. Did you apply the patch to the older version of git that generates builtin/.depend/fetch.o.d or the newer version that consumes it? Curious, Jonathan Hi, Jonathan, I applied the patch to newer version. This time, I tried to apply the patch to older version of Makefile, and now the issue is fixed~. Thanks~! Yeah, that result is understandable, as .depend/*.o.d files will not be rebuilt when the rules to build them changes in the Makefile. Applying the patch to the Makefile in the pristine old tree, run the build (which will generate .depend/*.o.d files with the corrected rules), then checking out the new tree and running the build again without make clean, with or with the patch applied, would validate that the patch fixes the issue for old ccache. Thanks Jonathan for diagnosing, fixing, and thanks Jongman for testing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] branch: show rebase/bisect info when possible instead of (no branch)
On Mon, Feb 4, 2013 at 4:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: --- a/t/t6030-bisect-porcelain.sh +++ b/t/t6030-bisect-porcelain.sh @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing .git/BISECT_START not modified if cp .git/BISECT_START saved test_must_fail git bisect start $HASH4 foo -- git branch branch.output - test_i18ngrep * (no branch) branch.output /dev/null + test_i18ngrep * (bisecting other) branch.output /dev/null I'd have spelled it (no branch, bisecting other) to make it clear that we're on detached HEAD, and avoid confusing old-timers. But maybe your version is enough, I'm not sure. If we want to make it clear, I think the standard * (no branch) should become * HEAD (detached) or non-detached case: * HEAD - foo Then we could present rebase/bisect information as * HEAD (detached, bisecting) * HEAD (detached, rebasing) * foo (rebasing) I don't want to make this line too long because it would break (well, waste space in) column layout. So if we do this, no branch name added for rebase/bisect. -- 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] Verify Content-Type from smart HTTP servers
Jeff King p...@peff.net writes:
I was specifically thinking of this (on top of your patch):
diff --git a/remote-curl.c b/remote-curl.c
index e6f3b63..63680a8 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -134,14 +134,12 @@ static struct discovery* discover_refs(const char
*service)
last-buf_alloc = strbuf_detach(buffer, last-len);
last-buf = last-buf_alloc;
- if (maybe_smart 5 = last-len last-buf[4] == '#') {
+ strbuf_addf(exp, application/x-%s-advertisement, service);
+ if (maybe_smart !strbuf_cmp(exp, type)) {
/*
* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
- strbuf_addf(exp, application/x-%s-advertisement, service);
- if (strbuf_cmp(exp, type))
- die(invalid content-type %s, type.buf);
if (packet_get_line(buffer, last-buf, last-len) = 0)
die(%s has invalid packet header, refs_url);
if (buffer.len buffer.buf[buffer.len - 1] == '\n')
To just follow the dumb path if we don't get the content-type we expect.
We may want to keep the '#' format check in addition (packet_get_line
will check it and die, anyway, but we may want to drop back to
considering it dumb, just to protect against a badly configured dumb
server which uses our mime type, but I do not think it likely).
Yeah, but it doesn't cost anything to check, so let's do so.
Does this look good to both of you (relative to Shawn's patch)?
remote-curl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index e6f3b63..933c69a 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -134,14 +134,14 @@ static struct discovery* discover_refs(const char
*service)
last-buf_alloc = strbuf_detach(buffer, last-len);
last-buf = last-buf_alloc;
- if (maybe_smart 5 = last-len last-buf[4] == '#') {
+ strbuf_addf(exp, application/x-%s-advertisement, service);
+ if (maybe_smart
+ (5 = last-len last-buf[4] == '#')
+ !strbuf_cmp(exp, type)) {
/*
* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
- strbuf_addf(exp, application/x-%s-advertisement, service);
- if (strbuf_cmp(exp, type))
- die(invalid content-type %s, type.buf);
if (packet_get_line(buffer, last-buf, last-len) = 0)
die(%s has invalid packet header, refs_url);
if (buffer.len buffer.buf[buffer.len - 1] == '\n')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] branch: show rebase/bisect info when possible instead of (no branch)
On Mon, Feb 4, 2013 at 2:14 PM, Duy Nguyen pclo...@gmail.com wrote: * foo (rebasing) Well, this one does not make sense (or causes more confusion). -- 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
pandora charms happen to be an exquisite individual variant within the charisma accessory
pandora charms http://www.pandoracheapcanada.com is not really an individual's early days charisma accessory, however , it's quite as exceptional. On earth do you take into account the main charisma accessory everyone used the as the young lady? Which you were which means that proud of every last different charisma that you included to an individual's set together with when compared to it all towards your friends' necklace. Maybe you have a good roller skate, a good ballet slipper, or simply a pom-pom. They had new puppy together with kitten necklaces that will speak for their favorite family dog. You would probably search for a innovative charisma that will symbolize every one different attraction or simply achievements. As the souvenir with a fun holiday vacation, you could add more one other charisma. In a little while, you experienced a seriously dangly accessory approximately an individual's wrist. Some people choose to adored it all, you have got to tell you it all regularly have stuck regarding details and perchance quite possibly spoiled a handful of knitwear. Could be you still have the fact that ancient charisma accessory filed scattered in your own Jewelry compartment. Anytime you notice it all, everyone look at every one charisma together with take into account an item prized in the early days. You can will not by chance dream about being dressed in it all just as before, yet your not losing it all also. Pandora Necklaces is definitely beautiful individual variant within the charisma accessory. Those necklaces are designed to speak for points that happen to be exceptional to your stylish an innovative the baby or simply a most loved holiday vacation, yet Pandora Necklaces happen to be terribly distinct from any dangly silver and gold handy work for former. To develop an individual's exceptional pandora charms canada http://www.pandoracheapcanada.com , get started on out when using the accessory again. Pick precious metal, precious metal by using a jewelry snatch, or simply a ton of 14K jewelry. Necklace incorporate the lobster clasp or simply any Pandora clasp the fact that appearance like one other Pandora Charisma and definitely will squeeze in seamlessly utilizing everything else for your different accessory. Estimate an individual's wrist together with add more 1. 5 long to your wonderful in good shape anytime enjoy an individual's accessory specifications. Snap solution stands out as the up coming consideration. You could test any shows that you choose to apply to an individual's accessory. Feel free to use exact same styles meant for proportion or simply you could look at different ones meant for vast array. Those shows could distinguish an individual's accessory towards unique segments and prevent any necklaces with slip out as you retain an individual's accessory. Any shows shall be interesting to decide since they're at the same time Pandora Necklaces. Any interesting fifty percent of is available after that. Consider with about 900 Pandora Necklaces that will speak for an individual's hobbies and interests together with layout. At last, exercise . spacers so as to add facet towards your accessory or even to head out the fact that exceptional charisma. AdChoices charms for pandora bracelets http://www.pandoracheapcanada.com are fashioned during silver and gold. A lot of offer rocks or simply semi-precious gallstones. One can find many phenomenal gatherings to you that will collection, yet below are some which you could make by using a exceptional Pandora Charm:http://www.pandoracheapcanada.com -- View this message in context: http://git.661346.n2.nabble.com/pandora-charms-happen-to-be-an-exquisite-individual-variant-within-the-charisma-accessory-tp7576896.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tiffany uk: fashionables
As one of the numerous agreed on earrings, tiffany uk http://www.cheapstiffanyandcoclub.co.uk . adornment is getting when the allow to be aware of any cool gal in any curve within the society. Yet, any Tiffany Earrings Adornment originates out when using the fasted velocity when the fast validation within the most critical styles during the looks society. I'd like to allotment on you utilizing certain different hints, whilst everyone allow to have certain stategies to tell you any complete earrings. You could acquire related to most of the argent adornment comes along with graven dirt or simply peel off stickers for those who shop for it all, which unfortunately conveys persons the region for professional or simply any alloy devices within the Tiffany Adornment you wish to shop for. Often, any peel off stickers when using the adornment stage any put in rich analogy for supporting go out with, attributes, accession progression, attentions, together with right bazaar level for example. To analyze any dirt over the adornment one of many will recommendation everyone to locate the most critical styles conveniently, however , in the process will looks everyone any adornment is certainly different or simply old. Ordinarily, any dirt for Tiffany Adornment happen to be authentic minor, which will acquaint everyone the adventure with regards to the adornment or certain adventurous type of adulation excitement enclosing for it. Certain dirt seem to be utilizing ensemble or simply level passcode, which unfortunately betoken certain necessary recommendation with regards to the Earrings At discount. On earth do you apperceive what precisely any acceptation within the make for 92. 5 over the Tiffany Adornment is certainly? It's the argent agreed on in the us alone that gives any argent material. The fact that agent any argent is certainly fabricated for 92. 5 p . c notable argent together with 7. 5 p . c admixture that can carry out any adornment rich put in strong. During the tiffany rings http://www.cheapstiffanyandcoclub.co.uk Adornment retail outlet, most of the adornment delivers the make within the ensemble business logo Tiffany Co. whilst others allow any graven 92. 5 make principal within the sounds, necklaces or simply bangles, any brooch for jewelry or simply necklace. Any adornment once all dirt accepts to generally be aerial styles. And also make often is certainly very clear mainly because. 925. www.cheapstiffanyandcoclub.co.uk -- View this message in context: http://git.661346.n2.nabble.com/tiffany-uk-fashionables-tp7576897.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
