Re: [PATCH 7/7] rebase: implement --[no-]autostash and rebase.autostash
Ramkumar Ramachandra artag...@gmail.com writes:
+finish_rebase () {
+ if test -f $state_dir/autostash
+ then
+ stash_sha1=$(cat $state_dir/autostash)
+ if git stash apply $stash_sha1 21 /dev/null
+ then
+ echo Applied autostash
+ else
+ ref_stash=refs/stash
+ : $GIT_DIR/logs/$ref_stash
+ git update-ref -m autostash $ref_stash $stash_sha1 \
+ || die $(eval_gettext 'Cannot store
$stash_sha1')
Writing it like this:
ref_stash=refs/stash
: $GIT_DIR/logs/$ref_stash
git update-ref -m autostash $ref_stash $stash_sha1 ||
die $(eval_gettext 'Cannot store $stash_sha1')
with a blank line before the next echo, it would be more readable.
As I said in a separate message, having a code that knows where
stash is and how it is organized outside the implementation of
git stash is less than ideal. It probably makes more sense to
let programs like this to say:
git stash store -m autostash $stash_sha1 || exit
+ echo
+$(gettext 'Applying autostash resulted in conflicts.
+Your changes are safe in the stash.
+You can apply or drop it at any time.')
This feels funny. Why not
gettext $msg
without an extra command substitution with an echo?
--
To unsubscribe from this list: send the line 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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
On Mon, May 13, 2013 at 6:56 AM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: The refname_expand() function no longer uses mkpath()/mksnpath() to perform the pattern expansion. Instead, it uses strbuf_expand(), which removes the need for using fixed-length buffers from the code. It is a brilliant idea to use strbuf_expand() for this. I like it. I notice that you later introduce %1 (that is 'one', not 'el'), but unless you are planning to introduce %2 and %3 that semantically fall into a similar category as %1, I would rather see a different letter used that is mnemonic to what the placeholder _means_. The choice of the letter is arbitrary and may not look like it matters that much, because it is not exposed to the end user. But by switching from the sprintf() semantics that shows things given to it in the order they were given, without knowing what they mean, and introducing a strbuf_expand() machinery tailored for refnames (and refnames only), the new code assigns meanings to each part of the refname, and we can afford to be more descriptive. The choice of '%*' is justifiable, it is the closest to the '*' we traditionally used to replace only one thing, but '%1' does not look the best placeholder to use, at least to me. Obviously, I named it '%1' since it expands into the _first_ component of the (slash-separated) shorthand. There is no further parsing or verification that it actually corresponds to a remote (and as far as I currently understand, we do not want to do such verification), so I thought it better not to make such assumptions in the placeholder name. That said, I could go with '%r' for remote, although we have plenty of other concepts in Git that use 'r' as the initial letter. I could maybe use '%remote' instead? Also, about the '%*': When used alone, it means the entire shorthand, but when preceded with a '%1' it subtly changes meaning into 'the remainder of the shorthand after extracting the first component'. I believe the two interpretations are compatible and unambiguous, but if we want to be very explicit about what's happening, we could use something like '%all' and '%the_rest' for the two cases, respectively? ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/10] remote: Reject remote names containing '/'
On Mon, May 13, 2013 at 6:54 AM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: Although we definitely support and encourage use of multi-level branch names, we have never conciously tried to give support for multi-level remote names. Currently, they are allowed, but there is no evidence that they are commonly used. Now, they do provide a source of problems when trying to expand the $nick/$name shorthand notation (where $nick matches a remote name) into a full refname. Consider the shorthand foo/bar/baz: Does this parse as $nick = foo, $name = bar/baz, or $nick = foo/bar, $name = baz? Since we need to be unambiguous about these things, we hereby declare that a remote name shall never contain a '/' character, and that the only correct way to parse foo/bar/baz is $nick = foo, $name = bar/baz. I know I am guilty of hinting to go in this direction in the earlier discussion, but I have to wonder how much more refactoring is needed to see if there is only one unique possibility among many. For a string with N slashes, you have only N possible ways to split it into $nick and $name, and if you see a ref bar/baz copied from remote foo but no ref baz copied from remote foo/bar (or you may not even have a remote foo/bar in the first place), the user is already very unambiguous. The declaration is merely being lazy. I am not saying we must implement such a back-track to disambiguate the user input better. I am wondering how much more effort on top of this series is needed if we want to get there (provided that the disambiguation is a good thing to do in the first place). I feel the problem with multi-level remote names runs a little deeper than merely disambiguation when resolving remote-tracking refs: If you have two remotes foo and foo/bar, and they have branches bar/baz and baz, respectively, then they will (in the default current configuration) end up clobbering eachother due to the overlapping remote-tracking branch (refs/remotes/foo/bar/baz). Although the remote ref namespace coincidentally resolves this by mapping the two to refs/peers/foo/heads/bar/baz and refs/peers/foo/bar/heads/baz respectively, you can easily create a different (although probably even more unlikely) case where the remote ref namespace causes the same kind of overlap: One remote foo with branch heads/bar, and another remote foo/heads with branch bar will both end up clobbering eachother at refs/peers/foo/heads/heads/bar... The disambiguation can probably be resolved, although the resulting code will obviously be somewhat more cumbersome and ugly (and IMHO the current code is plenty of that already...). Combine this with the problems of clobbering of the same remote-tracking ref (describe above), and the fact that AFAIK a multi-level remote name has never been observed in the wild (none of the people I asked at the Git Merge conference had ever observed multi-level remote names, nor did they directly oppose banning them), I'm not at all sure it's worth bothering about this at all. Simply disallowing multi-level remote names seems like the simpler and naturally ambiguity-resistant approach. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 10/10] branch: Fix display of remote branches in refs/peers/*
On Mon, May 13, 2013 at 7:19 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sat, May 11, 2013 at 12:21 PM, Johan Herland jo...@herland.net wrote: +* When displaying more then just remote-tracking branches, make the s/then/than/ Thanks, will fix. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/10] interactive git clean
Jiang Xin worldhello@gmail.com writes: My initial intention for flags toggle is for git newbies, who are not clear about how to use -x/-d/-X/-ff options. I feel it may have values for these people. It may have value for some of them, but throwing too many options in a menu is usually counter-productive for a newbie. I never heard anyone say Git is super newbie-friendly because it has so many commands, but quite often the opposite. -- 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 v7 03/10] Add colors to interactive git-clean
Jiang Xin worldhello@gmail.com writes:
2013/5/13 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
* color.interactive.slot: Use customized color for interactive
git-clean output (like git add --interactive). slot may be
prompt, header, help or error.
This should go to the documentation (a short summary is welcome in the
commit messages in addition, but users won't read this...)
+ if (!prefixcmp(var, color.interactive.)) {
+ int slot = parse_clean_color_slot(var, 18);
For readability and maintainability: please use
strlen(color.interactive.), not 18.
Feel like conventional:
git grep -C2 prefixcmp builtin/apply.c builtin/archive.c
builtin/branch.c builtin/checkout.c
I know there are already many instances of this in the code, but I don't
think it's a good idea to add even more.
--
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
[PATCH v3 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8
Mac OS X Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the Common Digest SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a COMMON_DIGEST_SHA1 option to the Makefile to allow choosing this implementation and define it by default on Darwin. Define COMMON_DIGEST_FOR_SHA1 to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: David Aguilar dav...@gmail.com --- Here's a replacement patch for what's in pu. This version uses the built-in #defines and can thus avoid touching cache.h. Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 25282b4..9d174b9 100644 --- a/Makefile +++ b/Makefile @@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin) endif endif COMMON_DIGEST_HMAC = YesPlease + COMMON_DIGEST_SHA1 = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1390,10 +1391,15 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_SHA1 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_SHA1=1 + SHA1_HEADER = CommonCrypto/CommonDigest.h +else SHA1_HEADER = openssl/sha.h EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif ifdef COMMON_DIGEST_HMAC BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC=1 -- 1.8.3.rc1.47.g1b7707e -- To unsubscribe from this list: send the line 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/2] git-prompt.sh: strip unnecessary space in prompt string
Junio C Hamano wrote: It is like asking why typeset a space after a sentence a tad wider than a space after each word: Not at all. The prompt has nothing to do with sentences. grouping related things together, and separating groups of different kind apart, to make it more readable. You could argue that the colors are not very well thought-out (branch-name has the same color as +), but I really don't see the problem otherwise. How is this more readable: artagnon|master *=:~/src/git$ than: artagnon|master*=:~/src/git$ (where master is green, * is red, and = is white)? Looking at what we've done so far, I would argue that we're not thinking about the usability of the prompt enough: it currently screams I AM DOING REBASE-i! (and similarly for other operations in progress). I intend to fix these things in future patches. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] merge-base: add --merge-child option
On Sun, May 12, 2013 at 10:02:39PM -0700, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: On 12/05/2013 19:58, John Keeping wrote: With the patch below, the --ancestry-path version drops to under 2 seconds. I'm not sure if this is a good idea though. It helps me say I know nothing that isn't on the ancestry path can be patch-identical, so don't bother checking if it is but it regresses users who want the full cherry-pick check while only limiting the output. Hmm. Should an excluded commit be a valid comparator? Is it sensible/correct to show a left commit as = to a right commit that has been excluded by the revision specifiers? Doesn't sound right to me. Neither to me. OK. I'll add some tests and send a proper patch once 1.8.3 is out of the way. -- To unsubscribe from this list: send the line 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 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8
On Mon, May 13, 2013 at 3:20 AM, David Aguilar dav...@gmail.com wrote: Mac OS X Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the Common Digest SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a COMMON_DIGEST_SHA1 option to the Makefile to allow choosing this implementation and define it by default on Darwin. Define COMMON_DIGEST_FOR_SHA1 to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: David Aguilar dav...@gmail.com --- Here's a replacement patch for what's in pu. This version uses the built-in #defines and can thus avoid touching cache.h. Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 25282b4..9d174b9 100644 --- a/Makefile +++ b/Makefile @@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin) endif endif COMMON_DIGEST_HMAC = YesPlease + COMMON_DIGEST_SHA1 = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1390,10 +1391,15 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_SHA1 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_SHA1=1 This is incorrect. As noted in my previous email, you need to define COMMON_DIGEST_FOR_OPENSSL, not COMMON_DIGEST_FOR_SHA1, in order for CommonDigest.h to provide the OpenSSL defines magically. Thus: s/COMMON_DIGEST_FOR_SHA1=1/COMMON_DIGEST_FOR_OPENSSL/ + SHA1_HEADER = CommonCrypto/CommonDigest.h +else SHA1_HEADER = openssl/sha.h EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif ifdef COMMON_DIGEST_HMAC BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC=1 -- 1.8.3.rc1.47.g1b7707e -- To unsubscribe from this list: send the line 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] patch-ids.c: cache patch IDs in a notes tree
On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: But it is not a big problem. Either 3-way merge notices that there is nothing new, or you get a conflict and have chance to inspect what is going on. It's not a problem here, but false negatives would be annoying if you're looking at git log --cherry-mark. The primary thing to notice is that it is not a new problem with or without the caching layer. As Linus mentioned how patch-ids are computed by ignoring offsets and whitespaces, the filtering is done as a crude approximation and false negatives are part of design, so making the cache more complex by recording hash of the binary and/or options used to compute misses the fundamental. The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction and then run a command that uses the cache with no such restriction you could hit a patch that is the same for those paths but also touches other paths that you don't want to ignore and mark it as patch identical even though it is not. Adding a hash of the diffopts fixes that. -- To unsubscribe from this list: send the line 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 0/7] rebase.autostash completed
Junio C Hamano wrote: Especially I did not check if there are still undesirable data loss behaviour in corner cases that people were worried about in the discussion. Check the tests. What am I missing? In the longer term, it is unmaintainable to make such users (like this new code) of the stash mechanism manually do so, and we may want to add a git stash __store subcommand, not meant for the interactive use of end users. The implementation of the stash can later be changed without affecting such users by doing so. Yes, a store that stores a commit created with create would be nice. Why the horrible double-underscore though? git stash create is not meant for interactive use of end users either. Perhaps rebase can be taught to be more careful when checking if local changes may overlap with the changes being replayed. Frankly, I don't know if it's worth the effort. It might be a nice theoretical exercise, but what tangible benefit do I get as the end user (now that I have rebase.autostash)? In fact, I'll probably be slowing down the interactive rebase noticeably by executing a diff-tree at every step. And for what? Those who still want to use stash would benefit from having an autostash, but at that point, there is no reason to single out rebase for the autostash feature. Those who want to stash immediately before a merge that is known to conflict can use the same autostash and may want to do so for exactly the same reason they may want to use it for rebase. Each command that wants to have autostash will have to implement it independently. You argued that an implicit merge.autostash may be harmful earlier: maybe an explicit --autostash; but at this point, the returns are diminishing: what is the great advantage of --autostash over a quick manual g ss, g sp (git stash save, git stash pop)? I don't know what problem you're trying to solve anymore. -- To unsubscribe from this list: send the line 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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Junio C Hamano wrote: Writing it like this: [...] with a blank line before the next echo, it would be more readable. This feels funny. Why not [...] without an extra command substitution with an echo? I'll re-roll if there are more comments. Otherwise, can you fix these up locally? Thanks. git stash store -m autostash $stash_sha1 || exit Definitely nicer. I'll write follow-ups for pull and stash. -- To unsubscribe from this list: send the line 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 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8
On Mon, May 13, 2013 at 12:55 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, May 13, 2013 at 3:20 AM, David Aguilar dav...@gmail.com wrote: Mac OS X Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the Common Digest SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a COMMON_DIGEST_SHA1 option to the Makefile to allow choosing this implementation and define it by default on Darwin. Define COMMON_DIGEST_FOR_SHA1 to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: David Aguilar dav...@gmail.com --- Here's a replacement patch for what's in pu. This version uses the built-in #defines and can thus avoid touching cache.h. Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 25282b4..9d174b9 100644 --- a/Makefile +++ b/Makefile @@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin) endif endif COMMON_DIGEST_HMAC = YesPlease + COMMON_DIGEST_SHA1 = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1390,10 +1391,15 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_SHA1 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_SHA1=1 This is incorrect. As noted in my previous email, you need to define COMMON_DIGEST_FOR_OPENSSL, not COMMON_DIGEST_FOR_SHA1, in order for CommonDigest.h to provide the OpenSSL defines magically. Thus: s/COMMON_DIGEST_FOR_SHA1=1/COMMON_DIGEST_FOR_OPENSSL/ Yes, you're right. Strangely, it compiled just fine either way which is why I hadn't noticed. I'll resend along w/ a replacement for 2/3 to drop the =1 in the -D definition. -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] imap-send: eliminate HMAC deprecation warnings on OS X 10.8
Mac OS X Mountain Lion warns that HMAC_Init() and friends are deprecated. Use CommonCrypto's HMAC to eliminate the warnings. Reviewed-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: David Aguilar dav...@gmail.com --- 1/3 not included since it is unchanged. These are replacement patches for what's currently in pu. Changes since last time: We no longer say =1 when defining COMMON_DIGEST_FOR_HMAC. I added the word deprecated to the commit message subject for consistency with the other patches in this series. Makefile| 5 + imap-send.c | 10 ++ 2 files changed, 15 insertions(+) diff --git a/Makefile b/Makefile index f698c1a..a0f7afc 100644 --- a/Makefile +++ b/Makefile @@ -1054,6 +1054,7 @@ ifeq ($(uname_S),Darwin) BASIC_LDFLAGS += -L/opt/local/lib endif endif + COMMON_DIGEST_HMAC = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1393,6 +1394,10 @@ else EXTLIBS += $(LIB_4_CRYPTO) endif endif + +ifdef COMMON_DIGEST_HMAC + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC +endif ifdef NO_PERL_MAKEMAKER export NO_PERL_MAKEMAKER endif diff --git a/imap-send.c b/imap-send.c index d9bcfb4..1b2e69c 100644 --- a/imap-send.c +++ b/imap-send.c @@ -29,8 +29,18 @@ #ifdef NO_OPENSSL typedef void *SSL; #else +#ifdef COMMON_DIGEST_FOR_HMAC +#include CommonCrypto/CommonHMAC.h +#define HMAC_CTX CCHmacContext +#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) +#define HMAC_Update CCHmacUpdate +#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) +#define HMAC_CTX_cleanup +#define EVP_md5() kCCHmacAlgMD5 +#else #include openssl/evp.h #include openssl/hmac.h +#endif #include openssl/x509v3.h #endif -- 1.8.3.rc1.52.g872cb7b -- To unsubscribe from this list: send the line 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 v4 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8
Mac OS X Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the CommonCrytpo SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a COMMON_DIGEST_SHA1 option to the Makefile to allow choosing this implementation and define it by default on Darwin. Define COMMON_DIGEST_FOR_OPENSSL to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: David Aguilar dav...@gmail.com --- Changes since last round: COMMON_DIGEST_FOR_OPENSSL is used to enable the compatibility macros. Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index a0f7afc..29c02ed 100644 --- a/Makefile +++ b/Makefile @@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin) endif endif COMMON_DIGEST_HMAC = YesPlease + COMMON_DIGEST_SHA1 = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1390,10 +1391,15 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_SHA1 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL + SHA1_HEADER = CommonCrypto/CommonDigest.h +else SHA1_HEADER = openssl/sha.h EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif ifdef COMMON_DIGEST_HMAC BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC -- 1.8.3.rc1.52.g872cb7b -- To unsubscribe from this list: send the line 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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Ramkumar Ramachandra artag...@gmail.com writes:
+finish_rebase () {
+ if test -f $state_dir/autostash
+ then
+ stash_sha1=$(cat $state_dir/autostash)
+ if git stash apply $stash_sha1 21 /dev/null
+ then
+ echo Applied autostash
Any reason why this is not using gettext and the other messages do.
+ else
+ ref_stash=refs/stash
+ : $GIT_DIR/logs/$ref_stash
+ git update-ref -m autostash $ref_stash $stash_sha1 \
+ || die $(eval_gettext 'Cannot store
$stash_sha1')
+ echo
+$(gettext 'Applying autostash resulted in conflicts.
+Your changes are safe in the stash.
+You can apply or drop it at any time.')
Good idea to put the autostash in an actual stash. Perhaps the message
can be made more explicit, e.g.
You can run git stash apply or git stash drop at any time.
(actually, git stash pop may be a better suggestion to git stash
apply here).
--
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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Matthieu Moy wrote: Any reason why this is not using gettext and the other messages do. You can run git stash apply or git stash drop at any time. Fixed. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] rebase.autostash completed
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Especially I did not check if there are still undesirable data loss behaviour in corner cases that people were worried about in the discussion. Check the tests. What am I missing? I didn't do a thorough check, but my earlier comments are taken into account, I didn't see anything wrong and the tests in 7/7 are good. Perhaps rebase can be taught to be more careful when checking if local changes may overlap with the changes being replayed. Frankly, I don't know if it's worth the effort. It might be a nice theoretical exercise, but what tangible benefit do I get as the end user (now that I have rebase.autostash)? In fact, I'll probably be slowing down the interactive rebase noticeably by executing a diff-tree at every step. And for what? One benefit would be to avoid triggering rebuild (and editor reload) by keeping the timestamps intact. But I agree it's probably not worth the effort (and definitely isn't in the scope of this series). -- 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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Ramkumar Ramachandra artag...@gmail.com writes: Matthieu Moy wrote: Any reason why this is not using gettext and the other messages do. You can run git stash apply or git stash drop at any time. Fixed. Thanks. After thinking a bit, I have another nit about the message: it's not clear whether it's saying your changes are in the work tree, but with conflicts so you may want to retry later with git stash pop, or I could not apply your changes at all, do it yourself with git stash pop. I suppose it's the former, but it could be more explicit. -- 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: Mapping file contents from one repository to another
On 05/12/2013 05:22 PM, Jason Timrod wrote: Hi all, This is a complicated question to try and ask, let alone answer, so I had best give some background. I have two repositories --- one of them, which I'll call repoA, is the main repository, it's the one which most of the code we develop ends up. The other repository, repoB is our portable version of the code---the one which is used to deploy on systems other than the one which repoA is deployed on. As such, repoB often (and does) contain commits specific to repoB which will never appear in repoA, such as OS-specific things. In this case, in repoA we have a man page. Up until recently, this used to be the same file in both repositories. But because of the way the files in repoB are deployed, unlike in repoA this file has had its name changed from: foo.1 - foo.1.in Because the man page is run through some sed script to replace various things which never need to happen in repoA Why don't you name it foo.1.in in both repos and pipe it through cat on repoA (i.e., just copy it to foo.1)? Then you would only have to maintain a small difference in your build system between repoA/repoB rather than having to coordinate two versions of the bigger source document. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-prompt.sh: strip unnecessary space in prompt string
On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote: SZEDER Gábor wrote: Don't forget that others might use a different prompt format and using colors in the prompt is optional. With the default prompt format and without colors I find that that space definitely helps readability. I'm finding it hard to believe that anyone would want to use a colorless prompt. Well, back then I was shell-shocked to find that there are people who want colors in their prompt ;) IMHO that's just ugly ;) If we can agree that it's just a matter of taste, we should both be able to have what we want. Any suggestions on how to make this configurable? The same way we make other things configurable in the prompt: specify the GIT_PS1_HIDESTATESEPARATOR or something similar variable to strip that space from the prompt. -- To unsubscribe from this list: send the line 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/2] git-prompt.sh: strip unnecessary space in prompt string
On Mon, May 13, 2013 at 01:05:51PM +0200, SZEDER Gábor wrote: On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote: If we can agree that it's just a matter of taste, we should both be able to have what we want. Any suggestions on how to make this configurable? The same way we make other things configurable in the prompt: specify the GIT_PS1_HIDESTATESEPARATOR or something similar variable to strip that space from the prompt. Or perhaps better yet: use a variable, e.g. GIT_PS1_STATESEPARATOR or whatever, to specify what should separate the branch name from the repo state, defaulting to a space to keep the current behavior. Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: simplify file filtering
On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote: Thanks; is this the last one for this cycle and is your usual branch ready to be pulled? It is now; please pull from the usual place, git://ozlabs.org/~paulus/gitk.git. Thanks, Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: simplify file filtering
On Mon, May 13, 2013 at 10:58:49AM +0200, Stefan Haller wrote: Would you also consider Tair Sabirgaliev's v2 patch for not launching gitk in the background on Mac? This fixes a very serious usability problem. http://permalink.gmane.org/gmane.comp.version-control.git/43 Yes, I put it in. I didn't see it when he posted because my spam filters decided it was spam. :) Paul. -- To unsubscribe from this list: send the line 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: [PATCHv3 3/7] show: honor --textconv for blobs
On Sun, May 12, 2013 at 10:01:38PM -0700, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: Adding to that: Somehow I still feel I should introduce a new attribute show (or a better name) similar to diff so that you can specifiy a diff driver to use for showing a blob (or grepping it), which may or may not be the same you use for diff. This would be a much more fine-grained and systematic way of setting a default for --textconv for blobs. Of course, some driver attributes would just not matter for coverting blobs, but that doesn't hurt. I'm just wondering whether it's worth the effort and whether I should distinguish between show and grep. Haven't thought things through, but my gut feeling is that it is on the other side of the line. We could of course add more features and over-engineered mechanisms, and the implementation may end up to be even modular and clean, but I cannot answer Yes with a confidence to the question Does such a fine grained control help the users? and cannot answer If so in what way? myself. Yeah, I think the _most_ flexible thing is going to look something like: $ cat .gitattributes *.pdf diff=pdf show=pdf $ cat ~/.gitconfig [diff pdf] textconv = ... [show pdf] textconv = ... But that obviously sucks, because in the common case that you want to use the same command, you are repeating yourself in the config. You could assume that the show attribute points us at a diff block. And that makes sense for textconv, but what does it mean if you have show=foo and diff.foo.command set? If the _only_ thing you would want to do with such a show mechanism is to display converted contents on show/grep, then we could lose the flexibility and say that show is a single-bit: do we respect diff textconv for show/grep in this case, or not? And that leaves only the question of where to put it: is it a gitattribute, or does it go in the config? I don't think that it is a property of the file itself. That is, you do not say foo files are inherently uninteresting to git-show, and therefore we always convert them, whereas bar files do not have that property'. You say in my workflows, I expect to see converted results from grep/show. And the latter points to using config, like either diff.*.showConverted (to allow per-type setting), or even grep.useTextconv and show.textConv (to allow setting it per-user for all types). And of course for any workflow-oriented config, you will sometimes want to override it for a particular operation. But that is why we have a command-line escape hatch, and that part is already implemented. -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 1/2] sha1_name.c: signal if @{-N} was a true branch nameor a detached head
On Thu, May 09, 2013 at 10:08:24AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Since the point of marking the detached HEAD is to turn off things like
@{-1}@{u}, we would want to be generous and err on the side of
assuming it is a branch if it _might_ be one.
I am not sure X and Y mesh well in your Since X, we would want Y.
It seems to argue for erring on the side of detached HEAD to me.
Thinking on it more, I don't see that one is actually better than the
other. If you claim a detached HEAD when there isn't one, the user says
stupid git, that was a branch, and you should tell me its upstream.
But if you claim an undetached HEAD when there isn't one, asking for the
upstream provides wildly inaccurate results (e.g., git checkout
@{-1}@{u} taking you somewhere unexpected).
Checking the from name $HEX against old_sha1 is a local and cheap
measure I added there for the first level of disambiguation. If
they do not match, we _know_ we didn't come back from a detached
HEAD state.
In order to err on the favor branch when it could have been one,
you could additionally look for the reflog .git/logs/refs/heads/$HEX
when the from name $HEX matches old_sha1 (which is likely to be
detached, but it is possible that we were on the $HEX branch when
its tip was at $HEX) and making sure the tip of that $HEX branch
once used to be at $HEX at the time recorded for @{-N} in the HEAD
reflog in question.
I was thinking in terms of @{-1}@{u}, so that you could say well, do we
have upstream config for such a branch currently?. Because even though
we are digging into history (and it _may_ have been a branch at the
time, but isn't now), if we are ultimately going to ask about the
upstream config (as it is _now_, not when the entry was made), then it
does not matter if the branch was detached or not: we are still going to
return failure either way.
But there are _other_ uses for @{-1}, and I am probably being too
focused on this one use-case.
So given all of the above, I think I am fine with the direction of the
series.
-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 0/6] Get stash to help rebase.autostash
Hi, This topic is based on the rebase.autostash topic. It cleans up a few things, introduces 'git stash store', and patches rebase to use it. Should be simple enough. Thanks. Ramkumar Ramachandra (6): Documentation/stash: correct synopsis for create Documentation/stash: document short form -p in synopsis stash: simplify option parser for create stash: introduce 'git stash store' stash: tweak error message in store_stash () rebase: use 'git stash store' to simplify logic Documentation/git-stash.txt | 10 -- git-rebase.sh | 6 +- git-stash.sh| 32 +--- t/t3903-stash.sh| 20 4 files changed, 50 insertions(+), 18 deletions(-) -- 1.8.3.rc1.57.g4ac1522 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8
On Mon, May 13, 2013 at 4:23 AM, David Aguilar dav...@gmail.com wrote: Mac OS X Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the CommonCrytpo SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a COMMON_DIGEST_SHA1 option to the Makefile to allow choosing this implementation and define it by default on Darwin. The approach of adding a Makefile option for each CommonCrypto facility does not really scale well. For instance, these days, I generally build git against OpenSSL from MacPorts, which gives me a warning-free git build since MacPorts/OpenSSL lacks those Apple-specific deprecation flags. With this patch series introducing several Makefile knobs, people wishing to use MacPorts/OpenSSL will have to tweak each knob. These patches already introduce two knobs (COMMON_DIGEST_SHA1, COMMON_DIGEST_HMAC). Adding more knobs to silence the remaining 29 deprecation warnings will make the build more cumbersome for those who prefer OpenSSL. Instead, introducing a single knob (such as APPLE_COMMON_CRYPTO) would avoid this problem. More generally, is the approach of trying to figure out CommonCrypto replacements for DIGEST, HMAC, and the other 29 warnings worthwhile? After all, Apple introduced deprecation warnings due to the ABI-instability of OpenSSL, not due to any particular flaw in OpenSSL or its API. A more manageable approach might simply be to disable that particular warning on Darwin (via CFLAGS or perhaps '#pragma GCC diagnostic ignored' for more fine-grained control). Define COMMON_DIGEST_FOR_OPENSSL to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: David Aguilar dav...@gmail.com --- Changes since last round: COMMON_DIGEST_FOR_OPENSSL is used to enable the compatibility macros. Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index a0f7afc..29c02ed 100644 --- a/Makefile +++ b/Makefile @@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin) endif endif COMMON_DIGEST_HMAC = YesPlease + COMMON_DIGEST_SHA1 = YesPlease NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1390,10 +1391,15 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_SHA1 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL + SHA1_HEADER = CommonCrypto/CommonDigest.h +else SHA1_HEADER = openssl/sha.h EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif ifdef COMMON_DIGEST_HMAC BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC -- 1.8.3.rc1.52.g872cb7b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] teach the user to be nice to git and let him say please sometimes
Hi, On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: Since ages we do not care about our program enough. Lets not treat them as slaves anymore and say please. Signed-off-by: Heiko Voigt hvo...@hvoigt.net Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Thomas Rast tr...@inf.ethz.ch Signed-off-by: Johan Herland jo...@herland.net So these were the ones present on the dev-day? No this was just a random sample of the ones sitting at the same beer garden table that this feature was implemented on. I actually would have expected, from the please title, the opposite, us saying please to the user, either once in a while in the advice messages we give to them, or perhaps in the en_POLITE locale ;-) The en_POLITE is also a nice idea :-) We could split up the work on the translations amongst all people joining a git meetup. .gitignore | 1 + Makefile | 1 + builtin.h| 1 + builtin/config.c | 23 ++- builtin/please.c | 9 cache.h | 1 + config.c | 23 +++ contrib/completion/git-prompt.sh | 5 +++- git.c| 49 +++- There is no test to protect this feature from future breakages? In fact the whole testsuite should fail after the first 10 tests if you said please right before running it. So since battery life is short and this feature so important we did not bother to fix that. We already had enough please complaints during intermediate commits and entering the signed-off messages. It is really annoying, you should try this patch! ;-) And it is especially unuseful when you are committing using git gui. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Colored prompt for ZSH
Thanks to Felipe, SZEDER, and Junio for a review of v1. This is a v2 in response to those reviews. Ramkumar Ramachandra (3): prompt: introduce GIT_PS1_STATESEPARATOR prompt: factor out gitstring coloring logic prompt: colorize ZSH prompt contrib/completion/git-prompt.sh | 128 +++ 1 file changed, 89 insertions(+), 39 deletions(-) -- 1.8.3.rc1.57.g4ac1522 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] prompt: introduce GIT_PS1_STATESEPARATOR
A typical prompt looks like:
artagnon|master *=:~/src/git$
^
why do we have this space?
Nobody has branch names that end with +, *, =, or anyway, so it
doesn't serve the purpose of disambiguation.
Make this separator configurable via GIT_PS1_STATESEPARATOR. This means
that you can set it to and get this prompt:
artagnon|master*=:~/src/git$
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index eaf5c36..5d8b745 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -359,6 +359,11 @@ __git_ps1 ()
fi
fi
+ local z=
+ if [ -n ${GIT_PS1_STATESEPARATOR+set} ]; then
+ z=${GIT_PS1_STATESEPARATOR}
+ fi
+
local f=$w$i$s$u
if [ $pcmode = yes ]; then
local gitstring=
@@ -384,7 +389,7 @@ __git_ps1 ()
gitstring=\[$branch_color\]$branchstring\[$c_clear\]
if [ -n $w$i$s$u$r$p ]; then
- gitstring=$gitstring
+ gitstring=$gitstring$z
fi
if [ $w = * ]; then
gitstring=$gitstring\[$bad_color\]$w
@@ -400,13 +405,13 @@ __git_ps1 ()
fi
gitstring=$gitstring\[$c_clear\]$r$p
else
- gitstring=$c${b##refs/heads/}${f:+ $f}$r$p
+ gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
fi
gitstring=$(printf -- $printf_format $gitstring)
PS1=$ps1pc_start$gitstring$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode
- printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
+ printf -- $printf_format
$c${b##refs/heads/}${f:+$z$f}$r$p
fi
fi
}
--
1.8.3.rc1.57.g4ac1522
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] prompt: factor out gitstring coloring logic
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 79 ++--
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 5d8b745..6943f86 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -222,6 +222,48 @@ __git_ps1_show_upstream ()
}
+# Helper function that is meant to be called from __git_ps1. It
+# builds up a gitstring injecting color codes into the appropriate
+# places.
+__git_ps1_colorize_gitstring ()
+{
+ local c_red='\e[31m'
+ local c_green='\e[32m'
+ local c_lblue='\e[1;34m'
+ local c_clear='\e[0m'
+ local bad_color=$c_red
+ local ok_color=$c_green
+ local branch_color=$c_clear
+ local flags_color=$c_lblue
+ local branchstring=$c${b##refs/heads/}
+
+ if [ $detached = no ]; then
+ branch_color=$ok_color
+ else
+ branch_color=$bad_color
+ fi
+
+ # Setting gitstring directly with \[ and \] around colors
+ # is necessary to prevent wrapping issues!
+ gitstring=\[$branch_color\]$branchstring\[$c_clear\]
+
+ if [ -n $w$i$s$u$r$p ]; then
+ gitstring=$gitstring$z
+ fi
+ if [ $w = * ]; then
+ gitstring=$gitstring\[$bad_color\]$w
+ fi
+ if [ -n $i ]; then
+ gitstring=$gitstring\[$ok_color\]$i
+ fi
+ if [ -n $s ]; then
+ gitstring=$gitstring\[$flags_color\]$s
+ fi
+ if [ -n $u ]; then
+ gitstring=$gitstring\[$bad_color\]$u
+ fi
+ gitstring=$gitstring\[$c_clear\]$r$p
+}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
@@ -368,42 +410,7 @@ __git_ps1 ()
if [ $pcmode = yes ]; then
local gitstring=
if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
- local c_red='\e[31m'
- local c_green='\e[32m'
- local c_lblue='\e[1;34m'
- local c_clear='\e[0m'
- local bad_color=$c_red
- local ok_color=$c_green
- local branch_color=$c_clear
- local flags_color=$c_lblue
- local branchstring=$c${b##refs/heads/}
-
- if [ $detached = no ]; then
- branch_color=$ok_color
- else
- branch_color=$bad_color
- fi
-
- # Setting gitstring directly with \[ and \]
around colors
- # is necessary to prevent wrapping issues!
-
gitstring=\[$branch_color\]$branchstring\[$c_clear\]
-
- if [ -n $w$i$s$u$r$p ]; then
- gitstring=$gitstring$z
- fi
- if [ $w = * ]; then
- gitstring=$gitstring\[$bad_color\]$w
- fi
- if [ -n $i ]; then
- gitstring=$gitstring\[$ok_color\]$i
- fi
- if [ -n $s ]; then
- gitstring=$gitstring\[$flags_color\]$s
- fi
- if [ -n $u ]; then
- gitstring=$gitstring\[$bad_color\]$u
- fi
- gitstring=$gitstring\[$c_clear\]$r$p
+ __git_ps1_colorize_gitstring
else
gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
fi
--
1.8.3.rc1.57.g4ac1522
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] prompt: colorize ZSH prompt
Add colors suitable for use in the ZSH prompt. Having learnt that the
ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
GIT_PS1_SHOWCOLORHINTS with ZSH.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 6943f86..e2dd8a8 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -20,7 +20,8 @@
#post, which are strings you would put in $PS1 before
#and after the status string generated by the git-prompt
#machinery. e.g.
-# PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#Bash: PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#ZSH: precmd () { __git_ps1 %n :%~$ |%s }
#will show username, at-sign, host, colon, cwd, then
#various status string, followed by dollar and SP, as
#your prompt.
@@ -227,6 +228,43 @@ __git_ps1_show_upstream ()
# places.
__git_ps1_colorize_gitstring ()
{
+ if [[ -n ${ZSH_VERSION-} ]]; then
+ local c_red='%F{red}'
+ local c_green='%F{green}'
+ local c_lblue='%F{blue}'
+ local c_clear='%f'
+ local bad_color=$c_red
+ local ok_color=$c_green
+ local branch_color=$c_clear
+ local flags_color=$c_lblue
+ local branchstring=$c${b##refs/heads/}
+
+ if [ $detached = no ]; then
+ branch_color=$ok_color
+ else
+ branch_color=$bad_color
+ fi
+
+ gitstring=$branch_color$branchstring$c_clear
+
+ if [ -n $w$i$s$u$r$p ]; then
+ gitstring=$gitstring$z
+ fi
+ if [ $w = * ]; then
+ gitstring=$gitstring$bad_color$w
+ fi
+ if [ -n $i ]; then
+ gitstring=$gitstring$ok_color$i
+ fi
+ if [ -n $s ]; then
+ gitstring=$gitstring$flags_color$s
+ fi
+ if [ -n $u ]; then
+ gitstring=$gitstring$bad_color$u
+ fi
+ gitstring=$gitstring$c_clear$r$p
+ return
+ fi
local c_red='\e[31m'
local c_green='\e[32m'
local c_lblue='\e[1;34m'
--
1.8.3.rc1.57.g4ac1522
--
To unsubscribe from this list: send the line 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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Writing it like this: [...] with a blank line before the next echo, it would be more readable. This feels funny. Why not [...] without an extra command substitution with an echo? I'll re-roll if there are more comments. Otherwise, can you fix these up locally? Thanks. No, thanks. I won't be even taking the patch right now, so you have plenty of time ;-). -- To unsubscribe from this list: send the line 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 7/7] rebase: implement --[no-]autostash and rebase.autostash
Junio C Hamano wrote: No, thanks. I won't be even taking the patch right now, so you have plenty of time ;-). There were some additional comments from Matthieu, so I will re-roll (just this part). I've even posted a stash series based on this one. Do you have any additional comments? -- To unsubscribe from this list: send the line 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] patch-ids.c: cache patch IDs in a notes tree
John Keeping j...@keeping.me.uk writes: The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction ... What? What business does patch-id have with pathspec-limited diff generation? You do not rebase or cherry-pick with pathspec, so unless you are populating the patch-id cache at a wrong point (like, say whenevern git show $commit is run), I am not sure why pathspec limit becomes even an issue. -- To unsubscribe from this list: send the line 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: English/German terminology, git.git's de.po, and pro-git
On Monday 2013-05-13 14:54, Thomas Rast wrote: As I am sure you are all aware, there are two main religions as to how one can translate technical material into German: leave the technical terms mostly in English, or translate them to an appropriate corresponding word. I'll denote them G+E and Ger, respectively. The problem is that there are often no technical equivalent terms in Ger, leaving you only with Eng which are paraphrased (in more or less detail) in the German-language manpages. treeish is one of those. The literal translation would be baumig, bäumlich. This is strange in German and at best only used by kids. In the SYNOPSIS section of e.g. git-ls-tree(1), you can get away with baumähnlich, but in flowtext (prose), the sane choices are, for example: git-ls-tree erfordert als ersten nicht-Options-Parameter... ~... einen tree-ish, d.h. eine Referenz, aus der sich ein Baum-Objekt ableiten lässt. ~... eine zu einem Baum-Objekt führende Refernz ~... eine Baum-Objekt-Referenz (dies kann auch ein Commit sein, da jedem Commit genau ein Baum-Objekt zugeordnet ist) My vote is G+E. Essentially, so is mine. German terms will be used where such have been used in prior computing (Bäume have been used in the 90s too, so that term is fine, for example). Stash however is something that could be seen as something that has had its first appearence in Git, with no corresponding native German term, in which case we should do it roughly like Wikipedia, that is, provide a German equivalent, but only for the introductory sake: Der Stash (dt: Versteck) bezeichnet einen Bereich ... afterwards which the meaning of stash is at most re-recognizable in the verb: ... mit `git stash` wird der aktuelle Zustand im Stash weggespeichert. That's my common-world use. glossary for git's de.po is [2]. I have no idea what Sven and Ralph do. Perhaps a github wiki page would be fine for everyone? A single wiki page might not suffice; we may need as much as one wiki page per term, so that there is ample visual space to record each person's comments and justification for choosing a particular German translation. (Just look at my go at treeish above, for example.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-prompt.sh: strip unnecessary space in prompt string
SZEDER Gábor sze...@ira.uka.de writes: On Mon, May 13, 2013 at 01:05:51PM +0200, SZEDER Gábor wrote: On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote: If we can agree that it's just a matter of taste, we should both be able to have what we want. Any suggestions on how to make this configurable? The same way we make other things configurable in the prompt: specify the GIT_PS1_HIDESTATESEPARATOR or something similar variable to strip that space from the prompt. Or perhaps better yet: use a variable, e.g. GIT_PS1_STATESEPARATOR or whatever, to specify what should separate the branch name from the repo state, defaulting to a space to keep the current behavior. Why just a single knob for that SP? If you restructure the code to formulate gitstring to call a shell function to do so, people can override it and come up with whatever format they want to use, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] teach the user to be nice to git and let him say please sometimes
On Mon, May 13, 2013 at 8:30 PM, Heiko Voigt hvo...@hvoigt.net wrote: + if (impolite_counter 10) + die(Error: Learn some manners, say please some time!); + if (polite_counter 10) + die(Error: Too many please! I don't believe you.); NAK. If we truly care, we need better AI here! I agree but this patches goal was to implement the basic politeness infrastructure. We planned to add more features, like inter-repository jealousy, later. For inter-repository jealousy git would complain if you worked more with one repository than others you cloned and you'd for example sometimes need a double please to satisfy it. I'm still not happy with this direction. I propose we rewrite C Git in Lisp first as a preparation step for git-please improvements. We could drop support for all platforms but Lisp Machine along the way. That would make all other Git implementations jealous. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] rebase.autostash completed
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Especially I did not check if there are still undesirable data loss behaviour in corner cases that people were worried about in the discussion. Check the tests. What am I missing? In the longer term, it is unmaintainable to make such users (like this new code) of the stash mechanism manually do so, and we may want to add a git stash __store subcommand, not meant for the interactive use of end users. The implementation of the stash can later be changed without affecting such users by doing so. Yes, a store that stores a commit created with create would be nice. Why the horrible double-underscore though? git stash create is not meant for interactive use of end users either. create is not advertised very widely, but store is too close to what is already familiar to the people save and we really do not want to confuse them. store -m message commit sounds as if you are creating a stash to apply to the given $commit. -- To unsubscribe from this list: send the line 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 0/7] rebase.autostash completed
Matthieu Moy matthieu@grenoble-inp.fr writes: One benefit would be to avoid triggering rebuild (and editor reload) by keeping the timestamps intact. But I agree it's probably not worth the effort (and definitely isn't in the scope of this series). It isn't in the scope, of course. If rebase were done right, the series will become much less necessary in the first place ;-). -- To unsubscribe from this list: send the line 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] patch-ids.c: cache patch IDs in a notes tree
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction ... What? What business does patch-id have with pathspec-limited diff generation? You do not rebase or cherry-pick with pathspec, so unless you are populating the patch-id cache at a wrong point (like, say whenevern git show $commit is run), I am not sure why pathspec limit becomes even an issue. revision.c::cherry_pick_list() sets the pathspec to what was specified in the revision options. It's done that since commit 36d56de (Fix --cherry-pick with given paths, 2007-07-10) and t6007 tests that it works. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH v4 3/5] config: make parsing stack struct independent from actual data source
On Sun, May 12, 2013 at 09:56:39PM -0700, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: /* - * The fields f and name of top need to be initialized before calling + * All source specific fields in the union, name and the callbacks + * fgetc, ungetc, ftell of top need to be initialized before calling * this function. */ -static int do_config_from(struct config_file *top, config_fn_t fn, void *data) +static int do_config_from_source(struct config_source *top, config_fn_t fn, void *data) This renaming may have made sense if we were to have many different do_config_from_$type functions for different types of source, but as this patch introduces a nice config_source abstraction, I do not think it is unnecessary. Shortening do_config_from() to do_config() may make more sense, if anything. But that is a very minor point, as this is entirely internal with a single caller. Did you really intent this double negation: ..., I do not think it is unnecessary. ? The rest of the paragraph sounds like you would think the rename is actually not necessary. I thought I recalled that Jeff asked me to change the name but I can not find the email, so maybe its just my wrong memory. I am happy to drop the rename here, if thats what you meant. Cheers Heiko -- To unsubscribe from this list: send the line 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 0/7] rebase.autostash completed
Junio C Hamano wrote: create is not advertised very widely, but store is too close to what is already familiar to the people save and we really do not want to confuse them. store -m message commit sounds as if you are creating a stash to apply to the given $commit. In the store series I posted a few minutes ago, I use the format store commit message. I've not advertised it in the usage (like create), and documented it just like create. Maybe we should add the line Not for end user interactive use to both descriptions? We can get that double-underscore if you really want, but it'd stick out like a sore thumb since we can't change create. -- To unsubscribe from this list: send the line 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/2] git-prompt.sh: strip unnecessary space in prompt string
Junio C Hamano wrote: If you restructure the code to formulate gitstring to call a shell function to do so, people can override it and come up with whatever format they want to use, no? The user would essentially have to implement her own __git_ps1_colorize_string; a function that takes a lot of arguments and stitches them together with color. Much too painful for little gain. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] merge-base: add --merge-child option
On 13/05/2013 01:22, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: git log --ancestry-path --left-right E...F --not $(git merge-base --all E F) which looks like we're having to repeat ourselves because it's not paying attention... You are half wrong; --left-right is about do we show the //= marker in the output?, so it is true that it does not make sense without ..., but the reverse is not true: A...B does not and should not imply --left-right. The repetition I meant is that by the definition of ancestry-path, the above would seem to be equivalent to git log --ancestry-path --left-right E F --not $(git merge-base --all E F) $(git merge-base --all E F) Anyway, revised separated-out version of the patch follows. Kevin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] stash: simplify option parser for create
Ramkumar Ramachandra artag...@gmail.com writes: The option parser for create unnecessarily checks $1 inside a case statement that matches $1 in the first place. Also, use $@, not $*, as our caller is expecting $1 $2, not $1c$2 (where c is the first character of IFS). The first part of the patch may be OK but the rest unfortunately is wrong. The semi-user facing git stash create never was meant to take anything but a message sentence and $* is the proper way to say everything is meant for a single message (just like echo). Changing it to $@ will change the semantics in a big way. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-stash.sh | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index bbefdf6..0ede313 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -546,11 +546,8 @@ clear) clear_stash $@ ;; create) - if test $# -gt 0 test $1 = create - then - shift - fi - create_stash $* echo $w_commit + shift + create_stash $@ echo $w_commit ;; drop) shift -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 05e462b..e58ab74 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -17,6 +17,7 @@ SYNOPSIS [-u|--include-untracked] [-a|--all] [message]] 'git stash' clear 'git stash' create [message [include-untracked-p]] +'git stash' store commit message Two points: - We should not advertise store (and create for that matter) in the end-user facing documentation. IIRC, git stash -h deliberately omits 'create'; having it in the documentation is unavoidable, but it was a mistake that it was not marked with this is most likely not what you want to use; see 'save'. It may even be better with a leading underscore or two in the name that clearly marks it as not meant for direct end-user consumption. - The error message store_stash() gives should not be hardcoded in that function. Save-stash may want to keep saying 'the current status' as it said before, but a caller like your rebase-autostash will not be saving the current status and would want to have a different message. Other than that, the overfall structure of the patch looks OK 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 5/6] stash: tweak error message in store_stash ()
Ramkumar Ramachandra artag...@gmail.com writes:
When the update-ref invocation fails, store_stash currently prints:
Cannot save the current status
This is not very useful for diagnosing the problem. Instead, print:
Cannot store 688268c4254ca5dc6e2effa83bae4f0dbbe75e5b
so we can inspect the object and analyze why the update-ref failed.
This would break the error message for save_stash with your current
patch series, wouldn't it? I think this patch is a solution to a
wrong problem. As I already said in 4/6, store_stash should allow
its caller to supply a customised error message.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-stash.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-stash.sh b/git-stash.sh
index 1d483f5..24d72fc 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -167,7 +167,7 @@ store_stash () {
# Make sure the reflog for stash is kept.
: $GIT_DIR/logs/$ref_stash
git update-ref -m $stash_msg $ref_stash $w_commit ||
- die $(gettext Cannot save the current status)
+ die $(gettext Cannot store $w_commit)
}
save_stash () {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] merge-base: add --merge-child option
Kevin Bracey venit, vidit, dixit 13.05.2013 16:26: On 13/05/2013 01:22, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: git log --ancestry-path --left-right E...F --not $(git merge-base --all E F) which looks like we're having to repeat ourselves because it's not paying attention... You are half wrong; --left-right is about do we show the //= marker in the output?, so it is true that it does not make sense without ..., but the reverse is not true: A...B does not and should not imply --left-right. The repetition I meant is that by the definition of ancestry-path, the above would seem to be equivalent to git log --ancestry-path --left-right E F --not $(git merge-base --all E F) $(git merge-base --all E F) Anyway, revised separated-out version of the patch follows. Kevin It is certainly true that git log --cherry needs much less information than what the merge base machinery provides. I've been experimenting with that in order to get the speedup which is necessary for replacing the git cherry code with calls into the revision walker using --cherry. But I can't wrap my head around the feature proposed here, sorry. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/10] Add support for -i/--interactive to git-clean
2013/5/13 Matthieu Moy matthieu@grenoble-inp.fr: + /* Confirmation dialog */ + printf(_(Remove ([y]es/[n]o/[e]dit) ? )); To be more consistent with git add -p, this should use [] instead of (), and have no space before ?. Will be replaced with: printf(_(Remove [y/n]? )); + die(_(clean.requireForce defaults to true and neither -i, -n nor -f given; refusing to clean)); That makes it a 85 characters message, and we usually break lines before 80. Adding \n after ; (instead of a space) would be better IMO. If die with multiple lines, it looks ugly. E.g. % git clean fatal: clean.requireForce defaults to true and neither -i, -n nor -f given; refusing to clean I think because of this, some die messages are longer than 80 characters. Such as: # builtin/apply.c:1496 die(Q_(git diff header lacks filename information when removing %d leading pathname component (line %d), git diff header lacks filename information when removing %d leading pathname components (line %d), -- Jiang Xin http://www.worldhello.net/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree
John Keeping j...@keeping.me.uk writes: On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction ... What? What business does patch-id have with pathspec-limited diff generation? You do not rebase or cherry-pick with pathspec, so unless you are populating the patch-id cache at a wrong point (like, say whenevern git show $commit is run), I am not sure why pathspec limit becomes even an issue. revision.c::cherry_pick_list() sets the pathspec to what was specified in the revision options. It's done that since commit 36d56de (Fix --cherry-pick with given paths, 2007-07-10) and t6007 tests that it works. Then the caching should be automatically turned off when pathspec is given. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: simplify file filtering
Paul Mackerras pau...@samba.org writes: On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote: Thanks; is this the last one for this cycle and is your usual branch ready to be pulled? It is now; please pull from the usual place, git://ozlabs.org/~paulus/gitk.git. Thanks, Thanks. Here is what I ended up with: Merge git://ozlabs.org/~paulus/gitk * git://ozlabs.org/~paulus/gitk: gitk: On OSX, bring the gitk window to front gitk: Add support for -G'regex' pickaxe variant gitk: Add menu item for reverting commits gitk: Simplify file filtering gitk: Display the date of a tag in a human-friendly way gitk: Improve behaviour of drop-down lists gitk: Move hard-coded colors to .gitk gitk-git/gitk | 254 +- 1 file changed, 199 insertions(+), 55 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] config: make parsing stack struct independent from actual data source
Heiko Voigt hvo...@hvoigt.net writes: On Sun, May 12, 2013 at 09:56:39PM -0700, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: /* - * The fields f and name of top need to be initialized before calling + * All source specific fields in the union, name and the callbacks + * fgetc, ungetc, ftell of top need to be initialized before calling * this function. */ -static int do_config_from(struct config_file *top, config_fn_t fn, void *data) +static int do_config_from_source(struct config_source *top, config_fn_t fn, void *data) This renaming may have made sense if we were to have many different do_config_from_$type functions for different types of source, but as this patch introduces a nice config_source abstraction, I do not think it is unnecessary. Shortening do_config_from() to do_config() may make more sense, if anything. But that is a very minor point, as this is entirely internal with a single caller. Did you really intent this double negation: ..., I do not think it is unnecessary. Eh, rather I think it is unnecessary or I do not think it is necessary. -- To unsubscribe from this list: send the line 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 0/7] rebase.autostash completed
Ramkumar Ramachandra artag...@gmail.com writes: Maybe we should add the line Not for end user interactive use to both descriptions? We can get that double-underscore if you really want, but it'd stick out like a sore thumb since we can't change create. Yeah, good point about the __name. It was a mistake that the description of 'create' does not have This is probably not what you want to use; see 'save' there. Let's do that, and do the same for 'store' (that is, not advertise in 'git stash -h' output, describe in the manual for scripters, and mark it not for the end user in the description). -- To unsubscribe from this list: send the line 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: [PATCHv3 3/7] show: honor --textconv for blobs
Jeff King venit, vidit, dixit 13.05.2013 13:55: On Sun, May 12, 2013 at 10:01:38PM -0700, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: Adding to that: Somehow I still feel I should introduce a new attribute show (or a better name) similar to diff so that you can specifiy a diff driver to use for showing a blob (or grepping it), which may or may not be the same you use for diff. This would be a much more fine-grained and systematic way of setting a default for --textconv for blobs. Of course, some driver attributes would just not matter for coverting blobs, but that doesn't hurt. I'm just wondering whether it's worth the effort and whether I should distinguish between show and grep. Haven't thought things through, but my gut feeling is that it is on the other side of the line. We could of course add more features and over-engineered mechanisms, and the implementation may end up to be even modular and clean, but I cannot answer Yes with a confidence to the question Does such a fine grained control help the users? and cannot answer If so in what way? myself. Yeah, I think the _most_ flexible thing is going to look something like: $ cat .gitattributes *.pdf diff=pdf show=pdf $ cat ~/.gitconfig [diff pdf] textconv = ... [show pdf] textconv = ... But that obviously sucks, because in the common case that you want to use the same command, you are repeating yourself in the config. You could assume that the show attribute points us at a diff block. And that makes sense for textconv, but what does it mean if you have show=foo and diff.foo.command set? I don't propose show drivers. In your example above, you would point to the same diff driver. If you use a diff driver just with the show attribute then only its textconv config will be relevant. But you do have the possibility to use different drivers for diff and show. For example, for showing a file some sort of automatic pagination or line numbering can be helpful whereas it would hurt the diff case. If the _only_ thing you would want to do with such a show mechanism is to display converted contents on show/grep, then we could lose the flexibility and say that show is a single-bit: do we respect diff textconv for show/grep in this case, or not? And that leaves only the question of where to put it: is it a gitattribute, or does it go in the config? I don't think that it is a property of the file itself. That is, you do not say foo files are inherently uninteresting to git-show, and therefore we always convert them, whereas bar files do not have that property'. You say in my workflows, I expect to see converted results from grep/show. And the latter points to using config, like either diff.*.showConverted (to allow per-type setting), or even grep.useTextconv and show.textConv (to allow setting it per-user for all types). I strongly disagree here. I have textconv filters for pdf, gpg, odf, xls, doc, xoj... I know, ugly. At least some of them would benefit from different filteres or different settings. The way I propose it, a user would just have to add show=foo to the diff=foo lines without having to ad an extra filter, but with the flexibility to do so. And of course for any workflow-oriented config, you will sometimes want to override it for a particular operation. But that is why we have a command-line escape hatch, and that part is already implemented. One may ask what a purely ui output oriented setting like show has to do in .gitattributes, of course, but that applies to diff as well. Separating the two (one in attributes, one in config) looks artificial to me. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] stash: simplify option parser for create
Junio C Hamano wrote: The semi-user facing git stash create never was meant to take anything but a message sentence and $* is the proper way to say everything is meant for a single message (just like echo). Changing it to $@ will change the semantics in a big way. Ah, I see. As an interactive caller, it is impossible to set $untracked (I thought this was a mistake, but you're indicating that it's intentional). Okay, I'll fix the patch and documentation. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree
On Mon, May 13, 2013 at 07:46:09AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: The caching layer could also introduce false positives though, which is more serious. If you cache patch IDs with a pathspec restriction ... What? What business does patch-id have with pathspec-limited diff generation? You do not rebase or cherry-pick with pathspec, so unless you are populating the patch-id cache at a wrong point (like, say whenevern git show $commit is run), I am not sure why pathspec limit becomes even an issue. revision.c::cherry_pick_list() sets the pathspec to what was specified in the revision options. It's done that since commit 36d56de (Fix --cherry-pick with given paths, 2007-07-10) and t6007 tests that it works. Then the caching should be automatically turned off when pathspec is given. That was my first thought, but since we can be affected by other diff options set in the user's config as well it ended up being simpler to include it in the options hash and use that. This has the advantage that you get the benefit of the cache if you run git log --cherry-mark with the same paths more than once. In my testing the cache is beneficial as soon as you examine more than one similar range (e.g. master...feature-A and then master...feature-B). -- To unsubscribe from this list: send the line 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 0/2] Make --ancestry-path A...B work
This patch is a revised form of the one in my history traversal refinements series. Pulled out to allow it to proceed faster, given that John Keeping has found a use for the command. I suggest this is placed onto pu ahead of the existing series, dropping the equivalent final commit there. And then hopefully this can proceed to next faster. (Dropping that commit will drop the only --ancestry-path A...B test in t6111, meaning no immediate dependencies. But the next version of that series will be sent with t6111 testing and expecting a pass due to this fix being in.) Kevin Bracey (2): t6019: demonstrate --ancestry-path A...B breakage revision.c: treat A...B merge bases as if manually specified revision.c| 17 + revision.h| 1 + t/t6019-rev-list-ancestry-path.sh | 21 - 3 files changed, 38 insertions(+), 1 deletion(-) -- 1.8.3.rc0.28.g4b02ef5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] revision.c: treat A...B merge bases as if manually specified
The documentation assures users that A...B is defined as A B --not
$(git merge-base --all A B). This wasn't in fact quite true, because
the calculated merge bases were not sent to add_rev_cmdline().
The main effect of this was that although
git rev-list --ancestry-path A B --not $(git merge-base --all A B)
worked, the simpler form
git rev-list --ancestry-path A...B
failed with a no bottom commits error.
Other potential users of bottom commits could also be affected by this
problem, if they examine revs-cmdline_info; I came across the issue in
my proposed history traversal refinements series.
So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged with new 'whence' enum value REV_CMD_MERGE_BASE.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
revision.c| 17 +
revision.h| 1 +
t/t6019-rev-list-ancestry-path.sh | 2 +-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index a67b615..7f7a8ab 100644
--- a/revision.c
+++ b/revision.c
@@ -915,6 +915,19 @@ static void add_rev_cmdline(struct rev_info *revs,
info-nr++;
}
+static void add_rev_cmdline_list(struct rev_info *revs,
+struct commit_list *commit_list,
+int whence,
+unsigned flags)
+{
+ while (commit_list) {
+ struct object *object = commit_list-item-object;
+ add_rev_cmdline(revs, object, sha1_to_hex(object-sha1),
+ whence, flags);
+ commit_list = commit_list-next;
+ }
+}
+
struct all_refs_cb {
int all_flags;
int warned_bad_reflog;
@@ -1092,6 +1105,7 @@ static void prepare_show_merge(struct rev_info *revs)
add_pending_object(revs, head-object, HEAD);
add_pending_object(revs, other-object, MERGE_HEAD);
bases = get_merge_bases(head, other, 1);
+ add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING);
add_pending_commit_list(revs, bases, UNINTERESTING);
free_commit_list(bases);
head-object.flags |= SYMMETRIC_LEFT;
@@ -1179,6 +1193,9 @@ int handle_revision_arg(const char *arg_, struct rev_info
*revs, int flags, unsi
if (symmetric) {
exclude = get_merge_bases(a, b, 1);
+ add_rev_cmdline_list(revs, exclude,
+REV_CMD_MERGE_BASE,
+flags_exclude);
add_pending_commit_list(revs, exclude,
flags_exclude);
free_commit_list(exclude);
diff --git a/revision.h b/revision.h
index 01bd2b7..878a555 100644
--- a/revision.h
+++ b/revision.h
@@ -35,6 +35,7 @@ struct rev_cmdline_info {
REV_CMD_PARENTS_ONLY,
REV_CMD_LEFT,
REV_CMD_RIGHT,
+ REV_CMD_MERGE_BASE,
REV_CMD_REV
} whence;
unsigned flags;
diff --git a/t/t6019-rev-list-ancestry-path.sh
b/t/t6019-rev-list-ancestry-path.sh
index 5287f6a..dd5b0e5 100755
--- a/t/t6019-rev-list-ancestry-path.sh
+++ b/t/t6019-rev-list-ancestry-path.sh
@@ -81,7 +81,7 @@ test_expect_success 'rev-list F...I' '
test_cmp expect actual
'
-test_expect_failure 'rev-list --ancestry-path F...I' '
+test_expect_success 'rev-list --ancestry-path F...I' '
for c in F H I; do echo $c; done expect
git rev-list --ancestry-path --format=%s F...I |
sed -e /^commit /d |
--
1.8.3.rc0.28.g4b02ef5
--
To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: - The error message store_stash() gives should not be hardcoded in that function. Save-stash may want to keep saying 'the current status' as it said before, but a caller like your rebase-autostash will not be saving the current status and would want to have a different message. Makes sense. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] prompt: introduce GIT_PS1_STATESEPARATOR
Ramkumar Ramachandra artag...@gmail.com writes:
A typical prompt looks like:
artagnon|master *=:~/src/git$
^
why do we have this space?
Nobody has branch names that end with +, *, =, or anyway, so it
doesn't serve the purpose of disambiguation.
Make this separator configurable via GIT_PS1_STATESEPARATOR. This means
that you can set it to and get this prompt:
artagnon|master*=:~/src/git$
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index eaf5c36..5d8b745 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -359,6 +359,11 @@ __git_ps1 ()
fi
fi
+ local z=
+ if [ -n ${GIT_PS1_STATESEPARATOR+set} ]; then
+ z=${GIT_PS1_STATESEPARATOR}
+ fi
It is simpler to use 'default values', no?
local z=${GIT_PS1_STATESEPARATOR- }
@@ -384,7 +389,7 @@ __git_ps1 ()
gitstring=\[$branch_color\]$branchstring\[$c_clear\]
if [ -n $w$i$s$u$r$p ]; then
- gitstring=$gitstring
+ gitstring=$gitstring$z
Perhaps not even a nit, but you do not have to concatenate when $z
is set to empty, so it may be worth doing
if [ -n $w$i$s$u$r$p ] [ -n $z ]; then
gitstring=$gitstring$z
fi
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] t6019: demonstrate --ancestry-path A...B breakage
Signed-off-by: Kevin Bracey ke...@bracey.fi --- t/t6019-rev-list-ancestry-path.sh | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/t/t6019-rev-list-ancestry-path.sh b/t/t6019-rev-list-ancestry-path.sh index 39b4cb0..5287f6a 100755 --- a/t/t6019-rev-list-ancestry-path.sh +++ b/t/t6019-rev-list-ancestry-path.sh @@ -13,6 +13,9 @@ test_description='--ancestry-path' # # D..M -- M.t == M # --ancestry-path D..M -- M.t == M +# +# F...I == F G H I +# --ancestry-path F...I == F H I . ./test-lib.sh @@ -63,13 +66,29 @@ test_expect_success 'rev-list D..M -- M.t' ' test_cmp expect actual ' -test_expect_success 'rev-list --ancestry-patch D..M -- M.t' ' +test_expect_success 'rev-list --ancestry-path D..M -- M.t' ' echo M expect git rev-list --ancestry-path --format=%s D..M -- M.t | sed -e /^commit /d actual test_cmp expect actual ' +test_expect_success 'rev-list F...I' ' + for c in F G H I; do echo $c; done expect + git rev-list --format=%s F...I | + sed -e /^commit /d | + sort actual + test_cmp expect actual +' + +test_expect_failure 'rev-list --ancestry-path F...I' ' + for c in F H I; do echo $c; done expect + git rev-list --ancestry-path --format=%s F...I | + sed -e /^commit /d | + sort actual + test_cmp expect actual +' + # b---bc # / \ / # a X -- 1.8.3.rc0.28.g4b02ef5 -- To unsubscribe from this list: send the line 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] t5551: do not use unportable sed '\+'
On 2013-05-13 00.50, Junio C Hamano wrote: Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5551-http-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Thanks, works like a charm, tested on Mac OS. /torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/7] show: honor --textconv for blobs
Michael J Gruber g...@drmicha.warpmail.net writes: But you do have the possibility to use different drivers for diff and show. For example, for showing a file some sort of automatic pagination or line numbering can be helpful whereas it would hurt the diff case. I do not find the example convincing (yet); it looks more like you are grasping for straws. You would certainly do not want line numbering in grep. My gut feeling is that normal users would expect to have a single text version and pass that to pr (if they want pagination) or cat -n (if they want line numbering), regardless of where it comes from, be it git show --textconv or some other program output, but you seem to want to have different text versions for different purposes out of a single binary file I strongly disagree here. I have textconv filters for pdf, gpg, odf, xls, doc, xoj... I know, ugly. At least some of them would benefit from different filteres or different settings. and an example to show why it is useful would help here. I do not feel that I have seen anything to substantiate at least some of them would benefit yet. Would it follow that grep and cat-file should be controlled by yet two other knobs so that optionally the user can use different text versions meant for them? The way I propose it, a user would just have to add show=foo to the diff=foo lines without having to ad an extra filter, but with the flexibility to do so. And of course for any workflow-oriented config, you will sometimes want to override it for a particular operation. But that is why we have a command-line escape hatch, and that part is already implemented. One may ask what a purely ui output oriented setting like show has to do in .gitattributes, of course, but that applies to diff as well. Separating the two (one in attributes, one in config) looks artificial to me. I am not sure what you mean by artificial, but the separation of the roles between attribute and config is not artificial at all. It is very much deliberate and done for a good reason. The attribute specifies what the type of the file is project wide and is meant to go in in-tree .gitattrbute file, shared among people on different platforms. It says things like These files are PDF. The config specifies what should happen to the type of a file on a particular platform each user uses to work in the copy of the project, i.e. repository. It says things like Pass PDF files through /opt/bin/pdf2txt, which obviously cannot be shared across platforms. -- To unsubscribe from this list: send the line 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] patch-ids.c: cache patch IDs in a notes tree
John Keeping j...@keeping.me.uk writes: This has the advantage that you get the benefit of the cache if you run git log --cherry-mark with the same paths more than once. In my testing the cache is beneficial as soon as you examine more than one similar range (e.g. master...feature-A and then master...feature-B). OK, so perhaps the notes that are keyed with commit ID will record multiple entries, one for each invocation pattern (i.e. all pathspec given, possibly with nonstandard options)? git diff -- t Documentation and git diff -- Docu\* t, even though they use different pathspec, would produce the same diff; instead of pathspec you may need to key with the actual list of paths in the patch, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] stash: introduce 'git stash store'
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: - The error message store_stash() gives should not be hardcoded in that function. Save-stash may want to keep saying 'the current status' as it said before, but a caller like your rebase-autostash will not be saving the current status and would want to have a different message. Makes sense. I think it is fine to have a default message to be used when store_stash shell function is not given an optional error message. The command line for it may become: git stash store [-m message] [-e error message] $stash_sha1 or something like that. -- To unsubscribe from this list: send the line 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] patch-ids.c: cache patch IDs in a notes tree
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: This has the advantage that you get the benefit of the cache if you run git log --cherry-mark with the same paths more than once. In my testing the cache is beneficial as soon as you examine more than one similar range (e.g. master...feature-A and then master...feature-B). OK, so perhaps the notes that are keyed with commit ID will record multiple entries, one for each invocation pattern (i.e. all pathspec given, possibly with nonstandard options)? That would be possible, but I didn't do it in the current version of the patch. git diff -- t Documentation and git diff -- Docu\* t, even though they use different pathspec, would produce the same diff; instead of pathspec you may need to key with the actual list of paths in the patch, though. Maybe, but I think that would be overkill. I'm interested to see how much of a benefit we could get by not calculating the patch ID of any commits on the larger side of a symmetric range that touch paths outside the set touched by the smaller side. (revision.c::cherry_pick_list() remembers patch IDs for the smaller side of a symmetric range and then checks if anything on the larger side matches so this fits in naturally.) In my usage I generally compare a relatively small topic branch against whatever has happened in some upstream branch so I think this could give a big improvement but I haven't had time to try it yet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] revision.c: treat A...B merge bases as if manually specified
Looks good. 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: English/German terminology, git.git's de.po, and pro-git
2013/5/13 Thomas Rast tr...@inf.ethz.ch:
Hi
I hope I got together a Cc list that pretty much represents everyone
involved in git core and pro-git book translation into German.
As I am sure you are all aware, there are two main religions as to how
one can translate technical material into German: leave the technical
terms mostly in English, or translate them to an appropriate
corresponding word. I'll denote them G+E and Ger, respectively. I
would really like to avoid rehashing that entire discussion in this
thread, if at all possible; we've flogged that horse enough. See
e.g. [1] for previous threads on the git list about the transation.
However, an unfortunate and unsatisfactory situation has developed:
Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
Thielow built core git's de.po on top of it, so it's also Ger.
Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
translation of pro-git (which is also quite mature at this point, having
apparently begun in 2009), and as you probably guessed by now, it's G+E.
So that leaves us at a point where the libre Git book (and also the
one that happens to be hosted on git-scm.com, the official site) does
not match the terminology used by German git.
Like, at all. They're not even remotely near each other.
Therefore, a total newbie would find at least one of those two totally
useless. I haven't done a comprehensive survey yet, but it is my
impression that the commercial git books are also G+E, so the
hypothetical newbie would be stuck learning the English terms in one of
the two regardless.
So where to go from this mess?
Obviously -- unless the agreement is that the status quo should persist
-- we'd first have to sort out what the preferable translation should
be. And I'm a bit scared of trying, except that a straw poll on IRC
gave me some hope that a simple majority vote could help settle it.
My vote is G+E.
My vote is G+E, too. IMO the users should read the same terms in Git
messages as they read in the majority of German Git-books/blogs/etc.
(I don't know one of them where Git terms are translated.) I think that
would make users life easier and less confusing.
After that, we should create a unified glossary. Even in the G+E case,
a few terms would presumably be translated fully and some others might
have partial translations (checkout - auschecken?). The current
glossary for git's de.po is [2]. I have no idea what Sven and Ralph do.
Perhaps a github wiki page would be fine for everyone?
Finally, converting the existing translation will require some manpower.
I'll help review things, as I have previously done for translation
updates of core git de.po; perhaps with a few more volunteers it can be
done pretty quickly.
Thanks for your time.
- Thomas
[1] http://thread.gmane.org/gmane.comp.version-control.git/58315
http://thread.gmane.org/gmane.comp.version-control.git/156226/focus=156373
http://thread.gmane.org/gmane.comp.version-control.git/196779/focus=196792
[2] https://github.com/ralfth/git-po-de/wiki/Glossary
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t5551: do not use unportable sed '\+'
Torsten Bögershausen tbo...@web.de writes: On 2013-05-13 00.50, Junio C Hamano wrote: Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5551-http-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Thanks, works like a charm, tested on Mac OS. /torsten Thanks; I take it that you reverted the sed fix part and saw the updated clone check fail with the platform sed? -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: git stash store [-m message] [-e error message] $stash_sha1 1. The message is NOT optional. If the user says 'git stash store b8bb3fe9', what default message can we possibly put in? There is absolutely no context: no branch name, nothing. So, the best we can do is generic WIP. What is the point of putting in such a useless message? 2. We have already determined that the command is NOT for end user interactive use. So, why do we need a default error message at all? The last statement is an update-ref, and you can infer whether it succeeded or failed from the exit status. 3. Why are we designing a command-line interface? git stash store $stash_sha1 $message is sufficient for scripts, and there is absolutely no point in parsing '-m', '-e', or any such thing. -- To unsubscribe from this list: send the line 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: English/German terminology, git.git's de.po, and pro-git
Am 13.05.2013 15:57, schrieb Jan Engelhardt: On Monday 2013-05-13 14:54, Thomas Rast wrote: My vote is G+E. Essentially, so is mine. ... Same here. I frequently get asked to switch Git back to English when the LANG=C gets lost, because my coworkers and myself - almost all of which are native German speakers - are terribly confused by the current git gui translations. Having said that, no matter how this vote turns out the term submodule should be translated as Submodul and not Unterprojekt. The former is a perfectly valid German word and I see no reason to arbitrarily use a different one here. -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: git stash store [-m message] [-e error message] $stash_sha1 ... 3. Why are we designing a command-line interface? git stash store $stash_sha1 $message is sufficient for scripts, and there is absolutely no point in parsing '-m', '-e', or any such thing. git stash store $stash_sha1 $message [ $error_message ] is adequate an internal API _for now_. I however suspect that you would regret later when you need more customization. It already happened once for git merge when it was an internal API for git pull and it was painful to support saner interface and the traditional one at the same time [*1*]. [Footnote] *1* And no, don't even try to rewrite git merge call inside git pull to use the modern style with -m message; you will likely break it (I've tried once and decided it was not worth the hassle). -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: I however suspect that you would regret later when you need more customization. It already happened once for git merge when it was an internal API for git pull and it was painful to support saner interface and the traditional one at the same time [*1*]. Oh god. git-merge --stat --progress $merge_name HEAD 04c5b83c46760573 We made a design mistake at the command-level in merge. This is at a subcommand-level. 1. Will git stash store ever be more than a one-liner? Can you think of how this function could be larger? 2. Will git stash store ever become an interactive command? Isn't the whole point of interactive stash something that operates on a worktree? Why will I ever want to operate on a commit with stash, interactively? While it is absolutely necessary to avoid calamities like the merge invocation in git-pull.sh, we shouldn't be over-engineering either. -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: *1* And no, don't even try to rewrite git merge call inside git pull to use the modern style with -m message; you will likely break it (I've tried once and decided it was not worth the hassle). This falls in my basket of nice theoretical exercise: a lot of work for no tangible benefit ;) Footnote: I'm not saying that code is not important; you've seen me arguing for beautiful implementations several times before, against all odds. -- To unsubscribe from this list: send the line 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] t5551: do not use unportable sed '\+'
On 2013-05-13 18.30, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: On 2013-05-13 00.50, Junio C Hamano wrote: Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5551-http-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Thanks, works like a charm, tested on Mac OS. /torsten Thanks; I take it that you reverted the sed fix part and saw the updated clone check fail with the platform sed? In my first test with the fix the test case passed. Then the sed expression was only manipulated to verify that the TC failes. And now I took even the original expression and have verfied it is failing. The short version: Yes -- To unsubscribe from this list: send the line 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] t5551: do not use unportable sed '\+'
Torsten Bögershausen tbo...@web.de writes: On 2013-05-13 18.30, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: On 2013-05-13 00.50, Junio C Hamano wrote: Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5551-http-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Thanks, works like a charm, tested on Mac OS. /torsten Thanks; I take it that you reverted the sed fix part and saw the updated clone check fail with the platform sed? In my first test with the fix the test case passed. Then the sed expression was only manipulated to verify that the TC failes. And now I took even the original expression and have verfied it is failing. The short version: Yes Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: That is not a valid question. I was just asking to see if you could think of something. I just did: named stashes (each one has a different ref/ reflog) for internal use. Sure, we'll go with the -m -e approach. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.3-rc2
A release candidate Git v1.8.3-rc2 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: b7569aa316d2e6c29249b15e8fc8e9c25fc7d6b1 git-1.8.3.rc2.tar.gz d34d977dcec40e3d1468654079d9ac1fa0b9a6f0 git-htmldocs-1.8.3.rc2.tar.gz 35d0020d6756a81f8d494a90ba19830d82621e92 git-manpages-1.8.3.rc2.tar.gz Also the following public repositories all have a copy of the v1.8.3-rc2 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git In addition, https://www.kernel.org/pub/software/scm/git/testing/ will have the tarballs (hopefully). Git v1.8.3 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the simple semantics that pushes only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch. Use the user preference configuration variable push.default to change this. If you are an old-timer who is used to the matching semantics, you can set the variable to matching to keep the traditional behaviour. If you want to live in the future early, you can set it to simple today without waiting for Git 2.0. When git add -u (and git add -A) is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with git commit -a and other commands. There will be no mechanism to make plain git add -u behave like git add -u .. Current users of git add -u (without a pathspec) should start training their fingers to explicitly say git add -u . before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, git add path will behave as git add -A path, so that git add dir/ will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using git add --ignore-removal path now before 2.0 is released. Updates since v1.8.2 Foreign interface * remote-hg and remote-bzr helpers (in contrib/ since v1.8.2) have been updated; especially, the latter has been accelerated to help Emacs folks, whose primary SCM seems to be stagnating. UI, Workflows Features * A handful of updates applied to gitk, including an addition of revert action, showing dates in tags in a nicer way, making colors configurable, and support for -G'pickaxe' search. * The prompt string generator (in contrib/completion/) learned to show how many changes there are in total and how many have been replayed during a git rebase session. * git branch --vv learned to paint the name of the branch it integrates with in a different color (color.branch.upstream, which defaults to blue). * In a sparsely populated working tree, git checkout pathspec no longer unmarks paths that match the given pathspec that were originally ignored with --sparse (use --ignore-skip-worktree-bits option to resurrect these paths out of the index if you really want to). * git log --format specifier learned %C(auto) token that tells Git to use color when interpolating %d (decoration), %h (short commit object name), etc. for terminal output. * git bisect leaves the final outcome as a comment in its bisect log file. * git clone --reference can now refer to a gitfile textual symlink that points at the real location of the repository. * git count-objects learned --human-readable aka -H option to show various large numbers in Ki/Mi/GiB scaled as necessary. * git cherry-pick $blob and git cherry-pick $tree are nonsense, and a more readable error message e.g. can't cherry-pick a tree is given (we used to say expected exactly one commit). * The --annotate option to git send-email can be turned on (or off) by default with sendemail.annotate configuration variable (you can use --no-annotate from the command line to override it). * The --cover-letter option to git format-patch can be turned on (or off) by default with format.coverLetter configuration variable. By
Re: [PATCH] gitk: add support for -G'regex' pickaxe variant
Paul Mackerras wrote: How about changing lines matching:? Sorry for the slow response. Sounds perfect. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: English/German terminology, git.git's de.po, and pro-git
Hi, My vote is G+E, too. lb1a, Florian Breisch and I are working on the german translation of the pro-git book (hosted on git-scm.com). We use the repository [1] to share our work. If someone wants to help us, JOIN US! The current translation of pro-git is mixed, Ger and G+E. For example, the translation of annotated tag is Annotated Tag, kommentierter Tag and also kommentierte Markierung. I agree with the opinion of Jan Engelhardt that german terms should be used if they are commonly used in technical context (tree= Baum but tag should be Tag in german, too). There is a glossary for the pro-git book (see [2]) but it is not up-to-date and it is also mixed. Therefor I would like to avoid using this glossary. I like the idea of a shared wiki (git de.po and pro-git). I suggest a single page as overview and single pages for complicated terms. Maybe we can use our GitHub wiki (see also [3]). So long Ralph [1] https://github.com/progit-de/progit [2] https://github.com/progit/progit/blob/master/de/NOTES [3] https://github.com/progit-de/progit/wiki/Glossar -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: That is not a valid question. I was just asking to see if you could think of something. I just did: named stashes (each one has a different ref/ reflog) for internal use. Sure, we'll go with the -m -e approach. The whole point of my response is that it is not a valid approach to decide to add (or not to add) a reasonable enhancement mechanism built in from the beginning by asking what future enhancement do you foresee today?. It is unclear if you got that point. As long as the end result is to have something that does not paint us into a corner from which it will be painful to escape, I'll be happy anyway. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add support for -G'regex' pickaxe variant
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote: My experience is the opposite. I wonder What did the author of this nonsense comment mean? or What is the purpose of this strange condition in this if () statement?. Then git log -S finds the culprit Only if that if () statement looks that way from a single commit. That's my point. If the line code bit you are looking at is the result of several changes, your log -S will grind a while and find you nothing. cheers, m -- mar...@laptop.org - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To unsubscribe from this list: send the line 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: AW: English/German terminology, git.git's de.po, and pro-git
On Monday 2013-05-13 20:57, Ralph Haußmann wrote: There is a glossary for the pro-git book (see [2]) but it is not up-to-date and it is also mixed. Therefor I would like to avoid using this glossary. I like the idea of a shared wiki (git de.po and pro-git). I suggest a single page as overview and single pages for complicated terms. Maybe we can use our GitHub wiki (see also [3]). [2] https://github.com/progit/progit/blob/master/de/NOTES [3] https://github.com/progit-de/progit/wiki/Glossar This is how I envision a good glossary http://inai.de/files/git-glossary.txt Maybe the Benevolent Dictator model might be better suited instead of a wiki? (Think of the edit wars.) -- To unsubscribe from this list: send the line 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 4/6] stash: introduce 'git stash store'
Junio C Hamano wrote: The whole point of my response is that it is not a valid approach to decide to add (or not to add) a reasonable enhancement mechanism built in from the beginning by asking what future enhancement do you foresee today?. It is unclear if you got that point. Right, got it. The fact that we weren't able to foresee the merge UI problem tells us that we're capable of repeating the mistake no matter how much we think we've thought about 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] gitk: add support for -G'regex' pickaxe variant
Martin Langhoff wrote: On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote: My experience is the opposite. I wonder What did the author of this nonsense comment mean? or What is the purpose of this strange condition in this if () statement?. Then git log -S finds the culprit Only if that if () statement looks that way from a single commit. That's my point. If the line code bit you are looking at is the result of several changes, your log -S will grind a while and find you nothing. Well, no, it should find the final change that brought it into the current form. Just like git blame. Has it been finding zero results in some cases where the current code matches the pattern? That sounds like a bug. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] branch: show me the hot branches
Uses commit-date to sort displayed refs.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Just had this idea and wrote it down in five minutes. The
implementation is only meant to be indicative.
Isn't this awesome?
builtin/branch.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0836890..8b08563 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -59,6 +59,11 @@ static enum merge_filter {
} merge_filter;
static unsigned char merge_filter_ref[20];
+static enum sort_strategy {
+ LEXICAL = 0,
+ DATE,
+} sort_strategy;
+
static struct string_list output = STRING_LIST_INIT_DUP;
static unsigned int colopts;
@@ -406,7 +411,7 @@ static void free_ref_list(struct ref_list *ref_list)
free(ref_list-list);
}
-static int ref_cmp(const void *r1, const void *r2)
+static int ref_cmp_lexical(const void *r1, const void *r2)
{
struct ref_item *c1 = (struct ref_item *)(r1);
struct ref_item *c2 = (struct ref_item *)(r2);
@@ -416,6 +421,16 @@ static int ref_cmp(const void *r1, const void *r2)
return strcmp(c1-name, c2-name);
}
+static int ref_cmp_date(const void *r1, const void *r2)
+{
+ struct ref_item *c1 = (struct ref_item *)(r1);
+ struct ref_item *c2 = (struct ref_item *)(r2);
+
+ if (c1-kind != c2-kind)
+ return c1-kind - c2-kind;
+ return c1-commit-date c2-commit-date;
+}
+
static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
int show_upstream_ref)
{
@@ -621,7 +636,6 @@ static int print_ref_list(int kinds, int detached, int
verbose, int abbrev, stru
memset(ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
- ref_list.verbose = verbose;
ref_list.abbrev = abbrev;
ref_list.with_commit = with_commit;
if (merge_filter != NO_FILTER)
@@ -629,7 +643,14 @@ static int print_ref_list(int kinds, int detached, int
verbose, int abbrev, stru
cb.ref_list = ref_list;
cb.pattern = pattern;
cb.ret = 0;
+
+ if (sort_strategy == DATE verbose 1)
+ ref_list.verbose = 1;
+ else
+ ref_list.verbose = verbose;
for_each_rawref(append_ref, cb);
+ ref_list.verbose = verbose;
+
if (merge_filter != NO_FILTER) {
struct commit *filter;
filter = lookup_commit_reference_gently(merge_filter_ref, 0);
@@ -646,7 +667,10 @@ static int print_ref_list(int kinds, int detached, int
verbose, int abbrev, stru
ref_list.maxwidth = calc_maxwidth(ref_list);
}
- qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
+ if (sort_strategy == DATE)
+ qsort(ref_list.list, ref_list.index, sizeof(struct ref_item),
ref_cmp_date);
+ else
+ qsort(ref_list.list, ref_list.index, sizeof(struct ref_item),
ref_cmp_lexical);
detached = (detached (kinds REF_LOCAL_BRANCH));
if (detached match_patterns(pattern, HEAD))
@@ -843,6 +867,8 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
OPT_END(),
};
+ sort_strategy = DATE;
+
if (argc == 2 !strcmp(argv[1], -h))
usage_with_options(builtin_branch_usage, options);
--
1.8.3.rc1.49.g8d97506.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] git-svn: introduce --parents parameter for commands branch and tag
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
Signed-off-by: Tobias Schulte tobias.schu...@gliderpilot.de
---
Documentation/git-svn.txt|5
git-svn.perl | 22 +-
t/t9167-git-svn-cmd-branch-subproject.sh | 46 ++
3 files changed, 72 insertions(+), 1 deletion(-)
create mode 100755 t/t9167-git-svn-cmd-branch-subproject.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 58b6d54..4f2141d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -298,6 +298,11 @@ where name is the name of the SVN repository as
specified by the -R option to
git config --get-all svn-remote.name.commiturl
+
+--parents;;
+ Create parent folders. This parameter is equivalent to the parameter
+ --parents on svn cp commands and is useful for non-standard repository
+ layouts.
+
'tag'::
Create a tag in the SVN repository. This is a shorthand for
'branch -t'.
diff --git a/git-svn.perl b/git-svn.perl
index ccabe06..204313d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -113,7 +113,7 @@ my ($_stdin, $_help, $_edit,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_before, $_after,
- $_merge, $_strategy, $_preserve_merges, $_dry_run, $_local,
+ $_merge, $_strategy, $_preserve_merges, $_dry_run, $_parents, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
$_commit_url, $_tag, $_merge_info, $_interactive);
@@ -203,6 +203,7 @@ my %cmd = (
{ 'message|m=s' = \$_message,
'destination|d=s' = \$_branch_dest,
'dry-run|n' = \$_dry_run,
+ 'parents' = \$_parents,
'tag|t' = \$_tag,
'username=s' = \$Git::SVN::Prompt::_username,
'commit-url=s' = \$_commit_url } ],
@@ -211,6 +212,7 @@ my %cmd = (
{ 'message|m=s' = \$_message,
'destination|d=s' = \$_branch_dest,
'dry-run|n' = \$_dry_run,
+ 'parents' = \$_parents,
'username=s' = \$Git::SVN::Prompt::_username,
'commit-url=s' = \$_commit_url } ],
'set-tree' = [ \cmd_set_tree,
@@ -1172,6 +1174,10 @@ sub cmd_branch {
$ctx-ls($dst, 'HEAD', 0);
} and die branch ${branch_name} already exists\n;
+ if ($_parents) {
+ mk_parent_dirs($ctx, $dst);
+ }
+
print Copying ${src} at r${rev} to ${dst}...\n;
$ctx-copy($src, $rev, $dst)
unless $_dry_run;
@@ -1179,6 +1185,20 @@ sub cmd_branch {
$gs-fetch_all;
}
+sub mk_parent_dirs {
+ my $ctx = shift;
+ my $parent = shift;
+ $parent =~ s/\/[^\/]*$//;
+
+ if (!eval{$ctx-ls($parent, 'HEAD', 0)}) {
+ mk_parent_dirs($ctx, $parent);
+ print Creating parent folder ${parent} ...\n;
+ $ctx-mkdir($parent)
+ unless $_dry_run;
+ }
+
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die SVN or git revision required ,
as a command-line argument\n;
diff --git a/t/t9167-git-svn-cmd-branch-subproject.sh
b/t/t9167-git-svn-cmd-branch-subproject.sh
new file mode 100755
index 000..9cb891b
--- /dev/null
+++ b/t/t9167-git-svn-cmd-branch-subproject.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+#
+# Copyright (c) 2013 Tobias Schulte
+#
+
+test_description='git svn branch for subproject clones'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize svnrepo' '
+mkdir import
+(
+(cd import
+mkdir -p trunk/project branches tags
+(cd trunk/project
+echo foo foo
+)
+svn_cmd import -m import for git-svn . $svnrepo /dev/null
+)
+rm -rf import
+svn_cmd co $svnrepo/trunk/project trunk/project
+(cd trunk/project
+echo bar foo
+svn_cmd ci -m updated trunk
+)
+rm -rf trunk
+)
+'
+
+test_expect_success 'import into git' '
+git svn init --trunk=trunk/project --branches=branches/*/project
--tags=tags/*/project $svnrepo
+git svn fetch
+git checkout remotes/trunk
+'
+
+test_expect_success 'git svn branch tests' '
+test_must_fail git svn branch a
+git svn branch --parents a
+test_must_fail git svn branch -t tag1
+git svn branch --parents -t tag1
+test_must_fail git svn branch --tag tag2
+git svn branch --parents --tag tag2
+test_must_fail git svn tag tag3
+git svn tag --parents tag3
+'
+
+test_done
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
Junio C Hamano gits...@pobox.com writes: Johan Herland jo...@herland.net writes: Obviously, I named it '%1' since it expands into the _first_ component of the (slash-separated) shorthand. OK, I can buy something like %* refs/%* refs/heads/%* ... refs/remotes/%*/HEAD refs/remotes/%1/%2 refs/peers/%1/heads/%2 that is, for a pattern that has %*, we feed the end-user string as a whole, and for a pattern that has %1 thru %N, we find an appropriate way to chop the end-user string into N pieces (e.g. nick/name would be split into %1 = nick, %2 = name, while foo/bar/baz might have two possibilities, %1, %2 = foo, bar/baz or foo/bar, baz). The earlier ones on the above list can even be written with their %* substituted with %1 if we go that route. Just to make sure. Please do not let two possibilities stop you. As I said in the nearby thread, I do not necessarily insist that we must try all N possibilities. We find an appropriate way could be just we always chop at the first slash, and %1 is what comes before it, %2 is what comes after it. That will close the possibility for us to use %1 thru %N (N is limited to 2), but it still is We have %1 and we have %2, both fall into the same 'path components, numbered from left to right' category, and justifies the use of %1 (one, not el). So still no objection to %1 from me. And that makes perfect sense, and is exactly the kind of you plan to have %2 and %3 that falls into the same category as %1 I was asking you about in the message. So, no more objection to %1 from me, if that is the direction you are taking us. -- To unsubscribe from this list: send the line 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] teach the user to be nice to git and let him say please sometimes
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
Signed-off-by: Johan Herland jo...@herland.net
So these were the ones present on the dev-day?
No this was just a random sample of the ones sitting at the same
beer garden table that this feature was implemented on.
Also see
http://thomasrast.ch/pix/foss/20130509_gitmerge/DSC_7078.jpg.php
for an illustration of the history of this patch.
/plug
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] teach the user to be nice to git and let him say please sometimes
Thomas Rast tr...@inf.ethz.ch writes: Heiko Voigt hvo...@hvoigt.net writes: On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: Signed-off-by: Heiko Voigt hvo...@hvoigt.net Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Thomas Rast tr...@inf.ethz.ch Signed-off-by: Johan Herland jo...@herland.net So these were the ones present on the dev-day? No this was just a random sample of the ones sitting at the same beer garden table that this feature was implemented on. Also see http://thomasrast.ch/pix/foss/20130509_gitmerge/DSC_7078.jpg.php for an illustration of the history of this patch. /plug Thanks for sharing. I see some familiar faces. Envy, envy... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add support for -G'regex' pickaxe variant
On Mon, May 13, 2013 at 3:33 PM, Jonathan Nieder jrnie...@gmail.com wrote: Well, no, it should find the final change that brought it into the current form. Just like git blame. Has it been finding zero results in some cases where the current code matches the pattern? That sounds like a bug. Ummm, maybe. You are right, with current git it does work as I would expect (usefully ;-) ). I know I struggled quite a bit with log -S not finding stuff I thought it should and that log -G did find, back a year ago. Damn, I don't have a precise record of what git it was on, nor a good repro example. Too long ago, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add support for -G'regex' pickaxe variant
Jonathan Nieder wrote: Martin Langhoff wrote: On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote: My experience is the opposite. I wonder What did the author of this nonsense comment mean? or What is the purpose of this strange condition in this if () statement?. Then git log -S finds the culprit Only if that if () statement looks that way from a single commit. That's my point. If the line code bit you are looking at is the result of several changes, your log -S will grind a while and find you nothing. Well, no, it should find the final change that brought it into the current form. Just like git blame. I still don't know exactly what -G and -S do. The documentation can be improved, no? A nice example would definitely help. 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
[PATCH 0/4] Coverage support revisited
Jens asked me at git-merge if coverage support was still available. Turns out it is, but there were some weirdnesses. So this should fix them. It is relly slow as you still have to run the tests one by one; despite claims in the wild that it is multiprocess- safe but thread-unsafe, I am in fact observing the opposite behavior pretty clearly. (As before, it switches to sequential tests automatically, so you have to edit the Makefile if you want to try with parallel tests.) Below is the coverage-untested-functions output; it seems submodule.c is covered, so there is nothing for Jens to do ;-) Thomas Rast (4): coverage: split build target into compile and test coverage: do not delete .gcno files before building coverage: set DEFAULT_TEST_TARGET to avoid using prove coverage: build coverage-untested-functions by default Makefile | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) --- coverage-untested-functions --- alloc.c: report alloc.c: alloc_report archive-tar.c: write_extended_header attr.c: git_etc_gitattributes builtin#add.c: ignore_removal_cb builtin#apply.c: checkout_target builtin#apply.c: add_name_limit builtin#apply.c: option_parse_exclude builtin#apply.c: option_parse_include builtin#apply.c: option_parse_z builtin#blame.c: read_ancestry builtin#blame.c: sanity_check_refcnt builtin#blame.c: prepare_initial builtin#blame.c: blame_move_callback builtin#branch.c: calc_maxwidth builtin#checkout-index.c: option_parse_z builtin#clone.c: remove_junk_on_signal builtin#commit.c: find_author_by_nickname builtin#config.c: cmd_repo_config builtin#fetch.c: unlock_pack_on_signal builtin#fmt-merge-msg.c: add_branch_desc builtin#for-each-ref.c: copy_advance builtin#grep.c: help_callback builtin#help.c: parse_help_format builtin#help.c: get_man_viewer_info builtin#help.c: check_emacsclient_version builtin#help.c: exec_woman_emacs builtin#help.c: exec_man_konqueror builtin#help.c: exec_man_man builtin#help.c: exec_man_cmd builtin#help.c: add_man_viewer builtin#help.c: supported_man_viewer builtin#help.c: do_add_man_viewer_info builtin#help.c: add_man_viewer_path builtin#help.c: add_man_viewer_cmd builtin#help.c: add_man_viewer_info builtin#help.c: git_help_config builtin#help.c: is_git_command builtin#help.c: prepend builtin#help.c: cmd_to_page builtin#help.c: setup_man_path builtin#help.c: exec_viewer builtin#help.c: show_man_page builtin#help.c: show_info_page builtin#help.c: get_html_page_path builtin#help.c: open_html builtin#help.c: show_html_page builtin#help.c: list_common_guides_help builtin#help.c: cmd_help builtin#index-pack.c: delta_pos_compare builtin#log.c: estimate_commit_count builtin#log.c: show_early_header builtin#log.c: log_show_early builtin#log.c: early_output builtin#log.c: setup_early_output builtin#log.c: finish_early_output builtin#log.c: no_numbered_callback builtin#log.c: header_callback builtin#mailsplit.c: populate_maildir_list builtin#mailsplit.c: maildir_filename_cmp builtin#mailsplit.c: split_maildir builtin#merge-base.c: handle_is_ancestor builtin#merge.c: reset_hard builtin#merge.c: setup_with_upstream builtin#pack-objects.c: pbase_tree_cache_ix_incr builtin#pack-objects.c: try_to_free_from_threads builtin#pack-objects.c: mark_in_pack_object builtin#pack-objects.c: ofscmp builtin#pack-objects.c: add_objects_in_unpacked_packs builtin#pack-objects.c: option_parse_ulong builtin#pack-redundant.c: llist_item_put builtin#pack-redundant.c: llist_item_get builtin#pack-redundant.c: llist_free builtin#pack-redundant.c: llist_init builtin#pack-redundant.c: llist_copy builtin#pack-redundant.c: llist_insert builtin#pack-redundant.c: llist_insert_back builtin#pack-redundant.c: llist_insert_sorted_unique builtin#pack-redundant.c: llist_sorted_remove builtin#pack-redundant.c: llist_sorted_difference_inplace builtin#pack-redundant.c: pack_list_insert builtin#pack-redundant.c: pack_list_size builtin#pack-redundant.c: pack_list_difference builtin#pack-redundant.c: cmp_two_packs builtin#pack-redundant.c: pll_free builtin#pack-redundant.c: get_permutations builtin#pack-redundant.c: is_superset builtin#pack-redundant.c: sizeof_union builtin#pack-redundant.c: get_pack_redundancy builtin#pack-redundant.c: pack_set_bytecount builtin#pack-redundant.c: minimize builtin#pack-redundant.c: load_all_objects builtin#pack-redundant.c: cmp_local_packs builtin#pack-redundant.c: scan_alt_odb_packs builtin#pack-redundant.c: add_pack builtin#pack-redundant.c: add_pack_file builtin#pack-redundant.c: load_all builtin#pack-redundant.c: cmd_pack_redundant builtin#push.c: advise_use_upstream builtin#push.c: advise_checkout_pull_push builtin#push.c: advise_ref_needs_force builtin#read-tree.c: debug_stage builtin#read-tree.c: debug_merge builtin#reflog.c: find_cfg_ent builtin#remote-ext.c: send_git_request builtin#remote-fd.c: command_loop builtin#remote-fd.c: cmd_remote_fd builtin#rev-list.c: show_edge builtin#rev-list.c: print_var_str builtin#rev-list.c: print_var_int
[PATCH 1/4] coverage: split build target into compile and test
Confusingly, the coverage-build target in fact builds with gcov support _and runs tests_. Split it into two targets that actually are named after what they do. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Makefile | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 0f931a2..f98296b 100644 --- a/Makefile +++ b/Makefile @@ -2524,10 +2524,10 @@ check-builtins:: ### Test suite coverage testing # -.PHONY: coverage coverage-clean coverage-build coverage-report +.PHONY: coverage coverage-clean coverage-compile coverage-test coverage-report coverage: - $(MAKE) coverage-build + $(MAKE) coverage-test $(MAKE) coverage-report object_dirs := $(sort $(dir $(OBJECTS))) @@ -2543,8 +2543,10 @@ COVERAGE_CFLAGS = $(CFLAGS) -O0 -ftest-coverage -fprofile-arcs COVERAGE_LDFLAGS = $(CFLAGS) -O0 -lgcov GCOVFLAGS = --preserve-paths --branch-probabilities --all-blocks -coverage-build: coverage-clean +coverage-compile: $(MAKE) CFLAGS=$(COVERAGE_CFLAGS) LDFLAGS=$(COVERAGE_LDFLAGS) all + +coverage-test: coverage-clean-results coverage-compile $(MAKE) CFLAGS=$(COVERAGE_CFLAGS) LDFLAGS=$(COVERAGE_LDFLAGS) \ -j1 test -- 1.8.3.rc1.400.g07d6e4a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] coverage: build coverage-untested-functions by default
Change the 'coverage' target to build coverage-untested-functions by default, so as to make it more discoverable. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 153d24d..6f9d1c7 100644 --- a/Makefile +++ b/Makefile @@ -2529,7 +2529,7 @@ check-builtins:: coverage: $(MAKE) coverage-test - $(MAKE) coverage-report + $(MAKE) coverage-untested-functions object_dirs := $(sort $(dir $(OBJECTS))) coverage-clean-results: -- 1.8.3.rc1.400.g07d6e4a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] coverage: do not delete .gcno files before building
The coverage-compile target depends on coverage-clean, which is supposed to remove the earlier build products that would get in the way of the next coverage test run. However, removing *.gcno is actively wrong. These are the files that contain the compile-time coverage related data. They are only rebuilt if the source is compiled. So if one ran 'make coverage' two times in a row, the second run would remove *.gcno, but then fail to recreate them because neither source files nor build flags have changed. (This remained hidden for so long most likely because any other intervening use of 'make' will change the build flags, causing a full rebuild.) So we make an exception for *.gcno. The *.gcda are the coverage results, written when the gcov-instrumented program is run. We still remove those, so as to get a one-test-run view of the data; you could probably argue the other way too. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Makefile | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index f98296b..99e4d09 100644 --- a/Makefile +++ b/Makefile @@ -2443,7 +2443,7 @@ profile-clean: $(RM) $(addsuffix *.gcda,$(addprefix $(PROFILE_DIR)/, $(object_dirs))) $(RM) $(addsuffix *.gcno,$(addprefix $(PROFILE_DIR)/, $(object_dirs))) -clean: profile-clean +clean: profile-clean coverage-clean $(RM) *.o block-sha1/*.o ppc/*.o compat/*.o compat/*/*.o xdiff/*.o vcs-svn/*.o \ builtin/*.o $(LIB_FILE) $(XDIFF_LIB) $(VCSSVN_LIB) $(RM) $(ALL_PROGRAMS) $(SCRIPT_LIB) $(BUILT_INS) git$X @@ -2525,20 +2525,23 @@ check-builtins:: ### Test suite coverage testing # .PHONY: coverage coverage-clean coverage-compile coverage-test coverage-report +.PHONY: coverage-clean-results coverage: $(MAKE) coverage-test $(MAKE) coverage-report object_dirs := $(sort $(dir $(OBJECTS))) -coverage-clean: +coverage-clean-results: $(RM) $(addsuffix *.gcov,$(object_dirs)) $(RM) $(addsuffix *.gcda,$(object_dirs)) - $(RM) $(addsuffix *.gcno,$(object_dirs)) $(RM) coverage-untested-functions $(RM) -r cover_db/ $(RM) -r cover_db_html/ +coverage-clean: coverage-clean-results + $(RM) $(addsuffix *.gcno,$(object_dirs)) + COVERAGE_CFLAGS = $(CFLAGS) -O0 -ftest-coverage -fprofile-arcs COVERAGE_LDFLAGS = $(CFLAGS) -O0 -lgcov GCOVFLAGS = --preserve-paths --branch-probabilities --all-blocks -- 1.8.3.rc1.400.g07d6e4a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] coverage: set DEFAULT_TEST_TARGET to avoid using prove
If the user sets DEFAULT_TEST_TARGET=prove in his config.mak, that carries over into the coverage tests. Which is really bad if he also sets GIT_PROVE_OPTS=-j.. as that completely breaks the coverage runs. Instead of attempting to mess with the GIT_PROVE_OPTS, just force the test target to 'test' so that we run under make, like we intended all along. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 99e4d09..153d24d 100644 --- a/Makefile +++ b/Makefile @@ -2551,7 +2551,7 @@ coverage-compile: coverage-test: coverage-clean-results coverage-compile $(MAKE) CFLAGS=$(COVERAGE_CFLAGS) LDFLAGS=$(COVERAGE_LDFLAGS) \ - -j1 test + DEFAULT_TEST_TARGET=test -j1 test coverage-report: $(QUIET_GCOV)for dir in $(object_dirs); do \ -- 1.8.3.rc1.400.g07d6e4a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
