Re: [PATCH/RFC] rewrite `git_default_config()` using config-set API functions
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: In general, most strings one manipulates are const char *, it's frequent to modify a pointer to a string, but rather rare to modify the string itself. We seem to have a disagreement. Unlike git_config_get_value() that lets callers peek the only cached copy, git_config_get_string() gives its caller a new copy that the caller needs to free. Such a new string can and should be given as mutable, I would say. You're right (I guess you replied to this one before seeing my other message). imap_folder could be declared const char *, but git_config_get_string() shouldn't be the one to force this. -- 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: scan.coverity: improve the modeling file of git.git
On Sun, Jul 20, 2014 at 11:44:53PM +0200, Stefan Beller wrote: We're currently seeing lots of false positives as the xmalloc/xrealloc function is handled not properly by coverity. There are lots of errors Allocation too small for type Hmm. Actually, I think this report from coverity kind of makes sense. If you pass zero bytes to xmalloc, like: const char **foo = xmalloc(0); and your system malloc returns NULL, we convert that into a single-byte allocation, and it is the caller's responsibility not to actually dereference it. Coverity doesn't know that, and says wait, one byte isn't enough to store *foo, which is right. Most cases of this are something like: const char **foo = xmalloc(nr * sizeof(*foo)); /* do something nr times */ What coverity _should_ be able to do is realize that we only trigger this when nr is zero, and then make sure that we only dereference foo when nr is non-zero. But I guess it's not that smart (yet). As a fallback, we should be able to say xrealloc is opaque; just trust us that it will allocate the right amount, which I think is what you are getting at with the modeling file. However I have reviewed the function and I'd be pretty sure it would work as expected. According to https://scan.coverity.com/tune we can upload a modelling file, which will allow us to supress such false positive errors. I believe we'd need to put in the modelling file something like: // coverity[+alloc] void *xrealloc(void *ptr, size_t size); and that should do. We'd not need to modify the git.git sources, but just add such a declaration to the modelling file. I think that is how we would comment it in the source code. For the modeling file, we would actually provide a fake implementation of xmalloc that just calls malloc. I think you shouldn't generally need to model functions which are actually in your code base (as coverity looks across all files, not just what gets included when compiling any single one), but I assume that a model would take precedence over the real one for cases like this. Does anyone of you administrators want to experiment with that? I don't think anybody is actively submitting builds to coverity. I played with it a while ago and have meant to look again when I got more time (as there were many false positives that I figured could be removed with some modeling), but haven't gotten around to it. I'm happy to upload any model file you want, or if you want to actively work on this, I can bump you to maintainer status and you can fiddle with the project settings as necessary. -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
Dearest Beloved
I am Mrs. Susan Patrick, suffering from cancerous ailment.I want you to establish my husband money (35,000,000.00 GBP) to charity home for the upkeep of widows, widowers, orphans,destitute, the down-trodden, physically challenged children. My Doctor told me recently, that I have limited days to live due to the cancerous problems that I have been suffering from. You can contact me through my personal email Address. Please assure me that you will act just as I have stated Here in. Email: susanpatric...@qq.com Hope to hear from you soon. Remain Blessed, Mrs. Susan Patrick -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OSX packages on git-scm.com broken on previous OSX versions?
On Mon, Jul 21, 2014 at 01:08:53PM +0100, Dan Ackroyd wrote: Apologies in advance if this is the wrong place, but it looks like the OSX packages available from http://git-scm.com/download/mac are not working for at least some people including myself. As you noticed, those packages are done by the git-osx-installer project. I've cc'd Tim Harper, who runs that project (but who I don't think reads the list carefully). -Peff -- 8 -- [copious quoting of original problem below] What I'm seeing is that any call to invoke git gives an illegal instruction, crash report is below. The other people are listed at: http://sourceforge.net/p/git-osx-installer/tickets/97/ Apparently this may be a problem caused by the lack of the compile flag -mmacosx-version-min=10.5 according to: http://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10 Any chance this can be investigated and fixed please? cheers Dan Ackroyd btw I'm on OSX 10.6.8 but the other reports are on more up to date versions. Process: bash [90170] Path:/bin/bash Identifier: bash Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [89840] Date/Time: 2014-07-21 12:34:59.093 +0100 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGILL) Exception Codes: KERN_INVALID_ADDRESS at 0xfff8 Crashed Thread: Unknown Backtrace not available Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0055 rbx: 0x rcx: 0x rdx: 0x rdi: 0x rsi: 0x rbp: 0x rsp: 0x r8: 0x r9: 0x r10: 0x r11: 0x r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff5fc01028 rfl: 0x00010203 cr2: 0xfff8 Binary images description not available -- To unsubscribe from this list: send the line unsubscribe 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/4] use strbuf_getcwd() to get the current working directory without fixed-sized buffers
On Mon, Jul 21, 2014 at 07:10:13PM +0200, René Scharfe wrote: Probably. And I was so glad to have found an example case for getcwd without dying and without touching the get-there-and-back cases. :) Guess I'll have to look closer at setup.c and perhaps unix-socket.c for a replacement. I think just: const char *x = xgetcwd(); setenv(GIT_DIR_ENVIRONMENT, x, 0); free(x); would be enough? By the way: Simply setting $GIT_DIR to . probably won't work in the two cases, I guess? It might, but I'd be a little wary. For example, for the call in init_db, would we later then chdir to the working tree in order to do a checkout (since init_db is part of a clone)? Even if it works now, it seems like a bit of an accident waiting to happen. -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] config.c: change the function signature of `git_config_string()`
`git_config_string()` output parameter `dest` is declared as a const
which is unnecessary as the caller of the function is given a strduped
string which can be modified without causing any harm.
Thus, remove the const from the function signature.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
cache.h | 2 +-
config.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 92fc9f1..93d357a 100644
--- a/cache.h
+++ b/cache.h
@@ -1303,7 +1303,7 @@ extern unsigned long git_config_ulong(const char *, const
char *);
extern int git_config_bool_or_int(const char *, const char *, int *);
extern int git_config_bool(const char *, const char *);
extern int git_config_maybe_bool(const char *, const char *);
-extern int git_config_string(const char **, const char *, const char *);
+extern int git_config_string(char **, const char *, const char *);
extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set_in_file(const char *, const char *, const char *);
extern int git_config_set(const char *, const char *);
diff --git a/config.c b/config.c
index ba882a1..25e28a7 100644
--- a/config.c
+++ b/config.c
@@ -633,7 +633,7 @@ int git_config_bool(const char *name, const char *value)
return !!git_config_bool_or_int(name, value, discard);
}
-int git_config_string(const char **dest, const char *var, const char *value)
+int git_config_string(char **dest, const char *var, const char *value)
{
if (!value)
return config_error_nonbool(var);
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config.c: change the function signature of `git_config_string()`
On Tue, Jul 22, 2014 at 03:49:56AM -0700, Tanay Abhra wrote: `git_config_string()` output parameter `dest` is declared as a const which is unnecessary as the caller of the function is given a strduped string which can be modified without causing any harm. Thus, remove the const from the function signature. You are correct that it is unnecessary. However, this patch alone is not sufficient because of the way const-ness in C works. If I have: static const char *some_global; then with your patch, calling: git_config_string(some_global, var, value); will complain that we are passing a pointer to const char *, not a pointer to char *. And indeed, compiling with your patch introduces a ton of compiler warnings. We would have to convert each of the variables we pass to it to: static char *some_global; That's not so bad, but: static char *some_global = some_default_value; is wrong. Such a global sometimes points to const storage (i.e., initially), and sometimes to allocated storage (if it was loaded from config). We simply keep the latter as a const pointer (since we would not bother to free it at the end of the program anyway), and that decision influences git_config_string, which is just a helper for setting such variables anyway. So I would not mind lifting this unnecessary restriction on git_config_string, but I do not see a way to do it without making the rest of the code much uglier (and I do not see a particular advantage in modifying git_config_string here that would make it worth the trouble). -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 v3 6/6] notes-util.c: replace `git_config()` with `git_config_get_value()`
On Mon, Jul 21, 2014 at 04:12:25AM -0700, Tanay Abhra wrote:
-static int notes_rewrite_config(const char *k, const char *v, void *cb)
+static void notes_rewrite_config(struct notes_rewrite_cfg *c)
{
- struct notes_rewrite_cfg *c = cb;
- if (starts_with(k, notes.rewrite.) !strcmp(k+14, c-cmd)) {
- c-enabled = git_config_bool(k, v);
- return 0;
- } else if (!c-mode_from_env !strcmp(k, notes.rewritemode)) {
+ const char *v;
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(key, notes.rewrite.%s, c-cmd);
+ git_config_get_bool(key.buf, c-enabled);
+ strbuf_release(key);
I wonder if it is worth teaching the accessors to form such strings
themselves, like:
void git_config_get_bool(int *out, const char *fmt, ...);
so you could do:
git_config_get_bool(c-enabled, notes.rewrite.%s, c-cmd);
The normal cases where we do not need any run-time modification could
be used as-is (I swapped the parameter order above, but you would not
have to do so). But I guess that would require us doing extra work in
the common normal case to print the string into a buffer, even though
it does not have any expansions (or to do a strchr, I guess, to look for
%). It's probably not worth it considering how few config keys have
computed values like this.
-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] config.c: change the function signature of `git_config_string()`
On 7/22/2014 4:37 PM, Jeff King wrote: On Tue, Jul 22, 2014 at 03:49:56AM -0700, Tanay Abhra wrote: `git_config_string()` output parameter `dest` is declared as a const which is unnecessary as the caller of the function is given a strduped string which can be modified without causing any harm. Thus, remove the const from the function signature. You are correct that it is unnecessary. However, this patch alone is not sufficient because of the way const-ness in C works. If I have: static const char *some_global; then with your patch, calling: git_config_string(some_global, var, value); will complain that we are passing a pointer to const char *, not a pointer to char *. And indeed, compiling with your patch introduces a ton of compiler warnings. I had also thought that the compiler would raise lot of warnings but it didn't on the first compile. Now I checked again and now it complains a lot, maybe it because I was tinkering with my config.mak, dunno. We would have to convert each of the variables we pass to it to: static char *some_global; That's not so bad, but: static char *some_global = some_default_value; is wrong. Such a global sometimes points to const storage (i.e., initially), and sometimes to allocated storage (if it was loaded from config). We simply keep the latter as a const pointer (since we would not bother to free it at the end of the program anyway), and that decision influences git_config_string, which is just a helper for setting such variables anyway. So I would not mind lifting this unnecessary restriction on git_config_string, but I do not see a way to do it without making the rest of the code much uglier (and I do not see a particular advantage in modifying git_config_string here that would make it worth the trouble). Yes, you are right. This patch is the conclusion of discussion in [1]. I used the same function signature as git_config_string for git_config_get_string() which lead to some ugly casts like +git_config_get_string(imap.folder, (const char**)imap_folder); in imap-send.c patch and others. What should we do about such cases, I used either an intermediate variable or casts but Junio commented that it would be better if the dest parameter was a non-const and that it was a weakness of the config-set API that demanded the dest to be a const pointer. [1]: http://thread.gmane.org/gmane.comp.version-control.git/253948/ -- To unsubscribe from this list: send the line unsubscribe 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] config.c: change the function signature of `git_config_string()`
Jeff King p...@peff.net writes: will complain that we are passing a pointer to const char *, not a pointer to char *. And indeed, compiling with your patch introduces a ton of compiler warnings. Tanay: are you not compiling with gcc -Wall -Werror? (see my earlier message, just create a file config.mak containing CFLAGS += -Wdeclaration-after-statement -Wall -Werror ) We would have to convert each of the variables we pass to it to: static char *some_global; OK, it seems I got convinced too quickly by Junio ;-). The function produces a char * that can be modified, but it also receives a value, and the function should keep the const to allow passing const char *. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config.c: change the function signature of `git_config_string()`
On 7/22/2014 5:14 PM, Matthieu Moy wrote: Jeff King p...@peff.net writes: will complain that we are passing a pointer to const char *, not a pointer to char *. And indeed, compiling with your patch introduces a ton of compiler warnings. Tanay: are you not compiling with gcc -Wall -Werror? (see my earlier message, just create a file config.mak containing CFLAGS += -Wdeclaration-after-statement -Wall -Werror ) Yes, I was. Dunno why it didn't work 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: [PATCH] config.c: change the function signature of `git_config_string()`
Matthieu Moy matthieu@grenoble-inp.fr writes: OK, it seems I got convinced too quickly by Junio ;-). The function produces a char * that can be modified, but it also receives a value, and the function should keep the const to allow passing const char *. Don't blame me. I never suggested to touch that existing function, with existing call sites. -- To unsubscribe from this list: send the line unsubscribe 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] config.c: change the function signature of `git_config_string()`
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: OK, it seems I got convinced too quickly by Junio ;-). The function produces a char * that can be modified, but it also receives a value, and the function should keep the const to allow passing const char *. Don't blame me. I never suggested to touch that existing function, with existing call sites. I don't understand what you mean. The new git_config_get_string() function is meant to be used in essentially every places where git_config_string() is currently used, so removing the const from git_config_get_string() raises the same issue as changing the existing function. Dropping the const means we won't be able to write const char *v = default; ... git_config_get_string(v, ...); -- 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: inotify support, nearly there
On Sun, Jul 20, 2014 at 10:10 PM, Juan P juandavid1...@gmail.com wrote: Duy Nguyen pclouds at gmail.com writes: Just a quick update for the enthusiasts. My branch file-watcher [1] has got working per-user inotify support. It's a 20 patch series so I'll refrain from spamming git at vger for a while, even though it hurts your eyes a lot less than what I have posted so far. The test suite ran fine with it so it's not that buggy. It has new tests too, even though real inotify is not tested in the new tests. Documentation is there, either in .txt or comments. Using it is simple: $ mkdir ~/.watcher $ git file-watcher --detach ~/.watcher $ git config --global filewatcher.path $HOME/.watcher Will this mean that Git would work faster with repositories with large number of files or commits? I am new into this topic, but I am trying to understand, any pointers are appreciated. That is the idea. Instead of having to recursively lstat() every file to find which ones have changed this will allow to query a database for tell me all files that match this criteria xyz which could speed up many things. Duy, keep up the good work. Once you are ready I am more than happy to help out reviewing the patches. regards ronnie sahlberg -- To unsubscribe from this list: send the line unsubscribe 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 + mod_auth_kerb
Hello, Thanks for this info. This make a lot of sense system wise. For a user point of view, it is a nightmare. Also, this break a lot of tools that are waiting username/password authentication via HTTPS. (I name Eclipse). Also, I m not able to reproduce the kerberos login on Ubuntu 14.04. I m asked to enter password even if a kerberos ticket is present and this even when I've embedded the username in the URI. Is there a better way to integrate Kerberos via HTTPS for git ? Thanks, JF On Mon, Jul 21, 2014 at 7:17 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jul 21, 2014 at 05:06:50PM -0400, Jean-Francois Bouchard wrote: Hello, We are currently working on a single sign on setup for our git install. We are using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the server side. Here some scenario we are trying to accomplish : -Without Kerberos ticket stored. Git ask for username/password. Result = Authentication failed -Kerberos ticket in store and BAD password : Git ask for username/password. Result = Authentication failed -Kerberos ticket in Store entering good password : Git ask for username/password. Result = Authentication failed on some host, other works -Kerberos ticket in Store and embedding the username in the URI (aka https://username@repo) Git don't ask for anything or ask for password Result = Works on some host, other request the password. (Will fail if the kerberos ticket not in store) So git uses libcurl with CURLAUTH_ANY. In order for authentication to work with libcurl, you have to supply a username. If you specify it in the URL, the libcurl realizes that it can use Kerberos, and goes on its merry way. If you don't specify the username in the URL, git notices that authentication has failed, and asks the credential store for a username and password. git does not know that a password is not needed, so the credential subsystem prompts for one anyway. I have mod_auth_kerb set up against Apache 2.4.9 at the moment, although I've used 2.2 before. I always use a username in the URL, and if I get prompted for the password, I just Ctrl-C out and run kinit before pushing again. I don't have mod_auth_kerb set up to fall back to basic auth, but if you do, using a username and password should work properly. You can use set the environment variable GIT_CURL_VERBOSE to 1 to see more information about what's actually going over the wire. This is a very strange behaviour. It seems to be cause by the way libcurl and git interact and the way the authentication goes (Negociate first, then basic auth). I have tried to use the helper to store invalid authentication information. With not much success. libcurl will always prefer something (anything) over basic auth, since basic auth is completely insecure unless you're using HTTPS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- Avis de confidentialité Les informations contenues dans le présent message et dans toute pièce qui lui est jointe sont confidentielles et peuvent être protégées par le secret professionnel. Ces informations sont à l’usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il vous plait communiquer immédiatement avec l’expéditeur et en détruire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you. -- To unsubscribe from this list: send the line unsubscribe 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] config.c: change the function signature of `git_config_string()`
Jeff King p...@peff.net writes: So I would not mind lifting this unnecessary restriction on git_config_string, but I do not see a way to do it without making the rest of the code much uglier (and I do not see a particular advantage in modifying git_config_string here that would make it worth the trouble). I do not think changing the existing one is warranted, either. Given that C's type system does not allow us to pass const char * as char * without cast (and vice versa), a function that takes an out parameter that points at the location to store the pointer to a string (instead of returning the pointer to a string as value) has to take either one of these forms: get_mutable(char **dest); get_const(const char **dest); and half the callers need to pass their variables with a cast, i.e. char *mutable_string; const char *const_string; get_mutable((char **)const_string); get_mutable(mutable_string); get_const(const_string); get_const((const char **)mutable_string); If we have to cast some [*1*], I'd prefer to see the type describe what it really is, and I think a function that gives a newly allocated storage for the callers' own use is better described by taking a pointer to non-const char * location. So I'd encourage a new function being introduced that does not have existing callers to use that as the criterion to decide which to take. Changing the existing function with existing calling site needs two other pros-and-cons evaluation, in addition to the above does the type describe what it really is?, which are is it worth the churn? and does the end result make more sense than the original? [Footnote] *1* We have safe_create_leading_directories_const() that works around this for input parameter around its _const less counterpart, which is ugly but livable solution. -- To unsubscribe from this list: send the line unsubscribe 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 + mod_auth_kerb
brian m. carlson sand...@crustytoothpaste.net writes: So git uses libcurl with CURLAUTH_ANY. In order for authentication to work with libcurl, you have to supply a username. If you specify it in the URL, the libcurl realizes that it can use Kerberos, and goes on its merry way. If you don't specify the username in the URL, git notices that authentication has failed, and asks the credential store for a username and password. git does not know that a password is not needed, so the credential subsystem prompts for one anyway. Hmmm, does this hint that we might want to be able to tell the credential subsystem that it is sufficient to have name without password, or allow the credential subsystem to say I am giving you sufficient information when it returns only username without password? -- To unsubscribe from this list: send the line unsubscribe 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 v10] tag: support configuring --sort via .gitconfig
On Wed, 2014-07-16 at 14:48 -0700, Jacob Keller wrote: Add support for configuring default sort ordering for git tags. Command line option will override this configured value, using the exact same syntax. Cc: Jeff King p...@peff.net Signed-off-by: Jacob Keller jacob.e.kel...@intel.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Just a ping on the status of this patch? Thanks, Jake
Re: [PATCH v10] tag: support configuring --sort via .gitconfig
Keller, Jacob E jacob.e.kel...@intel.com writes: Just a ping on the status of this patch? I wrote that v10 needs to be picked up in the last What's cooking, I think I did so already and pushed out the result somewhere between 'master' and 'pu'. -- To unsubscribe from this list: send the line unsubscribe 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 02/12] wrapper.c: add a new function unlink_or_msg
On Fri, Jul 18, 2014 at 3:59 PM, Junio C Hamano gits...@pobox.com wrote:
Hmm, the primary reason for this seems to be because you are going to handle
multiple refs at a time, some of them might fail to lock due to this
lowest-level
helper to unlink failing, some others may fail to lock due to some other
reason,
and the user may want to be able to differentiate various modes of failure.
But even if that were the case, would it be necessary to buffer the messages
like this and give them all at the end? In the transaction code path,
it is likely
that you would be aborting the whole thing at the first failure, no?
Not necessarily.
I can think of reasons both for and against abort on first failure.
One reason for the former could be if there are problems with multiple
refs in a single transaction.
It would be very annoying to have to do
$ git some command
error: ref foo has a problem
$ run command to fix the problem
$ git some sommand (try again)
error: ref bar has a problem
...
And it might be more userfriendly if that instead would be
$ git some command
error: ref foo has a problem
error: ref bar has a problem
...
And get all the failures in one go instead of having to iterate.
The reason for the latter I think is it would be cleaner/simpler/...
to just have an abort on first failure.
On the past discussions on the list I think I have heard voices for
both approaches.
I don't think we have all that many
multiple-refs-in-a-single-transaction yet in what is checked in so far
so I think we are practically still abort on first error.
I personally do not know yet which approach is the best but would like
to keep the door open for the try all and fail at the end.
That said, I do not feel all that strongly about this.
If you have strong feelings about this I can remove the unlink_or_msg
patch and rework the rest of the series to cope with it.
regards
ronnie sahlberg
I dunno...
On Fri, Jul 18, 2014 at 3:25 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
git-compat-util.h | 6 ++
wrapper.c | 18 ++
2 files changed, 24 insertions(+)
diff --git a/git-compat-util.h b/git-compat-util.h
index b6f03b3..426bc98 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -704,12 +704,18 @@ void git_qsort(void *base, size_t nmemb, size_t size,
#endif
#endif
+#include strbuf.h
+
/*
* Preserves errno, prints a message, but gives no warning for ENOENT.
* Always returns the return value of unlink(2).
*/
int unlink_or_warn(const char *path);
/*
+ * Like unlink_or_warn but populates a strbuf
+ */
+int unlink_or_msg(const char *file, struct strbuf *err);
+/*
* Likewise for rmdir(2).
*/
int rmdir_or_warn(const char *path);
diff --git a/wrapper.c b/wrapper.c
index 740e193..74a0cc0 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -438,6 +438,24 @@ static int warn_if_unremovable(const char *op, const
char *file, int rc)
return rc;
}
+int unlink_or_msg(const char *file, struct strbuf *err)
+{
+ if (err) {
+ int rc = unlink(file);
+ int save_errno = errno;
+
+ if (rc 0 errno != ENOENT) {
+ strbuf_addf(err, unable to unlink %s: %s,
+ file, strerror(errno));
+ errno = save_errno;
+ return -1;
+ }
+ return 0;
+ }
+
+ return unlink_or_warn(file);
+}
In general, I do not generally like to see messages propagated
upwards from deeper levels of the callchain to the callers to be
used later, primarily because that will easily make it harder to
localize the message-lego.
For this partcular one, shouldn't the caller be doing
if (unlink(file) errno != ENOENT) {
... do its own error message ...
}
instead of calling any of the unlink_or_whatever() helper?
int unlink_or_warn(const char *file)
{
return warn_if_unremovable(unlink, file, unlink(file));
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] wrapper.c: add a new function unlink_or_msg
Ronnie Sahlberg sahlb...@google.com writes: One reason for the former could be if there are problems with multiple refs in a single transaction. It would be very annoying to have to do $ git some command error: ref foo has a problem $ run command to fix the problem $ git some sommand (try again) error: ref bar has a problem ... And it might be more userfriendly if that instead would be $ git some command error: ref foo has a problem error: ref bar has a problem ... And get all the failures in one go instead of having to iterate. ... I personally do not know yet which approach is the best but would like to keep the door open for the try all and fail at the end. Yes, and often it is useful (e.g. we allow to push multiple and then show the result for individual refs). But that still does not show a need for accumulating the error messages to strbuf, does 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 05/12] refs.c: pass NULL as *flags to read_ref_full
On Fri, Jul 18, 2014 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
We call read_ref_full with a pointer to flags from rename_ref but since
we never actually use the returned flags we can just pass NULL here instead.
Sensible, at least for the current callers. I had to wonder if
rename_ref() would never want to take advantage of the flags return
parameter in the future, though. For example, would it want to act
differently when the given ref turns out to be a symref?
I don't know.
We have a check if the old refname was a symref or not since the old
version did not have code for how to handle renaming the reflog.
(That check is removed in a later series when we have enough
transaction code and reflog api changes so that we no longer need to
call rename() for the reflog handling.)
I can not think of any reason right now why, but if we need it we can
add the argument back when the need arises.
Would it
want to report something when the ref to be overwritten was a broken
one?
Good point.
There are two cases where the new ref could be broken.
1) It could either contain a broken SHA1, like if we do this :
$ echo Broken ref .git/refs/heads/foo-broken-1
2) or it could be broken due to having a bad/invalid name :
$ cp .git.refs.heads.master .git/refs/heads/foo-broken-1-\*...
For 2) I think this should not be allowed so the rename should just
fail with something like :
$ ./git branch -M foo foo-broken-1-\*...
fatal: 'foo-broken-1-*...' is not a valid branch name.
For 1) if the new branch already exists but it has a broken SHA1, for
that case I think we should allow rename_ref to overwrite the existing
bad SHA1 with the new, good, SHA1 value.
Currently this does not work in master :
$ echo Broken ref .git/refs/heads/foo-broken-1
$ ./git branch -m foo foo-broken-1
error: unable to resolve reference refs/heads/foo-broken-1: Invalid argument
error: unable to lock refs/heads/foo-broken-1 for update
fatal: Branch rename failed
And the only way to recover is to first delete the branch as my other
patch in this series now allows and then trying the rename again.
For 1), since we are planning to overwrite the current branch with a
new SHA1 value, I think that what makes most sense would be to treat
the branch exist but is broken as if the branch did not exist at all
and just allow overwriting it with the new good value.
Currently this does not work in master :
$ echo Broken ref .git/refs/heads/foo-broken-1
$ ./git branch -m foo foo-broken-1
error: unable to resolve reference refs/heads/foo-broken-1: Invalid argument
error: unable to lock refs/heads/foo-broken-1 for update
fatal: Branch rename failed
so since this is not a regression I will not update this particular
patch series but instead I
can add a new patch to the next patch series to allow this so that we can do :
$ echo Broken ref .git/refs/heads/foo-broken-1
$ ./git branch -m foo foo-broken-1
success
Comments/opinions?
regards
ronnie sahlberg
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 7d65253..0df6894 100644
--- a/refs.c
+++ b/refs.c
@@ -2666,7 +2666,7 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
goto rollback;
}
- if (!read_ref_full(newrefname, sha1, 1, flag)
+ if (!read_ref_full(newrefname, sha1, 1, NULL)
delete_ref(newrefname, sha1, REF_NODEREF)) {
if (errno==EISDIR) {
if (remove_empty_directories(git_path(%s,
newrefname))) {
--
To unsubscribe from this list: send the line 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 3/3] completion: complete `git push --force-with-lease=`
Signed-off-by: John Keeping j...@keeping.me.uk
---
contrib/completion/git-completion.bash | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 33a4962..293868a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1621,6 +1621,22 @@ _git_pull ()
__git_push_recurse_submodules=check on-demand
+__git_complete_force_with_lease ()
+{
+ local cur_=$1
+
+ case $cur_ in
+ --*=)
+ ;;
+ *:*)
+ __gitcomp_nl $(__git_refs) ${cur_#*:}
+ ;;
+ *)
+ __gitcomp_nl $(__git_refs) $cur_
+ ;;
+ esac
+}
+
_git_push ()
{
case $prev in
@@ -1633,6 +1649,10 @@ _git_push ()
return
esac
case $cur in
+ --force-with-lease=*)
+ __git_complete_force_with_lease ${cur##--force-with-lease=}
+ return
+ ;;
--repo=*)
__gitcomp_nl $(__git_remotes) ${cur##--repo=}
return
@@ -1646,7 +1666,7 @@ _git_push ()
--all --mirror --tags --dry-run --force --verbose
--quiet --prune --delete --follow-tags
--receive-pack= --repo= --set-upstream
- --recurse-submodules=
+ --force-with-lease --force-with-lease=
--recurse-submodules=
return
;;
--
2.0.1.472.g6f92e5f.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
[PATCH v2 1/3] completion: complete unstuck `git push --recurse-submodules`
Since the argument to `--recurse-submodules` is mandatory, it does not
need to be stuck to the option with `=`.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Change since v1:
- Fix typo --recurse{_ = -}submodules
- Dropped previous patch 1/4 adding ;; at the end of the --repo case
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7a6e1d7..bed3665 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1624,6 +1624,10 @@ __git_push_recurse_submodules=check on-demand
_git_push ()
{
case $prev in
+ --recurse-submodules)
+ __gitcomp $__git_push_recurse_submodules
+ return
+ ;;
--repo)
__gitcomp_nl $(__git_remotes)
return
--
2.0.1.472.g6f92e5f.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
[PATCH v2 2/3] completion: add some missing options to `git push`
Signed-off-by: John Keeping j...@keeping.me.uk --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index bed3665..33a4962 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1644,6 +1644,7 @@ _git_push () --*) __gitcomp --all --mirror --tags --dry-run --force --verbose + --quiet --prune --delete --follow-tags --receive-pack= --repo= --set-upstream --recurse-submodules= -- 2.0.1.472.g6f92e5f.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
[BUG] git merge-file mismerge
Consider these three files: $ printf %s\n A B C D ours $ printf %s\n A C B D common $ printf %s\n A B D theirs Starting from A C B D, our side flips the order of the second (C) and the third (B), while their side removes the second (C). The correct three-way content level merge should notice conflict during this merge, but git merge-file that uses xdiff/xmerge.c, which is meant to be equivalent to merge from the RCS suite, declares that our version is already the correct merge result: $ merge ours common theirs merge: warning: conflicts during merge $ cat ours A ours B C === B theirs D $ printf %s\n A B C D ours ;# revert it back $ git merge-file ours common theirs ; echo $? 0 $ cat ours A B C D -- To unsubscribe from this list: send the line unsubscribe 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/4] completion: add missing terminator in case statement
On Mon, Jul 21, 2014 at 01:09:13PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: John Keeping j...@keeping.me.uk writes: Signed-off-by: John Keeping j...@keeping.me.uk --- As these ;; are separators not terminators, this is not strictly necessary. Squashing it into a change that adds more case arms to this case statement is of course not just good but necessary, though. s/necessary/may be /; if you add new arms before this one, you won't need it. But if you add one after this, you would ;-). Hmm... POSIX describes them as terminators :-) The compound-list for each list of patterns, with the possible exception of the last, shall be terminated with ;;. Although, bash.info is inaccurate here (clearly Bash does implement the POSIX behaviour otherwise the existing code wouldn't work): Each clause must be terminated with `;;', `;', or `;;'. The WORD undergoes tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal before matching is attempted. Each PATTERN undergoes tilde expansion, parameter expansion, command substitution, and arithmetic expansion. There may be an arbitrary number of `case' clauses, each terminated by a `;;', `;', or `;;'. The first pattern that matches determines the command-list that is executed. I'll drop this patch in the re-roll since it isn't necessary. contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 7a6e1d7..d0b2895 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1627,6 +1627,7 @@ _git_push () --repo) __gitcomp_nl $(__git_remotes) return + ;; esac case $cur in --repo=*) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in get_pwd_cwd() in Windows?
Am 21.07.2014 16:13, schrieb Duy Nguyen: This function tests if $PWD is the same as getcwd() using st_dev and st_ino. But on Windows these fields are always zero (mingw.c:do_lstat). If cwd is moved away, I think falling back to $PWD is wrong. I don't understand the use of $PWD in the first place. 1b9a946 (Use nonrelative paths instead of absolute paths for cloned repositories - 2008-06-05) does not explain much. The commit message reads: Particularly for the alternates file, if one will be created, we want a path that doesn't depend on the current directory, but we want to retain any symlinks in the path as given and any in the user's view of the current directory when the path was given. The intent of the patch seems to be to prefer $PWD if it points to the same directory as the one returned by getcwd() in order to preserve the user's view. That's why it introduces make_nonrelative_path() (now called absolute_path()), in contrast to make_absolute_path() (now called real_path()). I imagine it's useful e.g. if your home is accessed through a symlink: /home/foo - /some/boring/mountpoint Then real_path(bar) would give you /some/boring/mountpoint/bar, while absolute_path(bar) returned /home/foo/bar. Not resolving symlinks keeps the path friendly in this case. And it keeps working even after the user's home is migrated to /a/bigger/partition and /home/foo is updated accordingly. René -- To unsubscribe from this list: send the line unsubscribe 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/4] completion: add missing terminator in case statement
John Keeping j...@keeping.me.uk writes: On Mon, Jul 21, 2014 at 01:09:13PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: John Keeping j...@keeping.me.uk writes: Signed-off-by: John Keeping j...@keeping.me.uk --- As these ;; are separators not terminators, this is not strictly necessary. Squashing it into a change that adds more case arms to this case statement is of course not just good but necessary, though. s/necessary/may be /; if you add new arms before this one, you won't need it. But if you add one after this, you would ;-). Hmm... POSIX describes them as terminators :-) The compound-list for each list of patterns, with the possible exception of the last, shall be terminated with ;;. A terminator that is optional at the end is a separator ;-). Having ';;' immediately before 'esac' is not wrong, but omitting it is exactly equally correct as having one, so it is not something we would want a patch to churn. I'll drop this patch in the re-roll since it isn't necessary. This round looked good from a cursory read, except that the first one still makes me wonder why you chose to put it there _before_ where we handle --repo, where the corresponding case on $cur handles --repo= first and then --recurse-submodules= next. Wouldn't the end result easier to follow if you stuck to the same order? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] completion: complete unstuck `git push --recurse-submodules`
John Keeping j...@keeping.me.uk writes:
Since the argument to `--recurse-submodules` is mandatory, it does not
need to be stuck to the option with `=`.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Change since v1:
- Fix typo --recurse{_ = -}submodules
- Dropped previous patch 1/4 adding ;; at the end of the --repo case
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7a6e1d7..bed3665 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1624,6 +1624,10 @@ __git_push_recurse_submodules=check on-demand
_git_push ()
{
case $prev in
+ --recurse-submodules)
+ __gitcomp $__git_push_recurse_submodules
+ return
+ ;;
--repo)
__gitcomp_nl $(__git_remotes)
return
If you mimick the order they are handled in the case on $cur, it
would also let us sneak in the missing-optional ;; to case/esac to
keep symmetry between the two ;-)
In other words, like this, perhaps?
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 019026e..b27f385 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1617,6 +1617,11 @@ _git_push ()
--repo)
__gitcomp_nl $(__git_remotes)
return
+ ;;
+ --recurse-submodules)
+ __gitcomp $__git_push_recurse_submodules
+ return
+ ;;
esac
case $cur in
--repo=*)
--
2.0.2-892-g223db29
--
To unsubscribe from this list: send the line unsubscribe 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 12/12] refs.c: fix handling of badly named refs
Ronnie Sahlberg sahlb...@google.com writes: We currently do not handle badly named refs well : $ cp .git/refs/heads/master .git/refs/heads/master.@\*@\\. $ git branch fatal: Reference has invalid format: 'refs/heads/master.@*@\.' $ git branch -D master.@\*@\\. error: branch 'master.@*@\.' not found. But we can not really recover from a badly named ref with less than manually deleting the .git/refs/heads/refname file. Change resolve_ref_unsafe to take a flags field instead of a 'reading' boolean and update all callers that used a non-zero value for reading to pass the flag RESOLVE_REF_READING instead. Add another flag RESOLVE_REF_ALLOW_BAD_NAME that will make resolve_ref_unsafe skip checking the refname for sanity and use this from branch.c so that we will be able to call resolve_ref_unsafe on such refs when trying to delete it. Makes sense. Add checks for refname sanity when updating (not deleting) a ref in ref_transaction_update and in ref_transaction_create to make the transaction fail if an attempt is made to create/update a badly named ref. Since all ref changes will later go through the transaction layer this means we no longer need to check for and fail for bad refnames in lock_ref_sha1_basic. Change lock_ref_sha1_basic to not fail for bad refnames. Just check the refname, and print an error, and remember that the refname is bad so that we can skip calling verify_lock(). This is somewhat puzzling, though. @@ -2180,6 +2196,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname, else unable_to_lock_index_die(ref_file, errno); } + if (bad_refname) + return lock; Hmph. If the only offence was that the ref was named badly due to historically loose code, does the caller not still benefit from the verify-lock check to make sure that other people did not muck with the ref while we were planning to update it? return old_sha1 ? verify_lock(lock, old_sha1, mustexist) : lock; error_return: -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
.gitignore and git stash -u
We had been experiencing random deletions of files and directories, and we finally figured out what they were: git stash -u. A coworker happened upon a webpage (after losing a weeks worth of experimental work, back to his last backup), which described our problems exactly: http://blog.icefusion.co.uk/git-stash-can-delete-ignored-files-git-stash-u/ The command git stash -u deletes ignored files from the hard drive.. very dangerous! Which leads me to my first question: Why does git stash -u delete these files but a checkout doesn't? It seems inconsistent. We have the following in .gitignore, which is directly related to the problems we're having (please note, we're using git on Windows, in case that makes a syntax difference): */**/* ![Ss][Rr][Cc]/**/* So what that does is ignores every file and subdirectory at the top level, and then un-ignores Src/ and all files/dirs under that (we have a few more that we unignore). The reason behind this is we have files that are generated in the same tree as the source code, and unfortunately it is infeasible to change that design. So, if someone creates Data and puts their own custom configuration file it in, it doesn't contaminate the repository. However, if course they don't want to lose their configuration file either. My understanding from the linked page is that our problem is having the /* at the end which causes the files to be ignored and not the directories themselves. However, I couldn't seem to find a combination without the trailing /* that duplicated the functionality we had, but that prevented git stash from deleting our files. Can anyone provide me with one? This is what I am really after. I have come up with an inelegant workaround. If I add this line to .gitignore: !Data/.placeholder And then commit an empty .placeholder file, it seems to fix the deletion problem. After that, we can place all sorts of untracked files and sub-directories and they don't get deleted during a stash. I guess it's because that tracked file keeps the directory alive in some fashion, but I am not sure I understand why the sub-directories are not deleted though, can anyone enlighten me on that? I would have expected to have to put a .placeholder file in every sub-directory under Data to prevent them from getting deleted too (because of the ** in the .gitignore line). Another thing we were considering is modifying git itself to provide a command-line option not to delete ignored files during a stash. Can someone point me to the appropriate file? Thanks a lot, Jeff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] completion: complete unstuck `git push --recurse-submodules`
On Tue, Jul 22, 2014 at 01:23:25PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Since the argument to `--recurse-submodules` is mandatory, it does not
need to be stuck to the option with `=`.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Change since v1:
- Fix typo --recurse{_ = -}submodules
- Dropped previous patch 1/4 adding ;; at the end of the --repo case
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7a6e1d7..bed3665 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1624,6 +1624,10 @@ __git_push_recurse_submodules=check on-demand
_git_push ()
{
case $prev in
+ --recurse-submodules)
+ __gitcomp $__git_push_recurse_submodules
+ return
+ ;;
--repo)
__gitcomp_nl $(__git_remotes)
return
If you mimick the order they are handled in the case on $cur, it
would also let us sneak in the missing-optional ;; to case/esac to
keep symmetry between the two ;-)
In other words, like this, perhaps?
Makes sense. I don't think I noted the order in the $cur case, I just
put the new one in here so that they were sorted lexicographically.
Do you want me to re-roll with this change or can you replace the patch
while applying?
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 019026e..b27f385 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1617,6 +1617,11 @@ _git_push ()
--repo)
__gitcomp_nl $(__git_remotes)
return
+ ;;
+ --recurse-submodules)
+ __gitcomp $__git_push_recurse_submodules
+ return
+ ;;
esac
case $cur in
--repo=*)
--
2.0.2-892-g223db29
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Two gitweb bugs related to javascript-actions
Hi
Some time ago I reported the two following bugs to Debian BTS,
could you please look at them?
1. http://bugs.debian.org/741883 -- gitweb blame does not work
correctly when $feature{'javascript-actions'} is enabled
This should be one-line change fix, which I really would like to be
applied to the git package itself, not to do the same change over and
over again every time my gitweb package is updated on my system.
2. https://bugs.debian.org/741884 feature{'javascript-actions'} breaks
external links
This might be more challenging, but the simplest approach would be avoid
adding those strange '[#?]js=1' parts to non-gitweb-generated links.
Thanks a lot,
robert
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] completion: complete unstuck `git push --recurse-submodules`
John Keeping j...@keeping.me.uk writes: Makes sense. I don't think I noted the order in the $cur case, I just put the new one in here so that they were sorted lexicographically. Unless there is particular reason, consistently using lexicographic order in all related places is one good way to organize things, but doing so would involve flipping orders in the other case statement for this particular patch. In general, I prefer to see people add new things at the end, when there is no particular reason to do otherwise. Do you want me to re-roll with this change or can you replace the patch while applying? I think I had to flip the third one to adjust to the change I suggested to this; the result will be on 'pu', so please double check when I push it out. 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: .gitignore and git stash -u
Jeffry Johnston j...@kidsquid.com writes: We had been experiencing random deletions of files and directories, and we finally figured out what they were: git stash -u. A coworker happened upon a webpage (after losing a weeks worth of experimental work, back to his last backup), which described our problems exactly: http://blog.icefusion.co.uk/git-stash-can-delete-ignored-files-git-stash-u/ The command git stash -u deletes ignored files from the hard drive.. very dangerous! Although I never use stash --include-untracked myself, I think it is deliberate that the command removes all the untracked files. The author of that feature explains its use this way: commit 787513027a7d0af3c2cd2f04b85bc7136d580586 Author: David Caldwell da...@porkrind.org Date: Fri Jun 24 17:56:06 2011 -0700 stash: Add --include-untracked option to stash and remove all untracked files The --include-untracked option acts like the normal git stash save but also adds all untracked files in the working directory to the stash and then calls git clean --force --quiet to restore the working directory to a pristine state. This is useful for projects that need to run release scripts. With this option, the release scripts can be from the main working directory so one does not have to maintain a clean directory in parallel just for releasing. Basically the work-flow becomes: $ git tag release-1.0 $ git stash --include-untracked $ make release $ git clean -f $ git stash pop git stash alone is not enough in this case--it leaves untracked files lying around that might mess up a release process that expects everything to be very clean or might let a release succeed that should actually fail (due to a new source file being created that hasn't been committed yet). Signed-off-by: David Caldwell da...@porkrind.org Signed-off-by: Junio C Hamano gits...@pobox.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 12/12] refs.c: fix handling of badly named refs
On Tue, Jul 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com writes: We currently do not handle badly named refs well : $ cp .git/refs/heads/master .git/refs/heads/master.@\*@\\. $ git branch fatal: Reference has invalid format: 'refs/heads/master.@*@\.' $ git branch -D master.@\*@\\. error: branch 'master.@*@\.' not found. But we can not really recover from a badly named ref with less than manually deleting the .git/refs/heads/refname file. Change resolve_ref_unsafe to take a flags field instead of a 'reading' boolean and update all callers that used a non-zero value for reading to pass the flag RESOLVE_REF_READING instead. Add another flag RESOLVE_REF_ALLOW_BAD_NAME that will make resolve_ref_unsafe skip checking the refname for sanity and use this from branch.c so that we will be able to call resolve_ref_unsafe on such refs when trying to delete it. Makes sense. Add checks for refname sanity when updating (not deleting) a ref in ref_transaction_update and in ref_transaction_create to make the transaction fail if an attempt is made to create/update a badly named ref. Since all ref changes will later go through the transaction layer this means we no longer need to check for and fail for bad refnames in lock_ref_sha1_basic. Change lock_ref_sha1_basic to not fail for bad refnames. Just check the refname, and print an error, and remember that the refname is bad so that we can skip calling verify_lock(). This is somewhat puzzling, though. @@ -2180,6 +2196,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname, else unable_to_lock_index_die(ref_file, errno); } + if (bad_refname) + return lock; Hmph. If the only offence was that the ref was named badly due to historically loose code, does the caller not still benefit from the verify-lock check to make sure that other people did not muck with the ref while we were planning to update it? I don't think we need to do that. That would imply that we would need to be able to also allow reading the content of a badly named ref. Currently a badly named ref can not be accessed by any function except git branch -D badlynamedref which contains the special flag that allows locking it eventhough the ref has an illegal name. So no one else should be able to read or modify the ref at all. I think it is sufficient for this case to just have the semantics just delete it, I don't care what it used to point to. for this special case git branch -D badrefname so therefore since it is not the content of the ref but the name of the ref itself we have a problem with I don't think we need to read the old value or verify 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 12/12] refs.c: fix handling of badly named refs
On Tue, Jul 22, 2014 at 2:30 PM, Ronnie Sahlberg sahlb...@google.com wrote: On Tue, Jul 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com writes: We currently do not handle badly named refs well : $ cp .git/refs/heads/master .git/refs/heads/master.@\*@\\. $ git branch fatal: Reference has invalid format: 'refs/heads/master.@*@\.' $ git branch -D master.@\*@\\. error: branch 'master.@*@\.' not found. But we can not really recover from a badly named ref with less than manually deleting the .git/refs/heads/refname file. Change resolve_ref_unsafe to take a flags field instead of a 'reading' boolean and update all callers that used a non-zero value for reading to pass the flag RESOLVE_REF_READING instead. Add another flag RESOLVE_REF_ALLOW_BAD_NAME that will make resolve_ref_unsafe skip checking the refname for sanity and use this from branch.c so that we will be able to call resolve_ref_unsafe on such refs when trying to delete it. Makes sense. Add checks for refname sanity when updating (not deleting) a ref in ref_transaction_update and in ref_transaction_create to make the transaction fail if an attempt is made to create/update a badly named ref. Since all ref changes will later go through the transaction layer this means we no longer need to check for and fail for bad refnames in lock_ref_sha1_basic. Change lock_ref_sha1_basic to not fail for bad refnames. Just check the refname, and print an error, and remember that the refname is bad so that we can skip calling verify_lock(). This is somewhat puzzling, though. @@ -2180,6 +2196,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname, else unable_to_lock_index_die(ref_file, errno); } + if (bad_refname) + return lock; Hmph. If the only offence was that the ref was named badly due to historically loose code, does the caller not still benefit from the verify-lock check to make sure that other people did not muck with the ref while we were planning to update it? I don't think we need to do that. That would imply that we would need to be able to also allow reading the content of a badly named ref. Currently a badly named ref can not be accessed by any function except git branch -D badlynamedref which contains the special flag that allows locking it eventhough the ref has an illegal name. So no one else should be able to read or modify the ref at all. I think it is sufficient for this case to just have the semantics just delete it, I don't care what it used to point to. for this special case git branch -D badrefname so therefore since it is not the content of the ref but the name of the ref itself we have a problem with I don't think we need to read the old value or verify it. It is also that prior to this change we could not access these badly named refs at all. This change tries to be careful to not open up too much as it tries to only allow git branch -D and nothing else to start working for such refs. (To avoid accidentally opening things up so that it becomes possible to start using/depending on such refs) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] git clean deletes excluded files in untracked directories
Jeff King p...@peff.net writes: If you have an untracked directory that contains excluded files, like this: mkdir foo echo content foo/one echo content foo/two echo foo/one .gitignore then git clean -d will notice that foo is untracked and recursively delete it and its contents, including the ignored foo/one. Hmph, starting from an empty repository and doing the above four commands, and git clean without -d does not bother removing either foo/one or foo/two. Is this correct? It gets worse. Following the above four commands and then these two: foo/three git add foo/two and git clean (with or without -d) suddenly notices that foo/three is expendable, but not foo/one nor foo/two, which sounds about right. Honestly, as I do not use git clean myself, I do not know what the right behaviour is for that command. Anything it does seems just arbitrary and wrong to me ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] refs.c: pass NULL as *flags to read_ref_full
On Tue, Jul 22, 2014 at 11:19 AM, Ronnie Sahlberg sahlb...@google.com wrote: On Fri, Jul 18, 2014 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com writes: We call read_ref_full with a pointer to flags from rename_ref but since we never actually use the returned flags we can just pass NULL here instead. Sensible, at least for the current callers. I had to wonder if rename_ref() would never want to take advantage of the flags return parameter in the future, though. For example, would it want to act differently when the given ref turns out to be a symref? I don't know. We have a check if the old refname was a symref or not since the old version did not have code for how to handle renaming the reflog. (That check is removed in a later series when we have enough transaction code and reflog api changes so that we no longer need to call rename() for the reflog handling.) I can not think of any reason right now why, but if we need it we can add the argument back when the need arises. Would it want to report something when the ref to be overwritten was a broken one? Good point. There are two cases where the new ref could be broken. 1) It could either contain a broken SHA1, like if we do this : $ echo Broken ref .git/refs/heads/foo-broken-1 2) or it could be broken due to having a bad/invalid name : $ cp .git.refs.heads.master .git/refs/heads/foo-broken-1-\*... For 2) I think this should not be allowed so the rename should just fail with something like : $ ./git branch -M foo foo-broken-1-\*... fatal: 'foo-broken-1-*...' is not a valid branch name. For 1) if the new branch already exists but it has a broken SHA1, for that case I think we should allow rename_ref to overwrite the existing bad SHA1 with the new, good, SHA1 value. Currently this does not work in master : $ echo Broken ref .git/refs/heads/foo-broken-1 $ ./git branch -m foo foo-broken-1 error: unable to resolve reference refs/heads/foo-broken-1: Invalid argument error: unable to lock refs/heads/foo-broken-1 for update fatal: Branch rename failed And the only way to recover is to first delete the branch as my other patch in this series now allows and then trying the rename again. For 1), since we are planning to overwrite the current branch with a new SHA1 value, I think that what makes most sense would be to treat the branch exist but is broken as if the branch did not exist at all and just allow overwriting it with the new good value. Currently this does not work in master : $ echo Broken ref .git/refs/heads/foo-broken-1 $ ./git branch -m foo foo-broken-1 error: unable to resolve reference refs/heads/foo-broken-1: Invalid argument error: unable to lock refs/heads/foo-broken-1 for update fatal: Branch rename failed so since this is not a regression I will not update this particular patch series but instead I can add a new patch to the next patch series to allow this so that we can do : $ echo Broken ref .git/refs/heads/foo-broken-1 $ ./git branch -m foo foo-broken-1 success I have a patch to make it possible to delete a broken ref that can not be resolved in : https://github.com/rsahlberg/git/commit/763ab16e1874d58a4fc5c37920abc1ea40ccd814 This patch is scheduled at the end of the next patch series (use transactions for all reflog updates) I plan to send out tomorrow. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jul 2014, #04; Tue, 22)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We would need to start slowing down to prepare for -rc0 preview at the end of this week and then feature freeze. Some topics that joined 'next' late may want to stay there for the remainder of this cycle. Many of the accumulated fixes have been flushed to 'maint' and Git 2.0.2 has been tagged. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * ak/profile-feedback-build (2014-07-08) 4 commits (merged to 'next' on 2014-07-14 at c40e86e) + Fix profile feedback with -jN and add profile-fast + Run the perf test suite for profile feedback too + Don't define away __attribute__ on gcc + Use BASIC_FLAGS for profile feedback The support for the profile-feedback build, which has been left bit-rotten for quite a while, has been updated. * cc/for-each-mergetag (2014-07-07) 1 commit (merged to 'next' on 2014-07-15 at c5dd3ee) + commit: add for_each_mergetag() (this branch is used by cc/replace-graft.) * ek/alt-odb-entry-fix (2014-07-15) 1 commit (merged to 'next' on 2014-07-17 at a5f43e2) + sha1_file: do not add own object directory as alternate * jk/alloc-commit-id (2014-07-13) 8 commits (merged to 'next' on 2014-07-16 at f14c01a) + diff-tree: avoid lookup_unknown_object + object_as_type: set commit index + alloc: factor out commit index + add object_as_type helper for casting objects + parse_object_buffer: do not set object type + move setting of object-type to alloc_* functions + alloc: write out allocator definitions + alloc.c: remove the alloc_raw_commit_node() function Make sure all in-core commit objects are assigned a unique number so that they can be annotated using the commit-slab API. * jk/remote-curl-squelch-extra-errors (2014-07-10) 3 commits (merged to 'next' on 2014-07-14 at a2efa2f) + remote-curl: mark helper-protocol errors more clearly + remote-curl: use error instead of fprintf(stderr) + remote-curl: do not complain on EOF from parent git Show HTTP transfer errors from remote-curl helper more clearly to help avoid user confusion. * jl/submodule-tests (2014-07-14) 14 commits (merged to 'next' on 2014-07-14 at 0c750bb) + revert: add t3513 for submodule updates + stash: add t3906 for submodule updates + am: add t4255 for submodule updates + cherry-pick: add t3512 for submodule updates + pull: add t5572 for submodule updates + rebase: add t3426 for submodule updates + merge: add t7613 for submodule updates + bisect: add t6041 for submodule updates + reset: add t7112 for submodule updates + read-tree: add t1013 for submodule updates + apply: add t4137 for submodule updates + checkout: call the new submodule update test framework + submodules: add the lib-submodule-update.sh test library + test-lib: add test_dir_is_empty() * kb/avoid-fchmod-for-now (2014-07-16) 1 commit (merged to 'next' on 2014-07-17 at fc26c4b) + config: use chmod() instead of fchmod() Replace the only two uses of fchmod() with chmod() because the former does not work on Windows port and because luckily we can. * kb/hashmap-updates (2014-07-07) 4 commits (merged to 'next' on 2014-07-15 at 6dd6611) + hashmap: add string interning API + hashmap: add simplified hashmap_get_from_hash() API + hashmap: improve struct hashmap member documentation + hashmap: factor out getting a hash code from a SHA1 * kb/perf-trace (2014-07-13) 17 commits (merged to 'next' on 2014-07-15 at 09ade08) + api-trace.txt: add trace API documentation + progress: simplify performance measurement by using getnanotime() + wt-status: simplify performance measurement by using getnanotime() + git: add performance tracing for git's main() function to debug scripts + trace: add trace_performance facility to debug performance issues + trace: add high resolution timer function to debug performance issues + trace: add 'file:line' to all trace output + trace: move code around, in preparation to file:line output + trace: add current timestamp to all trace output + trace: disable additional trace output for unit tests + trace: add infrastructure to augment trace output with additional info + sha1_file: change GIT_TRACE_PACK_ACCESS logging to use trace API + Documentation/git.txt: improve documentation of 'GIT_TRACE*' variables + trace: improve trace performance + trace: remove redundant printf format attribute + trace: consistently name the format parameter + trace: move trace declarations from cache.h to new trace.h Show timestamps in GIT_TRACE output. * nd/path-max-must-go (2014-07-14) 3 commits (merged to 'next' on 2014-07-15 at ce68dde) + prep_exclude: remove the artificial PATH_MAX limit + dir.h: move struct exclude declaration to
Re: [PATCH 12/12] refs.c: fix handling of badly named refs
Ronnie Sahlberg sahlb...@google.com writes: I don't think we need to do that. That would imply that we would need to be able to also allow reading the content of a badly named ref. Currently a badly named ref can not be accessed by any function except git branch -D badlynamedref which contains the special flag that allows locking it eventhough the ref has an illegal name. So no one else should be able to read or modify the ref at all. OK. I think it is sufficient for this case to just have the semantics just delete it, I don't care what it used to point to. for this special case git branch -D badrefname so therefore since it is not the content of the ref but the name of the ref itself we have a problem with I don't think we need to read the old value or verify 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: [RFH] git clean deletes excluded files in untracked directories
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: If you have an untracked directory that contains excluded files, like this: mkdir foo echo content foo/one echo content foo/two echo foo/one .gitignore then git clean -d will notice that foo is untracked and recursively delete it and its contents, including the ignored foo/one. Hmph, starting from an empty repository and doing the above four commands, and git clean without -d does not bother removing either foo/one or foo/two. Is this correct? It gets worse. Following the above four commands and then these two: foo/three git add foo/two and git clean (with or without -d) suddenly notices that foo/three is expendable, but not foo/one nor foo/two, which sounds about right. Honestly, as I do not use git clean myself, I do not know what the right behaviour is for that command. Anything it does seems just arbitrary and wrong to me ;-) Having said that... Let's play my usual I do not know what I am doing because I do not use it myself, but instead of leaving the mess other people created that may harm users, let's try to clean it up, and the first step for that is to clarify what is wrong about it, and what, if anything, could be a more sensible behaviour. git clean with or without -d in my two-command added to your four-command example notices .gitignore and foo/three are to be cleaned, and further with -x makes foo/one eligible for removal. I think these are all sensible. git clean without -d in your four-command example says .gitignore is untracked and can be cleaned, but is foo/two that is not tracked fundamentally different from .gitignore? The only difference I can see is one is at the top-level while the other is not. What bad things could happen if we remove foo/two with or without -d, making -d a no-op? I know -d talks about untracked directory, but notice that with your four-command example, there is no git add; there is no difference between the top-level and foo/ in tracked-ness, so it is a meaningless distinction. I could be pursuaded to buy a proposal to make -d almost no-op except that a directory that becomes empty after running git clean [-x] is rmdir(2)'ed and without -d the empty directory is kept. Would such a pair of changes bring some sanity to the command? No matter what we do, I suspect that people expect various combinations of options to git clean has some parallel to ls-files -o with various combinations of options, to allow them to list paths that will be cleaned with ls-files, store them away, and then run clean, or something, so any fix would involve updating ls-files in a way consistent with the updated behaviour of clean. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inotify support, nearly there
On Tue, Jul 22, 2014 at 11:39 PM, Ronnie Sahlberg sahlb...@google.com wrote: Duy, keep up the good work. Once you are ready I am more than happy to help out reviewing the patches. The road I'm taking is: 1) split-index to speed up index writing time 2) add index-helper daemon to speed up index reading time 3) speed up .gitignore processing by caching the results and validate using directory stat info 4) make sure 3) works (e.g. index extension data..) with another source than directory stat info, like inotify 5) finally put inotify in place to kill lstat in index refresh and .gitignore 1) is entering next (or master) now. I need to submit 2) again and get Windows guys' opinion (up to 3 it should work on Windows). As you can see it'll like take a lot more months to get to 5). I feel a bit guilty of blocking David Turner's inotify support series, which does not require so many changes like this (but only benefits *nix), because I _think_ this road is better. If you have time, maybe you can have a look at his series and push it forward? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git + mod_auth_kerb
On Tue, Jul 22, 2014 at 10:00:22AM -0700, Junio C Hamano wrote: brian m. carlson sand...@crustytoothpaste.net writes: So git uses libcurl with CURLAUTH_ANY. In order for authentication to work with libcurl, you have to supply a username. If you specify it in the URL, the libcurl realizes that it can use Kerberos, and goes on its merry way. If you don't specify the username in the URL, git notices that authentication has failed, and asks the credential store for a username and password. git does not know that a password is not needed, so the credential subsystem prompts for one anyway. Hmmm, does this hint that we might want to be able to tell the credential subsystem that it is sufficient to have name without password, or allow the credential subsystem to say I am giving you sufficient information when it returns only username without password? Possibly. In the --negotiate documentation of the curl man page, it says: When using this option, you must also provide a fake -u, --user option to activate the authentication code properly. Sending a '-u :' is enough as the user name and password from the -u option aren't actually used. That implies to me that setting an empty value for CURLOPT_USERNAME in git might be sufficient to solve the problem. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH v2] Documentation: fix missing text for rev-parse --verify
The caret (^) is used as a markup symbol in AsciiDoc. Due to the
inability of AsciiDoc to parse a line containing an unmatched caret, it
omitted the line from the output, resulting in the man page missing the
end of a sentence. The rest of the documentation uses backticks
whenever a caret is encountered in running text, so do the same here.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 9bd76a5..074030f 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -102,7 +102,7 @@ eval set -- $(git rev-parse --sq --prefix $prefix $@)
+
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
-you require, you can add ^{type} peeling operator to the parameter.
+you require, you can add `^{type}` peeling operator to the parameter.
For example, `git rev-parse $VAR^{commit}` will make sure `$VAR`
names an existing object that is a commit-ish (i.e. a commit, or an
annotated tag that points at a commit). To make sure that `$VAR`
--
2.0.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 v2] Documentation: fix missing text for rev-parse --verify
brian m. carlson wrote: Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- Documentation/git-rev-parse.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks again for catching and fixing it. Reviewed-by: Jonathan Nieder jrnie...@gmail.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/RFC] git-svn: New flag to add a file in empty directories
Any idea why this parameter would slow down a clone so severely? I am experiencing clone slowdown by 5x+ after adding this parameter, which is not cool given the size of the repository and the urgency of finishing the migration. -- View this message in context: http://git.661346.n2.nabble.com/PATCH-RFC-git-svn-New-flag-to-add-a-file-in-empty-directories-tp6375393p7615634.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git + mod_auth_kerb
On Tue, Jul 22, 2014 at 12:41:19PM -0400, Jean-Francois Bouchard wrote: Thanks for this info. This make a lot of sense system wise. For a user point of view, it is a nightmare. Also, this break a lot of tools that are waiting username/password authentication via HTTPS. (I name Eclipse). What you may want to do is have each user adjust their .gitconfig to do something like: [url https://b...@git.crustytoothpaste.net/;] insteadOf = https://git.crustytoothpaste.net/ That way, everyone can continue to use the same URLs, but have git fix them up per-user. Hopefully I'll get some time this week to see if making HTTPS requests provide an empty username by default will work. Also, I m not able to reproduce the kerberos login on Ubuntu 14.04. I m asked to enter password even if a kerberos ticket is present and this even when I've embedded the username in the URI. This sounds like an issue with Kerberos and curl on Ubuntu 14.04. I'm using Debian unstable (from which Ubuntu pulls changes), and at no point have I had this problem. Can you send us the output of the push with the environment GIT_CURL_VERBOSE set to 1 on a system where it works and one where it doesn't? Is there a better way to integrate Kerberos via HTTPS for git ? I don't know of any better way. It does work for me, although I'm just one person. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Fuck this piece of shit software
-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
confused about remote branch management
My local master branch is the result of a merge of upstream master and some local changes. I want to merge in more recent upstream work. git pull doesn't seem to have updated origin/master, and git checkout origin/master also doesn't seem to work. Here's some info that may be relevant. ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git remote -v origin https://github.com/emacs-ess/ESS.git (fetch) origin https://github.com/emacs-ess/ESS.git (push) personalhttps://github.com/RossBoylan/ESS.git (fetch) personalhttps://github.com/RossBoylan/ESS.git (push) # I think I originally cloned from what is now the personal remote # and switched names later so origin refers to upstream. ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -v * master 8fa569c [ahead 340] merge from origin # 340 ahead of personal is plausible, but ahead from origin seems odd ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version git version 1.7.10.4 ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -a * master remotes/origin/S+eldoc remotes/origin/gretl remotes/origin/linewise_callbacks remotes/origin/litprog remotes/origin/master remotes/origin/transmissions remotes/personal/HEAD - personal/master remotes/personal/S+eldoc remotes/personal/gretl remotes/personal/linewise_callbacks remotes/personal/litprog remotes/personal/master remotes/personal/transmissions ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status # On branch master # Your branch is ahead of 'personal/master' by 340 commits. # nothing to commit (working directory clean) ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout origin/master Note: checking out 'origin/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at a33a2f9... Merge branch 'trunk' ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout master Previous HEAD position was a33a2f9... Merge branch 'trunk' Switched to branch 'master' ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git pull origin master # [messages] Not committing merge; use 'git commit' to complete the merge. ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status # On branch master # Changes to be committed: # [long list] ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master commit a33a2f9e06185a225af7d72ea3896cfd260e455e Merge: 136742f 6b22a88 Author: Vitalie Spinu spinu...@gmail.com Date: Mon Jan 20 00:43:30 2014 -0800 Merge branch 'trunk' # this was the head of origin/master BEFORE I did the pull. # I think this means it has not been updated. ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git commit -m merge in upstream, probably fe7d609..8fa569c [master 59f6841] merge in upstream, probably fe7d609..8fa569c ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master -v # no change -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Same last name 8.15 am
Dear. Friend, I am Vice Chairman, Board of Directors Hang Seng Bank Hong Kong. Dr.Raymond Chien; A deceased client of mine, that shares the same last name as yours, Died without a next of kin. $16,M in my Branch. Contact Email: drhraymo...@yahoo.com.hk Regards, Dr Raymond. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 11/31] $GIT_COMMON_DIR: a new environment variable
On Sun, Jul 13, 2014 at 12:50 AM, Nguyễn Thái Ngọc Duy
pclo...@gmail.com wrote:
This variable is intended to support multiple working directories
attached to a repository. Such a repository may have a main working
directory, created by either git init or git clone and one or more
linked working directories. These working directories and the main
repository share the same repository directory.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index 17d2ea6..7629e38 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -133,6 +138,11 @@ being a symref to point at the current branch. Such a
state
is often called 'detached HEAD.' See linkgit:git-checkout[1]
for details.
+config::
+ Repository specific configuration file. This file is ignored
s/ignored/ignored if/
+ $GIT_COMMON_DIR is set and $GIT_COMMON_DIR/config will be
+ used instead.
+
branches::
A slightly deprecated way to store shorthands to be used
to specify a URL to 'git fetch', 'git pull' and 'git push'.
diff --git a/environment.c b/environment.c
index fee12a6..6b74f68 100644
--- a/environment.c
+++ b/environment.c
@@ -149,9 +149,18 @@ static void setup_git_env(void)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
gitfile = read_gitfile(git_dir);
git_dir = xstrdup(gitfile ? gitfile : git_dir);
- git_object_dir = git_path_from_env(DB_ENVIRONMENT, objects,
git_db_env);
- git_index_file = git_path_from_env(INDEX_ENVIRONMENT, index,
git_index_env);
- git_graft_file = git_path_from_env(GRAFT_ENVIRONMENT, info/grafts,
git_graft_env);
+ git_common_dir = getenv(GIT_COMMON_DIR_ENVIRONMENT);
+ if (git_common_dir) {
+ git_common_dir_env = 1;
+ git_common_dir = xstrdup(git_common_dir);
+ } else
+ git_common_dir = git_dir;
+ git_object_dir = git_path_from_env(DB_ENVIRONMENT, git_common_dir,
+ objects, git_db_env);
+ git_index_file = git_path_from_env(INDEX_ENVIRONMENT, git_dir,
+ index, git_index_env);
+ git_graft_file = git_path_from_env(GRAFT_ENVIRONMENT, git_dir,
+ info/grafts, git_graft_env);
Replacement refs come from git_common_dir, but grafts come from
git_dir. Is the inconsistency intentional?
if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
check_replace_refs = 0;
namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
diff --git a/path.c b/path.c
index 3deb80c..8a6586c 100644
--- a/path.c
+++ b/path.c
@@ -90,6 +90,38 @@ static void replace_dir(struct strbuf *buf, int len, const
char *newdir)
buf-buf[newlen] = '/';
}
+static const char *common_list[] = {
+ /branches, /hooks, /info, /logs, /lost-found, /modules,
+ /objects, /refs, /remotes, /rr-cache, /svn,
+ config, gc.pid, packed-refs, shallow,
+ NULL
+};
+
+static void update_common_dir(struct strbuf *buf, int git_dir_len)
+{
+ char *base = buf-buf + git_dir_len;
+ const char **p;
+
+ if (is_dir_file(base, logs, HEAD))
+ return; /* keep this in $GIT_DIR */
+ for (p = common_list; *p; p++) {
+ const char *path = *p;
+ int is_dir = 0;
+ if (*path == '/') {
+ path++;
+ is_dir = 1;
+ }
+ if (is_dir dir_prefix(base, path)) {
+ replace_dir(buf, git_dir_len, get_git_common_dir());
+ return;
+ }
+ if (!is_dir !strcmp(base, path)) {
+ replace_dir(buf, git_dir_len, get_git_common_dir());
+ return;
+ }
The bodies of these two conditionals are identical. Would it make
sense to combine them (or does a later patch take advantage of the
distinction)?
if ((is_dir dir_prefix(base, path)) ||
(!is_dir !strcmp(base, path))) {
replace_dir(buf, git_dir_len, get_git_common_dir());
return;
}
+ }
+}
+
static void adjust_git_path(struct strbuf *buf, int git_dir_len)
{
const char *base = buf-buf + git_dir_len;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
