* [PATCH] attr: expose error reporting function for invalid attribute names
From: Stefan Beller @ 2016-10-26 21:20 UTC (permalink / raw)
To: ramsay; +Cc: git, bmwill, gitster, pclouds, Stefan Beller
In-Reply-To: <0425fea3-3419-c265-b964-f5a309b867fa@ramsayjones.plus.com>
From: Junio C Hamano <gitster@pobox.com>
Export invalid_attr_name_message() function that returns the
message to be given when a given <name, len> pair
is not a good name for an attribute.
We could later update the message to exactly spell out what the
rules for a good attribute name are, etc.
We do not need to export the validity check 'attr_name_valid()' itself
as we will learn about the validity indirectly in a later patch
via calling 'git_attr_counted()'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Ramsay,
I intend to replace the previous
[PATCH 17/36] attr: expose validity check for attribute names
by this one in a reroll.
Thanks,
Stefan
attr.c | 39 +++++++++++++++++++++++++--------------
attr.h | 2 ++
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/attr.c b/attr.c
index 90dbacd..ec878c3 100644
--- a/attr.c
+++ b/attr.c
@@ -59,23 +59,38 @@ static unsigned hash_name(const char *name, int namelen)
return val;
}
-static int invalid_attr_name(const char *name, int namelen)
+static int attr_name_valid(const char *name, size_t namelen)
{
/*
* Attribute name cannot begin with '-' and must consist of
* characters from [-A-Za-z0-9_.].
*/
if (namelen <= 0 || *name == '-')
- return -1;
+ return 0;
while (namelen--) {
char ch = *name++;
if (! (ch == '-' || ch == '.' || ch == '_' ||
('0' <= ch && ch <= '9') ||
('a' <= ch && ch <= 'z') ||
('A' <= ch && ch <= 'Z')) )
- return -1;
+ return 0;
}
- return 0;
+ return 1;
+}
+
+void invalid_attr_name_message(struct strbuf *err, const char *name, int len)
+{
+ strbuf_addf(err, _("%.*s is not a valid attribute name"),
+ len, name);
+}
+
+static void report_invalid_attr(const char *name, size_t len,
+ const char *src, int lineno)
+{
+ struct strbuf err = STRBUF_INIT;
+ invalid_attr_name_message(&err, name, len);
+ fprintf(stderr, "%s: %s:%d\n", err.buf, src, lineno);
+ strbuf_release(&err);
}
struct git_attr *git_attr_counted(const char *name, size_t len)
@@ -90,7 +105,7 @@ struct git_attr *git_attr_counted(const char *name, size_t len)
return a;
}
- if (invalid_attr_name(name, len))
+ if (!attr_name_valid(name, len))
return NULL;
FLEX_ALLOC_MEM(a, name, name, len);
@@ -176,17 +191,15 @@ static const char *parse_attr(const char *src, int lineno, const char *cp,
cp++;
len--;
}
- if (invalid_attr_name(cp, len)) {
- fprintf(stderr,
- "%.*s is not a valid attribute name: %s:%d\n",
- len, cp, src, lineno);
+ if (!attr_name_valid(cp, len)) {
+ report_invalid_attr(cp, len, src, lineno);
return NULL;
}
} else {
/*
* As this function is always called twice, once with
* e == NULL in the first pass and then e != NULL in
- * the second pass, no need for invalid_attr_name()
+ * the second pass, no need for attr_name_valid()
* check here.
*/
if (*cp == '-' || *cp == '!') {
@@ -229,10 +242,8 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
name += strlen(ATTRIBUTE_MACRO_PREFIX);
name += strspn(name, blank);
namelen = strcspn(name, blank);
- if (invalid_attr_name(name, namelen)) {
- fprintf(stderr,
- "%.*s is not a valid attribute name: %s:%d\n",
- namelen, name, src, lineno);
+ if (!attr_name_valid(name, namelen)) {
+ report_invalid_attr(name, namelen, src, lineno);
goto fail_return;
}
}
diff --git a/attr.h b/attr.h
index bcedf92..d39e327 100644
--- a/attr.h
+++ b/attr.h
@@ -13,6 +13,8 @@ extern struct git_attr *git_attr(const char *);
/* The same, but with counted string */
extern struct git_attr *git_attr_counted(const char *, size_t);
+extern void invalid_attr_name_message(struct strbuf *, const char *, int);
+
/* Internal use */
extern const char git_attr__true[];
extern const char git_attr__false[];
--
2.10.1.508.g6572022
^ permalink raw reply related
* Re: [PATCH 0/2] git-svn: implement "git worktree" awareness
From: Junio C Hamano @ 2016-10-26 21:17 UTC (permalink / raw)
To: Eric Wong
Cc: Jakub Narębski, git, Mathieu Arnold,
Nguyễn Thái Ngọc Duy, Stefan Beller
In-Reply-To: <20161026200248.GA28105@starla>
Eric Wong <e@80x24.org> writes:
> Eric Wong <e@80x24.org> wrote:
>> +Cc Jakub since gitweb could probably take advantage of get_record
>> from the first patch, too. I'm not completely sure about the API
>> for this, though.
>
> Jakub: ping?
>
> +Cc: Junio, too. I'm hoping to have this in 2.11.
I somehow was hoping that I can pull this as part of git-svn updates
for the upcoming release without having to even think about it (I
did read the patch when they were posted and did not find anything
wrong with them, fwiw).
>> The following changes since commit 3cdd5d19178a54d2e51b5098d43b57571241d0ab:
>>
>> Sync with maint (2016-10-11 14:55:48 -0700)
>>
>> are available in the git repository at:
>>
>> git://bogomips.org/git-svn.git svn-wt
>>
>> for you to fetch changes up to 112423eb905cf28c9445781a7647ba590d597ab3:
>>
>> git-svn: "git worktree" awareness (2016-10-14 01:36:12 +0000)
Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Junio C Hamano @ 2016-10-26 21:15 UTC (permalink / raw)
To: Jeff King; +Cc: git, Lars Schneider, Eric Wong, Johannes Schindelin
In-Reply-To: <20161026201721.2pw4slsuyhxhcwxj@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote:
>
>> > I actually wonder if it is worth carrying around the O_NOATIME hack at
>> > all.
>>
>> Yes, I share the thought. We no longer have too many loose objects
>> to matter.
>>
>> I do not mind flipping the order, but I'd prefer to cook the result
>> even longer. I am tempted to suggest we take two step route:
>>
>> - ship 2.11 with the "atime has been there and we won't regress it"
>> shape, while cooking the "cloexec is semantically more
>> important" version in 'next' during the feature freeze
>>
>> - immediately after 2.11 merge it to 'master' for 2.12 to make sure
>> there is no fallout.
>
> That sounds reasonable, though I'd consider jumping straight to "NOATIME
> is not worth it; drop it" as the patch for post-2.11.
That endgame is fine by me too. Thanks for a sanity-check.
^ permalink raw reply
* Re: git-archive and submodules
From: Stefan Beller @ 2016-10-26 21:04 UTC (permalink / raw)
To: Anatoly Borodin; +Cc: git@vger.kernel.org
In-Reply-To: <nur45i$e9b$1@blaine.gmane.org>
On Wed, Oct 26, 2016 at 1:37 PM, Anatoly Borodin
<anatoly.borodin@gmail.com> wrote:
> are there plans to add submodules support to git-archive?
plans by whom?
Git is a project with contributors from all over the place. (different
time zones,
people motivated by different means, i.e. we have the hobbiest that
scratches their
itch, we have paid people working on Git because their employer wants
them to work on Git,
there are other people (who like to) use Git in their work environment
and hack on it
in their spare time to make it awesome.)
AFAICT there are currently not a lot of people actively working on
submodule features,
though there is some history, e.g. Jens Lehmann maintains a wiki
specialised on submodules
https://github.com/jlehmann/git-submod-enhancements/wiki
and archive is mentioned there as one of the many "Issues still to be tackled".
Maybe you want to give it a try as you need it? I'd be happy to review any
submodule related code.
How to get started:
* git clone https://github.com/git/git
* Read (at least skim) Documentation/SubmittingPatches)
* Look at builtin/archive.c as a starting point (cmd_archive is called
when you call "git archive ...")
* That leads to archive.c:write_archive, which calls parse_archive_args
There we'd want to add an option there for recursing into submodules.
* See write_archive_entry (still in archive.c) that mentions S_ISGITLINK
Somewhere there you need to add code. :)
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Stefan Beller @ 2016-10-26 20:46 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jeff King, Simon Ruderich, Johannes Schindelin, Junio C Hamano,
git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <6f231a78-5d74-b93f-a644-a4700c9dfbe7@kdbg.org>
On Wed, Oct 26, 2016 at 1:40 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 26.10.2016 um 22:26 schrieb Jeff King:
>>
>> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
>>
>>> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
>>>>
>>>> it is
>>>> very convenient to not have to explicitly initialize mutexes?
>>>
>>>
>>> Not to initialize a mutex is still wrong for pthreads.
>>
>>
>> I think Stefan was being loose with his wording. There would still be an
>> initializer, but it would be a constant (and in the case of pthread
>> emulation on Windows, would just be NULL).
>
>
> And I was loose, too: Not to initialize a mutex with at least
> PTHREAD_MUTEX_INITILIZER (if not pthread_mutex_init) is still wrong.
>
My words were wrong, I meant statically initialized instead of the need to
call a function to initialize a mutex. (For the attribute subsystem, where would
that function go? We use attrs all over the place. My current thinking would
be in git.c to initialize the Big Single Attr Lock. I feel like that
is not very well
maintainable though).
Sorry for the confusion,
Stefan
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Stefan Beller @ 2016-10-26 20:43 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Sixt, Simon Ruderich, Johannes Schindelin,
Junio C Hamano, git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <20161026202652.kz63mxqqjan7swvl@sigill.intra.peff.net>
On Wed, Oct 26, 2016 at 1:26 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
>
>> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
>> > it is
>> > very convenient to not have to explicitly initialize mutexes?
>>
>> Not to initialize a mutex is still wrong for pthreads.
>
> I think Stefan was being loose with his wording. There would still be an
> initializer, but it would be a constant (and in the case of pthread
> emulation on Windows, would just be NULL).
Exactly, so we would do
/* as per the man page of pthread_mutexes: */
pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
int somefunction()
{
pthread_mutex_lock(&mymutex); /* threadsafely initialised on first use */
...
pthread_unlock(&mymutex);
}
and for the Windows compat we'd do
#define PTHREAD_MUTEX_INITIALIZER NULL
#define pthread_mutex_lock emulate_pthread_mutex_lock
int emulate_pthread_mutex_lock(volatile MUTEX_TYPE *mx)
{
if (*mx == NULL) /* static initializer? */
{ /* this stackoverflow magic to initialize threadsafely if not init'd */}
EnterCriticalSection(mx) /* as it currently is in compat/win32/pthread.h */
return 0;
}
>
> -Peff
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Johannes Sixt @ 2016-10-26 20:40 UTC (permalink / raw)
To: Jeff King
Cc: Stefan Beller, Simon Ruderich, Johannes Schindelin,
Junio C Hamano, git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <20161026202652.kz63mxqqjan7swvl@sigill.intra.peff.net>
Am 26.10.2016 um 22:26 schrieb Jeff King:
> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
>
>> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
>>> it is
>>> very convenient to not have to explicitly initialize mutexes?
>>
>> Not to initialize a mutex is still wrong for pthreads.
>
> I think Stefan was being loose with his wording. There would still be an
> initializer, but it would be a constant (and in the case of pthread
> emulation on Windows, would just be NULL).
And I was loose, too: Not to initialize a mutex with at least
PTHREAD_MUTEX_INITILIZER (if not pthread_mutex_init) is still wrong.
-- Hannes
^ permalink raw reply
* git-archive and submodules
From: Anatoly Borodin @ 2016-10-26 20:37 UTC (permalink / raw)
To: git
Hi All,
are there plans to add submodules support to git-archive?
--
Mit freundlichen Grüßen,
Anatoly Borodin
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Jeff King @ 2016-10-26 20:26 UTC (permalink / raw)
To: Johannes Sixt
Cc: Stefan Beller, Simon Ruderich, Johannes Schindelin,
Junio C Hamano, git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <e1f760f5-27a7-8266-5d6c-d61fab7e194d@kdbg.org>
On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
> > it is
> > very convenient to not have to explicitly initialize mutexes?
>
> Not to initialize a mutex is still wrong for pthreads.
I think Stefan was being loose with his wording. There would still be an
initializer, but it would be a constant (and in the case of pthread
emulation on Windows, would just be NULL).
-Peff
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Johannes Sixt @ 2016-10-26 20:25 UTC (permalink / raw)
To: Stefan Beller
Cc: Jeff King, Simon Ruderich, Johannes Schindelin, Junio C Hamano,
git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <CAGZ79kYgk9rQDju0MT2uniaxhAWpzJ9f1T9czgNnxfq+Wz6m+A@mail.gmail.com>
Am 26.10.2016 um 21:51 schrieb Stefan Beller:
> it is
> very convenient to not have to explicitly initialize mutexes?
Not to initialize a mutex is still wrong for pthreads.
-- Hannes
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Jeff King @ 2016-10-26 20:20 UTC (permalink / raw)
To: Stefan Beller
Cc: Simon Ruderich, Johannes Schindelin, Junio C Hamano,
git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <CAGZ79kYgk9rQDju0MT2uniaxhAWpzJ9f1T9czgNnxfq+Wz6m+A@mail.gmail.com>
On Wed, Oct 26, 2016 at 12:51:02PM -0700, Stefan Beller wrote:
> > I seem to recall this does not work on Windows, where the pthread
> > functions are thin wrappers over CRITICAL_SECTION. Other threaded code
> > in git does an explicit setup step before entering threaded sections.
> > E.g., see start_threads() in builtin/grep.c.
> >
>
> I wonder if we can have a similar thing as
> http://stackoverflow.com/a/9490113 in compat/win32/pthread.{h.c} as it is
> very convenient to not have to explicitly initialize mutexes?
I agree it would be much more convenient and get rid of some repetitive
boilerplate code. I'll leave it to Windows folks to decide if they are
OK with that approach or not (I do not offhand know of any reason it
would not work).
-Peff
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Jeff King @ 2016-10-26 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Lars Schneider, Eric Wong, Johannes Schindelin
In-Reply-To: <xmqqpomnatg6.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote:
> > I actually wonder if it is worth carrying around the O_NOATIME hack at
> > all.
>
> Yes, I share the thought. We no longer have too many loose objects
> to matter.
>
> I do not mind flipping the order, but I'd prefer to cook the result
> even longer. I am tempted to suggest we take two step route:
>
> - ship 2.11 with the "atime has been there and we won't regress it"
> shape, while cooking the "cloexec is semantically more
> important" version in 'next' during the feature freeze
>
> - immediately after 2.11 merge it to 'master' for 2.12 to make sure
> there is no fallout.
That sounds reasonable, though I'd consider jumping straight to "NOATIME
is not worth it; drop it" as the patch for post-2.11.
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] git-svn: implement "git worktree" awareness
From: Eric Wong @ 2016-10-26 20:02 UTC (permalink / raw)
To: Jakub Narębski
Cc: git, Mathieu Arnold, Nguyễn Thái Ngọc Duy,
Stefan Beller, Junio C Hamano
In-Reply-To: <20161014014623.15223-1-e@80x24.org>
Eric Wong <e@80x24.org> wrote:
> +Cc Jakub since gitweb could probably take advantage of get_record
> from the first patch, too. I'm not completely sure about the API
> for this, though.
Jakub: ping?
+Cc: Junio, too. I'm hoping to have this in 2.11.
> The following changes since commit 3cdd5d19178a54d2e51b5098d43b57571241d0ab:
>
> Sync with maint (2016-10-11 14:55:48 -0700)
>
> are available in the git repository at:
>
> git://bogomips.org/git-svn.git svn-wt
>
> for you to fetch changes up to 112423eb905cf28c9445781a7647ba590d597ab3:
>
> git-svn: "git worktree" awareness (2016-10-14 01:36:12 +0000)
>
> ----------------------------------------------------------------
> Eric Wong (2):
> git-svn: reduce scope of input record separator change
> git-svn: "git worktree" awareness
>
> git-svn.perl | 13 +++++++------
> perl/Git.pm | 16 +++++++++++++++-
> perl/Git/SVN.pm | 24 +++++++++++++++---------
> perl/Git/SVN/Editor.pm | 12 +++++-------
> perl/Git/SVN/Fetcher.pm | 15 +++++----------
> perl/Git/SVN/Migration.pm | 37 ++++++++++++++++++++++---------------
> 6 files changed, 69 insertions(+), 48 deletions(-)
^ permalink raw reply
* Re: [PATCH 27/36] attr: convert to new threadsafe API
From: Stefan Beller @ 2016-10-26 19:51 UTC (permalink / raw)
To: Jeff King
Cc: Simon Ruderich, Johannes Schindelin, Junio C Hamano,
git@vger.kernel.org, Brandon Williams, Duy Nguyen
In-Reply-To: <20161026121525.twgiavpgfbr2ahvn@sigill.intra.peff.net>
On Wed, Oct 26, 2016 at 5:15 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 26, 2016 at 11:35:58AM +0200, Simon Ruderich wrote:
>
>> > static pthread_mutex_t attr_mutex;
>> > -#define attr_lock()pthread_mutex_lock(&attr_mutex)
>> > +static inline void attr_lock(void)
>> > +{
>> > + static int initialized;
>> > +
>> > + if (!initialized) {
>> > + pthread_mutex_init(&attr_mutex, NULL);
>> > + initialized = 1;
>> > + }
>> > + pthread_mutex_lock(&attr_mutex);
>> > +}
>>
>> This may initialize the mutex multiple times during the first
>> lock (which may happen in parallel).
>>
>> pthread provides static initializers. To quote the man page:
>>
>> Variables of type pthread_mutex_t can also be initialized
>> statically, using the constants PTHREAD_MUTEX_INITIALIZER
>> (for fast mutexes), PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
>> (for recursive mutexes), and
>> PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (for error checking
>> mutexes).
>
> I seem to recall this does not work on Windows, where the pthread
> functions are thin wrappers over CRITICAL_SECTION. Other threaded code
> in git does an explicit setup step before entering threaded sections.
> E.g., see start_threads() in builtin/grep.c.
>
I wonder if we can have a similar thing as
http://stackoverflow.com/a/9490113 in compat/win32/pthread.{h.c} as it is
very convenient to not have to explicitly initialize mutexes?
^ permalink raw reply
* Re: A bug with "git svn show-externals"
From: Eric Wong @ 2016-10-26 19:10 UTC (permalink / raw)
To: Tao Peng; +Cc: git, Vineet Kumar
In-Reply-To: <B8D25850-A4DE-435C-A856-240D612D59DA@me.com>
Tao Peng <pengtao@me.com> wrote:
> Hi there,
>
> I met a bug of the "git svn show-externals” command. If a subdirectory item has a svn:externals property, and the format of the property is “URL first, then the local path”, running "git svn show-externals” command at the root level will result in an unusable output.
>
> Example:
> $ svn pg svn:externals svn+ssh://src.foo.com/svn/ref/English.lproj/
> svn+ssh://src.foo.com/svn/orig/trunk/Resources/English.lproj/Localizable.strings Localizable.strings
+Cc Vineet who originally implemented this 9 years ago
I've never used externals much, but I guess it's common for
externals to be a full URL and not merely a relative path
to somewhere within the same SVN repo.
> $ git svn show-externals
> # /English.lproj/
> /English.lproj/svn+ssh://src.foo.com/svn/orig/trunk/Resources/English.lproj/Localizable.strings Localizable.strings
>
> This bug is preventing my script from correctly finishing the svn-to-git repo migration work. Does anyone know a workaround to this bug?
Can you try the following change to ignore path prefixing for
full URLs?
diff --git a/git-svn.perl b/git-svn.perl
index 4d41d22..ced665a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1303,7 +1303,9 @@ sub cmd_show_externals {
my $s = $props->{'svn:externals'} or return;
$s =~ s/[\r\n]+/\n/g;
chomp $s;
- $s =~ s#^#$path#gm;
+ if ($s !~ m#^[a-z\+]+://#i) {
+ $s =~ s#^#$path#gm;
+ }
print STDOUT "$s\n";
});
}
^ permalink raw reply related
* Re: [PATCH] Documentation/git-diff: document git diff with 3+ commits
From: Junio C Hamano @ 2016-10-26 18:11 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jacob Keller
In-Reply-To: <07712c2c94670ca4d91ef78cd7d3602a8d36b0c1.1477472970.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> That one is difficult to discover but super useful, so document it:
> Specifying 3 or more commits makes git diff switch to combined diff.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>
> Notes:
> Note that we have the following now:
> ...
> 'git diff A..B' equivalent to 'git diff A B'
> in contrast to 'git log A..B' listing commits between M and B only
> (without the commits between M and A unless they are "in" B).
The standard answer is:
Do not use two-dot form with 'git diff', if you find it
confusing. Diff is about two endpoints, not about a range
between two.
The reason why we do not reject can be easily guessed by any
intelligent person when some historical background is given, I
think.
- In the beginning A...B did not exist. A..B was the only "range"
notation.
- "git log A..B" was in wide use. Remember, "git log A...B" did
not exist.
- People started mistyping "git diff A..B", which looked as if the
user typed "git diff ^A B" to the internal.
- Git _could_ have rejected that as a bogus request to diff two
points, ^A (what is that???) and B, but "What else could the user
have meant with 'git diff A..B' other than 'git diff A B'?" was
an argument to favor doing _something_ useful rather than
erroring out. Remember, "A...B" did not exist when this
happened.
So there. We may want to deprecate "diff A..B" but I personally do
not think it is worth the effort. There is no substitute for the
current "diff A...B" to allow us to deprecate both at the same time,
which is the required first step if we want to eventually swap their
meaning in a far future version of Git which would have been better
if we had hindsight. But remember, "A...B" did not exist back then.
> diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
> index bbab35fcaf..2047318a27 100644
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -12,6 +12,7 @@ SYNOPSIS
> 'git diff' [options] [<commit>] [--] [<path>...]
> 'git diff' [options] --cached [<commit>] [--] [<path>...]
> 'git diff' [options] <commit> <commit> [--] [<path>...]
> +'git diff' [options] <commit> <commit> <commit> [<commit>...]
Made me wonder "is [<A>...] 0-or-more As or 1-or-more As?".
Don't we allow pathspecs in this case?
> 'git diff' [options] <blob> <blob>
> 'git diff' [options] [--no-index] [--] <path> <path>
>
> @@ -75,9 +76,16 @@ two blob objects, or changes between two files on disk.
> "git diff $(git-merge-base A B) B". You can omit any one
> of <commit>, which has the same effect as using HEAD instead.
>
> +'git diff' [options] <commit> <commit> <commit> [<commit>...]::
> +
> + This is to view a combined diff between the first <commit>
> + and the remaining ones, just like viewing a combined diff
> + for a merge commit (see below) where the first <commit>
> + is the merge commit and the remaining ones are the parents.
> +
> Just in case if you are doing something exotic, it should be
> noted that all of the <commit> in the above description, except
> -in the last two forms that use ".." notations, can be any
> +in the two forms that use ".." notations, can be any
> <tree>.
>
> For a more complete list of ways to spell <commit>, see
^ permalink raw reply
* Re: [PATCH] hex: use unsigned index for ring buffer
From: Junio C Hamano @ 2016-10-26 17:53 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, Git List
In-Reply-To: <3c95a89a-2a9b-2856-42a1-6b994f2e31cd@web.de>
René Scharfe <l.s.r@web.de> writes:
> Actually I didn't sign-off on purpose originally. But OK, let's keep
> the version below. I just feel strangely sad seeing that concise magic
> go. Nevermind.
I actually share the sadness, too, but let's be stupid and obvious
here.
Thanks.
>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>
>> -- >8 --
>> From: René Scharfe <l.s.r@web.de>
>> Date: Sun, 23 Oct 2016 19:57:30 +0200
>> Subject: [PATCH] hex: make wraparound of the index into ring-buffer explicit
>>
>> Overflow is defined for unsigned integers, but not for signed ones.
>>
>> We could make the ring-buffer index in sha1_to_hex() and
>> get_pathname() unsigned to be on the safe side to resolve this, but
>> let's make it explicit that we are wrapping around at whatever the
>> number of elements the ring-buffer has. The compiler is smart enough
>> to turn modulus into bitmask for these codepaths that use
>> ring-buffers of a size that is a power of 2.
>>
>> Signed-off-by: René Scharfe <l.s.r@web.de>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>> hex.c | 3 ++-
>> path.c | 3 ++-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/hex.c b/hex.c
>> index ab2610e498..845b01a874 100644
>> --- a/hex.c
>> +++ b/hex.c
>> @@ -78,7 +78,8 @@ char *sha1_to_hex(const unsigned char *sha1)
>> {
>> static int bufno;
>> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
>> - return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
>> + bufno = (bufno + 1) % ARRAY_SIZE(hexbuffer);
>> + return sha1_to_hex_r(hexbuffer[bufno], sha1);
>> }
>>
>> char *oid_to_hex(const struct object_id *oid)
>> diff --git a/path.c b/path.c
>> index fe3c4d96c6..9bfaeda207 100644
>> --- a/path.c
>> +++ b/path.c
>> @@ -24,7 +24,8 @@ static struct strbuf *get_pathname(void)
>> STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
>> };
>> static int index;
>> - struct strbuf *sb = &pathname_array[3 & ++index];
>> + struct strbuf *sb = &pathname_array[index];
>> + index = (index + 1) % ARRAY_SIZE(pathname_array);
>> strbuf_reset(sb);
>> return sb;
>> }
>>
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Junio C Hamano @ 2016-10-26 17:52 UTC (permalink / raw)
To: Jeff King; +Cc: git, Lars Schneider, Eric Wong, Johannes Schindelin
In-Reply-To: <20161026164746.2fu57f4pji5qdtnh@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Of the two flags, I would say CLOEXEC is the more important one to
> respect because it may actually impact correctness (e.g., leaking
> descriptors to sub-processes). Whereas O_NOATIME is purely a performance
> optimization.
I tend to agree.
> I actually wonder if it is worth carrying around the O_NOATIME hack at
> all.
Yes, I share the thought. We no longer have too many loose objects
to matter.
I do not mind flipping the order, but I'd prefer to cook the result
even longer. I am tempted to suggest we take two step route:
- ship 2.11 with the "atime has been there and we won't regress it"
shape, while cooking the "cloexec is semantically more
important" version in 'next' during the feature freeze
- immediately after 2.11 merge it to 'master' for 2.12 to make sure
there is no fallout.
^ permalink raw reply
* Re: [PATCH] hex: use unsigned index for ring buffer
From: René Scharfe @ 2016-10-26 17:08 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Git List
In-Reply-To: <xmqqd1ios2p3.fsf@gitster.mtv.corp.google.com>
Am 25.10.2016 um 20:28 schrieb Junio C Hamano:
> Jeff King <peff@peff.net> writes:
>
>> On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote:
>>
>>>> So how about this? It gets rid of magic number 3 and works for array
>>>> size that's not a power of two. And as a nice side effect it can't
>>>> trigger a signed overflow anymore.
>>>
>>> Looks good to me. Peff?
>>
>> Any of the variants discussed in this thread is fine by me.
>
> OK, here is what I'll queue then.
> I assumed that René wants to sign it off ;-).
Actually I didn't sign-off on purpose originally. But OK, let's keep
the version below. I just feel strangely sad seeing that concise magic
go. Nevermind.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
> -- >8 --
> From: René Scharfe <l.s.r@web.de>
> Date: Sun, 23 Oct 2016 19:57:30 +0200
> Subject: [PATCH] hex: make wraparound of the index into ring-buffer explicit
>
> Overflow is defined for unsigned integers, but not for signed ones.
>
> We could make the ring-buffer index in sha1_to_hex() and
> get_pathname() unsigned to be on the safe side to resolve this, but
> let's make it explicit that we are wrapping around at whatever the
> number of elements the ring-buffer has. The compiler is smart enough
> to turn modulus into bitmask for these codepaths that use
> ring-buffers of a size that is a power of 2.
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> hex.c | 3 ++-
> path.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hex.c b/hex.c
> index ab2610e498..845b01a874 100644
> --- a/hex.c
> +++ b/hex.c
> @@ -78,7 +78,8 @@ char *sha1_to_hex(const unsigned char *sha1)
> {
> static int bufno;
> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
> - return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
> + bufno = (bufno + 1) % ARRAY_SIZE(hexbuffer);
> + return sha1_to_hex_r(hexbuffer[bufno], sha1);
> }
>
> char *oid_to_hex(const struct object_id *oid)
> diff --git a/path.c b/path.c
> index fe3c4d96c6..9bfaeda207 100644
> --- a/path.c
> +++ b/path.c
> @@ -24,7 +24,8 @@ static struct strbuf *get_pathname(void)
> STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
> };
> static int index;
> - struct strbuf *sb = &pathname_array[3 & ++index];
> + struct strbuf *sb = &pathname_array[index];
> + index = (index + 1) % ARRAY_SIZE(pathname_array);
> strbuf_reset(sb);
> return sb;
> }
>
^ permalink raw reply
* Re: [PATCH] reset: --unmerge
From: Junio C Hamano @ 2016-10-26 17:06 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8Dn7m2axEFkkQtnZMs2yzFwivAJyZCWxODg-HQ=qLnVMA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> Interestingly the thread/bug that resulted in that commit started with
> "report this bug to git" [2]. Something about git-stash. I quote the
> original mail here in case anyone wants to look into it (not sure if
> it's actually reported here before, I don't pay much attention to
> git-stash mails)
>
> -- 8< --
> Bad news, everyone!
>
> When a stash contains changes for several files, and "stash pop"
> encounters conflicts only in some of them, the rest of the files are
> stages automatically.
It indeed is curious.
That is the designed behaviour for _ANY_ mergy operation, and not
limited to "stash pop".
A clean application is added to the index so that you can find out
about them from "diff --cached", while conflicted ones keep their
unmerged stages so that the conflict can be resolved in the working
tree files. There is no bad news here.
Once you resolve the conflict, you would add the final contents to
the working tree, but as anybody who knows how "git diff" after
resolving conflicts in the working tree files is useful would know,
"saving the editor buffer after removing conflict markers" is not a
valid signal that the user is confident that the contents is final.
> At least, that happens with Git 2.1.0 on my machine, and some
> commenters here: http://stackoverflow.com/a/1237337/615245
>
> So then when we unstage the files which had conflicts after resolving
> those, the result is mixed. Which doesn't look right.
Whoever wrote this does not understand how mergy operations in Git
works, I guess.
> What shall we do? Unstage the automatically-staged files? Revert the
> changes from this bug? It seems Git really wants the changes staged
> after the conflict resolution.
The first order of business is to learn how mergy operations in Git
is designed to work, and if they are in the business of building a
tool around Git to make the life of users better, avoid going against
the designed workflow.
If this "Bad news, everyone!" is why vc-git-resolve-conflicts was
added and defaults to true, I can feel safe in toggling it off
forever in my ~/.emacs, knowing that it is a totally broken option
that came from a desire to fix a problem that does not exist.
^ permalink raw reply
* Re: [PATCH] rebase: add --forget to cleanup rebase, leave HEAD untouched
From: Junio C Hamano @ 2016-10-26 16:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20161026094658.20704-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> There are occasions when you decide to abort an in-progress rebase and
> move on to do something else but you forget to do "git rebase --abort"
> first. Or the rebase has been in progress for so long you forgot about
> it. By the time you realize that (e.g. by starting another rebase)
> it's already too late to retrace your steps. The solution is normally
>
> rm -r .git/<some rebase dir>
>
> and continue with your life. But there could be two different
> directories for <some rebase dir> (and it obviously requires some
> knowledge of how rebase works), and the ".git" part could be much
> longer if you are not at top-dir, or in a linked worktree. And
> "rm -r" is very dangerous to do in .git, a mistake in there could
> destroy object database or other important data.
>
> Provide "git rebase --forget" for this exact use case.
Two and a half comments.
- The title says "leave HEAD untouched". Are my working tree files
and my index also safe from this operation, or is HEAD the only
thing that is protected?
- I think I saw a variant of this gotcha for an unconcluded
cherry-pick that was left behind, which the bash-prompt script
did not notice but the next "git cherry-pick" did by complaining
"you are in the middle" or something like that. Perhaps we would
want to have a similarly sounding option to help that case, too,
not in this patch but as another patch on the same theme?
- Would it have helped if bash-prompt were in use? I am not saying
that this patch becomes unnecessary if you use it; I am trying to
see if it helps its users by reminding them what state they are
in.
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Jeff King @ 2016-10-26 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Lars Schneider, Eric Wong, Johannes Schindelin
In-Reply-To: <xmqqa8drcc5i.fsf@gitster.mtv.corp.google.com>
On Wed, Oct 26, 2016 at 09:23:21AM -0700, Junio C Hamano wrote:
> >> + /* Might the failure be due to O_NOATIME? */
> >> + if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
> >> + sha1_file_open_flag &= ~O_NOATIME;
> >> + continue;
> >> + }
> >
> > We drop O_NOATIME, and end up with an empty flag field.
> >
> > But we will never have tried just O_CLOEXEC, which might have worked.
>
> Yes, doing so would smudge atime, so one question is which one
> between noatime or cloexec is more important to be done at open(2)
> time.
Yes, but the missing case is one where we know that O_NOATIME does not
work (but O_CLOEXEC does), so we know we have to smudge the atime.
Of the two flags, I would say CLOEXEC is the more important one to
respect because it may actually impact correctness (e.g., leaking
descriptors to sub-processes). Whereas O_NOATIME is purely a performance
optimization.
I actually wonder if it is worth carrying around the O_NOATIME hack at
all. Linus added it on 2005-04-23 via 144bde78e9; the aim was to reduce
the cost of opening loose object files. Some things have changed since
then:
1. In June 2005, git learned about packfiles, which means we would do
a lot fewer atime updates (rather than one per object access, we'd
generally get one per packfile).
2. In late 2006, Linux learned about "relatime", which is generally
the default on modern installs. So performance around atime updates
is a non-issue there these days.
All the world isn't Linux, of course, but I can't help that feel
that atime performance hackery is something that belongs at the
system level, not in individual applications.
So I don't have hard numbers, but I'd be surprised if O_NOATIME is
really buying us anything these days.
-Peff
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Junio C Hamano @ 2016-10-26 16:23 UTC (permalink / raw)
To: Jeff King; +Cc: git, Lars Schneider, Eric Wong, Johannes Schindelin
In-Reply-To: <20161026042555.neaxvnmggtcku5cc@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> + /* Try again w/o O_CLOEXEC: the kernel might not support it */
>> + if ((sha1_file_open_flag & O_CLOEXEC) && errno == EINVAL) {
>> + sha1_file_open_flag &= ~O_CLOEXEC;
>> continue;
>> }
>
> So if we start with O_CLOEXEC|O_NOATIME, we drop CLOEXEC here and try
> again with just O_NOATIME. And then if _that_ fails...
>
>> + /* Might the failure be due to O_NOATIME? */
>> + if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
>> + sha1_file_open_flag &= ~O_NOATIME;
>> + continue;
>> + }
>
> We drop O_NOATIME, and end up with an empty flag field.
>
> But we will never have tried just O_CLOEXEC, which might have worked.
Yes, doing so would smudge atime, so one question is which one
between noatime or cloexec is more important to be done at open(2)
time.
It may be possible to open(2) only with cloexec and then fcntl(2)
FD_SET noatime immediately after, but going that way would explode
the combination even more, as it may not be possible to set these
two flags the other way around.
> I'm not sure it's worth worrying about or not; I don't know which
> systems are actually lacking either of the flags, or if they tend to
> have both.
^ permalink raw reply
* Re: [PATCH v1 00/19] Add configuration options for split-index
From: Junio C Hamano @ 2016-10-26 16:14 UTC (permalink / raw)
To: Duy Nguyen
Cc: Christian Couder, Git Mailing List,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8Ba0BY=pZwrKf5rcD5AaZ3YyKh9=ENKkj7hHpTqh00OnA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Even if we ignore user index files (by forcing them all to be stored
> in one piece), there is a problem with the special temporary file
> index.lock, which must use split-index because it will become the new
> index. Handling race conditions could be tricky with ref counting.
> Timestamps help in this regard.
I actually think using the split-index only for the $GIT_DIR/index,
the primary one, and using the full index for others is a bad idea,
as we use temporary index ourselves when making partial commits,
which happens quite often.
So time-based GC it is.
I actually do not think index.lock is a problem, but is a solution,
if we only limit the split-index to the primary one (we can have at
most one, so we can GC the stale shared ones while holding the
lock).
But that is no longer important.
^ permalink raw reply
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
From: Junio C Hamano @ 2016-10-26 16:08 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jeff King, Johannes Schindelin, Johannes Sixt, Git Mailing List
In-Reply-To: <CACsJy8DUqrsaqmrCHzzuS3Q7DXRAPkisOJbSmYPX8-AhmNUz6w@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> I don't object the alias.<name>.<property> approach though. It's
> definitely a cleaner one in my opinion. It just needs people who can
> spend time to follow up until the end. But if someone decides to do
> that now, I'll drop the "(properties)!command" and try to support
> him/her.
I don't object to either approach, but what I would love to see
people avoid is to end up with both.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox