* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Michael Haggerty @ 2012-12-21 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git
In-Reply-To: <7vr4mj1g8j.fsf@alter.siamese.dyndns.org>
On 12/21/2012 06:12 PM, Junio C Hamano wrote:
> "diff" is always about two endpoints, not the path that connects
> these two endpoints (aka "range"), and when you want to "diff"
> between two commits, you say "diff A B". "A..B" happens to be
> accepted as such only by accident (e.g. the old command line parser
> did not have a reliable way to tell "^A B" and "A..B" apart), not by
> design.
>
> side note: incidentally, now we have rev_cmdline_info support,
> we could start deprecating "diff A..B" syntax.
I often find myself using "git diff A..B" syntax when using the command
line history because the previous command used "A..B"; e.g.,
git log A..B
git diff A..B
It's quick to recall the previous command, edit "log" -> "diff", and
press enter; having to remove the dots would require a few extra keypresses.
> Actually, in many places where the command line parser knows it
> wants a single point, and never a range, we should be able to apply
> the "A...B as a notation to specify a single point" rule.
>
> Of course you could come up with a symbol other than "..." for that
> purpose, and migrate the current "git checkout A...B" special case
> to use that other symbol, but that would be more work and also you
> would need to retrain existing users.
OTOH making A...B sometimes mean a range and sometimes a merge-base
(depending on context) adds a confusing non-uniformity, and also has the
disadvantage of making merge-base shorthand unavailable in contexts that
allow a range.
OTOOH git already has so many notations that can be used on the command
line; inventing yet another one would make it that much more overwhelming.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Pushing symbolic references to remote repositories?
From: Dun Peal @ 2012-12-21 19:53 UTC (permalink / raw)
To: Git ML
Hi,
I need to share a symbolic reference - essentially, a named pointer to
another reference - among multiple repositories.
As shown in the code below, I can successfully create a local
symbolic-ref `foo_ptr` to branch `foo`, but can't push it to a remote,
in this case `origin`:
$ git branch foo; git symbolic-ref foo_ptr refs/heads/foo; git rev-parse foo_ptr
fbfec27dc6d42d48ca5d5b178caa34c666a4c39b
$ git push origin foo foo_ptr
error: dst ref refs/heads/foo receives from more than one src.
Is there a clean and reliable way to do that, or are symbolic
references just not meant to be shared?
Thanks, D.
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 20:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael J Gruber, git
In-Reply-To: <vpqhanf2yny.fsf@grenoble-inp.fr>
On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> "Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
>
>> The split command will create a new repository for all files foo in a
>> folder (path/foo) and their commit history.
>>
>> The replant command reverses that process, re-adding the path prefix
>> for each file. It may be possible to extend that process into one that
>> automatically reintegrates the new commits in the original history,
>> but I never had time to complete that work.
>>
>> I did originally add the "replant" functionality into my version of
>> the git-subtree script, but given the number of commits in the
>> original repository, git-subtree turned out to be inefficient, due to
>> the use of temporary files (tens of thousands of files IIRC).
>>
>> Those problems led to my development of git-splitter in Python
>> (bypassing the problem of temporary files), but just including the
>> functionality I needed, join was not one of those functions.
>
> That still doesn't answer the question: why did you need to write a new
> tool instead of extending git-subtree?
The primary problem with git-subtree was that I ended up with a temporary
file directory containing 100+K files, which I tracked back to being used
to manage the commit-to-tree mapping. On Windows, at least, that literally
slowed down the process to a crawl.
> If one doesn't use "replant", is your tool different from git-subtree?
No, it is not different. However, my tool will use RAM, not diskspace to
manage information.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Martin von Zweigbergk @ 2012-12-21 21:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git
In-Reply-To: <50D4BBDC.6030700@alum.mit.edu>
On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 12/21/2012 06:12 PM, Junio C Hamano wrote:
>> "diff" is always about two endpoints, not the path that connects
>> these two endpoints (aka "range"), and when you want to "diff"
>> between two commits, you say "diff A B". "A..B" happens to be
>> accepted as such only by accident (e.g. the old command line parser
>> did not have a reliable way to tell "^A B" and "A..B" apart), not by
>> design.
Off topic: I also find it hard to wrap my head around what diffing
against a negative revision would mean. Looking at the result of
running it, it seems to be the same as diffing against a positive one.
>>
>> side note: incidentally, now we have rev_cmdline_info support,
>> we could start deprecating "diff A..B" syntax.
>
> I often find myself using "git diff A..B" syntax when using the command
> line history because the previous command used "A..B"; e.g.,
>
> git log A..B
> git diff A..B
The problem with this, to me, if it wasn't clear, is that "git log
A..B" shows you is new _since B branched off from A_, while "git diff
A..B" shows you what has changed _between A and B_.
>> Actually, in many places where the command line parser knows it
>> wants a single point, and never a range, we should be able to apply
>> the "A...B as a notation to specify a single point" rule.
>>
>> Of course you could come up with a symbol other than "..." for that
>> purpose, and migrate the current "git checkout A...B" special case
>> to use that other symbol, but that would be more work and also you
>> would need to retrain existing users.
>
> OTOH making A...B sometimes mean a range and sometimes a merge-base
> (depending on context) adds a confusing non-uniformity, and also has the
> disadvantage of making merge-base shorthand unavailable in contexts that
> allow a range.
And making it unavailable in contexts where the command was not
specifically implemented to support it. I'm sure there are many
scripts out there that use "git ... $(git merge-base A B) ..." that
could be simplified if rev-parse could resolve a merge base.
> OTOOH git already has so many notations that can be used on the command
> line; inventing yet another one would make it that much more overwhelming.
Agreed.
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Manlio Perillo @ 2012-12-21 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vip7v1d96.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/12/2012 19:17, Junio C Hamano ha scritto:
> [...]
> Of course you can plan ahead (this is what I usually do when working
> on a series that is not "how about this" throw-away patch I send to
> this list all the time) and name the topic "topic-v1", fork the new
> round "topic-v2", "topic-v3", etc. and do things like
>
> $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
>
> (the point being that then you do ^P or whatever shell command
> history mechanism to recall that line, edit "4" to "3" and rerun the
> comparison for other corresponding ones).
>
Thanks, this seems fine.
Maybe topic-v2 --> topic/v2 (it looks better to me).
> On a related but different front, I've been thinking about improving
> the "format-patch --subject-prefix" mechanism to make it even easier
> to use.
>
> [...]
>
> What if we added another option, say --reroll $n (or -v$n), to let
> you write:
>
> $ git format-patch --cover-letter -v4 -o ./+mp master
>
> that produces output files named like:
>
> ./+mp/v4-0000-cover-letter.txt
> ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
>
> with the subject '[PATCH v4]' prefix?
>
I think it is a good idea to reduce the things one have to do by hand.
I, too, was thinking something similar, with a -v$n option.
And, from these few days I have started to follow the mailing list, it
seems that '[PATCH v$n'] is the standard practice.
By the way, I would also like to be able to set the default value for
the --output option in config file; something like:
[format]
output = +mp/$(git symbolic-ref --short HEAD)
where the string will be processed by the shell:
sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"
Note that printf is POSIX, and the standard suggests to use it instead
of echo:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
I have read the affected source code, and it should not be too hard.
What do you think?
I should be able to hack the patch in the weekend, but I'm not sure it
will be accepted.
> Then you can transplant the cover letter material from the cover
> letter from the older iteration to the new cover letter in your
> editor, and sending them out will become
>
> $ git send-email ... ./+mp/v4-*.txt
>
> Hmm?
Seems good.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDU1REACgkQscQJ24LbaUT5dgCgismeh+R3B26otuBIXRf/VUiq
+5gAoIR56wVfs8Vw8AAWtim4aor97MXN
=DfeG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-21 21:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50D4B639.9000807@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> Perhaps your experience is with an older version of cvs2svn?
Well, it has been at least four years since I ran it on anything.
Maybe that counts as old.
I'm willing to believe it's working better now, but I've had to deal
with geological strata of nastiness older versions produced in various
Subversion repositories (cleaning up that crud was a major motivation
for reposurgeon) and I'm fairly sure I haven't seen the last such
fossils. Every sufficiently old Subversion repository seems to have
few.
> If not,
> please be specific rather than just making complaints that are too vague
> to be rebutted or fixed (whichever is appropriate). I put a *lot* of
> effort into getting cvs2svn to run correctly, and I take bug reports
> very seriously.
I can't be specific now, but that may change shortly. I'm putting
together a test suite for cvsps with the specific intention of
capturing as many odd corner cases as I can. (I just finished writing
a small Python framework for expressing interleaved CVS command
sequences on multiple checkouts in a way that can be easily run.)
It wouldn't be difficult for me to test whether these break cvs2svn.
You've established that someone over there is paying attention, so
I'll do that, I guess.
I'm willing to share my test suite as well. Do you have your own zoo
of odd cases I could test on?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Junio C Hamano @ 2012-12-21 21:45 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Michael Haggerty, git
In-Reply-To: <CANiSa6hcDHTpZnAXR3zxdv-H4r-yRjuSx_kgE5V1rSFk_pNhOA@mail.gmail.com>
> Off topic: I also find it hard to wrap my head around what diffing
> against a negative revision would mean. Looking at the result of
> running it, it seems to be the same as diffing against a positive one.
That is not an off-topic at all, but is the crux of "diff A..B" being
a hysterical raisins.
It is parsed as and converted to "diff ^A B" by the revision command
line parser in
setup_revisions(), and the caller *guesses* what the command line
originally said by
inspecting that there are two revs in rev.pending[] array, the first
one is negative and
the second one is positive, to infer that the user typed "diff A..B"
and then finally
decides to compare A and B.
This was done before we introduced rev.cmdline_info to record what was
given from
the command line to result in the set of commits in rev.pending array.
If we were
writing "git diff" UI from scratch today, we wouldn't be looking at
rev.pending but
would be looking at rev.cmdline_info and we can differenciate between
"A B", "^A B",
and "A..B" (and reject the latter two as nonsense).
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Shawn Pearce @ 2012-12-21 21:54 UTC (permalink / raw)
To: Dun Peal; +Cc: Git ML
In-Reply-To: <CAD03jn5ACZyxJM9LEOSJov3BsT3W1N0sV3WYwcerJciMSpmSPA@mail.gmail.com>
On Fri, Dec 21, 2012 at 11:53 AM, Dun Peal <dunpealer@gmail.com> wrote:
> I need to share a symbolic reference - essentially, a named pointer to
> another reference - among multiple repositories.
>
> As shown in the code below, I can successfully create a local
> symbolic-ref `foo_ptr` to branch `foo`, but can't push it to a remote,
> in this case `origin`:
>
> $ git branch foo; git symbolic-ref foo_ptr refs/heads/foo; git rev-parse foo_ptr
> fbfec27dc6d42d48ca5d5b178caa34c666a4c39b
> $ git push origin foo foo_ptr
> error: dst ref refs/heads/foo receives from more than one src.
>
> Is there a clean and reliable way to do that, or are symbolic
> references just not meant to be shared?
There is no support for symbolic references in the network protocol,
so they cannot currently be shared by git push or git fetch.
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Michael Haggerty @ 2012-12-21 21:59 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Junio C Hamano, git
In-Reply-To: <CANiSa6hcDHTpZnAXR3zxdv-H4r-yRjuSx_kgE5V1rSFk_pNhOA@mail.gmail.com>
On 12/21/2012 10:31 PM, Martin von Zweigbergk wrote:
> On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 12/21/2012 06:12 PM, Junio C Hamano wrote:
>>> side note: incidentally, now we have rev_cmdline_info support,
>>> we could start deprecating "diff A..B" syntax.
>>
>> I often find myself using "git diff A..B" syntax when using the command
>> line history because the previous command used "A..B"; e.g.,
>>
>> git log A..B
>> git diff A..B
>
> The problem with this, to me, if it wasn't clear, is that "git log
> A..B" shows you is new _since B branched off from A_, while "git diff
> A..B" shows you what has changed _between A and B_.
You are quite right, of course, though in many useful cases they are the
same. But I guess I should just buck myself up for the new orthodoxy :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Michael Haggerty @ 2012-12-21 22:16 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121221214311.GA29147@thyrsus.com>
On 12/21/2012 10:43 PM, Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
>> Perhaps your experience is with an older version of cvs2svn?
>
> Well, it has been at least four years since I ran it on anything.
> Maybe that counts as old.
cvs2svn version 2.0 (Aug 2007) totally changed how cvs2svn deduces
changesets. Any results from before that are utterly irrelevant to
modern times.
The changes between version 2.0 and version 2.4 (Sep 2012) have done a
lot more to improve the quality of the conversion. The state of the art
is far beyond what it was four years ago.
>> If not,
>> please be specific rather than just making complaints that are too vague
>> to be rebutted or fixed (whichever is appropriate). I put a *lot* of
>> effort into getting cvs2svn to run correctly, and I take bug reports
>> very seriously.
>
> I can't be specific now, but that may change shortly. I'm putting
> together a test suite for cvsps with the specific intention of
> capturing as many odd corner cases as I can. (I just finished writing
> a small Python framework for expressing interleaved CVS command
> sequences on multiple checkouts in a way that can be easily run.)
>
> It wouldn't be difficult for me to test whether these break cvs2svn.
> You've established that someone over there is paying attention, so
> I'll do that, I guess.
I look forward to your results (whether positive or negative).
> I'm willing to share my test suite as well. Do you have your own zoo
> of odd cases I could test on?
Yes, we have a rather extensive test suite that includes lots of CVS
perversions. See run-tests.py and the CVS repositories under test-data.
Unfortunately, the tests mostly cover only 2svn conversions, but since
most of the tricky work is in the common code that infers the CVS
history, cvs2git benefits from the tests too.
This discussion is getting pretty cvs2svn-specific, so we should
probably move it over to the cvs2svn-dev mailing list.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Junio C Hamano @ 2012-12-21 22:17 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D4D511.4010003@gmail.com>
On Fri, Dec 21, 2012 at 1:30 PM, Manlio Perillo
<manlio.perillo@gmail.com> wrote:
>
> By the way, I would also like to be able to set the default value for
> the --output option in config file; something like:
>
> [format]
> output = +mp/$(git symbolic-ref --short HEAD)
>
> where the string will be processed by the shell:
>
> sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"
My knee-jerk reaction is that, while it might make sense to give an
option to allow users to use a dedicated directory per branch, I am
not interested in that form; especially the part that lets the users too
long a rope to hang themselves with by allowing an arbitrary shell
expansions goes against my taste.
But you *can* prove me wrong; read on.
> I should be able to hack the patch in the weekend, but I'm not sure it
> will be accepted.
You got it backwards, just like many other new people who come and go on
this list. If something is very useful, you'd work on it even if the result may
not appear immediately in the upstream, and you'd keep maintaining a local
fork so that you can keep benefiting from it, once you have written such a
useful feature (whatever it is). If even the original "itch-holder"
does not think
that the benefit from his change outweighs the cost of such an effort, why
should *I* carry it in my tree?
The goal of a contributor who comes up with an idea, gets "It doesn't sound
like a good idea" during the review but disagrees and believes in his idea
ought to be to prove the reviewer(s) wrong by polishing the idea and the
implementation so much that the upstream comes begging for your change ;-)
The core part of the change to add --reroll $n option should be straight-forward
and will involve a few functions in builtin/log.c, but the existing
code is so badly
structured that it probably needs a couple of "preparatory steps" patch to clean
up the API between internal functions on that codepath, before the real change
can be made, I think.
^ permalink raw reply
* Re: Noob Question
From: Andrew Ardill @ 2012-12-21 22:38 UTC (permalink / raw)
To: W T Riker; +Cc: git@vger.kernel.org
In-Reply-To: <50D463C4.6030208@gmail.com>
On 22 December 2012 00:27, W T Riker <wtriker.ffe@gmail.com> wrote:
> One basic question, since I don't make changes from the Linux
> side, only builds, do I need to install anything git related on that
> machine?
You don't need to install it, but there is no harm in it. If you ever
start doing a build from the linux box and decide you have the wrong
version of your code, it would be useful to have git installed so you
can checkout the right version. Installing git is quick and painless,
however, so you can cross that bridge once you get to it.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Installation Plan
From: Andrew Ardill @ 2012-12-21 22:48 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git@vger.kernel.org
In-Reply-To: <50D475A9.9020407@bellsouth.net>
hi Dennis,
In general your plan looks good. Note that you don't actually need the
Eclipse plugin at all, it just makes it possible to do git operations
while in your IDE. Most people will, even if they have the plugin,
still use the full client as it provides a lot more power and
flexibility. Use whatever you need to, and extend your toolset when
required.
Also, the leap from central repository on Linux to a clone on Windows
needs a little more thought. Will you set up a git server? Access the
central repository over ssh? A shared drive? Many people use a web
service (such as Bitbucket or GitHub) for this purpose as it becomes
easier to manage. You can then have a clone on the Linux box as well
as the Windows box.
On 22 December 2012 01:43, Dennis Putnam <dap1@bellsouth.net> wrote:
> Am I over simplifying things? I also think that this will open the door
> for collaborators in the event I need them with no changes to the way I
> work. I should note that builds are done on demand so is there a way to
> detect when a push is occurring and have the build script wait for
> completion and I suppose vise-versa?
You want to look into the different hooks available, most notable the
post-receive hook. There are also build servers that can monitor a
repository and build whenever it sees a new commit (Jenkins and Bamboo
are two I know of).
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Junio C Hamano @ 2012-12-21 23:11 UTC (permalink / raw)
To: Dun Peal; +Cc: Shawn Pearce, Git ML
In-Reply-To: <CAJo=hJvqptfKqM+6J8Ddfb5qcqjAU8bB_JO9VB-XVsCCf64NUQ@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Fri, Dec 21, 2012 at 11:53 AM, Dun Peal <dunpealer@gmail.com> wrote:
>>
>> Is there a clean and reliable way to do that, or are symbolic
>> references just not meant to be shared?
>
> There is no support for symbolic references in the network protocol,
> so they cannot currently be shared by git push or git fetch.
What Shawn said is technically correct, but do not read it as "we
know what protocol update we want at the network level, but we
haven't got around implementing it".
It is unclear what it means to send symrefs across repositories
(rather, what we want it to mean). In that sense, the reality is
closer to the latter of your choices.
There are three primary kinds of symrefs to consider:
* worktree/.git/HEAD is meant to point at the branch that is
currently checked out. This is designed to be under sole control
of the person who is working in such a repository and the outside
people have no business knowing which branch he happens to be
working on at this very moment (it can change the next minute).
* worktree/.git/refs/remotes/$name/HEAD is meant to point at the
remote-tracking branch of the named remote (e.g. 'origin') the
local user is interested in, to let "git checkout -b topic
origin" work, instead of a longer "git checkout -b topic
origin/master".
* bare.git/HEAD is meant to point at the "primary" branch at a
bare, distribution repository nobody works in directly. The
branch pointed at by the symref rarely, if ever, changes.
Nobody will imagine flipping worktree/.git/HEAD from outside by
pushing into it (unless you are trying to pull a prank on the user
who is working in that repository). Also, nobody would want to
update this symref by fetching from outside. So we won't have to
consider updating the first kind in the following discussion.
It is unlikely that anybody sane wants to update the remote-tracking
worktree/.git/refs/remotes/origin/HEAD from outside by pushing.
It *may* make sense to update it upon fetching, though, in some
cases. You first clone from bare.git/HEAD and learn [*1*] that the
primary branch at the time of cloning was 'master', and
remote/origin/HEAD in your repository is set to point at
origin/master. Now the upstream designates a different branch as
the primary (perhaps 'trunk'), and you may want your next "git
fetch" to repoint your remote/origin/HEAD to point at
'remote/origin/trunk'.
However, even this one is not unconditionally a good idea. The
branch you are interested in might be different from what your
remote designates as its primary branch in the first place. You may
for example want to follow along 'next' after cloning from me. E.g.
$ git clone git://git.kernel.org/pub/scm/git/git.git git
$ cd git
$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/next
It is not clear if it is a good idea to allow "git fetch" to repoint
your remotes/origin/HEAD to whatever I chose to point my HEAD at.
So for the second kind, pushing is irrelevant, and fetching is
"perhaps sometimes it may make sense".
I think that the only one and a half sensible use cases that
unconditionally make sense to update symrefs across repositories are
to update bare.git/HEAD symref:
- update bare.git/HEAD of a repository that is a local mirror of a
more authoritative repository with "git fetch --mirror", in which
case you do want to follow what branch is designated as the
primary by the project you are mirroring from;
- update bare.git/HEAD from outside by some means to change which
branch is the primary one for the project. Only because your
hosting site does not give you an easy way to do so, pushing from
another repository that happens to point its HEAD at a different
branch seems to be one plausible way to do so, but that does not
have to be the only way.
[Footnote]
*1* We would need to update the network protocol for this purpose,
as most transports do not carry this information and clone has to
guess which branch bare.git/HEAD points at.
The purpose of this message, though, is to illustrate that the
protocol update to carry the information is not the end of the
story, but merely is an enabling beginning. We need to know what
semantics we would want to implement on top of that transfer.
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #06; Fri, 21)
From: Junio C Hamano @ 2012-12-21 23:59 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I'll do another rc (hopefully final) for this cycle tomorrow, with
documentation updates that are already in 'master'. The toolchain
to prepare preformatted documentation pages in HTML/man formats have
been updated to the latest AsciiDoc (from 8.5.2 to 8.6.8), and I'd
appreciate it if people can report possible regressions (I already
know the updated toolchain fixes the pretty-quotes that appear in
some pages, e.g. "git fast-import", look for "Here <name").
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* as/doc-for-devs (2012-12-16) 2 commits
(merged to 'next' on 2012-12-18 at ff1f37e)
+ Documentation: move support for old compilers to CodingGuidelines
+ SubmittingPatches: add convention of prefixing commit messages
It might be a better idea to move the text the bottom one adds to
the extended description from the quick checklist part.
Will fast-track to the upcoming release.
* cr/doc-checkout-branch (2012-12-18) 2 commits
(merged to 'next' on 2012-12-19 at e14b6c4)
+ Documentation/git-checkout.txt: document 70c9ac2 behavior
+ Documentation/git-checkout.txt: clarify usage
Document the magic "git checkout <no-such-branch>" hack to create
local branch out of a remote tracking branch that hasn't been
documented so far.
Will fast-track to the upcoming release.
* jc/doc-diff-blobs (2012-12-18) 1 commit
(merged to 'next' on 2012-12-19 at 82c5000)
+ Documentation: Describe "git diff <blob> <blob>" separately
"git diff <blob> <blob>" was not documented and was only hinted as
an extension to "git diff <commit> <commit> -- <pathspec>", but
comparison between two blobs are more special than that. It does
not take any pathspec to begin with.
Will fast-track to the upcoming release.
* jc/fetch-tags-doc (2012-12-13) 1 commit
(merged to 'next' on 2012-12-17 at 857413a)
+ fetch --tags: clarify documentation
"git fetch --tags" was explained as if it were "git fetch
--no-no-tags", which is not the case, causing confusion.
Will fast-track to the upcoming release.
* jk/avoid-mailto-invalid-in-doc (2012-12-16) 1 commit
(merged to 'next' on 2012-12-18 at 81dac40)
+ Documentation: don't link to example mail addresses
Avoids invalid sample e-mail addresses from becoming mailto links
in the formatted output.
Will fast-track to the upcoming release.
* jk/mailmap-cleanup (2012-12-12) 5 commits
(merged to 'next' on 2012-12-17 at 07c1a11)
+ contrib: update stats/mailmap script
+ .mailmap: normalize emails for Linus Torvalds
+ .mailmap: normalize emails for Jeff King
+ .mailmap: fix broken entry for Martin Langhoff
+ .mailmap: match up some obvious names/emails
Update various entries in our .mailmap file.
Will fast-track to the upcoming release.
* nd/index-format-doc (2012-12-13) 1 commit
(merged to 'next' on 2012-12-17 at 7984924)
+ index-format.txt: clarify what is "invalid"
Will fast-track to the upcoming release.
* sl/git-svn-docs (2012-12-05) 4 commits
(merged to 'next' on 2012-12-07 at 5bfbb73)
+ git-svn: Note about tags.
+ git-svn: Expand documentation for --follow-parent
+ git-svn: Recommend use of structure options.
+ git-svn: Document branches with at-sign(@).
Will fast-track to the upcoming release.
* sl/readme-gplv2 (2012-12-15) 2 commits
(merged to 'next' on 2012-12-18 at c839810)
+ README: it does not matter who the current maintainer is
+ README: Git is released under the GPLv2, not just "the GPL"
Clarify that the project as a whole is GPLv2 only, with some parts
borrowed under different licenses that are compatible with GPLv2.
Will fast-track to the upcoming release.
* ta/api-index-doc (2012-12-16) 1 commit
(merged to 'next' on 2012-12-18 at a251888)
+ Remove misleading date from api-index-skel.txt
Will fast-track to the upcoming release.
* ta/new-command-howto (2012-12-21) 1 commit
(merged to 'next' on 2012-12-21 at 5d0f65f)
+ Move ./technical/api-command.txt to ./howto/new-command.txt
Will fast-track to the upcoming release.
--------------------------------------------------
[New Topics]
* jc/mkstemp-more-careful-error-reporting (2012-12-18) 1 commit
- xmkstemp(): avoid showing truncated template more carefully
An earlier patch to save original arguments to mkstemp() away and
use it to report what filename we failed to create incorrectly used
the buffer munged by failing mkstemp().
Will merge to 'next'.
* jc/maint-test-portability (2012-12-19) 3 commits
- t4014: fix arguments to grep
- t9502: do not assume GNU tar
- t0200: "locale" may not exist
(this branch is used by jc/test-portability.)
Minor test fixes noticed while running our tests on OpenBSD 5.2,
applicable to 'maint'.
Will merge to 'next'.
* jc/test-portability (2012-12-19) 3 commits
- t9020: use configured Python to run the test helper
- t3600: Avoid "cp -a", which is a GNUism
- Merge branch 'jc/maint-test-portability' into 'jc/test-portability'
(this branch uses jc/maint-test-portability.)
The remainder of jc/maint-test-portability, applicable to 'master'.
Will merge to 'next'.
* jc/maint-fnmatch-old-style-definition (2012-12-19) 1 commit
- compat/fnmatch: update old-style definition to ANSI
Update old-style function definition "int foo(bar) int bar; {}"
to "int foo(int bar) {}".
Will merge to 'next'.
* jk/pathspec-literal (2012-12-19) 1 commit
- add global --literal-pathspecs option
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
Will merge to 'next'.
* da/p4merge-mktemp (2012-12-21) 1 commit
- mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Create an empty file in $TMPDIR instead of using an empty file in
the local directory (but why?).
* er/python-version-requirements (2012-12-20) 2 commits
- (squash???) remote-helpers/git/__init__.py needs sys before checking sys.hexversion
- Python scripts: check minimum compatible version after auditing
Will merge to 'next' after getting an Ack on the top-squash.
* jc/unpack-file-in-tmpdir (2012-12-19) 1 commit
- unpack-file: allow output to be in $TMPDIR
Throw-away "how about this" to teach unpack-file to use $TMPDIR to
store its output.
Will discard.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
- oneway_merge(): only lstat() when told to update worktree
Optimize "read-tree -m <tree-ish>" without "-u".
Will merge to 'next'.
* jk/repack-ref-racefix (2012-12-21) 1 commit
- refs: do not use cached refs in repack_without_ref
Race-fix for pack-refs running in parallel to ref creation.
Will merge to 'next'.
* rb/http-cert-cred-no-username-prompt (2012-12-21) 1 commit
- http.c: Avoid username prompt for certifcate credentials
There is no need to ask for username if the authentication is done
by certificate identity.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jc/merge-blobs (2012-12-13) 5 commits
. [broken] wip to fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* fc/remote-bzr (2012-12-13) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree upon pushing
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* wk/submodule-update-remote (2012-12-19) 3 commits
- submodule add: If --branch is given, record it in .gitmodules
- submodule update: add --remote for submodule's upstream changes
- submodule: add get_submodule_config helper funtion
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
Will merge to 'next'.
* cc/no-gitk-build-dependency (2012-12-18) 3 commits
- Makefile: replace "echo 1>..." with "echo >..."
- Makefile: detect when PYTHON_PATH changes
- Makefile: remove tracking of TCLTK_PATH
Remove leftover bits from an earlier change to move gitk in its own
subdirectory. Reimplementing the dependency tracking rules needs
to be done in gitk history separately.
Will merge to 'next'.
* jc/format-color-auto (2012-12-17) 2 commits
(merged to 'next' on 2012-12-18 at 5aaac94)
+ log --format: teach %C(auto,black) to respect color config
+ t6006: clean up whitespace
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
Will cook in 'next'.
* ss/svn-prompt (2012-12-17) 3 commits
- git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
- perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not set
- git-svn, perl/Git.pm: add central method for prompting passwords
Waiting for an Ack from the area export.
* zk/clean-report-failure (2012-12-17) 1 commit
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
* mp/complete-paths (2012-12-21) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts review.
* ja/directory-attrs (2012-12-17) 1 commit
(merged to 'next' on 2012-12-17 at ced8e73)
+ Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
Will cook in 'next'.
* jk/mailmap-from-blob (2012-12-13) 5 commits
(merged to 'next' on 2012-12-17 at 14b7cdc)
+ mailmap: default mailmap.blob in bare repositories
+ mailmap: fix some documentation loose-ends for mailmap.blob
+ mailmap: clean up read_mailmap error handling
+ mailmap: support reading mailmap from blobs
+ mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
Will cook in 'next'.
* dm/port (2012-12-19) 4 commits
- git-compat-util.h: do not #include <sys/param.h> by default
- Generalize the inclusion of strings.h
- Detect when the passwd struct is missing pw_gecos
- Support builds when sys/param.h is missing
(this branch is used by mk/qnx.)
Will merge to 'next'.
* jk/complete-commit-c (2012-12-15) 1 commit
(merged to 'next' on 2012-12-18 at 75b5f21)
+ completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
Will cook in 'next'.
* jk/error-const-return (2012-12-15) 2 commits
- silence some -Wuninitialized false positives
- make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings. Looks somewhat ugly but not too much.
Will merge to 'next'.
* mk/qnx (2012-12-19) 2 commits
- Port to QNX
- Make lock local to fetch_pack
(this branch uses dm/port.)
Port to QNX; we may want to rebase this on top of dm/port topic as
it also wants to use the HAVE_STRINGS_H mechanism it introduces.
Will merge to 'next'.
* rj/maint-cygwin-say-color (2012-12-15) 1 commit
- tests: Allow customization of how say_color() prints
Even though I do not think of a cleaner way to do this, I am not
happy with the way how $GIT_TEST_PRINT and $GIT_TEST_PRINT_LN are
interpolated into the command line with token splitting at $IFS.
Will discard, per discussion with the author.
* as/test-tweaks (2012-12-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- tests: refactor mechanics of testing in a sub test-lib
- tests: change info messages from yellow/brown to cyan
- tests: paint skipped tests in blue
- tests: paint known breakages in yellow
- tests: test number comes first in 'not ok $count - $message'
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Will merge to 'next'.
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
Will cook in 'next'.
* ap/log-mailmap (2012-12-15) 7 commits
- test: Add test for --use-mailmap option
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Simplify map_user() interface
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Will merge to 'next' after reading it over once again.
* jc/fetch-ignore-symref (2012-12-11) 1 commit
(merged to 'next' on 2012-12-17 at 370e2c8)
+ fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
Will cook in 'next'.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at 9f39410)
+ gitweb: Sort projects with undefined ages last
Gitweb showed repositories without any commit at the top in its
age-sorted view, in which the users are interested in looking at
active projects; sorting them at the bottom makes it more useful.
Will cook in 'next'.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at c1f0d7f)
+ nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
Will cook in 'next'.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Will cook in 'next'.
* jc/same-encoding (2012-12-10) 1 commit
(merged to 'next' on 2012-12-17 at 86b41c7)
+ format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
Will cook in 'next'.
* nd/invalidate-i-t-a-cache-tree (2012-12-15) 4 commits
(merged to 'next' on 2012-12-18 at 33e4488)
+ cache-tree: invalidate i-t-a paths after generating trees
+ cache-tree: fix writing cache-tree when CE_REMOVE is present
+ cache-tree: replace "for" loops in update_one with "while" loops
+ cache-tree: remove dead i-t-a code in verify_cache()
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
Will cook in 'next'.
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will cook in 'next'.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will cook in 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will cook in 'next'.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will cook in 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will cook in 'next'.
* nd/wildmatch (2012-12-15) 15 commits
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will cook in 'next'.
^ permalink raw reply
* Missing Refs after Garbage Collection
From: Earl Gresh @ 2012-12-22 1:41 UTC (permalink / raw)
To: git
Hi-
I have observed that after running GC, one particular git repository ended up with some missing refs in the refs/changes/* namespace the Gerrit uses for storing patch sets. The refs were valid and should not have been pruned. Concerned about loosing data, GC is still enabled but ref packing is turned off. Now the number of refs has grown to the point that it's causing performance problems when cloning the project.
Is anyone familiar with git gc deleting valid references? I'm running git version 1.7.8. Have there been any patches in later git releases that might address this issue ( if it is a git problem )?
Thanks
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: Junio C Hamano @ 2012-12-22 1:53 UTC (permalink / raw)
To: David Aguilar; +Cc: Jeremy Morton, git
In-Reply-To: <7v4njf2xrk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> By the way, who is going to remove this temporary file once the
> command is done?
Nevermind; I can see that once the backend returns it is removed in
the same function.
^ permalink raw reply
* Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Heiko Voigt @ 2012-12-22 3:47 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Michael Haggerty, git
In-Reply-To: <20121221104437.GA5244@thyrsus.com>
Hi,
On Fri, Dec 21, 2012 at 05:44:37AM -0500, Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
> > In 2009 I added tests demonstrating some of the erroneous behavior of
> > git-cvsimport. The failing tests in t9601-t9603 are concrete examples
> > of the problems mentioned in the manpage.
>
> Thanks, that will be extremely useful. One of the things I'm putting effort
> into is building a good test suite for the tool; I may well be able to adapt
> your tests directly.
Back then when I was converting some repositories to git and I also
wrote a quick testsuite for cvsps in an attempt to fix the bugs but gave
up. That was the point when I wrote about cvsimports limitations in the
documentation.
My commits can be found here:
http://repo.or.cz/w/cvsps-hv.git
I just quickly checked and it seems that it does not run cleanly on a
modern Linux anymore. If it is of interest to you I can try to get it
running again.
Cheers Heiko
^ permalink raw reply
* Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-22 6:21 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Haggerty, git
In-Reply-To: <20121222034751.GA11635@book-mint>
Heiko Voigt <hvoigt@hvoigt.net>:
> Back then when I was converting some repositories to git and I also
> wrote a quick testsuite for cvsps in an attempt to fix the bugs but gave
> up. That was the point when I wrote about cvsimports limitations in the
> documentation.
>
> My commits can be found here:
>
> http://repo.or.cz/w/cvsps-hv.git
>
> I just quickly checked and it seems that it does not run cleanly on a
> modern Linux anymore. If it is of interest to you I can try to get it
> running again.
That would be helpful. Please give it some effort.
I'm going to work on merging the cvsps patches Yann Dirson has been
accumulating.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* MDaemon Notification -- Attachment Removed
From: Postmaster @ 2012-12-22 6:41 UTC (permalink / raw)
To: git
-------------------------------------------------------------------
MDaemon has detected restricted attachments within an email message
-------------------------------------------------------------------
>From : git@vger.kernel.org
To : vcsc@vinalinescontainer.com
Subject : STATUS
Message-ID:
---------------------
Attachment(s) removed
---------------------
vcsc@vinalinescontainer.com
^ permalink raw reply
* [PATCH 0/8] fnmatch replacement step 1
From: Nguyễn Thái Ngọc Duy @ 2012-12-22 7:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
This series makes wildmatch compatible with fnmatch, at least for
FNM_CASEFOLD and FNM_PATHNAME. This makes it possible to use wildmatch
as a fnmatch replacement. The replacement is optional and turned on via
USE_WILDMATCH.
Step 2 would be turn USE_WILDMATCH by default and remove
compat/fnmatch. We can leave it for now until we are certain we don't
introduce any kind of regressions.
Measurement is performed to see how wildmatch compete with
fnmatch(es). I was surprised that my glibc version is even slower than
compat/fnmatch. For more details, see 5/8. wildmatch is faster (about
20%) in most cases. It is slower in '*/*/*' tests both with and without
FNM_PATHNAME. 7/8 and 8/8 fix that, making wildmatch fastest in all
(tested) cases.
I'd appreciate if people test it with more patterns (both weird and
commonly used) against different fnmatch versions and turn on
USE_WILDMATCH to see if we need to fix something else, both correctness
and performance. So far I'm convinced that the replacement is a good
thing to do.
The series requires nd/wildmatch, obviously.
Nguyễn Thái Ngọc Duy (8):
compat/fnmatch: respect NO_FNMATCH* even on glibc
wildmatch: rename constants and update prototype
wildmatch: make dowild() take arbitrary flags
wildmatch: support "no FNM_PATHNAME" mode
test-wildmatch: add "perf" command to compare wildmatch and fnmatch
Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
wildmatch: make a special case for "*/" with FNM_PATHNAME
wildmatch: advance faster in <asterisk> + <literal> patterns
Makefile | 6 +++
compat/fnmatch/fnmatch.c | 3 +-
dir.c | 3 +-
git-compat-util.h | 13 +++++
t/t3070-wildmatch.sh | 27 ++++++++++
test-wildmatch.c | 82 +++++++++++++++++++++++++++-
wildmatch.c | 137 +++++++++++++++++++++++++++++------------------
wildmatch.h | 23 +++++---
8 files changed, 232 insertions(+), 62 deletions(-)
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply
* [PATCH 1/8] compat/fnmatch: respect NO_FNMATCH* even on glibc
From: Nguyễn Thái Ngọc Duy @ 2012-12-22 7:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1356163028-29967-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
compat/fnmatch/fnmatch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
index 9473aed..6f7387d 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch.c
@@ -55,7 +55,8 @@
program understand `configure --with-gnu-libc' and omit the object files,
it is simpler to just do this in the source for each such file. */
-#if defined _LIBC || !defined __GNU_LIBRARY__
+#if defined NO_FNMATCH || defined NO_FNMATCH_CASEFOLD || \
+ defined _LIBC || !defined __GNU_LIBRARY__
# if defined STDC_HEADERS || !defined isascii
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH 4/8] wildmatch: support "no FNM_PATHNAME" mode
From: Nguyễn Thái Ngọc Duy @ 2012-12-22 7:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1356163028-29967-1-git-send-email-pclouds@gmail.com>
So far, wildmatch() has always honoured directory boundary and there
was no way to turn it off. Make it behave more like fnmatch() by
requiring all callers that want the FNM_PATHNAME behaviour to pass
that in the equivalent flag WM_PATHNAME. Callers that do not specify
WM_PATHNAME will get wildcards like ? and * in their patterns matched
against '/', just like not passing FNM_PATHNAME to fnmatch().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
dir.c | 2 +-
t/t3070-wildmatch.sh | 27 +++++++++++++++++++++++++++
test-wildmatch.c | 6 ++++--
wildmatch.c | 13 +++++++++----
wildmatch.h | 1 +
5 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/dir.c b/dir.c
index 175a182..6ef0396 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,7 @@ int match_pathname(const char *pathname, int pathlen,
}
return wildmatch(pattern, name,
- ignore_case ? WM_CASEFOLD : 0,
+ WM_PATHNAME | (ignore_case ? WM_CASEFOLD : 0),
NULL) == 0;
}
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index d5bafef..dbfa903 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -29,6 +29,18 @@ match() {
fi
}
+pathmatch() {
+ if [ $1 = 1 ]; then
+ test_expect_success "pathmatch: match '$2' '$3'" "
+ test-wildmatch pathmatch '$2' '$3'
+ "
+ else
+ test_expect_success "pathmatch: no match '$2' '$3'" "
+ ! test-wildmatch pathmatch '$2' '$3'
+ "
+ fi
+}
+
# Basic wildmat features
match 1 1 foo foo
match 0 0 foo bar
@@ -192,4 +204,19 @@ match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
+pathmatch 1 foo foo
+pathmatch 0 foo fo
+pathmatch 1 foo/bar foo/bar
+pathmatch 1 foo/bar 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/**'
+pathmatch 1 foo/bba/arr 'foo*'
+pathmatch 1 foo/bba/arr 'foo**'
+pathmatch 1 foo/bba/arr 'foo/*arr'
+pathmatch 1 foo/bba/arr 'foo/**arr'
+pathmatch 0 foo/bba/arr 'foo/*z'
+pathmatch 0 foo/bba/arr 'foo/**z'
+pathmatch 1 foo/bar 'foo?bar'
+pathmatch 1 foo/bar 'foo[/]bar'
+
test_done
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 4bb23b4..a5f4833 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,11 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
- return !!wildmatch(argv[3], argv[2], 0, NULL);
+ return !!wildmatch(argv[3], argv[2], WM_PATHNAME, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
- return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
+ return !!wildmatch(argv[3], argv[2], WM_PATHNAME | WM_CASEFOLD, NULL);
+ else if (!strcmp(argv[1], "pathmatch"))
+ return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index a79f97e..4fe1d65 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -77,14 +77,17 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
continue;
case '?':
/* Match anything but '/'. */
- if (t_ch == '/')
+ if ((flags & WM_PATHNAME) && t_ch == '/')
return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
const uchar *prev_p = p - 2;
while (*++p == '*') {}
- if ((prev_p == text || *prev_p == '/') ||
+ if (!(flags & WM_PATHNAME))
+ /* without WM_PATHNAME, '*' == '**' */
+ special = 1;
+ else if ((prev_p == text || *prev_p == '/') ||
(*p == '\0' || *p == '/' ||
(p[0] == '\\' && p[1] == '/'))) {
/*
@@ -103,7 +106,8 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
} else
return WM_ABORT_MALFORMED;
} else
- special = 0;
+ /* without WM_PATHNAME, '*' == '**' */
+ special = flags & WM_PATHNAME ? 0 : 1;
if (*p == '\0') {
/* Trailing "**" matches everything. Trailing "*" matches
* only if there are no more slash characters. */
@@ -214,7 +218,8 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
} else if (t_ch == p_ch)
matched = 1;
} while (prev_ch = p_ch, (p_ch = *++p) != ']');
- if (matched == special || t_ch == '/')
+ if (matched == special ||
+ ((flags & WM_PATHNAME) && t_ch == '/'))
return WM_NOMATCH;
continue;
}
diff --git a/wildmatch.h b/wildmatch.h
index 1c814fd..4090c8f 100644
--- a/wildmatch.h
+++ b/wildmatch.h
@@ -2,6 +2,7 @@
#define WILDMATCH_H
#define WM_CASEFOLD 1
+#define WM_PATHNAME 2
#define WM_ABORT_MALFORMED 2
#define WM_NOMATCH 1
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH 2/8] wildmatch: rename constants and update prototype
From: Nguyễn Thái Ngọc Duy @ 2012-12-22 7:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1356163028-29967-1-git-send-email-pclouds@gmail.com>
- All exported constants now have a prefix WM_
- Do not rely on FNM_* constants, use the WM_ counterparts
- Remove TRUE and FALSE to follow Git's coding style
- While at it, turn flags type from int to unsigned int
- Add an (unused yet) argument to carry extra information
so that we don't have to change the prototype again later
when we need to pass other stuff to wildmatch
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
dir.c | 3 +-
test-wildmatch.c | 4 +--
wildmatch.c | 86 +++++++++++++++++++++++++++-----------------------------
wildmatch.h | 22 ++++++++++-----
4 files changed, 61 insertions(+), 54 deletions(-)
diff --git a/dir.c b/dir.c
index cb7328b..175a182 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,8 @@ int match_pathname(const char *pathname, int pathlen,
}
return wildmatch(pattern, name,
- ignore_case ? FNM_CASEFOLD : 0) == 0;
+ ignore_case ? WM_CASEFOLD : 0,
+ NULL) == 0;
}
/* Scan the list and let the last match determine the fate.
diff --git a/test-wildmatch.c b/test-wildmatch.c
index e384c8e..4bb23b4 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,9 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
- return !!wildmatch(argv[3], argv[2], 0);
+ return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
- return !!wildmatch(argv[3], argv[2], FNM_CASEFOLD);
+ return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 3972e26..6ee1b09 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -18,9 +18,6 @@ typedef unsigned char uchar;
#define NEGATE_CLASS '!'
#define NEGATE_CLASS2 '^'
-#define FALSE 0
-#define TRUE 1
-
#define CC_EQ(class, len, litmatch) ((len) == sizeof (litmatch)-1 \
&& *(class) == *(litmatch) \
&& strncmp((char*)class, litmatch, len) == 0)
@@ -63,7 +60,7 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
int matched, special;
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
- return ABORT_ALL;
+ return WM_ABORT_ALL;
if (force_lower_case && ISUPPER(t_ch))
t_ch = tolower(t_ch);
if (force_lower_case && ISUPPER(p_ch))
@@ -76,12 +73,12 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
/* FALLTHROUGH */
default:
if (t_ch != p_ch)
- return NOMATCH;
+ return WM_NOMATCH;
continue;
case '?':
/* Match anything but '/'. */
if (t_ch == '/')
- return NOMATCH;
+ return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
@@ -100,33 +97,33 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
* both foo/bar and foo/a/bar.
*/
if (p[0] == '/' &&
- dowild(p + 1, text, force_lower_case) == MATCH)
- return MATCH;
- special = TRUE;
+ dowild(p + 1, text, force_lower_case) == WM_MATCH)
+ return WM_MATCH;
+ special = 1;
} else
- return ABORT_MALFORMED;
+ return WM_ABORT_MALFORMED;
} else
- special = FALSE;
+ special = 0;
if (*p == '\0') {
/* Trailing "**" matches everything. Trailing "*" matches
* only if there are no more slash characters. */
if (!special) {
if (strchr((char*)text, '/') != NULL)
- return NOMATCH;
+ return WM_NOMATCH;
}
- return MATCH;
+ return WM_MATCH;
}
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text, force_lower_case)) != NOMATCH) {
- if (!special || matched != ABORT_TO_STARSTAR)
+ if ((matched = dowild(p, text, force_lower_case)) != WM_NOMATCH) {
+ if (!special || matched != WM_ABORT_TO_STARSTAR)
return matched;
} else if (!special && t_ch == '/')
- return ABORT_TO_STARSTAR;
+ return WM_ABORT_TO_STARSTAR;
t_ch = *++text;
}
- return ABORT_ALL;
+ return WM_ABORT_ALL;
case '[':
p_ch = *++p;
#ifdef NEGATE_CLASS2
@@ -134,101 +131,102 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
p_ch = NEGATE_CLASS;
#endif
/* Assign literal TRUE/FALSE because of "matched" comparison. */
- special = p_ch == NEGATE_CLASS? TRUE : FALSE;
+ special = p_ch == NEGATE_CLASS;
if (special) {
/* Inverted character class. */
p_ch = *++p;
}
prev_ch = 0;
- matched = FALSE;
+ matched = 0;
do {
if (!p_ch)
- return ABORT_ALL;
+ return WM_ABORT_ALL;
if (p_ch == '\\') {
p_ch = *++p;
if (!p_ch)
- return ABORT_ALL;
+ return WM_ABORT_ALL;
if (t_ch == p_ch)
- matched = TRUE;
+ matched = 1;
} else if (p_ch == '-' && prev_ch && p[1] && p[1] != ']') {
p_ch = *++p;
if (p_ch == '\\') {
p_ch = *++p;
if (!p_ch)
- return ABORT_ALL;
+ return WM_ABORT_ALL;
}
if (t_ch <= p_ch && t_ch >= prev_ch)
- matched = TRUE;
+ matched = 1;
p_ch = 0; /* This makes "prev_ch" get set to 0. */
} else if (p_ch == '[' && p[1] == ':') {
const uchar *s;
int i;
for (s = p += 2; (p_ch = *p) && p_ch != ']'; p++) {} /*SHARED ITERATOR*/
if (!p_ch)
- return ABORT_ALL;
+ return WM_ABORT_ALL;
i = p - s - 1;
if (i < 0 || p[-1] != ':') {
/* Didn't find ":]", so treat like a normal set. */
p = s - 2;
p_ch = '[';
if (t_ch == p_ch)
- matched = TRUE;
+ matched = 1;
continue;
}
if (CC_EQ(s,i, "alnum")) {
if (ISALNUM(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "alpha")) {
if (ISALPHA(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "blank")) {
if (ISBLANK(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "cntrl")) {
if (ISCNTRL(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "digit")) {
if (ISDIGIT(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "graph")) {
if (ISGRAPH(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "lower")) {
if (ISLOWER(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "print")) {
if (ISPRINT(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "punct")) {
if (ISPUNCT(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "space")) {
if (ISSPACE(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "upper")) {
if (ISUPPER(t_ch))
- matched = TRUE;
+ matched = 1;
} else if (CC_EQ(s,i, "xdigit")) {
if (ISXDIGIT(t_ch))
- matched = TRUE;
+ matched = 1;
} else /* malformed [:class:] string */
- return ABORT_ALL;
+ return WM_ABORT_ALL;
p_ch = 0; /* This makes "prev_ch" get set to 0. */
} else if (t_ch == p_ch)
- matched = TRUE;
+ matched = 1;
} while (prev_ch = p_ch, (p_ch = *++p) != ']');
if (matched == special || t_ch == '/')
- return NOMATCH;
+ return WM_NOMATCH;
continue;
}
}
- return *text ? NOMATCH : MATCH;
+ return *text ? WM_NOMATCH : WM_MATCH;
}
/* Match the "pattern" against the "text" string. */
-int wildmatch(const char *pattern, const char *text, int flags)
+int wildmatch(const char *pattern, const char *text,
+ unsigned int flags, struct wildopts *wo)
{
return dowild((const uchar*)pattern, (const uchar*)text,
- flags & FNM_CASEFOLD ? 1 :0);
+ flags & WM_CASEFOLD ? 1 :0);
}
diff --git a/wildmatch.h b/wildmatch.h
index 984a38c..1c814fd 100644
--- a/wildmatch.h
+++ b/wildmatch.h
@@ -1,9 +1,17 @@
-/* wildmatch.h */
+#ifndef WILDMATCH_H
+#define WILDMATCH_H
-#define ABORT_MALFORMED 2
-#define NOMATCH 1
-#define MATCH 0
-#define ABORT_ALL -1
-#define ABORT_TO_STARSTAR -2
+#define WM_CASEFOLD 1
-int wildmatch(const char *pattern, const char *text, int flags);
+#define WM_ABORT_MALFORMED 2
+#define WM_NOMATCH 1
+#define WM_MATCH 0
+#define WM_ABORT_ALL -1
+#define WM_ABORT_TO_STARSTAR -2
+
+struct wildopts;
+
+int wildmatch(const char *pattern, const char *text,
+ unsigned int flags,
+ struct wildopts *wo);
+#endif
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCH 3/8] wildmatch: make dowild() take arbitrary flags
From: Nguyễn Thái Ngọc Duy @ 2012-12-22 7:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1356163028-29967-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
wildmatch.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index 6ee1b09..a79f97e 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -52,7 +52,7 @@ typedef unsigned char uchar;
#define ISXDIGIT(c) (ISASCII(c) && isxdigit(c))
/* Match pattern "p" against "text" */
-static int dowild(const uchar *p, const uchar *text, int force_lower_case)
+static int dowild(const uchar *p, const uchar *text, unsigned int flags)
{
uchar p_ch;
@@ -61,9 +61,9 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
return WM_ABORT_ALL;
- if (force_lower_case && ISUPPER(t_ch))
+ if ((flags & WM_CASEFOLD) && ISUPPER(t_ch))
t_ch = tolower(t_ch);
- if (force_lower_case && ISUPPER(p_ch))
+ if ((flags & WM_CASEFOLD) && ISUPPER(p_ch))
p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
@@ -97,7 +97,7 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
* both foo/bar and foo/a/bar.
*/
if (p[0] == '/' &&
- dowild(p + 1, text, force_lower_case) == WM_MATCH)
+ dowild(p + 1, text, flags) == WM_MATCH)
return WM_MATCH;
special = 1;
} else
@@ -116,7 +116,7 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text, force_lower_case)) != WM_NOMATCH) {
+ if ((matched = dowild(p, text, flags)) != WM_NOMATCH) {
if (!special || matched != WM_ABORT_TO_STARSTAR)
return matched;
} else if (!special && t_ch == '/')
@@ -227,6 +227,5 @@ static int dowild(const uchar *p, const uchar *text, int force_lower_case)
int wildmatch(const char *pattern, const char *text,
unsigned int flags, struct wildopts *wo)
{
- return dowild((const uchar*)pattern, (const uchar*)text,
- flags & WM_CASEFOLD ? 1 :0);
+ return dowild((const uchar*)pattern, (const uchar*)text, flags);
}
--
1.8.0.rc2.23.g1fb49df
^ 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