[PATCH v2] gettext.h: add parentheses around N_ expansion if supported

[Kyle J. McKay]

The N_ macro is used to mark strings for translation without
actually translating them.  At runtime the string is expected
to be passed to the gettext API for translation.

If two N_ macro invocations appear next to each other with only
whitespace (or nothing at all) between them, the two separate
strings will be marked for translation, but the preprocessor
will then combine the strings into one and at runtime the
string passed to gettext will not match the strings that were
translated.

Avoid this by adding parentheses around the expansion of the
N_ macro so that instead of ending up with two adjacent strings
that are then combined by the preprocessor, two adjacent strings
surrounded by parentheses result instead which causes a compile
error so the mistake can be quickly found and corrected.

However, since these string literals are typically assigned to
static variables and not all compilers support parenthesized
string literal assignments, only add the parentheses when the
compiler is known to support the syntax.

For now only __GNUC__ is tested which covers both gcc and clang
which should result in early detection of any adjacent N_ macros.

Although the necessary #ifdef makes the header less elegant,
the benefit of avoiding propagation of a translation-marking
error to all the translation teams thus creating extra work
for them when the error is eventually detected and fixed would
seem to outweigh the minor inelegance the #ifdef introduces.

Signed-off-by: Kyle J. McKay 
---
 gettext.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gettext.h b/gettext.h
index 7671d09d..80ec29b5 100644
--- a/gettext.h
+++ b/gettext.h
@@ -62,7 +62,19 @@ const char *Q_(const char *msgid, const char *plu, unsigned 
long n)
return ngettext(msgid, plu, n);
 }
 
-/* Mark msgid for translation but do not translate it. */
+/* Mark msgid for translation but do not translate it.
+ *
+ * In order to prevent accidents where two adjacent N_ macros
+ * are mistakenly used, this macro is defined with parentheses
+ * when the compiler is known to support parenthesized string
+ * literal assignments.  This guarantees a compiler error in
+ * such a case rather than a silent conjoining of the strings
+ * by the preprocessor which results in translation failures.
+ */
+#ifdef __GNUC__
+#define N_(msgid) (msgid)
+#else
 #define N_(msgid) msgid
+#endif
 
 #endif
-- 
2.1.4

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

[PATCH] show-branch --upstream: add upstream branches to the list of branches to display

[Mike Hommey]

`git show-branch --upstream` is equivalent to `git show-branch
$(git for-each-ref refs/heads --format '%(refname:short)')
$(git for-each-ref refs/heads --format '%(upstream:short)')`

`git show-branch --upstream foo bar` is equivalent to `git show-branch
foo bar $(git for-each-ref refs/heads/foo refs/heads/bar
--format '%(upstream:short)')`

Combined with --topics, it shows commits that are NOT on any of
the upstream branches.

Signed-off-by: Mike Hommey 
---

Note that in the --topics --upstream case, when there are different
upstreams branches involved, only the merge-base of all of them is
shown. I'm not sure if it's desirable to show more. The output as it
is works for my own use cases.

 Documentation/git-show-branch.txt |  6 ++
 builtin/show-branch.c | 42 +--
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-show-branch.txt 
b/Documentation/git-show-branch.txt
index b91d4e5..fd29c8d 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -53,6 +53,10 @@ OPTIONS
branch to the list of revs to be shown when it is not
given on the command line.
 
+--upstream::
+   With this option, the command includes the upstream
+   branch of each rev to be shown.
+
 --topo-order::
 By default, the branches and their commits are shown in
 reverse chronological order.  This option makes them
@@ -102,6 +106,8 @@ OPTIONS
 
 --topics::
Shows only commits that are NOT on the first branch given.
+   When used with `--upstream`, shows only commits that are NOT
+   on any upstream branch.
This helps track topic branches by hiding any commit that
is already in the main line of development.  When given
"git show-branch --topics master topic1 topic2", this
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 270e39c..90e2ac3 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -4,9 +4,10 @@
 #include "builtin.h"
 #include "color.h"
 #include "parse-options.h"
+#include "remote.h"
 
 static const char* show_branch_usage[] = {
-N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order] [--current] [--color[=] | --no-color] [--sparse] 
[--more= | --list | --independent | --merge-base] [--no-name | --sha1-name] 
[--topics] [( | )...]"),
+N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order] [--current] [--upstream] [--color[=] | --no-color] 
[--sparse] [--more= | --list | --independent | --merge-base] [--no-name | 
--sha1-name] [--topics] [( | )...]"),
 N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
 NULL
 };
@@ -640,6 +641,7 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
int sha1_name = 0;
int shown_merge_point = 0;
int with_current_branch = 0;
+   int with_upstream_branches = 0;
int head_at = -1;
int topics = 0;
int dense = 1;
@@ -658,6 +660,8 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
OPT_BOOL(0, "no-name", &no_name, N_("suppress naming strings")),
OPT_BOOL(0, "current", &with_current_branch,
 N_("include the current branch")),
+   OPT_BOOL(0, "upstream", &with_upstream_branches,
+N_("include upstream branches")),
OPT_BOOL(0, "sha1-name", &sha1_name,
 N_("name commits with their object names")),
OPT_BOOL(0, "merge-base", &merge_base,
@@ -848,7 +852,41 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
if (commit->object.flags == flag)
commit_list_insert_by_date(commit, &list);
rev[num_rev] = commit;
+
+   if (with_upstream_branches) {
+   unsigned char branch_sha1[20];
+   struct branch *branch;
+   int current_ref_name_cnt = ref_name_cnt;
+
+   /* If this ref is already marked as an upstream, skip */
+   if (topics & flag)
+   continue;
+
+   branch = branch_get(ref_name[num_rev]);
+
+   if (!branch || !branch->merge || !branch->merge[0] ||
+   !branch->merge[0]->dst)
+   continue;
+   if (get_sha1(branch->merge[0]->dst, branch_sha1))
+   continue;
+   append_remote_ref(branch->merge[0]->dst, branch_sha1, 
0, 0);
+   /* If append_remote_ref didn't add a ref, it's either
+* because it's an upstream of a previous ref, or 
because
+* it was given on the command line. In neither case we
+* want the bit being set. */
+   if (topic

Re: [PATCH] standardize usage info string format

[Johannes Schindelin]

Hi Alex,

[somehow my mailer did not like the Cc: list, so I had to cull it]

On Wed, 7 Jan 2015, Alex Henrie wrote:

> This patch puts the usage info strings that were not already in docopt-
> like format into docopt-like format, which will be a litle easier for
> end users and a lot easier for translators.

I briefly glanced over the changes and like the patch!

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

Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Johannes Schindelin]

Hi Junio,

On Wed, 7 Jan 2015, Junio C Hamano wrote:

> Dscho, this sounds to me like the additional "8.3 ambiguity
> protection" (which is only in Git for Windows) in action. Any
> thoughts?

First thought: the Git for Windows mailing list should be Cc:ed (I was
traveling yesterday and somebody else might have been able to address
Dmitry's problem).

Second thought below:

> On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov  wrote:
> >
> > Recently I installed 1.9.5 git version and faced the problem that one
> > of the files in my cloned repository with a name ICON~714.PNG is
> > marked as deleted even repository was freshly cloned. Trying to do
> > anything with that file resulted in constant "Invalid Path" errors.
> > Reverting back to 1.9.4. fixed that problem.

ICON~714.PNG is a valid short name for a long name (such as
'icon.background.png') because it fits the shortening scheme (8.3 format,
the base name ends in ~). As this can clash with a validly shortened
long name, Git for Windows refuses to check out such paths by default.

If you want the old -- unsafe -- behavior back, just set your
core.protectNTFS to false (this means that you agree that the incurred
problems are your own responsibility and cannot be blamed on anybody else
;-))

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

Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Jeff King]

On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote:

> ICON~714.PNG is a valid short name for a long name (such as
> 'icon.background.png') because it fits the shortening scheme (8.3 format,
> the base name ends in ~). As this can clash with a validly shortened
> long name, Git for Windows refuses to check out such paths by default.
> 
> If you want the old -- unsafe -- behavior back, just set your
> core.protectNTFS to false (this means that you agree that the incurred
> problems are your own responsibility and cannot be blamed on anybody else
> ;-))

I wonder if it is worth having a "git-only" mode for core.protectNTFS.
Turning it off entirely would make him susceptible to GIT~1 attacks.

-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 v2 2/2] t/t3308-notes-merge.sh: succeed with relaxed notes refs

[Jeff King]

On Wed, Jan 07, 2015 at 08:03:58AM -0800, Junio C Hamano wrote:

> > But we are talking about
> > somebody who is already fully-qualifying a ref (and anything unqualified
> > continues to get looked up under refs/notes).
> 
> That (specifically 'merge') is not my real worry.  It's the other
> way around, actually.
> 
> Because expand_notes_ref() makes sure that any given notes ref is
> prefixed appropriately to start with refs/notes/,
> 
> git notes --ref=refs/heads/master add ...blah...
> git notes --ref=refs/tag/v1.0 add ...blah...
> 
> would be a sensible way when somebody wants to keep a forest of
> notes refs, one per real ref.  Wouldn't they have already been
> trained to spell "refs/heads/master" when they want to refer to
> refs/notes/refs/heads/master because of this?

Thanks, that is a more interesting case, and I agree that moving to
allowing fully-qualified refs would technically be a regression.  I'm
still slightly doubtful that this is something people do in practice,
but I guess we have no way to know for sure.

-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: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Johannes Schindelin]

Hi Peff,

On Thu, 8 Jan 2015, Jeff King wrote:

> On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote:
> 
> > ICON~714.PNG is a valid short name for a long name (such as
> > 'icon.background.png') because it fits the shortening scheme (8.3 format,
> > the base name ends in ~). As this can clash with a validly shortened
> > long name, Git for Windows refuses to check out such paths by default.
> > 
> > If you want the old -- unsafe -- behavior back, just set your
> > core.protectNTFS to false (this means that you agree that the incurred
> > problems are your own responsibility and cannot be blamed on anybody else
> > ;-))
> 
> I wonder if it is worth having a "git-only" mode for core.protectNTFS.
> Turning it off entirely would make him susceptible to GIT~1 attacks.

That is a good idea!

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

Re: A better git log --graph?

[Yuri D'Elia]

On 01/08/2015 08:52 AM, Kyle J. McKay wrote:
> Since --graph is text-based, this response may not be on-topic hence  
> no cc: to the list.

I see --graph as an important tool to get an overview on how the
development is being done. I don't mind having a graphical tool for the
job, and I was even suggesting if there was a graphviz-based tool that
could do a better job.

I have a couple of projects where we made heavy use of topic branches,
cherrypicks and whatnot. Not the best way to work, but I realized I just
needed a graphical overview of the layout to streamline a bit the
development.

I normally use tig, but the drawn graph, even when turning on bar
drawing, is really poor.

> I assume that you've tried gitk?  It has a graphic viewer for the log,  
> but I also find it difficult to tell what's going on in its graph  
> although it's somewhat better than the --graph graph.  It does not  
> parse --graph output.

I usually never use frontends. The notable exception is "tig" when I
want to get a feeling of the status of several branches and/or "blame"
some files. It haves a lot of typing. That being said, I tried gitk, but
assumed it was also parsing --graph layout.

Now looking again, I notice some differencies, but it doesn't give me a
better picture.

> A better repository to view it on is the scons mirror 
> (http://repo.or.cz/scons 
> ) as it doesn't have nearly the number of branches/merges as Git  
> (direct link is   >).

It's better, but still not something I would feel like using.

Github's network "graph" is a bit better in my mind, but it also has his
own share of problems, namely trying his own logic to reduce the height
of the graph recyling the row for multiple branches.

> However, I find its graphs much easier to grok as it draws --first- 
> parent links in a much thicker line style and they stay the same color  
> so it's very easy to see forks, merges and where a fork was re-merged  
> into a main branch.

Yes, this does make a lot of difference when just looking at it. It
immediately becomes much more apparent.

I'm wondering if just turning on the bold attribute in --graph --color
would help improve the output.

> P.S. I'm not 100%, but I think that fossil shows the kinds of graphs  
> you're looking for (see a sample at 
>   >) -- each branch head stays in the same column and non-first-parent  
> links are thinner lines.

Now that's *really* readable for me! Isn't it?
I never used fossil so this is the first time I see it.

The symbols are really well chosen as well.

Can we have something like this in git?
It might entirely be that it breaks for 200 branches, but hell, for
smaller projects it's a boon.

> P.P.S. In any case if this isn't too much off-topic for your original  
> message, feel free to include any parts of the above message in a  
> reply to the list.

It was very helpful, so it's done.


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

Re: A better git log --graph?

[John Szakmeister]

On Thu, Jan 8, 2015 at 6:39 AM, Yuri D'Elia  wrote:
[snip]
> I usually never use frontends. The notable exception is "tig" when I
> want to get a feeling of the status of several branches and/or "blame"
> some files. It haves a lot of typing. That being said, I tried gitk, but
> assumed it was also parsing --graph layout.

Try "gitk --date-order".  I find it gives me the picture I really want
to see.  I've aliased it to "git k" in my gitconfig because I find it
very valuable.

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

git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

[Minty]

I appear to have hit a bug (or have data that the code fails on) while
importing an SVN repo to git.

I'm wondering if there is anything I can do to help find / fix the
cause, given I appear to have a fail-case.

Sadly I can't supply the SVN repo as the code is private.

What I did:

git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo

What I'm running:

MacOS Yosemite 10.10.1 (14B25)

§ git --version
git version 2.2.1

Built via MacPorts using: sudo port install git +svn

and updated today to the latest available.

The process was running for a few minutes and does appear to have
imported a lot.  The last few lines of output, including the error
(with paths/names anonymised)

r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
Dpath/to/stuff/Example1.java
Dpath/to/stuff/Example2.java
W: -empty_dir: path/to/stuff/Example1.java
W: -empty_dir: path/to/stuff/Example2.java
r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
write .git/Git_svn_hash_BmjclS: Bad file descriptor
 at /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
line 623.

Any advice / pointers would be welcome -- I'd be happy to run any
tests & I'm reasonably comfortable coding in Perl so happy to poke
around where I can.

I've been using git for year (thanks! it rocks) and hoping I can avoid
having to (re)learn too much about SVN.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Torsten Bögershausen]

On 01/08/2015 11:28 AM, Jeff King wrote:

On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote:


ICON~714.PNG is a valid short name for a long name (such as
'icon.background.png') because it fits the shortening scheme (8.3 format,
the base name ends in ~). As this can clash with a validly shortened
long name, Git for Windows refuses to check out such paths by default.

If you want the old -- unsafe -- behavior back, just set your
core.protectNTFS to false (this means that you agree that the incurred
problems are your own responsibility and cannot be blamed on anybody else
;-))

I wonder if it is worth having a "git-only" mode for core.protectNTFS.
Turning it off entirely would make him susceptible to GIT~1 attacks.

-Peff


There is something more then just the "tilde" protection going on, it seems:


torstenbogershausen@TORBOGWM ~/projects/test_tilde (master)
$  ~/projects/git/msysgit/git ls-files
ICON~714.PNG

torstenbogershausen@TORBOGWM ~/projects/test_tilde (master)
$  ~/projects/git/msysgit/git status
On branch master
nothing to commit, working directory clean

torstenbogershausen@TORBOGWM ~/projects/test_tilde (master)
$  ~/projects/git/tb/git status
On branch master
nothing to commit, working directory clean

torstenbogershausen@TORBOGWM ~/projects/test_tilde (master)
$  ~/projects/git/msysgit/git --version
git version 1.9.2.msysgit.0.2273.gc47d6ec

torstenbogershausen@TORBOGWM ~/projects/test_tilde (master)
$  ~/projects/git/tb/git --version
git version 2.2.1.268.g1e6f5b2

Neither latest msygit nor latest git.git reports a problem with a single 
file

within a short path.
It may be, that the '~' is not accepted in a long path or there are 
"problems"

when a directory is filled with many files, but that is speculation.

Dimitry,
is there a way to make the problem reproducible for other people ?
Either a public demo-repo, or a step-by-step receipe  ?

--
To unsubscribe from this list: send the line "unsubscribe 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] standardize usage info string format

[Matthieu Moy]

Alex Henrie  writes:

> - Placing angle brackets around fill-in-the-blank parameters
> - Putting dashes in multiword parameter names
> - Adding spaces to [-f|--foobar] to make [-f | --foobar]
> - Replacing * with [...]

The review would be easier with a patch series having one patch per item
in this list (not sure splitting the series now is worth the trouble
though).

I went quickly through the patch and didn't find any issue. I do support
the style standardization effort.

-- 
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: [msysGit] Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Johannes Schindelin]

Hi Torsten,

On Thu, 8 Jan 2015, Torsten Bögershausen wrote:

> There is something more then just the "tilde" protection going on, [...]

Indeed. What is going on is that you build Git yourself, from git.git,
while Dmitry obviously used Git for Windows -- which carries a couple of
patches on top of upstream git.git.

In this particular case, the tilde protection was introduced in
https://github.com/msysgit/git/commit/2e2a2d12.

Ciao,
Johannes

low memory system to clone larger repo

[matthew sporleder]

I am attempting to clone this repo: https://github.com/jsonn/src/

and have been successful on some lower memory systems, but i'm
interested in continuing to push down the limit.

I am getting more success running clone via https:// than git:// or
ssh (which is confusing to me) and the smallest system that works is a
raspberry pi with 256 RAM + 256 swap.

I seem to run out of memory consistently around 16% into Resolving
deltas phase but I don't notice an RSS jump so that's another
confusing spot.

My config is below and I'd appreciate any more suggestions of getting
that down to working on a 128MB box (or smaller).

---

I appreciate any suggestions,
Matt

p.s. shallow clones work fine on very small systems


[pack]
windowMemory = 1m
packSizeLimit = 1m
deltaCacheSize = 1m
deltaCacheLimit = 10
packSizeLimit = 1m
threads = 1
[core]
packedGitWindowSize = 1m
packedGitLimit = 1m
deltaBaseCacheLimit = 1m
compression = 0
loosecompression = 0
bigFileThreshold = 10m
[http]
sslVerify = false
[transfer]
unpackLimit = 10
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Torsten Bögershausen]

On 01/08/2015 04:58 PM, Johannes Schindelin wrote:
> Hi Torsten,
> 
> On Thu, 8 Jan 2015, Torsten Bögershausen wrote:
> 
>> There is something more then just the "tilde" protection going on, [...]
> 
> Indeed. What is going on is that you build Git yourself, from git.git,
> while Dmitry obviously used Git for Windows -- which carries a couple of
> patches on top of upstream git.git.
> 
> In this particular case, the tilde protection was introduced in
> https://github.com/msysgit/git/commit/2e2a2d12.
> 
> Ciao,
> Johannes
> 
My bad, I was building the msysgit master branch, which didn't have the 
2e2a2d12.

However, I am wondering if 2e2a2d12 is really needed that much ?
In the same spirit that we do not prevent the checkout of "FILE" when "file" is 
present,
why do we prevent people from using "~" in file names ?
When a file is visible under different file names, I assume that the user 
chooses only
one representation to run "git add" on.
But that is another discussion.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] SVNGit - Checkout Git repository by SVN Client

[Yi, EungJun]

Hello, all.

I just have started to develop SVNGit, the servlet library in pure
Java for SVN Client to checkout Git repository. The project is hosted
at https://github.com/naver/svngit.

Since the project is at very early stage, SVNGit unstably supports
only a few SVN commands: checkout, update and log.

SVNGit is based on SVNKit to accept HTTP(DAV) requests from SVN client
and uses JGit to access Git repository.

If you have interest in my project, please download it and test with
your Git repositories. I will be very happy if you give me a comment,
a bug report and/or a pullrequest.

Thank you for reading.
--
To unsubscribe from this list: send the line "unsubscribe 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 svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

[Minty]

On Thu, Jan 8, 2015 at 12:43 PM, Minty  wrote:
> git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo
>
> r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
> Dpath/to/stuff/Example1.java
> Dpath/to/stuff/Example2.java
> W: -empty_dir: path/to/stuff/Example1.java
> W: -empty_dir: path/to/stuff/Example2.java
> r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
> write .git/Git_svn_hash_BmjclS: Bad file descriptor
>  at 
> /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
> line 623.

fyi - tried the same repo, same command under Ubuntu 14.04, using the
stock git-svn deb & it worked.

happy to help try debugging the problem on MacOS if anyone wants to
give me a pointer, but otherwise I'm good.

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

[PATCH 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[Alexander Kuleshov]

git remote show doesn't use -v/--verbose option

Signed-off-by: Alexander Kuleshov 
---
 builtin/remote.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 46ecfd9..978c645 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
N_("git remote rename  "),
N_("git remote remove "),
N_("git remote set-head  (-a | --auto | -d | --delete 
|)"),
-   N_("git remote [-v | --verbose] show [-n] "),
+   N_("git remote show [-n] "),
N_("git remote prune [-n | --dry-run] "),
N_("git remote [-v | --verbose] update [-p | --prune] [( | 
)...]"),
N_("git remote set-branches [--add]  ..."),
-- 
2.2.1.364.g47473d1.dirty

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

[PATCH 2/2] Documentation: Remove -v/--verbose option from git remote show synopsis

[Alexander Kuleshov]

git remote show doesn't use -v/--verbose option

Signed-off-by: Alexander Kuleshov 
---
 Documentation/git-remote.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index cb103c8..07eb668 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -18,7 +18,7 @@ SYNOPSIS
 'git remote set-url' [--push]   []
 'git remote set-url --add' [--push]  
 'git remote set-url --delete' [--push]  
-'git remote' [-v | --verbose] 'show' [-n] ...
+'git remote show' [-n] ...
 'git remote prune' [-n | --dry-run] ...
 'git remote' [-v | --verbose] 'update' [-p | --prune] [( | )...]
 
-- 
2.2.1.364.g47473d1.dirty

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

[PATCH] show-branch: Indentation for show-branch usage

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 builtin/show-branch.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 270e39c..2e60107 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -6,7 +6,10 @@
 #include "parse-options.h"
 
 static const char* show_branch_usage[] = {
-N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order] [--current] [--color[=] | --no-color] [--sparse] 
[--more= | --list | --independent | --merge-base] [--no-name | --sha1-name] 
[--topics] [( | )...]"),
+N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order]\n\
+   [--current] [--color[=] | --no-color] 
[--sparse]\n\
+   [--more= | --list | --independent | --merge-base]\n\
+   [--no-name | --sha1-name] [--topics] [( | 
)...]"),
 N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
 NULL
 };
-- 
2.2.1.268.g1e6f5b2.dirty

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

[PATCH] cat-file: Move assignment to the buffer declaration

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 builtin/cat-file.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index f8d8129..840ace2 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -17,14 +17,13 @@ static int cat_one_file(int opt, const char *exp_type, 
const char *obj_name)
 {
unsigned char sha1[20];
enum object_type type;
-   char *buf;
+   char *buf = NULL;
unsigned long size;
struct object_context obj_context;
 
if (get_sha1_with_context(obj_name, 0, sha1, &obj_context))
die("Not a valid object name %s", obj_name);
 
-   buf = NULL;
switch (opt) {
case 't':
type = sha1_object_info(sha1, NULL);
-- 
2.2.1.268.g1e6f5b2.dirty

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

[PATCH] cat-file: Remove unused includes

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 builtin/cat-file.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index f8d8129..750b5a2 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -4,12 +4,8 @@
  * Copyright (C) Linus Torvalds, 2005
  */
 #include "cache.h"
-#include "exec_cmd.h"
-#include "tag.h"
-#include "tree.h"
 #include "builtin.h"
 #include "parse-options.h"
-#include "diff.h"
 #include "userdiff.h"
 #include "streaming.h"
 
-- 
2.2.1.269.g787aadb.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: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Junio C Hamano]

Jeff King  writes:

> On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote:
>
>> ICON~714.PNG is a valid short name for a long name (such as
>> 'icon.background.png') because it fits the shortening scheme (8.3 format,
>> the base name ends in ~). As this can clash with a validly shortened
>> long name, Git for Windows refuses to check out such paths by default.
>> 
>> If you want the old -- unsafe -- behavior back, just set your
>> core.protectNTFS to false (this means that you agree that the incurred
>> problems are your own responsibility and cannot be blamed on anybody else
>> ;-))
>
> I wonder if it is worth having a "git-only" mode for core.protectNTFS.
> Turning it off entirely would make him susceptible to GIT~1 attacks.

Yes, I think having distinctions would make sense, but I am not sure
if "git-only" vs "every questionable included" should be the
classification.

To classify various funniness of paths by the extent of damage they
may cause for Windows:

 - ".Git" and "GIT~1" would be the worst level; 

 - "CON.c" and the like would be the next bad level; and

 - "ICON~714.PNG" would be in "to be avoided in an ideal world but
   as long as the project is comfortable with having it in, Git is
   in no position to complain" level.

that is just my knee-jerk reaction.

And if we were to go with just two level, I'd throw "CON.c" into the
same level as ".Git"; they both are to break the host that checks
out such paths.  The former may break Git on the host, and the
latter may break something that is not Git on the host, but they are
not that different in that the end user on that host is harmed.

"8.3 ambiguity" does not directly harm individual hosts, but the
reason to flag is primarily because such a path may make the
project's contents unreliable (e.g. "icon1234234.png" may alias
"ICON~714.PNG" on somebody's machine, causing confusion).  The same
reason should make us flag a tree object as suspect if it contains
two paths that are the same case-insensitively (e.g. a tree that
represents the "net/netfilter" part of the Linux kernel source would
be flagged because it contains both "xt_tcpmss.c" and "xt_TCPMSS.c").

Let's call the former Harmful and the latter Questionable.  "CON.c"
is Harmful on Windows, while "net/netfilter" is Questionable on
Windows.  Orthogonal to this, we earlier discussed what to do in
fsck and receive.fsckObjects.  I think we want to be express
different shades of grays between the two extremes:

 - A repository of a mono-culture project would want to flag
   Harmfuls and Questionables that apply to the project's intended
   platform as errors.  By definition, a mono-culture project would
   not care about paths that may only be Harmful on others'
   platforms.

 - A repository for a cross-platform project would want to flag
   paths that may be Harmful or Questionable on some platform, and
   does not care if these paths are Harmful or Questionable on the
   platform that happens to host the repository.  By definition, a
   cross-platform project wants to make sure everybody involved will
   not get hurt.


--
To unsubscribe from this list: send the line "unsubscribe 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] gettext.h: add parentheses around N_ expansion if supported

[Junio C Hamano]

"Kyle J. McKay"  writes:

> For now only __GNUC__ is tested which covers both gcc and clang
> which should result in early detection of any adjacent N_ macros.

I didn't check the list of -W options, but if there were a way to
tell gcc to stick to the C standard in a more strict way than its
default, wouldn't this patch start causing trouble?

> Although the necessary #ifdef makes the header less elegant,
> the benefit of avoiding propagation of a translation-marking
> error to all the translation teams thus creating extra work
> for them when the error is eventually detected and fixed would
> seem to outweigh the minor inelegance the #ifdef introduces.
>
> Signed-off-by: Kyle J. McKay 
> ---
>  gettext.h | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/gettext.h b/gettext.h
> index 7671d09d..80ec29b5 100644
> --- a/gettext.h
> +++ b/gettext.h
> @@ -62,7 +62,19 @@ const char *Q_(const char *msgid, const char *plu, 
> unsigned long n)
>   return ngettext(msgid, plu, n);
>  }
>  
> -/* Mark msgid for translation but do not translate it. */
> +/* Mark msgid for translation but do not translate it.
> + *
> + * In order to prevent accidents where two adjacent N_ macros
> + * are mistakenly used, this macro is defined with parentheses
> + * when the compiler is known to support parenthesized string
> + * literal assignments.  This guarantees a compiler error in
> + * such a case rather than a silent conjoining of the strings
> + * by the preprocessor which results in translation failures.
> + */
> +#ifdef __GNUC__
> +#define N_(msgid) (msgid)
> +#else
>  #define N_(msgid) msgid
> +#endif
>  
>  #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 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[René Scharfe]

Am 08.01.2015 um 18:57 schrieb Alexander Kuleshov:

git remote show doesn't use -v/--verbose option


Hmm, but it does?

$ git version
git version 2.2.1
$ git remote show
origin
$ git remote -v show
origin  git://git.kernel.org/pub/scm/git/git.git (fetch)
origin  git://git.kernel.org/pub/scm/git/git.git (push)

Perhaps you meant the following variant?  The changed line documents the 
one above, though (-v before show).


$ git remote show -v
error: unknown switch `v'
usage: git remote show [] 

-ndo not query remotes


Signed-off-by: Alexander Kuleshov 
---
  builtin/remote.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 46ecfd9..978c645 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
N_("git remote rename  "),
N_("git remote remove "),
N_("git remote set-head  (-a | --auto | -d | --delete 
|)"),
-   N_("git remote [-v | --verbose] show [-n] "),
+   N_("git remote show [-n] "),
N_("git remote prune [-n | --dry-run] "),
N_("git remote [-v | --verbose] update [-p | --prune] [( | 
)...]"),
N_("git remote set-branches [--add]  ..."),



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

Re: [PATCH 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[Alexander Kuleshov]

Ah, yes, right. Please dismiss 1,2 patches.

Sorry for noise

2015-01-09 1:17 GMT+06:00 René Scharfe :
> Am 08.01.2015 um 18:57 schrieb Alexander Kuleshov:
>>
>> git remote show doesn't use -v/--verbose option
>
>
> Hmm, but it does?
>
> $ git version
> git version 2.2.1
> $ git remote show
> origin
> $ git remote -v show
> origin  git://git.kernel.org/pub/scm/git/git.git (fetch)
> origin  git://git.kernel.org/pub/scm/git/git.git (push)
>
> Perhaps you meant the following variant?  The changed line documents the one
> above, though (-v before show).
>
> $ git remote show -v
> error: unknown switch `v'
> usage: git remote show [] 
>
> -ndo not query remotes
>
>
>> Signed-off-by: Alexander Kuleshov 
>> ---
>>   builtin/remote.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/builtin/remote.c b/builtin/remote.c
>> index 46ecfd9..978c645 100644
>> --- a/builtin/remote.c
>> +++ b/builtin/remote.c
>> @@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
>> N_("git remote rename  "),
>> N_("git remote remove "),
>> N_("git remote set-head  (-a | --auto | -d | --delete
>> |)"),
>> -   N_("git remote [-v | --verbose] show [-n] "),
>> +   N_("git remote show [-n] "),
>> N_("git remote prune [-n | --dry-run] "),
>> N_("git remote [-v | --verbose] update [-p | --prune] [( |
>> )...]"),
>> N_("git remote set-branches [--add]  ..."),
>>
>



-- 
_
0xAX
--
To unsubscribe from this list: send the line "unsubscribe 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] cat-file: Move assignment to the buffer declaration

[Junio C Hamano]

Alexander Kuleshov  writes:

> Subject: Re: [PATCH] cat-file: Move assignment to the buffer declaration

"git shortlog" on recent history shows that it is conventional not
to upcase the sentence after the ":" on titles.

This line not just "declares" but "defines" buf, so I'd phrase it
more like:

cat-file: initialize buf to NULL at its definition

This way is shorter than with a separate assignment.

or somesuch.

If two people posted two patches to add a new cat-file.c file and
one patch did it the way the current code does while the other patch
did it the way the code with this patch does, I would likely to pick
the latter, because it is more concise and it is more clear that
there is less chance that buf could be used uninitialized.

To be bluntly honest, however, it's such a minor thing that once it
_is_ in the tree, it's not really worth the patch noise to go and
fix it up.

> Signed-off-by: Alexander Kuleshov 
> ---
>  builtin/cat-file.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index f8d8129..840ace2 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -17,14 +17,13 @@ static int cat_one_file(int opt, const char *exp_type, 
> const char *obj_name)
>  {
>   unsigned char sha1[20];
>   enum object_type type;
> - char *buf;
> + char *buf = NULL;
>   unsigned long size;
>   struct object_context obj_context;
>  
>   if (get_sha1_with_context(obj_name, 0, sha1, &obj_context))
>   die("Not a valid object name %s", obj_name);
>  
> - buf = NULL;



>   switch (opt) {
>   case 't':
>   type = sha1_object_info(sha1, NULL);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

[Jeff King]

On Thu, Jan 08, 2015 at 11:08:47AM -0800, Junio C Hamano wrote:

> > I wonder if it is worth having a "git-only" mode for core.protectNTFS.
> > Turning it off entirely would make him susceptible to GIT~1 attacks.
> 
> Yes, I think having distinctions would make sense, but I am not sure
> if "git-only" vs "every questionable included" should be the
> classification.

Yeah, I agree with everything you said below (I should have said
"security-relevant" instead of "git-only" originally). I also agree that
there may be more than two classifications, but I do not know enough
about the severity of the bad effects of each type to judge. I'd leave
that to the folks on each platform.

-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] cat-file: Remove unused includes

[Junio C Hamano]

Alexander Kuleshov  writes:

> Signed-off-by: Alexander Kuleshov 
> ---
>  builtin/cat-file.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index f8d8129..750b5a2 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -4,12 +4,8 @@
>   * Copyright (C) Linus Torvalds, 2005
>   */
>  #include "cache.h"
> -#include "exec_cmd.h"
> -#include "tag.h"
> -#include "tree.h"
>  #include "builtin.h"
>  #include "parse-options.h"
> -#include "diff.h"
>  #include "userdiff.h"
>  #include "streaming.h"

Interesting.

 - "exec_cmd.h" became unnecessary at b931aa5a (Call builtin ls-tree
   in git-cat-file -p, 2006-05-26).

 - "tag.h" and "tree.h" became unnecessary at 21666f1a (convert
   object type handling from a string to a number, 2007-02-26).

 - "diff.h" was added at e5fba602 (textconv: support for cat_file,
   2010-06-15), together with "userdiff.h".  Was it unnecessary from
   the beginning?

I didn't dig further to find out the answer to the last question,
but a patch to remove these include should explain these in its log
message, I would think.

Thanks.


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

Re: [PATCH 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[Junio C Hamano]

Alexander Kuleshov  writes:

> git remote show doesn't use -v/--verbose option
>
> Signed-off-by: Alexander Kuleshov 

Thanks.  

I think these two patches should be squashed into one (which I can
do locally without asking you to resend) but they are good changes.
The subcommand does not just "not use", but it does not even support
(i.e. it throws an error when the option is given).

> ---
>  builtin/remote.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index 46ecfd9..978c645 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
>   N_("git remote rename  "),
>   N_("git remote remove "),
>   N_("git remote set-head  (-a | --auto | -d | --delete 
> |)"),
> - N_("git remote [-v | --verbose] show [-n] "),
> + N_("git remote show [-n] "),
>   N_("git remote prune [-n | --dry-run] "),
>   N_("git remote [-v | --verbose] update [-p | --prune] [( | 
> )...]"),
>   N_("git remote set-branches [--add]  ..."),
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] configure.ac: check 'tv_nsec' field in 'struct stat'

[Reuben Hawkins]

Detect 'tv_nsec' field in 'struct stat' and set Makefile variable
NO_NSEC appropriately.

A side-effect of the above detection is that we also determine
whether 'stat.st_mtimespec' is available, so, as a bonus, set the
Makefile variable USE_ST_TIMESPEC, as well.

Signed-off-by: Reuben Hawkins 
---
 configure.ac | 13 +
 1 file changed, 13 insertions(+)

diff --git a/configure.ac b/configure.ac
index 6af9647..210eb4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -754,6 +754,19 @@ AC_CHECK_TYPES([struct itimerval],
 [#include ])
 GIT_CONF_SUBST([NO_STRUCT_ITIMERVAL])
 #
+# Define USE_ST_TIMESPEC=YesPlease when stat.st_mtimespec.tv_nsec exists.
+# Define NO_NSEC=YesPlease when neither stat.st_mtim.tv_nsec nor
+# stat.st_mtimespec.tv_nsec exists.
+AC_CHECK_MEMBER([struct stat.st_mtimespec.tv_nsec])
+AC_CHECK_MEMBER([struct stat.st_mtim.tv_nsec])
+if test x$ac_cv_member_struct_stat_st_mtimespec_tv_nsec = xyes ; then
+   USE_ST_TIMESPEC=YesPlease
+   GIT_CONF_SUBST([USE_ST_TIMESPEC])
+elif test x$ac_cv_member_struct_stat_st_mtim_tv_nsec != xyes ; then
+   NO_NSEC=YesPlease
+   GIT_CONF_SUBST([NO_NSEC])
+fi
+#
 # Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
 AC_CHECK_MEMBER(struct dirent.d_ino,
 [NO_D_INO_IN_DIRENT=],
-- 
2.2.0.68.g8f72f0c.dirty

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

[PATCH 3/3] configure.ac: check for HMAC_CTX_cleanup

[Reuben Hawkins]

OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
Newer versions define HMAC_CTX_cleanup.  Check for HMAC_CTX_cleanup and
fall back to HMAC_cleanup when the newer function is missing.

Signed-off-by: Reuben Hawkins 
---
 Makefile  | 6 ++
 configure.ac  | 4 
 git-compat-util.h | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index 57e33f2..2ce1f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -341,6 +341,9 @@ all::
 # Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt.
 #
 # Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC in librt.
+#
+# Define NO_HMAC_CTX_CLEANUP if your OpenSSL is version 0.9.6b or earlier to
+# cleanup the HMAC context with the older HMAC_cleanup function.
 
 GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1061,6 +1064,9 @@ ifndef NO_OPENSSL
ifdef NEEDS_CRYPTO_WITH_SSL
OPENSSL_LIBSSL += -lcrypto
endif
+   ifdef NO_HMAC_CTX_CLEANUP
+   BASIC_CFLAGS += -DNO_HMAC_CTX_CLEANUP
+   endif
 else
BASIC_CFLAGS += -DNO_OPENSSL
BLK_SHA1 = 1
diff --git a/configure.ac b/configure.ac
index c3293b9..9c66c3e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -924,6 +924,10 @@ AC_CHECK_LIB([iconv], [locale_charset],
  [CHARSET_LIB=-lcharset])])
 GIT_CONF_SUBST([CHARSET_LIB])
 #
+# Define NO_HMAC_CTX_CLEANUP=YesPlease if HMAC_CTX_cleanup is missing.
+AC_CHECK_LIB([crypto], [HMAC_CTX_cleanup],
+   [], [GIT_CONF_SUBST([NO_HMAC_CTX_CLEANUP], [YesPlease])])
+#
 # Define HAVE_CLOCK_GETTIME=YesPlease if clock_gettime is available.
 GIT_CHECK_FUNC(clock_gettime,
[HAVE_CLOCK_GETTIME=YesPlease],
diff --git a/git-compat-util.h b/git-compat-util.h
index 400e921..2fdca2d 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -213,6 +213,9 @@ extern char *gitbasename(char *);
 #ifndef NO_OPENSSL
 #include 
 #include 
+#ifdef NO_HMAC_CTX_CLEANUP
+#define HMAC_CTX_cleanup HMAC_cleanup
+#endif
 #endif
 
 /* On most systems  would have given us this, but
-- 
2.2.0.68.g8f72f0c.dirty

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

[PATCH 2/3] configure.ac: check for clock_gettime and CLOCK_MONOTONIC

[Reuben Hawkins]

The checks will override and unset YesPlease settings for HAVE_CLOCK_GETTIME
and HAVE_CLOCK_MONOTONIC in config.mak.uname.

CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3 systems
being used in production.

Signed-off-by: Reuben Hawkins 
---
 Makefile |  6 ++
 config.mak.uname |  1 +
 configure.ac | 22 ++
 trace.c  |  2 +-
 4 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7482a4d..57e33f2 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,8 @@ all::
 # return NULL when it receives a bogus time_t.
 #
 # Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt.
+#
+# Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC in librt.
 
 GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1382,6 +1384,10 @@ ifdef HAVE_CLOCK_GETTIME
EXTLIBS += -lrt
 endif
 
+ifdef HAVE_CLOCK_MONOTONIC
+   BASIC_CFLAGS += -DHAVE_CLOCK_MONOTONIC
+endif
+
 ifeq ($(TCLTK_PATH),)
 NO_TCLTK = NoThanks
 endif
diff --git a/config.mak.uname b/config.mak.uname
index a2f380f..926773e 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -35,6 +35,7 @@ ifeq ($(uname_S),Linux)
LIBC_CONTAINS_LIBINTL = YesPlease
HAVE_DEV_TTY = YesPlease
HAVE_CLOCK_GETTIME = YesPlease
+   HAVE_CLOCK_MONOTONIC = YesPlease
 endif
 ifeq ($(uname_S),GNU/kFreeBSD)
HAVE_ALLOCA_H = YesPlease
diff --git a/configure.ac b/configure.ac
index 210eb4e..c3293b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -924,6 +924,28 @@ AC_CHECK_LIB([iconv], [locale_charset],
  [CHARSET_LIB=-lcharset])])
 GIT_CONF_SUBST([CHARSET_LIB])
 #
+# Define HAVE_CLOCK_GETTIME=YesPlease if clock_gettime is available.
+GIT_CHECK_FUNC(clock_gettime,
+   [HAVE_CLOCK_GETTIME=YesPlease],
+   [HAVE_CLOCK_GETTIME=])
+GIT_CONF_SUBST([HAVE_CLOCK_GETTIME])
+
+AC_DEFUN([CLOCK_MONOTONIC_SRC], [
+AC_LANG_PROGRAM([[
+#include 
+clockid_t id = CLOCK_MONOTONIC;
+]])])
+
+#
+# Define HAVE_CLOCK_MONOTONIC=YesPlease if CLOCK_MONOTONIC is available.
+AC_MSG_CHECKING([for CLOCK_MONOTONIC])
+AC_COMPILE_IFELSE([CLOCK_MONOTONIC_SRC],
+   [AC_MSG_RESULT([yes])
+   HAVE_CLOCK_MONOTONIC=YesPlease],
+   [AC_MSG_RESULT([no])
+   HAVE_CLOCK_MONOTONIC=])
+GIT_CONF_SUBST([HAVE_CLOCK_MONOTONIC])
+#
 # Define NO_SETITIMER if you don't have setitimer.
 GIT_CHECK_FUNC(setitimer,
 [NO_SETITIMER=],
diff --git a/trace.c b/trace.c
index 4778608..bfbd48f 100644
--- a/trace.c
+++ b/trace.c
@@ -324,7 +324,7 @@ int trace_want(struct trace_key *key)
return !!get_trace_fd(key);
 }
 
-#ifdef HAVE_CLOCK_GETTIME
+#if defined(HAVE_CLOCK_GETTIME) && defined(HAVE_CLOCK_MONOTONIC)
 
 static inline uint64_t highres_nanos(void)
 {
-- 
2.2.0.68.g8f72f0c.dirty

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

Re: [PATCH] show-branch: Indentation for show-branch usage

[Junio C Hamano]

Alexander Kuleshov  writes:

> Signed-off-by: Alexander Kuleshov 
> ---

s/Indentation for/line-wrap/, perhaps?

What the patch wants to do makes sense to me, but I haven't seen a
long multi-line string, each lines in which is terminated with "\n\"
in the source, fed to N_() macro anywhere else in the existing
codebase, which makes me a bit nervous.

Would writing it this way instead, i.e. making it more obvious where
each line begins and how long the indentation of subsequent lines are,
also work?

N_("git show-branch [-a|--all] ...\n"
   "[--current] [--color[=]] ...\n"
   ...
   "[--no-name ...");

Or does it break N_() macro?

Thanks.


>  builtin/show-branch.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/show-branch.c b/builtin/show-branch.c
> index 270e39c..2e60107 100644
> --- a/builtin/show-branch.c
> +++ b/builtin/show-branch.c
> @@ -6,7 +6,10 @@
>  #include "parse-options.h"
>  
>  static const char* show_branch_usage[] = {
> -N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
> --date-order] [--current] [--color[=] | --no-color] [--sparse] 
> [--more= | --list | --independent | --merge-base] [--no-name | 
> --sha1-name] [--topics] [( | )...]"),
> +N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
> --date-order]\n\
> +   [--current] [--color[=] | --no-color] 
> [--sparse]\n\
> +   [--more= | --list | --independent | 
> --merge-base]\n\
> +   [--no-name | --sha1-name] [--topics] [( | 
> )...]"),
>  N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
>  NULL
>  };
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[Junio C Hamano]

René Scharfe  writes:

> Am 08.01.2015 um 18:57 schrieb Alexander Kuleshov:
>> git remote show doesn't use -v/--verbose option
>
> Hmm, but it does?
>
>   $ git version
>   git version 2.2.1
>   $ git remote show
>   origin
>   $ git remote -v show
>   origin  git://git.kernel.org/pub/scm/git/git.git (fetch)
>   origin  git://git.kernel.org/pub/scm/git/git.git (push)
>
> Perhaps you meant the following variant?  The changed line documents
> the one above, though (-v before show).
>
>   $ git remote show -v
>   error: unknown switch `v'
>   usage: git remote show [] 
>
>   -ndo not query remotes

Ahh, I misread the patch.  Thanks.

>> diff --git a/builtin/remote.c b/builtin/remote.c
>> index 46ecfd9..978c645 100644
>> --- a/builtin/remote.c
>> +++ b/builtin/remote.c
>> @@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
>>  N_("git remote rename  "),
>>  N_("git remote remove "),
>>  N_("git remote set-head  (-a | --auto | -d | --delete 
>> |)"),
>> -N_("git remote [-v | --verbose] show [-n] "),
>> +N_("git remote show [-n] "),
>>  N_("git remote prune [-n | --dry-run] "),
>>  N_("git remote [-v | --verbose] update [-p | --prune] [( | 
>> )...]"),
>>  N_("git remote set-branches [--add]  ..."),
>>

I however have a bit larger question.  Does it make sense to have
[-v/--verbose] in front of some but not all of the subcommands?

For example, the above snippet gives me an impression that

$ git remote -v prune -n origin

should not work, but that does not seem to be the case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cat-file: Remove unused includes

[Alexander Kuleshov]

Will research this question and resend the patch.

Thank you.

2015-01-09 1:45 GMT+06:00 Junio C Hamano :
> Alexander Kuleshov  writes:
>
>> Signed-off-by: Alexander Kuleshov 
>> ---
>>  builtin/cat-file.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
>> index f8d8129..750b5a2 100644
>> --- a/builtin/cat-file.c
>> +++ b/builtin/cat-file.c
>> @@ -4,12 +4,8 @@
>>   * Copyright (C) Linus Torvalds, 2005
>>   */
>>  #include "cache.h"
>> -#include "exec_cmd.h"
>> -#include "tag.h"
>> -#include "tree.h"
>>  #include "builtin.h"
>>  #include "parse-options.h"
>> -#include "diff.h"
>>  #include "userdiff.h"
>>  #include "streaming.h"
>
> Interesting.
>
>  - "exec_cmd.h" became unnecessary at b931aa5a (Call builtin ls-tree
>in git-cat-file -p, 2006-05-26).
>
>  - "tag.h" and "tree.h" became unnecessary at 21666f1a (convert
>object type handling from a string to a number, 2007-02-26).
>
>  - "diff.h" was added at e5fba602 (textconv: support for cat_file,
>2010-06-15), together with "userdiff.h".  Was it unnecessary from
>the beginning?
>
> I didn't dig further to find out the answer to the last question,
> but a patch to remove these include should explain these in its log
> message, I would think.
>
> Thanks.
>
>



-- 
_
0xAX
--
To unsubscribe from this list: send the line "unsubscribe 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] show-branch: Indentation for show-branch usage

[Alexander Kuleshov]

No it doesn't breaks N_ macro. Will resend the patch.

2015-01-09 2:05 GMT+06:00 Junio C Hamano :
> Alexander Kuleshov  writes:
>
>> Signed-off-by: Alexander Kuleshov 
>> ---
>
> s/Indentation for/line-wrap/, perhaps?
>
> What the patch wants to do makes sense to me, but I haven't seen a
> long multi-line string, each lines in which is terminated with "\n\"
> in the source, fed to N_() macro anywhere else in the existing
> codebase, which makes me a bit nervous.
>
> Would writing it this way instead, i.e. making it more obvious where
> each line begins and how long the indentation of subsequent lines are,
> also work?
>
> N_("git show-branch [-a|--all] ...\n"
>"[--current] [--color[=]] ...\n"
>...
>"[--no-name ...");
>
> Or does it break N_() macro?
>
> Thanks.
>
>
>>  builtin/show-branch.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/show-branch.c b/builtin/show-branch.c
>> index 270e39c..2e60107 100644
>> --- a/builtin/show-branch.c
>> +++ b/builtin/show-branch.c
>> @@ -6,7 +6,10 @@
>>  #include "parse-options.h"
>>
>>  static const char* show_branch_usage[] = {
>> -N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
>> --date-order] [--current] [--color[=] | --no-color] [--sparse] 
>> [--more= | --list | --independent | --merge-base] [--no-name | 
>> --sha1-name] [--topics] [( | )...]"),
>> +N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
>> --date-order]\n\
>> +   [--current] [--color[=] | --no-color] 
>> [--sparse]\n\
>> +   [--more= | --list | --independent | 
>> --merge-base]\n\
>> +   [--no-name | --sha1-name] [--topics] [( | 
>> )...]"),
>>  N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
>>  NULL
>>  };



-- 
_
0xAX
--
To unsubscribe from this list: send the line "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] show-branch: line-wrap for show-branch usage

[Alexander Kuleshov]

Signed-off-by: 0xAX 
---
 builtin/show-branch.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 270e39c..18245ad 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -6,9 +6,11 @@
 #include "parse-options.h"
 
 static const char* show_branch_usage[] = {
-N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order] [--current] [--color[=] | --no-color] [--sparse] 
[--more= | --list | --independent | --merge-base] [--no-name | --sha1-name] 
[--topics] [( | )...]"),
-N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
-NULL
+   N_("git show-branch [-a|--all] [-r|--remotes] [--topo-order | 
--date-order]\n"
+"   [--current] [--color[=] | --no-color] [--sparse] 
[--more= | --list | --independent | --merge-base]\n"
+"   [--no-name | --sha1-name] [--topics] [( | 
)...]"),
+   N_("git show-branch (-g|--reflog)[=[,]] [--list] []"),
+   NULL
 };
 
 static int showbranch_use_color = -1;
-- 
2.2.1.269.gb441311.dirty

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

Re: [PATCH 1/2] remote: Remove -v/--verbose option from git remote show synopsis

[Alexander Kuleshov]

What if move -v/--verbose after commands? Like:

git remote show [-v | --verbose] [-n] 

and etc...?

2015-01-09 2:14 GMT+06:00 Junio C Hamano :
> René Scharfe  writes:
>
>> Am 08.01.2015 um 18:57 schrieb Alexander Kuleshov:
>>> git remote show doesn't use -v/--verbose option
>>
>> Hmm, but it does?
>>
>>   $ git version
>>   git version 2.2.1
>>   $ git remote show
>>   origin
>>   $ git remote -v show
>>   origin  git://git.kernel.org/pub/scm/git/git.git (fetch)
>>   origin  git://git.kernel.org/pub/scm/git/git.git (push)
>>
>> Perhaps you meant the following variant?  The changed line documents
>> the one above, though (-v before show).
>>
>>   $ git remote show -v
>>   error: unknown switch `v'
>>   usage: git remote show [] 
>>
>>   -ndo not query remotes
>
> Ahh, I misread the patch.  Thanks.
>
>>> diff --git a/builtin/remote.c b/builtin/remote.c
>>> index 46ecfd9..978c645 100644
>>> --- a/builtin/remote.c
>>> +++ b/builtin/remote.c
>>> @@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
>>>  N_("git remote rename  "),
>>>  N_("git remote remove "),
>>>  N_("git remote set-head  (-a | --auto | -d | --delete 
>>> |)"),
>>> -N_("git remote [-v | --verbose] show [-n] "),
>>> +N_("git remote show [-n] "),
>>>  N_("git remote prune [-n | --dry-run] "),
>>>  N_("git remote [-v | --verbose] update [-p | --prune] [( | 
>>> )...]"),
>>>  N_("git remote set-branches [--add]  ..."),
>>>
>
> I however have a bit larger question.  Does it make sense to have
> [-v/--verbose] in front of some but not all of the subcommands?
>
> For example, the above snippet gives me an impression that
>
> $ git remote -v prune -n origin
>
> should not work, but that does not seem to be the case.



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

Re: PATCH/RFC: format-patch: Add format.subjectprefixsep to change separators

[Marc Finet]

On Sun, Jan 04, 2015 at 11:55:24AM -0800, Junio C Hamano wrote:
> Marc Finet  writes:
> 
> > Some mailing list use "PATCH:" rather than "[PATCH]" to prefix
> > patches, so introduce a new option to configure:
> >  - 2 chars that would enclose PATCH (and counters)
> >  - 1 char that would come just after the PATCH (and counters)
> > ---
> > This mail has been sent with:
> >  git -c format.subjectprefixsep=: send-email --annotate 
> > --subject-prefix=PATCH/RFC
> 
> A few comments:
> 
>  - "Some mailing lists" may want to say "[PATCH v3 #4 of 10]" or
>somesuch; as a customization mechanism, the approach this patch
>takes falls way short to be useful.  "--subject=" option
>where  is similar the "log --format" options, e.g.
> 
>--subject="[PATCH% v #%N of %T] %s"
> 
>with format-patch specific set of substitutions (in the above
>example, %v stands for patch version, %N patch number and %T
>total number of patches in the series) may be a better way to go.
In fact the log-tree.c::log_write_email_headers() has two cases
depending on the number of patches to send. So we need either two (or
three) options or we need to implement (because AFAIK it does not exists
yet) conditionals. Both seemed to me a little bit overkill here.
 
>  - Do not add configuration variable before you add command line
>option.  Add option first and then when option proves useful you
>can have the corresponding variable, not the other way around.
>Make sure that the comamnd line option overrides configuration
>variable while adding the variable in the second step of such a
>patch series.
Ok.

> Having said all that.
> 
> What are these mailing lists and why are they using non-standard
> convention?  Back when Git was young, we would have added more knobs
> to adjust the behaviour to existing prevailing convention, but now
> Git is older than X% of projects that use Git where the number X is
> a pretty large number.  Perhaps just like they (whichever mailing
> lists they are) switched out of Subversion or CVS and started using
> Git to come to the modern world, maybe it is time they switch their
> convention as well?
Well, the only mailing-list I saw this behavior is zsh. I did not dig
into its history to see when this behavior has been adopted. I did not
see remarks regarding patches sent with [PATCH], but I just wanted to
adopt the existing style rather than using a new one and thought that
git was already providing a way to do so, and eventually developed this
patch.

So, I do not know what to do now:
 - stick to [PATCH]
 - try one of the two first alternatives above (multiple options or
   implement conditionals)
 - re-work this patch by implementing the command line option, creating
   an other patch to use a configuration option, and hope it would be
   accepted because it makes sense to some people. The only advantage of
   using PATCH: rather than [PATCH] is that 1 char is saved :|. Making
   the subject less 'aggressive' is a feature but not necessarily an
   advantage.

Failing to see some interest for solutions 2 or 3, I would fall back to
solution 1 :).

Thanks,

Marc.
--
To unsubscribe from this list: send the line "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] receive-pack: support push-to-checkout hook

[Junio C Hamano]

When receive.denyCurrentBranch is set to updateInstead, a push that
tries to update the branch that is currently checked out is accepted
only when the index and the working tree exactly matches the
currently checked out commit, in which case the index and the
working tree are updated to match the pushed commit.  Otherwise the
push is refused.

This hook can be used to customize this "push-to-deploy" logic.  The
hook receives the commit with which the tip of the current branch is
going to be updated, and can decide what kind of local changes are
acceptable and how to update the index and the working tree to match
the updated tip of the current branch.

For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
in order to emulate 'git fetch' that is run in the reverse direction
with `git push`, as the two-tree form of `read-tree -u -m` is
essentially the same as `git checkout` that switches branches while
keeping the local changes in the working tree that do not interfere
with the difference between the branches.

Signed-off-by: Junio C Hamano 
---

 * This is an update to $gmane/260527; relative to what I have been
   keeping in 'pu', the only difference is that it comes with
   documentation updates.

 Documentation/config.txt   |  6 -
 Documentation/githooks.txt | 30 ++
 builtin/receive-pack.c | 19 +-
 t/t5516-fetch-push.sh  | 63 ++
 4 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6a4c19e..4e558ab 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2131,11 +2131,15 @@ receive.denyCurrentBranch::
message. Defaults to "refuse".
 +
 Another option is "updateInstead" which will update the working
-directory (must be clean) if pushing into the current branch. This option is
+tree if pushing into the current branch.  This option is
 intended for synchronizing working directories when one side is not easily
 accessible via interactive ssh (e.g. a live web site, hence the requirement
 that the working directory be clean). This mode also comes in handy when
 developing inside a VM to test and fix code on different Operating Systems.
++
+By default, "updateInstead" will refuse the push if the working tree or
+the index have any difference from the HEAD, but the `push-to-checkout`
+hook can be used to customize this.  See linkgit:githooks[5].
 
 receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 9ef2469..7ba0ac9 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -341,6 +341,36 @@ Both standard output and standard error output are 
forwarded to
 'git send-pack' on the other end, so you can simply `echo` messages
 for the user.
 
+push-to-checkout
+
+
+This hook is invoked by 'git-receive-pack' on the remote repository,
+which happens when a 'git push' is done on a local repository, when
+the push tries to update the branch that is currently checked out
+and the `receive.denyCurrentBranch` configuration variable is set to
+`updateInstead`.  Such a push by default is refused if the working
+tree and the index of the remote repository has any difference from
+the currently checked out commit; when both the working tree and the
+index match the current commit, they are updated to match the newly
+pushed tip of the branch.  This hook is to be used to override the
+default behaviour.
+
+The hook receives the commit with which the tip of the current
+branch is going to be updated.  It can exit with a non-zero status
+to refuse the push (when it does so, it must not modify the index or
+the working tree).  Or it can make any necessary changes to the
+working tree and to the index to bring them to the desired state
+when the tip of the current branch is updated to the new commit, and
+exit with a zero status.
+
+For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
+in order to emulate 'git fetch' that is run in the reverse direction
+with `git push`, as the two-tree form of `read-tree -u -m` is
+essentially the same as `git checkout` that switches branches while
+keeping the local changes in the working tree that do not interfere
+with the difference between the branches.
+
+
 pre-auto-gc
 ~~~
 
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 11800cd..fc8ec9c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -797,6 +797,20 @@ static const char *push_to_deploy(unsigned char *sha1,
return NULL;
 }
 
+static const char *push_to_checkout_hook = "push-to-checkout";
+
+static const char *push_to_checkout(unsigned char *sha1,
+   struct argv_array *env,
+   const char *work_tree)
+{
+   argv_array_pushf(env, "GIT_WORK_TREE=%s", absolu

Re: [PATCHv12 06/10] receive-pack.c: negotiate atomic push support

[Junio C Hamano]

Stefan Beller  writes:

> From: Ronnie Sahlberg 
>
> This adds the atomic protocol option to allow
> receive-pack to inform the client that it has
> atomic push capability.
>
> This commit makes the functionality introduced
> in the previous commits go live for the serving
> side. The changes in documentation reflect the
> protocol capabilities of the server.
>
> Signed-off-by: Stefan Beller 
> ---
>
> Notes:
> v10, v11, v12:
> * no changes
> 
> v9:
>  This was once part of "[PATCH 1/7] receive-pack.c:
>  add protocol support to negotiate atomic-push"
>  but now it only touches the receive-pack.c part
>  and doesn't bother with the send-pack part any more.
>  That is done in a later patch, when send-pack actually
>  learns all the things it needs to know about the
>  atomic push option.
> 
>  We can configure the remote if it wants to advertise
>  atomicity!
> 
> All previous notes were lost due to my glorious
> capability to operate git rebase.

The list archive remembers if you really care ;-)

I ran out of time and concentration for today to read it through at
this step; among things I saw, nothing looked wrong so far, and at
this step everything looks ready to be tested almost.

Looking good.

>
>  Documentation/technical/protocol-capabilities.txt | 13 +++--
>  builtin/receive-pack.c| 11 +++
>  2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/technical/protocol-capabilities.txt 
> b/Documentation/technical/protocol-capabilities.txt
> index 6d5424c..4f8a7bf 100644
> --- a/Documentation/technical/protocol-capabilities.txt
> +++ b/Documentation/technical/protocol-capabilities.txt
> @@ -18,8 +18,9 @@ was sent.  Server MUST NOT ignore capabilities that client 
> requested
>  and server advertised.  As a consequence of these rules, server MUST
>  NOT advertise capabilities it does not understand.
>  
> -The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities
> -are sent and recognized by the receive-pack (push to server) process.
> +The 'atomic', 'report-status', 'delete-refs', 'quiet', and 'push-cert'
> +capabilities are sent and recognized by the receive-pack (push to server)
> +process.
>  
>  The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
>  by both upload-pack and receive-pack protocols.  The 'agent' capability
> @@ -244,6 +245,14 @@ respond with the 'quiet' capability to suppress 
> server-side progress
>  reporting if the local progress reporting is also being suppressed
>  (e.g., via `push -q`, or if stderr does not go to a tty).
>  
> +atomic
> +--
> +
> +If the server sends the 'atomic' capability it is capable of accepting
> +atomic pushes. If the pushing client requests this capability, the server
> +will update the refs in one atomic transaction. Either all refs are
> +updated or none.
> +
>  allow-tip-sha1-in-want
>  --
>  
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 362d33f..4c069c5 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -37,6 +37,7 @@ static int receive_fsck_objects = -1;
>  static int transfer_fsck_objects = -1;
>  static int receive_unpack_limit = -1;
>  static int transfer_unpack_limit = -1;
> +static int advertise_atomic_push = 1;
>  static int unpack_limit = 100;
>  static int report_status;
>  static int use_sideband;
> @@ -159,6 +160,11 @@ static int receive_pack_config(const char *var, const 
> char *value, void *cb)
>   return 0;
>   }
>  
> + if (strcmp(var, "receive.advertiseatomic") == 0) {
> + advertise_atomic_push = git_config_bool(var, value);
> + return 0;
> + }
> +
>   return git_default_config(var, value, cb);
>  }
>  
> @@ -174,6 +180,8 @@ static void show_ref(const char *path, const unsigned 
> char *sha1)
>  
>   strbuf_addstr(&cap,
> "report-status delete-refs side-band-64k quiet");
> + if (advertise_atomic_push)
> + strbuf_addstr(&cap, " atomic");
>   if (prefer_ofs_delta)
>   strbuf_addstr(&cap, " ofs-delta");
>   if (push_cert_nonce)
> @@ -1263,6 +1271,9 @@ static struct command *read_head_info(struct sha1_array 
> *shallow)
>   use_sideband = LARGE_PACKET_MAX;
>   if (parse_feature_request(feature_list, "quiet"))
>   quiet = 1;
> + if (advertise_atomic_push
> + && parse_feature_request(feature_list, "atomic"))
> + use_atomic = 1;
>   }
>  
>   if (!strcmp(line, "push-cert")) {
--
To unsubscribe from this list: send the line "unsubscribe 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] gettext.h: add parentheses around N_ expansion if supported

[Kyle J. McKay]

On Jan 8, 2015, at 11:10, Junio C Hamano wrote:


"Kyle J. McKay"  writes:


For now only __GNUC__ is tested which covers both gcc and clang
which should result in early detection of any adjacent N_ macros.


I didn't check the list of -W options, but if there were a way to
tell gcc to stick to the C standard in a more strict way than its
default, wouldn't this patch start causing trouble?


With this test program:

-BEGIN TEST.C-
#include 

#define msg1(x) x
#define msg2(x) (x)

static const char *const a1[] = {
msg1("hi"),
msg2("bye") /* line 8 */
};

static const char s1[] = msg1("hi");

static const char s2[] = msg2("bye"); /* line 13 */

int main()
{
puts(a1[0]);
puts(a1[1]);
puts(s1);
puts(s2);
return 0;
}
-END TEST.C-

gcc, (but not clang) emits a warning (it still compiles just fine)  
when -pedantic is used:


  test.c:13: warning: array initialized from parenthesized string  
constant


However, none of -ansi, -Wall or -Wextra trigger that warning.

Neither does using -ansi -Wall -Wextra together cause a warning to be  
emitted (by either gcc or clang).


Note that line 8 never causes a problem (nor should it), only line 13  
is in question.


After a quick read-through of the -Wxxx options there does not appear  
to be a separate -Wxxx option to get that particular warning.


And compiling Git with -pedantic spits out a LOT of warnings (over  
7200) even before making the "(msgid)" change so I don't think there's  
an issue as apparently -pedantic is not normally used to compile Git.


Note that Git will not compile with gcc using -ansi (unless you add - 
Dinline=__inline__) and the change does not cause any new warnings to  
be emitted with -ansi (after adding the needed -Dinline=__inline__)  
since -pedantic is required for the "parenthesized string constant"  
warning.


I'm not super attached to this change, it's just that it seems to me  
that translation support for Git is a scarce resource.  I'm guessing  
that when considering the 7 complete translations (bg, ca, de, fr, sv,  
vi and zh_CN) the average number of translators per language is in the  
low single digits.  So I hate to see unnecessary translation churn,  
not when it can be so easily prevented.


-Kyle


Although the necessary #ifdef makes the header less elegant,
the benefit of avoiding propagation of a translation-marking
error to all the translation teams thus creating extra work
for them when the error is eventually detected and fixed would
seem to outweigh the minor inelegance the #ifdef introduces.

Signed-off-by: Kyle J. McKay 
---
gettext.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gettext.h b/gettext.h
index 7671d09d..80ec29b5 100644
--- a/gettext.h
+++ b/gettext.h
@@ -62,7 +62,19 @@ const char *Q_(const char *msgid, const char  
*plu, unsigned long n)

return ngettext(msgid, plu, n);
}

-/* Mark msgid for translation but do not translate it. */
+/* Mark msgid for translation but do not translate it.
+ *
+ * In order to prevent accidents where two adjacent N_ macros
+ * are mistakenly used, this macro is defined with parentheses
+ * when the compiler is known to support parenthesized string
+ * literal assignments.  This guarantees a compiler error in
+ * such a case rather than a silent conjoining of the strings
+ * by the preprocessor which results in translation failures.
+ */
+#ifdef __GNUC__
+#define N_(msgid) (msgid)
+#else
#define N_(msgid) msgid
+#endif

#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 1/3] configure.ac: check 'tv_nsec' field in 'struct stat'

[Eric Sunshine]

On Thu, Jan 8, 2015 at 3:00 PM, Reuben Hawkins  wrote:
> Detect 'tv_nsec' field in 'struct stat' and set Makefile variable
> NO_NSEC appropriately.
>
> A side-effect of the above detection is that we also determine
> whether 'stat.st_mtimespec' is available, so, as a bonus, set the
> Makefile variable USE_ST_TIMESPEC, as well.
>
> Signed-off-by: Reuben Hawkins 

These patches may or may not deserve a Helped-by:.

With or without the Helped-by: and the minor style fix-up below...

Reviewed-by: Eric Sunshine 

Thanks for the perseverance.

For convenience of other reviewers: This is v3. v1 through v3 are
threaded together here:
http://thread.gmane.org/gmane.comp.version-control.git/261619

> ---
> diff --git a/configure.ac b/configure.ac
> index 6af9647..210eb4e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -754,6 +754,19 @@ AC_CHECK_TYPES([struct itimerval],
>  [#include ])
>  GIT_CONF_SUBST([NO_STRUCT_ITIMERVAL])
>  #
> +# Define USE_ST_TIMESPEC=YesPlease when stat.st_mtimespec.tv_nsec exists.
> +# Define NO_NSEC=YesPlease when neither stat.st_mtim.tv_nsec nor
> +# stat.st_mtimespec.tv_nsec exists.
> +AC_CHECK_MEMBER([struct stat.st_mtimespec.tv_nsec])
> +AC_CHECK_MEMBER([struct stat.st_mtim.tv_nsec])
> +if test x$ac_cv_member_struct_stat_st_mtimespec_tv_nsec = xyes ; then

Style: For consistency with all other 'if' conditionals in
configure.ac, drop the space before the semicolon.

> +   USE_ST_TIMESPEC=YesPlease
> +   GIT_CONF_SUBST([USE_ST_TIMESPEC])
> +elif test x$ac_cv_member_struct_stat_st_mtim_tv_nsec != xyes ; then

Ditto.

> +   NO_NSEC=YesPlease
> +   GIT_CONF_SUBST([NO_NSEC])
> +fi
> +#
>  # Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
>  AC_CHECK_MEMBER(struct dirent.d_ino,
>  [NO_D_INO_IN_DIRENT=],
> --
> 2.2.0.68.g8f72f0c.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] configure.ac: check for HMAC_CTX_cleanup

[Eric Sunshine]

On Thu, Jan 8, 2015 at 3:00 PM, Reuben Hawkins  wrote:
> OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
> Newer versions define HMAC_CTX_cleanup.  Check for HMAC_CTX_cleanup and
> fall back to HMAC_cleanup when the newer function is missing.
>
> Signed-off-by: Reuben Hawkins 

Reviewed-by: Eric Sunshine 

Note that this patch has a minor and simple-to-resolve conflict with
b195aa00c1 (git-compat-util: suppress unavoidable Apple-specific
deprecation warnings; 2014-12-16) which was just promoted to master.
Junio may resolve it locally or ask you to re-send.

> ---
> diff --git a/Makefile b/Makefile
> index 57e33f2..2ce1f1f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -341,6 +341,9 @@ all::
>  # Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt.
>  #
>  # Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC in librt.
> +#
> +# Define NO_HMAC_CTX_CLEANUP if your OpenSSL is version 0.9.6b or earlier to
> +# cleanup the HMAC context with the older HMAC_cleanup function.
>
>  GIT-VERSION-FILE: FORCE
> @$(SHELL_PATH) ./GIT-VERSION-GEN
> @@ -1061,6 +1064,9 @@ ifndef NO_OPENSSL
> ifdef NEEDS_CRYPTO_WITH_SSL
> OPENSSL_LIBSSL += -lcrypto
> endif
> +   ifdef NO_HMAC_CTX_CLEANUP
> +   BASIC_CFLAGS += -DNO_HMAC_CTX_CLEANUP
> +   endif
>  else
> BASIC_CFLAGS += -DNO_OPENSSL
> BLK_SHA1 = 1
> diff --git a/configure.ac b/configure.ac
> index c3293b9..9c66c3e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -924,6 +924,10 @@ AC_CHECK_LIB([iconv], [locale_charset],
>   [CHARSET_LIB=-lcharset])])
>  GIT_CONF_SUBST([CHARSET_LIB])
>  #
> +# Define NO_HMAC_CTX_CLEANUP=YesPlease if HMAC_CTX_cleanup is missing.
> +AC_CHECK_LIB([crypto], [HMAC_CTX_cleanup],
> +   [], [GIT_CONF_SUBST([NO_HMAC_CTX_CLEANUP], [YesPlease])])
> +#
>  # Define HAVE_CLOCK_GETTIME=YesPlease if clock_gettime is available.
>  GIT_CHECK_FUNC(clock_gettime,
> [HAVE_CLOCK_GETTIME=YesPlease],
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 400e921..2fdca2d 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -213,6 +213,9 @@ extern char *gitbasename(char *);
>  #ifndef NO_OPENSSL
>  #include 
>  #include 
> +#ifdef NO_HMAC_CTX_CLEANUP
> +#define HMAC_CTX_cleanup HMAC_cleanup
> +#endif
>  #endif
>
>  /* On most systems  would have given us this, but
> --
> 2.2.0.68.g8f72f0c.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] configure.ac: check for clock_gettime and CLOCK_MONOTONIC

[Eric Sunshine]

On Thu, Jan 8, 2015 at 3:00 PM, Reuben Hawkins  wrote:
> The checks will override and unset YesPlease settings for HAVE_CLOCK_GETTIME
> and HAVE_CLOCK_MONOTONIC in config.mak.uname.

I find this hard to grok and would rewrite it as:

Set or clear Makefile variables HAVE_CLOCK_GETTIME and
HAVE_CLOCK_MONOTONIC based upon results of the checks (overriding
default values from config.mak.uname).

> CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3 systems
> being used in production.
>
> Signed-off-by: Reuben Hawkins 

With or without the minor rewrite above...

Reviewed-by: Eric Sunshine 

> ---
> diff --git a/Makefile b/Makefile
> index 7482a4d..57e33f2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,8 @@ all::
>  # return NULL when it receives a bogus time_t.
>  #
>  # Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt.
> +#
> +# Define HAVE_CLOCK_MONOTONIC if your platform has CLOCK_MONOTONIC in librt.
>
>  GIT-VERSION-FILE: FORCE
> @$(SHELL_PATH) ./GIT-VERSION-GEN
> @@ -1382,6 +1384,10 @@ ifdef HAVE_CLOCK_GETTIME
> EXTLIBS += -lrt
>  endif
>
> +ifdef HAVE_CLOCK_MONOTONIC
> +   BASIC_CFLAGS += -DHAVE_CLOCK_MONOTONIC
> +endif
> +
>  ifeq ($(TCLTK_PATH),)
>  NO_TCLTK = NoThanks
>  endif
> diff --git a/config.mak.uname b/config.mak.uname
> index a2f380f..926773e 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -35,6 +35,7 @@ ifeq ($(uname_S),Linux)
> LIBC_CONTAINS_LIBINTL = YesPlease
> HAVE_DEV_TTY = YesPlease
> HAVE_CLOCK_GETTIME = YesPlease
> +   HAVE_CLOCK_MONOTONIC = YesPlease
>  endif
>  ifeq ($(uname_S),GNU/kFreeBSD)
> HAVE_ALLOCA_H = YesPlease
> diff --git a/configure.ac b/configure.ac
> index 210eb4e..c3293b9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -924,6 +924,28 @@ AC_CHECK_LIB([iconv], [locale_charset],
>   [CHARSET_LIB=-lcharset])])
>  GIT_CONF_SUBST([CHARSET_LIB])
>  #
> +# Define HAVE_CLOCK_GETTIME=YesPlease if clock_gettime is available.
> +GIT_CHECK_FUNC(clock_gettime,
> +   [HAVE_CLOCK_GETTIME=YesPlease],
> +   [HAVE_CLOCK_GETTIME=])
> +GIT_CONF_SUBST([HAVE_CLOCK_GETTIME])
> +
> +AC_DEFUN([CLOCK_MONOTONIC_SRC], [
> +AC_LANG_PROGRAM([[
> +#include 
> +clockid_t id = CLOCK_MONOTONIC;
> +]])])
> +
> +#
> +# Define HAVE_CLOCK_MONOTONIC=YesPlease if CLOCK_MONOTONIC is available.
> +AC_MSG_CHECKING([for CLOCK_MONOTONIC])
> +AC_COMPILE_IFELSE([CLOCK_MONOTONIC_SRC],
> +   [AC_MSG_RESULT([yes])
> +   HAVE_CLOCK_MONOTONIC=YesPlease],
> +   [AC_MSG_RESULT([no])
> +   HAVE_CLOCK_MONOTONIC=])
> +GIT_CONF_SUBST([HAVE_CLOCK_MONOTONIC])
> +#
>  # Define NO_SETITIMER if you don't have setitimer.
>  GIT_CHECK_FUNC(setitimer,
>  [NO_SETITIMER=],
> diff --git a/trace.c b/trace.c
> index 4778608..bfbd48f 100644
> --- a/trace.c
> +++ b/trace.c
> @@ -324,7 +324,7 @@ int trace_want(struct trace_key *key)
> return !!get_trace_fd(key);
>  }
>
> -#ifdef HAVE_CLOCK_GETTIME
> +#if defined(HAVE_CLOCK_GETTIME) && defined(HAVE_CLOCK_MONOTONIC)
>
>  static inline uint64_t highres_nanos(void)
>  {
> --
> 2.2.0.68.g8f72f0c.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: added long options for -v and -n

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 Documentation/git-add.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 9631526..1c74907 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -8,7 +8,7 @@ git-add - Add file contents to the index
 SYNOPSIS
 
 [verse]
-'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | 
-i] [--patch | -p]
  [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
  [--intent-to-add | -N] [--refresh] [--ignore-errors] 
[--ignore-missing]
  [--] [...]
-- 
2.2.1.522.g2561c04.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