Re: Why can't I push from a shallow clone?
On Thu, Jul 25, 2013 at 07:33:16PM -0700, Gulshan Singh wrote: > I've been trying to figure out why I can't push from a shallow clone > (using --depth) to a repository. I've made simple examples where it > works, but I've read that in doesn't work in every case. However, I > can't come up with a case where it doesn't work. Googling gives this > answer: > http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, > but I don't completely understand the explanation, so I was hoping > someone could explain it. I can't explain it better than what Junio did in the link you just provide. However there's ongoing work to allow shallow clones to be able to push. You can read about it here: http://thread.gmane.org/gmane.comp.version-control.git/230612/focus=230878 -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.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: [REQUEST 1/1] docs: update http..* options documentation
On Jul 25, 2013, at 23:23, Kyle J. McKay wrote: On Jul 25, 2013, at 21:37, Jeff King wrote: You should add your S-O-B, too, for your bits. Yes. I wanted to make certain it didn't get applied just yet. :) Looks like it got patch snarfed anyway. ;-) On Jul 25, 2013, at 23:07, Junio C Hamano wrote: Junio C Hamano writes: Will queue the attached, unless you spot glaring errors made by me, coding while drunk ;-) On Jul 25, 2013, at 21:37, Jeff King wrote: So this patch looks pretty good to me; the two points I raised above are how I would have done it, but they are relatively minor if you do not agree. So Yeah, looks pretty good to me too 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: [REQUEST 1/1] docs: update http..* options documentation
On Jul 25, 2013, at 21:37, Jeff King wrote: On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote: Overhaul the text of the http..* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. --- Signed-off-by: Jeff King Thank you. Added. You should add your S-O-B, too, for your bits. Yes. I wanted to make certain it didn't get applied just yet. :) +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. These look fine in the rendered manpage, but I think the source might be a little easier to read with a blank line between items. My ASCIIDOC is a bit weak. I have added some blank lines. +. Exact user name match (e.g., `user` in `https://u...@example.com/repo.git `). + If the config key has a user name it must match the user name in the URL + exactly. +. Any user name match. If a config key does not have a user name, that config + key will match a URL with any user name (including none). IMHO, this would be more clear as a single item, like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none). The only problem I have with a single item is what's the precedence? Does an exact user match have the same precedence as an any-user match? That would seem to be implied by having them as the same item number. Separating them would appear to make it clearer that an exact user match wins over an any user match, but if you have some alternate text as a suggestion for the single item that clears that up... :) +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) so that +equivalent urls that are simply spelled differently will match properly. And this nicely ties up the open questions I had after re-reading the list. Good. We could define "equivalent" here (the %-encoding thing is obvious, I think, but which components are case-sensitive and which are not is perhaps a bit subtle). I do not necessarily know that it is useful to the user, though, and is one more thing to confuse them. And somebody who really cares can look at the appropriate RFCs. I am considering this text to address that: All URLs are normalized (%-encodings are standardized, case- insensitive parts are lowercased, `./` and `../` path components are resolved) before attempting any matching (the password part, if embedded in the URL, but I'm not sure the extra verbiage makes it better. I think it may just complicate the explanation unnecessarily? -- To unsubscribe from this list: send the line "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: [REQUEST 1/1] docs: update http..* options documentation
Junio C Hamano writes: > Will queue the attached, unless you spot glaring errors made by me, > coding while drunk ;-) ... aand, it turns out that I screwed up while running "git commit --amend" (missed "-a"). I should go to bed now. -- >8 -- From: "Kyle J. McKay" Date: Thu, 25 Jul 2013 15:39:13 -0700 Subject: [PATCH] docs: update http..* options documentation Overhaul the text of the http..* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. Signed-off-by: Jeff King Signed-off-by: Kyle J. McKay Signed-off-by: Junio C Hamano --- Documentation/config.txt | 63 ++-- 1 file changed, 40 insertions(+), 23 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 6b135be..60c140f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1515,30 +1515,47 @@ http.useragent:: 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 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). A - with longer path matches takes precedence over shorter matches no matter - what order they occur in the configuration file. + For a config key to match a URL, each element of the config key is + compared to that of the URL, in the following order: + -For example, if both "https://u...@example.com/path"; and -"https://example.com/path/name"; are used as a config value and -then "https://u...@example.com/path/name/here"; is passed to a git -command, the settings in the "https://example.com/path/name"; section -will be preferred because that has a longer path length match than -"https://u...@example.com/path"; even though the latter did match the -user. 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. +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. + +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. + +. Port number (e.g., `8080` in `http://example.com:8080/`). + This field must match exactly between the config key and the URL. + Omitted port numbers are automatically converted to the correct + default for the scheme before matching. + +. Path (e.g., `repo.git` in `https://example.com/repo.git`). The + path field of the config key must match the path field of the URL + either exactly or as a prefix of slash-delimited path elements. This means + a config key with path `foo/` matches URL path `foo/bar`. A prefix can only + match on a slash (`/`) boundary. Longer matches take precedence (so a config + key with path `foo/bar` is a better match to URL path `foo/bar` than a config + key with just path `foo/`). + +. User name (e.g., `user` in `https://u...@example.com/repo.git`). If + the config key has a user name it must match the user name in the + URL exactly. If the config key does not have a user name, that + config key will match a URL with any user name (including none). +-- ++ +The list above is ordered by decreasing precedence; a URL that matches +a config key's path is preferred to one that matches its user name. For example, +if the URL is `https://u...@example.com/foo/bar` a config key match of +`https://example.com/foo` will be preferred over a config key match of +`https://u...@example.com`. ++ +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) 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 -- 1.8.4-rc0-117-gda13126 -- To unsubscribe
Re: redundant message in builtin/rm.c
Ralf Thielow writes:
> It's more readable if "\n" is at the end of a line.
>
> Q_("the following submodule (or one of its nested submodules)\n"
> "uses a .git directory:"
Thanks both. Perhaps we should do something like this?
-- >8 --
Subject: builtin/rm.c: consolidate error reporting for removing submodules
We have two (not identical) copies of error reporting when
attempting to remove submodules that have their repositories
embedded within them. Add a helper function so that we do not have
to repeat similar error messages with subtly different wording
without a good reason.
Noticed by Jiang Xin.
Signed-off-by: Junio C Hamano
---
builtin/rm.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 5d0c068..694568a 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -57,6 +57,21 @@ static void print_error_files(struct string_list *files_list,
}
}
+static void error_removing_concrete_submodules(struct string_list *files, int
*errs)
+{
+ print_error_files(files,
+ Q_("the following submodule (or one of its nested "
+"submodules)\n"
+"uses a .git directory:",
+"the following submodules (or one of its nested "
+"submodules)\n"
+"use a .git directory:", files->nr),
+ _("\n(use 'rm -rf' if you really want to remove "
+ "it including all of its history)"),
+ errs);
+ string_list_clear(files, 0);
+}
+
static int check_submodules_use_gitfiles(void)
{
int i;
@@ -85,16 +100,8 @@ static int check_submodules_use_gitfiles(void)
if (!submodule_uses_gitfile(name))
string_list_append(&files, name);
}
- print_error_files(&files,
- Q_("the following submodule (or one of its nested "
-"submodules)\n uses a .git directory:",
-"the following submodules (or one of its nested "
-"submodules)\n use a .git directory:",
-files.nr),
- _("\n(use 'rm -rf' if you really want to remove "
- "it including all of its history)"),
- &errs);
- string_list_clear(&files, 0);
+
+ error_removing_concrete_submodules(&files, &errs);
return errs;
}
@@ -236,17 +243,9 @@ static int check_local_mod(unsigned char *head, int
index_only)
" or -f to force removal)"),
&errs);
string_list_clear(&files_cached, 0);
- print_error_files(&files_submodule,
- Q_("the following submodule (or one of its nested "
-"submodule)\nuses a .git directory:",
-"the following submodules (or one of its nested "
-"submodule)\nuse a .git directory:",
-files_submodule.nr),
- _("\n(use 'rm -rf' if you really "
- "want to remove it including all "
- "of its history)"),
- &errs);
- string_list_clear(&files_submodule, 0);
+
+ error_removing_concrete_submodules(&files_submodule, &errs);
+
print_error_files(&files_local,
Q_("the following file has local modifications:",
"the following files have local modifications:",
--
To unsubscribe from this list: send the line "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: [REQUEST 1/1] docs: update http..* options documentation
Jeff King writes: > Signed-off-by: Jeff King > > You should add your S-O-B, too, for your bits. > ... > So this patch looks pretty good to me; the two points I raised above are > how I would have done it, but they are relatively minor if you do not > agree. Will queue the attached, unless you spot glaring errors made by me, coding while drunk ;-) -- >8 -- From: "Kyle J. McKay" Date: Thu, 25 Jul 2013 15:39:13 -0700 Subject: [PATCH] docs: update http..* options documentation Overhaul the text of the http..* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. Signed-off-by: Jeff King Signed-off-by: Kyle J. McKay Signed-off-by: Junio C Hamano --- Documentation/config.txt | 60 +--- 1 file changed, 37 insertions(+), 23 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 6b135be..ec852ab 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1515,30 +1515,44 @@ http.useragent:: 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 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). A - with longer path matches takes precedence over shorter matches no matter - what order they occur in the configuration file. + For a config key to match a URL, each element of the config key is + compared to that of the URL, in the following order: + -For example, if both "https://u...@example.com/path"; and -"https://example.com/path/name"; are used as a config value and -then "https://u...@example.com/path/name/here"; is passed to a git -command, the settings in the "https://example.com/path/name"; section -will be preferred because that has a longer path length match than -"https://u...@example.com/path"; even though the latter did match the -user. 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. +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. +. Port number (e.g., `8080` in `http://example.com:8080/`). + This field must match exactly between the config key and the URL. + Omitted port numbers are automatically converted to the correct + default for the scheme before matching. +. Path (e.g., `repo.git` in `https://example.com/repo.git`). The + path field of the config key must match the path field of the URL + either exactly or as a prefix of slash-delimited path elements. This means + a config key with path `foo/` matches URL path `foo/bar`. A prefix can only + match on a slash (`/`) boundary. Longer matches take precedence (so a config + key with path `foo/bar` is a better match to URL path `foo/bar` than a config + key with just path `foo/`). +. Exact user name match (e.g., `user` in `https://u...@example.com/repo.git`). + If the config key has a user name it must match the user name in the URL + exactly. +. Any user name match. If a config key does not have a user name, that config + key will match a URL with any user name (including none). +-- ++ +The list above is ordered by decreasing precedence; a URL that matches +a config key's path is preferred to one that matches its user name. For example, +if the URL is `https://u...@example.com/foo/bar` a config key match of +`https://example.com/foo` will be preferred over a config key match of +`https://u...@example.com`. ++ +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) 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. i
Re: [RFC] Faster git grep.
On Thu, Jul 25, 2013 at 06:28:50PM -0700, Junio C Hamano wrote: > Ondřej Bílka writes: > > > If grepping random commit in history is important use case then keeping > > db information in history makes sense. Otherwise just having database > > for current version and updating it on the fly as version changes is > > enough. > > Will you reindex every time I do "git checkout next; git checkout > master"? This is separate issue as you would need to change index anyway, number of changes would be proportionate to size of diff so you would not gain much. Possible problem here is that you would end changing many files. A possible solution is do rebuilding in background. For switching often to different branches that are vastly different a best solution for me seems to keep separate index for each branch. Also data structure is trigraph: list of files with counts. -- To unsubscribe from this list: send the line "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: [REQUEST 1/1] docs: update http..* options documentation
On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote: > Overhaul the text of the http..* options documentation > providing a hopefully easier to understand itemized list of > matching behavior as suggested by and including text from > Jeff King. > --- Signed-off-by: Jeff King You should add your S-O-B, too, for your bits. > +-- > +. Scheme (e.g., `https` in `https://example.com/`). This field > + must match exactly between the config key and the URL. > +. Host/domain name (e.g., `example.com` in `https://example.com/`). > + This field must match exactly between the config key and the URL. These look fine in the rendered manpage, but I think the source might be a little easier to read with a blank line between items. > +. Port number (e.g., `8080` in `http://example.com:8080/`). > + This field must match exactly between the config key and the URL. > + Omitted port numbers are automatically converted to the correct > + default for the scheme before matching. Thanks, I forgot to include port number in my original suggested text. > +. Exact user name match (e.g., `user` in > `https://u...@example.com/repo.git`). > + If the config key has a user name it must match the user name in the URL > + exactly. > +. Any user name match. If a config key does not have a user name, that > config > + key will match a URL with any user name (including none). IMHO, this would be more clear as a single item, like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none). > +All URLs are normalized before attempting any matching (the password part, > +if embedded in the URL, is always ignored for matching purposes) so that > +equivalent urls that are simply spelled differently will match properly. And this nicely ties up the open questions I had after re-reading the list. Good. We could define "equivalent" here (the %-encoding thing is obvious, I think, but which components are case-sensitive and which are not is perhaps a bit subtle). I do not necessarily know that it is useful to the user, though, and is one more thing to confuse them. And somebody who really cares can look at the appropriate RFCs. So this patch looks pretty good to me; the two points I raised above are how I would have done it, but they are relatively minor if you do not agree. -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: redundant message in builtin/rm.c
2013/7/26 Jiang Xin :
> Hi,
>
> Commit v1.8.3-1-g914dc02 (rm: better error message on failure for
> multiple files)
> introduced many messages need to be translated. I found two similar messages
> each has a slight typo, and the differences cause redundant works for
> l10n translators.
>
> # builtin/rm.c, line: 90
>
> Q_("the following submodule (or one of its nested "
> "submodules)\n uses a .git directory:",
> "the following submodules (or one of its nested "
> "submodules)\n use a .git directory:",
>
> ( no space before "use(s) a .git directory" ?)
>
> # builtin/rm.c, line: 240
>
> Q_("the following submodule (or one of its nested "
> "submodule)\nuses a .git directory:",
> "the following submodules (or one of its nested "
> "submodule)\nuse a .git directory:",
>
> ( "nested submodule" should be "nested submodules" ?)
>
It's more readable if "\n" is at the end of a line.
Q_("the following submodule (or one of its nested submodules)\n"
"uses a .git directory:"
> --
> Jiang Xin
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CommonCrypto in git
[cc:ed Eric Sunshine and the Git list since folks might be
interested.. not quite [PATCH] ready yet, but it's not too far...]
On Thu, Jul 25, 2013 at 6:00 PM, Jeremy Huddleston Sequoia
wrote:
>
> On Jul 25, 2013, at 17:40, David Aguilar wrote:
>
>> On Thu, Jul 25, 2013 at 4:19 PM, Jeremy Huddleston Sequoia
>> wrote:
>>> Thanks for finally backtracking on this decision(*) and deciding to take my
>>> CommonCrypto changes into git. You really should've attributed us for
>>> providing you with this patch, but at least they're there...
>>>
>>> --Jeremy
>>>
>>> *:
>>> http://git.661346.n2.nabble.com/PATCH-darwin-Use-CommonCrypto-to-compute-SHA1-td4706146.html#a4706906
>>
>> Ah, sorry for not having seen that thread; I would have certainly
>> liked to have credited you.
>>
>> There are still a few deprecation warnings when building on
>> imap-send.c on 10.8 after these changes. We don't have a solution for
>> those yet. The warnings are because we use things from
>> openssl/x509v3.h.
>>
>> If you are aware of an upgrade path for that functionality then I'd be
>> happy to work with the Git list to get them in (and properly attribute
>> you, of course).
>
>
> Hi David,
>
> Based on comparing deprecation warning from my changes and 1.8.3.4, it looks
> like you got about as far as I did (HMAC/CRAM-MD5 and SHA1).
>
> Looking back on my notes, I was intending to rewrite the connection code in
> imap-send.c using SecureTransport (), but I
> hadn't actually started working on that.
>
> I also took a stab at replacing git's use of OpenSSL for base64
> encode/decode, but I ran into some issues, and the bug has been sitting with
> the maintainers of CFData for a while. I've attached patch (which has
> probably bitrotted) and test-case for the bug. If you wouldn't mind, could
> you review the changes as I'm not confident that it's not just a bug in my
> code and would prefer some other eyes looking it over.
> ~ $ clang test.c -lcrypto -framework Security -framework CoreFoundation
> test.c:50:9: warning: 'EVP_DecodeBlock' is deprecated
> [-Wdeprecated-declarations]
> o = EVP_DecodeBlock(out, (unsigned char *)in, strlen(in));
> ^
> 1 warning generated.
>
> ~ $ ./a.out
> 49 <0606932735571463.1337625...@cid.outersquare.org>
> 51 <0606932735571463.1337625...@cid.outersquare.org>
>
> Thanks,
> Jeremy
Hmm. strlen() on both outputs is the same, so it's correct in that
respect, but it does seem like a bug in CFDataGetLength(). I don't
think we deal with nulls inside the strings so that could paper over
it, but it does seem kinda wrong.
The reason is that base64 encoding requires padding of the data so
that its length is a multiple of 3, and 51 is the next divisible by 3
number. The internals of the decoder is leaking into the interface it
seems...
I'm not sure what that would mean for backwards compatibility if
CFDataGetLength() were changed. For Git, it seems that strlen(output)
would work for imap-send's purposes.
My assumption is that folks don't have NULL in their usernames and
passwords, which I think is sane.
I've inlined your original patch and test program below. Jeremy, can
you help with a follow-up patch?
The style should also be adjusted to match Git's; under_scores instead
of camelCase, and tabs for indents. I can help roll a patch together
next week if you don't beat me to it ;-)
cheers, and thanks for the patch.
--
David
--- test.c ---
#include
#include
#include
#define die(...) abort()
static int _EVP_DecodeBlock(unsigned char *out, const unsigned char
*in, int in_len) {
CFErrorRef error;
SecTransformRef decoder;
CFDataRef inData, outData;
CFIndex length, result_len;
decoder = SecDecodeTransformCreate(kSecBase64Encoding, &error);
if (!decoder) {
die("SecEncodeTransformCreate failed: %ld",
(long)CFErrorGetCode(error));
}
inData = CFDataCreate(kCFAllocatorDefault, in, in_len);
SecTransformSetAttribute(decoder, kSecTransformInputAttributeName,
inData, &error);
if (error) {
die("SecTransformSetAttribute failed: %ld",
(long)CFErrorGetCode(error));
}
outData = SecTransformExecute(decoder, &error);
if (error) {
die("SecTransformExecute failed: %ld", (long)CFErrorGetCode(error));
}
length = CFDataGetLength(outData);
CFDataGetBytes(outData, CFRangeMake(0, length), out);
CFRelease(outData);
CFRelease(inData);
CFRelease(decoder);
return (int)length;
}
int main() {
int i;
const char *in =
"PDA2MDY5MzI3MzU1NzE0NjMuMTMzNzYyNTUxM0BjaWQub3V0ZXJzcXVhcmUub3JnPg==";
unsigned char out[1024];
int o;
o = _EVP_DecodeBlock(out, (unsigned char *)in, strlen(in));
printf("%d %ld %s\n", o, strlen((const char *)out), out);
o = EVP_DecodeBlock(out, (unsigned char *)in, strlen(in));
printf("%d %ld %s\n", o, strlen((const char *)out), out);
return 0;
}
--- >8 --- original patch --- >8 ---
commit c5d5a2cb24bc3248aa49076577131e550e2af529
Author: Jer
redundant message in builtin/rm.c
Hi,
Commit v1.8.3-1-g914dc02 (rm: better error message on failure for
multiple files)
introduced many messages need to be translated. I found two similar messages
each has a slight typo, and the differences cause redundant works for
l10n translators.
# builtin/rm.c, line: 90
Q_("the following submodule (or one of its nested "
"submodules)\n uses a .git directory:",
"the following submodules (or one of its nested "
"submodules)\n use a .git directory:",
( no space before "use(s) a .git directory" ?)
# builtin/rm.c, line: 240
Q_("the following submodule (or one of its nested "
"submodule)\nuses a .git directory:",
"the following submodules (or one of its nested "
"submodule)\nuse a .git directory:",
( "nested submodule" should be "nested submodules" ?)
--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Why can't I push from a shallow clone?
I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain 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: git and cyrillic branches
On 2013-07-25 14.19, иванов иван wrote: > hello! there is problem vith git and cyrillic (utf-8) names of branches. > branch creates perfectly, but when i clone this remote branch to local host, > there are 2 bugs: > 1) "git branch" doesnt show checked branch with asterisk (while on remote > server it does) > 2) "git push" gives 2 errors: "fatal: BRANCH_NAME cannot be resolved to > branch." and "fatal: The remote end hung up unexpectedly" > thanks. It could be helpful if you could provide more information. The best could be a step-by-step instruction using a some "mini repo", so that we we can reproduce the problem. I have done an illustrating example using UTF-8, (not cyrillic, I don't have these letters on my keyboard ;-) tb@linux:~$ mkdir cyrill tb@linux:~$ cd cyrill/ tb@linux:~/cyrill$ git init Initialized empty Git repository in /home/tb/cyrill/.git/ tb@linux:~/cyrill$ echo File>File tb@linux:~/cyrill$ git checkout -b bränch Switched to a new branch 'bränch' tb@linux:~/cyrill$ git add File tb@linux:~/cyrill$ git commit -m "Add File" [bränch (root-commit) e39d84e] Add File 1 file changed, 1 insertion(+) create mode 100644 "File" tb@linux:~/cyrill$ git branch * bränch tb@linux:~/cyrill$ tb@macos:~> git clone tb@linux:~/cyrill Cloning into 'cyrill'... tb@linux's password: remote: Counting objects: 3, done. Receiving objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) tb@macos:~> cd cyrill/ tb@macos:~/cyrill> git branch * bränch tb@macos:~/cyrill> ls -l total 8 -rw-r--r-- 1 tb staff 6 Jul 26 03:39 File tb@macos:~/cyrill> === Other question: what does (on Mac OS) git config core.precomposeunicode give you? /Torsten -- To unsubscribe from this list: send the line "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] remotes-hg: bugfix for fetching non local remotes
Antoine Pelisse writes: > On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras > wrote: >> That's true. Maybe something like: >> >> for x in repos: >> local_hg = os.path.join(shared_path, x, 'clone', '.hg') >> if os.path.exists(local_hg): >> shutil.copytree(local_hg, hg_path) >> break > > I think that would work, but I think the patch from Joern Hees would > have to be reverted first (as it's merged in next) The expectation is that not all things in 'next' today will be in 1.8.4 anyway, so it is perfectly OK to revert it as needed. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Faster git grep.
Ondřej Bílka writes: > If grepping random commit in history is important use case then keeping > db information in history makes sense. Otherwise just having database > for current version and updating it on the fly as version changes is > enough. Will you reindex every time I do "git checkout next; git checkout master"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REQUEST 1/1] docs: update http..* options documentation
Overhaul the text of the http..* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. --- Documentation/config.txt | 60 +--- 1 file changed, 37 insertions(+), 23 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 6b135be..8ff966d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1515,30 +1515,44 @@ http.useragent:: 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 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). A - with longer path matches takes precedence over shorter matches no matter - what order they occur in the configuration file. + For a config key to match a URL, each element of the config key is + compared to that of the URL, in the following order: + -For example, if both "https://u...@example.com/path"; and -"https://example.com/path/name"; are used as a config value and -then "https://u...@example.com/path/name/here"; is passed to a git -command, the settings in the "https://example.com/path/name"; section -will be preferred because that has a longer path length match than -"https://u...@example.com/path"; even though the latter did match the -user. 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. +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. +. Port number (e.g., `8080` in `http://example.com:8080/`). + This field must match exactly between the config key and the URL. + Omitted port numbers are automatically converted to the correct + default for the scheme before matching. +. Path (e.g., `repo.git` in `https://example.com/repo.git`). The + path field of the config key must match the path field of the URL + either exactly or as a prefix of slash-delimited path elements. This means + a config key with path `foo/` matches URL path `foo/bar`. A prefix can only + match on a slash (`/`) boundary. Longer matches take precedence (so a config + key with path `foo/bar` is a better match to URL path `foo/bar` than a config + key with just path `foo/`). +. Exact user name match (e.g., `user` in `https://u...@example.com/repo.git`). + If the config key has a user name it must match the user name in the URL + exactly. +. Any user name match. If a config key does not have a user name, that config + key will match a URL with any user name (including none). +-- ++ +The list above is ordered by decreasing precedence; a URL that matches +a config key's path is preferred to one that matches its user name. For example, +if the URL is `https://u...@example.com/foo/bar` a config key match of +`https://example.com/foo` will be preferred over a config key match of +`https://u...@example.com`. ++ +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) 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 -- 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
[REQUEST 0/1] Requesting your signed-off-by
Peff, The tentative patch included in the following [REQUEST 1/1] message includes so much of your suggested text from: > From: Jeff King > Date: July 23, 2013 23:42:59 PDT > Subject: Re: [PATCH v8 4/4] config: allow http..* any user matching > [...] > For (1), I wonder if the explanation would be simpler if the precedences > of each sub-part were simply laid out. That is, would it be correct to > say something like: > > For a config key to match a URL, each element of the config key (if > present) is compared to that of the URL, in the following order: > >1. Protocol (e.g., `https` in `https://example.com/`). This field > must match exactly between the config key and the URL. > >2. Host/domain name (e.g., `example.com` in `https://example.com/`). > This field must match exactly between the config key and the URL. > >3. Path (e.g., `repo.git` in `https://example.com/repo.git`). This > field is prefix-matched by slash-delimited path elements, so that > config key `foo/` matches URL `foo/bar`. Longer matches take > precedence (so `foo/bar`, if it exists, is a better match than > just `foo/`). > >4. Username (e.g., `user` in `https://u...@example.com/repo.git`). > > The list above is ordered by decreasing precedence; a URL that matches > a config key's path is preferred to one that matches its username. that I do not feel comfortable submitting a patch containing it under my name without your 'Signed-off-by:' as I feel it would be a copyright violation to do otherwise. Since the 'Signed-off-by' mechanism is how the Git project handles this, I'm asking for a reply to the following [REQUEST 1/1] message that includes the full patch text with a 'Signed-off-by' line added from you before I include it in any patch series (after which I will add my own 'Signed-off-by' for the other changes I made). If you would prefer to simply submit your own patch with the changes, I have no objection and will simply refer to that as a required patch instead. Thanks, Kyle Kyle J. McKay (1): docs: update http..* options documentation Documentation/config.txt | 60 +--- 1 file changed, 37 insertions(+), 23 deletions(-) -- 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
Re: [RFC] Faster git grep.
On Thu, Jul 25, 2013 at 01:41:13PM -0700, Junio C Hamano wrote: > Ondřej Bílka writes: > > > One solution would be to use same trick as was done in google code. > > Build and keep database of trigraphs and which files contain how many of > > them. When querry is made then check > > only these files that have appropriate combination of trigraphs. > > This depends on how you go about trying to reducing the database > overhead, I think. For example, a very naive approach would be to > create such trigraph hit index for each and every commit for all > paths. When "git grep $commit $pattern" is run, you would consult > such table with $commit and potential trigraphs derived from the > $pattern to grab the potential paths your hits _might_ be in. > Do you think that git grep $commit $pattern is run in more than 1% of cases than git grep $pattern ? If grepping random commit in history is important use case then keeping db information in history makes sense. Otherwise just having database for current version and updating it on the fly as version changes is enough. > But the contents of a path usually do not change in each and every > commit. So you may want to instead index with the blob object names > (i.e. which trigraphs appear in what blobs). But once you go that > route, your "git grep $commit $pattern" needs to read and enumerate > all the blobs that appear in $commit's tree, and see which blobs may > potentially have hits. Then you would need to build an index every > time you make a new commit for blobs whose trigraphs have not been > counted. > > Nice thing is that once a blob (or a commit for that matter) is > created and its object name is known, its contents will not change, > so you can index once and reuse it many times. But I am not yet > convinced if pre-indexing is an overall win, compared to the cost of > maintaining such a database. -- To unsubscribe from this list: send the line "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] remotes-hg: bugfix for fetching non local remotes
On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras wrote: > That's true. Maybe something like: > > for x in repos: > local_hg = os.path.join(shared_path, x, 'clone', '.hg') > if os.path.exists(local_hg): > shutil.copytree(local_hg, hg_path) > break I think that would work, but I think the patch from Joern Hees would have to be reverted first (as it's merged in next) Cheers, Antoine -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
YOUR EMAIL HAS WON (Microsoft Iberica)
Confirm Detail Congratulation To The Owner Of This Email Address. We are delighted to inform you of our Post Code Microsoft Iberica award held in Spain. This awards is fully based on an electronic selection, Winners were picked by computerized system, drawn from over 43,000,00 companies and individuals e-mail addresses worldwide. This award is officially announced in Madrid/Spain. Your email ID has hereby been approved alump sum pay out of (€300,000.00) Three Hundred Thousand Euros in cash credit file Ref/Eu/Email509/Eu06 Note: No ticket was sold in this prize award, winners were randomly selected from electronic online world wide. Simply contact Our Foreign Financial Office by email with the contact address below. David Belujo e-mail:microsoftiber...@kimo.com Congratulations! once again. Sincerely, Mrs Anna Maria (Dpt Sec.) -- To unsubscribe from this list: send the line "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] remotes-hg: bugfix for fetching non local remotes
On Thu, Jul 25, 2013 at 2:53 PM, Antoine Pelisse wrote:
> On Thu, Jul 25, 2013 at 9:12 PM, Felipe Contreras
> wrote:
>> Besides, I don't see
>> the point of having a '.shared/.hg' directory, and nothing else on
>> that '.shared' folder.
>
> Is it not already true about the ".git/hg/$alias/clone/" directory ?
Yeah, but that directory is kind of useful. Somebody might want to
clone that, and it's self-explanatory; "Where is the clone of that
Mercurial remote? Oh, there".
>> So, here's my patch. If only Junio read them.
>>
>> Subject: [PATCH] remote-hg: add shared repo upgrade
>>
>> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
>> making the shared repository '.git/hg', which is already used before
>> that patch, so clones that happened before that patch, fail after that
>> patch, because there's no shared Mercurial repo.
>>
>> It's trivial to upgrade to the new organization by copying the Mercurial
>> repo from one of the remotes (e.g. 'origin'), so let's do so.
>
> I agree with you that we should consider migration. But there's
> another use-case I think can fail.
> What happens with the following:
>
> git clone hg::/my/hg/repo
> cd repo && git remote add newremote hg::http://some/hg/url
>
> Git clone will create .git/hg/origin and with no hg clone (because
> it's a local repository), and then create marks-file in there.
>
>> Reported-by: Joern Hees
>> Signed-off-by: Felipe Contreras
>> ---
>> contrib/remote-helpers/git-remote-hg.py | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/contrib/remote-helpers/git-remote-hg.py
>> b/contrib/remote-helpers/git-remote-hg.py
>> index 0194c67..57a8ec4 100755
>> --- a/contrib/remote-helpers/git-remote-hg.py
>> +++ b/contrib/remote-helpers/git-remote-hg.py
>> @@ -396,6 +396,13 @@ def get_repo(url, alias):
>> hg.clone(myui, {}, url, shared_path, update=False,
>> pull=True)
>> except:
>> die('Repository error')
>> +else:
>> +# check and upgrade old organization
>> +hg_path = os.path.join(shared_path, '.hg')
>> +if not os.path.exists(hg_path):
>> +repos = os.listdir(shared_path)
>> +local_hg = os.path.join(shared_path, repos[0], 'clone',
>> '.hg')
>> +shutil.copytree(local_hg, hg_path)
>
> With the use-case I described above, I think shutil.copytree() would
> raise an exception because local_hg doesn't exist.
That's true. Maybe something like:
for x in repos:
local_hg = os.path.join(shared_path, x, 'clone', '.hg')
if os.path.exists(local_hg):
shutil.copytree(local_hg, hg_path)
break
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Faster git grep.
Ondřej Bílka writes: > One solution would be to use same trick as was done in google code. > Build and keep database of trigraphs and which files contain how many of > them. When querry is made then check > only these files that have appropriate combination of trigraphs. This depends on how you go about trying to reducing the database overhead, I think. For example, a very naive approach would be to create such trigraph hit index for each and every commit for all paths. When "git grep $commit $pattern" is run, you would consult such table with $commit and potential trigraphs derived from the $pattern to grab the potential paths your hits _might_ be in. But the contents of a path usually do not change in each and every commit. So you may want to instead index with the blob object names (i.e. which trigraphs appear in what blobs). But once you go that route, your "git grep $commit $pattern" needs to read and enumerate all the blobs that appear in $commit's tree, and see which blobs may potentially have hits. Then you would need to build an index every time you make a new commit for blobs whose trigraphs have not been counted. Nice thing is that once a blob (or a commit for that matter) is created and its object name is known, its contents will not change, so you can index once and reuse it many times. But I am not yet convinced if pre-indexing is an overall win, compared to the cost of maintaining such a database. -- To unsubscribe from this list: send the line "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] Faster git grep.
On Thu, Jul 25, 2013 at 08:29:05PM +0200, Ondřej Bílka wrote: > One solution would be to use same trick as was done in google code. > Build and keep database of trigraphs and which files contain how many of > them. When querry is made then check > only these files that have appropriate combination of trigraphs. That seems like a sensible approach. > Updating database would be relatively inexpensive compared to disk > access we need to do anyway. Yes, I think it can be quite cheap, since you would only need to re-index files that have changed (and git is very quick at telling you what those files are). > A space usage might be problem so which is why I decided go option > route. > > Comments, pointers? I think it is a good idea, but not need to be part of core git. It seems more like you would want to glue together an existing code-indexing solution (like codesearch) with git (which would provide the list of files to index and to search). If that proves useful in practice, but the interface is clunky for whatever reason, then a good follow-on project could be to build support for updating and using the index via the usual "git grep". -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] commit.h: drop redundant comment
We mention twice that the from_ident field of struct
pretty_print_context is internal.
The first comment was added by 10f2fbf, which prepares the
struct for internal fields, and then the second by a908047,
which actually adds such a field. This was a mistake made
when re-rolling the series on the list; the comment should
have been removed from the latter commit.
Signed-off-by: Jeff King
---
Not that important, really. I only bothered tracking down the source of
the error because I was curious if it was a mis-merge or something. But
nope, just me screwing up, and missing it in review.
commit.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/commit.h b/commit.h
index 35cc4e2..d912a9d 100644
--- a/commit.h
+++ b/commit.h
@@ -102,8 +102,6 @@ struct pretty_print_context {
* Fields below here are manipulated internally by pp_* functions and
* should not be counted on by callers.
*/
-
- /* Manipulated by the pp_* functions internally. */
struct string_list in_body_headers;
};
--
1.8.3.rc1.30.gff0fb75
--
To unsubscribe from this list: send the line "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] remotes-hg: bugfix for fetching non local remotes
On Thu, Jul 25, 2013 at 9:12 PM, Felipe Contreras
wrote:
> Besides, I don't see
> the point of having a '.shared/.hg' directory, and nothing else on
> that '.shared' folder.
Is it not already true about the ".git/hg/$alias/clone/" directory ?
> So, here's my patch. If only Junio read them.
>
> Subject: [PATCH] remote-hg: add shared repo upgrade
>
> 6796d49 (remote-hg: use a shared repository store) introduced a bug by
> making the shared repository '.git/hg', which is already used before
> that patch, so clones that happened before that patch, fail after that
> patch, because there's no shared Mercurial repo.
>
> It's trivial to upgrade to the new organization by copying the Mercurial
> repo from one of the remotes (e.g. 'origin'), so let's do so.
I agree with you that we should consider migration. But there's
another use-case I think can fail.
What happens with the following:
git clone hg::/my/hg/repo
cd repo && git remote add newremote hg::http://some/hg/url
Git clone will create .git/hg/origin and with no hg clone (because
it's a local repository), and then create marks-file in there.
> Reported-by: Joern Hees
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/git-remote-hg.py | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/contrib/remote-helpers/git-remote-hg.py
> b/contrib/remote-helpers/git-remote-hg.py
> index 0194c67..57a8ec4 100755
> --- a/contrib/remote-helpers/git-remote-hg.py
> +++ b/contrib/remote-helpers/git-remote-hg.py
> @@ -396,6 +396,13 @@ def get_repo(url, alias):
> hg.clone(myui, {}, url, shared_path, update=False, pull=True)
> except:
> die('Repository error')
> +else:
> +# check and upgrade old organization
> +hg_path = os.path.join(shared_path, '.hg')
> +if not os.path.exists(hg_path):
> +repos = os.listdir(shared_path)
> +local_hg = os.path.join(shared_path, repos[0], 'clone',
> '.hg')
> +shutil.copytree(local_hg, hg_path)
With the use-case I described above, I think shutil.copytree() would
raise an exception because local_hg doesn't exist.
--
To unsubscribe from this list: send the line "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] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
On Wed, Jul 24, 2013 at 8:14 AM, Antoine Pelisse wrote: > IOW, the goal is to have only one copy of each "hg object" that are > shared amongst many "remotes" (and potentially import them only once, > though I don't think it currently works for me). That's right. I had code to import only once, but it didn't work correctly; we would need a way to have shared fast-import/export marks, and I don't think it's even possible from Mercurial's API to figure out which objects are shared and which specific, so I gave up on that. Sharing the repository is the only thing we can do safely and sanely. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] remotes-hg: bugfix for fetching non local remotes
On Wed, Jul 24, 2013 at 7:42 PM, Joern Hees wrote:
> 6796d49 introduced a bug by making shared_path == ".git/hg' which
> will most likely exist already, causing a new remote never to be
> cloned and subsequently causing hg.share to fail with error msg:
> "mercurial.error.RepoError: repository .git/hg not found"
>
> Changing shared_path to ".git/hg/.shared" will solve this problem
> and create a shared local mercurial repository for non local remotes.
> The initial dot circumvents a name clash problem should a remote be
> called "shared".
>
> Signed-off-by: Joern Hees
> Mentored-by: Antoine Pelisse
> Thanks-to: Junio C Hamano
> ---
> contrib/remote-helpers/git-remote-hg | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/remote-helpers/git-remote-hg
> b/contrib/remote-helpers/git-remote-hg
> index 0194c67..f4e9d1c 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -390,7 +390,7 @@ def get_repo(url, alias):
> if not os.path.exists(dirname):
> os.makedirs(dirname)
> else:
> -shared_path = os.path.join(gitdir, 'hg')
> +shared_path = os.path.join(gitdir, 'hg', '.shared')
> if not os.path.exists(shared_path):
> try:
> hg.clone(myui, {}, url, shared_path, update=False, pull=True)
> --
> 1.8.3.4
I don't like this approach because if it's a huge repository the user
would have to clone again, not only if he was using v1.8.3, but also
if he was using the latest and greatest (because you are changing the
location again). It's relatively trivial to move from the old to the
shared organization, so that's what I vote for. Besides, I don't see
the point of having a '.shared/.hg' directory, and nothing else on
that '.shared' folder.
So, here's my patch. If only Junio read them.
Subject: [PATCH] remote-hg: add shared repo upgrade
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
It's trivial to upgrade to the new organization by copying the Mercurial
repo from one of the remotes (e.g. 'origin'), so let's do so.
Reported-by: Joern Hees
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg.py | 7 +++
1 file changed, 7 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg.py
b/contrib/remote-helpers/git-remote-hg.py
index 0194c67..57a8ec4 100755
--- a/contrib/remote-helpers/git-remote-hg.py
+++ b/contrib/remote-helpers/git-remote-hg.py
@@ -396,6 +396,13 @@ def get_repo(url, alias):
hg.clone(myui, {}, url, shared_path, update=False, pull=True)
except:
die('Repository error')
+else:
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if not os.path.exists(hg_path):
+repos = os.listdir(shared_path)
+local_hg = os.path.join(shared_path, repos[0], 'clone', '.hg')
+shutil.copytree(local_hg, hg_path)
if not os.path.exists(dirname):
os.makedirs(dirname)
--
1.8.3.3
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Faster git grep.
Hi, When I do git grep then with big codebase (gcc) it executes slowly. I am thinking to add option to speed up search time. One solution would be to use same trick as was done in google code. Build and keep database of trigraphs and which files contain how many of them. When querry is made then check only these files that have appropriate combination of trigraphs. Updating database would be relatively inexpensive compared to disk access we need to do anyway. A space usage might be problem so which is why I decided go option route. Comments, pointers? Ondra -- To unsubscribe from this list: send the line "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 and cyrillic branches
On Thu, 25 Jul 2013 18:51:57 +0400 ксовиран wrote: [...] > > I'm afraid, this might be not that simple: Git received certain > > tweaks to work around certain problems Mac OS X has (as I > > understand it) with handling UTF-8 on various filesystems it > > supports; in particular, see commits > > 76759c7dff53e8c84e975b88cb8245587c14c7ba [1] and > > b856ad623e4f686815986c0b9341dd1bfd791e71 [2] which were released as > > part of v1.7.12. [...] And while we're at it, commit message of 76759c7 tells that in order for the fixes to work, the core.precomposedunicode configuration variable has to be set to 'true'. Did you do that? Did that help? -- To unsubscribe from this list: send the line "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] web--browse: support /usr/bin/cygstart on Cygwin
"Yaakov (Cygwin/X)" writes: >>> Signed-off-by: Yaakov Selkowitz >> >> Will queue and wait for somebody from Cygwin land to comment. > > Ping? Is there someone in particular whose input you are looking for? Nobody in particular. Nobody complained nor reported breakages, so we are good to go ;-) 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 and cyrillic branches
On Thu, 25 Jul 2013 18:51:57 +0400 ксовиран wrote: [...] > > I'm afraid, this might be not that simple: Git received certain > > tweaks to work around certain problems Mac OS X has (as I > > understand it) with handling UTF-8 on various filesystems it > > supports; in particular, see commits [...] > > So... I'm not sure, but I beleive these fixes might have been > > related to handling filenames in the work tree and the index only, > > not branches, as having branches with non-ASCII names is a weird > > idea to most developers, I think. [...] > there is nothing wrong with having branches with non-ASCII names as > english is not the only language in the world. Well, this my remark was just to explain why the problem with branches which *are* files (well, unless they have become "packed refs") in the reference Git implementation, might had good chances to escape the scope of the tweaks being discussed. Of course, there's nothing wrong with non-ASCII branch names unless this impedes collaboration on a project which uses them. > problem is still here, i've got ubuntu on VM and same shared > git-folder causes this problem on Mac Os and no problems on Ubuntu. > git version on Mac is 1.8.0.1 (on Ubuntu is 1.7.10.4) I hope someone possessing the necessary knowledge will look at 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: git and cyrillic branches
On Thu, Jul 25, 2013 at 10:51 AM, ксовиран wrote: > problem is still here, i've got ubuntu on VM and same shared git-folder > causes this problem on Mac Os and no problems on Ubuntu. > git version on Mac is 1.8.0.1 (on Ubuntu is 1.7.10.4) OSX filesystem code canonicalizes UTF-8 filenames in a way that disagrees with GIT's design (and Linux's fs design) which considers a filename to be a bag of bytes better left alone. So the ugly fixes applied to filenames need to be applied too to refs, I guess. Are you using packed refs? That's probably a good workaround in the meantime. Using packed refs, git will not need to store the branchname as a filename... cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line "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 and cyrillic branches
25.07.2013, 18:28, "Konstantin Khomoutov" : > On Thu, 25 Jul 2013 17:06:41 +0400 > ксовиран wrote: > hello! there is problem vith git and cyrillic (utf-8) names of branches. branch creates perfectly, but when i clone this remote branch to local host, there are 2 bugs: 1) "git branch" doesnt show checked branch with asterisk (while on remote server it does) 2) "git push" gives 2 errors: "fatal: BRANCH_NAME cannot be resolved to branch." and "fatal: The remote end hung up unexpectedly" thanks. >>> Works for me across two Debian systems: both have Git 1.7.10.4; user >>> accounts on both systems have LANG=en_US.UTF-8 configured in their >>> environment. >>> >>> Do both of your systems (local and remote) have an UTF-8-enabled (or >>> encoding-agnostic, like "C") locale active? >> oh, yes indeed. i was pushing from mac to ubuntu, but ubuntu to >> ubuntu works fine. although #locale gives almost identical output, so >> it is something to work out. спасибо за помощь! 25.07.2013, 16:45, > > I'm afraid, this might be not that simple: Git received certain tweaks > to work around certain problems Mac OS X has (as I understand it) with > handling UTF-8 on various filesystems it supports; in particular, see > commits 76759c7dff53e8c84e975b88cb8245587c14c7ba [1] > and b856ad623e4f686815986c0b9341dd1bfd791e71 [2] which were released as > part of v1.7.12. > > So... I'm not sure, but I beleive these fixes might have been related to > handling filenames in the work tree and the index only, not branches, as > having branches with non-ASCII names is a weird idea to most > developers, I think. So the question is: do you have Git >= 1.7.12 on > your Mac OS X machine? If so, do you still experience this problem (I > think that Macs do not have non-UTF-8 locales anyway, so this is > unlikely the root cause). > > P.S. > Please don't top-post as this breaks discussion flow and hence sucks. > > 1. https://github.com/git/git/commit/76759c7 > 2. https://github.com/git/git/commit/b856ad6 there is nothing wrong with having branches with non-ASCII names as english is not the only language in the world. problem is still here, i've got ubuntu on VM and same shared git-folder causes this problem on Mac Os and no problems on Ubuntu. git version on Mac is 1.8.0.1 (on Ubuntu is 1.7.10.4) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-tag man: when to use lightweight or annotated tags
On 13-07-25 09:45 AM, Daniele Segato wrote: > From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001 > From: Daniele Segato > Date: Thu, 25 Jul 2013 15:33:18 +0200 > Subject: [PATCH] git-tag man: when to use lightweight or annotated tags > > stress the difference between the two with suggestion on when the user > should use one in place of the other. > > Signed-off-by: Daniele Segato > --- > Documentation/git-tag.txt |4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt > index 22894cb..48f5504 100644 > --- a/Documentation/git-tag.txt > +++ b/Documentation/git-tag.txt > @@ -36,6 +36,10 @@ are absent, `-a` is implied. > Otherwise just a tag reference for the SHA-1 object name of the commit > object is > created (i.e. a lightweight tag). > > +Annotated and Lightweight tags are not the same thing for git and you > shouldn't > +mix them up. Annotated tags are meant for release while lightweight tags are > +meant to tag random commits. Unfortunately the word "annotated" hasn't yet been introduced at this point, so the overall effect is even more confusing. Also, I find the "release" vs. "random" distinction a bit misleading since both types of tag can refer to any object. I also liked the direction of your earlier "command only consider annotated tags by default" phrasing. After reading the Tagging section of the Git Book[1] I came up with the following. Feel free to modify it as you like, or ignore it completely: Tag objects (created with -a) are called annotated tags. While a lightweight tag is simply a name for an object (usually a commit object), an annotated tag contains the creation date, the tagger's name and e-mail, a tagging message, and can be signed and verified with GNU Privacy Guard (GnuPG). Most git commands only consider annotated tags by default. In general lightweight tags are for private or temporary object labels, while annotated tags are meant to be permanent and/or published. For example, an annotated tag is normally used to identify a release point. M. [1] http://git-scm.com/book/en/Git-Basics-Tagging -- To unsubscribe from this list: send the line "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 and cyrillic branches
On Thu, 25 Jul 2013 17:06:41 +0400 ксовиран wrote: > >> hello! there is problem vith git and cyrillic (utf-8) names of > >> branches. branch creates perfectly, but when i clone this remote > >> branch to local host, there are 2 bugs: > >> 1) "git branch" doesnt show checked branch with asterisk (while on > >> remote server it does) > >> 2) "git push" gives 2 errors: "fatal: BRANCH_NAME cannot be > >> resolved to branch." and "fatal: The remote end hung up > >> unexpectedly" thanks. > > > > Works for me across two Debian systems: both have Git 1.7.10.4; user > > accounts on both systems have LANG=en_US.UTF-8 configured in their > > environment. > > > > Do both of your systems (local and remote) have an UTF-8-enabled (or > > encoding-agnostic, like "C") locale active? > > oh, yes indeed. i was pushing from mac to ubuntu, but ubuntu to > ubuntu works fine. although #locale gives almost identical output, so > it is something to work out. спасибо за помощь! 25.07.2013, 16:45, I'm afraid, this might be not that simple: Git received certain tweaks to work around certain problems Mac OS X has (as I understand it) with handling UTF-8 on various filesystems it supports; in particular, see commits 76759c7dff53e8c84e975b88cb8245587c14c7ba [1] and b856ad623e4f686815986c0b9341dd1bfd791e71 [2] which were released as part of v1.7.12. So... I'm not sure, but I beleive these fixes might have been related to handling filenames in the work tree and the index only, not branches, as having branches with non-ASCII names is a weird idea to most developers, I think. So the question is: do you have Git >= 1.7.12 on your Mac OS X machine? If so, do you still experience this problem (I think that Macs do not have non-UTF-8 locales anyway, so this is unlikely the root cause). P.S. Please don't top-post as this breaks discussion flow and hence sucks. 1. https://github.com/git/git/commit/76759c7 2. https://github.com/git/git/commit/b856ad6 -- To unsubscribe from this list: send the line "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 usability issue: Lightweight vs Annotated confusion for the end user (ex. git describe default)
On 07/24/2013 10:34 PM, Junio C Hamano wrote: Daniele Segato writes: Annotated and Lightweight tags are not the same thing for git and you shouldn't mix them up. Annotated tags are meant for release while lightweight tags are meant to tag random commits. Nicely explained. This is one of those "we who worked on Git (not worked "with" Git) for a long time _know_ it and do not need it to be explained, and we didn't spot that it is not explained in the documentation for new people." Good! Any change in adding an option to filter tags list by annotated only? Care to roll a documentation patch (and get a commit count for yourself ;-)? I tried, just sent the patch, hopefully I managed to follow the guide I found here: http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD As you suggested I removed the "title" line and the reference to git describe default. If I did something wrong please explain me what and I'll fix it Thanks. You're Welcome :-) Cheers, Daniele Segato -- To unsubscribe from this list: send the line "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] git-tag man: when to use lightweight or annotated tags
From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001 From: Daniele Segato Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato --- Documentation/git-tag.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..48f5504 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -36,6 +36,10 @@ are absent, `-a` is implied. Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). +Annotated and Lightweight tags are not the same thing for git and you shouldn't +mix them up. Annotated tags are meant for release while lightweight tags are +meant to tag random commits. + A GnuPG signed tag object will be created when `-s` or `-u ` is used. When `-u ` is not used, the committer identity for the current user is used to find the -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] range-set and line-log bug fixes
On Thu, Jul 25, 2013 at 5:12 AM, Johannes Sixt wrote: > Am 7/25/2013 10:03, schrieb Eric Sunshine: >> The tests in this series identify real bugs in dealing with empty >> ranges, which the subsequent patches fix. The test are possible >> because one can specify an empty range via blame/log -L, however, I >> now realize that the ability for -L to create empty ranges was never >> intended or part of the design, but is in fact itself a bug. > ... >> * Should we drop these new t4211 tests which guard against real potential >> bugs? >> >> * Should we add custom C code to the test suite to make the >> empty-range testing possible? >> >> * Should we introduce another (undocumented) loophole just for the >> sake of the tests? > > IIUC, the tests you added are protecting the *implementation* of range-set > functions. For tests of the implementation, we usually write test-foo > programs that call the functions directly. You understand correctly. The added t4211 tests check range-set and line-log functionality. range-set is an implementation detail of git-log's -L and is entirely private (static to the implementation file), so there's no API to test via a test-foo program. It is sufficiently generic that its API could (some day) be published, thus allowing a test-foo program, however, doing so would involve writing documentation and covering its entire API with tests: a large enough task in itself, and quite orthogonal to fixing the log/blame -L loophole. line-log is partially public, however, the code in which the bug was discovered is private (static) and likely always will be since it is not generic. Moreover, once the -L loophole is closed, there will be no way to trigger the case under consideration via its public API, so again there is no opportunity for a test-foo program. Thus, the question remains: What to do with these two tests once the -L loophole is closed? Remove them? > Tests invoking git should test the observable behavior. Therefore, if > calling a git utility with "-Lfoo,+0" should be an error, then the test > suite should mark such a call with test_must_fail. I guess this rules out > the loophole approach. Indeed, nicely stated. -- To unsubscribe from this list: send the line "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 and cyrillic branches
On Thu, 25 Jul 2013 15:19:48 +0300 иванов иван wrote: > hello! there is problem vith git and cyrillic (utf-8) names of > branches. branch creates perfectly, but when i clone this remote > branch to local host, there are 2 bugs: > 1) "git branch" doesnt show checked branch with asterisk (while on > remote server it does) > 2) "git push" gives 2 errors: "fatal: BRANCH_NAME cannot be resolved > to branch." and "fatal: The remote end hung up unexpectedly" thanks. Works for me across two Debian systems: both have Git 1.7.10.4; user accounts on both systems have LANG=en_US.UTF-8 configured in their environment. Do both of your systems (local and remote) have an UTF-8-enabled (or encoding-agnostic, like "C") locale active? -- To unsubscribe from this list: send the line "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 and cyrillic branches
hello! there is problem vith git and cyrillic (utf-8) names of branches. branch creates perfectly, but when i clone this remote branch to local host, there are 2 bugs: 1) "git branch" doesnt show checked branch with asterisk (while on remote server it does) 2) "git push" gives 2 errors: "fatal: BRANCH_NAME cannot be resolved to branch." and "fatal: The remote end hung up unexpectedly" 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 subtree push-all and pull-all
I agree with the idea of maintaining git-subtree outside of contrib. However, you would need the commitment of apenwarr, or whoever hosts the master repo, to merge in any pull requests or we are no further forward. (apenwarr appears not to have been active on github since early May). On Thu, Jul 25, 2013 at 11:00 AM, Herman van Rink wrote: > On 22-07-13 21:35, Paul Campbell wrote: >> >> Hi, >> >> Sorry for the delay. Not been monitoring the list lately. >> >> I'm afraid work stopped for two reasons. Lack of interest from the >> list was the main one. I understand subtree isn't used much and >> subsequently there wasn't much interest in reviewing the patches I was >> putting out. As a result I lost interest. >> > > It seems to be hard to get anything done on such a busy list. :( Especially > when the maintainers lack time/attention for such a contrib. > > I think including it in the contrib folder has not done us any good. > > Maybe we should just focus on maintaining a separate repo, which could be > based of https://github.com/apenwarr/git-subtree (which has already 92 > forks, including one of mine). And obviously integrate all the recent work > from Paul. > > > -- > > Met vriendelijke groet / Regards, > > Herman van Rink > Initfour websolutions > -- Paul [W] Campbell -- To unsubscribe from this list: send the line "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 subtree push-all and pull-all
On 22-07-13 21:35, Paul Campbell wrote: Hi, Sorry for the delay. Not been monitoring the list lately. I'm afraid work stopped for two reasons. Lack of interest from the list was the main one. I understand subtree isn't used much and subsequently there wasn't much interest in reviewing the patches I was putting out. As a result I lost interest. It seems to be hard to get anything done on such a busy list. :( Especially when the maintainers lack time/attention for such a contrib. I think including it in the contrib folder has not done us any good. Maybe we should just focus on maintaining a separate repo, which could be based of https://github.com/apenwarr/git-subtree (which has already 92 forks, including one of mine). And obviously integrate all the recent work from Paul. -- Met vriendelijke groet / Regards, Herman van Rink Initfour websolutions -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] range-set and line-log bug fixes
Am 7/25/2013 10:03, schrieb Eric Sunshine: > The tests in this series identify real bugs in dealing with empty > ranges, which the subsequent patches fix. The test are possible > because one can specify an empty range via blame/log -L, however, I > now realize that the ability for -L to create empty ranges was never > intended or part of the design, but is in fact itself a bug. ... > * Should we drop these new t4211 tests which guard against real potential > bugs? > > * Should we add custom C code to the test suite to make the > empty-range testing possible? > > * Should we introduce another (undocumented) loophole just for the > sake of the tests? IIUC, the tests you added are protecting the *implementation* of range-set functions. For tests of the implementation, we usually write test-foo programs that call the functions directly. Tests invoking git should test the observable behavior. Therefore, if calling a git utility with "-Lfoo,+0" should be an error, then the test suite should mark such a call with test_must_fail. I guess this rules out the loophole approach. -- 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
Re: [PATCH 0/5] range-set and line-log bug fixes
On Thu, Jul 25, 2013 at 4:03 AM, Eric Sunshine wrote: > I don't > really consider this a good argument in favor of -Lfoo,+0 representing > an empty range, and it's a very poor substitute for Michael Haggerty's > more expressive proposal [1]. > > [1]: > http://thread.gmane.org/gmane.comp.version-control.git/229755/focus=230967 And here's the correct link to Michael's proposal: http://thread.gmane.org/gmane.comp.version-control.git/229755/focus=229995 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] range-set and line-log bug fixes
On Tue, Jul 23, 2013 at 10:28 AM, Eric Sunshine wrote: > While implementing multiple -L support for git-blame, I encountered > several bugs in range-set and line-log resulting in crashes. This > series fixes those bugs. > > Eric Sunshine (5): > range-set: fix sort_and_merge_range_set() corner case bug > t4211: demonstrate empty -L range crash > range-set: satisfy non-empty ranges invariant > t4211: demonstrate crash when first -L encountered is empty range > line-log: fix "log -LN" crash when N is last line of file I've run into a bit of a conundrum relating to the tests added by this series, for which I could use some input. The tests in this series identify real bugs in dealing with empty ranges, which the subsequent patches fix. The test are possible because one can specify an empty range via blame/log -L, however, I now realize that the ability for -L to create empty ranges was never intended or part of the design, but is in fact itself a bug. An example manifestation of this bug, given a 5-line file: % git blame -L5 foo # OK, blames line 5 % git blame -L6 foo # accepted, no error, no output, huh? % git blame -L7 foo # error: "fatal: file foo has only 5 lines" I believe that it is correct to fix this bug (and already have a fix locally). The example -L6 should error out just like -L7 rather than creating an empty range. Fixing this bug closes the empty-range-creation loophole which is used by the t4211 tests added in this series and, unfortunately, there is no other way to create an empty range, hence no way to keep these tests operational. What to do? * Should we drop these new t4211 tests which guard against real potential bugs? * Should we add custom C code to the test suite to make the empty-range testing possible? * Should we introduce another (undocumented) loophole just for the sake of the tests? For the last point, I was considering -Lfoo,+0. It is currently undocumented and its behavior undefined. In fact, -Lfoo,+0 and -Lfoo,-0 presently are interpreted as -Lfoo,+2 (definitely undefined behavior). It would be possible to make -Lfoo,+0 mean empty-range and keep it undocumented, which would create the loophole these tests require. I personally dislike this idea for several reasons: (1) we should be closing loopholes rather than creating them intentionally; (2) generally, an empty range has no useful meaning in conjunction with -L; (3) if not an empty range, then -Lfoo,+0 conveys nothing and should be reported as an error. The only possible minor advantage I can see to interpreting -Lfoo,+0 as an empty range is that it could provide an anchor for relative -L/RE/ searches once blame accepts multiple -L options. For example, "blame -L42,+0 -L/^struct/,/^}/ foo.c" would blame the first struct starting at line 42, without also showing blame for line 42. I don't really consider this a good argument in favor of -Lfoo,+0 representing an empty range, and it's a very poor substitute for Michael Haggerty's more expressive proposal [1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/229755/focus=230967 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
