* Re: [PATCH] Alphabetize the fast-import options, following a suggestion on the list.
From: Junio C Hamano @ 2013-01-06 7:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Eric S. Raymond, git, David Michael Barr, Pete Wyckoff
In-Reply-To: <20130105231151.GD3247@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> My knee-jerk response was "If the options are currently organized logically,
> wouldn't it be more appropriate to add a sub-heading for each group of options
> and alphabetize only within the subgroups?"
>
> But in fact the current options list doesn't seem to be well organized at all.
> What do you think would be a logical way to group these?
>
> Features of input syntax
>
> --date-format
> --done
>
> Verbosity
>
> --quiet
> --stats
>
> Marks handling (checkpoint/restore)
>
> --import-marks
> --import-marks-if-exists
> --export-marks
> --relative-marks
>
> Semantics of execution
>
> --dry-run
> --force
> --cat-blob-fd
> --export-pack-edges
>
> Tuning
>
> --active-branches
> --max-pack-size
> --big-file-threshold
> --depth
Sounds sensible.
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Torsten Bögershausen @ 2013-01-06 7:23 UTC (permalink / raw)
To: Jason Pyeron; +Cc: git
In-Reply-To: <BB541ECCD3F04E479F06CA491DDB598D@black>
On 06.01.13 07:29, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Stephen & Linda Smith
>> Sent: Sunday, January 06, 2013 1:21
>>
>>> Was it the commit before
>>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it
>>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
>> am doing a
>>> cygwin update presently to look at it.
>>
>> Since the email earlier today, I had blown away the
>> directory. I just now
>> did the following
>>
>> git clone https://github.com/git/git.git git-src && cd
>> git-src && make all
>> ... The make errored out as before
>>
>
> No error for me.
>
>> git co 9fca6c && make all
>> ... The make errored out as before
>
> No error for me.
>
>>
>> git co 9fca6c^ && make all
>> ... and this compiles to completion
>>
>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>> i686 Cygwin
>
> This is old, do you have the luxury of updating it?
>
>>
>> What else can I do to test this out (I will get a current
>> cygwin tomorrow to use in a test).
>
> I would also check to see if your devel packages are up to date too.
You can either upgrade to cygwin 1.17 or higher.
Or, if that is really not possible (because you are sitting on a production machine,
where no changes are allowed),
You can enable this in Makefile:
CYGWIN_V15_WIN32API = YesPlease
HTH
/Torsten
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: Document how to request a patch review tag
From: Michael Haggerty @ 2013-01-06 7:32 UTC (permalink / raw)
To: Jason Holden; +Cc: gitster, git
In-Reply-To: <1357333116-6971-1-git-send-email-jason.k.holden.swdev@gmail.com>
On 01/04/2013 09:58 PM, Jason Holden wrote:
> Document the preferred way a developer should request to have their
> Acked-by/Tested-by/Reviewed-by tag to a patch series under discussion
>
> Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
> ---
> Junio,
> I was ready to add my Reviewed-by to this patch series, but I wasn't sure if
> I should email just you the patch author (to cut down on overall list traffic)
> or both you and the list. If all reviewed-by/acked-by/tested-by traffic
> should go via the email list I think this patch would be helpful, as I
> wasn't quite sure how wide of a distribution list to use for my
> "Reviewed-by" email.
>
> A very similiar question was asked previously in:
> http://thread.gmane.org/gmane.comp.version-control.git/185564/focus=185570
On 01/04/2013 10:47 PM, Junio C Hamano wrote:
> "Reviewed-by" is for those who are familiar with the part of the
> system being touched to say "I reviewed this patch, it looks good",
> and Michael indeed was involved in recent updates to the refs.c
> infrastructure, so as he said in his message "it looks like I should",
> it was the right thing to do.
>
> I do not think Michael was asking if that was the standard _thing_
> to do; I think the question was if there was a standard _way_
> (perhaps a tool) to send such a "Reviewed-by:" line.
Junio is correct; I was just asking whether there was a particular email
convention for adding a "Reviewed-by:" line. It would be nice for this
to be mentioned in the documentation.
> Documentation/SubmittingPatches | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index f6276ff..80001c9 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -268,6 +268,11 @@ If you like, you can put extra tags at the end:
> 4. "Tested-by:" is used to indicate that the person applied the patch
> and found it to have the desired effect.
>
> +If you are a reviewer and wish to add your Acked-by/Reviewed-by/Tested-by tag
> +to a patch series under discussion (after having reviewed it or tested it
> +of course!), reply to the author of the patch series, cc'ing the git mailing
> +list.
> +
> You can also create your own tag or use one that's in common usage
> such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
I don't think this is quite correct. Such emails should be
"reply-to-all" people who have participated in the thread, which might
include more than just the patch author and the git mailing list.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] clone: support atomic operation with --separate-git-dir
From: Duy Nguyen @ 2013-01-06 8:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Heiko Voigt, git, Manlio Perillo, W. Trevor King
In-Reply-To: <7vfw2eq0a0.fsf@alter.siamese.dyndns.org>
On Sun, Jan 6, 2013 at 1:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> How is the file that points at the real git dir removed with this
> fix, by the way?
It's part of the worktree cleanup, pointed by junk_work_tree. And
because junk_work_tree is not set up for --bare, I guess we still need
to fix "--bare --separate-git-dir" case, or forbid it because i'm not
sure if that case makes sense at all.
--
Duy
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: Document how to request a patch review tag
From: Junio C Hamano @ 2013-01-06 9:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jason Holden, git
In-Reply-To: <50E92875.6080305@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/04/2013 10:47 PM, Junio C Hamano wrote:
>> "Reviewed-by" is for those who are familiar with the part of the
>> system being touched to say "I reviewed this patch, it looks good",
>> and Michael indeed was involved in recent updates to the refs.c
>> infrastructure, so as he said in his message "it looks like I should",
>> it was the right thing to do.
>>
>> I do not think Michael was asking if that was the standard _thing_
>> to do; I think the question was if there was a standard _way_
>> (perhaps a tool) to send such a "Reviewed-by:" line.
>
> Junio is correct; I was just asking whether there was a particular email
> convention for adding a "Reviewed-by:" line. It would be nice for this
> to be mentioned in the documentation.
Yeah, I wasn't exactly correct in that I was talking more about
Acked-by than Reviewed-by, but they are morally very similar and the
same argument applies to both.
In the particular case of your "refs.c" review, because you are not
just familiar with the code, but essentially are the current owner
of the code, Acked-by might have been even more appropriate than
Reviewed-by, by the way.
>> +If you are a reviewer and wish to add your Acked-by/Reviewed-by/Tested-by tag
>> +to a patch series under discussion (after having reviewed it or tested it
>> +of course!), reply to the author of the patch series, cc'ing the git mailing
>> +list.
>> +
>> You can also create your own tag or use one that's in common usage
>> such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
>
> I don't think this is quite correct. Such emails should be
> "reply-to-all" people who have participated in the thread, which might
> include more than just the patch author and the git mailing list.
That would be more helpful. In practice, I can pick these up either
way, but Cc'ing everybody would be better as a common courtesy.
When the author resubmits an already reviewed patch with these Acks
and Reviews for final application, these reviewers should be Cc'ed
so that they can say "Huh? that is not the exact patch I reviewed.
What is going on?".
Thanks for a review.
^ permalink raw reply
* Re: [PATCH] clone: support atomic operation with --separate-git-dir
From: Jonathan Nieder @ 2013-01-06 9:16 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, Jens Lehmann, Heiko Voigt, git, Manlio Perillo,
W. Trevor King
In-Reply-To: <CACsJy8Dbe1+e4-XjB+S=kvXyi_Hdt4CQ6K1Z1V-4sqaYekKPWw@mail.gmail.com>
Duy Nguyen wrote:
> And
> because junk_work_tree is not set up for --bare, I guess we still need
> to fix "--bare --separate-git-dir" case, or forbid it because i'm not
> sure if that case makes sense at all.
Forbidding it makes sense to me. If some day we want a git command to
create a .git file, I don't think it should be spelled as "git clone
--bare --separate-git-dir <repo>". In the meantime,
printf '%s\n' 'gitdir: /path/to/repo' >repo.git
works fine.
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jonathan Nieder @ 2013-01-06 9:32 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Stephen & Linda Smith, Jason Pyeron, git, Mark Levedahl
In-Reply-To: <50E92675.4010907@web.de>
Hi,
Torsten Bögershausen wrote:
>> Stephen & Linda Smith wrote:
>>> git co 9fca6c && make all
>>> ... The make errored out as before
[...]
>>> git co 9fca6c^ && make all
>>> ... and this compiles to completion
>>>
>>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>>> i686 Cygwin
[...]
> You can either upgrade to cygwin 1.17 or higher.
> Or, if that is really not possible (because you are sitting on a production machine,
> where no changes are allowed),
>
> You can enable this in Makefile:
> CYGWIN_V15_WIN32API = YesPlease
What I don't understand is why commit 9fca6c would have had any
effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't
the setting to avoid including <sys/stat.h> and <sys/errno.h> be
unset both before and after that commit?
Stephen, what is the content of your config.mak?
Curious,
Jonathan
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Torsten Bögershausen @ 2013-01-06 9:42 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Mark Levedahl
In-Reply-To: <20130106093211.GB10956@elie.Belkin>
On 06.01.13 10:32, Jonathan Nieder wrote:
> Hi,
>
> Torsten Bögershausen wrote:
>>> Stephen & Linda Smith wrote:
>
>>>> git co 9fca6c && make all
>>>> ... The make errored out as before
> [...]
>>>> git co 9fca6c^ && make all
>>>> ... and this compiles to completion
>>>>
>>>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>>>> i686 Cygwin
> [...]
>> You can either upgrade to cygwin 1.17 or higher.
>> Or, if that is really not possible (because you are sitting on a production machine,
>> where no changes are allowed),
>>
>> You can enable this in Makefile:
>> CYGWIN_V15_WIN32API = YesPlease
>
> What I don't understand is why commit 9fca6c would have had any
> effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't
> the setting to avoid including <sys/stat.h> and <sys/errno.h> be
> unset both before and after that commit?
>
> Stephen, what is the content of your config.mak?
>
> Curious,
> Jonathan
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
The change in cygwin came in in 1.7.17,
(and from that version of cygwin we need commit 9fca6c to compile git)
Currently we can not compile git under cygwin 1.7.1 .. 1.7.16 :-(
As "everybody" running cygwin 1.7 seems to update to the latest,
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
/Torsten
http://git.661346.n2.nabble.com/PATCH-Rename-V15-MINGW-HEADERS-into-CYGWIN-OLD-WINSOCK-HEADERS-td7571449.html
^ permalink raw reply
* [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Nguyễn Thái Ngọc Duy @ 2013-01-06 9:47 UTC (permalink / raw)
To: Jonathan Niedier
Cc: git, Junio C Hamano, Jens Lehmann, Heiko Voigt, Manlio Perillo,
W. Trevor King, Nguyễn Thái Ngọc Duy
In-Reply-To: <20130106091642.GA10956@elie.Belkin>
--separate-git-dir was added to clone with the repository away from
standard position <worktree>/.git. It does not make sense to use it
without creating working directory.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Sun, Jan 6, 2013 at 4:16 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Duy Nguyen wrote:
>
>> And
>> because junk_work_tree is not set up for --bare, I guess we still need
>> to fix "--bare --separate-git-dir" case, or forbid it because i'm not
>> sure if that case makes sense at all.
>
> Forbidding it makes sense to me. If some day we want a git command to
> create a .git file, I don't think it should be spelled as "git clone
> --bare --separate-git-dir <repo>".
That command does not work because --separate-git-dir requires an
argument in addition to <repo>, which is taken as the target repo.
Still it's hard to find a use case for
git clone --bare --separate-git-dir <real-repo> <symlink-repo>
> In the meantime,
>
> printf '%s\n' 'gitdir: /path/to/repo' >repo.git
>
> works fine.
Yeah. A separate clone operation following by that printf should be
clearer.
builtin/clone.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index ec2f75b..360e430 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -704,6 +704,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_origin)
die(_("--bare and --origin %s options are incompatible."),
option_origin);
+ if (real_git_dir)
+ /*
+ * If you lift this restriction, remember to
+ * clean .git in this case in remove_junk_on_signal
+ */
+ die(_("--bare and --separate-git-dir are incompatible."));
option_no_checkout = 1;
}
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jonathan Nieder @ 2013-01-06 9:57 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Stephen & Linda Smith, Jason Pyeron, git, Mark Levedahl,
Eric Blake
In-Reply-To: <50E946EB.1000709@web.de>
Torsten Bögershausen wrote:
> The short version:
> Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
> I don't know if we want to improve the Makefile to enable
> CYGWIN_V15_WIN32API = YesPlease
> for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
Confusing. Sounds like the condition in 380a4d92 (Update cygwin.c for
new mingw-64 win32 api headers, 2012-11-11) was too strict and the
Makefile should say something like
# Cygwin versions up to 1.7.16 used the same headers
# as Cygwin 1.5.
ifeq ($(shell expr "$(uname_R)" : '1\.7\.[0-9]$$'),5)
CYGWIN_V15_WIN32API = YesPlease
endif
ifeq ($(shell expr "$(uname_R)" : '1\.7\.1[0-6]$$'),6)
CYGWIN_V15_WIN32API = YesPlease
endif
ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
CYGWIN_V15_WIN32API = YesPlease
...
endif
Is that right?
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Jonathan Nieder @ 2013-01-06 10:19 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Jens Lehmann, Heiko Voigt, Manlio Perillo,
W. Trevor King
In-Reply-To: <1357465670-32766-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> --separate-git-dir was added to clone with the repository away from
> standard position <worktree>/.git. It does not make sense to use it
> without creating working directory.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The patch correctly implements the above. The description leaves out
detail. I'd say something like
The --separate-git-dir option was introduced to make it simple
to put the git directory somewhere outside the worktree, for
example when cloning a repository for use as a submodule.
It was not intended for use when creating a bare repository.
In that case there is no worktree and it is more natural to
directly clone the repository and create a .git file as
separate steps:
git clone --bare /path/to/repo.git bar.git
printf 'gitdir: bar.git\n' >foo.git
Unfortunately we forgot to forbid the --bare
--separate-git-dir combination. In practice, we know no one
could be using --bare with --separate-git-dir because it is
broken in the following way: <explanation here>. So it is
safe to make good on our mistake and forbid the combination,
making the command easier to explain.
I don't know what would go in the <explanation here> blank above,
though. Is it possible that some people are relying on this option
combination?
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Michael Haggerty @ 2013-01-06 11:15 UTC (permalink / raw)
To: esr
Cc: Max Horn, Yann Dirson, Heiko Voigt, Antoine Pelisse, Bart Massey,
Keith Packard, David Mansfield, git
In-Reply-To: <20130105151106.GA1938@thyrsus.com>
On 01/05/2013 04:11 PM, Eric S. Raymond wrote:
> Perhaps I was unclear. I consider the interface design error to
> be not in the fact that all the blobs are written first or detached,
> but rather that the implementation detail of the two separate journal
> files is ever exposed.
>
> I understand why the storage of intermediate results was done this
> way, in order to decrease the tool's working set during the run, but
> finishing by automatically concatenating the results and streaming
> them to stdout would surely have been the right thing here.
cvs2svn/cvs2git is built to be able to handle very large CVS
repositories, not only those that can fit in RAM. This goal influences
a lot of its design, including the pass-by-pass structure with
intermediate databases and the resumability of passes.
The blobfile necessarily contains every version of every file, with no
delta-encoding and no compression. Its size can be a large multiple of
the on-disk size of the original CVS repository. If the "save to
tempfiles then cat tempfiles at end of run" behavior were hard-coded
into cvs2git, then there would be no way to avoid requiring enough
temporary space to hold the whole blobfile.
Writing the blobfile into a separate file, on the other hand, means that
for example the blobfile could be written into a named pipe connected to
the standard input of "git fast-import" [1]. "git fast-import" could
even be run on a remote server.
I consider these bigger advantages than the ability to pipe the output
of cvs2git directly into another command.
> The downstream cost of letting the journalling implementation be
> exposed, instead, can be seen in this snippet from the new git-cvsimport
> I've been working on:
>
> def command(self):
> "Emit the command implied by all previous options."
> return "(cvs2git --username=git-cvsimport --quiet --quiet --blobfile={0} --dumpfile={1} {2} {3} && cat {0} {1} && rm {0} {1})".format(tempfile.mkstemp()[1], tempfile.mkstemp()[1], self.opts, self.modulepath)
>
> According to the documentation, every caller of csv2git must go
> through analogous contortions! This is not the Unix way; if Unix
> design principles had been minimally applied, that second line would
> just read like this:
>
> return "cvs2git --username=git-cvsimport --quiet --quiet"
Never in my worst nightmares did I imagine that my terrible design taste
would force you to type an extra two lines of code. Oh the humanity!
By the way, patches are welcome. And you don't need to trumpet their
imminent arrival [2] or malign the existing code beforehand. Moreover,
it would be adequate if you just demonstrate working code and *then* ask
for "sign-in", rather than the other way around.
> If Unix design principles had been thoroughly applied, the "--quiet
> --quiet" part would be unnecessary too - well-behaved Unix commands
> *default* to being completely quiet unless either (a) they have an
> exceptional condition to report, or (b) their expected running time is
> so long that tasteful silence would leave users in doubt that they're
> working.
cvs2git is not a command that one uses 100 times a day. It is a tool
for one-shot conversions of CVS repositories to git. These conversions
can take hours or even days of processing time (not to mention the time
for configuring the conversion and changing the rest of a project's
infrastructure from CVS to git). So yes, I think we would like to
appeal to (b) and humbly ask for your permission to give the user some
feedback during the conversion.
> (And yes, I do think violating these principles is a lapse of taste when
> git tools do it, too.)
>
> Michael Haggerty wants me to trust that cvs2git's analysis stage has
> been fixed, but I must say that is a more difficult leap of faith when
> two of the most visible things about it are still (a) a conspicuous
> instance of interface misdesign, and (b) documentation that is careless and
> incomplete.
The cvs2git documentation is lacking; I admit it (as opposed to the
cvs2svn documentation, which I think is quite complete). And the
program itself also has a lot of rough edges, for example its inability
to convert .cvsignore files into .gitignore files. Patches are welcome.
I haven't used cvs2svn for my own purposes in many years and I've
*never* once had a need to use cvs2git; I maintain these programs purely
as a service to the community. Most of the community seems satisfied
with the programs as they are, and if not they usually submit courteous
and concrete bug reports or submit patches.
I request that you follow their example. I especially ask that you
restrain from spreading public FUD about imagined problems based on
speculation. Please do your tests and *then* report any problems that
you find.
Yours,
Michael
[1] In fact, the current implementation of generate_blobs.py sometimes
seeks back to earlier parts of the blob file when it needs the fulltext
of a revision that has already been output, but this would be easy to
change as soon as somebody needs it.
[2] http://comments.gmane.org/gmane.comp.version-control.git/212340
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Mark Levedahl @ 2013-01-06 11:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Eric Blake
In-Reply-To: <20130106095757.GC10956@elie.Belkin>
On 01/06/2013 04:57 AM, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
>
>> The short version:
>> Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
> [...]
>> I don't know if we want to improve the Makefile to enable
>> CYGWIN_V15_WIN32API = YesPlease
>> for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
>>
You are conflating the cygwin dll version with the win32 api version.
These are independent packages (just as the kernel and glibc packages
are independent on linux) and do not share a version number. However,
the newer win32api is provided only for the current cygwin release
series, which can be reliably identified by having dll version 1.7.x,
while the older frozen releases (dll versions 1.6.x from redhat, 1.5.x
open source) still have the older api as no updates are being made for
the legacy version(s).
Cygwin does not version the win32api in any useful way: the package
names changed completely, for instance, and there is no macro defined
from the header files to indicate a version number. Also, there is no
supported way to now install the older version: the only supported
configuration is with the *current* win32api: multiple packages depend
by name on the current win32api package, so the installer will insist
upon its installation.
So the solution is to update the cygwin installation. Really. If you
don't believe me, try asking on the cygwin mailing list. They only
support the current releases, not obsolete packages, and the older
win32api is explicitly obsolete.
Mark
^ permalink raw reply
* [PATCH] docs: manpage XML depends on asciidoc.conf
From: Jonathan Nieder @ 2013-01-06 12:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, git, Sergey Vlasov, Thomas Ackermann
In-Reply-To: <7vbod2pzxd.fsf@alter.siamese.dyndns.org>
When building manual pages, the source text is transformed to XML with
AsciiDoc before the man pages are generated from the XML with xmlto.
Fix the dependencies in the Makefile so that the XML files are rebuilt
when asciidoc.conf changes and not just the manual pages from
unchanged XML, and move the dependencies from a recipeless rule to the
rules with commands that use asciidoc.conf to make the dependencies
easier to understand and maintain.
Reported-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Care to do a real patch?
Here you go.
Documentation/Makefile | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e53d333e..971977b8 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -178,8 +178,6 @@ all: html man
html: $(DOC_HTML)
-$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
-
man: man1 man5 man7
man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
@@ -257,7 +255,7 @@ clean:
$(RM) $(cmds_txt) *.made
$(RM) manpage-base-url.xsl
-$(MAN_HTML): %.html : %.txt
+$(MAN_HTML): %.html : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
@@ -270,7 +268,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in
$(QUIET_XMLTO)$(RM) $@ && \
$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
-%.xml : %.txt
+%.xml : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
@@ -286,7 +284,7 @@ technical/api-index.txt: technical/api-index-skel.txt \
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
-$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt
+$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt asciidoc.conf
$(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
--
1.8.1
^ permalink raw reply related
* Re: [PATCH v3 02/19] Improve documentation and comments regarding directory traversal API
From: Adam Spiers @ 2013-01-06 12:02 UTC (permalink / raw)
To: git list
In-Reply-To: <CAOkDyE_DX8iAAd5ubJaQ_guPQ-PSz4-sFETZoRf7JRTrH6Qcpw@mail.gmail.com>
On Wed, Jan 02, 2013 at 12:54:19PM +0000, Adam Spiers wrote:
> On Tue, Jan 1, 2013 at 8:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Adam Spiers <git@adamspiers.org> writes:
> >> diff --git a/dir.c b/dir.c
> >> index ee8e711..89e27a6 100644
> >> --- a/dir.c
> >> +++ b/dir.c
> >> @@ -2,6 +2,8 @@
> >> * This handles recursive filename detection with exclude
> >> * files, index knowledge etc..
> >> *
> >> + * See Documentation/technical/api-directory-listing.txt
> >> + *
> >> * Copyright (C) Linus Torvalds, 2005-2006
> >> * Junio Hamano, 2005-2006
> >> */
> >> @@ -476,6 +478,10 @@ void add_excludes_from_file(struct dir_struct *dir, const char *fname)
> >> die("cannot use %s as an exclude file", fname);
> >> }
> >>
> >> +/*
> >> + * Loads the per-directory exclude list for the substring of base
> >> + * which has a char length of baselen.
> >> + */
> >> static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)
> >> {
> >> struct exclude_list *el;
> >> @@ -486,7 +492,7 @@ static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)
> >> (baselen + strlen(dir->exclude_per_dir) >= PATH_MAX))
> >> return; /* too long a path -- ignore */
> >>
> >> - /* Pop the ones that are not the prefix of the path being checked. */
> >> + /* Pop the directories that are not the prefix of the path being checked. */
> >
> > The "one" does not refer to a "directory", but to an "exclude-list".
>
> No, if that was the case, it would mean that multiple exclude lists
> would be popped, but that is not the case here (prior to v4).
Sorry, I meant prior to v3 11/19.
> > Pop the ones that are not for parent directories of the path
> > being checked
>
> Better would be:
>
> Pop the entries within the EXCL_DIRS exclude list which originate
> from directories not in the prefix of the path being checked.
>
> although as previously stated, the v4 series I have been holding off
> from submitting (in order not to distract you from a maint release)
> actually changes this behaviour so EXCL_DIRS becomes an exclude_group of
> multiple exclude_lists, one per directory. So in v4, multiple
> exclude_lists *will* be popped. I'll tweak the comment in v4 to make
> this clear.
Again, I got confused and forgot that I already included the switch to
exclude_list_groups as v3 11/19. But since the patch being discussed
here is v3 02/19 which precedes it, everything I said still applies.
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jonathan Nieder @ 2013-01-06 12:09 UTC (permalink / raw)
To: Mark Levedahl
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Eric Blake
In-Reply-To: <50E9647F.4090209@gmail.com>
Mark Levedahl wrote:
> However, the newer
> win32api is provided only for the current cygwin release series, which can
> be reliably identified by having dll version 1.7.x, while the older frozen
> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
> older api as no updates are being made for the legacy version(s).
Ah. That makes sense, thanks.
(For the future, if we wanted to diagnose an out-of-date win32api and
print a helpful message, I guess cygcheck would be the command to use.)
^ permalink raw reply
* Re: [PATCH] docs: manpage XML depends on asciidoc.conf
From: John Keeping @ 2013-01-06 12:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Sergey Vlasov, Thomas Ackermann
In-Reply-To: <20130106120153.GB22081@elie.Belkin>
On Sun, Jan 06, 2013 at 04:01:53AM -0800, Jonathan Nieder wrote:
> When building manual pages, the source text is transformed to XML with
> AsciiDoc before the man pages are generated from the XML with xmlto.
>
> Fix the dependencies in the Makefile so that the XML files are rebuilt
> when asciidoc.conf changes and not just the manual pages from
> unchanged XML, and move the dependencies from a recipeless rule to the
> rules with commands that use asciidoc.conf to make the dependencies
> easier to understand and maintain.
>
> Reported-by: John Keeping <john@keeping.me.uk>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
This fixes the problem I wanted to fix (as well as being clearer for the
future), so FWIW:
Tested-by: John Keeping <john@keeping.me.uk>
^ permalink raw reply
* [PATCH] git-fast-import(1): reorganise options
From: John Keeping @ 2013-01-06 13:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Eric S. Raymond, git, David Michael Barr,
Pete Wyckoff
In-Reply-To: <7vy5g6okdi.fsf@alter.siamese.dyndns.org>
On Sat, Jan 05, 2013 at 11:12:25PM -0800, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> But in fact the current options list doesn't seem to be well organized at all.
>> What do you think would be a logical way to group these?
>>
>> Features of input syntax
>>
>> --date-format
>> --done
>>
>> Verbosity
>>
>> --quiet
>> --stats
>>
>> Marks handling (checkpoint/restore)
>>
>> --import-marks
>> --import-marks-if-exists
>> --export-marks
>> --relative-marks
>>
>> Semantics of execution
>>
>> --dry-run
>> --force
>> --cat-blob-fd
>> --export-pack-edges
>>
>> Tuning
>>
>> --active-branches
>> --max-pack-size
>> --big-file-threshold
>> --depth
>
> Sounds sensible.
How about this?
I left the "Semantics of execution" options with the general options
since I couldn't think of a sensible heading that didn't also apply to
'--quiet' or '--stats', but I think the result is reasonable.
-- <8 --
The options in git-fast-import(1) are not currently arranged in a
logical order, which has caused the '--done' options to be documented
twice (commit 3266de10).
Rearrange them into logical groups under subheadings.
While doing this, fix the duplicate '--done' documentation by taking the
best bits of each. Also combine the descriptions of '--relative-marks'
and '--no-relative-marks' since they make more sense together.
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
---
Documentation/git-fast-import.txt | 115 +++++++++++++++++++-------------------
1 file changed, 59 insertions(+), 56 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 68bca1a..0e25c8d 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -33,38 +33,55 @@ the frontend program in use.
OPTIONS
-------
---date-format=<fmt>::
- Specify the type of dates the frontend will supply to
- fast-import within `author`, `committer` and `tagger` commands.
- See ``Date Formats'' below for details about which formats
- are supported, and their syntax.
--- done::
- Terminate with error if there is no 'done' command at the
- end of the stream.
+--quiet::
+ Disable all non-fatal output, making fast-import silent when it
+ is successful. This option disables the output shown by
+ \--stats.
+
+--stats::
+ Display some basic statistics about the objects fast-import has
+ created, the packfiles they were stored into, and the
+ memory used by fast-import during this run. Showing this output
+ is currently the default, but can be disabled with \--quiet.
--force::
Force updating modified existing branches, even if doing
so would cause commits to be lost (as the new commit does
not contain the old commit).
---max-pack-size=<n>::
- Maximum size of each output packfile.
- The default is unlimited.
+--cat-blob-fd=<fd>::
+ Write responses to `cat-blob` and `ls` queries to the
+ file descriptor <fd> instead of `stdout`. Allows `progress`
+ output intended for the end-user to be separated from other
+ output.
---big-file-threshold=<n>::
- Maximum size of a blob that fast-import will attempt to
- create a delta for, expressed in bytes. The default is 512m
- (512 MiB). Some importers may wish to lower this on systems
- with constrained memory.
+--export-pack-edges=<file>::
+ After creating a packfile, print a line of data to
+ <file> listing the filename of the packfile and the last
+ commit on each branch that was written to that packfile.
+ This information may be useful after importing projects
+ whose total object set exceeds the 4 GiB packfile limit,
+ as these commits can be used as edge points during calls
+ to 'git pack-objects'.
---depth=<n>::
- Maximum delta depth, for blob and tree deltification.
- Default is 10.
+Options related to the input stream
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---active-branches=<n>::
- Maximum number of branches to maintain active at once.
- See ``Memory Utilization'' below for details. Default is 5.
+--date-format=<fmt>::
+ Specify the type of dates the frontend will supply to
+ fast-import within `author`, `committer` and `tagger` commands.
+ See ``Date Formats'' below for details about which formats
+ are supported, and their syntax.
+
+--done::
+ Terminate with error if there is no `done` command at the end of
+ the stream. This option might be useful for detecting errors
+ that cause the frontend to terminate before it has started to
+ write a stream.
+
+Options related to marks
+~~~~~~~~~~~~~~~~~~~~~~~~
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
@@ -87,51 +104,37 @@ OPTIONS
Like --import-marks but instead of erroring out, silently
skips the file if it does not exist.
---relative-marks::
+--[no-]relative-marks::
After specifying --relative-marks the paths specified
with --import-marks= and --export-marks= are relative
to an internal directory in the current repository.
In git-fast-import this means that the paths are relative
to the .git/info/fast-import directory. However, other
importers may use a different location.
++
+Relative and non-relative marks may be combined by interweaving
+--(no-)-relative-marks with the --(import|export)-marks= options.
---no-relative-marks::
- Negates a previous --relative-marks. Allows for combining
- relative and non-relative marks by interweaving
- --(no-)-relative-marks with the --(import|export)-marks=
- options.
+Options for tuning
+~~~~~~~~~~~~~~~~~~
---cat-blob-fd=<fd>::
- Write responses to `cat-blob` and `ls` queries to the
- file descriptor <fd> instead of `stdout`. Allows `progress`
- output intended for the end-user to be separated from other
- output.
-
---done::
- Require a `done` command at the end of the stream.
- This option might be useful for detecting errors that
- cause the frontend to terminate before it has started to
- write a stream.
+--active-branches=<n>::
+ Maximum number of branches to maintain active at once.
+ See ``Memory Utilization'' below for details. Default is 5.
---export-pack-edges=<file>::
- After creating a packfile, print a line of data to
- <file> listing the filename of the packfile and the last
- commit on each branch that was written to that packfile.
- This information may be useful after importing projects
- whose total object set exceeds the 4 GiB packfile limit,
- as these commits can be used as edge points during calls
- to 'git pack-objects'.
+--big-file-threshold=<n>::
+ Maximum size of a blob that fast-import will attempt to
+ create a delta for, expressed in bytes. The default is 512m
+ (512 MiB). Some importers may wish to lower this on systems
+ with constrained memory.
---quiet::
- Disable all non-fatal output, making fast-import silent when it
- is successful. This option disables the output shown by
- \--stats.
+--depth=<n>::
+ Maximum delta depth, for blob and tree deltification.
+ Default is 10.
---stats::
- Display some basic statistics about the objects fast-import has
- created, the packfiles they were stored into, and the
- memory used by fast-import during this run. Showing this output
- is currently the default, but can be disabled with \--quiet.
+--max-pack-size=<n>::
+ Maximum size of each output packfile.
+ The default is unlimited.
Performance
--
1.8.0.2
^ permalink raw reply related
* [PATCH/RFC] fast-import doc: split OPTIONS into subsections
From: Jonathan Nieder @ 2013-01-06 13:34 UTC (permalink / raw)
To: git
Cc: John Keeping, Eric S. Raymond, David Michael Barr, Pete Wyckoff,
Thomas Rast
In-Reply-To: <20130105231151.GD3247@elie.Belkin>
The OPTIONS section of this manpage has grown long without any
particular organization to ensure it remains manageable. Split into
categories to make the documentation for each option easier to find.
The categories:
1. Features of the input format, such as the date format and whether
the file is required to end with a "done" command.
2. How much output the importer should write to stderr.
3. Marks Handling (Checkpoint/Restart).
4. Other options that change the behavior in a semantically
meaningful way (backflow pipe setup, whether to force ref
updates, where to list pack edges).
5. Performance and compression tuning.
Reported-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
The second-to-last subsection ("Import Semantics") is kind of a
catch-all. Better ideas for organization or naming would be
welcome.
Documentation/git-fast-import.txt | 82 ++++++++++++++++++++++-----------------
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index d2c0e357..1676d436 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -32,35 +32,36 @@ the frontend program in use.
OPTIONS
-------
+Input Syntax
+~~~~~~~~~~~~
--date-format=<fmt>::
Specify the type of dates the frontend will supply to
fast-import within `author`, `committer` and `tagger` commands.
See ``Date Formats'' below for details about which formats
are supported, and their syntax.
---force::
- Force updating modified existing branches, even if doing
- so would cause commits to be lost (as the new commit does
- not contain the old commit).
+--done::
+ Terminate with error if there is no 'done' command at the
+ end of the stream.
+ This option might be useful for detecting errors that
+ cause the frontend to terminate before it has started to
+ write a stream.
---max-pack-size=<n>::
- Maximum size of each output packfile.
- The default is unlimited.
+Verbosity
+~~~~~~~~~
+--quiet::
+ Disable all non-fatal output, making fast-import silent when it
+ is successful. This option disables the output shown by
+ \--stats.
---big-file-threshold=<n>::
- Maximum size of a blob that fast-import will attempt to
- create a delta for, expressed in bytes. The default is 512m
- (512 MiB). Some importers may wish to lower this on systems
- with constrained memory.
-
---depth=<n>::
- Maximum delta depth, for blob and tree deltification.
- Default is 10.
-
---active-branches=<n>::
- Maximum number of branches to maintain active at once.
- See ``Memory Utilization'' below for details. Default is 5.
+--stats::
+ Display some basic statistics about the objects fast-import has
+ created, the packfiles they were stored into, and the
+ memory used by fast-import during this run. Showing this output
+ is currently the default, but can be disabled with \--quiet.
+Marks Handling (Checkpoint/Restart)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
@@ -96,18 +97,18 @@ OPTIONS
--(no-)-relative-marks with the --(import|export)-marks=
options.
+Import Semantics
+~~~~~~~~~~~~~~~~
+--force::
+ Force updating modified existing branches, even if doing
+ so would cause commits to be lost (as the new commit does
+ not contain the old commit).
+
--cat-blob-fd=<fd>::
Specify the file descriptor that will be written to
when the `cat-blob` command is encountered in the stream.
The default behaviour is to write to `stdout`.
---done::
- Terminate with error if there is no 'done' command at the
- end of the stream.
- This option might be useful for detecting errors that
- cause the frontend to terminate before it has started to
- write a stream.
-
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
<file> listing the filename of the packfile and the last
@@ -117,16 +118,25 @@ OPTIONS
as these commits can be used as edge points during calls
to 'git pack-objects'.
---quiet::
- Disable all non-fatal output, making fast-import silent when it
- is successful. This option disables the output shown by
- \--stats.
+Tuning
+~~~~~~
+--max-pack-size=<n>::
+ Maximum size of each output packfile.
+ The default is unlimited.
---stats::
- Display some basic statistics about the objects fast-import has
- created, the packfiles they were stored into, and the
- memory used by fast-import during this run. Showing this output
- is currently the default, but can be disabled with \--quiet.
+--big-file-threshold=<n>::
+ Maximum size of a blob that fast-import will attempt to
+ create a delta for, expressed in bytes. The default is 512m
+ (512 MiB). Some importers may wish to lower this on systems
+ with constrained memory.
+
+--depth=<n>::
+ Maximum delta depth, for blob and tree deltification.
+ Default is 10.
+
+--active-branches=<n>::
+ Maximum number of branches to maintain active at once.
+ See ``Memory Utilization'' below for details. Default is 5.
Performance
--
1.8.1
^ permalink raw reply related
* Re: [PATCH] git-fast-import(1): reorganise options
From: Jonathan Nieder @ 2013-01-06 13:51 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Eric S. Raymond, git, David Michael Barr,
Pete Wyckoff, Thomas Rast
In-Reply-To: <20130106132915.GG6440@serenity.lan>
John Keeping wrote:
> How about this?
Ah, our patches crossed.
> I left the "Semantics of execution" options with the general options
> since I couldn't think of a sensible heading
Neat trick. :)
[...]
> -- <8 --
> The options in git-fast-import(1) are not currently arranged in a
> logical order, which has caused the '--done' options to be documented
> twice (commit 3266de10).
>
> Rearrange them into logical groups under subheadings.
Nice description.
> While doing this, fix the duplicate '--done' documentation by taking the
> best bits of each. Also combine the descriptions of '--relative-marks'
> and '--no-relative-marks' since they make more sense together.
I'd prefer to keep those as separate patches, if that's manageable.
The organization you propose is:
OPTIONS
-------
--quiet
--stats
--force
--cat-blob-fd
--export-pack-edges
Options related to the input stream
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--date-format
--done
Options related to marks
~~~~~~~~~~~~~~~~~~~~~~~~
--export-marks
--import-marks
--import-marks-if-exists
--relative-marks
--no-relative-marks
Options for tuning
~~~~~~~~~~~~~~~~~~
--active-branches
--big-file-threshold
--depth
--max-pack-size
These headings are less cryptic than the ones I proposed, which is a
nice thing.
My only nitpicks:
I'd worry that the catch-all toplevel category would grow larger
and larger with time, since it's the obvious place to put any new
option.
Part of what I tried to do with the proposed categorization was to
separate options that change the semantics of the import (which one
uses with "feature" when they are specified in the fast-import stream
since ignoring them results in a broken import) from options that only
change superficial aspects of the interface or the details of how the
resulting packfiles representing the same objects get written.
The phrasing of the name of the category "Options related to the input
stream" is too broad. All options relate to the input stream, since
consuming an input stream and acting on it is all fast-import does.
Something more specific than "related to" and a mention of "syntax"
could make it clearer --- how about something like "Input Syntax
Features"?
Likewise, lots of functionality is _related_ to marks, but the marks
options are the options that specify marks files. I don't know a good
way to say that --- maybe "Location of Marks Files"?
"Options for Tuning" could also be made more specific --- e.g.,
"Performance and Compression Tuning".
I like how you put important options like --force on top. Perhaps
the less important --quiet and --stats could be split off from that
into a subsection like "Verbosity" to make them stand out even more.
Generally I think this is a better starting point for future work than
the patch I sent. Thanks for writing it.
Jonathan
^ permalink raw reply
* [PATCH jk/pathspec-literal] t6130-pathspec-noglob: Windows does not allow a file named "f*"
From: Johannes Sixt @ 2013-01-06 14:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List, msysGit
Windows disallows file names that contain a star. Arrange the test setup
to insert the file name "f*" in the repository without the corresponding
file in the worktree.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t6130-pathspec-noglob.sh | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/t/t6130-pathspec-noglob.sh b/t/t6130-pathspec-noglob.sh
index bb5e710..39ef619 100755
--- a/t/t6130-pathspec-noglob.sh
+++ b/t/t6130-pathspec-noglob.sh
@@ -6,7 +6,13 @@ test_description='test globbing (and noglob) of pathspec limiting'
test_expect_success 'create commits with glob characters' '
test_commit unrelated bar &&
test_commit vanilla foo &&
- test_commit star "f*" &&
+ # insert file "f*" in the commit, but in a way that avoids
+ # the name "f*" in the worktree, because it is not allowed
+ # on Windows (the tests below do not depend on the presence
+ # of the file in the worktree)
+ git update-index --add --cacheinfo 100644 "$(git rev-parse HEAD:foo)" "f*" &&
+ test_tick &&
+ git commit -m star &&
test_commit bracket "f[o][o]"
'
--
1.8.1.1672.g5e2a3d4.dirty
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Stephen & Linda Smith @ 2013-01-06 14:09 UTC (permalink / raw)
To: ischis2
Cc: Jonathan Nieder, Mark Levedahl, Jason Pyeron, Eric Blake, git,
Torsten Bögershausen
In-Reply-To: <20130106120917.GC22081@elie.Belkin>
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote:
> Mark Levedahl wrote:
> > However, the
> > newer
> >
> > win32api is provided only for the current cygwin release series, which can
> > be reliably identified by having dll version 1.7.x, while the older frozen
> > releases (dll versions 1.6.x from redhat, 1.5.x open source) still have
> > the
> > older api as no updates are being made for the legacy version(s).
>
> Ah. That makes sense, thanks.
>
> (For the future, if we wanted to diagnose an out-of-date win32api and
> print a helpful message, I guess cygcheck would be the command to use.)
Thank you for the information. I will update my cygwin installation.
^ permalink raw reply
* Re: [PATCH] git-fast-import(1): reorganise options
From: John Keeping @ 2013-01-06 14:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Eric S. Raymond, git, David Michael Barr,
Pete Wyckoff, Thomas Rast
In-Reply-To: <20130106135109.GF22081@elie.Belkin>
On Sun, Jan 06, 2013 at 05:51:09AM -0800, Jonathan Nieder wrote:
> John Keeping wrote:
>> I left the "Semantics of execution" options with the general options
>> since I couldn't think of a sensible heading
>
> Neat trick. :)
I took inspiration from git-pull(1), which has a few general options
followed by several "Options related to..." sections.
> [...]
> > -- <8 --
> > The options in git-fast-import(1) are not currently arranged in a
> > logical order, which has caused the '--done' options to be documented
> > twice (commit 3266de10).
> >
> > Rearrange them into logical groups under subheadings.
>
> Nice description.
>
> > While doing this, fix the duplicate '--done' documentation by taking the
> > best bits of each. Also combine the descriptions of '--relative-marks'
> > and '--no-relative-marks' since they make more sense together.
>
> I'd prefer to keep those as separate patches, if that's manageable.
I'll send a series of three patches if the discussion below seems
reasonable:
[1/3] remove duplicate '--done'
[2/3] combine --[no-]relative-marks
[3/3] reorganize options
> The organization you propose is:
>
> OPTIONS
> -------
> --quiet
> --stats
> --force
> --cat-blob-fd
> --export-pack-edges
>
> Options related to the input stream
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --date-format
> --done
>
> Options related to marks
> ~~~~~~~~~~~~~~~~~~~~~~~~
> --export-marks
> --import-marks
> --import-marks-if-exists
> --relative-marks
> --no-relative-marks
>
> Options for tuning
> ~~~~~~~~~~~~~~~~~~
> --active-branches
> --big-file-threshold
> --depth
> --max-pack-size
>
> These headings are less cryptic than the ones I proposed, which is a
> nice thing.
>
> My only nitpicks:
>
> I'd worry that the catch-all toplevel category would grow larger
> and larger with time, since it's the obvious place to put any new
> option.
I agree that that's a concern, perhaps '--cat-blob-fd' should be
combined with '--date-format' and '--done' into a section called
"Options for frontends" or similar?
And maybe '--export-pack-edges' can move to the performance/compression
tuning section? I expect the interested audience would be the same.
That only leaves three options in that section, which seems more
reasonable.
> Part of what I tried to do with the proposed categorization was to
> separate options that change the semantics of the import (which one
> uses with "feature" when they are specified in the fast-import stream
> since ignoring them results in a broken import) from options that only
> change superficial aspects of the interface or the details of how the
> resulting packfiles representing the same objects get written.
>
> The phrasing of the name of the category "Options related to the input
> stream" is too broad. All options relate to the input stream, since
> consuming an input stream and acting on it is all fast-import does.
> Something more specific than "related to" and a mention of "syntax"
> could make it clearer --- how about something like "Input Syntax
> Features"?
>
> Likewise, lots of functionality is _related_ to marks, but the marks
> options are the options that specify marks files. I don't know a good
> way to say that --- maybe "Location of Marks Files"?
>
> "Options for Tuning" could also be made more specific --- e.g.,
> "Performance and Compression Tuning".
I realise it's personal taste, but I like the subheadings of the form
"Options (for|related to) ...", so maybe:
Options for input stream features
Options related to marks files
Options for performance and compression tuning
Note that I chose sentence case instead of title case to be consistent
with git-pull(1).
> I like how you put important options like --force on top. Perhaps
> the less important --quiet and --stats could be split off from that
> into a subsection like "Verbosity" to make them stand out even more.
I quite like having the verbosity options near the top since those are
the ones that are most likely to be of interest to a user, whereas the
rest are likely to be prescribed by the frontend (or only really useful
to frontend authors).
John
^ permalink raw reply
* Re: [PATCH jk/pathspec-literal] t6130-pathspec-noglob: Windows does not allow a file named "f*"
From: Jeff King @ 2013-01-06 14:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, msysGit
In-Reply-To: <50E9852F.2060005@kdbg.org>
On Sun, Jan 06, 2013 at 03:07:43PM +0100, Johannes Sixt wrote:
> Windows disallows file names that contain a star. Arrange the test setup
> to insert the file name "f*" in the repository without the corresponding
> file in the worktree.
> [...]
> - test_commit star "f*" &&
> + # insert file "f*" in the commit, but in a way that avoids
> + # the name "f*" in the worktree, because it is not allowed
> + # on Windows (the tests below do not depend on the presence
> + # of the file in the worktree)
> + git update-index --add --cacheinfo 100644 "$(git rev-parse HEAD:foo)" "f*" &&
> + test_tick &&
> + git commit -m star &&
Thanks, looks obviously correct to me.
Sorry to break Windows again. It seems I learn about a new gotcha with
every patch series. :)
-Peff
^ permalink raw reply
* Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
From: Adam Spiers @ 2013-01-06 15:20 UTC (permalink / raw)
To: git list
In-Reply-To: <7v1ue0veww.fsf@alter.siamese.dyndns.org>
On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
> > diff --git a/builtin/clean.c b/builtin/clean.c
> > index 0c7b3d0..bd18b88 100644
> > --- a/builtin/clean.c
> > +++ b/builtin/clean.c
> > @@ -97,9 +97,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> > if (!ignored)
> > setup_standard_excludes(&dir);
> >
> > + add_exclude_list(&dir, EXC_CMDL);
> > for (i = 0; i < exclude_list.nr; i++)
> > add_exclude(exclude_list.items[i].string, "", 0,
> > - &dir.exclude_list[EXC_CMDL]);
> > + &dir.exclude_list_groups[EXC_CMDL].ary[0]);
>
> This looks somewhat ugly for two reasons.
>
> * The abstraction add_exclude() offers to its callers is just to
> let them add one pattern to the list of patterns for the kind
> (here, EXC_CMDL); why should they care about .ary[0] part?
Because the caller has to decide which exclude list the new exclude
should be added to; that is how it has been for a long time, and I am
not proposing we change that.
There are currently three callers:
builtin/clean.c: cmd_clean()
builtin/ls-files.c: option_parse_exclude()
dir.c: add_excludes_from_file_to_list()
The first two add to EXC_CMDL, but the latter could be adding to
numerous different possible lists, e.g.
- .git/info/exclude (EXC_FILE)
- core.excludesfile (EXC_FILE)
- any of the per-directory .gitignore lists (EXC_DIRS)
> Are
> there cases any sane caller (not the implementation of the
> exclude_list_group machinery e.g. add_excludes_from_... function)
> may want to call it with .ary[1]?
Effectively yes, although it is not written like ".ary[1]". For
example prep_exclude() calls add_excludes_from_file_to_list() for each
new .gitignore file
> Shouldn't the public API function add_exclude() take a pointer to
> the list group itself?
Typically EXC_DIRS and EXC_FILE will contain excludes from multiple
sources, whereas EXC_CMDL will contain excludes from a single source.
Therefore when transitioning to exclude_list_groups, I had to make a
choice whether to keep EXC_CMDL as a singleton list, or split it out
into a separate field in struct dir_struct, e.g.:
struct exclude_list exclude_list_cmdl;
struct exclude_list exclude_list[2];
#define EXC_DIRS 0
#define EXC_FILE 1
I decided it was cleaner to use a singleton list, because this
preserved the design that excludes in earlier members of
exclude_list[3] take priority over excludes in later members of
exclude_list[3]. That way, this loop in last_exclude_matching():
for (i = EXC_CMDL; i <= EXC_FILE; i++) {
still makes sense.
> * When naming an array of things, we tend to prefer naming it
>
> type thing[count]
>
> so that the second element can be called "thing[2]" and not
> "things[2]". dir.exclude_list_group[EXC_CMDL] reads beter.
OK, I will change that.
> > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > index ef7f99a..c448e06 100644
> > --- a/builtin/ls-files.c
> > +++ b/builtin/ls-files.c
> > @@ -420,10 +420,10 @@ static int option_parse_z(const struct option *opt,
> > static int option_parse_exclude(const struct option *opt,
> > const char *arg, int unset)
> > {
> > - struct exclude_list *list = opt->value;
> > + struct exclude_list_group *group = opt->value;
> >
> > exc_given = 1;
> > - add_exclude(arg, "", 0, list);
> > + add_exclude(arg, "", 0, &group->ary[0]);
>
> This is another example where the caller would wish to be able to say
>
> add_exclude(arg, "", 0, group);
>
> instead.
Why? The caller needs to decide which exclude list the exclude should
go on, because that determines matching priority. Specifying an
exclude_list_group is insufficient information to determine that.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox