Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Tay Ray Chuan]

On Wed, May 15, 2013 at 3:37 AM, Torsten Bögershausen tbo...@web.de wrote:
 Second,
 I was able to do some testing.
 The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

 Turning the screen saver off in Win XP helps that the machine reacts,
 and using process explorer showed that the hanging is happening
 in test cases doing git fetch (or git pull) from a local repository.
 What I can see is one git-fetch.exe together with git-upload-pack.exe

I also managed to run into the intermittent hanging of git-fetch when
running t5510. What I do is keep running the test till it stalls:

  while [ $? -eq 0 ]; do date; ./t5510-fetch.sh -i -v; done

Almost always the git-fetch output looks like this:

  remote: Counting objects: 7, done.
  remote: Compressing objects: 100% (5/5), done.
  remote: Total 6 (delta 1), reused 0 (delta 0)

However my task manager indicates that git-upload-pack or whatever
that runs on the remote side is absent, only git-fetch is waiting - 0
I/O, 0 cswitches, nilda. I tried getting a gdb backtrace but I get ???
nonsense, despite having compiled git with `-g -O0`. I also noticed
there were a couple of threads. This is my gdb session:

$ gdb --pid=7936
GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
...
Attaching to process 7936
[New Thread 7936.0x1c7c]
[New Thread 7936.0x6b8]
[New Thread 7936.0xd20]
[New Thread 7936.0x1cf8]
[New Thread 7936.0x1b24]
Reading symbols from /cygdrive/f/files/coding/git/git.exe...done.
(gdb) info thread
  Id   Target Id Frame
* 5Thread 7936.0x1b24 0x77c5000d in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  4Thread 7936.0x1cf8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  3Thread 7936.0xd20 0x77c5f91d in ntdll!ZwWriteFile ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  2Thread 7936.0x6b8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  1Thread 7936.0x1c7c 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5000d in ntdll!DbgBreakPoint () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77cdf896 in ntdll!DbgUiRemoteBreakin () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x775c5cca in ?? ()
#3  0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 7936.0x1cf8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0148 in ?? ()
#4  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 7936.0xd20)]
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7572dec1 in WriteFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x009c in ?? ()
#4  0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 7936.0x6b8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x001c in ?? ()
#4  0x in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 7936.0x1c7c)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0034 in ?? ()
#4  0x in ?? ()

--
Cheers,
Ray Chuan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

is this a bug of git-diff?

[eric liou]

The output of git-diff is different from my expectation.
It may skip some lines of context.
For the case of the diff result attached here, a blank line and a line
with a leading slash is skipped.

Please check out the attached files for details.

Thanks.


ab.patch
Description: Binary data
int a = 1;

/*
 * 1
 * 2
 * 3
 * added
 */
 int a = 1;

/*
 * 1
 * 2
 * 3
 */
 

Re: Fwd: git cvsimport implications

[Michael Haggerty]

On 05/15/2013 12:19 AM, Junio C Hamano wrote:
 Eugene Sajine eugu...@gmail.com writes:
 
 What if there are a lot of branches in the CVS repo? Is it guaranteed
 to be broken after import?
 
 Even though CVS repository can record branches in individual ,v
 files, reconstructing per branch history and where the branch
 happened in each changeset cannot be determined with any
 certainty.  The best you can get is a heuristic result.
 
 I do not think anybody can give such a guarantee.  The best you can
 do is to convert it and validate if the result matches what you
 think has happened in the CVS history.

Junio, you are correct that there is no 100% reliable way of inferring
the changesets that were made in CVS.  CVS doesn't record which file
revisions were committed at the same time, unambiguous branch points,
etc.  The best a tool can do is use heuristics.

But it *is* possible for a conversion tool to make some more elementary
guarantees regarding aspects of the history that are recorded
unambiguously in CVS, for example:

* That if you check the tip of same branch out of CVS and out of Git,
you get the same contents.

* That CVS file revisions are committed to Git in the correct order
relative to each other; e.g., that the changes made in CVS revision
1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of
the same file.

git-cvsimport fails to ensure even this minimal level of correctness.
Such errors are demonstrated in its own test suite.

cvs2git, on the other hand, gets the basics 100% correct (if you find a
discrepancy, please file a bug!), in addition to having great heuristics
for inferring the details of the history.

There is no reason ever to use git-cvsimport for one-time conversions
from CVS to Git.  The only reason ever to use it is if you absolutely
require an incremental bridge between CVS and Git, and even then please
use it with great caution.

Michael
the cvs2svn/cvs2git maintainer

-- 
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: is this a bug of git-diff?

[Antoine Pelisse]

On Wed, May 15, 2013 at 8:23 AM, eric liou accw...@gmail.com wrote:
 The output of git-diff is different from my expectation.
 It may skip some lines of context.

git-diff is using a default of 3 lines of context above and below the changes.
In your example, there is only two lines of context below the change,
so only two lines are displayed.
Above the change, three lines are displayed, as expected. That's why
the blank line and leading slash line are not displayed.
You can change the number of context lines by invoking git-diff with -Un.

Hope that helps,
Antoine
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Michael Haggerty]

On 05/14/2013 04:24 PM, Johan Herland wrote:
 On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano gits...@pobox.com wrote:
 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.
 
 I think I like refs/peers/%1/heads/%* better than
 refs/peers/%1/heads/%2, since the latter sort of makes me wonder
 whether the 3rd, 4th, etc. components would be discarded. That said,
 having %* mean the rest of the shorthand means that we must adjust
 the expansion of %* for every preceding %N, which prevents us from
 simplifying the code by using strbuf_expand_dict_cb() with a static
 dictionary [1].
 
 I am not sure why we would want refs/remotes/%1/%2 instead of
 refs/remote/%*. Maybe I've been staring at this for too long, but I
 find the latter shorter and more descriptive and the %1/%2 notation
 needlessly cumbersome, especially if it's also supposed to match
 foo/bar/baz

refs/remotes/%1/%2 (or refs/remotes/%1/%*) might be a nice way to
imply that the rule should only be attempted if the input has at least
two components, whereas something like refs/heads/%* would be applied
even for inputs with no slashes.

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: git grep --no-index doesn't do what it says on the tin?

[Antoine Pelisse]

On Wed, May 15, 2013 at 7:32 AM, Nazri Ramliy ayieh...@gmail.com wrote:
 Hi,

 From git help grep:

   --no-index
Search files in the current directory that is not managed by Git.

--untracked
In addition to searching in the tracked files in the working tree,
search also in untracked files.

The difference is in the not managed by Git. Inside a repository,
they will do the same thing. But only the first can work outside a
repository.

Cheers,
Antoine
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

[David Aguilar]

Mac OS X 10.8 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().

COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL
compatibility macros in CommonDigest.h.

Add a NO_APPLE_COMMON_CRYPTO option to the Makefile to allow
users to opt out of using this library.  When defined, Git will
use OpenSSL instead.

Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: David Aguilar dav...@gmail.com
---
Both of these are replacement patches pu.

Changes from last time:

It now uses a single APPLE_COMMON_CRYPTO definition.
Users can now opt-out by setting NO_APPLE_COMMON_CRYPTO.

 Makefile | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index f698c1a..8309c41 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,10 @@ all::
 # specify your own (or DarwinPort's) include directories and
 # library directories by defining CFLAGS and LDFLAGS appropriately.
 #
+# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
+# and do not want to use Apple's CommonCrypto library.  This allows you
+# to provide your own OpenSSL library, for example from MacPorts.
+#
 # Define BLK_SHA1 environment variable to make use of the bundled
 # optimized C SHA1 routine.
 #
@@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+   ifndef NO_APPLE_COMMON_CRYPTO
+   APPLE_COMMON_CRYPTO = YesPlease
+   endif
NO_REGEX = YesPlease
PTHREAD_LIBS =
 endif
@@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
LIB_H += ppc/sha1.h
 else
+ifdef APPLE_COMMON_CRYPTO
+   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 NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
 endif
-- 
1.8.3.rc2.2.gbc955d1

--
To unsubscribe from this list: send the line 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 v5 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X

[David Aguilar]

Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
are deprecated.  Detect the COMMON_CRYPTO_FOR_OPENSSL definition
and use CommonCrypto's HMAC functions to eliminate the warnings.

Signed-off-by: David Aguilar dav...@gmail.com
---
Changes since last time:

This version re-uses the existing COMMON_CRYPTO_FOR_OPENSSL define
instead of tweaking the Makefile to add a new one, so it's simpler.

My previous patch had Jonathan's reviewed-by tag, but he hasn't
reviewed this exact patch, so I removed it.  The C macros are unchanged.

 imap-send.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/imap-send.c b/imap-send.c
index d9bcfb4..96012b1 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -29,8 +29,18 @@
 #ifdef NO_OPENSSL
 typedef void *SSL;
 #else
+#ifdef COMMON_DIGEST_FOR_OPENSSL
+#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.rc2.2.gbc955d1

--
To unsubscribe from this list: send the line 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: is this a bug of git-diff?

[Antoine Pelisse]

On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com wrote:
 Thank you for the quick reply.
 But this line is not correct: @@ -4,5 +4,6 @@ int a = 1;

Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any function so of course the
information is not very helpful.

Typically it will look like the following, helping the reader by
giving the function name:

@@ -591,6 +609,14 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
paths[1] = NULL;
}

+   if (!use_index) {
+   if (cached)
+   die(--cached cannot be used with --no-index.);
+   if (list.nr)
+   die(--no-index cannot be used with revs.);
+   return !grep_directory(opt, paths);
+   }
+
if (!list.nr) {
if (!cached)
setup_work_tree();
--
To unsubscribe from this list: send the line 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

[Johan Herland]

On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 On 05/14/2013 04:24 PM, Johan Herland wrote:
 I am not sure why we would want refs/remotes/%1/%2 instead of
 refs/remote/%*. Maybe I've been staring at this for too long, but I
 find the latter shorter and more descriptive and the %1/%2 notation
 needlessly cumbersome, especially if it's also supposed to match
 foo/bar/baz

 refs/remotes/%1/%2 (or refs/remotes/%1/%*) might be a nice way to
 imply that the rule should only be attempted if the input has at least
 two components, whereas something like refs/heads/%* would be applied
 even for inputs with no slashes.

/me likes, at least for refs/remotes/%1/%*.

...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: is this a bug of git-diff?

[Matthieu Moy]

Antoine Pelisse apeli...@gmail.com writes:

 On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com wrote:
 Thank you for the quick reply.
 But this line is not correct: @@ -4,5 +4,6 @@ int a = 1;

Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @@ ... @@ part would
be colored, but not the function name):

  git config --global color.ui auto

-- 
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: is this a bug of git-diff?

[John Keeping]

On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
 Antoine's answer is correct. In addition, I'd say that you may want to
 enable color in the output to make it clearer (the @@ ... @@ part would
 be colored, but not the function name):
 
   git config --global color.ui auto

I wonder if that should be the default.  I've advised a lot of people to
turn it on and it seems to me that a user is much more likely to go
looking for a turn color off option than realise that color is an
option at all.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Default for color.ui (was Re: is this a bug of git-diff?)

[Matthieu Moy]

John Keeping j...@keeping.me.uk writes:

 I wonder if that should be the default.  I've advised a lot of people to
 turn it on and it seems to me that a user is much more likely to go
 looking for a turn color off option than realise that color is an
 option at all.

I'd love to see this by default, yes. Maybe a 2.0 change?

If people agree that this is a good change, would we need a transition
plan? I'd say no, as there is no real backward incompatibility involved.
People who dislike colors can already set color.ui=false, and seeing
colors can hardly harm them, just temporarily reduce the comfort for
them.

-- 
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: Default for color.ui (was Re: is this a bug of git-diff?)

[Felipe Contreras]

On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 John Keeping j...@keeping.me.uk writes:

 I wonder if that should be the default.  I've advised a lot of people to
 turn it on and it seems to me that a user is much more likely to go
 looking for a turn color off option than realise that color is an
 option at all.

 I'd love to see this by default, yes. Maybe a 2.0 change?

 If people agree that this is a good change, would we need a transition
 plan? I'd say no, as there is no real backward incompatibility involved.
 People who dislike colors can already set color.ui=false, and seeing
 colors can hardly harm them, just temporarily reduce the comfort for
 them.

I vote for this. It's the first thing I do in any setup, even the ones
that are note mine. I've also seen it in basically all the tutorials,
even before setting user.name/email.

I also don't see the point of a transition plan.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: English/German terminology, git.git's de.po, and pro-git

[Holger Hellmuth (IKS)]

Am 14.05.2013 19:51, schrieb Ralf Thielow:

- repository = Projektarchiv
- bare repository = bloßes Projektarchiv
+ repository = Projektarchiv, (or just Repository?)
+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)


I would vote for Repository or if it needs to be translated, simply 
Archiv. Neither Projektarchiv nor Archiv is commonly used by me but 
Archiv is shorter and not everything in a repository is a project.



I'm not sure about using Repository. I think Projektarchiv is
actually good enough.

- committer = Eintragender
- tagger = Markierer
+ committer = Eintragender (or Committer, Commit-Ersteller)
+ tagger = Markierer (or Tagger, Tag-Ersteller)
...[each usage of commit and tag]...


Both commit and tag are used in commands so with the exception of 
the place where they are defined the english words should be used. I 
think Commit-/Tag-Ersteller actually sounds fine and german enough so no 
one notices there is an english word in there ;-)




+ branch = Zweig (or Branch)

I think Zweig is already fine.


Same reason, branch is used as a command and should not be translated. 
But Zweig is a really natural and together with Baum fitting 
translation, so I'm conflicted 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: is this a bug of git-diff?

[Mike Hommey]

On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:
 On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
  Antoine's answer is correct. In addition, I'd say that you may want to
  enable color in the output to make it clearer (the @@ ... @@ part would
  be colored, but not the function name):
  
git config --global color.ui auto
 
 I wonder if that should be the default.  I've advised a lot of people to
 turn it on and it seems to me that a user is much more likely to go
 looking for a turn color off option than realise that color is an
 option at all.

+1. My settings have been there for so long that I thought it was the
default.

Mike
--
To unsubscribe from this list: send the line 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

[Jens Lehmann]

Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):
 Am 14.05.2013 19:51, schrieb Ralf Thielow:
 - repository = Projektarchiv
 - bare repository = bloßes Projektarchiv
 + repository = Projektarchiv, (or just Repository?)
 + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)
 
 I would vote for Repository or if it needs to be translated, simply Archiv. 
 Neither Projektarchiv nor Archiv is commonly used by me but Archiv is shorter 
 and not everything in a repository is a project.

Hmm, I rather tend towards using Repository instead of Archiv too, as
Archiv can mean anything from a tar-file to a git repository, while we are
talking about something very specific here (and a German might be surprised
what the command git archive is about if we use Archiv here ;-). So if
it has to be translated, I like Projektarchiv better than Archiv for
those reasons. We can also think about using Repo as an abbreviated form,
we often use that when talking about repositories in German. That would be a
new term without ambiguity and will be pronounced pretty much correctly by
all Germans too. But this remains one of the tougher questions.

And then pack is currently translated as Archiv:

  pack(noun) = Archiv

but I believe Packdatei would be a much better translation (especially as
the translation of pack(verb) is packen). I find it natural that a file
with the extension .pack is named Packdatei, just like a file with the
extension .zip is a Zipdatei (known by the Duden) in German. And the
Duden already knows Pack as an assembly of smaller parts, so we should be
safe here.

 I'm not sure about using Repository. I think Projektarchiv is
 actually good enough.

 - committer = Eintragender
 - tagger = Markierer
 + committer = Eintragender (or Committer, Commit-Ersteller)
 + tagger = Markierer (or Tagger, Tag-Ersteller)
 ...[each usage of commit and tag]...
 
 Both commit and tag are used in commands so with the exception of the 
 place where they are defined the english words should be used. I think 
 Commit-/Tag-Ersteller actually sounds fine and german enough so no one 
 notices there is an english word in there ;-)

Yup, im my experience committen (to commit), einchecken (to check in),
auschecken (to check out) und taggen (to tag) made it into our daily
German language use. To avoid e.g. having past tenses look strange (like
committet) the combined Form (Commit erstellt) could solve that problem.

 + branch = Zweig (or Branch)

 I think Zweig is already fine.
 
 Same reason, branch is used as a command and should not be translated. But 
 Zweig is a really natural and together with Baum fitting translation, so 
 I'm conflicted here.

Yes, Baum, Wurzel and Zweig are obviously equivalent to tree, root and branch,
so I don't care much if we translate that or not.
--
To unsubscribe from this list: send the line 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

[Jan Engelhardt]

On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:

Hmm, I rather tend towards using Repository instead of Archiv too, as
Archiv can mean anything from a tar-file to a git repository

It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has not made it into ralfth's
latest wiki, but that's the most essential part of a glossary IMHO).

but I believe Packdatei would be a much better translation (especially as
the translation of pack(verb) is packen). I find it natural that a file
with the extension .pack is named Packdatei

While it's spoken Packdatei, the way to actually write it is
.pack-Datei or .pack-Datei.

extension .zip is a Zipdatei (known by the Duden)

If that's how Duden specifies it, it's time to call wrong upon Duden.
It's ZIP-Datei, of course, and follows the same origin (.zip-Datei).
The history of ZIP-Datei can be explained by way of MSDOS showing
the filename in the DIR command without the dot - which is also
why we do not pronounce the dot in .zip- or .pack-Datei.


Yup, im my experience committen (to commit), einchecken (to check in),
auschecken (to check out) und taggen (to tag) made it into our daily
German language use. To avoid e.g. having past tenses look strange (like
committet)

Not so strange. We have other words with -tet.
bitten - erbittete - habe erbittet.
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Matthieu Moy]

Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of git log).

Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skiping this step and starting the
real Git manipualtions earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
blackwhite outputs while they may have prefered colors.

A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling disable colors in git
already tells them how to do so).

A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.

The default value is changed, and the documentation is reworded to
mention color.ui=false first, since the primary use of color.ui after
this change is to disable colors, not to enable it.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
  I'd love to see this by default, yes. Maybe a 2.0 change?
 
  If people agree that this is a good change, would we need a transition
  plan? I'd say no, as there is no real backward incompatibility involved.
  People who dislike colors can already set color.ui=false, and seeing
  colors can hardly harm them, just temporarily reduce the comfort for
  them.
 
 I vote for this. It's the first thing I do in any setup, even the ones
 that are note mine. I've also seen it in basically all the tutorials,
 even before setting user.name/email.
 
 I also don't see the point of a transition plan.

OK, then let's try turning the discussion into code.

I'm starting to wonder why we didn't do this earlier ;-).

 Documentation/config.txt | 11 ++-
 color.c  |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option.  Set it
-   to `always` if you want all output not intended for machine
-   consumption to use color, to `true` or `auto` if you want such
-   output to use color when written to the terminal, or to `false` or
-   `never` if you prefer Git commands not to use color unless enabled
-   explicitly with some other configuration or the `--color` option.
+   to `false` or `never` if you prefer Git commands not to use
+   color unless enabled explicitly with some other configuration
+   or the `--color` option. Set it to `always` if you want all
+   output not intended for machine consumption to use color, to
+   `true` or `auto` (this is the default since Git 2.0) if you
+   want such output to use color when written to the terminal.
 
 column.ui::
Specify whether supported commands should output in columns.
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
 #include cache.h
 #include color.h
 
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
 int color_stdout_is_tty = -1;
 
 /*
-- 
1.8.3.rc1.313.geb32591.dirty

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: English/German terminology, git.git's de.po, and pro-git

[Jens Lehmann]

Am 15.05.2013 13:56, schrieb Jan Engelhardt:
 On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
 but I believe Packdatei would be a much better translation (especially as
 the translation of pack(verb) is packen). I find it natural that a file
 with the extension .pack is named Packdatei
 
 While it's spoken Packdatei, the way to actually write it is
 .pack-Datei or .pack-Datei.

I actually had the '-' in there too until I tried to look up Zip-Datei
in the Duden. While I don't get the leading '.' (I cannot remember having
seen that anywhere, AFAIK the file extensions are always used without the
dot), I'm not a grammar expert and will be fine either way.

 extension .zip is a Zipdatei (known by the Duden)
 
 If that's how Duden specifies it, it's time to call wrong upon Duden.

Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-)

 Yup, im my experience committen (to commit), einchecken (to check in),
 auschecken (to check out) und taggen (to tag) made it into our daily
 German language use. To avoid e.g. having past tenses look strange (like
 committet)
 
 Not so strange. We have other words with -tet.
 bitten - erbittete - habe erbittet.

That example was not the best, what about wenn Du das mergest(?) (if
you merge that), I cannot really say how to write that correctly (as in
German we would want to drop the last 'e', right?). All that goes away
when we use Merge as a noun: wenn Du den Merge machst. But again,
somebody else might come up with a grammatically correct solution for
that I'm missing.
--
To unsubscribe from this list: send the line 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] branch: show me the hot branches

[Phil Hord]

On Tue, May 14, 2013 at 7:34 PM, Junio C Hamano gits...@pobox.com wrote:
 Phil Hord phil.h...@gmail.com writes:

 I imagine it with --date-order and whatnot.

 Perhaps modeled after this one.

 git for-each-ref \
 --format='%(refname:short) %(subject)'
 --sort='-committerdate' refs/heads/


Nice.  I had no idea about for-each-ref.  I knew it was out there, but
not what it could do.  Another tool in the swiss army knife that is
git.

I think Duy was right about his patch's merits.

Phil
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Johan Herland]

On Wed, May 15, 2013 at 2:09 PM, Matthieu Moy matthieu@imag.fr wrote:
 Signed-off-by: Matthieu Moy matthieu@imag.fr

Reviewed and supported-by: Johan Herland jo...@herland.net


...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: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:

 While it's spoken Packdatei, the way to actually write it is
 .pack-Datei or .pack-Datei.

I actually had the '-' in there too until I tried to look up Zip-Datei
in the Duden. While I don't get the leading '.' (I cannot remember having
seen that anywhere, AFAIK the file extensions are always used without the
dot), I'm not a grammar expert and will be fine either way.

In UNIX-land, extension seemed to always include the dot.
In DOS-land, it's without (inherited from VMS too, perhaps?)
As such, either way to write it is acceptable.

 extension .zip is a Zipdatei (known by the Duden)
 
 If that's how Duden specifies it, it's time to call wrong upon Duden.

Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-)

(There seems to be no way to send corrections. Sucks not
to be a wiki.) Ah well that explains their cluelessness:

 nach englisch zip file, zu: to zip = (mit dem Reißverschluss) schließen und
 file = Datei 

ZIP-Datei kommt daher, weil die Erweiterung ZIP/.zip ist, nicht
weil da ein symbolischer Reißverschluss zugezogen wird oder ein
Programmicon selbiges suggerieren will.

Wir haben ja schließlich auch RAR-Dateien, die deswegen so heißen,
weil sie eben .rar als Endung tragen und nicht, weil sie
wertvolle Mangelware sind. ;-)


 Not so strange. We have other words with -tet.
 bitten - erbittete - habe erbittet.

That example was not the best, what about wenn Du das mergest(?) (if

Konjugation wie merken, nur Aussprache mit [dʒ] statt [k]-Laut.
merge/mergst/mergt/mergen/mergt/mergen/mergte/(habe,hatte) (ge)mergt.
Ich sehe da keine Komplikationen.

you merge that), I cannot really say how to write that correctly (as in
German we would want to drop the last 'e', right?)
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Stefano Lattarini]

On 05/15/2013 02:09 PM, Matthieu Moy wrote:
 Most users seem to like having colors enabled, and colors can help
 beginners to understand the output of some commands (e.g. notice
 immediately the boundary between commits in the output of git log).
 
 Many tutorials tell the users to set color.ui=auto as a very first step.
 These tutorials would benefit from skiping

s/skiping/skipping/

 this step and starting the
 real Git manipualtions earlier.

s/manipualtions/manipulations/

 Other beginners do not know about
 color.ui=auto, and may not discover it by themselves, hence live with
 blackwhite outputs while they may have prefered colors.

s/prefered/preferred/

 A few people (e.g. color-blind) prefer having no colors, but they can
 easily set color.ui=never for this (and googling disable colors in git
 already tells them how to do so).
 
 A transition period with Git emitting a warning when color.ui is unset
 would be possible, but the discomfort of having the warning seems
 superior to the benefit: users may be surprised by the change, but not
 harmed by it.
 
 The default value is changed, and the documentation is reworded to
 mention color.ui=false first, since the primary use of color.ui after
 this change is to disable colors, not to enable it.
 
 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---
 I'd love to see this by default, yes. Maybe a 2.0 change?

 If people agree that this is a good change, would we need a transition
 plan? I'd say no, as there is no real backward incompatibility involved.
 People who dislike colors can already set color.ui=false, and seeing
 colors can hardly harm them, just temporarily reduce the comfort for
 them.

 I vote for this. It's the first thing I do in any setup, even the ones
 that are note mine. I've also seen it in basically all the tutorials,
 even before setting user.name/email.

 I also don't see the point of a transition plan.
 
 OK, then let's try turning the discussion into code.
 
 I'm starting to wonder why we didn't do this earlier ;-).
 
  Documentation/config.txt | 11 ++-
  color.c  |  2 +-
  2 files changed, 7 insertions(+), 6 deletions(-)
 
 diff --git a/Documentation/config.txt b/Documentation/config.txt
 index 1009bfc..97550be 100644
 --- a/Documentation/config.txt
 +++ b/Documentation/config.txt
 @@ -913,11 +913,12 @@ color.ui::
   as `color.diff` and `color.grep` that control the use of color
   per command family. Its scope will expand as more commands learn
   configuration to set a default for the `--color` option.  Set it
 - to `always` if you want all output not intended for machine
 - consumption to use color, to `true` or `auto` if you want such
 - output to use color when written to the terminal, or to `false` or
 - `never` if you prefer Git commands not to use color unless enabled
 - explicitly with some other configuration or the `--color` option.
 + to `false` or `never` if you prefer Git commands not to use
 + color unless enabled explicitly with some other configuration
 + or the `--color` option. Set it to `always` if you want all
 + output not intended for machine consumption to use color, to
 + `true` or `auto` (this is the default since Git 2.0) if you
 + want such output to use color when written to the terminal.
  
  column.ui::
   Specify whether supported commands should output in columns.
 diff --git a/color.c b/color.c
 index e8e2681..f672885 100644
 --- a/color.c
 +++ b/color.c
 @@ -1,7 +1,7 @@
  #include cache.h
  #include color.h
  
 -static int git_use_color_default = 0;
 +static int git_use_color_default = GIT_COLOR_AUTO;
  int color_stdout_is_tty = -1;
  
  /*

With the typos above fixed:

  Reviewed and supported-by: Stefano Lattarini stefano.lattar...@gmail.com

Thanks,
  Stefano
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Matthieu Moy]

Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of git log).

Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skiping this step and starting the
real Git manipualtions earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
blackwhite outputs while they may have prefered colors.

A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling disable colors in git
already tells them how to do so).

A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.

The default value is changed, and the documentation is reworded to
mention color.ui=false first, since the primary use of color.ui after
this change is to disable colors, not to enable it.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
 Reviewed and supported-by: Johan Herland jo...@herland.net

Apparently not well enough ;-).

In v1, git config --get-colorbool was not affected, hence git add
-p wasn't colored. v2 fixes this.

 Documentation/config.txt | 11 ++-
 builtin/config.c |  2 +-
 color.c  |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option.  Set it
-   to `always` if you want all output not intended for machine
-   consumption to use color, to `true` or `auto` if you want such
-   output to use color when written to the terminal, or to `false` or
-   `never` if you prefer Git commands not to use color unless enabled
-   explicitly with some other configuration or the `--color` option.
+   to `false` or `never` if you prefer Git commands not to use
+   color unless enabled explicitly with some other configuration
+   or the `--color` option. Set it to `always` if you want all
+   output not intended for machine consumption to use color, to
+   `true` or `auto` (this is the default since Git 2.0) if you
+   want such output to use color when written to the terminal.
 
 column.ui::
Specify whether supported commands should output in columns.
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..ecfceca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -316,7 +316,7 @@ static void get_color(const char *def_color)
 
 static int get_colorbool_found;
 static int get_diff_color_found;
-static int get_color_ui_found;
+static int get_color_ui_found = GIT_COLOR_AUTO;
 static int git_get_colorbool_config(const char *var, const char *value,
void *cb)
 {
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
 #include cache.h
 #include color.h
 
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
 int color_stdout_is_tty = -1;
 
 /*
-- 
1.8.3.rc1.314.g2261e40.dirty

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Trouble with case insensitive filesystem

[Johannes Sixt]

Am 5/15/2013 10:40, schrieb Luc Bourhis:
 I work on a case insensitive filesystem and I have core.ignorecase set to 
 true. 
 ...
 So I thought it was a job for git filter-branch, ...
 
 However because of those two blobs, I have:
 
 ~ git status
 # modified:   .../fourCircles.py
 
 and git filter-branch therefore refuses to run.

Make a commit that has neither file, run git filter-branch, then throw
away the commit with git reset --hard HEAD~.

-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Johan Herland]

On Wed, May 15, 2013 at 9:39 AM, Johan Herland jo...@herland.net wrote:
 On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu 
 wrote:
 refs/remotes/%1/%2 (or refs/remotes/%1/%*) might be a nice way to
 imply that the rule should only be attempted if the input has at least
 two components, whereas something like refs/heads/%* would be applied
 even for inputs with no slashes.

 /me likes, at least for refs/remotes/%1/%*.

Unfortunately, using refs/remotes/%1/%* instead of refs/remotes/%*
breaks a number of git-svn tests which puts refs directly within
refs/remotes/, and then does things like git reset --hard trunk
(expecting trunk - refs/remotes/trunk, which the refs/remotes/%1/%*
doesn't match).

I don't know if putting refs directly within refs/remotes/ is
something that git-svn does by default (which would prevent us from
changing refs/remotes/%* to refs/remotes/%1/%*), or whether it is
specific to the tests (in which case we should fix the tests).

Also, there might be too many other users of refs directly within
refs/remotes/ that expect foo_without_slash to expand to
refs/remotes/foo_without_slash, which would prevent us from doing
this change.


...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

[PATCH v3] make color.ui default to 'auto'

[Matthieu Moy]

Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of git log).

Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skipping this step and starting the
real Git manipulations earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
blackwhite outputs while they may have preferred colors.

A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling disable colors in git
already tells them how to do so).

A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.

The default value is changed, and the documentation is reworded to
mention color.ui=false first, since the primary use of color.ui after
this change is to disable colors, not to enable it.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
v2 crossed Stefano's email with typos. v3 just fixes these typos in
the commit message.

 Documentation/config.txt | 11 ++-
 builtin/config.c |  2 +-
 color.c  |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option.  Set it
-   to `always` if you want all output not intended for machine
-   consumption to use color, to `true` or `auto` if you want such
-   output to use color when written to the terminal, or to `false` or
-   `never` if you prefer Git commands not to use color unless enabled
-   explicitly with some other configuration or the `--color` option.
+   to `false` or `never` if you prefer Git commands not to use
+   color unless enabled explicitly with some other configuration
+   or the `--color` option. Set it to `always` if you want all
+   output not intended for machine consumption to use color, to
+   `true` or `auto` (this is the default since Git 2.0) if you
+   want such output to use color when written to the terminal.
 
 column.ui::
Specify whether supported commands should output in columns.
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..ecfceca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -316,7 +316,7 @@ static void get_color(const char *def_color)
 
 static int get_colorbool_found;
 static int get_diff_color_found;
-static int get_color_ui_found;
+static int get_color_ui_found = GIT_COLOR_AUTO;
 static int git_get_colorbool_config(const char *var, const char *value,
void *cb)
 {
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
 #include cache.h
 #include color.h
 
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
 int color_stdout_is_tty = -1;
 
 /*
-- 
1.8.3.rc1.314.g2261e40.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

Lines missing from git diff-tree -p -c output?

[Matthijs Kooijman]

Hi folks,

while trying to parse git diff-tree output, I found out that in some
cases it appears to generate an incorrect diff (AFAICT). I orginally
found this in a 5-way merge commit in the Linux kernel, but managed to
reduce this to something a lot more managable (an ordinary 2-way merge
on a 6-line file).

To start with the wrong-ness, this is the diff generated:

$ git diff-tree -p -c HEAD
d945a51b6ca22e6e8e550c53980d026f11b05158
diff --combined file
index 3404f54,0eab113..e8c8c18
--- a/file
+++ b/file
@@@ -1,7 -1,5 +1,6 @@@
 +LEFT
  BASE2
  BASE3
  BASE4
- BASE5
+ BASE5MODIFIED
  BASE6

Here, the header claims that the first head has 7 lines, but there really are
only 6 (5 lines of context and one delete line). The numbers for the others
heads are incorrect. In the original diff, the difference was bigger
(first head was stated to have 28 lines, while the output was similar to
the above).

To find out what's going on, we can look at the -m output, which is
correct (or look at the original file contents at the end of this mail).

$ git diff-tree -m -p HEAD
d945a51b6ca22e6e8e550c53980d026f11b05158
diff --git a/file b/file
index 3404f54..e8c8c18 100644
--- a/file
+++ b/file
@@ -1,7 +1,6 @@
 LEFT
-BASE1
 BASE2
 BASE3
 BASE4
-BASE5
+BASE5MODIFIED
 BASE6
d945a51b6ca22e6e8e550c53980d026f11b05158
diff --git a/file b/file
index 0eab113..e8c8c18 100644
--- a/file
+++ b/file
@@ -1,3 +1,4 @@
+LEFT
 BASE2
 BASE3
 BASE4

As you can see here, first head added LEFT, and the second head removed
BASE1 and modified BASE5. In the -c diff-tree output above, this removal of
BASE1 is not shown, but it is counted in the number of lines, causing this
breakage.


Note that to trigger this behaviour, the number of context lines between the
BASE1 and BASE5 must be _exactly_ 3, more or less prevents this bug from
occuring. Also, the LEFT line introduced does not seem to be
essential, but there needed to be some change from both sides in order
to generate a diff at all.

I haven't looked into the code, though I might give that a go later.
Anyone got any clue why this is happening? Is this really a bug, or am I
misunderstanding here?

To recreate the above situation, you can use the following commands:

git init
cat  file EOF
BASE1
BASE2
BASE3
BASE4
BASE5
BASE6
EOF
git add file
git commit -m BASE
git checkout -b RIGHT
cat  file EOF
BASE2
BASE3
BASE4
BASE5MODIFIED
BASE6
EOF
git commit -m RIGHT file
git checkout -b LEFT master
cat  file EOF
LEFT
BASE1
BASE2
BASE3
BASE4
BASE5
BASE6
EOF
git commit -m LEFT file
git merge RIGHT
cat  file EOF
LEFT
BASE2
BASE3
BASE4
BASE5MODIFIED
BASE6
EOF
git add file
git commit --no-edit
git diff-tree -p -c HEAD


Gr.

Matthijs
--
To unsubscribe from this list: send the line 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 v9 1/9] git-clean: refactor git-clean into two phases

[Junio C Hamano]

Jiang Xin worldhello@gmail.com writes:

 2013/5/15 Junio C Hamano gits...@pobox.com:
 @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
 *prefix)
   continue; /* Yup, this one exists unmerged */
   }

 - /*
 -  * we might have removed this as part of earlier
 -  * recursive directory removal, so lstat() here could
 -  * fail with ENOENT.
 -  */
   if (lstat(ent-name, st))
   continue;

 I am guessing that the reason why you removed the comment is because
 during this phase there is no way we might have removed.  But if
 that is the case, does it still make sense to run lstat() and ignore
 errors from the call?


 Run lstat() here is necessary, because we need to check whether
 ent-name points to a file or a directory. If ent points to a directory,
 only add to del_list when user provides '-x' option to git-clean.

Sorry, but that was not the question; we can see st is used
immediately below so somebody needs to fill it.

I was pointing out that the lstat() is expected to fail with ENOENT
but it is not an error worth reporting justification the original
code had to silently ignore an error, because you no longer remove
anything immediately in this part of the code.  Is if () continue
still valid thing to do here, not if () die()?
--
To unsubscribe from this list: send the line 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 v9 1/9] git-clean: refactor git-clean into two phases

[Jiang Xin]

2013/5/15 Junio C Hamano gits...@pobox.com:
 Jiang Xin worldhello@gmail.com writes:

 2013/5/15 Junio C Hamano gits...@pobox.com:
 @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
 *prefix)
   continue; /* Yup, this one exists unmerged */
   }

 - /*
 -  * we might have removed this as part of earlier
 -  * recursive directory removal, so lstat() here could
 -  * fail with ENOENT.
 -  */
   if (lstat(ent-name, st))
   continue;

 I am guessing that the reason why you removed the comment is because
 during this phase there is no way we might have removed.  But if
 that is the case, does it still make sense to run lstat() and ignore
 errors from the call?


 Run lstat() here is necessary, because we need to check whether
 ent-name points to a file or a directory. If ent points to a directory,
 only add to del_list when user provides '-x' option to git-clean.

 Sorry, but that was not the question; we can see st is used
 immediately below so somebody needs to fill it.

 I was pointing out that the lstat() is expected to fail with ENOENT
 but it is not an error worth reporting justification the original
 code had to silently ignore an error, because you no longer remove
 anything immediately in this part of the code.  Is if () continue
 still valid thing to do here, not if () die()?

I'm clear, it could be:

if (lstat(ent-name, st))
die_errno(Cannot lstat '%s', ent-name);


-- 
Jiang Xin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Junio C Hamano]

Johan Herland jo...@herland.net writes:

 On Wed, May 15, 2013 at 9:39 AM, Johan Herland jo...@herland.net wrote:
 On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu 
 wrote:
 refs/remotes/%1/%2 (or refs/remotes/%1/%*) might be a nice way to
 imply that the rule should only be attempted if the input has at least
 two components, whereas something like refs/heads/%* would be applied
 even for inputs with no slashes.

 /me likes, at least for refs/remotes/%1/%*.

 Unfortunately, using refs/remotes/%1/%* instead of refs/remotes/%*
 breaks a number of git-svn tests which puts refs directly within
 refs/remotes/, and then does things like git reset --hard trunk
 (expecting trunk - refs/remotes/trunk, which the refs/remotes/%1/%*
 doesn't match).

Oh, I never thought refs/remotes/%1/%* was a suggestion for a
serious improvement, but was merely a thought experiment if all
the remotes were at least two level names, we could express it like
this to stress that fact.

We already allow 'origin' to refer to refs/remotes/origin/HEAD, so
it is clear refs/remotes/%1/%* alone will not be able to replace
what we have; we need refs/remotes/%* and refs/remotes/%*/HEAD
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

[RFC 0/2] refactor relative_path in path.c

[Jiang Xin]

2013/5/15 Junio C Hamano gits...@pobox.com:
 Jiang Xin worldhello@gmail.com writes:

 +/*
 + * Give path as relative to prefix.
 + *
 + * This function is a combination of path_relative (in quote.c) and
 + * relative_path (in path.c)
 + */
 +static const char *path_relative(const char *in, const char *prefix)
 +{
 +...

 Hmph.  Is it possible to reuse the public one (in path.c) here and
 in quote.c, perhaps after enhancing it a bit to serve needs of the
 callers of two existing ones and the new callers of this one?


These two patches enhance relative_path() in path.c, so that function
relative_path() will return real relative path, not a path strip off
the prefix.

The 2nd patch is a bit aggressive, it refactor all related functions,
remove unnecessary arguments: len and/or prefix_len.

Please review them. They will be prerequisites for the interactive
git-clean patch series.

Jiang Xin (2):
  path.c: refactor relative_path(), not only strip prefix
  quote.c: remove path_relative, use relative_path instead

 builtin/clean.c| 18 +--
 builtin/grep.c |  4 +--
 builtin/ls-files.c | 13 
 path.c | 94 ++
 quote.c| 71 +++--
 quote.h|  7 ++--
 wt-status.c| 17 +-
 7 files changed, 107 insertions(+), 117 deletions(-)

-- 
1.8.3.rc1.404.ga32c147

--
To unsubscribe from this list: send the line 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 1/2] path.c: refactor relative_path(), not only strip prefix

[Jiang Xin]

Original design of relative_path() is simple, just strip the prefix
(*base) from the abosolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.

Refactor relative_path() in path.c to return real relative path, so
that user can reuse this function without reimplement his/her own.
I will use this method for interactive git-clean later. Some of the
implementations are borrowed from path_relative() in quote.c.

Different results for relative_path() before and after this refactor:

base path  abs path  relative (orignal)  relative (refactor)
=    ==  ===
/a/b   /a/b/c/   c/  c/
//a///b/   /a/b//c/  c/  c/
/a/b   /a/b/ .   ./
/a/b/  /a/a  ../
/a/b/  / /   ../../
/a/b/  /a/c  /a/c../c

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 path.c | 94 --
 1 file changed, 74 insertions(+), 20 deletions(-)

diff --git a/path.c b/path.c
index 04ff..4dafa8 100644
--- a/path.c
+++ b/path.c
@@ -444,38 +444,92 @@ int adjust_shared_perm(const char *path)
 const char *relative_path(const char *abs, const char *base)
 {
static char buf[PATH_MAX + 1];
-   int i = 0, j = 0;
+   int abs_off, base_off, i, j;
+   int abs_len, base_len;
 
if (!base || !base[0])
return abs;
-   while (base[i]) {
+
+   abs_len = strlen(abs);
+   base_len = strlen(base);
+
+   abs_off = 0;
+   base_off = 0;
+   i = 0;
+   j = 0;
+   while (i  base_len  j  abs_len  base[i] == abs[j]) {
if (is_dir_sep(base[i])) {
-   if (!is_dir_sep(abs[j]))
-   return abs;
while (is_dir_sep(base[i]))
i++;
while (is_dir_sep(abs[j]))
j++;
-   continue;
-   } else if (abs[j] != base[i]) {
+   base_off = i;
+   abs_off = j;
+   } else {
+   i++;
+   j++;
+   }
+   }
+   if (
+   /* base seems like prefix of abs */
+   i = base_len 
+   /*
+* but /foo is not a prefix of /foobar
+* (i.e. base not end with '/')
+*/
+   base_off  base_len) {
+   if (j = abs_len) {
+   /* abs=/a/b, base=/a/b */
+   abs_off = abs_len;
+   } else if (is_dir_sep(abs[j])) {
+   /* abs=/a/b/c, base=/a/b */
+   while (is_dir_sep(abs[j]))
+   j++;
+   abs_off = j;
+   } else {
+   /* abs=/a/bbb/c, base=/a/b */
+   i = base_off;
+   }
+   } else if (
+  /* abs is short than base (prefix of base) */
+  j = abs_len 
+  /* abs not end with '/' */
+  abs_off  abs_len) {
+   if (is_dir_sep(base[i])) {
+   /* abs=/a/b, base=/a/b/c/ */
+   while (is_dir_sep(base[i]))
+   i++;
+   abs_off = abs_len;
+   }
+   }
+   abs += abs_off;
+   abs_len -= abs_off;
+
+   /* base is prefix of abs */
+   if (i = base_len) {
+   if (*abs == '\0') {
+   strcpy(buf, ./);
+   return buf;
+   } else {
return abs;
}
+   }
+
+   buf[0] = '\0';
+   while (i  base_len) {
+   if (is_dir_sep(base[i])) {
+   strcat(buf, ../);
+   while (is_dir_sep(base[i]))
+   i++;
+   continue;
+   }
i++;
-   j++;
}
-   if (
-   /* /foo is a prefix of /foo */
-   abs[j] 
-   /* /foo is not a prefix of /foobar */
-   !is_dir_sep(base[i-1])  !is_dir_sep(abs[j])
-  )
-   return abs;
-   while (is_dir_sep(abs[j]))
-   j++;
-   if (!abs[j])
-   strcpy(buf, .);
-   else
-   strcpy(buf, abs + j);
+   if (!is_dir_sep(base[base_len - 1]))
+   strcat(buf, ../);
+
+   strcat(buf, abs);
+
return buf;
 }
 
-- 
1.8.3.rc1.404.ga32c147

--
To unsubscribe from this list: send the line 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 2/2] quote.c: remove path_relative, use relative_path instead

[Jiang Xin]

Since there is a enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.

Also refactor related functions, remove unnecessary arguments:
len and/or prefix_len.

Signed-off-by: Jiang Xin worldhello@gmail.com
---
 builtin/clean.c| 18 +++---
 builtin/grep.c |  4 +--
 builtin/ls-files.c | 13 +-
 quote.c| 71 --
 quote.h|  7 +++---
 wt-status.c| 17 ++---
 6 files changed, 33 insertions(+), 97 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..a93c3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -56,7 +56,7 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
if ((force_flag  REMOVE_DIR_KEEP_NESTED_GIT) 
!resolve_gitlink_ref(path-buf, HEAD, 
submodule_head)) {
if (!quiet) {
-   quote_path_relative(path-buf, strlen(path-buf), 
quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
printf(dry_run ?  _(msg_would_skip_git_dir) : 
_(msg_skip_git_dir),
quoted.buf);
}
@@ -70,7 +70,7 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
/* an empty dir could be removed even if it is unreadble */
res = dry_run ? 0 : rmdir(path-buf);
if (res) {
-   quote_path_relative(path-buf, strlen(path-buf), 
quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
}
@@ -94,7 +94,7 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
if (remove_dirs(path, prefix, force_flag, dry_run, 
quiet, gone))
ret = 1;
if (gone) {
-   quote_path_relative(path-buf, 
strlen(path-buf), quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
string_list_append(dels, quoted.buf);
} else
*dir_gone = 0;
@@ -102,10 +102,10 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
} else {
res = dry_run ? 0 : unlink(path-buf);
if (!res) {
-   quote_path_relative(path-buf, 
strlen(path-buf), quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
string_list_append(dels, quoted.buf);
} else {
-   quote_path_relative(path-buf, 
strlen(path-buf), quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -127,7 +127,7 @@ static int remove_dirs(struct strbuf *path, const char 
*prefix, int force_flag,
if (!res)
*dir_gone = 1;
else {
-   quote_path_relative(path-buf, strlen(path-buf), 
quoted, prefix);
+   quote_path_relative(path-buf, quoted, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -262,7 +262,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
if (remove_dirs(directory, prefix, rm_flags, 
dry_run, quiet, gone))
errors++;
if (gone  !quiet) {
-   qname = 
quote_path_relative(directory.buf, directory.len, buf, prefix);
+   qname = 
quote_path_relative(directory.buf, buf, prefix);
printf(dry_run ? _(msg_would_remove) : 
_(msg_remove), qname);
}
}
@@ -272,11 +272,11 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
continue;
res = dry_run ? 0 : unlink(ent-name);
if (res) {
-   qname = quote_path_relative(ent-name, -1, 
buf, prefix);
+   qname = quote_path_relative(ent-name, buf, 
prefix);
warning(_(msg_warn_remove_failed), qname);
errors++;
} else if (!quiet) {
-  

Re: English/German terminology, git.git's de.po, and pro-git

[Holger Hellmuth (IKS)]

Am 15.05.2013 15:14, schrieb Jan Engelhardt:


On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:


While it's spoken Packdatei, the way to actually write it is
.pack-Datei or .pack-Datei.


I actually had the '-' in there too until I tried to look up Zip-Datei
in the Duden. While I don't get the leading '.' (I cannot remember having
seen that anywhere, AFAIK the file extensions are always used without the
dot), I'm not a grammar expert and will be fine either way.


In UNIX-land, extension seemed to always include the dot.
In DOS-land, it's without (inherited from VMS too, perhaps?)
As such, either way to write it is acceptable.


Even in unix-land no one adds a dot because usually the extension is 
named after the data format, only that the file extension is used as the 
common abbreviation (at least that is my interpretation). Compare with 
jpeg. You often write jpeg-Datei instead of jpg-Datei because the data 
format is called jpeg.
This is why I don't think the dot has any reason to be there. I can't 
remember ever seeing anyone writing .jpg-Datei (or .doc-Datei, 
.rar-Datei) except to ask what a .xyz Datei contains (i.e. when he 
doesn't know what the data format is)




--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@imag.fr writes:

 Many tutorials tell the users to set color.ui=auto as a very first step.
 These tutorials would benefit from skiping this step and starting the
 real Git manipualtions earlier. Other beginners do not know about
 color.ui=auto, and may not discover it by themselves, hence live with
 blackwhite outputs while they may have prefered colors.

 A few people (e.g. color-blind) prefer having no colors, but they can
 easily set color.ui=never for this (and googling disable colors in git
 already tells them how to do so).

The above two paragraphs do not make a good justification [*1*].
The former can just as easily websearch for enable colours in git
as the latter would for disable in order to avoid having to live
with distraction while they may have preferred monochrome.

The train of thought that is a sufficient justification for this
change is Our document and third-party tutorials often start with
setting color.ui=auto configuration. leading to Our recommendation
is to enable colour on terminals. which in turn leading to Why is
our default monochrome, against our own recommendation?.  Saying
anything more, like who are the majority or how easily the default
can be overridden, is unnecessary, I think [*2*].

As this is purely a UI thing, and since daa0c3d97176 (color: delay
auto-color decision until point of use, 2011-08-17), the logic to
decide when auto colouring is triggered is centrary controlled
(hence it is much less likely than before that color.ui=auto could
misfire when it shouldn't), I agree that this does not even deserve
a warning. You could even sell it as a pure bugfix (we recommend
users to use auto colouring but we did not set it up for users).

 The default value is changed, and the documentation is reworded to
 mention color.ui=false first, since the primary use of color.ui after
 this change is to disable colors, not to enable it.

Good.

 I'm starting to wonder why we didn't do this earlier ;-).

  Documentation/config.txt | 11 ++-
  color.c  |  2 +-
  2 files changed, 7 insertions(+), 6 deletions(-)

 diff --git a/Documentation/config.txt b/Documentation/config.txt
 index 1009bfc..97550be 100644
 --- a/Documentation/config.txt
 +++ b/Documentation/config.txt
 @@ -913,11 +913,12 @@ color.ui::
   as `color.diff` and `color.grep` that control the use of color
   per command family. Its scope will expand as more commands learn
   configuration to set a default for the `--color` option.  Set it
 + to `false` or `never` if you prefer Git commands not to use
 + color unless enabled explicitly with some other configuration
 + or the `--color` option. Set it to `always` if you want all
 + output not intended for machine consumption to use color, to
 + `true` or `auto` (this is the default since Git 2.0) if you
 + want such output to use color when written to the terminal.

OK, so this is planned for 2.0?


[Footnote]

*1* Unless you have some statistical fact to demonstrate that
beginners who prefer colours are of lessor intelligence than
those who do not, that is.

*2* It unnecessarily muddies the water to bring up which is
majority?.  A poll might reveal more people prefer monochrome, but
in that case, either we keep the default monochrome *and* fix the
tutorial not to suggest auto, or we stick to the recommendation to
use auto colouring.  In other words, I see this change as merely
making the code in line with the spirit of the documentation.
--
To unsubscribe from this list: send the line 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: Lines missing from git diff-tree -p -c output?

[Matthijs Kooijman]

Hi folks,

 $ git diff-tree -p -c HEAD
 d945a51b6ca22e6e8e550c53980d026f11b05158
 diff --combined file
 index 3404f54,0eab113..e8c8c18
 --- a/file
 +++ b/file
 @@@ -1,7 -1,5 +1,6 @@@
  +LEFT
   BASE2
   BASE3
   BASE4
 - BASE5
 + BASE5MODIFIED
   BASE6

I found the spot in the code where this is going wrong, there is an
incorrectly set no_pre_delete flag for the context lines before each
hunk. Since a patch says more than a thousand words, here's what I think
will fix this problem:

diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..d36bfcf 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -518,8 +518,11 @@ static int give_context(struct sline *sline, unsigned long 
cnt, int num_parent)
unsigned long k;
 
/* Paint a few lines before the first interesting line. */
-   while (j  i)
-   sline[j++].flag |= mark | no_pre_delete;
+   while (j  i) {
+   if (!(sline[j++].flag  mark))
+   sline[j++].flag |= no_pre_delete;
+   sline[j++].flag |= mark;
+   }
 
again:
/* we know up to i is to be included.  where does the

I'll see if I can write up a testcase and then submit this as a proper
patch, but I wanted to at least send this over now lest someone wastes
time coming to the same conclusion as I did.

Gr.

Matthijs
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@imag.fr writes:

 diff --git a/builtin/config.c b/builtin/config.c
 index 000d27c..ecfceca 100644
 --- a/builtin/config.c
 +++ b/builtin/config.c
 @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
  
  static int get_colorbool_found;
  static int get_diff_color_found;
 -static int get_color_ui_found;
 +static int get_color_ui_found = GIT_COLOR_AUTO;

It is curious to notice that we have these three and only one is
initialized to the new default value, while the other two get -1
at the beginning of get_colorbool().

I wonder if it would be cleaner to statically initialize all three
to -1 here, drop the assignment of -1 to two of them from the
beginning of get_colorbool(), and then have a final fallback inside
the want_color() call itself, i.e.

get_colorbool_found = want_color(get_colorbool_found  0
? GIT_COLOR_AUTO
: get_colorbool_found);

so that it is clear that -1 consistently mean We haven't read any
value from the configuration file for this variable, instead of
making get_color_ui_found mean slightly different thing (the value
read from the configuration; GIT_COLOR_AUTO means we cannot tell if
we saw this variable or the user specified auto) from the other two
(the value read from the configuration; -1 means we did not find
any).
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@imag.fr writes:

 Many tutorials tell the users to set color.ui=auto as a very first step.
 These tutorials would benefit from skiping this step and starting the
 real Git manipualtions earlier. Other beginners do not know about
 color.ui=auto, and may not discover it by themselves, hence live with
 blackwhite outputs while they may have prefered colors.

 A few people (e.g. color-blind) prefer having no colors, but they can
 easily set color.ui=never for this (and googling disable colors in git
 already tells them how to do so).

 The above two paragraphs do not make a good justification [*1*].
 The former can just as easily websearch for enable colours in git

I disagree: I do not know anyone who would be really harmed by colors
(and such users would most likely have a terminal configured without
colors I guess), so although I can imagine some people feeling less
comfortable, disabling colors can be deferred to much later in the
learning process.

When I teach Git to students (a relatively short tutorial), I currently
ask them to type a ~/.gitconfig containing color.ui=auto before anything
else. If this was the default, I would skip this completely from the
beginner-oriented doc, and I would mention color.ui=never only to people
complaining about colors. It's really about _skipping_ the color-related
stuff from the newbie docs, not about reverting them.

Also, as my message points out, with disabled by default, many people
do not know that it is possible to have it, hence won't google for
anything related to colors. There's no symmetry either here: with colors
enabled by default, people will know that Git can use colors.

 diff --git a/Documentation/config.txt b/Documentation/config.txt
 index 1009bfc..97550be 100644
 --- a/Documentation/config.txt
 +++ b/Documentation/config.txt
 @@ -913,11 +913,12 @@ color.ui::
  as `color.diff` and `color.grep` that control the use of color
  per command family. Its scope will expand as more commands learn
  configuration to set a default for the `--color` option.  Set it
 +to `false` or `never` if you prefer Git commands not to use
 +color unless enabled explicitly with some other configuration
 +or the `--color` option. Set it to `always` if you want all
 +output not intended for machine consumption to use color, to
 +`true` or `auto` (this is the default since Git 2.0) if you
 +want such output to use color when written to the terminal.

 OK, so this is planned for 2.0?

We've lived without this for years, so I'd say it can wait untill Git
2.0. It may give a Wow effect to some users when upgrading ;-).

-- 
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] make color.ui default to 'auto'

[John Keeping]

On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:
 Matthieu Moy matthieu@imag.fr writes:
 
  Many tutorials tell the users to set color.ui=auto as a very first step.
  These tutorials would benefit from skiping this step and starting the
  real Git manipualtions earlier. Other beginners do not know about
  color.ui=auto, and may not discover it by themselves, hence live with
  blackwhite outputs while they may have prefered colors.
 
  A few people (e.g. color-blind) prefer having no colors, but they can
  easily set color.ui=never for this (and googling disable colors in git
  already tells them how to do so).
 
 The above two paragraphs do not make a good justification [*1*].
 The former can just as easily websearch for enable colours in git
 as the latter would for disable in order to avoid having to live
 with distraction while they may have preferred monochrome.
 
 The train of thought that is a sufficient justification for this
 change is Our document and third-party tutorials often start with
 setting color.ui=auto configuration. leading to Our recommendation
 is to enable colour on terminals. which in turn leading to Why is
 our default monochrome, against our own recommendation?.  Saying
 anything more, like who are the majority or how easily the default
 can be overridden, is unnecessary, I think [*2*].
 
 As this is purely a UI thing, and since daa0c3d97176 (color: delay
 auto-color decision until point of use, 2011-08-17), the logic to
 decide when auto colouring is triggered is centrary controlled
 (hence it is much less likely than before that color.ui=auto could
 misfire when it shouldn't), I agree that this does not even deserve
 a warning. You could even sell it as a pure bugfix (we recommend
 users to use auto colouring but we did not set it up for users).
 
  The default value is changed, and the documentation is reworded to
  mention color.ui=false first, since the primary use of color.ui after
  this change is to disable colors, not to enable it.
 
 Good.
 
  I'm starting to wonder why we didn't do this earlier ;-).
 
   Documentation/config.txt | 11 ++-
   color.c  |  2 +-
   2 files changed, 7 insertions(+), 6 deletions(-)
 
  diff --git a/Documentation/config.txt b/Documentation/config.txt
  index 1009bfc..97550be 100644
  --- a/Documentation/config.txt
  +++ b/Documentation/config.txt
  @@ -913,11 +913,12 @@ color.ui::
  as `color.diff` and `color.grep` that control the use of color
  per command family. Its scope will expand as more commands learn
  configuration to set a default for the `--color` option.  Set it
  +   to `false` or `never` if you prefer Git commands not to use
  +   color unless enabled explicitly with some other configuration
  +   or the `--color` option. Set it to `always` if you want all
  +   output not intended for machine consumption to use color, to
  +   `true` or `auto` (this is the default since Git 2.0) if you
  +   want such output to use color when written to the terminal.
 
 OK, so this is planned for 2.0?

I would vote for just considering this a bugfix as you say above and
therefore not worthy of any special treatment, so it should end up in
whatever the next release is after it hits master.

The changes that are being held back for 2.0 change how commands operate
and we don't provide any overrides for those; this is just a cosmetic
change to the default output format.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] make color.ui default to 'auto'

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@imag.fr writes:

 diff --git a/builtin/config.c b/builtin/config.c
 index 000d27c..ecfceca 100644
 --- a/builtin/config.c
 +++ b/builtin/config.c
 @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
  
  static int get_colorbool_found;
  static int get_diff_color_found;
 -static int get_color_ui_found;
 +static int get_color_ui_found = GIT_COLOR_AUTO;

 It is curious to notice that we have these three and only one is
 initialized to the new default value, while the other two get -1
 at the beginning of get_colorbool().

Right. The meaning of the _found suffix is clear for the first two, but
not the last.

 I wonder if it would be cleaner to statically initialize all three
 to -1 here, drop the assignment of -1 to two of them from the
 beginning of get_colorbool(), and then have a final fallback inside
 the want_color() call itself, i.e.

I've left the assignments within the function (I like the initialisation
right before usage, I don't have to worry about how many times the
function is called then), but I've added a patch that initializes
get_color_ui_found to -1 like the others, and does essentially this:

   get_colorbool_found = want_color(get_colorbool_found  0
   ? GIT_COLOR_AUTO
 : get_colorbool_found);

Except I've made it a separate if statement. Then PATCH 2/2 is really
crystal clear.

Reroll comming, with an improved commit message that should adress the
points in the other message.

-- 
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 1/2] config: refactor management of color.ui's default value

[Matthieu Moy]

The meaning of get_colorbool_found and get_diff_color_found is the
config value if found, and -1 otherwise, but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.

Make get_color_ui_found default to -1, and make it explicit that 0 is the
default value when nothing else is found.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
So, this is new, as suggested by Junio.

 builtin/config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..171bad7 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -333,6 +333,7 @@ static int get_colorbool(int print)
 {
get_colorbool_found = -1;
get_diff_color_found = -1;
+   get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
given_config_file, given_config_blob,
respect_includes);
@@ -344,6 +345,10 @@ static int get_colorbool(int print)
get_colorbool_found = get_color_ui_found;
}
 
+   if (get_colorbool_found  0)
+   /* default value if none found in config */
+   get_colorbool_found = 0;
+
get_colorbool_found = want_color(get_colorbool_found);
 
if (print) {
-- 
1.8.3.rc1.315.g4602f33

--
To unsubscribe from this list: send the line 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: Lines missing from git diff-tree -p -c output?

[Junio C Hamano]

Matthijs Kooijman matth...@stdin.nl writes:

 $ git diff-tree -p -c HEAD
 d945a51b6ca22e6e8e550c53980d026f11b05158
 diff --combined file
 index 3404f54,0eab113..e8c8c18
 --- a/file
 +++ b/file
 @@@ -1,7 -1,5 +1,6 @@@
  +LEFT
   BASE2
   BASE3
   BASE4
 - BASE5
 + BASE5MODIFIED
   BASE6

 Here, the header claims that the first head has 7 lines, but there really are
 only 6 (5 lines of context and one delete line). The numbers for the others
 heads are incorrect. In the original diff, the difference was bigger
 (first head was stated to have 28 lines, while the output was similar to
 the above).

The count and the output does look inconsistent.  The hunk header
claims that it is showing:

 - range 1,7 for the first parent but it should be 1,5 (2, 3, 4, 5 and 6) 
   to match the output.
 - range 1,5 for the second parent (left, 2, 3, 4, 5mod, and 6 -- correct)
 - range 1,6 for the result (left, 2, 3, 4, 5mod and 6 -- correct)

If we resurrect the loss of BASE1 from the output, then the
output should have shown:

  +LEFT
 - BASE1
   BASE2
   BASE3
   BASE4
 - BASE5
 + BASE5MODIFIED
   BASE6

which means the numbers shown for the first parent (1, 2, 3, 4, 5
and 6) should be 1,6.

 Note that to trigger this behaviour, the number of context lines between the
 BASE1 and BASE5 must be _exactly_ 3, more or less prevents this bug from
 occuring.

I think the coalescing of two adjacent hunks into one is painting
leading lines interesting to show context but not worth showing
deletion before it incorrectly.

Does this patch fix the issue?

 combine-diff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..7359b84 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -533,7 +533,7 @@ static int give_context(struct sline *sline, unsigned long 
cnt, int num_parent)
k = find_next(sline, mark, j, cnt, 0);
j = adjust_hunk_tail(sline, all_mask, i, j);
 
-   if (k  j + context) {
+   if (k = j + context) {
/* k is interesting and [j,k) are not, but
 * paint them interesting because the gap is small.
 */
--
To unsubscribe from this list: send the line 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

[Jan Engelhardt]

On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:

 I actually had the '-' in there too until I tried to look up Zip-Datei
 in the Duden. While I don't get the leading '.' (I cannot remember having
 seen that anywhere, AFAIK the file extensions are always used without the
 dot), I'm not a grammar expert and will be fine either way.

 In UNIX-land, extension seemed to always include the dot.
 In DOS-land, it's without (inherited from VMS too, perhaps?)
 As such, either way to write it is acceptable.

 Even in unix-land no one adds a dot because usually the extension is named
 after the data format, only that the file extension is used as the common
 abbreviation (at least that is my interpretation). Compare with jpeg. You 
 often
 write jpeg-Datei instead of jpg-Datei because the data format is called jpeg.

That too is correct, and actually a third way of describing files.
For example, .doc/.xls-Datei in speech is very seldom, if at all; MS
Office output has had generally been called Word-Datei,
Excel-Tabelle/-Datei and so on.

What I meant however is that the extension is .jpg (or .jpeg) from
a programming aspect (like, when naïvely trying to figure out the
filetype) as in
  ($name, $ext) = (/^[^\.]+(\..+)?/)

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@imag.fr writes:

 diff --git a/builtin/config.c b/builtin/config.c
 index 000d27c..ecfceca 100644
 --- a/builtin/config.c
 +++ b/builtin/config.c
 @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
  
  static int get_colorbool_found;
  static int get_diff_color_found;
 -static int get_color_ui_found;
 +static int get_color_ui_found = GIT_COLOR_AUTO;

 It is curious to notice that we have these three and only one is
 initialized to the new default value, while the other two get -1
 at the beginning of get_colorbool().

 Right. The meaning of the _found suffix is clear for the first two, but
 not the last.

 I wonder if it would be cleaner to statically initialize all three
 to -1 here, drop the assignment of -1 to two of them from the
 beginning of get_colorbool(), and then have a final fallback inside
 the want_color() call itself, i.e.

 I've left the assignments within the function (I like the initialisation
 right before usage, I don't have to worry about how many times the
 function is called then), but I've added a patch that initializes
 get_color_ui_found to -1 like the others, and does essentially this:

  get_colorbool_found = want_color(get_colorbool_found  0
  ? GIT_COLOR_AUTO
 : get_colorbool_found);

 Except I've made it a separate if statement. Then PATCH 2/2 is really
 crystal clear.

Yeah, sounds good.

 Reroll comming, with an improved commit message that should adress the
 points in the other message.

Hmm, I don't see much improvement in the message, though.  It seems
to talk about may not discover, live with, a few people, and
they can easily, none of which should be there.

--
To unsubscribe from this list: send the line 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: Lines missing from git diff-tree -p -c output?

[Matthijs Kooijman]

Hi Junio,

 I think the coalescing of two adjacent hunks into one is painting
 leading lines interesting to show context but not worth showing
 deletion before it incorrectly.
Yup, that seems to be the case.

 Does this patch fix the issue?

Yes, it fixes the issue. However, I think that this patch actually hides
the real problem (in a way that will always work with the current code,
though).

I had come up with a different fix myself (similar to the one I sent to
the list as a followup, but that one still had a bug), which I think
might be better. In any case, it includes a testcase for this bug which
seems good to include.

I'll send my patch as a followup in a minute, feel free to use it
entirely or only partially.

Gr.

Matthijs
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 The above two paragraphs do not make a good justification [*1*].
 The former can just as easily websearch for enable colours in git

 I disagree: I do not know anyone who would be really harmed by colors
 ...

I actually am one of them (light cyan or green on white background
with small font is very hard to read for me), but I think you are
missing the entire point, which is not is anyone harmed?

This patch is not even about deciding if colored output should be
the default.  That has already been decided by documentation for us
long time ago; the patch does not have to (and should not) argue for
and justify why color is good.  Our recommendation has been use
color=auto, and change of the in-code default is merely to make the
default in line with that recommendation.

--
To unsubscribe from this list: send the line 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: Lines missing from git diff-tree -p -c output?

[Junio C Hamano]

Matthijs Kooijman matth...@stdin.nl writes:

 Hi Junio,

 I think the coalescing of two adjacent hunks into one is painting
 leading lines interesting to show context but not worth showing
 deletion before it incorrectly.
 Yup, that seems to be the case.

 Does this patch fix the issue?

 Yes, it fixes the issue. However, I think that this patch actually hides
 the real problem (in a way that will always work with the current code,
 though).

Could you explain why you think it hides the real problem, and what
kind of future enhancement may break it?

This is *not* my usual rhetorical question Please explain yourself,
because I think you are wrong, but is I do not understand the
reasoning behind your statement, and I (and the reasoning behind my
patch) must be missing something important, so please enlighten me
by pointing out where I am wrong, so that I won't stick to my flawed
patch.

The painting with no_pre_delete is applied when we extend the common
context back to lines we _know_ otherwise not worth showing (because
there is no difference) only because we want to show them as the
context lines and we do not need to show deletions that come before
these common context.  By forcing (k == j + context) case, that is,
there are exactly context number of lines between the end of the
current hunk and the next hunk, which the old code would have showed
context lines at the beginning of the next hunk, to go back to the
again label, we are coalescing the two hunks that _should_ have
been shown together anyway, without painting the context lines
incorrectly with before this line, do not show deletion mark.

 I had come up with a different fix myself (similar to the one I sent to
 the list as a followup, but that one still had a bug), which I think
 might be better. In any case, it includes a testcase for this bug which
 seems good to include.

 I'll send my patch as a followup in a minute, feel free to use it
 entirely or only partially.

 Gr.

 Matthijs
--
To unsubscribe from this list: send the line 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 v5 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

[Torsten Bögershausen]

On 2013-05-15 09.11, David Aguilar wrote:
 Mac OS X 10.8 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().
 
 COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL
 compatibility macros in CommonDigest.h.
 
 Add a NO_APPLE_COMMON_CRYPTO option to the Makefile to allow
 users to opt out of using this library.  When defined, Git will
 use OpenSSL instead.
 
 Helped-by: Eric Sunshine sunsh...@sunshineco.com
 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 Both of these are replacement patches pu.
 
 Changes from last time:
 
 It now uses a single APPLE_COMMON_CRYPTO definition.
 Users can now opt-out by setting NO_APPLE_COMMON_CRYPTO.
 
  Makefile | 13 +
  1 file changed, 13 insertions(+)
 
 diff --git a/Makefile b/Makefile
 index f698c1a..8309c41 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -137,6 +137,10 @@ all::
  # specify your own (or DarwinPort's) include directories and
  # library directories by defining CFLAGS and LDFLAGS appropriately.
  #
 +# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
 +# and do not want to use Apple's CommonCrypto library.  This allows you
 +# to provide your own OpenSSL library, for example from MacPorts.
 +#
  # Define BLK_SHA1 environment variable to make use of the bundled
  # optimized C SHA1 routine.
  #
 @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin)
   BASIC_LDFLAGS += -L/opt/local/lib
   endif
   endif
 + ifndef NO_APPLE_COMMON_CRYPTO
 + APPLE_COMMON_CRYPTO = YesPlease
 + endif
   NO_REGEX = YesPlease
   PTHREAD_LIBS =
  endif
 @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
   LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
   LIB_H += ppc/sha1.h
  else
 +ifdef APPLE_COMMON_CRYPTO
 + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL
 + SHA1_HEADER = CommonCrypto/CommonDigest.h

Would it make sense to replace APPLE_COMMON_CRYPTO
with COMMON_DIGEST_FOR_OPENSSL ?

In the spirit of other Makefile-defines becoming Compiler defines,
a random picked example:
ifdef NO_STRTOULL
COMPAT_CFLAGS += -DNO_STRTOULL
endif

/Torsten
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] make color.ui default to 'auto'

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 I think you are missing the entire point, which is not is anyone
 harmed?

Again, it is. If the new default is really harmful for too many people,
then documentations will have to mention how to fix it.

And really, I do not forsee any newbie-oriented starting with here's
how to disable colors in case you need it, because of the reasons
mentionned in the message.

 Our recommendation has been use color=auto

Not really. Neither Documentation/gittutorial.txt nor
Documentation/user-manual.txt mention colors. Pro Git mentions it, but
more as a possibility than as a recommandation. This is the
recommandation of the rest of the world, not ours.

It's not either we update the docs or we update the code, it's follow
what the rest of the world is doing, and rest of the world has to
imply a notion of majority (not all tutorials talk about color.ui).

-- 
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] combine-diff.c: Fix output when changes are exactly 3 lines apart

[Matthijs Kooijman]

When a deletion is followed by exactly 3 (or whatever the number of
context lines) unchanged lines, followed by another change, the combined
diff output would hide the first deletion, resulting in a malformed
diff.

This happened because the 3 lines before each change are painted
interesting, but also marked as no_pre_delete to prevent showing deletes
that were previously marked as uninteresting. This behaviour was
introduced in c86fbe53 (diff -c/--cc: do not include uninteresting
deletion before leading context). However, as a side effect, this could
also mark deletes that were already interesting as no_pre_delete. This
would happen only if the delete was exactly 3 lines away from the next
change, since lines farther away would not be touched by the paint
three lines before the change code and lines closer would be painted
by the merge two adjacent hunks code instead, which does not set the
no_pre_delete flag.

This commit fixes this problem by only setting the no_pre_delete flag
for changes that were previously uninteresting.

Signed-off-by: Matthijs Kooijman matth...@stdin.nl
---
 combine-diff.c   |  7 +--
 t/t4038-diff-combined.sh | 47 +++
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..3e8bb17 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -518,8 +518,11 @@ static int give_context(struct sline *sline, unsigned long 
cnt, int num_parent)
unsigned long k;
 
/* Paint a few lines before the first interesting line. */
-   while (j  i)
-   sline[j++].flag |= mark | no_pre_delete;
+   while (j  i) {
+   if (!(sline[j].flag  mark))
+   sline[j].flag |= no_pre_delete;
+   sline[j++].flag |= mark;
+   }
 
again:
/* we know up to i is to be included.  where does the
diff --git a/t/t4038-diff-combined.sh b/t/t4038-diff-combined.sh
index 1261dbb..a23ca7e 100755
--- a/t/t4038-diff-combined.sh
+++ b/t/t4038-diff-combined.sh
@@ -353,4 +353,51 @@ test_expect_failure 'combine diff coalesce three parents' '
compare_diff_patch expected actual
 '
 
+# Test for a bug reported at
+# http://thread.gmane.org/gmane.comp.version-control.git/224410
+# where a delete lines were missing from combined diff output when they
+# occurred exactly before the context lines of a later change.
+test_expect_success 'combine diff missing delete bug' '
+   git commit -m initial --allow-empty 
+   cat -\EOF test 
+   1
+   2
+   3
+   4
+   EOF
+   git add test
+   git commit -a -m side1 
+   git checkout -B side1 
+   git checkout HEAD^ 
+   cat -\EOF test 
+   0
+   1
+   2
+   3
+   4modified
+   EOF
+   git commit -a -m side2 
+   git branch -f side2 
+   test_must_fail git merge --no-commit side1 
+   cat -\EOF test 
+   1
+   2
+   3
+   4modified
+   EOF
+   git add test 
+   git commit -a -m merge 
+   git diff-tree -c -p HEAD actual.tmp 
+   sed -e 1,/^@@@/d  actual.tmp actual 
+   tr -d Q -\EOF expected 
+   - 0
+ 1
+ 2
+ 3
+-4
++4modified
+   EOF
+   compare_diff_patch expected actual
+'
+
 test_done
-- 
1.8.3.rc1

--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 Junio C Hamano gits...@pobox.com writes:

 I think you are missing the entire point, which is not is anyone
 harmed?

 Again, it is. If the new default is really harmful for too many people,
 then documentations will have to mention how to fix it.

 And really, I do not forsee any newbie-oriented starting with here's
 how to disable colors in case you need it, because of the reasons
 mentionned in the message.

 Our recommendation has been use color=auto

 Not really. Neither Documentation/gittutorial.txt nor
 Documentation/user-manual.txt mention colors. Pro Git mentions it, but
 more as a possibility than as a recommandation. This is the
 recommandation of the rest of the world, not ours.

Do you mean the git users who learn and use Git without being in the
circle of people who updates Documentation/ hierarchy the rest of
the world?

I think that is a flawed mentality.  They are part of us.

 It's not either we update the docs or we update the code, it's follow
 what the rest of the world is doing, and rest of the world has to
 imply a notion of majority (not all tutorials talk about color.ui).

Yes, exactly.

Read the statement you made again, with the assumption that
everybody (the rest of the world) already knows (and/or agreed to)
colouring is a good thing.

 ... Other beginners do not know about
 color.ui=auto, and may not discover it by themselves, hence live with
 blackwhite outputs while they may have prefered colors.

 A few people (e.g. color-blind) prefer having no colors, but they can
 easily set color.ui=never for this (and googling disable colors in git
 already tells them how to do so).

Now, realize that after switching the default, these few people
have to live with distracting (or unreadable) output.  Because these
people are minority, their websearch disable colors in git will by
definition have smaller number of hits than enable colors in git
the above claims people may not discover it by themselves.  In a
way, you are making things even harder because these minority do not
have many similar others to ask help for.

That is the honest way to express what you said in the second
paragraph.

If we really want to justify the changing of the default, we should
not try to weasel out by using asymmetric wording from the fact that
we are making things less convenient for one kind of people.  We
should be honest and say what we are doing: it will make things
easier for majority while making it less convenient for minority.

I am however saying that in this case, we are better off not even
trying to come up with such a lame excuse for us to hurt color-blind
people in order to make things easier for majority.  Just saying
the rest of the world prefer automatic color and that is what we
recommend, so make the code match should be sufficient.

--
To unsubscribe from this list: send the line 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: Fwd: git cvsimport implications

[Eugene Sajine]

Hi

My primary goal was to understand better what are the real problems
that we might have with the way we use git cvsimport, so I was not
asking about the guarantee of the cvsimport to import things
correctly, but if there is a guarantee the import will result in
completely broken history. IF there is a situation when cvsimport can
do things right and when it definitely going to fail?

Anyway, thanks a lot for the info. I do know that cvs2git is an option.

If the cvsimport is that broken - is there any plan to fix it?

Thanks,
Eugene

On Wed, May 15, 2013 at 2:24 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
 On 05/15/2013 12:19 AM, Junio C Hamano wrote:
 Eugene Sajine eugu...@gmail.com writes:

 What if there are a lot of branches in the CVS repo? Is it guaranteed
 to be broken after import?

 Even though CVS repository can record branches in individual ,v
 files, reconstructing per branch history and where the branch
 happened in each changeset cannot be determined with any
 certainty.  The best you can get is a heuristic result.

 I do not think anybody can give such a guarantee.  The best you can
 do is to convert it and validate if the result matches what you
 think has happened in the CVS history.

 Junio, you are correct that there is no 100% reliable way of inferring
 the changesets that were made in CVS.  CVS doesn't record which file
 revisions were committed at the same time, unambiguous branch points,
 etc.  The best a tool can do is use heuristics.

 But it *is* possible for a conversion tool to make some more elementary
 guarantees regarding aspects of the history that are recorded
 unambiguously in CVS, for example:

 * That if you check the tip of same branch out of CVS and out of Git,
 you get the same contents.

 * That CVS file revisions are committed to Git in the correct order
 relative to each other; e.g., that the changes made in CVS revision
 1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of
 the same file.

 git-cvsimport fails to ensure even this minimal level of correctness.
 Such errors are demonstrated in its own test suite.

 cvs2git, on the other hand, gets the basics 100% correct (if you find a
 discrepancy, please file a bug!), in addition to having great heuristics
 for inferring the details of the history.

 There is no reason ever to use git-cvsimport for one-time conversions
 from CVS to Git.  The only reason ever to use it is if you absolutely
 require an incremental bridge between CVS and Git, and even then please
 use it with great caution.

 Michael
 the cvs2svn/cvs2git maintainer

 --
 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: Lines missing from git diff-tree -p -c output?

[Matthijs Kooijman]

Hi Junio,

 Could you explain why you think it hides the real problem, and what
 kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
line because it is checked in the line before it. In your patch, it
never happens because the control flow guarantees the context lines
before each change must be uninteresting.

The net effect is of course identical, but I'm arguing that depending on
the control flow and some code a doze lines down is easier to break than
depending on a previous line.

Having said that: I'm not sure if the difference is significant enough
to convince me in either direction.



However, thinking about this a bit more (and getting sidetracked on a
completely separate issue/question), I wonder why the coalescing-hunks
code is there in the first place? e.g., why not leave out these lines?

if (k  j + context) {
/* k is interesting and [j,k) are not, but
 * paint them interesting because the gap is small.
 */
while (j  k)
sline[j++].flag |= mark;
i = k;
goto again;
}

If the context lines before and after each group of changes are
painted interesting, then these lines in between will also be painted
interesting. Of course, this could cause some lines to be painted as
interesting twice and it needs my fix for the no_pre_delete thing, but
it would work just as well?

However, I can imagine that this code is present to prevent painting
lines twice, which would of course be a bit of a performance loss. But
if this really was the motivation, why is the first if not something
like:

if (k = j + 2 * context) {

Since IIUC, the current code can still paint a few context lines twice
when they are exacly context lines apart, once by the paint before
and one by the paint after code (which is also what happens in my bug
example, I think). The above should fix that as well (the first part
of the test suite hasn't complained so far).

Gr.

Matthijs
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Now, realize that after switching the default, these few people
 have to live with distracting (or unreadable) output.  Because these
 people are minority, their websearch disable colors in git will by
 definition have smaller number of hits than enable colors in git
 the above claims people may not discover it by themselves.

As my message says, disable colors in git already gives you the
answer, today (1st hit in Google). I'm not worried about the difficulty
to find the information in the future.

 We should be honest and say what we are doing: it will make things
 easier for majority while making it less convenient for minority.

I thought this was what I did, but your first complain was I was
mentionning the majority, and you are now suggesting something about
majority/minority, so I'm lost.

In any case, feel free to change the commit message, what's really
important is the actual change, and it does not seem controversial.

-- 
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: [RFC 0/2] refactor relative_path in path.c

[Junio C Hamano]

Jiang Xin worldhello@gmail.com writes:

 These two patches enhance relative_path() in path.c, so that function
 relative_path() will return real relative path, not a path strip off
 the prefix.

 The 2nd patch is a bit aggressive, it refactor all related functions,
 remove unnecessary arguments: len and/or prefix_len.

I did not particularly find the second one aggressive; it would
have been much more pleasant to review if the drop unused 'len'
part were made into a separate patch [3/2] as a follow-up, though.

It is a bit sad that relative_path() in [1/2] uses a single static
and fixed sized buffer.  How is the new implementation making sure
the expanded result does not overflow the buf[]?
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 We should be honest and say what we are doing: it will make things
 easier for majority while making it less convenient for minority.

 I thought this was what I did, but your first complain was I was
 mentionning the majority, and you are now suggesting something about
 majority/minority, so I'm lost.

Not really.  My main complaint is that you were making it sound as
if the inconvenience for the majority is very severe with many
not discover, live with, and such phrases, while making the
inconveience you are placing on the minority trivial with easily
set and already tells them.  That sounds a lot more like making a
lame excuse than doing a balanced analysis of pros and cons of the
change.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Lines missing from git diff-tree -p -c output?

[Junio C Hamano]

Matthijs Kooijman matth...@stdin.nl writes:

 Could you explain why you think it hides the real problem, and what
 kind of future enhancement may break it?
 I think the differences is mostly in the locality of the fix. In my
 proposed patch, the no_pre_delete flag is never set on an interesting
 line because it is checked in the line before it. In your patch, it
 never happens because the control flow guarantees the context lines
 before each change must be uninteresting.

 The net effect is of course identical, but I'm arguing that depending on
 the control flow and some code a doze lines down is easier to break than
 depending on a previous line.

Yeah, that sounds like a reasonable reasoning.

--
To unsubscribe from this list: send the line 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 05/10] remote-hg: fix new branch creation

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 Felipe Contreras wrote:
 When force_push is disabled, we need to turn the argument to True.

With your follow-up clarification, here is what ended up in the log
message:

remote-hg: fix new branch creation

When a user creates a new branch with git:

  $ git checkout -b branches/devel

and then pushes this branch

  $ git push origin branches/devel

which is the way to push new mercurial branches, we do want to
create a branch, but the command would fail without newbranch=True.

This only matters when force_push=False, but setting newbranch=True
unconditionally does not hurt.

The only part that I came up with on my own is but ... does not
hurt at the end.  If that is incorrect, please supply an update.

Thanks.

 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
 ---
  contrib/remote-helpers/git-remote-hg | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/contrib/remote-helpers/git-remote-hg 
 b/contrib/remote-helpers/git-remote-hg
 index 4a5c72f..3cf9b4c 100755
 --- a/contrib/remote-helpers/git-remote-hg
 +++ b/contrib/remote-helpers/git-remote-hg
 @@ -856,7 +856,7 @@ def do_export(parser):
  continue
  
  if peer:
 -parser.repo.push(peer, force=force_push)
 +parser.repo.push(peer, force=force_push, newbranch=True)
  
  # handle bookmarks
  for bmark, node in p_bmarks:
 -- 
 1.8.3.rc1.579.g184e698
--
To unsubscribe from this list: send the line 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] make color.ui default to 'auto'

[Felipe Contreras]

On Wed, May 15, 2013 at 1:32 PM, Junio C Hamano gits...@pobox.com wrote:
 Matthieu Moy matthieu@grenoble-inp.fr writes:

 We should be honest and say what we are doing: it will make things
 easier for majority while making it less convenient for minority.

 I thought this was what I did, but your first complain was I was
 mentionning the majority, and you are now suggesting something about
 majority/minority, so I'm lost.

 Not really.  My main complaint is that you were making it sound as
 if the inconvenience for the majority is very severe with many
 not discover, live with, and such phrases, while making the
 inconveience you are placing on the minority trivial with easily
 set and already tells them.  That sounds a lot more like making a
 lame excuse than doing a balanced analysis of pros and cons of the
 change.

I could barely parse this, but I've found that many colleagues didn't
know about this configuration. And I don't see why anybody would not
want this. The minority that don't want this can search the interwebs
to find out how to disable the unwanted behavior, so the majority that
do want this don't have to enable it all the time (*if* they know
about it).

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/10] remote-hg: fix new branch creation

[Felipe Contreras]

On Wed, May 15, 2013 at 2:40 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Felipe Contreras wrote:
 When force_push is disabled, we need to turn the argument to True.

 With your follow-up clarification, here is what ended up in the log
 message:

 remote-hg: fix new branch creation

 When a user creates a new branch with git:

   $ git checkout -b branches/devel

 and then pushes this branch

   $ git push origin branches/devel

 which is the way to push new mercurial branches,

I don't like this part. This is not documentation, this is a commit
message. You don't explain how git works in every commit message. It's
not relevant how to create Mercurial branches, it could be done
through a totally different way and it wouldn't affect this patch. The
only thing that is relevant is that a new Mercurial branch is created
somehow.

But since you never, *ever*, agree that a piece of information in the
commit message is not useful, I realize this is wasted breath.

 we do want to
 create a branch, but the command would fail without newbranch=True.

 This only matters when force_push=False, but setting newbranch=True
 unconditionally does not hurt.

 The only part that I came up with on my own is but ... does not
 hurt at the end.  If that is incorrect, please supply an update.

It's correct.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Eric Wong]

Johan Herland jo...@herland.net wrote:
 Unfortunately, using refs/remotes/%1/%* instead of refs/remotes/%*
 breaks a number of git-svn tests which puts refs directly within
 refs/remotes/, and then does things like git reset --hard trunk
 (expecting trunk - refs/remotes/trunk, which the refs/remotes/%1/%*
 doesn't match).
 
 I don't know if putting refs directly within refs/remotes/ is
 something that git-svn does by default (which would prevent us from
 changing refs/remotes/%* to refs/remotes/%1/%*), or whether it is
 specific to the tests (in which case we should fix the tests).

Yes, git-svn uses refs/remotes/%* by default.

This was a design mistake on my part.  I think it's too late to change,
now, as existing users will encounter breakage and/or out-of-date
documentation (which is even more confusing, as git-svn is often the
first introduction to git for SVN users).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-svn: introduce --parents parameter for commands branch and tag

[Tobias Schulte]

On 15.05.2013 04:35, Eric Wong wrote:
 +if (!eval{$ctx-ls($parent, 'HEAD', 0)}) {
 +mk_parent_dirs($ctx, $parent);
 +print Creating parent folder ${parent} ...\n;
 +$ctx-mkdir($parent)
 +unless $_dry_run;
 
 The newline is confusing, I prefer:
 
   $ctx-mkdir($parent) unless $_dry_run;

In fact, this was a copy/paste from a few lines above

print Copying ${src} at r${rev} to ${dst}...\n;
$ctx-copy($src, $rev, $dst)
unless $_dry_run;

 Howeve :
 
   if (!$_dry_run) {
   $ctx-mkdir($parent);
   }
 
 May be preferred, too (especially for the non-Perl-fluent)

I am a non-Perl-fluent, as I come from the Java world with some
knowledge of C and C++. But to be able to create the patch I had to
gather some Perl knowledge, and by doing this, I learned enough to
understand, that there is more than one way, ... Especially the
constructs if (condition) foo(); vs foo() if (condition); and the same
for unless. And since the dry_run is the exception in this case, I think
unless is a valid choice -- and is used often in git-svn.perl. So I will
stick to it, but remove the newline.

 
 +++ b/t/t9167-git-svn-cmd-branch-subproject.sh
 
 +test_expect_success 'initialize svnrepo' '
 +mkdir import 
 +(
 +(cd import 
 +mkdir -p trunk/project branches tags 
 +(cd trunk/project 
 +echo foo  foo
 +) 
 
 Tabs for all indentation, and indent consistently for subshells:
 
   mkdir import 
   (
   cd import 
   mkdir .. 
   (
   cd .. 
   ..
   )
   )
 
 We use subshells + cd like this so it's easier to read/maintain.

Again, this was a copy/paste from t9128-git-svn-cmd-branch.sh. So this
file needs some cosmetics, too. And t9127... as well...

 
 Thanks again, looking forward to applying v2.
 

I will send v2 soon.

Tobias

--
To unsubscribe from this list: send the line 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] git-svn: introduce --parents parameter for commands branch and tag

[Tobias Schulte]

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 |   19 +++-
 t/t9167-git-svn-cmd-branch-subproject.sh |   48 ++
 3 files changed, 71 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..842ff83 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..d070de0 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,17 @@ sub cmd_branch {
$gs-fetch_all;
 }
 
+sub mk_parent_dirs {
+   my ($ctx, $parent) = @_;
+   $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..53def87
--- /dev/null
+++ b/t/t9167-git-svn-cmd-branch-subproject.sh
@@ -0,0 +1,48 @@
+#!/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 

[RFC] New kind of upstream branch: base branch

[Felipe Contreras]

Hi,

I've been using Git from the start, but only lately have I forced myself to
configure upstream branches for all my branches, and I've found a few things
more convenient, but others completely contrary to what I expected.

Inconvenient:

Before, I used to do 'git fetch' to simply fetch from 'origin', but now, it
depends on where 'upstream' is set to.

Convinient:

Now, I can just do 'git rebase --interactive' and I don't have to specify the
starting point, which is particularily useful when there's a lot of branches
one depending on another.

I think I'm using 'upstream' for something it was not intended to, and I think
the current 'upstream' behavior should be split into 'upstream' and 'base'.

== base ==

The 'base' branch will be set each time you create a branch from another;
'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.

Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will
pick the right branch to rebase unto, even if you have no 'upstream'
configured.

This way 'git fetch' will keep picking 'origin', and other commands that make
use of 'upstrem' would be undisturbed.

If both 'base' and 'upstream' are defined, I think 'git rebase' should use
'base', but since that would break old behavior, perhaps there should be a
configuration variable to enable a different behavior.

I already started writting the patches, and although tedious, I think they
they'll be rather straightforward, but I thought it would be best to hear some
opinions first.

What do you think?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] New kind of upstream branch: base branch

[Felipe Contreras]

Hi,

I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.

Inconvenient:

Before, I used to do 'git fetch' to simply fetch from 'origin', but
now, it depends on where 'upstream' is set to.

Convinient:

Now, I can just do 'git rebase --interactive' and I don't have to
specify the starting point, which is particularily useful when there's
a lot of branches one depending on another.

I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.

== base ==

The 'base' branch will be set each time you create a branch from another;
'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.

Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and
Git will pick the right branch to rebase unto, even if you have no
'upstream'
configured.

This way 'git fetch' will keep picking 'origin', and other commands
that make use of 'upstream' would be undisturbed.

If both 'base' and 'upstream' are defined, I think 'git rebase' should
use 'base', but since that would break old behavior, perhaps there
should be a configuration variable to enable a different behavior.

I already started writting the patches, and although tedious, I think
they they'll be rather straightforward, but I thought it would be best
to hear some opinions first.

What do you think?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] New kind of upstream branch: base branch

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 The 'base' branch will be set each time you create a branch from another;
 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.

git checkout -t -b foobar mastee would instead set 'upstream' of
'foobar' to the branch 'master' of remote '.' (the current one).
This 'base' is a new mechanism to explicitly say The upstream of
this branch lives locally by not setting branch.foobar.remote.

 Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git 
 will
 pick the right branch to rebase unto, even if you have no 'upstream'
 configured.

Surely you can teach rebase to pay attention to 'base' and achieve
that.  But you can already do so with upstream, so this is not an
advertisement of a 'plus', but rather a lack of 'minus' (which is
not a bad thing at all).

 This way 'git fetch' will keep picking 'origin', and other commands that make
 use of 'upstrem' would be undisturbed.

And this is the true plus, because 'git fetch' with the current
setting a local base using the same upstream mechanism to point at
a branch of _this_ repository, indirectly setting the upstream
_repository_ for this branch to the current repository will end up
making you fetch from yourself, which is not very interesting.

So I think I understand your itch and I agree that it is a valid
one.

I however am not yet convinced if that direction is what you really
want go in, though.  What should your 'git pull' on that branch do,
for example?

When you are on foobar and want to integrate with the branch you
based your work on (i.e. local 'master'), you can do one of these:

$ git pull
$ git pull --rebase

to fetch the upstream branch and integrate with it, without having
to even care if that upstream branch is from the remote, or happens
to be truly local.  By making 'git fetch' to go to the remote origin
site, what will you be merging (or rebasing on) when you do the
above two?

Incidentally, I suspect you can do exactly the same thing without
introducing a new concept base and instead special casing a remote
whose URL is .; you essentially declare that The upstream of this
branch whose branch.$name.remote is set to '.' lives locally, which
is not all that different from saying The upstream of this branch
whose branch.$name.base exists lives locally, which is what you
seem to be proposing.  One of the things this alternative approach
would special case such remote is probably to cause git fetch to
ignore such a branch.$name.remote setting and instead go fetch from
'origin', just like your if there is branch.$name.base, but no
branch.$name.remote, fetch will go to 'origin' does.

But it has exactly the same what happens when you do 'git pull'
problem, so even though it is conceptually a lot simpler, it has the
same brokenness.
--
To unsubscribe from this list: send the line 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] New kind of upstream branch: base branch

[Philip Oakley]

From: Felipe Contreras felipe.contre...@gmail.com
Sent: Wednesday, May 15, 2013 9:34 PM

Hi,

I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.

Inconvenient:

Before, I used to do 'git fetch' to simply fetch from 'origin', but
now, it depends on where 'upstream' is set to.

Convinient:

Now, I can just do 'git rebase --interactive' and I don't have to
specify the starting point, which is particularily useful when there's
a lot of branches one depending on another.

I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.

== base ==

The 'base' branch will be set each time you create a branch from 
another;
'git checkout -b foobar master' sets 'master' as the 'base' of 
'foobar'.


Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and
Git will pick the right branch to rebase unto, even if you have no
'upstream'
configured.

This way 'git fetch' will keep picking 'origin', and other commands
that make use of 'upstream' would be undisturbed.

If both 'base' and 'upstream' are defined, I think 'git rebase' should
use 'base', but since that would break old behavior, perhaps there
should be a configuration variable to enable a different behavior.

I already started writting the patches, and although tedious, I think
they they'll be rather straightforward, but I thought it would be best
to hear some opinions first.

What do you think?

--
Felipe Contreras

---
Sound a reasonable idea. On some patches I was working on I had to 
[chose to] add a tag for the base which made it easier to rebase later.


The other point is that I had already noted that the glossary doesn't 
include the many base terms in use that aren't always well understood.


Philip Oakley 


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] git-submodule.txt: Clarify 'init' and 'add' subcommands.

[Dale R. Worley]

Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.

Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere.  Describe that
path arguments limit the submodules that are configured.

Signed-off-by: Dale Worley wor...@ariadne.com
---
This patch seems to have all the features that we have discussed:

- Describes how 'add' selects the submodule logical name, including
  the effect of --name.  (My first patch was on a version of Git that
  did not support --name, so I didn't know of it.)

- Corrects description of 'init' to clarify that its behavior is
  driven by the gitlinks recorded in the index, rather than implying
  it is driven by the contents of .gitmodules.

- Describes 'init' behavior to be driven by the index, rather than my
  previous incorrect use of file tree.  (Of course, gitlinks aren't
  visible in the file tree.)

- Updated text for 'init' is shorter and less technical than my
  previous patch.

- Since (which were added and committed elsewhere) is stated in the
  first sentence, I've removed the later sentence explaining that
  submodules must be added before they can be inited.

- Explains the effect of path arguments to 'init' subcommand.

 Documentation/git-submodule.txt |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index c99d795..83235c0 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -76,6 +76,8 @@ argument path is the relative location for the cloned 
submodule
 to exist in the superproject. If path is not given, the
 humanish part of the source repository is used (repo for
 /path/to/repo.git and foo for host.xz:foo/.git).
+The path is also used as the submodule's logical name in its
+configuration entries unless `--name` is used to specify a logical name.
 +
 repository is the URL of the new submodule's origin repository.
 This may be either an absolute URL, or (if it begins with ./
@@ -123,8 +125,10 @@ linkgit:git-status[1] and linkgit:git-diff[1] will provide 
that information
 too (and can also report changes to a submodule's work tree).
 
 init::
-   Initialize the submodules, i.e. register each submodule name
-   and url found in .gitmodules into .git/config.
+   Initialize the submodules recorded in the index (which were
+   added and committed elsewhere) by copying submodule
+   names and urls from .gitmodules to .git/config.
+   Optional path arguments limit which submodules will be initialized.
It will also copy the value of `submodule.$name.update` into
.git/config.
The key used in .git/config is `submodule.$name.url`.
-- 
1.7.7.6

--
To unsubscribe from this list: send the line 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] New kind of upstream branch: base branch

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 I however am not yet convinced if that direction is what you really
 want go in, though.  What should your 'git pull' on that branch do,
 for example?

 When you are on foobar and want to integrate with the branch you
 based your work on (i.e. local 'master'), you can do one of these:

 $ git pull
 $ git pull --rebase

 to fetch the upstream branch and integrate with it, without having
 to even care if that upstream branch is from the remote, or happens
 to be truly local.  By making 'git fetch' to go to the remote origin
 site, what will you be merging (or rebasing on) when you do the
 above two?

 Incidentally, I suspect you can do exactly the same thing without
 introducing a new concept base and instead special casing a remote
 whose URL is .; you essentially declare that The upstream of this
 branch whose branch.$name.remote is set to '.' lives locally, which
 is not all that different from saying The upstream of this branch
 whose branch.$name.base exists lives locally, which is what you
 seem to be proposing.  One of the things this alternative approach
 would special case such remote is probably to cause git fetch to
 ignore such a branch.$name.remote setting and instead go fetch from
 'origin', just like your if there is branch.$name.base, but no
 branch.$name.remote, fetch will go to 'origin' does.

 But it has exactly the same what happens when you do 'git pull'
 problem, so even though it is conceptually a lot simpler, it has the
 same brokenness.

I do not think of a good way to fix the 'git pull' confusion; the
desire to 'fetch from the overall upstream repository regardless of
which branch I am on' is a valid and understandable one, but that
does not mesh well with 'git pull' is 'git fetch' followed by
either merge or rebase to integrate the result and git merge or
git rebase pays attention to the other branch that is specified to
integrate with.  The best we could do might be to simply forbid
git pull if your current branch is marked with branch.$name.base
but still allow git fetch.

The changes that are involved are:

 * Do not change anything to @{upstream}'s definition, that is,
   checkout -t -b A localbranch will set branch.A.remote to '.',
   and git log A@{u}..A will stand for git log localbranch..A.

 * Current 'git fetch' pays attention to branch.A.remote when you
   are on branch A, and tries to fetch from there.  Stop doing that
   when branch.A.remote is set to '.' (the current repository) and
   let other rules in the current implementation decide what remote
   to fetch from. Also teach it to error out when branch.A.remote is
   set to '.' when a new --forbid-local option is passed.

 * Teach 'git pull' to pass --forbid-local option to 'git fetch',
   and let an error return fail the whole thing.

Ah, alternatively, instead of adding --forbid-local, we could modify
the changes for 'git fetch' and 'git pull' to read like this:

 * Current 'git fetch' pays attention to branch.A.remote when you
   are on branch A, and tries to fetch from there.  Stop doing that
   when branch.A.remote is set to '.' (the current repository) and
   let other rules in the current implementation decide what remote
   to fetch from, unless a new --allow-fetch-from-local option is
   passed.

 * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.

If we did this, we can keep the git pull [--rebase] as a way to
integrate with what you specified as your upstream, which is a
common expectation, without forcing you to say git fetch origin.
--
To unsubscribe from this list: send the line 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] New kind of upstream branch: base branch

[Felipe Contreras]

On Wed, May 15, 2013 at 5:20 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 The 'base' branch will be set each time you create a branch from another;
 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.

 git checkout -t -b foobar mastee would instead set 'upstream' of
 'foobar' to the branch 'master' of remote '.' (the current one).

Yeah, but I don't to set an upstream, because 'master' is not the
upstream of 'foobar'.

 This 'base' is a new mechanism to explicitly say The upstream of
 this branch lives locally by not setting branch.foobar.remote.

No, 'base' can point to a remote tracking branch.

 Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git 
 will
 pick the right branch to rebase unto, even if you have no 'upstream'
 configured.

 Surely you can teach rebase to pay attention to 'base' and achieve
 that.  But you can already do so with upstream, so this is not an
 advertisement of a 'plus', but rather a lack of 'minus' (which is
 not a bad thing at all).

Only if there's an upstream configured, which many times is not the
case, and many times causes side-effects the user doesn't want to.

The purpose of 'upstream' is completely different.

 This way 'git fetch' will keep picking 'origin', and other commands that make
 use of 'upstrem' would be undisturbed.

 And this is the true plus, because 'git fetch' with the current
 setting a local base using the same upstream mechanism to point at
 a branch of _this_ repository, indirectly setting the upstream
 _repository_ for this branch to the current repository will end up
 making you fetch from yourself, which is not very interesting.

 So I think I understand your itch and I agree that it is a valid
 one.

 I however am not yet convinced if that direction is what you really
 want go in, though.  What should your 'git pull' on that branch do,
 for example?

Exactly the same as 'git pull' does right now.

'base' has absolutely nothing to do with pulling or pushing.

 When you are on foobar and want to integrate with the branch you
 based your work on (i.e. local 'master'), you can do one of these:

 $ git pull
 $ git pull --rebase

 to fetch the upstream branch and integrate with it, without having
 to even care if that upstream branch is from the remote, or happens
 to be truly local.  By making 'git fetch' to go to the remote origin
 site, what will you be merging (or rebasing on) when you do the
 above two?

The same as we do now.

 Incidentally, I suspect you can do exactly the same thing without
 introducing a new concept base and instead special casing a remote
 whose URL is .; you essentially declare that The upstream of this
 branch whose branch.$name.remote is set to '.' lives locally, which
 is not all that different from saying The upstream of this branch
 whose branch.$name.base exists lives locally, which is what you
 seem to be proposing.

That would be good, but it doesn't have the same benefits:

If I have set an 'upstream' branch, say 'github/master', and I have
'base' branch, say 'origin/master'. I would expect 'git rebase' to
rebase onto 'origin/master'. When I do 'git push', I expect to push to
'github/master'. Moreover, I would expect 'git fetch' to fetch from
'origin', but that can be discussed later.

Right now I'm forced to choose a single branch and set it to
'upstream'. If I choose 'origin/master' (which is not really the
upstream), the rebase would do what I want, but not the push, unless I
have configured a remote.pushdefault, but that would only work if I
the real upstream is the common one. If I choose 'github/master', then
rebase would not do what I want (and neither would fetch).

 One of the things this alternative approach
 would special case such remote is probably to cause git fetch to
 ignore such a branch.$name.remote setting and instead go fetch from
 'origin', just like your if there is branch.$name.base, but no
 branch.$name.remote, fetch will go to 'origin' does.

 But it has exactly the same what happens when you do 'git pull'
 problem, so even though it is conceptually a lot simpler, it has the
 same brokenness.

There is no brokenness; 'git pull' does different things depending on
the configuration. With my proposal nothing would change.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] New kind of upstream branch: base branch

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 Exactly the same as 'git pull' does right now.

You set

[branch 'foobar']
base = refs/heads/master

then 'git pull [--rebase]' will go to 'origin' due to the default,
but then what branch from the 'origin' are you integrating with?

Do you mean you are also setting both remote and upstream, perhaps
like this, for all of your branches?

[remote origin]
url = github.com:maintainer/hisproject
fetch = +refs/heads/*:refs/remotes/origin/*

[remote github]
url = github.com:felipec/myproject
fetch = +refs/heads/*:refs/remotes/github/*

[branch 'foobar']
base = refs/heads/master
remote = github ;# or is it origin???
upstream = refs/heads/foobar

Then your 'git pull' will fetch from remote 'origin' and integrate
with its 'foobar' and 'push' may go to update 'foobar' at 'github'.

Perhaps that is what you meant.

 'base' has absolutely nothing to do with pulling or pushing.

I agree it shouldn't have anything to do with pushing, but given
that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with
what you 'git fetch', introducing something that 'merge' or 'rebase'
pays attention to that does not have anything to do with 'pull'
sounds like it breaks existing end user expectation.

But that does not mean it is a bad idea. The behaviour changes only
when you have branch.$name.base, so I suspect that we do not need to
worry about what if the user has both? case you mentioned in your
first message.

I think I misunderstood what you meant.  If it is the norm to have
both base and upstream/remote in branch.$name (as opposed to have
only branch.$name.base and not branch.$name.remote to force fetch to
go to the default 'origin'), then 'git pull' will not break and I
can see how many things would work naturally (admittedly I can only
say 'many things', not 'everything', at this point, as I haven't
thought things through).
--
To unsubscribe from this list: send the line 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] New kind of upstream branch: base branch

[Felipe Contreras]

On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano gits...@pobox.com wrote:
 Junio C Hamano gits...@pobox.com writes:

 I however am not yet convinced if that direction is what you really
 want go in, though.  What should your 'git pull' on that branch do,
 for example?

 When you are on foobar and want to integrate with the branch you
 based your work on (i.e. local 'master'), you can do one of these:

 $ git pull
 $ git pull --rebase

 to fetch the upstream branch and integrate with it, without having
 to even care if that upstream branch is from the remote, or happens
 to be truly local.  By making 'git fetch' to go to the remote origin
 site, what will you be merging (or rebasing on) when you do the
 above two?

 Incidentally, I suspect you can do exactly the same thing without
 introducing a new concept base and instead special casing a remote
 whose URL is .; you essentially declare that The upstream of this
 branch whose branch.$name.remote is set to '.' lives locally, which
 is not all that different from saying The upstream of this branch
 whose branch.$name.base exists lives locally, which is what you
 seem to be proposing.  One of the things this alternative approach
 would special case such remote is probably to cause git fetch to
 ignore such a branch.$name.remote setting and instead go fetch from
 'origin', just like your if there is branch.$name.base, but no
 branch.$name.remote, fetch will go to 'origin' does.

 But it has exactly the same what happens when you do 'git pull'
 problem, so even though it is conceptually a lot simpler, it has the
 same brokenness.

 I do not think of a good way to fix the 'git pull' confusion; the
 desire to 'fetch from the overall upstream repository regardless of
 which branch I am on' is a valid and understandable one, but that
 does not mesh well with 'git pull' is 'git fetch' followed by
 either merge or rebase to integrate the result

But that is not true. It's only true when merge.defaulttoupstream=true.

 and git merge or
 git rebase pays attention to the other branch that is specified to
 integrate with.  The best we could do might be to simply forbid
 git pull if your current branch is marked with branch.$name.base
 but still allow git fetch.

Why forbid it? Why not leave it as it is?

 The changes that are involved are:

  * Do not change anything to @{upstream}'s definition, that is,
checkout -t -b A localbranch will set branch.A.remote to '.',
and git log A@{u}..A will stand for git log localbranch..A.

Yes, but in addition it would set 'branch.A.base'.

  * Current 'git fetch' pays attention to branch.A.remote when you
are on branch A, and tries to fetch from there.  Stop doing that
when branch.A.remote is set to '.' (the current repository) and
let other rules in the current implementation decide what remote
to fetch from. Also teach it to error out when branch.A.remote is
set to '.' when a new --forbid-local option is passed.

I don't see the point of --forbid-local, but otherwise yeah.

 Ah, alternatively, instead of adding --forbid-local, we could modify
 the changes for 'git fetch' and 'git pull' to read like this:

  * Current 'git fetch' pays attention to branch.A.remote when you
are on branch A, and tries to fetch from there.  Stop doing that
when branch.A.remote is set to '.' (the current repository) and
let other rules in the current implementation decide what remote
to fetch from, unless a new --allow-fetch-from-local option is
passed.

  * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.

Perhaps.

 If we did this, we can keep the git pull [--rebase] as a way to
 integrate with what you specified as your upstream, which is a
 common expectation, without forcing you to say git fetch origin.

I'm starting to change my mind. Perhaps instead of aiming to change
the behavior 'git rebase', it would make more sense to change the
behavior of 'git push'. So that 'git rebase', 'git fetch' and 'git
pull' all use 'upstream' as is currently the case, but 'git push'
would use something different. That would solve my 'origin/master' vs.
'github/master' distinction. But I would like 'git checkout -b foo
master' to automatically setup 'upstream', and 'git checkout -t -b foo
master' to in addition set this other kind that only affects 'git
push'. This would be a much more intrusive change though.

So, 'branch.A.merge' would become 'branch.A.upstream' and have the
full tracking branch (e.g. 'refs/remotes/github/master'), and
'branch.A.remote' would only affect 'git push'.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] New kind of upstream branch: base branch

[Felipe Contreras]

On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Exactly the same as 'git pull' does right now.

 You set

 [branch 'foobar']
 base = refs/heads/master

 then 'git pull [--rebase]' will go to 'origin' due to the default,
 but then what branch from the 'origin' are you integrating with?

The same as if you didn't have 'branch.foobar.base': none. You get an
error because there's no upstream.

 Do you mean you are also setting both remote and upstream, perhaps
 like this, for all of your branches?

 [remote origin]
 url = github.com:maintainer/hisproject
 fetch = +refs/heads/*:refs/remotes/origin/*

 [remote github]
 url = github.com:felipec/myproject
 fetch = +refs/heads/*:refs/remotes/github/*

 [branch 'foobar']
 base = refs/heads/master
 remote = github ;# or is it origin???
 upstream = refs/heads/foobar

 Then your 'git pull' will fetch from remote 'origin' and integrate
 with its 'foobar' and 'push' may go to update 'foobar' at 'github'.

 Perhaps that is what you meant.

That's what I described in my example.

 'base' has absolutely nothing to do with pulling or pushing.

 I agree it shouldn't have anything to do with pushing, but given
 that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with
 what you 'git fetch', introducing something that 'merge' or 'rebase'
 pays attention to that does not have anything to do with 'pull'
 sounds like it breaks existing end user expectation.

But it's already broken.

'git pull' is not the same as 'git fetch'+'git merge'. That *only*
works  when merge.defaulttoupstream is set.

 But that does not mean it is a bad idea. The behaviour changes only
 when you have branch.$name.base, so I suspect that we do not need to
 worry about what if the user has both? case you mentioned in your
 first message.

Indeed. It wouldn't be an intrusive change; it would only affect 'git
rebase', and nothing more.

But I'm wondering if the behavior of 'git fecth' should change as
well. And in fact it should be the other way around.

 I think I misunderstood what you meant.  If it is the norm to have
 both base and upstream/remote in branch.$name (as opposed to have
 only branch.$name.base and not branch.$name.remote to force fetch to
 go to the default 'origin'), then 'git pull' will not break and I
 can see how many things would work naturally (admittedly I can only
 say 'many things', not 'everything', at this point, as I haven't
 thought things through).

But I think the norm would be to have only 'base', because a lot of
people don't manually set an upstream branch.

In the end it all boils down to; which is the upstream
'origin/master', or 'github/master'? Well, it is 'origin/master', so
'upstream' should point there, but I don't want to push to the
'upstream', I want to push somewhere else by default.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (May 2013, #04; Wed, 15)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

We are past -rc2 and haven't seen any regression reported since the
feature freeze started, which may be a good sign (the coming release
is perfect) or a bad sign (nobody is testing).  We'll see soon when
we tag the 1.8.3 final sometime next week.  We may see subsystem
(git-svn? gitk? git-gui?) and l10n updates before that happens.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit
 - CodingGuidelines: Documentation/*.txt are the sources


* fc/doc-style (2013-05-09) 2 commits
 - SQUASH??? more consistently update docs
 - documentation: trivial style cleanups


* da/darwin (2013-05-15) 3 commits
 - imap-send: eliminate HMAC deprecation warnings on Mac OS X
 - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
 - Makefile: fix default regex settings on Darwin

 Waiting for polishing discussion to finish.


* fc/macos-x-clipped-write (2013-05-10) 2 commits
 - SQUASH???
 - compate/clipped-write.c: large write(2) fails on Mac OS X/XNU

 The tip needs to be squashed, as it was reported to have tested OK.


* fc/remote-hg (2013-05-15) 39 commits
 - remote-hg: remove files before modifications
 - remote-hg: improve lightweight tag author
 - remote-hg: use remote 'default' not local one
 - remote-hg: improve branch listing
 - remote-hg: simplify branch_tip()
 - remote-hg: check diverged bookmarks
 - remote-hg: pass around revision refs
 - remote-hg: implement custom checkheads()
 - remote-hg: implement custom push()
 - remote-hg: only update necessary revisions
 - remote-hg: force remote bookmark push selectively
 - remote-hg: reorganize bookmark handling
 - remote-hg: add test for failed double push
 - remote-hg: add test for big push
 - remote-hg: add test for new bookmark special
 - remote-hg: add test for bookmark diverge
 - remote-hg: add test for diverged push
 - remote-hg: add test to push new bookmark
 - remote-hg: add remote tests
 - remote-hg: add check_bookmark() test helper
 - remote-bzr: simplify test checks
 - remote-hg: always point HEAD to master
 - remote-hg: improve progress calculation
 - remote-hg: trivial cleanups
 - remote-hg: ensure remote rebasing works
 - remote-hg: upgrade version 1 marks
 - remote-hg: switch from revisions to SHA-1 noteids
 - remote-hg: add version checks to the marks
 - remote-hg: improve node traversing
 - remote-hg: shuffle some code
 - remote-hg: use a shared repository store
 - remote-hg: load all extensions
 - remote-hg: test: simplify previous branch checkout
 - remote-helpers: test: simplify remote URLs
 - remote-helpers: tests: general improvements
 - remote-helpers: test: cleanup style
 - remote-helpers: test: cleanup white-spaces
 - remote-hg: trivial reorganization
 - remote-hg: test: be a little more quiet

 Probably will be one of the early topics to graduate post 1.8.3.


* hv/config-from-blob (2013-05-12) 5 commits
 - do not die when error in config parsing of buf occurs
 - teach config --blob option to parse config from database
 - config: make parsing stack struct independent from actual data source
 - config: drop cf validity check in get_next_char()
 - config: factor out config file stack management


* jc/t5551-posix-sed-bre (2013-05-12) 1 commit
 - t5551: do not use unportable sed '\+'

 Not a regression fix and not urgent.


* jk/fetch-always-update-tracking (2013-05-12) 4 commits
 - fetch: opportunistically update tracking refs
 - refactor ref-merge flag
 - fetch/pull doc: untangle meaning of bare ref
 - t5510: start tracking-ref tests from a known state

 git fetch origin master unlike git fetch origin or git fetch
 does not update refs/remotes/origin/master and it was an early
 design decision to keep the update of remote tracking branches
 predictable, but in practice it turns out that people find it more
 convenient to opportunisticly update them whenever we have a
 chance, and we have been updating them when we run git push which
 already breaks the original predictability anyway.


* nd/clone-connectivity-shortcut (2013-05-11) 4 commits
 - clone: open a shortcut for connectivity check
 - index-pack: remove dead code (it should never happen)
 - fetch-pack: prepare updated shallow file before fetching the pack
 - clone: let the user know when check_everything_connected is run


* rr/rebase-autostash (2013-05-12) 7 commits
 - rebase: implement --[no-]autostash and rebase.autostash
 - rebase --merge: return control to caller, for housekeeping
 - rebase -i: return control to caller, for housekeeping
 - am: return control to caller, for housekeeping
 - rebase: prepare to do generic housekeeping
 - rebase -i: don't error out if $state_dir already 

[PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

[David Aguilar]

Mac OS X 10.8 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 NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow
users to opt out of using this library.  When defined, Git will
use OpenSSL instead.

COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL
compatibility macros in CommonDigest.h.

Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: David Aguilar dav...@gmail.com
---
Changes since last time:

Name the Makefile variable after the #define for consistency.

 Makefile | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index f698c1a..b0eb949 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,10 @@ all::
 # specify your own (or DarwinPort's) include directories and
 # library directories by defining CFLAGS and LDFLAGS appropriately.
 #
+# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X
+# and do not want to use Apple's CommonCrypto library.  This allows you to
+# provide your own OpenSSL library, for example from MacPorts.
+#
 # Define BLK_SHA1 environment variable to make use of the bundled
 # optimized C SHA1 routine.
 #
@@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+   ifndef NO_COMMON_DIGEST_FOR_OPENSSL
+   COMMON_DIGEST_FOR_OPENSSL = YesPlease
+   endif
NO_REGEX = YesPlease
PTHREAD_LIBS =
 endif
@@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
LIB_H += ppc/sha1.h
 else
+ifdef COMMON_DIGEST_FOR_OPENSSL
+   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 NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
 endif
-- 
1.8.3.rc2.3.g81576a6

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X

[David Aguilar]

Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
are deprecated.  Detect the COMMON_CRYPTO_FOR_OPENSSL definition
and use CommonCrypto's HMAC functions to eliminate the warnings.

Signed-off-by: David Aguilar dav...@gmail.com
---
Changes since last time: None.

 imap-send.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/imap-send.c b/imap-send.c
index d9bcfb4..96012b1 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -29,8 +29,18 @@
 #ifdef NO_OPENSSL
 typedef void *SSL;
 #else
+#ifdef COMMON_DIGEST_FOR_OPENSSL
+#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.rc2.3.g81576a6

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (May 2013, #04; Wed, 15)

[David Aguilar]

On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano gits...@pobox.com wrote:
 Here are the topics that have been cooking.  Commits prefixed with
 '-' are only in 'pu' (proposed updates) while commits prefixed with
 '+' are in 'next'.

 We are past -rc2 and haven't seen any regression reported since the
 feature freeze started, which may be a good sign (the coming release
 is perfect) or a bad sign (nobody is testing).  We'll see soon when
 we tag the 1.8.3 final sometime next week.  We may see subsystem
 (git-svn? gitk? git-gui?) and l10n updates before that happens.

 You can find the changes described here in the integration branches
 of the repositories listed at

 http://git-blame.blogspot.com/p/git-public-repositories.html

 --
 [New Topics]

 * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit
  - CodingGuidelines: Documentation/*.txt are the sources


 * fc/doc-style (2013-05-09) 2 commits
  - SQUASH??? more consistently update docs
  - documentation: trivial style cleanups


 * da/darwin (2013-05-15) 3 commits
  - imap-send: eliminate HMAC deprecation warnings on Mac OS X
  - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
  - Makefile: fix default regex settings on Darwin

  Waiting for polishing discussion to finish.

Thanks.

imap-send and cache.h are now on their v6 patch which I just sent.
That last few rounds have been cosmetic/superficial changes and I
would like to consider this topic done.  We've painted this shed
enough times ;-)

I believe fix default regex settings on Darwin is uncontroversial
and should be included in the upcoming release.  It may even be
maint-worthy.  Without it we fail t0070-fundamental.sh.  The two
patches that follow it can wait and cook like normal.
--
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] strbuf_branchname(): do not double-expand @{-1}~22

[Junio C Hamano]

If you were on 'frotz' branch before you checked out your current
branch, git merge @{-1}~22 means the same as git merge frotz~22.

The strbuf_branchname() function, when interpret_branch_name() gives
up resolving @{-1}~22 fully, returns frotz and tells the caller
that it only resolved @{-1} part of the input, mistakes this as a
total failure, and appends the whole thing to the result, yielding
frotz@{-1}~22, which does not make any sense.

Inspect the return valud from interpret_branch_name() a bit more
carefully.  When it errored out without consuming anything, we will
get -1 and we should return the whole thing.  Otherwise, we should
append the remainder (i.e. ~22 in the earlier example) to the
partially resolved name (i.e. frotz).

The test suite adds enough number of checkout to make @{-12} in the
last test in t0100 that tried to check we haven't flipped branches
that many times error case; raise the number to a hundred.

Signed-off-by: Junio C Hamano gits...@pobox.com
---

 * The original code in a552de75eb01 (strbuf_branchname(): a wrapper
   for branch name shorthands, 2009-03-21) did not have this problem
   only because interpret_branch_name() did not return a partial
   success, but in today's code after d46a8301930a (fix parsing of
   @{-1}@{u} combination, 2010-01-28), it should pay attention to
   the condition.

   There might be other callers of interpret_branch_name() that
   still assume there is no partial success; I didn't check.

 sha1_name.c |  8 ++--
 t/t0100-previous.sh | 15 +--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..371a49d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1055,9 +1055,13 @@ int interpret_branch_name(const char *name, struct 
strbuf *buf)
 int strbuf_branchname(struct strbuf *sb, const char *name)
 {
int len = strlen(name);
-   if (interpret_branch_name(name, sb) == len)
+   int used = interpret_branch_name(name, sb);
+
+   if (used == len)
return 0;
-   strbuf_add(sb, name, len);
+   if (used  0)
+   used = 0;
+   strbuf_add(sb, name + used, len - used);
return len;
 }
 
diff --git a/t/t0100-previous.sh b/t/t0100-previous.sh
index 315b9b3..e0a6940 100755
--- a/t/t0100-previous.sh
+++ b/t/t0100-previous.sh
@@ -27,6 +27,7 @@ test_expect_success 'merge @{-1}' '
test_commit B 
git checkout A 
test_commit C 
+   test_commit D 
git branch -f master B 
git branch -f other 
git checkout other 
@@ -35,14 +36,24 @@ test_expect_success 'merge @{-1}' '
git cat-file commit HEAD | grep Merge branch '\''other'\''
 '
 
-test_expect_success 'merge @{-1} when there is not enough switches yet' '
+test_expect_success 'merge @{-1}~1' '
+   git checkout master 
+   git reset --hard B 
+   git checkout other 
+   git checkout master 
+   git merge @{-1}~1 
+   git cat-file commit HEAD actual 
+   grep Merge branch '\''other'\'' actual
+'
+
+test_expect_success 'merge @{-100} before checking out that many branches yet' 
'
git reflog expire --expire=now 
git checkout -f master 
git reset --hard B 
git branch -f other C 
git checkout other 
git checkout master 
-   test_must_fail git merge @{-12}
+   test_must_fail git merge @{-100}
 '
 
 test_done
-- 
1.8.3-rc2-210-gbc3cf50

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

[Junio C Hamano]

David Aguilar dav...@gmail.com writes:

 Mac OS X 10.8 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 NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow
 users to opt out of using this library.  When defined, Git will
 use OpenSSL instead.

 COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL
 compatibility macros in CommonDigest.h.

This symbol will also cover not just SHA but also HMAC, would it
make more sense to call it COMMON_CRYPTO_FOR_OPENSSL?  After all,
that is what Apple calls this library, no?



 Helped-by: Eric Sunshine sunsh...@sunshineco.com
 Helped-by: Torsten Bögershausen tbo...@web.de
 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 Changes since last time:

 Name the Makefile variable after the #define for consistency.

  Makefile | 13 +
  1 file changed, 13 insertions(+)

 diff --git a/Makefile b/Makefile
 index f698c1a..b0eb949 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -137,6 +137,10 @@ all::
  # specify your own (or DarwinPort's) include directories and
  # library directories by defining CFLAGS and LDFLAGS appropriately.
  #
 +# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X
 +# and do not want to use Apple's CommonCrypto library.  This allows you to
 +# provide your own OpenSSL library, for example from MacPorts.
 +#
  # Define BLK_SHA1 environment variable to make use of the bundled
  # optimized C SHA1 routine.
  #
 @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin)
   BASIC_LDFLAGS += -L/opt/local/lib
   endif
   endif
 + ifndef NO_COMMON_DIGEST_FOR_OPENSSL
 + COMMON_DIGEST_FOR_OPENSSL = YesPlease
 + endif
   NO_REGEX = YesPlease
   PTHREAD_LIBS =
  endif
 @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
   LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
   LIB_H += ppc/sha1.h
  else
 +ifdef COMMON_DIGEST_FOR_OPENSSL
 + 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 NO_PERL_MAKEMAKER
   export NO_PERL_MAKEMAKER
  endif
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X

[Junio C Hamano]

David Aguilar dav...@gmail.com writes:

 Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
 are deprecated.  Detect the COMMON_CRYPTO_FOR_OPENSSL definition

Ahh, I think you meant to use that name but forgot to adjust the
symbol you use in the patch ;-)

I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/;

 and use CommonCrypto's HMAC functions to eliminate the warnings.

 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 Changes since last time: None.

  imap-send.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/imap-send.c b/imap-send.c
 index d9bcfb4..96012b1 100644
 --- a/imap-send.c
 +++ b/imap-send.c
 @@ -29,8 +29,18 @@
  #ifdef NO_OPENSSL
  typedef void *SSL;
  #else
 +#ifdef COMMON_DIGEST_FOR_OPENSSL
 +#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
--
To unsubscribe from this list: send the line 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: Trouble with case insensitive filesystem

[Luc Bourhis]

On 15 May 2013, at 15:32, Johannes Sixt wrote:

 Am 5/15/2013 10:40, schrieb Luc Bourhis:
 I work on a case insensitive filesystem and I have core.ignorecase set to 
 true. 
 ...
 So I thought it was a job for git filter-branch, ...
 
 However because of those two blobs, I have:
 
 ~ git status
 #modified:   .../fourCircles.py
 
 and git filter-branch therefore refuses to run.
 
 Make a commit that has neither file, run git filter-branch, then throw
 away the commit with git reset --hard HEAD~.

That did not work, i.e. fourCircles remained unmodified. Eventually, I 
managed by successively removing the file with C and then the file with c. 
Then filter-branch, and then reset --hard as you suggested. Then of course, all 
the sha's have changed and git cvsimport can't be used for incremental updates 
anymore, which I knew would happen, obviously.

Thanks,

Luc J. Bourhis
 --
To unsubscribe from this list: send the line 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] strbuf_branchname(): do not double-expand @{-1}~22

[Jeff King]

On Wed, May 15, 2013 at 05:29:51PM -0700, Junio C Hamano wrote:

 If you were on 'frotz' branch before you checked out your current
 branch, git merge @{-1}~22 means the same as git merge frotz~22.
 
 The strbuf_branchname() function, when interpret_branch_name() gives
 up resolving @{-1}~22 fully, returns frotz and tells the caller
 that it only resolved @{-1} part of the input, mistakes this as a
 total failure, and appends the whole thing to the result, yielding
 frotz@{-1}~22, which does not make any sense.
 
 Inspect the return valud from interpret_branch_name() a bit more
 carefully.  When it errored out without consuming anything, we will
 get -1 and we should return the whole thing.  Otherwise, we should
 append the remainder (i.e. ~22 in the earlier example) to the
 partially resolved name (i.e. frotz).

Thanks, I think your patch looks like the right solution.

Also, s/valud/value/ in the commit message.

  * The original code in a552de75eb01 (strbuf_branchname(): a wrapper
for branch name shorthands, 2009-03-21) did not have this problem
only because interpret_branch_name() did not return a partial
success, but in today's code after d46a8301930a (fix parsing of
@{-1}@{u} combination, 2010-01-28), it should pay attention to
the condition.

A quick grep shows substitute_branch_name does not distinguish these
cases, either, but I think that is OK. It is used by dwim_ref and
dwim_log to convert a string into a refname, and a partial parse of
something like @{u}~22 should be a failure (it does not return a ref,
but rather a commit).

It does look like substitute_branch_name may leak buf in such a case,
though.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X

[David Aguilar]

On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano gits...@pobox.com wrote:
 David Aguilar dav...@gmail.com writes:

 Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
 are deprecated.  Detect the COMMON_CRYPTO_FOR_OPENSSL definition

 Ahh, I think you meant to use that name but forgot to adjust the
 symbol you use in the patch ;-)

 I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/;

The symbol in Apple's header is COMMON_DIGEST_FOR_OPENSSL.

I rebased this patch for so many bikesheds I was bound to screw up the
commit message ;-)

 diff --git a/imap-send.c b/imap-send.c
 index d9bcfb4..96012b1 100644
 --- a/imap-send.c
 +++ b/imap-send.c
 @@ -29,8 +29,18 @@
  #ifdef NO_OPENSSL
  typedef void *SSL;
  #else
 +#ifdef COMMON_DIGEST_FOR_OPENSSL

Yup, the symbol is fine.

 +#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



--
David
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

[David Aguilar]

On Wed, May 15, 2013 at 5:36 PM, Junio C Hamano gits...@pobox.com wrote:
 David Aguilar dav...@gmail.com writes:

 Mac OS X 10.8 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 NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow
 users to opt out of using this library.  When defined, Git will
 use OpenSSL instead.

 COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL
 compatibility macros in CommonDigest.h.

 This symbol will also cover not just SHA but also HMAC, would it
 make more sense to call it COMMON_CRYPTO_FOR_OPENSSL?  After all,
 that is what Apple calls this library, no?

They call it COMMON_DIGEST_FOR_OPENSSL.  weirdos,
but I guess they mean it's for the digest functions.

Thanks for catching the commit message typo.


 Helped-by: Eric Sunshine sunsh...@sunshineco.com
 Helped-by: Torsten Bögershausen tbo...@web.de
 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 Changes since last time:

 Name the Makefile variable after the #define for consistency.

  Makefile | 13 +
  1 file changed, 13 insertions(+)

 diff --git a/Makefile b/Makefile
 index f698c1a..b0eb949 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -137,6 +137,10 @@ all::
  # specify your own (or DarwinPort's) include directories and
  # library directories by defining CFLAGS and LDFLAGS appropriately.
  #
 +# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X
 +# and do not want to use Apple's CommonCrypto library.  This allows you to
 +# provide your own OpenSSL library, for example from MacPorts.
 +#
  # Define BLK_SHA1 environment variable to make use of the bundled
  # optimized C SHA1 routine.
  #
 @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin)
   BASIC_LDFLAGS += -L/opt/local/lib
   endif
   endif
 + ifndef NO_COMMON_DIGEST_FOR_OPENSSL
 + COMMON_DIGEST_FOR_OPENSSL = YesPlease
 + endif
   NO_REGEX = YesPlease
   PTHREAD_LIBS =
  endif
 @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1
   LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
   LIB_H += ppc/sha1.h
  else
 +ifdef COMMON_DIGEST_FOR_OPENSSL
 + 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 NO_PERL_MAKEMAKER
   export NO_PERL_MAKEMAKER
  endif



--
David
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 3/7] show: honor --textconv for blobs

[Jeff King]

On Mon, May 13, 2013 at 04:57:55PM +0200, Michael J Gruber wrote:

  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.

OK. I was speaking mostly from intuition, and I suspect you have more
real-world experience here. So I am willing to admit that my you do not
say... above was a strawman. :)

 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.

Yes, I think that would work OK. The only problem is that it is a bit
weird to pointing show=foo to diff.foo.*, especially when most of
the driver options are ignored. But if we can accept that wrinkle in the
UI, I think it would otherwise do what users want.

 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 think the point is that the attribute says a property of this path is
that it has type X. And then the config says when you see type X, do
this thing with it.

So arguably diff=X is wrong in the first place. It should be type=X,
and we should have diff.X, merge.X, etc in the config. And
diff.*.textconv is potentially misplaced; it is not really about diffing
at all, but rather about creating a human-readable presentation for the
file. I don't think it is so bad that it is worth the pain of fixing it
now, though. It is a historical weirdness that diff=X means present
the path according to the rules in X, but we can live with that.

But if we think of it that way, then automatically respecting textconv
for git show is a sensible thing to do. Hmph. Now I may have convinced
myself that flipping the default is the right thing. :)

So if it is not clear, I am pretty on the fence about how the defaults
should be handled, or what would surprise users the least. Either way,
though, it would probably make sense to have a configurable option. And
with the reasoning above for the split between attributes/config, it
would make sense to me for that option to be a boolean
diff.X.showtextconv. Which seems totally odd and broken (we are not
doing a diff at all!), but that is where the textconv config lives, for
historical reasons.

-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 4/4] fetch: opportunistically update tracking refs

[Jeff King]

On Sun, May 12, 2013 at 11:41:45AM +0200, Thomas Rast wrote:

  We miss an opportunity to update refs/remotes/origin/master
  (or whatever the user has configured). Some users find this
  confusing, because they would want to do further comparisons
  against the old state of the remote master, like:
 
$ git pull origin master
$ git log HEAD...origin/master
 
  I agree with the patch, but I would use a different reasoning. Your
  example here is not even correct because the range in the second command
  would be empty unless the merge conflicted.
 
 Meh, I just read this again and saw that you actually had *three* dots.
 Serves me right for writing a reply on the phone.
 
 So the quoted part is indeed correct.

Yes, it's correct, but it is a bit subtle. A better example would
probably be:

  $ git status
  # On branch foo
  # Your branch is ahead of 'origin/master' by 2 commits.

  $ git pull origin master
  [pull 10 new commits]

  $ git status
  # On branch foo
  # Your branch is ahead of 'origin/master' by 13 commits.

That is technically true, but only because origin/master is now out of
date. The more interesting number is 3: the two commits we had already,
plus the new merge commit.

And of course there are infinite variations where you pull on one
branch, and then switch branches to compare on another. But they all
boil down to having an out-of-date view of origin/master that does not
reflect the most recent pull.

-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

[RFC/PATCH 0/3] New kind of upstream branch: downstream branch

[Felipe Contreras]

Hi,

After thinking a bit more about, I think the current 'upstream' branch serves
most of the purposes; actually tracks an upstream branch; makes sense to rebase
onto that, makes sense to fetch from that remote, merge, and pull.

The only job it doesn't make sense to use the 'upstream' branch for is to push,
so here's a new notion of 'downstream' branch.

These patches are only exploratory, 'git branch -v' doesn't show these
branches, there's no @{downstream}, no documentation, and there isn't even a
way to set it.

If there's no downstream branch configured, nothing changes.

Felipe Contreras (3):
  remote: don't override default if cur head remote is '.'
  pull: trivial cleanups
  push: add separate 'downstream' branch

 builtin/push.c | 65 --
 git-pull.sh| 15 +-
 remote.c   | 10 ++---
 remote.h   |  3 +++
 4 files changed, 61 insertions(+), 32 deletions(-)

-- 
1.8.3.rc1.579.g184e698

--
To unsubscribe from this list: send the line 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 1/3] remote: don't override default if cur head remote is '.'

[Felipe Contreras]

'git fetch .' makes no sense, so let's keep using the default ('origin')
when the current branch's remote is '.'.

Also update 'git pull' so that pulling works the same way as before.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 git-pull.sh | 9 -
 remote.c| 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..75297c7 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -220,7 +220,14 @@ test true = $rebase  {
done
 }
 orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok 
$@ || exit 1
+# get the default remote
+remote=$(git config branch.$curr_branch_short.remote)
+if test $# == 0  test -n $remote
+then
+   git fetch $verbosity $progress $dry_run $recurse_submodules 
--update-head-ok $remote || exit 1
+else
+   git fetch $verbosity $progress $dry_run $recurse_submodules 
--update-head-ok $@ || exit 1
+fi
 test -z $dry_run || exit 0
 
 curr_head=$(git rev-parse -q --verify HEAD)
diff --git a/remote.c b/remote.c
index 68eb99b..322a1b6 100644
--- a/remote.c
+++ b/remote.c
@@ -360,7 +360,7 @@ static int handle_config(const char *key, const char 
*value, void *cb)
if (!strcmp(subkey, .remote)) {
if (git_config_string(branch-remote_name, key, value))
return -1;
-   if (branch == current_branch) {
+   if (branch == current_branch  
strcmp(branch-remote_name, .)) {
default_remote_name = branch-remote_name;
explicit_default_remote_name = 1;
}
-- 
1.8.3.rc1.579.g184e698

--
To unsubscribe from this list: send the line 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 2/3] pull: trivial cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 git-pull.sh | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 75297c7..b207df2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -166,9 +166,7 @@ error_on_no_merge_candidates () {
op_prep=with
fi
 
-   curr_branch=${curr_branch#refs/heads/}
-   upstream=$(git config branch.$curr_branch.merge)
-   remote=$(git config branch.$curr_branch.remote)
+   upstream=$(git config branch.$curr_branch_short.merge)
 
if [ $# -gt 1 ]; then
if [ $rebase = true ]; then
@@ -183,7 +181,7 @@ error_on_no_merge_candidates () {
echo You asked to pull from the remote '$1', but did not 
specify
echo a branch. Because this is not the default configured 
remote
echo for your current branch, you must specify a branch on the 
command line.
-   elif [ -z $curr_branch -o -z $upstream ]; then
+   elif [ -z $curr_branch_short -o -z $upstream ]; then
. git-parse-remote
error_on_missing_default_upstream pull $op_type $op_prep \
git pull remote branch
-- 
1.8.3.rc1.579.g184e698

--
To unsubscribe from this list: send the line 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 3/3] push: add separate 'downstream' branch

[Felipe Contreras]

It doesn't make sense to push to the upstream branch, so create new
configurations for the notion of 'downstream' branch, which is basically
the branch to push to by default.

The upstream branch is remote+merge, the downstream branch is
pushremote+push.

  [branch master]
  remote = origin
  merge = refs/heads/master
  pushremote = github
  push = refs/heads/master

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 builtin/push.c | 65 --
 remote.c   |  8 ++--
 remote.h   |  3 +++
 3 files changed, 50 insertions(+), 26 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index 909c34d..c062fa5 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -76,21 +76,23 @@ static int push_url_of_remote(struct remote *remote, const 
char ***url_p)
return remote-url_nr;
 }
 
-static NORETURN int die_push_simple(struct branch *branch, struct remote 
*remote) {
+static NORETURN int die_push_simple(struct branch *branch, struct remote 
*remote,
+   const char *kind, const char *related)
+{
/*
 * There's no point in using shorten_unambiguous_ref here,
 * as the ambiguity would be on the remote side, not what
 * we have locally. Plus, this is supposed to be the simple
 * mode. If the user is doing something crazy like setting
-* upstream to a non-branch, we should probably be showing
+* upstream/downstream to a non-branch, we should probably be showing
 * them the big ugly fully qualified ref.
 */
const char *advice_maybe = ;
-   const char *short_upstream =
-   skip_prefix(branch-merge[0]-src, refs/heads/);
+   const char *short_upstream = skip_prefix(related, refs/heads/);
 
if (!short_upstream)
-   short_upstream = branch-merge[0]-src;
+   short_upstream = related;
+
/*
 * Don't show advice for people who explicitely set
 * push.default.
@@ -99,8 +101,8 @@ static NORETURN int die_push_simple(struct branch *branch, 
struct remote *remote
advice_maybe = _(\n
 To choose either option permanently, 
 see push.default in 'git help config'.);
-   die(_(The upstream branch of your current branch does not match\n
- the name of your current branch.  To push to the upstream 
branch\n
+   die(_(The %s branch of your current branch does not match\n
+ the name of your current branch.  To push to the %s branch\n
  on the remote, use\n
  \n
  git push %s HEAD:%s\n
@@ -109,6 +111,7 @@ static NORETURN int die_push_simple(struct branch *branch, 
struct remote *remote
  \n
  git push %s %s\n
  %s),
+   kind, kind,
remote-name, short_upstream,
remote-name, branch-name, advice_maybe);
 }
@@ -117,6 +120,8 @@ static void setup_push_upstream(struct remote *remote, int 
simple)
 {
struct strbuf refspec = STRBUF_INIT;
struct branch *branch = branch_get(NULL);
+   const char *related, *kind, *pushremote_name;
+
if (!branch)
die(_(You are not currently on a branch.\n
To push the history leading to the current (detached 
HEAD)\n
@@ -124,26 +129,38 @@ static void setup_push_upstream(struct remote *remote, 
int simple)
\n
git push %s HEAD:name-of-remote-branch\n),
remote-name);
-   if (!branch-merge_nr || !branch-merge || !branch-remote_name)
-   die(_(The current branch %s has no upstream branch.\n
-   To push the current branch and set the remote as upstream, 
use\n
-   \n
-   git push --set-upstream %s %s\n),
-   branch-name,
-   remote-name,
-   branch-name);
-   if (branch-merge_nr != 1)
-   die(_(The current branch %s has multiple upstream branches, 
-   refusing to push.), branch-name);
-   if (strcmp(branch-remote_name, remote-name))
-   die(_(You are pushing to remote '%s', which is not the 
upstream of\n
+
+   if (branch-push) {
+   kind = _(downstream);
+   related = branch-push;
+   pushremote_name = branch-pushremote_name;
+   } else {
+   if (!branch-merge_nr || !branch-merge || !branch-remote_name)
+   die(_(The current branch %s has no upstream branch.\n
+   To push the current branch and set the remote as 
upstream, use\n
+   \n
+   git push --set-upstream %s %s\n),
+   branch-name,
+   remote-name,
+   branch-name);
+  

Re: [RFC] New kind of upstream branch: base branch

[Felipe Contreras]

On Wed, May 15, 2013 at 5:22 PM, Philip Oakley philipoak...@iee.org wrote:

 Sound a reasonable idea. On some patches I was working on I had to [chose
 to] add a tag for the base which made it easier to rebase later.

And was the 'upstream' branch somehow not appropriate for some reason?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] resolve_ref: close race condition for packed refs

[Jeff King]

On Mon, May 13, 2013 at 12:56:05AM +0200, Michael Haggerty wrote:

  + * This should be called from resolve_ref_unsafe when a loose ref cannot be
  + * accessed; err must represent the errno from the last attempt to access 
  the
  + * loose ref, and the other options are forwarded from 
  resolve_safe_unsaefe.
 
 s/resolve_ref_unsaefe/resolve_ref_unsafe/

Oops, thanks.

  -   return NULL;
  +   return handle_loose_ref_failure(errno, refname, sha1,
  +   reading, flag);
 
 I probably would have separated the rest of the patch, which is a pure
 refactoring, from this last chunk, which is a functional change.  But
 that's just me.

Yeah, I go back and forth on whether it is better to have strict
refactors followed by changes or not. Sometimes it is hard to understand
the motivation for the refactor without seeing the change, and you end
up explaining it twice.

My usual rule of thumb is:

  - If you are factoring out some code, and then are going to change
that code, make it two separate changes. That keeps the diffs
readable (the first one is pure movement and you do not need to look
closely, and the second shows a sane diff of the change).

  - If you are factoring out some code, and then adding more callers,
it's OK to do it together. The new caller provides the motivation
for the refactor.

This is the latter case. But I'm open to arguments that the rule is not
a good one. :)

 I suggest adding a comment here mentioning briefly the race condition
 that the call to handle_loose_ref_failure() is meant to address;
 otherwise somebody not thinking of race conditions might have the clever
 idea of inlining the call to return NULL because it seems redundant
 with the check of ENOENT following the lstat() call above.

Yeah, I thought I had mentioned that at the top of
handle_loose_ref_failure, but I see that I didn't. Probably something
like this squashed on top makes sense:

diff --git a/refs.c b/refs.c
index c127baf..1a7e4ef 100644
--- a/refs.c
+++ b/refs.c
@@ -,7 +,7 @@ static int get_packed_ref(const char *refname, unsigned 
char *sha1)
 /*
  * This should be called from resolve_ref_unsafe when a loose ref cannot be
  * accessed; err must represent the errno from the last attempt to access the
- * loose ref, and the other options are forwarded from resolve_safe_unsaefe.
+ * loose ref, and the other options are forwarded from resolve_safe_unsafe.
  */
 static const char *handle_loose_ref_failure(int err,
const char *refname,
@@ -1200,9 +1200,16 @@ const char *resolve_ref_unsafe(const char *refname, 
unsigned char *sha1, int rea
 * a ref
 */
fd = open(path, O_RDONLY);
-   if (fd  0)
+   if (fd  0) {
+   /*
+* We need to check again here for ENOENT and fall back
+* to the packed-refs file to avoid a race condition in
+* which the ref is packed and pruned between our
+* lstat() and open() calls.
+*/
return handle_loose_ref_failure(errno, refname, sha1,
reading, flag);
+   }
len = read_in_full(fd, buffer, sizeof(buffer)-1);
close(fd);
if (len  0)
--
To unsubscribe from this list: send the line 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/4] add a stat_validity struct

[Jeff King]

On Mon, May 13, 2013 at 04:29:34AM +0200, Michael Haggerty wrote:

  This patch introduces a stat_validity struct which
  encapsulates the concept of checking the stat-freshness of a
  file. It is implemented on top of struct cache_entry to
  reuse the logic about which stat entries to trust for a
  particular platform, but hides the complexity behind two
  simple functions: check and update.
 
 Given that struct cache_entry holds a lot of information that is
 irrelevant to stat-freshness and that ce_match_stat_basic() has a lot of
 logic that is geared towards cache_entries, it seems like there should
 be some kind of struct stat_data that holds the portion of the stat
 information that we use for checking whether a file might have been
 changed between two accesses.  cache_entry would contain a stat_data as
 a member, and the functionality for checking that part of a cache_entry
 validity would be moved to a separate function.
 
 Then your struct validity_info could hold a pointer to a stat_data
 rather than to a cache_entry, and it wouldn't have to contain the
 unrelated cache_entry stuff.

Yes, I had the exact same thought, and came up with the exact same
solution. I was just hesitant to do it because it meant touching all of
the cache_entry users to adjust their struct accesses.

But from your patches, it doesn't look too bad (and we can be sure we
updated every spot, because it's easy for the compiler to enforce).

I'm sorry to be so slow lately; I'm on vacation (and will be for a bit
yet). I'm happy to rebuild my series on top of yours, and it looks like
it is still only in pu (I haven't yet read What's Cooking to see the
plans for it). I don't think there's a rush, as it is post-1.8.3 anyway
(I _do_ think it's a serious bug, in that it can cause data loss, but in
practice I doubt most people would hit it).

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X

[Junio C Hamano]

David Aguilar dav...@gmail.com writes:

 On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano gits...@pobox.com wrote:
 David Aguilar dav...@gmail.com writes:

 Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
 are deprecated.  Detect the COMMON_CRYPTO_FOR_OPENSSL definition

 Ahh, I think you meant to use that name but forgot to adjust the
 symbol you use in the patch ;-)

 I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/;

 The symbol in Apple's header is COMMON_DIGEST_FOR_OPENSSL.

Sigh.
--
To unsubscribe from this list: send the line 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 3/3] push: add separate 'downstream' branch

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 It doesn't make sense to push to the upstream branch, so create new
 configurations for the notion of 'downstream' branch, which is basically
 the branch to push to by default.

It doesn't?  That depends.

To people coming from (and people who are still using) central
shared repository workflow, pushing to anywhere other than the
upstream makes no sense.

If qualified with something like When using a triangular workflow
to pull from one place and push to another place in front, I can
see why having a separate upstream and downstream makes sense, and...

 The upstream branch is remote+merge, the downstream branch is
 pushremote+push.

... this is a perfect explanation of what a downsream is.



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] resolve_ref: close race condition for packed refs

[Michael Haggerty]

On 05/16/2013 05:47 AM, Jeff King wrote:
 I probably would have separated the rest of the patch, which is a pure
 refactoring, from this last chunk, which is a functional change.  But
 that's just me.
 
 Yeah, I go back and forth on whether it is better to have strict
 refactors followed by changes or not. Sometimes it is hard to understand
 the motivation for the refactor without seeing the change, and you end
 up explaining it twice.

A pure refactoring doesn't need much justification.  Something like
extract function foo() plus maybe this function will soon have
multiple callers is IMO usually adequate, especially if the function is
well-named and documented in the patch itself.

 My usual rule of thumb is:
 
   - If you are factoring out some code, and then are going to change
 that code, make it two separate changes. That keeps the diffs
 readable (the first one is pure movement and you do not need to look
 closely, and the second shows a sane diff of the change).
 
   - If you are factoring out some code, and then adding more callers,
 it's OK to do it together. The new caller provides the motivation
 for the refactor.
 
 This is the latter case. But I'm open to arguments that the rule is not
 a good one. :)

Yes, I see how keeping the changes together makes the justification of
the refactoring more obvious.  On the other hand, splitting has the
following benefits:

1. Reviewers have a single thing to check in each patch: Did he
   transcribe the code correctly into a function and choose a good
   API? vs. Does it make sense to call the function from this new
   place?  The threads of feedback emails about each patch are
   similarly separated.

   On the other hand, of course these two changes are not completely
   independent, because having an idea what new callers want to do
   with the function affects what its API should be.

2. If the patch series needs to be revised, it is quite possible that
   the revisions affect only one patch or the other.  Therefore, the
   unaffected patch can be carried along through interactive rebases
   etc. intact, or might serve as a building block for an alternative
   solution.

3. If there's a problem, bisect can figure out which half of the change
   was to blame.

That being said, this case is very much in the gray area where it is a
matter of personal preference and I don't mind at all if you leave it as
a single patch.

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: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

Hi,

I think the discussion might work better via ML than GitHub.
This is the full glossary of git's de.po as it would look
like with (hopefully) all the changes included that have been
discussed here. Still without any reasoning for decisions
(except HEAD).

Thanks for reading.

+Basic repository objects:
+
+blob   = Blob
+tree   = Baum, Baum-Objekt (bevorzugt), Tree-Objekt
+submodule  = Submodul
+pack(noun) = Pack-Datei
+pack(verb) = packen (ggf. Pack-Datei erstellen)
+ancestor   = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)
+
+Content in a repository:
+
+file(s)= Datei(en)
+tracked file   = beobachtete Datei
+track file = beobachte Datei
+untracked file = unbeobachtete Datei
+directory  = Verzeichnis
+
+Repositories / tracking concepts:
+
+clone (verb)   = klonen
+clone (noun)   = der Klon
+repository = Repository
+
+bare repository= bloßes Repository
+working directory  = Arbeitsverzeichnis
+
+remote branch  = externer Zweig
+remote tracking branch = externer Übernahmezweig
+upstream branch= -||-
+tracking branch= Übernahmezweig
+
+remote repository  = externes Repository
+remote(noun)   = -||-
+remote(adj)= extern
+
+Authorship:
+
+author= Autor
+committer = Commit-Ersteller
+tagger= Tag-Ersteller
+
+Commits, tags and other references:
+
+HEAD   = HEAD
+ Konzept aus der Git-Welt, daher nicht zu übersetzen.
+detached HEAD  = losgelöster HEAD
+
+commit(noun)  = Commit
+commit(verb)  = committen
+commit the result = das Ergebnis committen
+parent commit = Eltern-Commit
+child commit  = Kind-Commit
+commit message= Commit-Beschreibung
+
+stash(noun)   = der Stash
+stash(verb)   = stashen, stash benutzen (bevorzugt)
+unstash(verb) = unstashen, zurückladen, aus 'stash'
zurückladen (bevorzugt)
+
+reference  = Referenz
+revision   = Commit
+branch = Zweig (or Branch)
+tag(noun)  = Tag
+tag(verb)  = taggen, Tag erstellen
+annotated tag  = annotierter Tag
+tag message= Tag-Beschreibung
+
+orphan commit=
+orphan reference =
+
+boundary commit = Grenz-Commit
+root commit = Ursprungs-Commit, Wurzel-Commit
+
+stage/index (noun) = Staging-Area, Index
+stage/index (verb) = (für einen | zum) Commit vormerken, zur
Staging Area hinzufügen, dem Index hinzufügen
+unstage (verb) = aus Staging Area entfernen/nehmen, aus Index
entfernen/nehmen
+
+The DAG:
+
+commit graph = Commit-Graph
+merge = Merge
+
+References in relation to other references:
+
+branches that have diverged = Zweige sind divergiert
+diverging references= divergierte Referenzen
+your branch is ahead= dein Zweig ist voraus
+your branch is behind   = dein Zweig ist hinterher
+
+Moving data around:
+
+fetch = anfordern
+pull  = zusammenführen
+push  = versenden
+
+fast-forward = vorspulen
+non-fast-forward = nicht vorspulen
+
+Commands:
+
+log= Log
+interactive commit = interaktiver Commit
+cherry-pick= cherry-pick benutzen
+rebase(verb)   = rebase benutzen
+rebase(noun)   = rebase
+archive= archivieren
+revert = zurücknehmen
+clean(verb)=
+clean(noun)=
+merge  = mergen
+
+bundle(noun)   = Paket
+bundle(verb)   = Paket erstellen
+unbundle(verb) = Paket entpacken
+
+bisect = binäre Suche
+bisecting  = bei einer binären Suche sein, binäre Suche durchführen
+
+Diff/patch related:
+
+diff   = Differenz
+delta  = Differenz (or Delta)
+patch  = Patch
+apply  = anwenden
+diffstat   = (leave it as it is)
+hunk   = Bereich
+whitespace = Leerzeichen (FIXME?) (maybe Leerraum)
+
+Still being worked out:
+
+prune  = veraltete(n) Zweig(e) entfernen
+checkout(verb) = auschecken
+
+git add  = hinzufügen
+
+merge conflict = Merge-Konflikt
+3-way merge= 3-Wege-Merge
+paths  = Pfade
+
+symbolic link = symbolische Verknüfung
+path = Pfad
+link = Verknüpfung
+
+reflog = Referenzprotokoll
+partial commit = teilweise committen, partiell committen
+
+reset = neu setzen (maybe umsetzen?)
+
+register   = in die Konfiguration eintragen
+unregister = aus der Konfiguration austragen
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html