* [PATCH 4/4] i18n: diff: mark warnings for translation
From: Vasco Almeida @ 2016-10-17 13:15 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA
In-Reply-To: <20161017131529.27856-1-vascomalmeida@sapo.pt>
Mark rename_limit_warning and degrade_cc_to_c_warning and
rename_limit_warning for translation.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
diff.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index 1d304e0..1687317 100644
--- a/diff.c
+++ b/diff.c
@@ -4638,25 +4638,25 @@ static int is_summary_empty(const struct diff_queue_struct *q)
}
static const char rename_limit_warning[] =
-"inexact rename detection was skipped due to too many files.";
+N_("inexact rename detection was skipped due to too many files.");
static const char degrade_cc_to_c_warning[] =
-"only found copies from modified paths due to too many files.";
+N_("only found copies from modified paths due to too many files.");
static const char rename_limit_advice[] =
-"you may want to set your %s variable to at least "
-"%d and retry the command.";
+N_("you may want to set your %s variable to at least "
+ "%d and retry the command.");
void diff_warn_rename_limit(const char *varname, int needed, int degraded_cc)
{
if (degraded_cc)
- warning(degrade_cc_to_c_warning);
+ warning(_(degrade_cc_to_c_warning));
else if (needed)
- warning(rename_limit_warning);
+ warning(_(rename_limit_warning));
else
return;
if (0 < needed && needed < 32767)
- warning(rename_limit_advice, varname, needed);
+ warning(_(rename_limit_advice), varname, needed);
}
void diff_flush(struct diff_options *options)
--
2.10.1.459.g5fd885d
^ permalink raw reply related
* Re: Automagic `git checkout branchname` mysteriously fails
From: Duy Nguyen @ 2016-10-17 11:39 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Kevin Daudt, Git
In-Reply-To: <CACPiFCJFXGmsJX97kQuA2h3trVX7L3SacwKrD4mpEU5SPxkLAA@mail.gmail.com>
On Sat, Oct 15, 2016 at 4:06 AM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt <me@ikke.info> wrote:
>> Correct, this only works when it's unambiguous what branch you actually
>> mean.
>
> That's not surprising, but there isn't a warning. IMHO, finding
> several branch matches is a strong indication that it'll be worth
> reporting to the user that the DWIM machinery got hits, but couldn't
> work it out.
>
> I get that process is not geared towards making a friendly msg easy,
> but we could print to stderr something like:
>
> "branch" matches more than one candidate ref, cannot choose automatically.
> If you mean to check out a branch, try git branch command.
> If you mean to check out a file, use -- before the pathname to
> disambiguate.
Or even better, list all ambiguous candidates like Jeff did for
ambiguous short SHA-1 in 1ffa26c (get_short_sha1: list ambiguous
objects on error - 2016-09-26).There were a few occasions I was
confused by ambiguous refs and displaying them all would help me see
what problem was much faster.
--
Duy
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Duy Nguyen @ 2016-10-17 11:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stefan Beller, Lars Schneider, git
In-Reply-To: <alpine.DEB.2.20.1610171241240.197091@virtualbox>
On Mon, Oct 17, 2016 at 5:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Duy,
>
> On Mon, 17 Oct 2016, Duy Nguyen wrote:
>
>> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi Stefan,
>> >
>> > On Sun, 16 Oct 2016, Stefan Beller wrote:
>> >
>> >> Conceptually I would prefer if we had a single switch that indicates a
>> >> case insensitive FS.
>> >
>> > AFAIU Lars' use case is where the FS is *case sensitive*, but he still
>> > needs the .gitattributes to be *case insensitive* because that file
>> > originates from a developer with such a file system.
>> >
>> > Otherwise he would simply tack onto the core.ignoreCase flag.
>>
>> That sounds to me like setting core.ignoreCase to true (on all devs'
>> repo) would "solve" this.
>
> It is good that you quoted this verb, because it does not solve things.
> Instead, it would try to use the flag for two slightly incompatible
> purposes at the same time.
>
> The first (and so far, only) purpose is to tell Git that the current file
> system is case insensitive.
>
> The new purpose you described would be to tell Git that the *user* does
> not care about the file names' case, even if the file system does.
>
> I do not think that this leads to a better situation than before. Instead,
> I am convinced that it will cause new and sometimes "entertaining"
> problems because you can no longer discern between those two purposes
> based on core.ignoreCase, you would have to teach Git to test every single
> time whether the file system is case-sensitive or not.
I agree. Which is why I wrote "we probably want something in the same
spirit but limited to .gitattributes and .gitignore only". In other
words we could have core.someName that makes .gitattributes and
.gitignore patterns case-insensitive (or core-sensitive). If it's
present, it overrides core.ignoreCase. If it's not present,
core.ignoreCase decides. I'm just not sure if the new config should
cover everything involving filename's case in git. That's too big to
fit in my head.
> Needless to say, I'd rather not see that happening. Many users, including
> my colleagues and myself, rely on Git being a rock solid piece of
> software, and that change would make it less so.
--
Duy
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Johannes Schindelin @ 2016-10-17 10:46 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Stefan Beller, Lars Schneider, git
In-Reply-To: <CACsJy8BBLcZvB1FswcEKS1KgvjMjo_uaVqOTgjmMJkjnmoye+w@mail.gmail.com>
Hi Duy,
On Mon, 17 Oct 2016, Duy Nguyen wrote:
> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Stefan,
> >
> > On Sun, 16 Oct 2016, Stefan Beller wrote:
> >
> >> Conceptually I would prefer if we had a single switch that indicates a
> >> case insensitive FS.
> >
> > AFAIU Lars' use case is where the FS is *case sensitive*, but he still
> > needs the .gitattributes to be *case insensitive* because that file
> > originates from a developer with such a file system.
> >
> > Otherwise he would simply tack onto the core.ignoreCase flag.
>
> That sounds to me like setting core.ignoreCase to true (on all devs'
> repo) would "solve" this.
It is good that you quoted this verb, because it does not solve things.
Instead, it would try to use the flag for two slightly incompatible
purposes at the same time.
The first (and so far, only) purpose is to tell Git that the current file
system is case insensitive.
The new purpose you described would be to tell Git that the *user* does
not care about the file names' case, even if the file system does.
I do not think that this leads to a better situation than before. Instead,
I am convinced that it will cause new and sometimes "entertaining"
problems because you can no longer discern between those two purposes
based on core.ignoreCase, you would have to teach Git to test every single
time whether the file system is case-sensitive or not.
Needless to say, I'd rather not see that happening. Many users, including
my colleagues and myself, rely on Git being a rock solid piece of
software, and that change would make it less so.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Jeff King @ 2016-10-17 9:50 UTC (permalink / raw)
To: larsxschneider; +Cc: git, tboegi, gitster
In-Reply-To: <20161017002550.88782-2-larsxschneider@gmail.com>
On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschneider@gmail.com wrote:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
> was deprecated since macOS 10.7.
>
> Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
> macOS. Make it possible to override this and use OpenSSL by defining
> `DARWIN_OPENSSL`.
I like that you gave an override, but I don't think it works in all
cases:
> diff --git a/config.mak.uname b/config.mak.uname
> index b232908..f0c94a9 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -108,6 +108,12 @@ ifeq ($(uname_S),Darwin)
> ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
> HAVE_GETDELIM = YesPlease
> endif
> + ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 15 && echo 1),1)
> + ifndef DARWIN_OPENSSL
> + NO_OPENSSL = YesPlease
> + APPLE_COMMON_CRYPTO=YesPlease
> + endif
> + endif
This is in config.mak.uname, which gets sourced before config.mak (and
ifndef is evaluated at the time of parsing). So it would work to do:
make DARWIN_OPENSSL=Yep
but not:
echo DARWIN_OPENSSL=Yep >>config.mak
make
I think you'd have to set a flag in config.mak.uname, and then resolve
it in the Makefile proper like:
ifdef DARWIN_OPENSSL
# Overrides AUTO_AVOID_OPENSSL, do nothing.
else ifdef AUTO_AVOID_OPENSSL
NO_OPENSSL = YesPlease
APPLE_COMMON_CRYPTO = YesPlease
endif
but that's totally untested.
-Peff
^ permalink raw reply
* Re: Uninitialized submodules as symlinks
From: Duy Nguyen @ 2016-10-17 9:45 UTC (permalink / raw)
To: David Turner; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <f0c11de1bd4d414d8a9464e6ccc1d58a@exmbdft7.ad.twosigma.com>
On Sat, Oct 8, 2016 at 2:59 AM, David Turner <David.Turner@twosigma.com> wrote:
>
>
>> -----Original Message-----
>> From: Stefan Beller [mailto:sbeller@google.com]
>> Sent: Friday, October 07, 2016 2:56 PM
>> To: David Turner
>> Cc: git@vger.kernel.org
>> Subject: Re: Uninitialized submodules as symlinks
>>
>> On Fri, Oct 7, 2016 at 11:17 AM, David Turner <David.Turner@twosigma.com>
>> wrote:
>> > Presently, uninitialized submodules are materialized in the working tree
>> > as empty directories.
>>
>> Right, there has to be something, to hint at the user that creating a file
>> with that path is probably not what they want.
>>
>> > We would like to consider having them be symlinks. Specifically, we'd
>> > like them to be symlinks into a FUSE filesystem which retrieves files on
>> > demand.
>> >
>> > We've actually already got a FUSE filesystem written, but we use a
>> > different (semi-manual) means to connect it to the initialized submodules.
>>
>> So you currently do a
>>
>> git submodule init <pathspec>
>> custom-submodule make-symlink <pathspec>
>>
>> ?
>
> We do something like
>
> For each initialized submodule: symlink it into the right place in .../somedir
> For each uninitialized submodule: symlink from the FUSE into the right place in .../somedir
>
> So .../somedir has the structure of the git main repo, but is all symlinks -- some into FUSE, some into the git repo.
>
> This means that when we initialize (or deinitialize) a submodule, we need to re-run the linking script.
Do .git files work? If .git files point to somewhere in fuse, I guess
you still have file retrieval on demand. It depends on what files to
retrieve I guess. If you want worktree files, not object database then
.git files won't work because worktree remains in the same filesystem
as the super repo.
--
Duy
^ permalink raw reply
* Re: [PATCH] convert: mark a file-local symbol static
From: Jeff King @ 2016-10-17 9:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ramsay Jones, Lars Schneider, Junio C Hamano, GIT Mailing-list
In-Reply-To: <alpine.DEB.2.20.1610171058580.197091@virtualbox>
On Mon, Oct 17, 2016 at 11:04:19AM +0200, Johannes Schindelin wrote:
> > Gross. I would not be opposed to a Makefile rule that outputs the
> > correct set of OBJECTS so this (or other) scripts could build on it.
>
> You could also use the method I use in Git for Windows to "extend" the
> Makefile:
>
> -- snipsnap --
> cat >dummy.mak <<EOF
> include Makefile
>
> blub: $(OBJECTS)
> do-something-with $^
> EOF
>
> make -f dummy.mak blub
Hacky but clever. I like it.
In the particular case of git, I think I've cheated similarly before by
putting things in config.mak, though of course an arbitrary script can't
assume it can overwrite that file.
-Peff
^ permalink raw reply
* Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing
From: Jeff King @ 2016-10-17 9:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Torsten Bögershausen, git, Jakub Narębski,
Johannes Sixt
In-Reply-To: <alpine.DEB.2.20.1610171025470.197091@virtualbox>
[tl;dr: the version in your repo is fine, and there's a trivial fix
below if we want to silence the warning in the meantime]
On Mon, Oct 17, 2016 at 10:37:52AM +0200, Johannes Schindelin wrote:
> > I'm not sure I agree. IIRC, Assigning values outside the range of an enum has
> > always been fishy according to the standard, and a compiler really is
> > allowed to allocate a single bit for storage for this enum.
>
> Really? I did see my share of code that completely violated this freedom,
> by assuming that it was really okay to cast a -1 to an enum and then test
> for that value later, when -1 was not a legal enum value.
I poked around a bit, and it seems we're both half-wrong. C99 says:
6.7.2.2 Enumeration specifiers
[...]
The expression that defines the value of an enumeration constant shall
be an integer constant expression that has a value representable as an
int.
[...]
Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration.
My reading is that it can't be a single-bit bitfield as I claimed, but
it also isn't necessarily interchangeable with an int. But you get at
least a "char", and you can use all of those integer values even if they
aren't explicitly part of the set. And I'd assume that goes for values
even beyond the largest tag as long as you don't need more bits, so
that:
enum { A = 1, B = 2, C = 4 } x = A | B | C;
is OK (though I didn't see anything particularly about that in the
standard).
Assigning "-1" works in the same way that normal "unsigned x = -1" works
(and is defined by the standard), though of course it may unexpectedly
conflict with an actual enum value if the compiler chooses a smaller
type (e.g., it may literally be 255 in many cases).
Anyway. Enough language lawyering. It seems like clang is being overly
strict in its interpretation of the standard (it should be giving us at
least a char's worth of values). But it matters less what the standard
says and more what real compilers do, and we have to deal with clang's
behavior.
> In any case, the fact that even one compiler used to build Git *may*
> violate that standard, and that we therefore need such safety guards as
> the one under discussion, still makes me think that this warning, while
> certainly well-intentioned, is poison for cross-platform projects.
Oh, I agree that the warning is annoying, and the code should not go
away. We just need to figure out how to silence clang.
> > I'm happy to test the TODO_NOOP version against clang (and prepare a
> > patch on top if it still complains), but that doesn't seem to have
> > Junio's tree at all yet.
>
> Junio chose to pick up only one patch series out of the rebase--helper
> thicket at a time, it seems. I did send out at least one revision per
> patch series prior to integrating them into Git for Windows v2.10.0,
> though. Plus, I kept updating the `interactive-rebase` branch in my
> repository on GitHub (https://github.com/dscho/git).
Thanks, I was able to test that branch. It looks like clang is happy
with it because you compare against the max value. Unlike the
ARRAY_SIZE() check, this does mean if somebody modifies the enum without
touching the array, we might go out of bounds. But things would be
severely broken enough from the mismatch that I don't think it's worth
worrying about too much (and I see you have a nice comment warning
people about this).
If the rest of your interactive-rebase branch is coming soon, I think we
can probably ignore it for now. Otherwise something like:
diff --git a/sequencer.c b/sequencer.c
index d662c6b..1fdc35e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -620,7 +620,8 @@ static int allow_empty(struct replay_opts *opts, struct commit *commit)
enum todo_command {
TODO_PICK = 0,
- TODO_REVERT
+ TODO_REVERT,
+ TODO_MAX
};
is probably the simplest portable fix.
As a more clever change, I wondered if switching the enum values from
(0,1) to (1,2) would silence the warning, and indeed it does. Which I
assume is because using bit-flags, we could now represent "1|2", or "3",
which is larger than the array (well, obviously "2" is, but we'd need to
subtract 1 when indexing the array). I don't think that's a good route,
though, because it loses the 0-indexing, the benefits of
zero-initialization, etc. I was mostly just poking at how clang
perceives the enum values.
> P.S.: I cannot wait for the day when somebody with an artistic touch
> provides .css for the public-inbox.org site so it stops threatening
> causing eye cancer to me.
Heh. I gently hinted something similar to Eric in the past, but I think
he actually likes how it looks. He has invited others to mirror
public-inbox and make their own interface, though. I just lack the
"artistic touch" you mentioned.
-Peff
^ permalink raw reply related
* Re: Uninitialized submodules as symlinks
From: Heiko Voigt @ 2016-10-17 9:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Daudt, David Turner, git@vger.kernel.org
In-Reply-To: <xmqqr37izxkf.fsf@gitster.mtv.corp.google.com>
On Fri, Oct 14, 2016 at 09:48:16AM -0700, Junio C Hamano wrote:
> Kevin Daudt <me@ikke.info> writes:
>
> > On Thu, Oct 13, 2016 at 06:10:17PM +0200, Heiko Voigt wrote:
> >> On Fri, Oct 07, 2016 at 06:17:05PM +0000, David Turner wrote:
> >> > Presently, uninitialized submodules are materialized in the working
> >> > tree as empty directories. We would like to consider having them be
> >> > symlinks. Specifically, we'd like them to be symlinks into a FUSE
> >> > filesystem which retrieves files on demand.
> >>
> >> How about portability? This feature would only work on Unix like
> >> operating systems. You have to be careful to not break Windows since
> >> they do not have symlinks.
> >
> > NTFS does have symlinks, but you need admin right to create them though
> > (unless you change the policy).
>
> That sounds like saying "It has, but it practically is not usable by
> Git as a mechanism to achieve this goal" to me.
Yes and that is why Git for Windows does not use them and I simplified
to: "Windows does not have symlinks". For a normal user there is no such
thing as symlinks on Windows, unfortunately.
Cheers Heiko
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Duy Nguyen @ 2016-10-17 9:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stefan Beller, Lars Schneider, git
In-Reply-To: <alpine.DEB.2.20.1610171056170.197091@virtualbox>
On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Stefan,
>
> On Sun, 16 Oct 2016, Stefan Beller wrote:
>
>> Conceptually I would prefer if we had a single switch that indicates a
>> case insensitive FS.
>
> AFAIU Lars' use case is where the FS is *case sensitive*, but he still
> needs the .gitattributes to be *case insensitive* because that file
> originates from a developer with such a file system.
>
> Otherwise he would simply tack onto the core.ignoreCase flag.
That sounds to me like setting core.ignoreCase to true (on all devs'
repo) would "solve" this. Yes core.ignoreCase may introduce some side
effects when used on case-sensitive filesystems, so we probably want
something in the same spirit but limited to .gitattributes and
.gitignore only.
--
Duy
^ permalink raw reply
* Re: [PATCH] convert: mark a file-local symbol static
From: Johannes Schindelin @ 2016-10-17 9:04 UTC (permalink / raw)
To: Jeff King; +Cc: Ramsay Jones, Lars Schneider, Junio C Hamano, GIT Mailing-list
In-Reply-To: <20161017021825.jgpsew7qqfjrirhw@sigill.intra.peff.net>
Hi Ramsay & Peff,
On Sun, 16 Oct 2016, Jeff King wrote:
> On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote:
>
> > Hmm, well, you have to remember that 'make clean' sometimes doesn't
> > make clean. Ever since the Makefile was changed to only remove
> > $(OBJECTS), rather than *.o xdiff/*.o etc., you have to remember to
> > 'make clean' _before_ you switch branches. Otherwise, you risk leaving
> > some objects laying around. Since the script runs 'nm' on all objects
> > it finds, any stale ones can cause problems. (Of course, I almost
> > always forget, so I frequently have to manually check for and remove
> > stale objects!)
>
> Gross. I would not be opposed to a Makefile rule that outputs the
> correct set of OBJECTS so this (or other) scripts could build on it.
You could also use the method I use in Git for Windows to "extend" the
Makefile:
-- snipsnap --
cat >dummy.mak <<EOF
include Makefile
blub: $(OBJECTS)
do-something-with $^
EOF
make -f dummy.mak blub
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Johannes Schindelin @ 2016-10-17 8:57 UTC (permalink / raw)
To: Stefan Beller; +Cc: Lars Schneider, git
In-Reply-To: <CAGZ79kZ6KaQ5gjGiEFQ-pRJCDAyS0oH=_4dK0nCU9hx8wZwdfw@mail.gmail.com>
Hi Stefan,
On Sun, 16 Oct 2016, Stefan Beller wrote:
> Conceptually I would prefer if we had a single switch that indicates a
> case insensitive FS.
AFAIU Lars' use case is where the FS is *case sensitive*, but he still
needs the .gitattributes to be *case insensitive* because that file
originates from a developer with such a file system.
Otherwise he would simply tack onto the core.ignoreCase flag.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Johannes Schindelin @ 2016-10-17 8:55 UTC (permalink / raw)
To: Lars Schneider; +Cc: git
In-Reply-To: <C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com>
Hi Lars,
On Sun, 16 Oct 2016, Lars Schneider wrote:
> One idea could be to add an attribute "case-sensitive" (or
> "caseSensitive") and set it to false (if desired) for all files in
> .gitattributes for a given repo.
>
> ### .gitattributes example ###
>
> * case-sensitive=false
> *.bar something
>
> ###
Hrm. Maybe a better idea would be to warn when attributes match a file
name with a different case?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing
From: Johannes Schindelin @ 2016-10-17 8:37 UTC (permalink / raw)
To: Jeff King
Cc: Torsten Bögershausen, git, Jakub Narębski,
Johannes Sixt
In-Reply-To: <20161016194238.wbge2pas5xr46av7@sigill.intra.peff.net>
Hi Peff,
On Sun, 16 Oct 2016, Jeff King wrote:
> On Sun, Oct 16, 2016 at 10:09:12AM +0200, Johannes Schindelin wrote:
>
> > > Good catch. It technically needs to check the lower bound, too. In
> > > theory, if somebody wanted to add an enum value that is negative, you'd
> > > use a signed cast and check against both 0 and ARRAY_SIZE(). In
> > > practice, that is nonsense for this case, and using an unsigned type
> > > means that any negative values become large, and the check catches them.
> >
> > I am pretty certain that I disagree with that warning: enums have been
> > used as equivalents of ints for a long time, and will be, for a long time
> > to come.
>
> I'm not sure I agree. IIRC, Assigning values outside the range of an enum has
> always been fishy according to the standard, and a compiler really is
> allowed to allocate a single bit for storage for this enum.
Really? I did see my share of code that completely violated this freedom,
by assuming that it was really okay to cast a -1 to an enum and then test
for that value later, when -1 was not a legal enum value.
In any case, the fact that even one compiler used to build Git *may*
violate that standard, and that we therefore need such safety guards as
the one under discussion, still makes me think that this warning, while
certainly well-intentioned, is poison for cross-platform projects.
> > Given that this test is modified to `if (command < TODO_NOOP)` later, I
> > hope that you agree that it is not worth the trouble to appease that
> > compiler overreaction?
>
> I don't mind if there are transient warnings on some compilers in the
> middle of a series, but I'm not sure when "later" is. The tip of "pu"
> has this warning right now when built with clang.
"Later" is the sequencer-i patch series I already sent out for review
[*1*], in particular the patch titled "sequencer (rebase -i):
differentiate between comments and 'noop'" [*2*].
> I'm happy to test the TODO_NOOP version against clang (and prepare a
> patch on top if it still complains), but that doesn't seem to have
> Junio's tree at all yet.
Junio chose to pick up only one patch series out of the rebase--helper
thicket at a time, it seems. I did send out at least one revision per
patch series prior to integrating them into Git for Windows v2.10.0,
though. Plus, I kept updating the `interactive-rebase` branch in my
repository on GitHub (https://github.com/dscho/git).
Ciao,
Dscho
Footnote *1*:
https://public-inbox.org/git/cover.1472633606.git.johannes.schindelin@gmx.de/
Footnote *2*:
https://public-inbox.org/git/736bcb8e860c876e32e8f89f68b0b901abedc187.1472633606.git.johannes.schindelin@gmx.de/t/#u
P.S.: I cannot wait for the day when somebody with an artistic touch
provides .css for the public-inbox.org site so it stops threatening
causing eye cancer to me.
^ permalink raw reply
* Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL
From: Junio C Hamano @ 2016-10-17 7:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stefan Beller, git@vger.kernel.org, Karl A., Dennis Kaarsemaker
In-Reply-To: <alpine.DEB.2.20.1610131255001.197091@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > expecting success:
>> > actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&
>> > test "$actual" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'
>> >
>> > +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.
>> > ++ actual=C:/git-sdk-64/usr/src/git/wip/t/.
>> > ++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'
This may well be total misunderstanding on my side, but is the
expectation of this test even correct? If it wants to take "../."
relative to "$LEAD/t/trash utils/.", should't it go one level up
with ".." to $LEAD/t and then stay there with ".", expecting
"$LEAD/t" which is what the above is giving us?
IOW, the above makes me wonder why having one of these as the base
A - path/to/dir
B - path/to/dir/
C - path/to/dir/.
to resolve the relative "../." give different results. Whether bash
on Windows removes the dot at the end of C to turn it into B, as
long as A and B give us the same result we wouldn't be hitting the
problem, no?
>> > test_submodule_relative_url "(null)" "$PWD/subsuper_update_r" "../subsubsuper_update_r" "$(pwd)/subsubsuper_update_r"
>> > test_submodule_relative_url "(null)" "$PWD/super_update_r2" "../subsuper_update_r" "$(pwd)/subsuper_update_r"
>> > -test_submodule_relative_url "(null)" "$PWD/." "../." "$(pwd)/."
>> > +test_submodule_relative_url "(null)" "$(pwd)/." "../." "$(pwd)/."
>> > The reasons this is ugly: we specifically test for *Unixy* paths when we
>> > use $PWD, as opposed to *Windowsy* paths when using $(pwd).
Just to ensure I am following this correctly, two tests that come
before the one you are touching above have $PWD on the input side
and $(pwd) on the expectation side. That is what you mean by the
next paragraph, right? They want to make sure that you honor the
Unixy user input on Windows and still produce Windowsy result, that
is.
>> > We do this to
>> > ensure a certain level of confidence that running things such as
>> >
>> > git clone --recurse-submodules /z/project/.
>> >
>> > work. And now that does not work anymore.
And I agree from that point of view that having to spell both sides
as $(pwd) would mean you are not testing that "Unixy input to
Windowsy output" expectation, but at the same time, I think you
would want "Windowsy input to Windowsy output" combination also does
produce correct result, which is not tested in the three tests shown
above. IOW, probably you would want to test both (at least on any
platform where $PWD and $(pwd) textually disagree) for all these
[*1*], and the pair
"../." taken relative to "$(pwd)/." must be "$(pwd)/."
"../." taken relative to "$PWD/." must be "$(pwd)/."
test, because of the limitation of your bash, cannot have the latter
half of the pair, so you'd need to comment it out with in-code
explanation, perhaps? IOW something along the lines of...
-- >8 -- snip -- >8 --
test_submodule_relative_url "(null)" "$(pwd)/subsuper_update_r" "../subsubsuper_update_r" "$(pwd)/subsubsuper_update_r"
test_submodule_relative_url "(null)" "$(pwd)/super_update_r2" "../subsuper_update_r" "$(pwd)/subsuper_update_r"
test_submodule_relative_url "(null)" "$(pwd)/." "../." "$(pwd)/."
if test_have_prereq MINGW
then
test_submodule_relative_url "(null)" "$PWD/subsuper_update_r" "../subsubsuper_update_r" "$(pwd)/subsubsuper_update_r"
test_submodule_relative_url "(null)" "$PWD/super_update_r2" "../subsuper_update_r" "$(pwd)/subsuper_update_r"
# This does not work correctly because Win-Bash strips . at the end
# "of $PWD/."
# test_submodule_relative_url "(null)" "$PWD/." "../." "$(pwd)/."
fi
-- >8 -- snip -- >8 --
In any case, I find it more disturbing that we somehow ended up with
a system where these three things are expected to behave differently:
A - path/to/dir
B - path/to/dir/
C - path/to/dir/.
Is that something we can fix?
[Footnote]
*1* It is tempting to update the above test sequence using
a helper like:
tsru () {
test_submodule_relative_url "(null)" "$(pwd)/$1" "$2" "$(pwd)/$3"
if test_have_prereq MINGW
then
test_submodule_relative_url "(null)" "$PWD/$1" "$2" "$(pwd)/$3"
fi
}
then write the above three tests like so:
tsru subsuper_update_r ../subsubsuper_update_r subsubsuper_update_r
tsru super_update_r2 ../subsuper_update_r subsuper_update_r
tsru . ../. .
but you would want to disable the MINGW half for only the third
test, we cannot quite do that.
^ permalink raw reply
* Re: [RFC] Case insensitive Git attributes
From: Torsten Bögershausen @ 2016-10-17 4:24 UTC (permalink / raw)
To: Stefan Beller, Lars Schneider; +Cc: git
In-Reply-To: <CAGZ79kZ6KaQ5gjGiEFQ-pRJCDAyS0oH=_4dK0nCU9hx8wZwdfw@mail.gmail.com>
On 17/10/16 05:07, Stefan Beller wrote:
> On Sun, Oct 16, 2016 at 6:04 PM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
>> Hi,
>>
>> Git attributes for path names are generally case sensitive. However, on
>> a case insensitive file system (e.g. macOS/Windows) they appear to be
>> case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`).
This feels like a bug:
$ git diff
diff --git a/.gitattributes b/.gitattributes
index 5e98806..1419867 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,3 +1,4 @@
* whitespace=!indent,trail,space
*.[ch] whitespace=indent,trail,space
*.sh whitespace=indent,trail,space
+*.C text
-----------
$ git -c core.ignorecase=false check-attr --all git.c
git.c: whitespace: indent,trail,space
#But running on a case insensitve FS I get:
$ git check-attr --all git.c
git.c: text: set
git.c: whitespace: indent,trail,space
>> That
>> works great until a Git users joins the party with a case sensitive file
>> system. For this Git user only files that match the exact case of the
>> attribute pattern get the attributes (only `foo.bar`).
>>
>> This inconsistent behavior can confuse Git users. An advanced Git user
>> could use a glob pattern (e.g. `*.[bB][aA][rR]) to match files in a
>> case insensitive way. However, this can get confusing quickly, too.
>>
>> I wonder if we can do something about this. One idea could be to add an
>> attribute "case-sensitive" (or "caseSensitive") and set it to false
>> (if desired) for all files in .gitattributes for a given repo.
> FYI: I am currently refactoring the attr subsystem (e.g.
> https://public-inbox.org/git/20161012224109.23410-1-sbeller@google.com/
> "attr: convert to new threadsafe API")
>
>> ### .gitattributes example ###
>>
>> * case-sensitive=false
How about
* ignorecase=true
?
> Would this modify the current file only or the whole stack of attrs?
> (In just one way or the whole stack, i.e. can you add this in .git/info/exclude
> and the attribute file in the home dir also behaves differently? Or rather the
> other way round when the system wide attr file enables case insensitivity,
> each repository local config is set automatically? both ways?)
>
>> *.bar something
>>
>> ###
>>
>> I haven't looked into the feasibility of an implementation, yet. However,
>> would that be an acceptable approach?
> Conceptually I would prefer if we had a single switch that indicates a
> case insensitive FS. That could be used for different purposes as well,
> that are FS relevant such as checking in, checking out/renaming files
> in the working tree? (does any such switch already exist for case
> sensitivity?)
>
> Thanks,
> Stefan
>
>> Thanks,
>> Lars
>>
>>
>>
^ permalink raw reply related
* Re: [RFC] Case insensitive Git attributes
From: Stefan Beller @ 2016-10-17 3:07 UTC (permalink / raw)
To: Lars Schneider; +Cc: git
In-Reply-To: <C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com>
On Sun, Oct 16, 2016 at 6:04 PM, Lars Schneider
<larsxschneider@gmail.com> wrote:
> Hi,
>
> Git attributes for path names are generally case sensitive. However, on
> a case insensitive file system (e.g. macOS/Windows) they appear to be
> case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
> works great until a Git users joins the party with a case sensitive file
> system. For this Git user only files that match the exact case of the
> attribute pattern get the attributes (only `foo.bar`).
>
> This inconsistent behavior can confuse Git users. An advanced Git user
> could use a glob pattern (e.g. `*.[bB][aA][rR]) to match files in a
> case insensitive way. However, this can get confusing quickly, too.
>
> I wonder if we can do something about this. One idea could be to add an
> attribute "case-sensitive" (or "caseSensitive") and set it to false
> (if desired) for all files in .gitattributes for a given repo.
FYI: I am currently refactoring the attr subsystem (e.g.
https://public-inbox.org/git/20161012224109.23410-1-sbeller@google.com/
"attr: convert to new threadsafe API")
>
> ### .gitattributes example ###
>
> * case-sensitive=false
Would this modify the current file only or the whole stack of attrs?
(In just one way or the whole stack, i.e. can you add this in .git/info/exclude
and the attribute file in the home dir also behaves differently? Or rather the
other way round when the system wide attr file enables case insensitivity,
each repository local config is set automatically? both ways?)
> *.bar something
>
> ###
>
> I haven't looked into the feasibility of an implementation, yet. However,
> would that be an acceptable approach?
Conceptually I would prefer if we had a single switch that indicates a
case insensitive FS. That could be used for different purposes as well,
that are FS relevant such as checking in, checking out/renaming files
in the working tree? (does any such switch already exist for case
sensitivity?)
Thanks,
Stefan
>
> Thanks,
> Lars
>
>
>
^ permalink raw reply
* Re: [PATCH] convert: mark a file-local symbol static
From: Jeff King @ 2016-10-17 2:18 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Lars Schneider, Junio C Hamano, GIT Mailing-list
In-Reply-To: <5a9a1c44-8a3f-1894-c4c5-8f1fa96b63b9@ramsayjones.plus.com>
On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote:
> Hmm, well, you have to remember that 'make clean' sometimes
> doesn't make clean. Ever since the Makefile was changed to only
> remove $(OBJECTS), rather than *.o xdiff/*.o etc., you have to
> remember to 'make clean' _before_ you switch branches. Otherwise,
> you risk leaving some objects laying around. Since the script
> runs 'nm' on all objects it finds, any stale ones can cause problems.
> (Of course, I almost always forget, so I frequently have to manually
> check for and remove stale objects!)
Gross. I would not be opposed to a Makefile rule that outputs the
correct set of OBJECTS so this (or other) scripts could build on it.
IIRC, BSD make has an option to do this "make -V OBJECTS" or something,
but I don't thnk there's an easy way to do so.
Or, since it seems to find useful results quite frequently, maybe it
would be worth including the script inside git (and triggering it with
an optional Makefile rule). It sounds like we'd need a way to annotate
known false positives, but if it were in common use, it would be easier
to get people to keep that list up to date.
-Peff
^ permalink raw reply
* Re: [PATCH] convert: mark a file-local symbol static
From: Ramsay Jones @ 2016-10-17 1:37 UTC (permalink / raw)
To: Lars Schneider; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <B7662EA0-3181-413E-A40B-69C88FC46F96@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4128 bytes --]
On 16/10/16 01:15, Lars Schneider wrote:
>> On 15 Oct 2016, at 14:01, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:
>> On 15/10/16 16:05, Lars Schneider wrote:
>>>> On 11 Oct 2016, at 16:46, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:
>> [snip]
>>>> -void stop_multi_file_filter(struct child_process *process)
>>>> +static void stop_multi_file_filter(struct child_process *process)
>>>
>>> Done! Do you have some kind of script to detect these things
>>> automatically or do you read the code that carefully?
>>
>> Heh, I'm _far_ too lazy to read the code that carefully. :-D
>>
>> A combination of 'make sparse' and a perl script (originally
>> posted to the list by Junio) find all of these for me.
>
> Interesting. Do you have a link to this script?
I'm attaching _a_ version of the script (you would think that
I would have it under version control; but no, I copy versions
around the several machines/git.git repos I have ... :-P ).
> Does it generate false positives?
Hmm, well, you have to remember that 'make clean' sometimes
doesn't make clean. Ever since the Makefile was changed to only
remove $(OBJECTS), rather than *.o xdiff/*.o etc., you have to
remember to 'make clean' _before_ you switch branches. Otherwise,
you risk leaving some objects laying around. Since the script
runs 'nm' on all objects it finds, any stale ones can cause problems.
(Of course, I almost always forget, so I frequently have to manually
check for and remove stale objects!)
Also, you have to interpret the results of the script. Just because
it shows you an unused external, that doesn't make it an error.
The way I use it, BTW, is to run it on a freshly built branch (saving
to a file) and then compare the files from master->next->pu.
I don't bother looking at the output on master (the 'stop list' in
the script is _way_ out of date), just the diffs master->next and
next->pu.
The current next->pu diff looks like:
$ diff nsc psc
0a1,2
> attr.o - attr_name_valid
> attr.o - invalid_attr_name_message
17a20
> convert.o - stop_multi_file_filter
34d36
< quote.o - sq_quotef
43a46
> sequencer.o - append_new_todo
50a54
> trailer.o - conf_head
55a60,61
> wt-status.o - has_uncommitted_changes
> wt-status.o - has_unstaged_changes
$
I have already sent mails about 'stop_multi_file_filter',
'append_new_todo' and 'conf_head'. The symbols in attr.o are
part of the revamp of the attribute system that Junio and Stefan
are working on, which is very much in flux. If they are still
there when it looks to have firmed up, then I will take a look.
The 'sq_quotef' symbol is an example of a useful function that was
written without having an immediate user (actually, if memory serves
correctly, it was originally used in the series which introduced it,
but later modifications removed the caller). It now has a user. The wt-status.o symbols have been introduced by Johannes in his 'rebase -i'
series (of series) and I am assuming that these symbols will find
additional external callers in up-coming series.
> Maybe I can add `make sparse` to the TravisCI build?
I don't know how feasible that would be. Apparently, the version of
sparse in most distribution repositories is so old that it spews so
many spurious errors as to make it unusable. See, for example:
https://public-inbox.org/git/56CA5753.9030308@ramsayjones.plus.com/
So, you would need to build from source to get a usable version (I am
currently running a version built with some local patches). If you were
to build from the sparse repo's master branch, then it would work great
on Linux, at least. I have no idea if it would work on mac OS X.
However, even then, a single sparse warning is issued on Linux (for
the master branch, several others on pu):
SP pack-revindex.c
pack-revindex.c:65:23: warning: memset with byte count of 262144
This is a problem with sparse (the byte count limit used is hardcoded
into sparse), but I haven't sent a patch upstream to fix it yet.
(I've been looking at that warning for _many_ years, so don't hold
your breath!)
ATB,
Ramsay Jones
[-- Attachment #2: static-check.pl --]
[-- Type: application/x-perl, Size: 1333 bytes --]
^ permalink raw reply
* [RFC] Case insensitive Git attributes
From: Lars Schneider @ 2016-10-17 1:04 UTC (permalink / raw)
To: git
Hi,
Git attributes for path names are generally case sensitive. However, on
a case insensitive file system (e.g. macOS/Windows) they appear to be
case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
works great until a Git users joins the party with a case sensitive file
system. For this Git user only files that match the exact case of the
attribute pattern get the attributes (only `foo.bar`).
This inconsistent behavior can confuse Git users. An advanced Git user
could use a glob pattern (e.g. `*.[bB][aA][rR]) to match files in a
case insensitive way. However, this can get confusing quickly, too.
I wonder if we can do something about this. One idea could be to add an
attribute "case-sensitive" (or "caseSensitive") and set it to false
(if desired) for all files in .gitattributes for a given repo.
### .gitattributes example ###
* case-sensitive=false
*.bar something
###
I haven't looked into the feasibility of an implementation, yet. However,
would that be an acceptable approach?
Thanks,
Lars
^ permalink raw reply
* [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: larsxschneider @ 2016-10-17 0:25 UTC (permalink / raw)
To: git; +Cc: tboegi, gitster, Lars Schneider
In-Reply-To: <20161017002550.88782-1-larsxschneider@gmail.com>
From: Lars Schneider <larsxschneider@gmail.com>
TravisCI changed their default macOS image from 10.10 to 10.11 [1].
Unfortunately the HTTPD tests do not run out of the box using the
pre-installed Apache web server anymore. Therefore we enable these
tests only for Linux and disable them for macOS.
[1] https://blog.travis-ci.com/2016-10-04-osx-73-default-image-live/
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
.travis.yml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 37a1e1f..d752447 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -32,7 +32,6 @@ env:
- DEFAULT_TEST_TARGET=prove
- GIT_PROVE_OPTS="--timer --jobs 3 --state=failed,slow,save"
- GIT_TEST_OPTS="--verbose --tee"
- - GIT_TEST_HTTPD=true
- GIT_TEST_CLONE_2GB=YesPlease
# t9810 occasionally fails on Travis CI OS X
# t9816 occasionally fails with "TAP out of sequence errors" on Travis CI OS X
@@ -57,6 +56,8 @@ before_install:
- >
case "${TRAVIS_OS_NAME:-linux}" in
linux)
+ export GIT_TEST_HTTPD=YesPlease
+
mkdir --parents custom/p4
pushd custom/p4
wget --quiet http://filehost.perforce.com/perforce/r$LINUX_P4_VERSION/bin.linux26x86_64/p4d
--
2.10.0
^ permalink raw reply related
* [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: larsxschneider @ 2016-10-17 0:25 UTC (permalink / raw)
To: git; +Cc: tboegi, gitster, Lars Schneider
In-Reply-To: <20161017002550.88782-1-larsxschneider@gmail.com>
From: Lars Schneider <larsxschneider@gmail.com>
Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
was deprecated since macOS 10.7.
Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
macOS. Make it possible to override this and use OpenSSL by defining
`DARWIN_OPENSSL`.
Original-patch-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
config.mak.uname | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index b232908..f0c94a9 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -108,6 +108,12 @@ ifeq ($(uname_S),Darwin)
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
HAVE_GETDELIM = YesPlease
endif
+ ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 15 && echo 1),1)
+ ifndef DARWIN_OPENSSL
+ NO_OPENSSL = YesPlease
+ APPLE_COMMON_CRYPTO=YesPlease
+ endif
+ endif
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
HAVE_DEV_TTY = YesPlease
--
2.10.0
^ permalink raw reply related
* [PATCH v1 0/2] Fix default macOS build locally and on Travis CI
From: larsxschneider @ 2016-10-17 0:25 UTC (permalink / raw)
To: git; +Cc: tboegi, gitster, Lars Schneider
From: Lars Schneider <larsxschneider@gmail.com>
Apple removed the OpenSSL header files in macOS and therefore Git does
not build out of the box on macOS anymore. See previous discussion with
Torsten here: http://public-inbox.org/git/565B3036.8000604@web.de/
This mini series makes Git build out of the box on macOS, again, and
disables the HTTPD tests on macOS TravisCI as they don't work anymore
with the new macOS TravisCI default image:
https://blog.travis-ci.com/2016-10-04-osx-73-default-image-live/
Thanks,
Lars
Lars Schneider (2):
config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
travis-ci: disable GIT_TEST_HTTPD for macOS
.travis.yml | 3 ++-
config.mak.uname | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.10.0
^ permalink raw reply
* Re: [PATCH v10 13/14] convert: add filter.<driver>.process option
From: Lars Schneider @ 2016-10-16 23:13 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, git, Jakub Narębski, peff
In-Reply-To: <20161011100946.GA13745@tb-raspi>
> On 11 Oct 2016, at 03:09, Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Tue, Oct 11, 2016 at 10:11:22AM +0200, Lars Schneider wrote:
>>
>>> On 10 Oct 2016, at 21:58, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> larsxschneider@gmail.com writes:
>>>
>>> [...]
>>>>
>> -test_cmp_count_except_clean () {
>> - for FILE in $@
>
>> +test_cmp_count () {
>> + expect=$1 actual=$2
>
> That could be
> expect="$1"
> actual="$2"
Sure!
>> + for FILE in "$expect" "$actual"
>> do
>
>> + sort "$FILE" | uniq -c | sed "s/^[ ]*//" |
>> + sed "s/^\([0-9]\) IN: clean/x IN: clean/" |
>> + sed "s/^\([0-9]\) IN: smudge/x IN: smudge/" >"$FILE.tmp" &&
>> + cat "$FILE.tmp" >"$FILE"
>
> How about
> cp "$FILE.tmp" "$FILE"
OK, I'll use "mv".
Thanks,
Lars
^ permalink raw reply
* [PATCH v11 14/14] contrib/long-running-filter: add long running filter example
From: larsxschneider @ 2016-10-16 23:20 UTC (permalink / raw)
To: git; +Cc: gitster, jnareb, peff, ramsay, tboegi, Lars Schneider
In-Reply-To: <20161016232038.84951-1-larsxschneider@gmail.com>
From: Lars Schneider <larsxschneider@gmail.com>
Add a simple pass-thru filter as example implementation for the Git
filter protocol version 2. See Documentation/gitattributes.txt, section
"Filter Protocol" for more info.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Documentation/gitattributes.txt | 4 +-
contrib/long-running-filter/example.pl | 128 +++++++++++++++++++++++++++++++++
2 files changed, 131 insertions(+), 1 deletion(-)
create mode 100755 contrib/long-running-filter/example.pl
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 3f4d1ed..976243a 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -516,7 +516,9 @@ the command pipe on exit. The filter is expected to detect EOF
and exit gracefully on its own. Git will wait until the filter
process has stopped.
-If you develop your own long running filter
+A long running filter demo implementation can be found in
+`contrib/long-running-filter/example.pl` located in the Git
+core repository. If you develop your own long running filter
process then the `GIT_TRACE_PACKET` environment variables can be
very helpful for debugging (see linkgit:git[1]).
diff --git a/contrib/long-running-filter/example.pl b/contrib/long-running-filter/example.pl
new file mode 100755
index 0000000..3945705
--- /dev/null
+++ b/contrib/long-running-filter/example.pl
@@ -0,0 +1,128 @@
+#!/usr/bin/perl
+#
+# Example implementation for the Git filter protocol version 2
+# See Documentation/gitattributes.txt, section "Filter Protocol"
+#
+# Please note, this pass-thru filter is a minimal skeleton. No proper
+# error handling was implemented.
+#
+
+use strict;
+use warnings;
+
+my $MAX_PACKET_CONTENT_SIZE = 65516;
+
+sub packet_bin_read {
+ my $buffer;
+ my $bytes_read = read STDIN, $buffer, 4;
+ if ( $bytes_read == 0 ) {
+
+ # EOF - Git stopped talking to us!
+ exit();
+ }
+ elsif ( $bytes_read != 4 ) {
+ die "invalid packet: '$buffer'";
+ }
+ my $pkt_size = hex($buffer);
+ if ( $pkt_size == 0 ) {
+ return ( 1, "" );
+ }
+ elsif ( $pkt_size > 4 ) {
+ my $content_size = $pkt_size - 4;
+ $bytes_read = read STDIN, $buffer, $content_size;
+ if ( $bytes_read != $content_size ) {
+ die "invalid packet ($content_size bytes expected; $bytes_read bytes read)";
+ }
+ return ( 0, $buffer );
+ }
+ else {
+ die "invalid packet size: $pkt_size";
+ }
+}
+
+sub packet_txt_read {
+ my ( $res, $buf ) = packet_bin_read();
+ unless ( $buf =~ s/\n$// ) {
+ die "A non-binary line MUST be terminated by an LF.";
+ }
+ return ( $res, $buf );
+}
+
+sub packet_bin_write {
+ my $buf = shift;
+ print STDOUT sprintf( "%04x", length($buf) + 4 );
+ print STDOUT $buf;
+ STDOUT->flush();
+}
+
+sub packet_txt_write {
+ packet_bin_write( $_[0] . "\n" );
+}
+
+sub packet_flush {
+ print STDOUT sprintf( "%04x", 0 );
+ STDOUT->flush();
+}
+
+( packet_txt_read() eq ( 0, "git-filter-client" ) ) || die "bad initialize";
+( packet_txt_read() eq ( 0, "version=2" ) ) || die "bad version";
+( packet_bin_read() eq ( 1, "" ) ) || die "bad version end";
+
+packet_txt_write("git-filter-server");
+packet_txt_write("version=2");
+packet_flush();
+
+( packet_txt_read() eq ( 0, "capability=clean" ) ) || die "bad capability";
+( packet_txt_read() eq ( 0, "capability=smudge" ) ) || die "bad capability";
+( packet_bin_read() eq ( 1, "" ) ) || die "bad capability end";
+
+packet_txt_write("capability=clean");
+packet_txt_write("capability=smudge");
+packet_flush();
+
+while (1) {
+ my ($command) = packet_txt_read() =~ /^command=([^=]+)$/;
+ my ($pathname) = packet_txt_read() =~ /^pathname=([^=]+)$/;
+
+ packet_bin_read();
+
+ my $input = "";
+ {
+ binmode(STDIN);
+ my $buffer;
+ my $done = 0;
+ while ( !$done ) {
+ ( $done, $buffer ) = packet_bin_read();
+ $input .= $buffer;
+ }
+ }
+
+ my $output;
+ if ( $command eq "clean" ) {
+ ### Perform clean here ###
+ $output = $input;
+ }
+ elsif ( $command eq "smudge" ) {
+ ### Perform smudge here ###
+ $output = $input;
+ }
+ else {
+ die "bad command '$command'";
+ }
+
+ packet_txt_write("status=success");
+ packet_flush();
+ while ( length($output) > 0 ) {
+ my $packet = substr( $output, 0, $MAX_PACKET_CONTENT_SIZE );
+ packet_bin_write($packet);
+ if ( length($output) > $MAX_PACKET_CONTENT_SIZE ) {
+ $output = substr( $output, $MAX_PACKET_CONTENT_SIZE );
+ }
+ else {
+ $output = "";
+ }
+ }
+ packet_flush(); # flush content!
+ packet_flush(); # empty list, keep "status=success" unchanged!
+
+}
--
2.10.0
^ permalink raw reply related
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