[PATCH] t2202: make sure "git add" (no args) stays a no-op
Signed-off-by: Junio C Hamano --- t/t2202-add-addremove.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t2202-add-addremove.sh b/t/t2202-add-addremove.sh index 6a81510..fc8b59e 100755 --- a/t/t2202-add-addremove.sh +++ b/t/t2202-add-addremove.sh @@ -41,4 +41,14 @@ test_expect_success 'git add --all' ' test_cmp expect actual ' +test_expect_success 'Just "git add" is a no-op' ' + git reset --hard && + echo >will-remove && + >will-not-be-added && + git add && + git diff-index --name-status --cached HEAD >actual && + >expect && + test_cmp expect actual +' + test_done -- 1.8.3.3-1028-g038de5b -- To unsubscribe from this list: send the line "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/7] connect.c: teach get_remote_heads to parse "shallow" lines
Nguyễn Thái Ngọc Duy writes:
> diff --git a/cache.h b/cache.h
> index dd0fb33..7665e03 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1091,6 +1091,7 @@ struct extra_have_objects {
> };
> extern struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
>struct ref **list, unsigned int flags,
> + struct extra_have_objects *,
>struct extra_have_objects *);
When it is the sole parameter of a specific type (i.e. not "char *",
int, size_t, etc. but an application specific structure like "struct
extra_have_objects *"), it is perfectly fine (and even preferrable)
to omit the parameter name from the declaration, as it is clear what
the parameter is and means.
But when you add another of the same type, you need to give both of
them a descriptive name (e.g. the ones you use in the definition).
Otherwise, somebody who wants to write a caller cannot tell which
"struct extra_have_objects *" parameter is the extra and which one
is the shallow graft points list.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] fetch-pack: support fetching from a shallow repository
Nguyễn Thái Ngọc Duy writes:
> Only server graft points that do not have corresponding SHA-1s in
> local repo are added to the temp shallow file because we don't want to
> accidentally cut the client history because the server's is
> shorter. The client cutting can only happen when --depth is requested.
This "have corresponding SHA-1" is iffy from connectivity point of view,
isn't it? That is,...
> + for (i = 0; i < extra->nr; i++) {
> + if (!remove_unused_grafts && has_sha1_file(extra->array[i]))
...shouldn't this require much more than "has_sha1_file()", like
"has it, and we have everything behind it with respect to the
shallow graft points we started with" or something?
Otherwise an isolated island that was left behind by an earlier
aborted commit walker fetch may mislead us to believe that we have
the complete history behind this commit object.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] config: improve support for http..* settings
"Kyle J. McKay" writes: > If you mean for all the strchr etc. calls, multiple tables would be > required since URL_SCHEME_CHARS and URL_HOST_CHARS partially overlap, The entries of the table could be at least 8-bit wide, so there shouldn't be any problem, should there? > but it could be done. Is the speed of strchr that much of a concern? > The code will only be invoked for http..* option settings in any > case and I expect the user would have to set an awfully large number > of those to even begin to notice. We can start slow and then optimize, but I suspect that there are sufficient number of people who are into micro-optimizing, and such a slow implementation may quickly be replaced. -- To unsubscribe from this list: send the line "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: One question about git-format-patch
Junio C Hamano writes: >> I’m a git user, and recently I’ve noticed there’re some differences between >> “$ git format-patch –n” and “$ git format-patch HEAD~n”. According to the >> documentation: “- Prepare patches from the topmost commits.” > > Correct. However, HEAD~n will prepare patches for commits that are > not ancestor of HEAD~n. > > And there may well be a lot more than n such commits, unless you are > working on a strictly linear history. Every once in a while, a illustration would help new folks. In this history (as always, the time and ancestry topology flows from left to right): E---F---G / / A---B---C---D imagine that your HEAD is at commit G. - G~1 == G^ == F - G~2 == G^^ == E (suppose F is a merge of D made on E) - G~3 == G^^^ == B - G~4 == G == A so "git format-patch HEAD~4" will give you B, C, D, E and G (five commits). Asking for "git format-patch -n 4" does not make much sense in a history like this, but it will give you G, D, C, E and at that point you have seen 4 commits, so you won't get B. Note that if F were a merge of E made on D, that would make - G~2 == G^^ == D - G~3 == G^^^ == C - G~4 == G == B And "git format-patch HEAD~4" will give you C, D, E and G (four commits). -- To unsubscribe from this list: send the line "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 tag output order is incorrect (IMHO)
On Fri, Jul 19, 2013 at 12:40:55PM -0700, Junio C Hamano wrote: > Andreas Schwab writes: > > > Rahul Bansal writes: > > > >> IMHO "git tag" is expected to show tag-list ordered by versions. > > > > A git tag can be anything, not related to versions at all. > > Correct. > > But that does not prevent somebody to add "git tag --sort=X" option > to the command, just like "git for-each-ref" has "--sort=X" option. A while ago I started on (but did not get very far on) unifying the ref selection code for for-each-ref, tag, and branch. It would be nice if they all supported the same set of --contains/--points-at/--merged/--sort, etc. I do plan to finish it eventually, but if anyone else feels like picking it up, I'd be glad to review patches and/or share my work-in-progress as a starting point. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] config: add support for http..* settings
On Jul 19, 2013, at 13:08, Junio C Hamano wrote: "Kyle J. McKay" writes: @@ -337,7 +472,7 @@ void http_init(struct remote *remote, const char *url, int proactive_auth) http_is_verbose = 0; - git_config(http_options, NULL); + git_config(http_options, (void *)url); Can http_init() be called more than once? max-matched-len (and leter user-matched as well) is initialized to zero at the link time, and never reset after it is used for matching the configuration file entries with a single URL. If this function is called more than once, the code needs to memset(0) the array(s), don't it? The http_init() function is never called more than once. It's called from http_fetch.c, http_push.c, and remote-curl.c exactly once in the main() function, so no worries. However, I do like your idea of bundling them all up into an on-stack variable, I just didn't want to stick those arrays on the stack if it's not necessary it and it seems like it isn't. I think I will just go ahead and add the memset to http_init to avoid unexpected breakage if something in the future actually does make multiple http_init()/http_cleanup() calls during its lifetime. [...] In any case, you no longer have to cast the second parameter of git_config to (void *) only to defeat constness ;-) That goes away in part 4/4 anyhow. :) -- To unsubscribe from this list: send the line "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 v6 2/4] config: improve support for http..* settings
On Jul 19, 2013, at 12:59, Junio C Hamano wrote:
"Kyle J. McKay" writes:
+#define URL_ALPHA
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+#define URL_DIGIT "0123456789"
+#define URL_HEXDIGIT URL_DIGIT "ABCDEFabcdef"
+#define URL_ALPHADIGIT URL_ALPHA URL_DIGIT
+#define URL_SCHEME_CHARS URL_ALPHADIGIT "+.-"
+#define URL_HOST_CHARS URL_ALPHADIGIT ".-[:]" /* IPv6 literals
need [:] */
+#define URL_UNSAFE_CHARS " <>\"%{}|\\^`" /* plus 0x00-0x1F,
0x7F-0xFF */
+#define URL_GEN_RESERVED ":/?#[]@"
+#define URL_SUB_RESERVED "!$&'()*+,;="
+#define URL_RESERVED URL_GEN_RESERVED URL_SUB_RESERVED /* only
allowed delims */
+ ...
+ while (from_len) {
+ int ch = *from++;
+ int was_esc = 0;
+
+ from_len--;
+ if (ch == '%') {
+ if (from_len < 2 ||
+ !strchr(URL_HEXDIGIT, from[0]) ||
+ !strchr(URL_HEXDIGIT, from[1]))
I actually do like the readability of the approach in this patch,
but these repeated strchrs() in a loop may want to be optimized,
using a trick similar to what is used in ctype.c::sane_ctype[].
A small build-time-only program or script gen-http-ctype.perl that
defines and uses these URL_* cpp macros and generates a C source
file http-ctype-gen.c that can be #included from http.c, with
something like this in the Makefile:
http-ctype-gen.c: gen-http-ctype.perl
rm -f $@ $@+
$(PERL_PATH) gen-http-ctype.perl >$@+
mv $@+ $@
http.o: http.c http-ctype-gen.c
would give us both readability and efficiency, perhaps?
Hmmm. That's a very fast technique. However something like:
#define IS_HEX_DIGIT(c) \
(('0'<=(c)&&(c)<='9')||('a'<=(c)&&(c)<='f')||('A'<=(c)&&(c)<='F'))
I would think would be suitably fast without needing any added build
files.
However, looks like there is a ctype.h isxdigit() function and it
looks like there's a version of that in git-compat-util.h as well as a
convenient hexval_table to use for the conversion, so I will alter the
code to use those instead which will also do away with the
hex_digit_value() function.
If you mean for all the strchr etc. calls, multiple tables would be
required since URL_SCHEME_CHARS and URL_HOST_CHARS partially overlap,
but it could be done. Is the speed of strchr that much of a concern?
The code will only be invoked for http..* option settings in any
case and I expect the user would have to set an awfully large number
of those to even begin to notice.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RESPOND URGENTLY!!
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels...@yahoo.com.hk. Have a pleasant day. George Daniels -- To unsubscribe from this list: send the line "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] Cygwin has trustable filemode
Mark Levedahl wrote: > After merging the following into current pu, all tests that run by > default pass on Cygwin 1.7, i.e. > prove -j 8 t[0-9]*.sh > reports "All tests successful." > I've *never* had this happen on Cygwin before. Nice. Thanks for your hard work. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Cygwin has trustable filemode
On 07/19/2013 03:16 PM, Junio C Hamano wrote: Mark Levedahl writes: Related: Should we have separate settings for 1.5 and 1.7 for several variables? Conflicts I see not reflected in config.mak.uname on pu: trustable filemode (1.7 has, 1.5 does not) MMAP/Pread (1.7 pread is thread safe, 1.5 I dont think was, MMAP utility is convolved in this) regex - 1.7 is broken, per Ramsay 1.5 works If you think its worth it, I'll create a patch series with the above and justifications for the different settings that I know. I'd say that would be a sensible thing to do, given that the alternative seems to be "let's drop 1.5 support right now, because otherwise we cannot run Git on 1.7". Ok, the following sequence builds up options for Cygwin 1.7 while leaving Cygwin 1.5 as-is. This series should replace dad577f Cygwin has trustable filemode 174bb98 Use compat/regex on Cygwin After merging the following into current pu, all tests that run by default pass on Cygwin 1.7, i.e. prove -j 8 t[0-9]*.sh reports "All tests successful." I've *never* had this happen on Cygwin before. Mark Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] Cygwin 1.7 supports mmap
git has shipped for years with MMAP enabled in the stock distribution, there are no reports of problems / failures on the list relating to this. Leave the default as-is on v1.5 due to lack of knowlege of this working on earlier Cygwin. Signed-off-by: Mark Levedahl --- config.mak.uname | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/config.mak.uname b/config.mak.uname index 048c252..32e8332 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -161,16 +161,16 @@ ifeq ($(uname_O),Cygwin) NO_TRUSTABLE_FILEMODE = UnfortunatelyYes OLD_ICONV = UnfortunatelyYes NO_THREAD_SAFE_PREAD = YesPlease + # There are conflicting reports about this. + # On some boxes NO_MMAP is needed, and not so elsewhere. + # Try commenting this out if you suspect MMAP is more efficient + NO_MMAP = YesPlease else NO_REGEX = UnfortunatelyYes endif NEEDS_LIBICONV = YesPlease NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease - # There are conflicting reports about this. - # On some boxes NO_MMAP is needed, and not so elsewhere. - # Try commenting this out if you suspect MMAP is more efficient - NO_MMAP = YesPlease X = .exe COMPAT_OBJS += compat/cygwin.o UNRELIABLE_FSTAT = UnfortunatelyYes -- 1.8.3.2.0.13 -- To unsubscribe from this list: send the line "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] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine writes: >> With no repository or branch on the command line, `git pull` needs >> to be told how to integrate the changes with your history. >> >> This can be done via either `--merge` or `--rebase` option, but most >> people would want to decide which method matches the workflow of the >> project once, and set the configuration variable `pull.rebase` or >> `branch..rebase` to stick to it; see linkgit:git-config[1]. > > At this point, I'm probably just bike-shedding. Perhaps? > > With no repository or branch on the command line, `git pull` > needs to be told how to integrate the changes with your history, > via either `--merge` or `--rebase`. > > To match a project's workflow and make the choice of merge or > rebase permanent, set configuration variable `pull.rebase` or > `branch..rebase` (see linkgit:git-config[1]). I agree with the bike-shedding aspect of your comment, and actually I like my version better. It makes it clear that a single-shot --merge or --rebase from the command line is not recommended. "To match the project's workflow" is not optional in most projects, and it is preferrable to decide once and set the choice in stone. -- To unsubscribe from this list: send the line "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] Delete current branch
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>> Did you know that the general way to spell the branch previously you
>>> were on is "@{-1}" and "checkout -" is an ugly special case that is
>>> possible only because "checkout" does not happen to take a "-" as a
>>> valid argument that means something else (like the more usual "read
>>> from standard input")?
>>
>> I disagree that it is ugly: it's a very commonly used shortcut that I
>> like.
>
> It does not matter if you like it or not ;-).
>
> I do agree that "checkout -" is 100% more pleasing to the eye than
> "checkout @{-1}" from visual "prettyness" point of view.
>
> But there is a very commonly accepted long tradition for "-" to mean
> "read from the standard input", so we cannot reuse it to mean "the
> branch I was previously on" for every command without first making
> sure the command will never want to use "-" for the other common
> purpose.
>
> That limits the context we could use "-" and we cannot consistently
> use it everywhere. I find _that_ ugly from the "design cleanliness"
> point of view.
Having said all that.
d18ba221 (sha1_name: support @{-N} syntax in get_sha1(), 2009-01-17)
was primarily for the follow-up patch 696acf45 (checkout: implement
"-" abbreviation, add docs and tests, 2009-01-17). Two years after
them, we finally did 4e8115ff (merge: allow "-" as a short-hand for
"previous branch", 2011-04-07).
There is no reason we cannot continue.
As long as the addition is carefully prepared so that we know it
will not conflict (or be confused by users) with possible other uses
of "-", I do not think we would mind "git branch -D -" and other
commands to learn "-" as a synonym for @{-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
[PATCH 1/4] Cygwin 1.7 has trustable filemode
The current Cygwin 1.7 distribution on supported Windows versions provides complete support for POSIX filemodes, so enable this by default. git as distributed by the Cygwin project is configured this way. Cygwin 1.5 installations are less likely to have this support, so leave the old default in place for those. This fixes one testsuite failure: t3300 test 17 (diff-index -M -p with mode change quotes funny filename) Historical notes: Cygwin version 1.7 supports Windows-XP and newer, thus dropped support for all OS variants that lack NTFS and/or the full win32 api, and since late 1.5 development, Cygwin maps POSIX modes to NTFS ACLs by default. Cygwin 1.5 supports OS variants that use FAT as the native file system, and had optional methods for providing POSIX file modes on top of FAT12/16 and NTFS, though not FAT32. Also, support for POSIX modes on top of FAT were dropped later in 1.5. Thus, POSIX filemode support is not expected by default on a Cygwin 1.5 installation, but is expected by default on a 1.7 installation. Signed-off-by: Mark Levedahl --- config.mak.uname | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index 7ac541e..104dc44 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -158,12 +158,12 @@ ifeq ($(uname_O),Cygwin) NO_MKSTEMPS = YesPlease NO_SYMLINK_HEAD = YesPlease NO_IPV6 = YesPlease + NO_TRUSTABLE_FILEMODE = UnfortunatelyYes OLD_ICONV = UnfortunatelyYes endif NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes - NO_TRUSTABLE_FILEMODE = UnfortunatelyYes NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease # There are conflicting reports about this. # On some boxes NO_MMAP is needed, and not so elsewhere. -- 1.8.3.2.0.13 -- To unsubscribe from this list: send the line "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: One question about git-format-patch
> I’m a git user, and recently I’ve noticed there’re some differences between > “$ git format-patch –n” and “$ git format-patch HEAD~n”. According to the > documentation: “- Prepare patches from the topmost commits.” Correct. However, HEAD~n will prepare patches for commits that are not ancestor of HEAD~n. And there may well be a lot more than n such commits, unless you are working on a strictly linear history. -- To unsubscribe from this list: send the line "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/4] Cygwin 1.7 needs compat/regex
Cygwin v1.7 uses the regex library from newlib which does not pass git's tests, so don't use it. This fixes failures in t4018 and t4034. Continue to use the platform supplied regex library for earlier versions. Signed-off-by: Mark Levedahl --- config.mak.uname | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index 104dc44..8652da9 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -160,6 +160,8 @@ ifeq ($(uname_O),Cygwin) NO_IPV6 = YesPlease NO_TRUSTABLE_FILEMODE = UnfortunatelyYes OLD_ICONV = UnfortunatelyYes + else + NO_REGEX = UnfortunatelyYes endif NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease -- 1.8.3.2.0.13 -- To unsubscribe from this list: send the line "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/4] Cygwin 1.7 has thread-safe pread
Per http://cygwin.com/ml/cygwin/2012-07/msg00331.html , cygwin 1.7 was modified to explicitly support git's use of pread, so make this the default. Do not affect earlier cygwin versions. Signed-off-by: Mark Levedahl --- config.mak.uname | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index 8652da9..048c252 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -160,10 +160,10 @@ ifeq ($(uname_O),Cygwin) NO_IPV6 = YesPlease NO_TRUSTABLE_FILEMODE = UnfortunatelyYes OLD_ICONV = UnfortunatelyYes + NO_THREAD_SAFE_PREAD = YesPlease else NO_REGEX = UnfortunatelyYes endif - NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease -- 1.8.3.2.0.13 -- To unsubscribe from this list: send the line "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] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jul 19, 2013 at 6:20 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >> Dropping the parenthetical comment might improve flow slightly: >> >> Without repository or branch on the command line, `git pull` >> needs to be told how to integrate the changes with your history, >> via either `--merge` or `--rebase`. >> >> With or without mention of the configuration options, either phrasing >> seems pretty easy to digest. > > Yeah, that reads much better, but I do prefer to see something that > explains this is often "just make sure you use the one that suits > your project and always use that". How about something like this? > > With no repository or branch on the command line, `git pull` needs > to be told how to integrate the changes with your history. > > This can be done via either `--merge` or `--rebase` option, but most > people would want to decide which method matches the workflow of the > project once, and set the configuration variable `pull.rebase` or > `branch..rebase` to stick to it; see linkgit:git-config[1]. At this point, I'm probably just bike-shedding. Perhaps? With no repository or branch on the command line, `git pull` needs to be told how to integrate the changes with your history, via either `--merge` or `--rebase`. To match a project's workflow and make the choice of merge or rebase permanent, set configuration variable `pull.rebase` or `branch..rebase` (see linkgit:git-config[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: [PATCH 1/3] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
Stefan Beller writes: > So is there any up-to-date task list for beginning contributors? I am fairly bad at keeping track of small things incrementally, as it is often quicker to do them myself if/when I were so inclined, but there are too many of them and a day does not have enough number of seconds X-<. These days, I tend to scan the mailing list backlog in batch every once in a while. http://git-blame.blogspot.com/search?q=leftover+bits may show some of them. Thanks for asking and volunteering. -- To unsubscribe from this list: send the line "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] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine writes: > Dropping the parenthetical comment might improve flow slightly: > > Without repository or branch on the command line, `git pull` > needs to be told how to integrate the changes with your history, > via either `--merge` or `--rebase`. > > With or without mention of the configuration options, either phrasing > seems pretty easy to digest. Yeah, that reads much better, but I do prefer to see something that explains this is often "just make sure you use the one that suits your project and always use that". How about something like this? With no repository or branch on the command line, `git pull` needs to be told how to integrate the changes with your history. This can be done via either `--merge` or `--rebase` option, but most people would want to decide which method matches the workflow of the project once, and set the configuration variable `pull.rebase` or `branch..rebase` to stick to it; see linkgit:git-config[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: [PATCH 6/6] diff: deprecate -q option to diff-files
Junio C Hamano wrote: > Jonathan Nieder writes: >> I don't mind seeing support for "-q" dropped, but I really don't think >> it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some >> future release/ be ok? > > I do not think keeping the support for "-q" in is any huge burden. > We do not have to remove it, forever, for that matter. I agree with the above, which is why I don't want a promise to remove the "-q" option to cause Git 2.0 to be delayed. It would be better to schedule it for Git 3.0, or for another unspecified future git release. I thought the 2.0 boundary was a time for changes that everyone already knew we should make, where we had been waiting for a good moment to change behavior while giving people adequate warning to avoid disrupting them too much. We have a good collection of those for 2.0, and the next batch can wait until 3.0. Sorry for the lack of clarity, 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
Сумка - легенда из итальянского бутика за I5 955 р!
Теплый шарфик в дар! http://cortalo.com/83526 -- To unsubscribe from this list: send the line "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 v6 2/4] config: improve support for http..* settings
"Kyle J. McKay" writes:
> +#define URL_ALPHA "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
> +#define URL_DIGIT "0123456789"
> +#define URL_HEXDIGIT URL_DIGIT "ABCDEFabcdef"
> +#define URL_ALPHADIGIT URL_ALPHA URL_DIGIT
> +#define URL_SCHEME_CHARS URL_ALPHADIGIT "+.-"
> +#define URL_HOST_CHARS URL_ALPHADIGIT ".-[:]" /* IPv6 literals need [:] */
> +#define URL_UNSAFE_CHARS " <>\"%{}|\\^`" /* plus 0x00-0x1F,0x7F-0xFF */
> +#define URL_GEN_RESERVED ":/?#[]@"
> +#define URL_SUB_RESERVED "!$&'()*+,;="
> +#define URL_RESERVED URL_GEN_RESERVED URL_SUB_RESERVED /* only allowed
> delims */
> + ...
> + while (from_len) {
> + int ch = *from++;
> + int was_esc = 0;
> +
> + from_len--;
> + if (ch == '%') {
> + if (from_len < 2 ||
> + !strchr(URL_HEXDIGIT, from[0]) ||
> + !strchr(URL_HEXDIGIT, from[1]))
I actually do like the readability of the approach in this patch,
but these repeated strchrs() in a loop may want to be optimized,
using a trick similar to what is used in ctype.c::sane_ctype[].
A small build-time-only program or script gen-http-ctype.perl that
defines and uses these URL_* cpp macros and generates a C source
file http-ctype-gen.c that can be #included from http.c, with
something like this in the Makefile:
http-ctype-gen.c: gen-http-ctype.perl
rm -f $@ $@+
$(PERL_PATH) gen-http-ctype.perl >$@+
mv $@+ $@
http.o: http.c http-ctype-gen.c
would give us both readability and efficiency, perhaps?
--
To unsubscribe from this list: send the line "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 tag output order is incorrect (IMHO)
Andreas Schwab writes: > Rahul Bansal writes: > >> IMHO "git tag" is expected to show tag-list ordered by versions. > > A git tag can be anything, not related to versions at all. Correct. But that does not prevent somebody to add "git tag --sort=X" option to the command, just like "git for-each-ref" has "--sort=X" option. -- To unsubscribe from this list: send the line "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] rev-parse(1): logically group options
John Keeping writes: > The options section of the git-rev-parse manual page has grown > organically so that there now does not seem to be much logic behind the > ordering of the options. It also does not make it clear that certain > options must appear first on the command line. > > Address this by reorganising the options into groups with subheadings. > The text of option descriptions does not change. > > Signed-off-by: John Keeping The idea to introduce a general grouping makes a lot of sense, I think. > +Operation Modes > +~~~ > + > +Each of these options must appear first on the command line. > + > +--local-env-vars:: > + List the GIT_* environment variables that are local to the > + repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR). > + Only the names of the variables are listed, not their value, > + even if they are set. Honestly speaking, "must appear first" for "--local-env-vars" is a bug in implementations of this option, I think. It does not make sense to ask git rev-parse --local-env-vars -- Makefile and the command operates on "--" and "Makefile" in the normal operation mode, not "local-env-vars" mode. > + > --parseopt:: > Use 'git rev-parse' in option parsing mode (see PARSEOPT section below). > > +--resolve-git-dir :: > + Check if is a valid repository or a gitfile that > + points at a valid repository, and print the location of the > + repository. If is a gitfile then the resolved path > + to the real repository is printed. > + > +--sq-quote:: > + Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE > + section below). In contrast to the `--sq` option below, this > + mode does only quoting. Nothing else is done to command input. > +Options for Input > +~ > > +--show-toplevel:: > + Show the absolute path of the top-level directory. > + > +--show-cdup:: > + When the command is invoked from a subdirectory, show the > + path of the top-level directory relative to the current > + directory (typically a sequence of "../", or an empty string). > + > --is-inside-git-dir:: > When the current working directory is below the repository > directory print "true", otherwise "false". > @@ -188,17 +219,10 @@ print a message to stderr and exit with nonzero status. > --is-bare-repository:: > When the repository is bare print "true", otherwise "false". > > +--show-prefix:: > + When the command is invoked from a subdirectory, show the > + path of the current directory relative to the top-level > + directory. I am not sure if --show-*, --is-*, and --git-dir belongs to "options for input". They are truly kitchen sink options to ask for various aspects of the repository and directory, and it may be equally valid (or even more valid) to consider them as separate operation modes. -- To unsubscribe from this list: send the line "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] traverse_trees(): clarify return value of the callback.
The variable name ret sounds like the variable to be returned, but
since e6c111b4 we return error. Hence the variable name is miss leading.
As this variable is used only to extract the bits from the callback of
a tree object, trees_used is a better name.
Also the assignment to 0 was removed at the start of the function as well
after the if(interesting) block. Those were unneeded as that variable
is set to the callback return value any time we enter the if(interesting)
block, so we'd overwrite old values anyway.
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
tree-walk.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index c366852..5ece8c3 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -324,7 +324,6 @@ static inline int prune_traversal(struct name_entry *e,
int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
{
- int ret = 0;
int error = 0;
struct name_entry *entry = xmalloc(n*sizeof(*entry));
int i;
@@ -342,6 +341,7 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
strbuf_setlen(&base, info->pathlen);
}
for (;;) {
+ int trees_used;
unsigned long mask, dirmask;
const char *first = NULL;
int first_len = 0;
@@ -405,15 +405,14 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
if (interesting < 0)
break;
if (interesting) {
- ret = info->fn(n, mask, dirmask, entry, info);
- if (ret < 0) {
- error = ret;
+ trees_used = info->fn(n, mask, dirmask, entry, info);
+ if (trees_used < 0) {
+ error = trees_used;
if (!info->show_all_errors)
break;
}
- mask &= ret;
+ mask &= trees_used;
}
- ret = 0;
for (i = 0; i < n; i++)
if (mask & (1ul << i))
update_extended_entry(tx + i, entry + i);
--
1.8.3.3.754.g9c3c367.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jul 19, 2013 at 12:22 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> +When `git pull` that does not explicitly specify what branch from >>> +which repository is to be integrated with your history on the >>> +command line, recent Git will refuse to work until you specify how >>> +that integration should happen, either with a command line option >>> +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` >>> +or `branch..rebase`, which is the same as `--merge` >>> +(`--rebase`) when set to `false` (`true`) respectively. >> >> This paragraph-long single sentence may be intimidating. Perhaps some >> simplification is possible: >> >> As a safety measure, bare `git pull` (without repository or >> branch) needs to be told how to integrate pulled changes with >> your history; either via `--merge` or `--rebase`. Also see >> configuration variables `pull.rebase` and `branch..rebase` >> in linkgit:git-config[1]. >> >> I intentionally omitted the true/false explanation of the >> configuration variables since the user can follow the link and read >> about them. It also may make sense to drop mention of those variables >> altogether since they are already described (including link) in the >> description of --rebase. >> >> I also intentionally omitted "recent Git" since it's rather nebulous. > > Looks much better than the original. I would further suggest > dropping the "As a safety measure, bare " at the beginning. > > `git pull` (without repository or branch on the command line) > needs to be told how to integrate the changes with your > history via either `--merge` or `--rebase` (see configuration > variables `pull.rebase` and `branch..rebase` in > linkgit:git-config[1]). > > perhaps? That works; or without the mentioning the configuration variables at all (assuming the reader will discover them from reading --rebase description): `git pull` (without repository or branch on the command line) needs to be told how to integrate the changes with your history via either `--merge` or `--rebase`. Dropping the parenthetical comment might improve flow slightly: Without repository or branch on the command line, `git pull` needs to be told how to integrate the changes with your history, via either `--merge` or `--rebase`. With or without mention of the configuration options, either phrasing seems pretty easy to digest. -- To unsubscribe from this list: send the line "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] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
On 07/19/2013 08:13 PM, Junio C Hamano wrote: > The "ret" was meant to mean "the return value we got from the > callback function", not "the return value we would give our caller". Thanks for clarifying. I assumed the "ret" was meant as the return value of that function as it was the case before e6c111b4c. In other projects I am using ret as "the return value we would give our caller" as it's such a convenient name for that if you cannot come up with a better name. > > This rename is a bit misleading in that "cb_bits == -1" does not > mean "full bits set", and it does not tell us much what these "bits" > signify. > > They are used to answer this question: which one of the trees in > t[0..n] did the callback function consumed (hence needs their > pointers updated). > > So perhaps call it "trees_used" or something? Sounds indeed way better. I'll rename it. > > By the way, our log message usually do not Capitalize the subject > after the ":", i.e. do something like this instead: > > Subject: [PATCH 1/3] traverse_trees(): clarify return value of the > callback > > Thanks. > Thanks for pointing out. As a general question: I was mostly doing micro-optimisations or the mailmap file, which are rather small fixups, which I think are ok for beginners. Is there a tasklist for beginners, other than that? Such as porting shell commands to C or other larger tasks? I used git://github.com/gitster/git.git as remote/origin. There the todo branch has the last commit as of 2012/04, so I also found git://git.kernel.org/pub/scm/git/git.git, where the todo branch seems more up-to-date, but the TODO file there also seems a little dated to me. So is there any up-to-date task list for beginning contributors? Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] config: add support for http..* settings
"Kyle J. McKay" writes:
> +static size_t http_option_max_matched_len[OPT_MAX];
> ...
> +static int new_match_is_shorter(size_t matchlen, enum http_option_type opt)
> +{
> + /*
> + * Compare matchlen to the last matched length of option opt and
> + * return true if matchlen is shorter than the last matched length
> + * (meaning the config setting should be ignored). Upon seeing the
> + * _same_ key (i.e. new key has the same match length which is therefore
> + * not shorter) the new setting will override the previous setting.
> + * Otherwise return false and record matchlen as the current last
> + * matched length of option opt.
> + */
> + if (matchlen < http_option_max_matched_len[opt])
> + return 1;
> + http_option_max_matched_len[opt] = matchlen;
> + return 0;
> +}
> + ...
> @@ -337,7 +472,7 @@ void http_init(struct remote *remote, const char *url,
> int proactive_auth)
>
> http_is_verbose = 0;
>
> - git_config(http_options, NULL);
> + git_config(http_options, (void *)url);
Can http_init() be called more than once? max-matched-len (and
leter user-matched as well) is initialized to zero at the link time,
and never reset after it is used for matching the configuration file
entries with a single URL.
If this function is called more than once, the code needs to
memset(0) the array(s), don't it?
Another possibility, which might be better, is to package that array
and the url into a structure, have it on the stackframe of this
function, i.e.
struct match_url_state {
const char *url;
size_t http_option_max_matched_len[OPT_MAX];
int http_option_user_matched[OPT_MAX];
} match_url_state = {NULL};
git_config(http_options, &match_url_state);
or something. In any case, you no longer have to cast the second
parameter of git_config to (void *) only to defeat constness ;-)
> curl_global_init(CURL_GLOBAL_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] do_one_ref(): save and restore value of current_ref
Michael Haggerty writes: > I sent the patch shortly before leaving for a trip so I didn't have time > to make it as complete as I would have liked. But given that the > problem was already in master, and the fix is pretty simple, I wanted to > send the fix right away. When I have some time I can fix it up better, That is very much appreciated. How would you describe this fix in a two-to-three line paragraph in Release Notes? -- To unsubscribe from this list: send the line "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] Delete current branch
Taylor Hedberg writes: > Junio C Hamano, Fri 2013-07-19 @ 09:48:06-0700: >> But there is a very commonly accepted long tradition for "-" to mean >> "read from the standard input", so we cannot reuse it to mean "the >> branch I was previously on" for every command without first making >> sure the command will never want to use "-" for the other common >> purpose. > ... > What would it mean to check out the standard input, anyway? That is my point exactly, isn't it? You have to ask that question "What would it mean to do X on the standard input?" for every operation X you might want to use the short-cut "-" for. -- To unsubscribe from this list: send the line "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] Cygwin has trustable filemode
Mark Levedahl writes: > Related: Should we have separate settings for 1.5 and 1.7 for several > variables? Conflicts I see not reflected in config.mak.uname on pu: > trustable filemode (1.7 has, 1.5 does not) > MMAP/Pread (1.7 pread is thread safe, 1.5 I dont think was, MMAP > utility is convolved in this) > regex - 1.7 is broken, per Ramsay 1.5 works > > If you think its worth it, I'll create a patch series with the above > and justifications for the different settings that I know. I'd say that would be a sensible thing to do, given that the alternative seems to be "let's drop 1.5 support right now, because otherwise we cannot run Git on 1.7". -- To unsubscribe from this list: send the line "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 Clone Parameter
"Philip Oakley" writes: >> Allan Acheampong writes: >> >>> ... I'm new to git, but I found it very >>> confusing to understand the difference between "remote" , >>> "remotes". Is it in the cloned repo, or is it in a remote place? >>> If its local, why doesn't it get shown when I do 'git branch' but >>> when I do 'git branch -a'. > > For the uninitiated, the lack of distinct terminology can cause no end > of confusion as most explanations presume that you will implicitly > understand the context, which can't be true for such newbies. True. * You work in a local repository. * You interact with repositories other than the local repository. Here, "to interact" mean "exchange the history with", either by pushing the commits in the local repository to the other one(s), or fetching the commits in the other one(s) to the local repository. These "other repositories" are "remote repositories" from the point of view of the local repository. Note that you may have two repositories you use for working on the same project, one on your desktop and one on your notebook. As far as the repository on your notebook is concerned, the repository on your desktop, if you interact with it from the repository on your notebook, is a "remote repository" (and the one on the desktop views the one on the notebook as "remote"). * Often we call a "remote repository" just a "remote". Especially when we give a convenience short-name to it, like "origin". * When you "clone" from a repository to create a "copy" to work in, from that new repository's point of view, the original repository is a "remote repository", and "git clone" configures things in the new repository so that you can conveniently interact with that original repository. The last part is what lets you say "git fetch origin", for example, to interact with the "origin" remote. * Branches are local to each repository. It is merely a social convention that the primary branch in the repository you cloned from (i.e. your "origin") is often called 'master', the primary branch in the local repository is called 'master', and you often interact with the history of the 'master' branch of the "origin" when you are on your 'master' branch. There is no stronger tie between their 'master' and your 'master' other than the social convention, but Git makes it easier for you to work that way by setting a few configuration variables. * Some of the social conventions, and the configuration Git sets up to let you follow them easily, allows you to find out where the tips of branches at your remotes were, when you last observed them (remember, Git is distributed, so you do not ask "right now"; instead you have "when you last observed" and "make an observation right now" separately). This is achieved by keeping the record of the last observation in "remote-tracking branches". The last observed value of the 'master' branch of the remote repository "origin" is stored as 'origin/master' (its full name is 'refs/remotes/origin/master', but you rarely have to spell it out) remote-tracking branch. CAVEAT: some older documentation call a "remote-tracking branch" just "remote branch", but we have been trying to move away from that practice, as it is confusing, because the 'master' branch at the 'origin' remote is often called a 'remote branch'. When you see 'remote branch', you need to make sure which one the writer meant. * "git fetch" (and "git pull", which internally invokes "git fetch") is a way to "make the observation now". "git fetch origin" updates your remote-tracking branches for the "origin". * "git pull" (and "git pull --rebase") is a way to do the "fetch" above and then integrate the history of the branch at the remote (which now you know its latest state, because you just observed it) with the history you have on your branch. Again, these branches may be named 'master' but the user needs to be aware that they are two separate branches (your 'master' branch is just as a different entity from the 'master' branch of the remote repository as it is your 'next' or any other branch). To make it easier to work, git configures the history of which branch you obtained/observed from what remote is to be integrated with your history per your local branch. Immediately after "git clone", you will typically have your 'master' branch, and the branch "knows" that it wants to integrate with the 'master' branch at 'origin' remote. So "git pull" becomes: - "git fetch origin", because you will integrate with the history that comes from that remote, not other remotes; - which updates 'origin/master' remote-tracking branch, and possibly other remote-tracking branches under 'origin/'; and - integrate your branch with the history of 'origin/master' remote-tracking branch. We say "
Re: [PATCH 2/3] http-push.c, add_send_request: Do not initialize transfer_request.
Patch 2 and 3 look fairly straight-forward. Will queue them directly on 'maint'. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/19] Index-v5
Thomas Gummerer writes:
> What I currently did is add a environment variable GIT_INDEX_VERSION
> that is used only if there is no index yet, to make sure existing
> repositories aren't affected and still have to be converted explicitly
> by using git update-index.
>
> For the tests I simply did export GIT_INDEX_VERSION in test-lib.sh to
> allow the addition of GIT_INDEX_VERSION in config.mak. Should I rename
> that to GIT_INDEX_VERSION_TEST and do something like
>
> set_index_version() {
> export GIT_INDEX_VERSION=$GIT_INDEX_VERSION_TEST
> }
>
> in test-lib-functions.sh instead, does that make sense?
Mostly Yes ;-). You have to write it in a valid POSIX shell, i.e.
set_index_version () {
GIT_INDEX_VERSION=$TEST_GIT_INDEX_VERSION
export GIT_INDEX_VERSION
}
--
To unsubscribe from this list: send the line "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 Clone Parameter
From: "Junio C Hamano" Sent: Friday, July 19, 2013 4:02 PM Allan Acheampong writes: ... I'm new to git, but I found it very confusing to understand the difference between "remote" , "remotes". Is it in the cloned repo, or is it in a remote place? If its local, why doesn't it get shown when I do 'git branch' but when I do 'git branch -a'. Allan, This (not being sure about local remote branches and distant remote branches, while coping with multiple remote servers) appears to be a common problem for new folks, which those well versed in the use of Git have become well used to so don't see the problem. For the uninitiated, the lack of distinct terminology can cause no end of confusion as most explanations presume that you will implicitly understand the context, which can't be true for such newbies. It doesn't help that the 'remotes' model of the Git DVCS fits a work flow style that isn't the same as the expectation of the newbie. For example, in a larger collaboration there can be many many branches (on a communal server) that essentially belong to other contributors which one would never be interested in, and you (and they) would want ignored. ... For example, I create a project locally with multiple branches, push it, delete it locally and clone it back to my machine. On a 'git branch' I would only see the head branch. Junio explains below how your suggestion of 'only the head branch' viewpoint is too limiting (among other things). That said, if you have a terminology for the distinction between the confusing aspects (once understood), then that would be worth something to help ease the path of understanding for others. I had the same confusions for a while, and even now have to use some of the awkward terminology I used above, so any improvements in that area would be useful. -- Branching models are an endless source of discussion! Philip ... I'd like to know your opinions about that and what you think about the suggestion. Not very interested, for a few reasons: (1) It is actively harmful if the aim is to blur the distinction between local branches and remote-tracking branches. New users will be in a lot of hurt if they are not aware that the 'master' branch in their repository is unique and different from the 'master' branch of everybody else's repository and the 'origin' remote repository they cloned from. (2) It is not necessary. You can do interesting things to the history on your local branch, like creating new commits to grow the branch, only after checking it out. And modern Git lets you say $ git checkout topic and it DWIMs the request to "check out the topic branch" to do the equivalent of $ git branch -t topic origin/topic && git checkout topic when 'topic' does not exist as your local branch and there is a single remote (i.e. 'origin') that has a remote-tracking branch of that same name 'topic'. This lets you create a corresponding local branch lazily any time you want to work on extending the work on a branch taken from the remote, and output from "git branch --list" to be meaningful: it only lists your local branch, the ones you have already said that you are interested in working on in this repository. (3) It makes "git branch --list" output less useful if you create local branches that correspond to all the branches taken from the remote. You cannot tell which ones you have worked on and which ones you haven't even touched yet. Having said that, it is fairly trivial to script it, if you really want to do so, ignoring all of the above downsides. Something like: git for-each-ref --format='%(refname)' refs/remotes/origin/ | sed -e 's|^refs/remotes/origin/||' -e '/^HEAD$/d' | while read branchname do git show-ref -q --verify "refs/heads/$branchname" || git branch -t "$branchname" "origin/$branchname" done But for the reasons stated, it is not a particularly good way to work to start from many local branches that are copies of all the remote-tracking branches, many of which you may not even touch, so I personally do not think we would want to add such an option to "clone". The implementation would be fairly trivial, as you can see from the "trivial script" above, but it would encourage a wrong workflow. Older Git around 1.4.x days used to conflate remote-tracking branches and local branches, and threw everything in refs/heads/ hierarchy, which had the exact set of problems above, and that is why modern Git uses refs/remotes/origin/ hierarchy to store the remote-tracking branches separately, for less cluttered local branch namespace. -- To unsubscribe from this list: send the line "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] Cygwin has trustable filemode
On 07/19/2013 12:40 PM, Junio C Hamano wrote: Thanks, will replace. What do we want to do with the compat/regex build-time switch? IIRC, this was only needed for 1.7 and not 1.5, and I also would expect (without anything to back-up, so this is more a faith than expectation) over time the "new library" would have a working regex library. The situation is that Cygwin uses newlib rather than glibc, and does so for licesnsing reasons (redhat sells licenses to developers allowing closed source applications built using Cygwin). So, there must be a compelling need to fix the library - git has a simple work around, so isn't the case. Also, Cygwin has a perl regex library for those demanding more complete / correct regex solution. So, I make no prediction on when the newlib regex functions are fixed. Related: Should we have separate settings for 1.5 and 1.7 for several variables? Conflicts I see not reflected in config.mak.uname on pu: trustable filemode (1.7 has, 1.5 does not) MMAP/Pread (1.7 pread is thread safe, 1.5 I dont think was, MMAP utility is convolved in this) regex - 1.7 is broken, per Ramsay 1.5 works If you think its worth it, I'll create a patch series with the above and justifications for the different settings that I know. Mark -- To unsubscribe from this list: send the line "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] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
The "ret" was meant to mean "the return value we got from the callback function", not "the return value we would give our caller". This rename is a bit misleading in that "cb_bits == -1" does not mean "full bits set", and it does not tell us much what these "bits" signify. They are used to answer this question: which one of the trees in t[0..n] did the callback function consumed (hence needs their pointers updated). So perhaps call it "trees_used" or something? By the way, our log message usually do not Capitalize the subject after the ":", i.e. do something like this instead: Subject: [PATCH 1/3] traverse_trees(): clarify return value of the callback 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] do_one_ref(): save and restore value of current_ref
On 07/17/2013 09:03 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> If do_one_ref() is called recursively, then the inner call should not >> permanently overwrite the value stored in current_ref by the outer >> call. Aside from the tiny optimization loss, peel_ref() expects the >> value of current_ref not to change across a call to peel_entry(). But >> in the presence of replace references that assumption could be >> violated by a recursive call to do_one_ref: >> >> do_for_each_entry() >> do_one_ref() >> builtin/describe.c:get_name() >> peel_ref() >> peel_entry() >> peel_object () >> deref_tag_noverify() >> parse_object() >> lookup_replace_object() >> do_lookup_replace_object() >> prepare_replace_object() >> do_for_each_ref() >> do_for_each_entry() >> do_for_each_entry_in_dir() >> do_one_ref() >> >> The inner call to do_one_ref() was unconditionally setting current_ref >> to NULL when it was done, causing peel_ref() to perform an invalid >> memory access. >> >> So change do_one_ref() to save the old value of current_ref before >> overwriting it, and restore the old value afterward rather than >> setting it to NULL. >> >> Reported by: Mantas Mikulėnas >> >> Signed-off-by: Michael Haggerty >> --- > > Thanks. > > s/Reported by:/Reported-by:/ and lose the extra blank line after it? ACK, sorry I got the notation wrong. > I wonder if we can have an easy reproduction recipe in our tests. I could reproduce the problem by following the recipe provided by Mantas upthread (or at least something very close to it; I can't find the script that I was using): > git pack-refs --all --prune > sed -i '/^[#^]/d' .git/packed-refs > git replace -f HEAD $(git --no-replace-objects cat-file commit HEAD \ > | sed 's/@/@test/' | git hash-object --stdin -t commit -w) > ~/src/git/git describe It would be good to document this in the commit message, but I don't think it is necessary to have a test for it in the test suite because I don't think it is the kind of bug that will reappear. I sent the patch shortly before leaving for a trip so I didn't have time to make it as complete as I would have liked. But given that the problem was already in master, and the fix is pretty simple, I wanted to send the fix right away. When I have some time I can fix it up better, or feel free to manhandle the patch and/or commit message yourself if you prefer. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/19] Index-v5
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> Ah ok, I understand. I think it's best to add a GIT_INDEX_VERSION=x
>> config option to config.mak, where x is the index version that should be
>> tested.
>
> Whatever you do, please do not call it GIT_INDEX_VERSION _if_ it is
> only to be used while testing. Have string "TEST" somewhere in the
> name, and make t/test-lib-functions.sh take notice.
>
> Currently, the way for the user to show the preference as to which
> index version to use is to explicitly set the version once, and then
> we will (try to) propagate it inside the repository.
>
> I would not mind if we add a mechanism to make write_index() notice
> the environment variable GIT_INDEX_VERSION and write the index in
> that version. But that is conceptually very different from whatever
> you give "make VARIABLE=blah" from the command line when building
> Git (or set in config.mak which amounts to the same thing).
What I currently did is add a environment variable GIT_INDEX_VERSION
that is used only if there is no index yet, to make sure existing
repositories aren't affected and still have to be converted explicitly
by using git update-index.
For the tests I simply did export GIT_INDEX_VERSION in test-lib.sh to
allow the addition of GIT_INDEX_VERSION in config.mak. Should I rename
that to GIT_INDEX_VERSION_TEST and do something like
set_index_version() {
export GIT_INDEX_VERSION=$GIT_INDEX_VERSION_TEST
}
in test-lib-functions.sh instead, does that make sense?
--
To unsubscribe from this list: send the line "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] Delete current branch
Junio C Hamano wrote: > That limits the context we could use "-" and we cannot consistently > use it everywhere. I find _that_ ugly from the "design cleanliness" > point of view. Right, noted. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] l10n: de.po: switch from pure German to German+English (part 1)
Am 17. Juli 2013 18:24 schrieb Ralf Thielow : > This switches the translation from pure German to German+English. > > Signed-off-by: Ralf Thielow > --- > po/de.po | 568 > +++ > 1 file changed, 284 insertions(+), 284 deletions(-) > [...] > #: remote.c:1787 > msgid " (use \"git push\" to publish your local commits)\n" > -msgstr " (benutzen Sie \"git push\" um lokalen Versionen herauszubringen)\n" > +msgstr " (benutzen Sie \"git push\" um lokale Commits herauszubringen)\n" > I just saw that I didn't change the translation of "publish" from "herausbringen" to "publizieren" as Thomas suggested. I don't think it's worth it to send a v4 for this small change. I'll change it to: msgid " (use \"git push\" to publish your local commits)\n" -msgstr " (benutzen Sie \"git push\" um lokalen Versionen herauszubringen)\n" +msgstr " (benutzen Sie \"git push\" um lokale Commits zu publizieren)\n" > -- > 1.8.2.1230.g519726a > -- To unsubscribe from this list: send the line "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] Delete current branch
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Did you know that the general way to spell the branch previously you
>> were on is "@{-1}" and "checkout -" is an ugly special case that is
>> possible only because "checkout" does not happen to take a "-" as a
>> valid argument that means something else (like the more usual "read
>> from standard input")?
>
> I disagree that it is ugly: it's a very commonly used shortcut that I
> like.
It does not matter if you like it or not ;-).
I do agree that "checkout -" is 100% more pleasing to the eye than
"checkout @{-1}" from visual "prettyness" point of view.
But there is a very commonly accepted long tradition for "-" to mean
"read from the standard input", so we cannot reuse it to mean "the
branch I was previously on" for every command without first making
sure the command will never want to use "-" for the other common
purpose.
That limits the context we could use "-" and we cannot consistently
use it everywhere. I find _that_ ugly from the "design cleanliness"
point of view.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation, git reset: fix typo.
Stefan Beller wrote: > --- a/Documentation/git-reset.txt > +++ b/Documentation/git-reset.txt > @@ -9,7 +9,7 @@ SYNOPSIS > > [verse] > 'git reset' [-q] [] [--] ... > -'git reset' (--patch | -p) [] [--] [...] > +'git reset' (--patch | -p) [] [--] [...] > 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [] Sure. Though these days it might make more sense to say 'git reset' [--soft | --mixed | --hard | --merge | --keep] [--] 'git reset' [] [--] ... 'git reset' (--patch | -p) [] [--] [...] since commands accept a commit or tag where a tree is expected pretty much universally. 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: [RFC] Delete current branch
Junio C Hamano, Fri 2013-07-19 @ 09:48:06-0700: > But there is a very commonly accepted long tradition for "-" to mean > "read from the standard input", so we cannot reuse it to mean "the > branch I was previously on" for every command without first making > sure the command will never want to use "-" for the other common > purpose. It may be worth noting that Bash (and probably other shells as well) allow you to type `cd -` to switch back to the previous working directory. I always (apparently mistakenly) assumed that `git checkout -` was deliberately designed to mirror that shortcut. I think the symmetry gives it some credibility, in any case. This alternative meaning for - is not totally without precedent. What would it mean to check out the standard input, anyway? I cannot see how that could ever make sense, unless `git checkout` gains some additional capaabilities that are unrelated to its current purpose. Maybe I am just being myopic, though. signature.asc Description: Digital signature
Re: [PATCH] Cygwin has trustable filemode
Mark Levedahl writes: > Junio - The above notes are more accurate than in my previous commit message, > so if this commit survives into next/master, I would prefer this version as > opposed to the one now on pu (da875762) Thanks, will replace. What do we want to do with the compat/regex build-time switch? IIRC, this was only needed for 1.7 and not 1.5, and I also would expect (without anything to back-up, so this is more a faith than expectation) over time the "new library" would have a working regex library. > > Mark > > config.mak.uname | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/config.mak.uname b/config.mak.uname > index 174703b..bf5db47 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -164,7 +164,6 @@ ifeq ($(uname_O),Cygwin) > NO_THREAD_SAFE_PREAD = YesPlease > NEEDS_LIBICONV = YesPlease > NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes > - NO_TRUSTABLE_FILEMODE = UnfortunatelyYes > NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease > # There are conflicting reports about this. > # On some boxes NO_MMAP is needed, and not so elsewhere. -- To unsubscribe from this list: send the line "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 Clone Parameter
Junio C Hamano wrote: > git branch -t "$branchname" "origin/$branchname" A couple of notes here: 1. I use git branch -u personally. Why the -t variant? 2. Don't we auto-track? (or is that only on checkout) -- To unsubscribe from this list: send the line "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 Clone Parameter
Junio C Hamano wrote: > You would at least need "xargs -n 1" for the produced command line > to make any sense, and it is wasteful to actually check out each > and every branch to the working tree only to create it. Right. xargs -n 1, git branch, and refname:short. -- To unsubscribe from this list: send the line "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] Delete current branch
Junio C Hamano wrote:
> Did you know that the general way to spell the branch previously you
> were on is "@{-1}" and "checkout -" is an ugly special case that is
> possible only because "checkout" does not happen to take a "-" as a
> valid argument that means something else (like the more usual "read
> from standard input")?
I disagree that it is ugly: it's a very commonly used shortcut that I
like. I love it so much that I have the following in my ~/.zshrc:
function - () {
if test "true" = "$(g rp --is-inside-work-tree 2>/dev/null)"; then
g co -
else
cd - >/dev/null
fi
}
So, I just
$ -
to switch back and forth :)
--
To unsubscribe from this list: send the line "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] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine writes: >> +When `git pull` that does not explicitly specify what branch from >> +which repository is to be integrated with your history on the >> +command line, recent Git will refuse to work until you specify how >> +that integration should happen, either with a command line option >> +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` >> +or `branch..rebase`, which is the same as `--merge` >> +(`--rebase`) when set to `false` (`true`) respectively. > > This paragraph-long single sentence may be intimidating. Perhaps some > simplification is possible: > > As a safety measure, bare `git pull` (without repository or > branch) needs to be told how to integrate pulled changes with > your history; either via `--merge` or `--rebase`. Also see > configuration variables `pull.rebase` and `branch..rebase` > in linkgit:git-config[1]. > > I intentionally omitted the true/false explanation of the > configuration variables since the user can follow the link and read > about them. It also may make sense to drop mention of those variables > altogether since they are already described (including link) in the > description of --rebase. > > I also intentionally omitted "recent Git" since it's rather nebulous. Looks much better than the original. I would further suggest dropping the "As a safety measure, bare " at the beginning. `git pull` (without repository or branch on the command line) needs to be told how to integrate the changes with your history via either `--merge` or `--rebase` (see configuration variables `pull.rebase` and `branch..rebase` in linkgit:git-config[1]). perhaps? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation, git reset: fix typo.
Reported-By: Ibrahim M. Ghazal Signed-off-by: Stefan Beller --- Documentation/git-reset.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index a404b47..f445cb3 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git reset' [-q] [] [--] ... -'git reset' (--patch | -p) [] [--] [...] +'git reset' (--patch | -p) [] [--] [...] 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [] DESCRIPTION -- 1.8.3.3.754.g9c3c367.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jul 2013, #03; Tue, 9)
Ramsay Jones writes: > Junio C Hamano wrote: > [ ... ] >> * rr/send-email-ssl-verify (2013-07-06) 6 commits >> - SQUASH??? update to support SSL_ca_file as well as SSL_ca_path >> - SQUASH??? send-email: cover both smtps and starttls cases >> - fixup! send-email: squelch warning from Net::SMTP::SSL >> - SQUASH??? send-email giving default value to ssl-cert-path with ||= >> assignment >> - send-email: introduce sendemail.smtpsslcertpath >> - send-email: squelch warning from Net::SMTP::SSL >> >> The issue seems a lot deeper than the initial attempt and needs >> somebody to sit down and sort out to get the version dependencies >> and lazy loading right. > > This causes test failures for me, since send-email can't load the > IO/Socket/SSL.pm module. (on Linux, cygwin and MinGW!) Good ;-). Can you try the more recent 'pu' with 35035bbf (send-email: be explicit with SSL certificate verification, 2013-07-18) that was updated with help from Brian Carlson? > [ ... ] > >> -- >> [Stalled] >> >> * rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits >> - ### DONTMERGE: needs better explanation on what config they need >> - pack-refs.c: Add missing call to git_config() >> - show-ref.c: Add missing call to git_config() >> >> The changes themselves are probably good, but it is unclear what >> basic setting needs to be read for which exact operation. >> >> Waiting for clarification. >> $gmane/228294 > > Sorry, still on my TODO list. (Having said that, I'm no longer sure > that these patches do the right thing! ;-) > > ATB, > Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Typo in git-reset man page.
On this line: https://git.kernel.org/cgit/git/git.git/tree/Documentation/git-reset.txt#n12 "tree-sh" should be "tree-ish". -- To unsubscribe from this list: send the line "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] status_printf_ln: Suppress false positive warnings of empty format string.
Stefan Beller writes:
> This is a response to 8dd0ee823f1829a3aa228c3c73e31de5c89b5317.
>
> Instead of having an empty string as format for the printf like function
> status_printf_ln, we could insert an empty string into the format
> parameter.
>
> A similar fixup commit is found in linux (2e4c332913b5), but there
> the empty string is replaced by a string containing one whitespace.
>
> To determine, which approach is better I setup 2 test programs, which
> either have a whitespace format (" ") or the empty string ("%s", ""),
> looking like:
> -
> #include
> #include
> int main (int argc, char** argv) {
> long i;
> for (i = 0; i < 1024*1024*1024; ++i)
> printf(" ");
> }
> -
> Checking the required time of the programs, while redirecting the actual
> output (the billion white spaces compared to nothing) to /dev/null
> indicates that the approach used in this patch is faster regardless
> of the optimization level of gcc.
>
> Also this patch doesn't change output, which favors this approach over
> the whitespace approach.
Even if the " " variant is faster, it does not matter if its output
is incorrect ;-)
> The only thing left to discuss, whether this patch is worth it, as it
> only suppresses false positive warnings from gcc, but makes the
> code slightly harder to read.
I think we discussed this already? The conclusion was it is silly
for GCC to warn on -Wformat-zero-length for user-defined function in
the first place, IIRC. func(other, args, fmt,...), when invoked as
func(other, args, ""), may very well do something useful regardless
of the formatting part based on other args.
For that matter, I personally think -Wformat-zero-length warning for
standard ones, like
printf("");
is silly, too. It is not like
printf("", extra, arg);
is not caught as an error.
So we can just add -Wno-format-zero-length after -Wall and be done
with it?
>
> Signed-off-by: Stefan Beller
> ---
> builtin/commit.c | 2 +-
> wt-status.c | 18 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 65cf2a7..34bc274 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -773,7 +773,7 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> committer_ident.buf);
>
> if (ident_shown)
> - status_printf_ln(s, GIT_COLOR_NORMAL, "");
> + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", "");
>
> saved_color_setting = s->use_color;
> s->use_color = 0;
> diff --git a/wt-status.c b/wt-status.c
> index cb24f1f..912ed88 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -179,7 +179,7 @@ static void wt_status_print_unmerged_header(struct
> wt_status *s)
> } else {
> status_printf_ln(s, c, _(" (use \"git add/rm ...\" as
> appropriate to mark resolution)"));
> }
> - status_printf_ln(s, c, "");
> + status_printf_ln(s, c, "%s", "");
> }
>
> static void wt_status_print_cached_header(struct wt_status *s)
> @@ -195,7 +195,7 @@ static void wt_status_print_cached_header(struct
> wt_status *s)
> status_printf_ln(s, c, _(" (use \"git reset %s ...\" to
> unstage)"), s->reference);
> else
> status_printf_ln(s, c, _(" (use \"git rm --cached ...\"
> to unstage)"));
> - status_printf_ln(s, c, "");
> + status_printf_ln(s, c, "%s", "");
> }
>
> static void wt_status_print_dirty_header(struct wt_status *s,
> @@ -214,7 +214,7 @@ static void wt_status_print_dirty_header(struct wt_status
> *s,
> status_printf_ln(s, c, _(" (use \"git checkout -- ...\" to
> discard changes in working directory)"));
> if (has_dirty_submodules)
> status_printf_ln(s, c, _(" (commit or discard the untracked or
> modified content in submodules)"));
> - status_printf_ln(s, c, "");
> + status_printf_ln(s, c, "%s", "");
> }
>
> static void wt_status_print_other_header(struct wt_status *s,
> @@ -226,12 +226,12 @@ static void wt_status_print_other_header(struct
> wt_status *s,
> if (!advice_status_hints)
> return;
> status_printf_ln(s, c, _(" (use \"git %s ...\" to include in
> what will be committed)"), how);
> - status_printf_ln(s, c, "");
> + status_printf_ln(s, c, "%s", "");
> }
>
> static void wt_status_print_trailer(struct wt_status *s)
> {
> - status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
> + status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
> }
>
> #define quote_path quote_path_relative
> @@ -1192,7 +1192,7 @@ void wt_status_print(struct wt_status *s)
> on_what = _("Not currently on any branch.");
> }
> }
> - status_printf(s, color(WT_STATUS_HEADER, s), "");
> + status_pri
Re: [PATCH] status_printf_ln: Suppress false positive warnings of empty format string.
> > Even if the " " variant is faster, it does not matter if its output > is incorrect ;-) Agreed. > I think we discussed this already? The conclusion was it is silly > for GCC to warn on -Wformat-zero-length for user-defined function in > the first place, IIRC. func(other, args, fmt,...), when invoked as > func(other, args, ""), may very well do something useful regardless > of the formatting part based on other args. > I am sorry, I did not pay attention enough to that specific topic. I was just finding warnings on next and pu, so I wondered how to fix it. signature.asc Description: OpenPGP digital signature
Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions
On 07/18/2013 07:32 PM, Junio C Hamano wrote: Mark Levedahl writes: Unlike the results on the fast Win7 laptop, the above show statistically significant slow down from the fast_lstat approach. I'm just not seeing a case for the special case handling, and of course Junio has already voted with his preference of removing the special case stuff as well. Please don't take what I said as any "vote" in this thread. I do not have a first-hand data to back anything up. I was primarily trying to see my understanding of the consensus of the thread was correct. If we can do without s/lstat/fast_lstat/ almost everywhere in the codebase, of course, I would be happier, as it would give us one less thing to worry about. If the assumptions like "they were declining minority and only lose population over time", "it is easy for them to revert the removal and keep going", and "removal will not hurt them too much in the first place, only a few hundred milliseconds", that might trump the longer-term maintainability issue, and we may end up having to carry that win32 stat implementation a bit longer until these users all switch to Cygwin 1.7, but judging from the "cvs binary seems to be built incorrectly" incident the other day, it might be the case some users still hesitate to update, fearing that 1.7 series may not be solid enough, perhaps? I cannot say how many users of 1.5 exist. I see no evidence of 1.5 users on the Cygwin lists, the developers noted a total of 14 downloads of the 1.5 installer in the year prior to removal of 1.5 from the mirrors. The stated reason for keeping 1.5 available for four years after its development stopped was support of older Windows variants (which Microsoft dropped support of before Cygwin did, BTW). But, none of this is conclusive about the current relevance of v 1.5. The status as I understand things: 1) The existing schizophrenic stat on master is incompatible with the new reference api on pu, therefore some change is required. 2) Ramsay has graciously provided two separate patches to address the above, one reverting to use only of cygwin stat/lstat, one including a fast_lstat that should provide better speed at the expense of POSIX compliance. 3) We have conflicting reports about the speed of the second patch: Ramsay shows a good speed up on Cygwin 1.5, with slight performance regrets on MINGW, no change on Linux. I found no effect on a current bare-metal Window 7 installation using Cygwin 1.7, but degradation on a virtualized WinXP installation using Cygwin 1.7. Ramsay also showed a significant performance difference between running from the git tree vs being installed, I looked for this effect but failed to replicate it. The maintenance argument between the two patches is clear, the performance argument less so. Perhaps others can help clarify this. Mark -- To unsubscribe from this list: send the line "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 Clone Parameter
Allan Acheampong writes: > ... I'm new to git, but I found it very > confusing to understand the difference between "remote" , > "remotes". Is it in the cloned repo, or is it in a remote place? > If its local, why doesn't it get shown when I do 'git branch' but > when I do 'git branch -a'. > ... > For example, I create a project locally > with multiple branches, push it, delete it locally and clone it > back to my machine. On a 'git branch' I would only see the head > branch. > ... > I'd like to know your opinions about that and what you think about > the suggestion. Not very interested, for a few reasons: (1) It is actively harmful if the aim is to blur the distinction between local branches and remote-tracking branches. New users will be in a lot of hurt if they are not aware that the 'master' branch in their repository is unique and different from the 'master' branch of everybody else's repository and the 'origin' remote repository they cloned from. (2) It is not necessary. You can do interesting things to the history on your local branch, like creating new commits to grow the branch, only after checking it out. And modern Git lets you say $ git checkout topic and it DWIMs the request to "check out the topic branch" to do the equivalent of $ git branch -t topic origin/topic && git checkout topic when 'topic' does not exist as your local branch and there is a single remote (i.e. 'origin') that has a remote-tracking branch of that same name 'topic'. This lets you create a corresponding local branch lazily any time you want to work on extending the work on a branch taken from the remote, and output from "git branch --list" to be meaningful: it only lists your local branch, the ones you have already said that you are interested in working on in this repository. (3) It makes "git branch --list" output less useful if you create local branches that correspond to all the branches taken from the remote. You cannot tell which ones you have worked on and which ones you haven't even touched yet. Having said that, it is fairly trivial to script it, if you really want to do so, ignoring all of the above downsides. Something like: git for-each-ref --format='%(refname)' refs/remotes/origin/ | sed -e 's|^refs/remotes/origin/||' -e '/^HEAD$/d' | while read branchname do git show-ref -q --verify "refs/heads/$branchname" || git branch -t "$branchname" "origin/$branchname" done But for the reasons stated, it is not a particularly good way to work to start from many local branches that are copies of all the remote-tracking branches, many of which you may not even touch, so I personally do not think we would want to add such an option to "clone". The implementation would be fairly trivial, as you can see from the "trivial script" above, but it would encourage a wrong workflow. Older Git around 1.4.x days used to conflate remote-tracking branches and local branches, and threw everything in refs/heads/ hierarchy, which had the exact set of problems above, and that is why modern Git uses refs/remotes/origin/ hierarchy to store the remote-tracking branches separately, for less cluttered local branch namespace. -- To unsubscribe from this list: send the line "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 Clone Parameter
Johannes Sixt writes: > Am 7/19/2013 11:21, schrieb Allan Acheampong: >> Something like 'git clone -createLocalBranchesForAllBranches' > > Perhaps: > > $ git clone theRepo > $ git fetch origin refs/heads/*:refs/heads/* > > (untested). There may be ways to write the same shorter, but I've lost > track of what is and what is not possible in refspec. That would overwrite your local branch and would not give you any tracking, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Cygwin has trustable filemode
The supported Cygwin distribution on supported Windows versions provides complete support for POSIX filemodes, so enable this by default. git as distributed by the Cygwin project is configured this way. This fixes one testsuite failure: t3300 test 17 (diff-index -M -p with mode change quotes funny filename) Historical notes: Cygwin version 1.7 supports Windows-XP and newer, thus dropped support for all OS variants that lack NTFS and/or the full win32 api, and since late 1.5 development, Cygwin maps POSIX modes to NTFS ACLs by default. Cygwin 1.5 supported OS variants that used FAT as the native file system, and had optional methods for providing POSIX file modes on top of FAT12/16 and NTFS, though not FAT32. Also, support for POSIX modes on top of FAT were dropped later in 1.5. Thus, POSIX filemode support could not be expected by default on a Cygwin 1.5 installation, but is expected by default on a 1.7 installation. Signed-off-by: Mark Levedahl --- Junio - The above notes are more accurate than in my previous commit message, so if this commit survives into next/master, I would prefer this version as opposed to the one now on pu (da875762) Mark config.mak.uname | 1 - 1 file changed, 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index 174703b..bf5db47 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -164,7 +164,6 @@ ifeq ($(uname_O),Cygwin) NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes - NO_TRUSTABLE_FILEMODE = UnfortunatelyYes NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease # There are conflicting reports about this. # On some boxes NO_MMAP is needed, and not so elsewhere. -- 1.8.3.2.0.13 -- To unsubscribe from this list: send the line "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 Clone Parameter
Ramkumar Ramachandra writes: > Allan Acheampong wrote: >> I could write a script with for each in but thats way too much hassle > > $ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed > 's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b > > (completely untested ofcourse) You would at least need "xargs -n 1" for the produced command line to make any sense, and it is wasteful to actually check out each and every branch to the working tree only to create 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 v2 03/19] read-cache: move index v2 specific functions to their own file
Duy Nguyen writes: > On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer > wrote: >> @@ -489,8 +479,8 @@ extern void *read_blob_data_from_index(struct >> index_state *, const char *, unsig >> #define CE_MATCH_RACY_IS_DIRTY 02 >> /* do stat comparison even if CE_SKIP_WORKTREE is true */ >> #define CE_MATCH_IGNORE_SKIP_WORKTREE 04 >> -extern int ie_match_stat(const struct index_state *, const struct >> cache_entry *, struct stat *, unsigned int); >> -extern int ie_modified(const struct index_state *, const struct cache_entry >> *, struct stat *, unsigned int); >> +extern int ie_match_stat(struct index_state *, const struct cache_entry *, >> struct stat *, unsigned int); >> +extern int ie_modified(struct index_state *, const struct cache_entry *, >> struct stat *, unsigned int); >> > > I would rather we keep "const struct index_state*" if we could. I > tried putting "const" back and found that ce_match_stat_basic() calls > set_istate_ops(), which writes to "struct index_state". Putting > set_istate_ops() in ce_match_stat_basic() may seem convenient, but > does not make much sense (why would a match_stat function update > index_ops?). I think you could move it out and > > - read_index calls set_istate_ops > - (bonus) discard_index probably should reset "version" field to zero > and clear internal_ops > - the callers that use index without read_index must call > initialize_index() or something, which in turn calls set_istate_ops. > initialize_index() may take the preferred index version > - do not let update-index modifies version field directly when > --index-version is given. Wrap it with set_index_version() or > something, so we can do internal conversion from one version to > another if needed > - remove set_istate_ops in write_index(), we may need internal_ops > long before writing. When write_index is called, internal_ops should > be already initialized Ok, this makes sense. The only thing that I'm a little worried about is catching all code paths that need to initialize the index. I'll implement these suggestions in the re-roll. -- To unsubscribe from this list: send the line "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] Delete current branch
Ramkumar Ramachandra writes:
> Many of my ideas turn out to be really stupid, and I need to throw
> away my feature branch. So, I find myself doing this often:
>
> # on branch menuconfig-jk
> $ git checkout master
> $ git branch -D
> # er, what was the branch name again?
> $ git checkout -
> # Ah
> $ git checkout master
> $ git branch -D menuconfig-jk
>
> So, I scripted it for myself. Perhaps we should get the functionality
> in core as `git branch -Dc` (c for "current"; or something)?
What branch will I be on after doing that? Detached at that branch?
> Also, perhaps a `git describe -` corresponding to `git checkout -`
Did you know that the general way to spell the branch previously you
were on is "@{-1}" and "checkout -" is an ugly special case that is
possible only because "checkout" does not happen to take a "-" as a
valid argument that means something else (like the more usual "read
from standard input")?
Perhaps
$ git branch -D @{-1}
would have worked without and everything that follows.
--
To unsubscribe from this list: send the line "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] Delete current branch
Ramkumar Ramachandra writes: > # er, what was the branch name again? > $ git checkout - You could take a look in the reflog. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation/git-checkout.txt: Inconsistent naming of paths arguments
Duy Nguyen writes: > On Fri, Jul 19, 2013 at 2:16 PM, Adam Brengesjö > wrote: >> From SYNOPSIS: >> >> git checkout [-p|--patch] [] [--] […] >> >> >> From DESCRIPTION >> >> git checkout [-p|--patch] [] [--] … >> >> >> >> 1. Named in SYNOPSIS, but in DESCRIPTION. (It's >> referred to as in the body text). >> >> 2. is marked as optional in SYNOPSIS, but is not. >> >> I'm not submitting a patch now, as I'm not sure which is correct. > > If I'm not mistaken, "git checkout" takes pathspec in all cases. Correct. And I think -p form (which I do not use myself so please double check) can be run with an empty pathspec. It looks somewhat idiotic that git checkout master git checout -p next will finish on the 'master' branch, with random selected bits of differences for 'master' to go to 'next' applied to the index and the working tree, but that seems to be how it works. -- To unsubscribe from this list: send the line "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] Delete current branch
Andreas Schwab wrote:
> Ramkumar Ramachandra writes:
>
>> # er, what was the branch name again?
>> $ git checkout -
>
> You could take a look in the reflog.
Yeah, or use the @{-N} revision to do that for me. My scripted
version is essentially:
test "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" || exit 1
git checkout master
git branch -D @{-1}
The main problem is the hard-coding of "master": I suppose I could
replace that with @{-1} too.
Not a big deal: I was just wondering if others use it often enough for
it to become `branch -Dc` in core; @{-N} is quite obscure.
--
To unsubscribe from this list: send the line "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] status_printf_ln: Suppress false positive warnings of empty format string.
This is a response to 8dd0ee823f1829a3aa228c3c73e31de5c89b5317.
Instead of having an empty string as format for the printf like function
status_printf_ln, we could insert an empty string into the format
parameter.
A similar fixup commit is found in linux (2e4c332913b5), but there
the empty string is replaced by a string containing one whitespace.
To determine, which approach is better I setup 2 test programs, which
either have a whitespace format (" ") or the empty string ("%s", ""),
looking like:
-
#include
#include
int main (int argc, char** argv) {
long i;
for (i = 0; i < 1024*1024*1024; ++i)
printf(" ");
}
-
Checking the required time of the programs, while redirecting the actual
output (the billion white spaces compared to nothing) to /dev/null
indicates that the approach used in this patch is faster regardless
of the optimization level of gcc.
Also this patch doesn't change output, which favors this approach over
the whitespace approach.
The only thing left to discuss, whether this patch is worth it, as it
only suppresses false positive warnings from gcc, but makes the
code slightly harder to read.
Signed-off-by: Stefan Beller
---
builtin/commit.c | 2 +-
wt-status.c | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 65cf2a7..34bc274 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -773,7 +773,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
committer_ident.buf);
if (ident_shown)
- status_printf_ln(s, GIT_COLOR_NORMAL, "");
+ status_printf_ln(s, GIT_COLOR_NORMAL, "%s", "");
saved_color_setting = s->use_color;
s->use_color = 0;
diff --git a/wt-status.c b/wt-status.c
index cb24f1f..912ed88 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -179,7 +179,7 @@ static void wt_status_print_unmerged_header(struct
wt_status *s)
} else {
status_printf_ln(s, c, _(" (use \"git add/rm ...\" as
appropriate to mark resolution)"));
}
- status_printf_ln(s, c, "");
+ status_printf_ln(s, c, "%s", "");
}
static void wt_status_print_cached_header(struct wt_status *s)
@@ -195,7 +195,7 @@ static void wt_status_print_cached_header(struct wt_status
*s)
status_printf_ln(s, c, _(" (use \"git reset %s ...\" to
unstage)"), s->reference);
else
status_printf_ln(s, c, _(" (use \"git rm --cached ...\"
to unstage)"));
- status_printf_ln(s, c, "");
+ status_printf_ln(s, c, "%s", "");
}
static void wt_status_print_dirty_header(struct wt_status *s,
@@ -214,7 +214,7 @@ static void wt_status_print_dirty_header(struct wt_status
*s,
status_printf_ln(s, c, _(" (use \"git checkout -- ...\" to
discard changes in working directory)"));
if (has_dirty_submodules)
status_printf_ln(s, c, _(" (commit or discard the untracked or
modified content in submodules)"));
- status_printf_ln(s, c, "");
+ status_printf_ln(s, c, "%s", "");
}
static void wt_status_print_other_header(struct wt_status *s,
@@ -226,12 +226,12 @@ static void wt_status_print_other_header(struct wt_status
*s,
if (!advice_status_hints)
return;
status_printf_ln(s, c, _(" (use \"git %s ...\" to include in
what will be committed)"), how);
- status_printf_ln(s, c, "");
+ status_printf_ln(s, c, "%s", "");
}
static void wt_status_print_trailer(struct wt_status *s)
{
- status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
}
#define quote_path quote_path_relative
@@ -1192,7 +1192,7 @@ void wt_status_print(struct wt_status *s)
on_what = _("Not currently on any branch.");
}
}
- status_printf(s, color(WT_STATUS_HEADER, s), "");
+ status_printf(s, color(WT_STATUS_HEADER, s), "%s", "");
status_printf_more(s, branch_status_color, "%s", on_what);
status_printf_more(s, branch_color, "%s\n", branch_name);
if (!s->is_initial)
@@ -1205,9 +1205,9 @@ void wt_status_print(struct wt_status *s)
free(state.detached_from);
if (s->is_initial) {
- status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial
commit"));
- status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
}
wt_status_print_updated(s);
@@ -1224,7 +1224,7 @@ void wt_status_print(struct wt_status *s)
Re: Git Clone Parameter
Am 7/19/2013 11:21, schrieb Allan Acheampong: > Something like 'git clone -createLocalBranchesForAllBranches' Perhaps: $ git clone theRepo $ git fetch origin refs/heads/*:refs/heads/* (untested). There may be ways to write the same shorter, but I've lost track of what is and what is not possible in refspec. -- Hannes -- To unsubscribe from this list: send the line "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 v6 3/4] tests: add new test for the url_normalize function
In order to perform sane URL matching for http..* options, http.c normalizes URLs before performing matches. A new test-url-normalize test program is introduced along with a new t5200-url-normalize.sh script to run the tests. Since the url_normalize function currently lives in http.c this test will be skipped if NO_CURL is defined since http.c is skipped in that case. Signed-off-by: Kyle J. McKay --- .gitignore | 1 + Makefile | 5 ++ t/t5200-url-normalize.sh | 161 +++ test-url-normalize.c | 61 ++ 4 files changed, 228 insertions(+) create mode 100755 t/t5200-url-normalize.sh create mode 100644 test-url-normalize.c diff --git a/.gitignore b/.gitignore index 6669bf0..cd97e16 100644 --- a/.gitignore +++ b/.gitignore @@ -198,6 +198,7 @@ /test-string-list /test-subprocess /test-svn-fe +/test-url-normalize /test-wildmatch /common-cmds.h *.tar.gz diff --git a/Makefile b/Makefile index 0f931a2..f83879c 100644 --- a/Makefile +++ b/Makefile @@ -567,6 +567,7 @@ TEST_PROGRAMS_NEED_X += test-sigchain TEST_PROGRAMS_NEED_X += test-string-list TEST_PROGRAMS_NEED_X += test-subprocess TEST_PROGRAMS_NEED_X += test-svn-fe +TEST_PROGRAMS_NEED_X += test-url-normalize TEST_PROGRAMS_NEED_X += test-wildmatch TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X)) @@ -2235,6 +2236,10 @@ test-parse-options$X: parse-options.o parse-options-cb.o test-svn-fe$X: vcs-svn/lib.a +test-url-normalize$X: test-url-normalize.o GIT-LDFLAGS $(GITLIBS) + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ + $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) + .PRECIOUS: $(TEST_OBJS) test-%$X: test-%.o GIT-LDFLAGS $(GITLIBS) diff --git a/t/t5200-url-normalize.sh b/t/t5200-url-normalize.sh new file mode 100755 index 000..82d78ce --- /dev/null +++ b/t/t5200-url-normalize.sh @@ -0,0 +1,161 @@ +#!/bin/sh + +test_description='url normalization' +. ./test-lib.sh + +if test -n "$NO_CURL"; then + skip_all='skipping test, git built without http support' + test_done +fi + +# Note that only file: URLs should be allowed without a host + +test_expect_success 'url scheme' ' + ! test-url-normalize "" && + ! test-url-normalize "_" && + ! test-url-normalize "scheme" && + ! test-url-normalize "scheme:" && + ! test-url-normalize "scheme:/" && + ! test-url-normalize "scheme://" && + ! test-url-normalize "file" && + ! test-url-normalize "file:" && + ! test-url-normalize "file:/" && + test-url-normalize "file://" && + ! test-url-normalize "://acme.co" && + ! test-url-normalize "x_test://acme.co" && + ! test-url-normalize "schem%6e://" && + test-url-normalize "x-Test+v1.0://acme.co" && + test "$(test-url-normalize -p "AbCdeF://x.Y")" = "abcdef://x.y/" +' + +test_expect_success 'url authority' ' + ! test-url-normalize "scheme://user:pass@" && + ! test-url-normalize "scheme://?" && + ! test-url-normalize "scheme://#" && + ! test-url-normalize "scheme:///" && + ! test-url-normalize "scheme://:" && + ! test-url-normalize "scheme://:555" && + test-url-normalize "file://user:pass@" && + test-url-normalize "file://?" && + test-url-normalize "file://#" && + test-url-normalize "file:///" && + test-url-normalize "file://:" && + ! test-url-normalize "file://:555" && + test-url-normalize "scheme://user:pass@host" && + test-url-normalize "scheme://@host" && + test-url-normalize "scheme://%00@host" && + ! test-url-normalize "scheme://%%@host" && + ! test-url-normalize "scheme://host_" && + test-url-normalize "scheme://user:pass@host/" && + test-url-normalize "scheme://@host/" && + test-url-normalize "scheme://host/" && + test-url-normalize "scheme://host?x" && + test-url-normalize "scheme://host#x" && + test-url-normalize "scheme://host/@" && + test-url-normalize "scheme://host?@x" && + test-url-normalize "scheme://host#@x" && + test-url-normalize "scheme://[::1]" && + test-url-normalize "scheme://[::1]/" && + ! test-url-normalize "scheme://hos%41/" && + test-url-normalize "scheme://[invalid:/" && + test-url-normalize "scheme://invalid:]/" && + ! test-url-normalize "scheme://invalid:[/" && + ! test-url-normalize "scheme://invalid:[" +' + +test_expect_success 'url port checks' ' + test-url-normalize "xyz://q...@some.host:" && + test-url-normalize "xyz://q...@some.host:456/" && + ! test-url-normalize "xyz://q...@some.host:0" && + ! test-url-normalize "xyz://q...@some.host:000" && + test-url-normalize "xyz://q...@some.host:001?" && + test-url-normalize "xyz://q...@some.host:065535#" && + test-url-normalize "xyz://q...@some.host:65535" && + ! test-url-normalize "x
[PATCH v6 2/4] config: improve support for http..* settings
Improve on the http..* url matching behavior by first
normalizing the urls before they are compared.
With this change, for example, the following configuration
section:
[http "https://example.com/path";]
useragent = example-agent
sslVerify = false
will properly match a "HTTPS://example.COM/p%61th" url which
is equivalent.
The normalization rules are based on RFC 3986 and should
result in any two equivalent urls being a match.
Signed-off-by: Kyle J. McKay
---
Documentation/config.txt | 19 ++-
http.c | 322 ++-
2 files changed, 329 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 41cab91..e461f32 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1517,16 +1517,15 @@ http..*::
Any of the http.* options above can be applied selectively to some urls.
For example "http.https://example.com.useragent"; would set the user
agent only for https connections to example.com. The value
- matches a url if it is an exact match or a prefix of the url matching
- at a "/" boundary. Longer matches take precedence over shorter
- ones with the environment variable settings taking precedence over all.
- Note that must match the url passed to git exactly (other than
- possibly being a prefix). This means any user, password and/or port
- setting that appears in a url as well as any %XX escapes that are
- present must also appear in to have a successful match. The urls
- that are matched against are those given directly to git commands. In
- other words, use exactly the same url that was passed to git (possibly
- shortened) for the value of the config setting.
+ matches a url if it is an exact match or if it is a prefix of the url
+ matching at a "/" boundary. Longer matches take precedence over
+ shorter ones with the environment variable settings taking precedence
+ over all. The urls are normalized before testing for a match. Note,
+ however, that any user, password and/or port setting that appears in a
+ url must also match that part of to have a successful match. The
+ urls that are matched against are those given directly to git commands.
+ This means any urls visited as a result of a redirection do not
+ participate in matching.
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
diff --git a/http.c b/http.c
index f61a79c..3c5c2ef 100644
--- a/http.c
+++ b/http.c
@@ -169,6 +169,311 @@ static void process_curl_messages(void)
}
#endif
+#define URL_ALPHA "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+#define URL_DIGIT "0123456789"
+#define URL_HEXDIGIT URL_DIGIT "ABCDEFabcdef"
+#define URL_ALPHADIGIT URL_ALPHA URL_DIGIT
+#define URL_SCHEME_CHARS URL_ALPHADIGIT "+.-"
+#define URL_HOST_CHARS URL_ALPHADIGIT ".-[:]" /* IPv6 literals need [:] */
+#define URL_UNSAFE_CHARS " <>\"%{}|\\^`" /* plus 0x00-0x1F,0x7F-0xFF */
+#define URL_GEN_RESERVED ":/?#[]@"
+#define URL_SUB_RESERVED "!$&'()*+,;="
+#define URL_RESERVED URL_GEN_RESERVED URL_SUB_RESERVED /* only allowed delims
*/
+
+static int hex_digit_value(int ch)
+{
+ /*
+* Returns the hexadecimal digit value (0x00..0x0F) of character ch.
+* If ch is not a hexadecimal digit, the return value is undefined.
+*/
+
+ if ('0' <= ch && ch <= '9')
+ return ch - '0';
+ return toupper(ch) - 'A' + 10;
+}
+
+static int append_normalized_escapes(struct strbuf *buf,
+const char *from,
+size_t from_len,
+const char *esc_extra,
+const char *esc_ok)
+{
+ /*
+* Append to strbuf 'buf' characters from string 'from' with length
+* 'from_len' while unescaping characters that do not need to be escaped
+* and escaping characters that do. The set of characters to escape
+* (the complement of which is unescaped) starts out as the RFC 3986
+* unsafe characters (0x00-0x1F,0x7F-0xFF," <>\"#%{}|\\^`"). If
+* 'esc_extra' is not NULL, those additional characters will also always
+* be escaped. If 'esc_ok' is not NULL, those characters will be left
+* escaped if found that way, but will not be unescaped otherwise (used
+* for delimiters). If a %-escape sequence is encountered that is not
+* followed by 2 hexadecimal digits, the sequence is invalid and
+* false (0) will be returned. Otherwise true (1) will be returned for
+* success.
+*
+* Note that all %-escape sequences will be normalized to UPPERCASE
+* as indicated in RFC 3986. Unless included in esc_extra or esc_ok
+* alphanumerics and "-._~" will always be unes
[PATCH v6 4/4] config: allow http..* any user matching
Previously the had to specify an exactly matching user name
and password if those were present in the url being matched against.
Now the password portion is always ignored and omitting the user
name from allows it to match against any user name.
Signed-off-by: Kyle J. McKay
---
Documentation/config.txt | 23 ++--
http.c | 280 +++
test-url-normalize.c | 11 +-
3 files changed, 254 insertions(+), 60 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e461f32..8b32a15 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1517,15 +1517,20 @@ http..*::
Any of the http.* options above can be applied selectively to some urls.
For example "http.https://example.com.useragent"; would set the user
agent only for https connections to example.com. The value
- matches a url if it is an exact match or if it is a prefix of the url
- matching at a "/" boundary. Longer matches take precedence over
- shorter ones with the environment variable settings taking precedence
- over all. The urls are normalized before testing for a match. Note,
- however, that any user, password and/or port setting that appears in a
- url must also match that part of to have a successful match. The
- urls that are matched against are those given directly to git commands.
- This means any urls visited as a result of a redirection do not
- participate in matching.
+ matches a url if it refers to the same scheme, host and port and the
+ path portion is an exact match or a prefix that matches at a "/"
+ boundary. If does not include a user name, it will match a url
+ with any username otherwise the user name must match as well (the
+ password part, if present in the url, is always ignored). Longer
+ path matches take precedence over shorter matches no matter what order
+ they occur in. For same length matches, the last one wins except that a
+ same-length match that includes a user name will be preferred over
+ a same-length match that does not. The urls are normalized before
+ matching so that equivalent urls that are simply spelled differently
+ will match properly. Environment variable settings always override any
+ matches. The urls that are matched against are those given directly to
+ git commands. This means any urls visited as a result of a redirection
+ do not participate in matching.
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
diff --git a/http.c b/http.c
index 3c5c2ef..3096a1d 100644
--- a/http.c
+++ b/http.c
@@ -56,7 +56,35 @@ enum http_option_type {
OPT_MAX
};
+struct url_info {
+ char *url; /* normalized url on success, must be freed,
otherwise NULL */
+ const char *err;/* if !url, a brief reason for the failure,
otherwise NULL */
+
+ /* the rest of the fields are only set if url != NULL */
+
+ size_t url_len; /* total length of url (which is now
normalized) */
+ size_t scheme_len; /* length of scheme name (excluding final :) */
+ size_t user_off;/* offset into url to start of user name (0 =>
none) */
+ size_t user_len;/* length of user name; if user_off != 0 but
+ user_len == 0, an empty user name was given
*/
+ size_t passwd_off; /* offset into url to start of passwd (0 =>
none) */
+ size_t passwd_len; /* length of passwd; if passwd_off != 0 but
+ passwd_len == 0, an empty passwd was given */
+ size_t host_off;/* offset into url to start of host name (0 =>
none) */
+ size_t host_len;/* length of host name; this INCLUDES any
':portnum';
+* file urls may have host_len == 0 */
+ size_t port_len;/* if a portnum is present (port_len != 0), it
has
+* this length (excluding the leading ':') at
the
+* end of the host name (always 0 for file
urls) */
+ size_t path_off;/* offset into url to the start of the url path;
+* this will always point to a '/' character
+* after the url has been normalized */
+ size_t path_len;/* length of path portion excluding any trailing
+* '?...' and '#...' portion; will always be >=
1 */
+};
+
static size_t http_option_max_matched_len[OPT_MAX];
+static int http_option_user_matched[OPT_MAX];
static int curl_ssl_verify = -1;
static int curl_ssl_try;
@@ -243,7 +271,7 @@ static int append_normalized_escapes(struct strbuf *buf,
return 1;
}
-static char *http_options_url_normalize(const char *ur
[PATCH v6 0/4] config: add support for http..* settings
NOTE: This patch requires the following preparatory change:
f1ff763 http.c: fix parsing of http.sslCertPasswordProtected variable
which is currently in pu.
This patch series adds support for http..* settings. The patch is
organized as a series of improvements on the functionality:
1/4 - adds basic textual matching support
2/4 - adds URL normalization before matching
3/4 - adds a test for the URL normalization function
4/4 - adds any user matching
With-Feedback-From-jh: Junio C Hamano
With-Feedback-From-jk: Jeff King
With-Feedback-From-es: Eric Sunshine
Differences from v5:
Dropped the GIT_SSL_CERT_PASSWORD_PROTECTED patch. It's related to the
http.sslCertPasswordProtected patch, but not required as it touches different
sections of the http.c file.
1/4 - this is identical to v5's 3/5. Updated from v4's 1/4:
* Added cover comments to log message (feedback-jh)
* Updated help text (feedback-jk)
* Uppercased enum values (feedback-jk)
* Moved #ifdef enum values to end (feedback-jh)
* Renamed check_matched_len to new_match_is_shorter (feedback-jh)
* Removed 1 unnecessary cast (feedback-jk,feedback-jh)
* Based on preparatory http.sslCertPasswordProtected fix (feedback-jh)
2/4 - Updated from v5's 4/5:
* Altered append_normalized_escapes descriptive comments (feedback-es)
* Improved normalization (keep empty user name, strip port leading 0s and
resolve . and .. in path)
3/4 - Updated from v5's 5/5:
* Add more tests and adjust to improved normalization behavior
4/4 - New code
* Allow a http..* config item without a user name to match a url passed
to git that has a user name
Applicable comments from v5 cover:
To better support matching URLs that are equivalent but spelled differently, a
url_normalize function has been added. Currently this patch leaves it in
http.c as http_options_url_normalize as I am unclear whether it should go into
url.{h,c} at this time since only http.c uses it.
Since the url_normalize function's behavior is non-trivial, it is presented as
a separate patch on top of the basic http..* settings support. A new test
for it has also been included as a separate patch. I am unclear on the proper
number for this test, but have gone ahead and put it with the other http tests
since this patch series places the url_normalize function into http.c.
Kyle J. McKay (4):
config: add support for http..* settings
config: improve support for http..* settings
tests: add new test for the url_normalize function
config: allow http..* any user matching
.gitignore | 1 +
Documentation/config.txt | 19 ++
Makefile | 5 +
http.c | 675 +--
t/t5200-url-normalize.sh | 161 +++
test-url-normalize.c | 62 +
6 files changed, 906 insertions(+), 17 deletions(-)
create mode 100755 t/t5200-url-normalize.sh
create mode 100644 test-url-normalize.c
--
1.8.3
--
To unsubscribe from this list: send the line "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 v6 1/4] config: add support for http..* settings
The credentials configuration values already support url-specific
configuration items in the form credential..*. This patch
adds similar support for http configuration values.
The value is considered a match to a url if the value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So "https://example.com/test"; will
match "https://example.com/test"; and "https://example.com/test/too";
but not "https://example.com/testextra";.
Longer matches take precedence over shorter matches with
environment variable settings taking precedence over all.
With this configuration:
[http]
useragent = other-agent
noEPSV = true
[http "https://example.com";]
useragent = example-agent
sslVerify = false
[http "https://example.com/path";]
useragent = path-agent
The "https://other.example.com/"; url will have useragent
"other-agent" and sslVerify will be on.
The "https://example.com/"; url will have useragent
"example-agent" and sslVerify will be off.
The "https://example.com/path/sub"; url will have useragent
"path-agent" and sslVerify will be off.
All three of the examples will have noEPSV enabled.
Signed-off-by: Kyle J. McKay
---
Documentation/config.txt | 15 +
http.c | 169 ++-
2 files changed, 167 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53fc5..41cab91 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1513,6 +1513,21 @@ http.useragent::
of common USER_AGENT strings (but not including those like git/1.7.1).
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
+http..*::
+ Any of the http.* options above can be applied selectively to some urls.
+ For example "http.https://example.com.useragent"; would set the user
+ agent only for https connections to example.com. The value
+ matches a url if it is an exact match or a prefix of the url matching
+ at a "/" boundary. Longer matches take precedence over shorter
+ ones with the environment variable settings taking precedence over all.
+ Note that must match the url passed to git exactly (other than
+ possibly being a prefix). This means any user, password and/or port
+ setting that appears in a url as well as any %XX escapes that are
+ present must also appear in to have a successful match. The urls
+ that are matched against are those given directly to git commands. In
+ other words, use exactly the same url that was passed to git (possibly
+ shortened) for the value of the config setting.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index 37986f8..f61a79c 100644
--- a/http.c
+++ b/http.c
@@ -30,6 +30,34 @@ static CURL *curl_default;
char curl_errorstr[CURL_ERROR_SIZE];
+enum http_option_type {
+ OPT_POST_BUFFER,
+ OPT_MIN_SESSIONS,
+ OPT_SSL_VERIFY,
+ OPT_SSL_TRY,
+ OPT_SSL_CERT,
+ OPT_SSL_CAINFO,
+ OPT_LOW_SPEED,
+ OPT_LOW_TIME,
+ OPT_NO_EPSV,
+ OPT_HTTP_PROXY,
+ OPT_COOKIE_FILE,
+ OPT_USER_AGENT,
+ OPT_PASSWD_REQ,
+#ifdef USE_CURL_MULTI
+ OPT_MAX_REQUESTS,
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070903
+ OPT_SSL_KEY,
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070908
+ OPT_SSL_CAPATH,
+#endif
+ OPT_MAX
+};
+
+static size_t http_option_max_matched_len[OPT_MAX];
+
static int curl_ssl_verify = -1;
static int curl_ssl_try;
static const char *ssl_cert;
@@ -141,33 +169,121 @@ static void process_curl_messages(void)
}
#endif
+static size_t http_options_url_match_prefix(const char *url,
+ const char *url_prefix,
+ size_t url_prefix_len)
+{
+ /*
+* url_prefix matches url if url_prefix is an exact match for url or it
+* is a prefix of url and the match ends on a path component boundary.
+* Both url and url_prefix are considered to have an implicit '/' on the
+* end for matching purposes if they do not already.
+*
+* url must be NUL terminated. url_prefix_len is the length of
+* url_prefix which need not be NUL terminated.
+*
+* The return value is the length of the match in characters (excluding
+* any final '/') or 0 for no match. Passing "/" as url_prefix will
+* always cause 0 to be returned.
+*/
+ size_t url_len;
+ if (url_prefix_len && url_prefix[url_prefix_len - 1] == '/')
+ url_prefix_len--;
+ if (!url_prefix_len || strncmp(url, url_prefix, url_prefix_len))
+ return 0;
+ url_len = strlen(url);
+ if ((url_len == url_
Re: [RFC] checkout --rebase
Damn it: checkout doesn't get executed at all because the $mb = $onto condition fails; I was looking in the wrong place. It's format-patch and am that are slowing things down terribly. Has anyone looked into stripping out the dependency? Why is cherry-pick deficient? My current workaround is to use the faster `--keep-empty` codepath, but it doesn't persist state on conflict. Isn't this an undocumented fact (aka. bug)? Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] Update po/git-gui.pot
Signed-off-by: Yamada Saburo --- po/git-gui.pot | 1056 +++- 1 file changed, 578 insertions(+), 478 deletions(-) diff --git a/po/git-gui.pot b/po/git-gui.pot index 0c94f9c..97ed37a 100644 --- a/po/git-gui.pot +++ b/po/git-gui.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2010-01-26 15:47-0800\n" +"POT-Creation-Date: 2013-07-10 03:27+0900\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -16,33 +16,33 @@ msgstr "" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n" -#: git-gui.sh:41 git-gui.sh:793 git-gui.sh:807 git-gui.sh:820 git-gui.sh:903 -#: git-gui.sh:922 -msgid "git-gui: fatal error" -msgstr "" - -#: git-gui.sh:743 +#: git-gui.sh:859 #, tcl-format msgid "Invalid font specified in %s:" msgstr "" -#: git-gui.sh:779 +#: git-gui.sh:911 msgid "Main Font" msgstr "" -#: git-gui.sh:780 +#: git-gui.sh:912 msgid "Diff/Console Font" msgstr "" -#: git-gui.sh:794 +#: git-gui.sh:926 git-gui.sh:940 git-gui.sh:953 git-gui.sh:1043 +#: git-gui.sh:1062 git-gui.sh:3094 +msgid "git-gui: fatal error" +msgstr "" + +#: git-gui.sh:927 msgid "Cannot find git in PATH." msgstr "" -#: git-gui.sh:821 +#: git-gui.sh:954 msgid "Cannot parse Git version string:" msgstr "" -#: git-gui.sh:839 +#: git-gui.sh:979 #, tcl-format msgid "" "Git version cannot be determined.\n" @@ -54,473 +54,493 @@ msgid "" "Assume '%s' is version 1.5.0?\n" msgstr "" -#: git-gui.sh:1128 +#: git-gui.sh:1276 msgid "Git directory not found:" msgstr "" -#: git-gui.sh:1146 +#: git-gui.sh:1306 msgid "Cannot move to top of working directory:" msgstr "" -#: git-gui.sh:1154 +#: git-gui.sh:1314 msgid "Cannot use bare repository:" msgstr "" -#: git-gui.sh:1162 +#: git-gui.sh:1322 msgid "No working directory" msgstr "" -#: git-gui.sh:1334 lib/checkout_op.tcl:306 +#: git-gui.sh:1494 lib/checkout_op.tcl:306 msgid "Refreshing file status..." msgstr "" -#: git-gui.sh:1390 +#: git-gui.sh:1554 msgid "Scanning for modified files ..." msgstr "" -#: git-gui.sh:1454 +#: git-gui.sh:1621 msgid "Calling prepare-commit-msg hook..." msgstr "" -#: git-gui.sh:1471 +#: git-gui.sh:1638 msgid "Commit declined by prepare-commit-msg hook." msgstr "" -#: git-gui.sh:1629 lib/browser.tcl:246 +#: git-gui.sh:1796 lib/browser.tcl:252 msgid "Ready." msgstr "" -#: git-gui.sh:1787 +#: git-gui.sh:1954 #, tcl-format msgid "Displaying only %s of %s files." msgstr "" -#: git-gui.sh:1913 +#: git-gui.sh:2080 msgid "Unmodified" msgstr "" -#: git-gui.sh:1915 +#: git-gui.sh:2082 msgid "Modified, not staged" msgstr "" -#: git-gui.sh:1916 git-gui.sh:1924 +#: git-gui.sh:2083 git-gui.sh:2095 msgid "Staged for commit" msgstr "" -#: git-gui.sh:1917 git-gui.sh:1925 +#: git-gui.sh:2084 git-gui.sh:2096 msgid "Portions staged for commit" msgstr "" -#: git-gui.sh:1918 git-gui.sh:1926 +#: git-gui.sh:2085 git-gui.sh:2097 msgid "Staged for commit, missing" msgstr "" -#: git-gui.sh:1920 +#: git-gui.sh:2087 msgid "File type changed, not staged" msgstr "" -#: git-gui.sh:1921 +#: git-gui.sh:2088 git-gui.sh:2089 +msgid "File type changed, old type staged for commit" +msgstr "" + +#: git-gui.sh:2090 msgid "File type changed, staged" msgstr "" -#: git-gui.sh:1923 +#: git-gui.sh:2091 +msgid "File type change staged, modification not staged" +msgstr "" + +#: git-gui.sh:2092 +msgid "File type change staged, file missing" +msgstr "" + +#: git-gui.sh:2094 msgid "Untracked, not staged" msgstr "" -#: git-gui.sh:1928 +#: git-gui.sh:2099 msgid "Missing" msgstr "" -#: git-gui.sh:1929 +#: git-gui.sh:2100 msgid "Staged for removal" msgstr "" -#: git-gui.sh:1930 +#: git-gui.sh:2101 msgid "Staged for removal, still present" msgstr "" -#: git-gui.sh:1932 git-gui.sh:1933 git-gui.sh:1934 git-gui.sh:1935 -#: git-gui.sh:1936 git-gui.sh:1937 +#: git-gui.sh:2103 git-gui.sh:2104 git-gui.sh:2105 git-gui.sh:2106 +#: git-gui.sh:2107 git-gui.sh:2108 msgid "Requires merge resolution" msgstr "" -#: git-gui.sh:1972 +#: git-gui.sh:2143 msgid "Starting gitk... please wait..." msgstr "" -#: git-gui.sh:1984 +#: git-gui.sh:2155 msgid "Couldn't find gitk in PATH" msgstr "" -#: git-gui.sh:2043 +#: git-gui.sh:2214 msgid "Couldn't find git gui in PATH" msgstr "" -#: git-gui.sh:2455 lib/choose_repository.tcl:36 +#: git-gui.sh:2633 lib/choose_repository.tcl:36 msgid "Repository" msgstr "" -#: git-gui.sh:2456 +#: git-gui.sh:2634 msgid "Edit" msgstr "" -#: git-gui.sh:2458 lib/choose_rev.tcl:561 +#: git-gui.sh:2636 lib/choose_rev.tcl:567 msgid "Branch" msgstr "" -#: git-gui.sh:2461 lib/choose_rev.tcl:548 +#: git-gui.sh:2639 lib/choose_rev.tcl:554 msgid "Commit@@noun" msgstr "" -#: git-gui.sh:2464 lib/merge.tcl:121 lib/merge.tcl:150 lib/merge.tcl:168 +#: git-gui.sh:2642 lib/merge.tcl:123 lib/merge.tcl:152 lib/merge.tcl:170 msgid "Me
Re: [PATCH v2 1/3] Add translation ("yes","no","ask")
Signed-off-by: Yamada Saburo
---
lib/option.tcl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/option.tcl b/lib/option.tcl
index 0cf1da1..7af858c 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -158,7 +158,7 @@ proc do_options {} {
{t gui.newbranchtemplate {mc "New Branch Name Template"}}
{c gui.encoding {mc "Default File Contents Encoding"}}
{b gui.warndetachedcommit {mc "Warn before committing to a
detached head"}}
- {s gui.stageuntracked {mc "Staging of untracked files"} {list
"yes"
"no" "ask"}}
+ {s gui.stageuntracked {mc "Staging of untracked files"} {list
[mc
"yes"] [mc "no"] [mc "ask"]}}
} {
set type [lindex $option 0]
set name [lindex $option 1]
--
1.8.1.msysgit.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
[PATCH v2 0/3] git-gui translation update
lib/option.tcl |2 +- po/git-gui.pot | 1056 +++ po/ja.po | 1143 ++-- 3 files changed, 1195 insertions(+), 1006 deletions(-) -- To unsubscribe from this list: send the line "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] TIG: Fix to reinstate proper operation with no arguments
On Fri, Jul 19, 2013 at 12:07 AM, Jonas Fonseca wrote:
> On Thu, Jul 18, 2013 at 9:30 AM, Drew Northup wrote:
>>
>> Somehow this patch breaks the main view to not open the correct commit in
>> diff view when is pressed. Back to the debugger...
>
> Does this (possibly white-space damaged) patch work for you?
I did look back at that sort of fix, but I kept getting compiler
warnings about a pointer conversion. Yes, it does work (I was actually
initializing the whole buffer to NULL), but I'd prefer doing so
without the implicit int* conversion warnings.
> diff --git a/tig.c b/tig.c
> index ba9ba98..74a2928 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -3104,7 +3104,7 @@ format_expand_arg(struct format_context *format,
> const char *name)
> static bool
> format_append_arg(struct format_context *format, const char
> ***dst_argv, const char *arg)
> {
> - format->bufpos = 0;
> + format->buf[0] = format->bufpos = 0;
>
> while (arg) {
> char *next = strstr(arg, "%(");
--
-Drew Northup
--
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
To unsubscribe from this list: send the line "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] checkout --rebase
Ramkumar Ramachandra wrote: > diff --git a/git-rebase.sh b/git-rebase.sh > index 0039ecf..7405d9a 100755 > --- a/git-rebase.sh > +++ b/git-rebase.sh Er, sorry. I think it suffices to check that $branch_name equals HEAD, for this optimization. -- To unsubscribe from this list: send the line "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] checkout --rebase
Ramkumar Ramachandra wrote: > Sebastian Staudt wrote: >> Isn't this what you want? >> >> $ git rebase master um-build > > Ha, yes. Sorry about the stupidity. Hm, I'm not entirely sure how to optimize the codepath to eliminate the checkout. It seems to be absolutely necessary atleast in the -i codepath. Let's inspect when $switch_to is set: # Is it "rebase other $branchname" or "rebase other $commit"? branch_name="$1" switch_to="$1" $revisions seems to be set correctly, and rebase--am does a move_to_original_branch as the last step. So, I wonder if this will work: diff --git a/git-rebase.sh b/git-rebase.sh index 0039ecf..7405d9a 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -542,9 +542,15 @@ then if test -z "$force_rebase" then # Lazily switch to the target branch if needed... - test -z "$switch_to" || - GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \ - git checkout "$switch_to" -- + if ! test -z "$switch_to"; then + if "$type" = am; then + GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout -b $switch_to-2" \ + git checkout -b "$switch_to-2" -- + else + GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \ + git checkout "$switch_to" -- + fi + fi say "$(eval_gettext "Current branch \$branch_name is up to date.")" finish_rebase exit 0 (ofcourse, we still need a mechanism to remove this temporary $switch_to-2 branch) What about rebase--merge? Can we eliminate the checkout then? -- To unsubscribe from this list: send the line "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] checkout --rebase
Sebastian Staudt wrote: > Isn't this what you want? > > $ git rebase master um-build Ha, yes. Sorry about the stupidity. -- To unsubscribe from this list: send the line "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] checkout --rebase
Isn't this what you want? $ git rebase master um-build 2013/7/19 Ramkumar Ramachandra : > Hi, > > I'm often work on small topic branches, and find myself doing this quite > often: > > # on branch master > $ git checkout um-build > $ git rebase master > > This is horribly inefficient; the first operation takes a _really_ > long time to complete, since master updates itself very often and I > have to check out an old worktree. So, I work around this issue by > doing: > > # on branch master > $ git checkout -b um-build-2 > $ git cherry-pick ..um-build > $ git branch -M um-build > > ... and I scripted it. Perhaps we should get this functionality in > core, as `git checkout --rebase` (or something)? > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Delete current branch
Hi, Many of my ideas turn out to be really stupid, and I need to throw away my feature branch. So, I find myself doing this often: # on branch menuconfig-jk $ git checkout master $ git branch -D # er, what was the branch name again? $ git checkout - # Ah $ git checkout master $ git branch -D menuconfig-jk So, I scripted it for myself. Perhaps we should get the functionality in core as `git branch -Dc` (c for "current"; or something)? Also, perhaps a `git describe -` corresponding to `git checkout -`? Then I can use it with --contains --all to get the name of the previous branch. 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
[RFC] checkout --rebase
Hi, I'm often work on small topic branches, and find myself doing this quite often: # on branch master $ git checkout um-build $ git rebase master This is horribly inefficient; the first operation takes a _really_ long time to complete, since master updates itself very often and I have to check out an old worktree. So, I work around this issue by doing: # on branch master $ git checkout -b um-build-2 $ git cherry-pick ..um-build $ git branch -M um-build ... and I scripted it. Perhaps we should get this functionality in core, as `git checkout --rebase` (or something)? 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: Git Clone Parameter
Allan Acheampong wrote: > I could write a script with for each in but thats way too much hassle $ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed 's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b (completely untested ofcourse) Do you see what the problem is immediately? There's nothing special about "origin": I could have branches with the same name on several remotes. Without detaching local branches from remote branches, there is no distributed workflow: your central workflow is just a special case. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git Clone Parameter
Hi, it would be nice to have a parameter on 'git clone' that not only clones the repo, but also creates local branches for ALL the branches that are in the repo. I'm new to git, but I found it very confusing to understand the difference between "remote" , "remotes". Is it in the cloned repo, or is it in a remote place? If its local, why doesn't it get shown when I do 'git branch' but when I do 'git branch -a'. For example, I create a project locally with multiple branches, push it, delete it locally and clone it back to my machine. On a 'git branch' I would only see the head branch. I understand that there are projects that have a lot of branches that are not needed for that specific developer, but still it would be nice if one could specify this at clone time. Something like 'git clone -createLocalBranchesForAllBranches' . Of course the param shouldn't be that long. I could write a script with for each in but thats way too much hassle and effort for something that should be there already and I don't think I am the first to get confused by this. I'd like to know your opinions about that and what you think about the suggestion. Allan.-- To unsubscribe from this list: send the line "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 add -e: Explicitly specify that patch should have no color
Andrew Wong writes: > After this commit: > 4c7f1819b3c142ace98269a556bc929c80e7c9fd make color.ui default to 'auto' > the patch file for 'git add -e' receives all the color codes. This is because > diffopt.use_color defaults to -1, which causes want_color to now return > 'auto'. Oops, indeed. The code was relying on the user's config not being loaded (hence color.ui was previously ignored), and now has to explicitely disable color. I'm wondering whether there are other instances of this. I checked that "git format-patch" is not broken, but I hope we did not forget others. > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -343,6 +343,7 @@ static int edit_patch(int argc, const char **argv, const > char *prefix) > > argc = setup_revisions(argc, argv, &rev, NULL); > rev.diffopt.output_format = DIFF_FORMAT_PATCH; > + rev.diffopt.use_color = 0; > DIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES); > out = open(file, O_CREAT | O_WRONLY, 0666); > if (out < 0) Acknowledged-by: Matthieu Moy -- 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: Documentation/git-checkout.txt: Inconsistent naming of paths arguments
On Fri, Jul 19, 2013 at 2:16 PM, Adam Brengesjö wrote: > From SYNOPSIS: > > git checkout [-p|--patch] [] [--] […] > > > From DESCRIPTION > > git checkout [-p|--patch] [] [--] … > > > > 1. Named in SYNOPSIS, but in DESCRIPTION. (It's > referred to as in the body text). > > 2. is marked as optional in SYNOPSIS, but is not. > > I'm not submitting a patch now, as I'm not sure which is correct. If I'm not mistaken, "git checkout" takes pathspec in all cases. -- 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 6/6] diff: deprecate -q option to diff-files
Jonathan Nieder writes: > Junio C Hamano wrote: > >> We should remove the support for "-q" in Git 2.0. > > No. I hope you are teasing. > > I don't mind seeing support for "-q" dropped, but I really don't think > it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some > future release/ be ok? I do not think keeping the support for "-q" in is any huge burden. We do not have to remove it, forever, for that matter. The option is so obscure that (1) I would suspect that only a few very old scripts would use it, (2) even the users who use such a script every day would not know what the script is doing with the option, and (3) we would not know if such scripts exist until a long time passes after we include patches up to this step in a released version. That is why the patch 7/6 rolls the removal into a version bump at which we promised to have a bunch of backward incompatible changes to people. -- To unsubscribe from this list: send the line "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] Add the GIT_SENTINEL macro
Jonathan Nieder writes: > Junio C Hamano wrote: > >> It seems to apply well on the tip of jk/gcc-function-attributes. >> >> - This macro is not about "git" at all, so I'll edit the patch to >>call it GCC_ATTR_SENTINEL before applying. > > Would naming it something like LAST_ARG_MUST_BE_NULL instead make > sense? That way, if some other compiler gains a different syntax for > the same annotation, it would be possible to do > > #if defined(__GNUC__) && __GNUC__ >= 4 > # define LAST_ARG_MUST_BE_NULL __attribute__((sentinel)) > #elif defined(_MSC_VER) && _MSC_VER > 27 > # define LAST_ARG_MUST_BE_NULL __declspec(lastargnull) > #else > # define LAST_ARG_MUST_BE_NULL > #endif I do like last-arg-must-be-null name for its descriptiveness; with the example of NORETURN vs NORETURN_PTR, however, I am not quite convinced that it would help reusing the same macro to different compilers. I would say it is already sheer luck that GCC's __attribute__(()) and MSC's __declspec() both come at the same place in the function declaration syntax, i.e. before the usual declaration. Your next compiler may want the magic immediately before the closing semicolon of the declaration, for example. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Documentation/git-checkout.txt: Inconsistent naming of paths arguments
>From SYNOPSIS: git checkout [-p|--patch] [] [--] […] >From DESCRIPTION git checkout [-p|--patch] [] [--] … 1. Named in SYNOPSIS, but in DESCRIPTION. (It's referred to as in the body text). 2. is marked as optional in SYNOPSIS, but is not. I'm not submitting a patch now, as I'm not sure which is correct. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
