Re: [PATCH] clone: support atomic operation with --separate-git-dir
On Sun, Jan 6, 2013 at 1:43 PM, Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SubmittingPatches: Document how to request a patch review tag
Michael Haggerty mhag...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: support atomic operation with --separate-git-dir
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clone: forbid --bare --separate-git-dir dir
--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 pclo...@gmail.com --- On Sun, Jan 6, 2013 at 4:16 PM, Jonathan Nieder jrnie...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: forbid --bare --separate-git-dir dir
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 pclo...@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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cvsps, parsecvs, svn2git and the CVS exporter mess
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
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] docs: manpage XML depends on asciidoc.conf
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 j...@keeping.me.uk Signed-off-by: Jonathan Nieder jrnie...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/19] Improve documentation and comments regarding directory traversal API
On Wed, Jan 02, 2013 at 12:54:19PM +, Adam Spiers wrote:
On Tue, Jan 1, 2013 at 8:52 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: manpage XML depends on asciidoc.conf
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 j...@keeping.me.uk Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- This fixes the problem I wanted to fix (as well as being clearer for the future), so FWIW: Tested-by: John Keeping j...@keeping.me.uk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-fast-import(1): reorganise options
On Sat, Jan 05, 2013 at 11:12:25PM -0800, Junio C Hamano wrote: Jonathan Nieder jrnie...@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 jrnie...@gmail.com Signed-off-by: John Keeping j...@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
[PATCH/RFC] fast-import doc: split OPTIONS into subsections
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 j...@keeping.me.uk Signed-off-by: Jonathan Nieder jrnie...@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
Re: [PATCH] git-fast-import(1): reorganise options
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH jk/pathspec-literal] t6130-pathspec-noglob: Windows does not allow a file named f*
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 j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-fast-import(1): reorganise options
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH jk/pathspec-literal] t6130-pathspec-noglob: Windows does not allow a file named f*
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:
Adam Spiers g...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] archive-zip: write uncompressed size into header even with streaming
We record the uncompressed and compressed sizes and the CRC of streamed
files as zero in the local header of the file. The actual values are
recorded in an extra data descriptor after the file content, and in the
usual ZIP directory entry at the end of the archive.
While we know the compressed size and the CRC only after we processed
the contents, we actually know the uncompressed size right from the
start. And for files that we store uncompressed we also already know
their final size.
Do it like InfoZIP's zip and recored the known values, even though they
can be reconstructed using the ZIP directory and the data descriptors
alone. InfoZIP's unzip worked fine before, but NetBSD's version
actually depends on these fields.
The uncompressed size is already set by sha1_object_info(). We just
need to initialize the compressed size to zero or the uncompressed size
depending on the compression method (0 means storing). The CRC was
propertly initialized already.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
archive-zip.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 55f66b4..d3aef53 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -240,7 +240,7 @@ static int write_zip_entry(struct archiver_args *args,
(mode 0111) ? ((mode) 16) : 0;
if (S_ISREG(mode) args-compression_level != 0 size 0)
method = 8;
- compressed_size = size;
+ compressed_size = (method == 0) ? size : 0;
if (S_ISREG(mode) type == OBJ_BLOB !args-convert
size big_file_threshold) {
@@ -313,10 +313,7 @@ static int write_zip_entry(struct archiver_args *args,
copy_le16(header.compression_method, method);
copy_le16(header.mtime, zip_time);
copy_le16(header.mdate, zip_date);
- if (flags ZIP_STREAM)
- set_zip_header_data_desc(header, 0, 0, 0);
- else
- set_zip_header_data_desc(header, size, compressed_size, crc);
+ set_zip_header_data_desc(header, size, compressed_size, crc);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, ZIP_EXTRA_MTIME_SIZE);
write_or_die(1, header, ZIP_LOCAL_HEADER_SIZE);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
On Fri, Jan 04, 2013 at 11:54:34PM -0800, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Adam Spiers g...@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? 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]? I do not think of any. Shouldn't the public API function add_exclude() take a pointer to the list group itself? * 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 better. Also, ary[] is a bad name, even as an implementation detail, for two reasons: it is naming it after its type (being an array) not after what it is (if it holds the patterns from the same information source, e.g. file, togeter, src might be a better name), and it uses rather unusual abbreviation (I haven't seen array shortened to ary anywhere else). OK, well in that case Documentation/technical/api-allocation-growing.txt needs to be fixed, because I copied it from that. I would never normally shorten array to ary either, but I did it in an attempt to conform to the stated guidelines. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] api-allocation-growing.txt: encourage better variable naming
The documentation for the ALLOC_GROW API implicitly encouraged developers to use ary as the variable name for the array which is dynamically grown. However ary is an unusual abbreviation hardly used anywhere else in the source tree, and it is also better to name variables based on their contents not on their type. Signed-off-by: Adam Spiers g...@adamspiers.org --- Documentation/technical/api-allocation-growing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 43dbe09..3894815 100644 --- a/Documentation/technical/api-allocation-growing.txt +++ b/Documentation/technical/api-allocation-growing.txt @@ -5,7 +5,9 @@ Dynamically growing an array using realloc() is error prone and boring. Define your array with: -* a pointer (`ary`) that points at the array, initialized to `NULL`; +* a pointer (`array`) that points at the array, initialized to `NULL` + (although please name the variable based on its contents, not on its + type); * an integer variable (`alloc`) that keeps track of how big the current allocation is, initialized to `0`; @@ -13,22 +15,22 @@ Define your array with: * another integer variable (`nr`) to keep track of how many elements the array currently has, initialized to `0`. -Then before adding `n`th element to the array, call `ALLOC_GROW(ary, n, +Then before adding `n`th element to the array, call `ALLOC_GROW(array, n, alloc)`. This ensures that the array can hold at least `n` elements by calling `realloc(3)` and adjusting `alloc` variable. -sometype *ary; +sometype *array; size_t nr; size_t alloc for (i = 0; i nr; i++) - if (we like ary[i] already) + if (we like array[i] already) return; /* we did not like any existing one, so add one */ -ALLOC_GROW(ary, nr + 1, alloc); -ary[nr++] = value you like; +ALLOC_GROW(array, nr + 1, alloc); +array[nr++] = value you like; You are responsible for updating the `nr` variable. -- 1.7.11.7.33.gb8feba5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: as/check-ignore (was Re: What's cooking in git.git (Jan 2013, #02; Thu, 3))
On Fri, Jan 04, 2013 at 01:13:12PM -0800, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: On Thu, Jan 3, 2013 at 7:17 PM, Junio C Hamano gits...@pobox.com wrote: * as/check-ignore (2012-12-28) 19 commits - Add git-check-ignore sub-command - setup.c: document get_pathspec() - pathspec.c: extract new validate_path() for reuse - pathspec.c: move reusable code from builtin/add.c - add.c: remove unused argument from validate_pathspec() - add.c: refactor treat_gitlinks() - dir.c: provide clear_directory() for reclaiming dir_struct memory - dir.c: keep track of where patterns came from - dir.c: use a single struct exclude_list per source of excludes - dir.c: rename free_excludes() to clear_exclude_list() - 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 - Improve documentation and comments regarding directory traversal API - api-directory-listing.txt: update to match code Rerolled. The early parts looked mostly fine; we may want to split this into two topics and have the early half graduate sooner. Sounds good to me. As already mentioned, I have the v4 series ready and it addresses all issues already voiced in v3, but I have postponed submitting it as per your request. Please let me know when and how to proceed, thanks! I was planning to add a new as/dir-c-cleanup topic that leads to f619881 (dir.c: rename free_excludes() to clear_exclude_list(), 2012-12-27), and leave the remainder in this series. I think the earlier parts of this series up to that point should go 'next' now. That sounds perfect; thanks. I'll rebase v4 on top of this and submit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] Remove the suggestion to use parsecvs, which is currently broken.
Hi,
On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote:
Heiko Voigt hvo...@hvoigt.net:
Maybe you could add that information to the parsecvs compile
instructions? I think just because it takes some effort to compile does
not justify to remove this useful pointer here. When I was converting a
legacy cvs repository this pointer would have helped me a lot.
I'm parsecvs's maintainer now. It's not in good shape; there is at
least one other known showstopper besides the build issue. I would
strongly prefer to direct peoples' attention away from it until I
have time to fix it and cut a release. This is not a distant
prospect - two or three weeks out, maybe.
So for this short amount of time you want to change gits documentation?
Is this hint causing you trouble? Are there many people asking for
support because of that?
Even if it takes some effort to get parsecvs running I would like to
keep the hint to a good and proven cvs importer.
The priority that is between me and fixing parsecvs is getting (a)
cvsps and git-cvsimport to a non-broken state, and (b) having a sound
test suite in place so I *know* it's in a non-broken state. As previously
discussed, I will then apply that test suite to parsecvs.
Heiko, you can speed up the process by (a) adapting your tests for
the new cvsps test code,
I had a quick glance at your testsuite. After building cvsps with
make
and cd'ing into test I got a lot of error messages some saying that
cvsps was not found when issuing
make
there. It would be great if do not need to install cvsps into my path
just for running the testsuite.
There is no README so I am not sure how the tests are supposed to be
build in general. Due to the lack of documentation its probably easier
for you Eric to port my tests.
The structure of my tests is quite simple:
t/ - All the tests
t/cvsroot - A cvs module per test
t/t[0-9]{4}*/expect - The expected cvsps output
You can copy the cvs repository modules and convert the expected cvsps
output to whatever output you want to test against. It the found
changeset ordering that is interesting.
and (b) merging the fix you wrote so cvsps
would pass the t9603 test.
The fix was never clean and AFAIR the reason behind that was that the
breakage in commit ordering is not easy to fix in cvsps. That and
because there are other working tools out there was the reason why I
stopped working on fixing cvsps.
Cheers Heiko
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/11] new git check-ignore sub-command
This is the v4 re-roll of the check-ignore series, which is based on Junio's as/dir-c-cleanup topic branch f6198812 (dir.c: rename free_excludes() to clear_exclude_list(), 2012-12-27). As previously discussed, the earlier parts of the v3 series seem to be complete and are progressing to 'next'. Since v3, I addressed the issue of newly public functions with unacceptably vague or generic names via the following steps: - eliminated extraction from add.c to pathspec.c of two functions which did not need to be public (validate_pathspec() and treat_gitlinks()) - edited the series history to create separate commits for extraction of reusable code from treat_gitlinks() and validate_pathspec() into more carefully named public functions This should make reviewing easier. I will summarise the changes in the revised patches since v3 in between the --- divider and the diffstat of each individual patch. This series is also available via the check-ignore-v4 tag in: git://github.com/aspiers/git.git Adam Spiers (11): dir.c: use a single struct exclude_list per source of excludes dir.c: keep track of where patterns came from dir.c: provide clear_directory() for reclaiming dir_struct memory dir.c: improve docs for match_pathspec() and match_pathspec_depth() add.c: remove unused argument from validate_pathspec() add.c: move pathspec matchers into new pathspec.c for reuse pathspec.c: rename newly public functions for clarity add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse add.c: extract new die_if_path_beyond_symlink() for reuse setup.c: document get_pathspec() add git-check-ignore sub-command .gitignore| 1 + Documentation/git-check-ignore.txt| 89 +++ Documentation/gitignore.txt | 6 +- Documentation/technical/api-directory-listing.txt | 14 +- Makefile | 3 + builtin.h | 1 + builtin/add.c | 78 +-- builtin/check-ignore.c| 173 ++ builtin/clean.c | 3 +- builtin/ls-files.c| 9 +- command-list.txt | 1 + contrib/completion/git-completion.bash| 1 + dir.c | 152 -- dir.h | 62 ++- git.c | 1 + pathspec.c| 101 pathspec.h| 9 + setup.c | 19 + t/t0008-ignores.sh| 632 ++ unpack-trees.c| 2 +- 20 files changed, 1240 insertions(+), 117 deletions(-) create mode 100644 Documentation/git-check-ignore.txt create mode 100644 builtin/check-ignore.c create mode 100644 pathspec.c create mode 100644 pathspec.h create mode 100755 t/t0008-ignores.sh -- 1.7.11.7.33.gb8feba5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/11] dir.c: improve docs for match_pathspec() and match_pathspec_depth()
Fix a grammatical issue in the description of these functions, and
make it more obvious how and why seen[] can be reused across multiple
invocations.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
dir.c | 38 ++
dir.h | 6 ++
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/dir.c b/dir.c
index 46f362e..547b83f 100644
--- a/dir.c
+++ b/dir.c
@@ -167,12 +167,19 @@ static int match_one(const char *match, const char *name,
int namelen)
}
/*
- * Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs. The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * Given a name and a list of pathspecs, returns the nature of the
+ * closest (i.e. most specific) match of the name to any of the
+ * pathspecs.
+ *
+ * The caller typically calls this multiple times with the same
+ * pathspec and seen[] array but with different name/namelen
+ * (e.g. entries from the index) and is interested in seeing if and
+ * how each pathspec matches all the names it calls this function
+ * with. A mark is left in the seen[] array for each pathspec element
+ * indicating the closest type of match that element achieved, so if
+ * seen[n] remains zero after multiple invocations, that means the nth
+ * pathspec did not match any names, which could indicate that the
+ * user mistyped the nth pathspec.
*/
int match_pathspec(const char **pathspec, const char *name, int namelen,
int prefix, char *seen)
@@ -239,12 +246,19 @@ static int match_pathspec_item(const struct pathspec_item
*item, int prefix,
}
/*
- * Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs. The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * Given a name and a list of pathspecs, returns the nature of the
+ * closest (i.e. most specific) match of the name to any of the
+ * pathspecs.
+ *
+ * The caller typically calls this multiple times with the same
+ * pathspec and seen[] array but with different name/namelen
+ * (e.g. entries from the index) and is interested in seeing if and
+ * how each pathspec matches all the names it calls this function
+ * with. A mark is left in the seen[] array for each pathspec element
+ * indicating the closest type of match that element achieved, so if
+ * seen[n] remains zero after multiple invocations, that means the nth
+ * pathspec did not match any names, which could indicate that the
+ * user mistyped the nth pathspec.
*/
int match_pathspec_depth(const struct pathspec *ps,
const char *name, int namelen,
diff --git a/dir.h b/dir.h
index dd42a3a..136e838 100644
--- a/dir.h
+++ b/dir.h
@@ -116,6 +116,12 @@ struct dir_struct {
char basebuf[PATH_MAX];
};
+/*
+ * The ordering of these constants is significant, with
+ * higher-numbered match types signifying closer (i.e. more
+ * specific) matches which will override lower-numbered match types
+ * when populating the seen[] array.
+ */
#define MATCHED_RECURSIVELY 1
#define MATCHED_FNMATCH 2
#define MATCHED_EXACTLY 3
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/11] dir.c: keep track of where patterns came from
For exclude patterns read in from files, the filename is stored in the
exclude list, and the originating line number is stored in the
individual exclude (counting starting at 1).
For exclude patterns provided on the command line, a string describing
the source of the patterns is stored in the exclude list, and the
sequence number assigned to each exclude pattern is negative, with
counting starting at -1. So for example the 2nd pattern provided via
--exclude would be numbered -2. This allows any future consumers of
that data to easily distinguish between exclude patterns from files
vs. from the CLI.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/clean.c| 4 ++--
builtin/ls-files.c | 5 +++--
dir.c | 26 --
dir.h | 21 +++--
4 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index dd89737..b098288 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -97,10 +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);
+ add_exclude_list(dir, EXC_CMDL, --exclude option);
for (i = 0; i exclude_list.nr; i++)
add_exclude(exclude_list.items[i].string, , 0,
- dir.exclude_list_group[EXC_CMDL].el[0]);
+ dir.exclude_list_group[EXC_CMDL].el[0], -(i+1));
pathspec = get_pathspec(prefix, argv);
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 0ca9d8e..fa9ccb8 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -35,6 +35,7 @@ static int error_unmatch;
static char *ps_matched;
static const char *with_tree;
static int exc_given;
+static int exclude_args;
static const char *tag_cached = ;
static const char *tag_unmerged = ;
@@ -423,7 +424,7 @@ static int option_parse_exclude(const struct option *opt,
struct exclude_list_group *group = opt-value;
exc_given = 1;
- add_exclude(arg, , 0, group-el[0]);
+ add_exclude(arg, , 0, group-el[0], --exclude_args);
return 0;
}
@@ -524,7 +525,7 @@ int cmd_ls_files(int argc, const char **argv, const char
*cmd_prefix)
if (read_cache() 0)
die(index file corrupt);
- add_exclude_list(dir, EXC_CMDL);
+ add_exclude_list(dir, EXC_CMDL, --exclude option);
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
ls_files_usage, 0);
if (show_tag || show_valid_bit) {
diff --git a/dir.c b/dir.c
index 3a15cb9..d3f462b 100644
--- a/dir.c
+++ b/dir.c
@@ -349,7 +349,7 @@ void parse_exclude_pattern(const char **pattern,
}
void add_exclude(const char *string, const char *base,
-int baselen, struct exclude_list *el)
+int baselen, struct exclude_list *el, int srcpos)
{
struct exclude *x;
int patternlen;
@@ -373,8 +373,10 @@ void add_exclude(const char *string, const char *base,
x-base = base;
x-baselen = baselen;
x-flags = flags;
+ x-srcpos = srcpos;
ALLOC_GROW(el-excludes, el-nr + 1, el-alloc);
el-excludes[el-nr++] = x;
+ x-el = el;
}
static void *read_skip_worktree_file_from_index(const char *path, size_t *size)
@@ -425,7 +427,7 @@ int add_excludes_from_file_to_list(const char *fname,
int check_index)
{
struct stat st;
- int fd, i;
+ int fd, i, lineno = 1;
size_t size = 0;
char *buf, *entry;
@@ -467,15 +469,17 @@ int add_excludes_from_file_to_list(const char *fname,
if (buf[i] == '\n') {
if (entry != buf + i entry[0] != '#') {
buf[i - (i buf[i-1] == '\r')] = 0;
- add_exclude(entry, base, baselen, el);
+ add_exclude(entry, base, baselen, el, lineno);
}
+ lineno++;
entry = buf + i + 1;
}
}
return 0;
}
-struct exclude_list *add_exclude_list(struct dir_struct *dir, int group_type)
+struct exclude_list *add_exclude_list(struct dir_struct *dir,
+ int group_type, const char *src)
{
struct exclude_list *el;
struct exclude_list_group *group;
@@ -484,6 +488,7 @@ struct exclude_list *add_exclude_list(struct dir_struct
*dir, int group_type)
ALLOC_GROW(group-el, group-nr + 1, group-alloc);
el = group-el[group-nr++];
memset(el, 0, sizeof(*el));
+ el-src = src;
return el;
}
@@ -493,7 +498,7 @@ struct exclude_list *add_exclude_list(struct dir_struct
*dir, int group_type)
void add_excludes_from_file(struct dir_struct *dir, const char *fname)
{
struct exclude_list *el;
- el = add_exclude_list(dir,
[PATCH v4 05/11] add.c: remove unused argument from validate_pathspec()
The 'argc' argument passed to validate_pathspec() was never used.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/add.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index c689f37..1f62ba3 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -197,7 +197,7 @@ static void refresh(int verbose, const char **pathspec)
free(seen);
}
-static const char **validate_pathspec(int argc, const char **argv, const char
*prefix)
+static const char **validate_pathspec(const char **argv, const char *prefix)
{
const char **pathspec = get_pathspec(prefix, argv);
@@ -248,7 +248,7 @@ int interactive_add(int argc, const char **argv, const char
*prefix, int patch)
const char **pathspec = NULL;
if (argc) {
- pathspec = validate_pathspec(argc, argv, prefix);
+ pathspec = validate_pathspec(argv, prefix);
if (!pathspec)
return -1;
}
@@ -414,7 +414,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
fprintf(stderr, _(Maybe you wanted to say 'git add .'?\n));
return 0;
}
- pathspec = validate_pathspec(argc, argv, prefix);
+ pathspec = validate_pathspec(argv, prefix);
if (read_cache() 0)
die(_(index file corrupt));
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/11] setup.c: document get_pathspec()
Since we have just created a new pathspec-handling library, now is a
good time to add some comments explaining get_pathspec().
Signed-off-by: Adam Spiers g...@adamspiers.org
---
The deprecation warning is new since v3.
setup.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/setup.c b/setup.c
index 7663a4c..9570147 100644
--- a/setup.c
+++ b/setup.c
@@ -249,6 +249,25 @@ static const char *prefix_pathspec(const char *prefix, int
prefixlen, const char
return prefix_path(prefix, prefixlen, copyfrom);
}
+/*
+ * N.B. get_pathspec() is deprecated in favor of the struct pathspec
+ * based interface - see pathspec_magic above.
+ *
+ * Arguments:
+ * - prefix - a path relative to the root of the working tree
+ * - pathspec - a list of paths underneath the prefix path
+ *
+ * Iterates over pathspec, prepending each path with prefix,
+ * and return the resulting list.
+ *
+ * If pathspec is empty, return a singleton list containing prefix.
+ *
+ * If pathspec and prefix are both empty, return an empty list.
+ *
+ * This is typically used by built-in commands such as add.c, in order
+ * to normalize argv arguments provided to the built-in into a list of
+ * paths to process, all relative to the root of the working tree.
+ */
const char **get_pathspec(const char *prefix, const char **pathspec)
{
const char *entry = *pathspec;
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/11] add git-check-ignore sub-command
This works in a similar manner to git-check-attr. Thanks to Jeff King and Junio C Hamano for the idea: http://thread.gmane.org/gmane.comp.version-control.git/108671/focus=108815 Signed-off-by: Adam Spiers g...@adamspiers.org --- Several minor improvements since v3: - rename char *dir to slash - fix some declaration-after-statement violations - correctly handle and test the case where --stdin is used but STDIN is empty - test that files in the index are not listed as ignored - test that the presence of a file in the working directory doesn't impact the result of running check-ignore on that file - stylistic tweaks - drop the -q option to grep in the test suite - fix potential brittleness with future tests which could call test_expect_success_multi with parameters containing double-quotes .gitignore| 1 + Documentation/git-check-ignore.txt| 89 +++ Documentation/gitignore.txt | 6 +- Documentation/technical/api-directory-listing.txt | 2 +- Makefile | 1 + builtin.h | 1 + builtin/check-ignore.c| 173 ++ command-list.txt | 1 + contrib/completion/git-completion.bash| 1 + git.c | 1 + t/t0008-ignores.sh| 632 ++ 11 files changed, 905 insertions(+), 3 deletions(-) create mode 100644 Documentation/git-check-ignore.txt create mode 100644 builtin/check-ignore.c create mode 100755 t/t0008-ignores.sh diff --git a/.gitignore b/.gitignore index f1acd3e..20ef4e8 100644 --- a/.gitignore +++ b/.gitignore @@ -19,6 +19,7 @@ /git-bundle /git-cat-file /git-check-attr +/git-check-ignore /git-check-ref-format /git-checkout /git-checkout-index diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt new file mode 100644 index 000..854e4d0 --- /dev/null +++ b/Documentation/git-check-ignore.txt @@ -0,0 +1,89 @@ +git-check-ignore(1) +=== + +NAME + +git-check-ignore - Debug gitignore / exclude files + + +SYNOPSIS + +[verse] +'git check-ignore' [options] pathname... +'git check-ignore' [options] --stdin list-of-paths + +DESCRIPTION +--- + +For each pathname given via the command-line or from a file via +`--stdin`, show the pattern from .gitignore (or other input files to +the exclude mechanism) that decides if the pathname is excluded or +included. Later patterns within a file take precedence over earlier +ones. + +OPTIONS +--- +-q, --quiet:: + Don't output anything, just set exit status. This is only + valid with a single pathname. + +-v, --verbose:: + Also output details about the matching pattern (if any) + for each given pathname. + +--stdin:: + Read file names from stdin instead of from the command-line. + +-z:: + The output format is modified to be machine-parseable (see + below). If `--stdin` is also given, input paths are separated + with a NUL character instead of a linefeed character. + +OUTPUT +-- + +By default, any of the given pathnames which match an ignore pattern +will be output, one per line. If no pattern matches a given path, +nothing will be output for that path; this means that path will not be +ignored. + +If `--verbose` is specified, the output is a series of lines of the form: + +source COLON linenum COLON pattern HT pathname + +pathname is the path of a file being queried, pattern is the +matching pattern, source is the pattern's source file, and linenum +is the line number of the pattern within that source. If the pattern +contained a `!` prefix or `/` suffix, it will be preserved in the +output. source will be an absolute path when referring to the file +configured by `core.excludesfile`, or relative to the repository root +when referring to `.git/info/exclude` or a per-directory exclude file. + +If `-z` is specified, the pathnames in the output are delimited by the +null character; if `--verbose` is also specified then null characters +are also used instead of colons and hard tabs: + +source NULL linenum NULL pattern NULL pathname NULL + + +EXIT STATUS +--- + +0:: + One or more of the provided paths is ignored. + +1:: + None of the provided paths are ignored. + +128:: + A fatal error was encountered. + +SEE ALSO + +linkgit:gitignore[5] +linkgit:gitconfig[5] +linkgit:git-ls-files[5] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 2e7328b..f401b8c 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -153,8 +153,10 @@ The second .gitignore prevents git from ignoring SEE ALSO -linkgit:git-rm[1], linkgit:git-update-index[1],
[PATCH v4 09/11] add.c: extract new die_if_path_beyond_symlink() for reuse
This will be reused by a new git check-ignore command.
Also document validate_pathspec().
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Unlike v3, this series doesn't make validate_pathspec() public.
builtin/add.c | 10 ++
pathspec.c| 12
pathspec.h| 1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index f95ded2..3716617 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -153,6 +153,11 @@ static void refresh(int verbose, const char **pathspec)
free(seen);
}
+/*
+ * Normalizes argv relative to prefix, via get_pathspec(), and then
+ * runs die_if_path_beyond_symlink() on each path in the normalized
+ * list.
+ */
static const char **validate_pathspec(const char **argv, const char *prefix)
{
const char **pathspec = get_pathspec(prefix, argv);
@@ -160,10 +165,7 @@ static const char **validate_pathspec(const char **argv,
const char *prefix)
if (pathspec) {
const char **p;
for (p = pathspec; *p; p++) {
- if (has_symlink_leading_path(*p, strlen(*p))) {
- int len = prefix ? strlen(prefix) : 0;
- die(_('%s' is beyond a symbolic link), *p +
len);
- }
+ die_if_path_beyond_symlink(*p, prefix);
}
}
diff --git a/pathspec.c b/pathspec.c
index 02d3344..284f397 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -87,3 +87,15 @@ const char *check_path_for_gitlink(const char *path)
}
return path;
}
+
+/*
+ * Dies if the given path refers to a file inside a symlinked
+ * directory in the index.
+ */
+void die_if_path_beyond_symlink(const char *path, const char *prefix)
+{
+ if (has_symlink_leading_path(path, strlen(path))) {
+ int len = prefix ? strlen(prefix) : 0;
+ die(_('%s' is beyond a symbolic link), path + len);
+ }
+}
diff --git a/pathspec.h b/pathspec.h
index bf8eb96..db0184a 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -4,5 +4,6 @@
extern char *find_pathspecs_matching_against_index(const char **pathspec);
extern void add_pathspec_matches_against_index(const char **pathspec, char
*seen, int specs);
extern const char *check_path_for_gitlink(const char *path);
+extern void die_if_path_beyond_symlink(const char *path, const char *prefix);
#endif /* PATHSPEC_H */
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/11] add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
Extract the body of the for loop in treat_gitlinks() into a separate
check_path_for_gitlink() function so that it can be reused elsewhere.
This paves the way for a new check-ignore sub-command.
Also document treat_gitlinks().
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Unlike v3, this series doesn't make treat_gitlinks() public.
builtin/add.c | 24 ++--
pathspec.c| 31 +++
pathspec.h| 1 +
3 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 8c3fdf9..f95ded2 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -121,6 +121,10 @@ static char *prune_directory(struct dir_struct *dir, const
char **pathspec, int
return seen;
}
+/*
+ * Checks the index to see whether any path in pathspec refers to
+ * something inside a submodule. If so, dies with an error message.
+ */
static void treat_gitlinks(const char **pathspec)
{
int i;
@@ -128,24 +132,8 @@ static void treat_gitlinks(const char **pathspec)
if (!pathspec || !*pathspec)
return;
- for (i = 0; i active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
- if (S_ISGITLINK(ce-ce_mode)) {
- int len = ce_namelen(ce), j;
- for (j = 0; pathspec[j]; j++) {
- int len2 = strlen(pathspec[j]);
- if (len2 = len || pathspec[j][len] != '/' ||
- memcmp(ce-name, pathspec[j], len))
- continue;
- if (len2 == len + 1)
- /* strip trailing slash */
- pathspec[j] = xstrndup(ce-name, len);
- else
- die (_(Path '%s' is in submodule
'%.*s'),
- pathspec[j], len, ce-name);
- }
- }
- }
+ for (i = 0; pathspec[i]; i++)
+ pathspec[i] = check_path_for_gitlink(pathspec[i]);
}
static void refresh(int verbose, const char **pathspec)
diff --git a/pathspec.c b/pathspec.c
index b73b15c..02d3344 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -56,3 +56,34 @@ char *find_pathspecs_matching_against_index(const char
**pathspec)
add_pathspec_matches_against_index(pathspec, seen, i);
return seen;
}
+
+/*
+ * Check the index to see whether path refers to a submodule, or
+ * something inside a submodule. If the former, returns the path with
+ * any trailing slash stripped. If the latter, dies with an error
+ * message.
+ */
+const char *check_path_for_gitlink(const char *path)
+{
+ int i, path_len = strlen(path);
+ for (i = 0; i active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ if (S_ISGITLINK(ce-ce_mode)) {
+ int ce_len = ce_namelen(ce);
+ if (path_len = ce_len || path[ce_len] != '/' ||
+ memcmp(ce-name, path, ce_len))
+ /* path does not refer to this
+* submodule or anything inside it */
+ continue;
+ if (path_len == ce_len + 1) {
+ /* path refers to submodule;
+* strip trailing slash */
+ return xstrndup(ce-name, ce_len);
+ } else {
+ die (_(Path '%s' is in submodule '%.*s'),
+path, ce_len, ce-name);
+ }
+ }
+ }
+ return path;
+}
diff --git a/pathspec.h b/pathspec.h
index 3852bc0..bf8eb96 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -3,5 +3,6 @@
extern char *find_pathspecs_matching_against_index(const char **pathspec);
extern void add_pathspec_matches_against_index(const char **pathspec, char
*seen, int specs);
+extern const char *check_path_for_gitlink(const char *path);
#endif /* PATHSPEC_H */
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/11] pathspec.c: rename newly public functions for clarity
Perform the following function renames to make it explicit that these
pathspec handling functions are for matching against the index, rather
than against a tree or the working directory.
- fill_pathspec_matches() - add_pathspec_matches_against_index()
- find_used_pathspec() - find_pathspecs_matching_against_index()
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/add.c | 4 ++--
pathspec.c| 17 +
pathspec.h| 4 ++--
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index e51ba44..8c3fdf9 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -117,7 +117,7 @@ static char *prune_directory(struct dir_struct *dir, const
char **pathspec, int
*dst++ = entry;
}
dir-nr = dst - dir-entries;
- fill_pathspec_matches(pathspec, seen, specs);
+ add_pathspec_matches_against_index(pathspec, seen, specs);
return seen;
}
@@ -415,7 +415,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
path_exclude_check_init(check, dir);
if (!seen)
- seen = find_used_pathspec(pathspec);
+ seen = find_pathspecs_matching_against_index(pathspec);
for (i = 0; pathspec[i]; i++) {
if (!seen[i] pathspec[i][0]
!file_exists(pathspec[i])) {
diff --git a/pathspec.c b/pathspec.c
index 1472af8..b73b15c 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -13,9 +13,10 @@
* altogether if seen[] already only contains non-zero entries.
*
* If seen[] has not already been written to, it may make sense
- * to use find_used_pathspec() instead.
+ * to use find_pathspecs_matching_against_index() instead.
*/
-void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
+void add_pathspec_matches_against_index(const char **pathspec,
+ char *seen, int specs)
{
int num_unmatched = 0, i;
@@ -39,12 +40,12 @@ void fill_pathspec_matches(const char **pathspec, char
*seen, int specs)
/*
* Finds which of the given pathspecs match items in the index.
*
- * This is a one-shot wrapper around fill_pathspec_matches() which
- * allocates, populates, and returns a seen[] array indicating the
- * nature of the closest (i.e. most specific) matches which each of
- * the given pathspecs achieves against all items in the index.
+ * This is a one-shot wrapper around add_pathspec_matches_against_index()
+ * which allocates, populates, and returns a seen[] array indicating the
+ * nature of the closest (i.e. most specific) matches which each of the
+ * given pathspecs achieves against all items in the index.
*/
-char *find_used_pathspec(const char **pathspec)
+char *find_pathspecs_matching_against_index(const char **pathspec)
{
char *seen;
int i;
@@ -52,6 +53,6 @@ char *find_used_pathspec(const char **pathspec)
for (i = 0; pathspec[i]; i++)
; /* just counting */
seen = xcalloc(i, 1);
- fill_pathspec_matches(pathspec, seen, i);
+ add_pathspec_matches_against_index(pathspec, seen, i);
return seen;
}
diff --git a/pathspec.h b/pathspec.h
index 1cb1909..3852bc0 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -1,7 +1,7 @@
#ifndef PATHSPEC_H
#define PATHSPEC_H
-extern char *find_used_pathspec(const char **pathspec);
-extern void fill_pathspec_matches(const char **pathspec, char *seen, int
specs);
+extern char *find_pathspecs_matching_against_index(const char **pathspec);
+extern void add_pathspec_matches_against_index(const char **pathspec, char
*seen, int specs);
#endif /* PATHSPEC_H */
--
1.7.11.7.33.gb8feba5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/11] add.c: move pathspec matchers into new pathspec.c for reuse
Extract the following functions from builtin/add.c to pathspec.c, in
preparation for reuse by a new git check-ignore command:
- fill_pathspec_matches()
- find_used_pathspec()
The functions being extracted are not changed in any way, except
removal of the 'static' qualifier.
Also add comments documenting these newly public functions,
including clarifications that they operate on the index.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
The v3 version of this patch extracted 5 functions from add.c to
pathspec.c, two of which did not need to be extracted. Here we
use more fine-grained commits for extraction, and also wrap pathspec.h
in a PATHSPEC_H gate to avoid duplication.
Makefile | 2 ++
builtin/add.c | 34 +-
pathspec.c| 57 +
pathspec.h| 7 +++
4 files changed, 67 insertions(+), 33 deletions(-)
create mode 100644 pathspec.c
create mode 100644 pathspec.h
diff --git a/Makefile b/Makefile
index 13293d3..48facad 100644
--- a/Makefile
+++ b/Makefile
@@ -645,6 +645,7 @@ LIB_H += pack-refs.h
LIB_H += pack-revindex.h
LIB_H += parse-options.h
LIB_H += patch-ids.h
+LIB_H += pathspec.h
LIB_H += pkt-line.h
LIB_H += progress.h
LIB_H += prompt.h
@@ -758,6 +759,7 @@ LIB_OBJS += parse-options-cb.o
LIB_OBJS += patch-delta.o
LIB_OBJS += patch-ids.o
LIB_OBJS += path.o
+LIB_OBJS += pathspec.o
LIB_OBJS += pkt-line.o
LIB_OBJS += preload-index.o
LIB_OBJS += pretty.o
diff --git a/builtin/add.c b/builtin/add.c
index 1f62ba3..e51ba44 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -6,6 +6,7 @@
#include cache.h
#include builtin.h
#include dir.h
+#include pathspec.h
#include exec_cmd.h
#include cache-tree.h
#include run-command.h
@@ -97,39 +98,6 @@ int add_files_to_cache(const char *prefix, const char
**pathspec, int flags)
return !!data.add_errors;
}
-static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
-{
- int num_unmatched = 0, i;
-
- /*
-* Since we are walking the index as if we were walking the directory,
-* we have to mark the matched pathspec as seen; otherwise we will
-* mistakenly think that the user gave a pathspec that did not match
-* anything.
-*/
- for (i = 0; i specs; i++)
- if (!seen[i])
- num_unmatched++;
- if (!num_unmatched)
- return;
- for (i = 0; i active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
- match_pathspec(pathspec, ce-name, ce_namelen(ce), 0, seen);
- }
-}
-
-static char *find_used_pathspec(const char **pathspec)
-{
- char *seen;
- int i;
-
- for (i = 0; pathspec[i]; i++)
- ; /* just counting */
- seen = xcalloc(i, 1);
- fill_pathspec_matches(pathspec, seen, i);
- return seen;
-}
-
static char *prune_directory(struct dir_struct *dir, const char **pathspec,
int prefix)
{
char *seen;
diff --git a/pathspec.c b/pathspec.c
new file mode 100644
index 000..1472af8
--- /dev/null
+++ b/pathspec.c
@@ -0,0 +1,57 @@
+#include cache.h
+#include dir.h
+#include pathspec.h
+
+/*
+ * Finds which of the given pathspecs match items in the index.
+ *
+ * For each pathspec, sets the corresponding entry in the seen[] array
+ * (which should be specs items long, i.e. the same size as pathspec)
+ * to the nature of the closest (i.e. most specific) match found for
+ * that pathspec in the index, if it was a closer type of match than
+ * the existing entry. As an optimization, matching is skipped
+ * altogether if seen[] already only contains non-zero entries.
+ *
+ * If seen[] has not already been written to, it may make sense
+ * to use find_used_pathspec() instead.
+ */
+void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
+{
+ int num_unmatched = 0, i;
+
+ /*
+* Since we are walking the index as if we were walking the directory,
+* we have to mark the matched pathspec as seen; otherwise we will
+* mistakenly think that the user gave a pathspec that did not match
+* anything.
+*/
+ for (i = 0; i specs; i++)
+ if (!seen[i])
+ num_unmatched++;
+ if (!num_unmatched)
+ return;
+ for (i = 0; i active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ match_pathspec(pathspec, ce-name, ce_namelen(ce), 0, seen);
+ }
+}
+
+/*
+ * Finds which of the given pathspecs match items in the index.
+ *
+ * This is a one-shot wrapper around fill_pathspec_matches() which
+ * allocates, populates, and returns a seen[] array indicating the
+ * nature of the closest (i.e. most specific) matches which each of
+ * the given pathspecs achieves against all items in the index.
+ */
+char *find_used_pathspec(const char **pathspec)
+{
+ char *seen;
+
[PATCH 0/4] ZIP test fixes
Fix a bug in two scripts that call unzip, use the opportunity for a small cleanup, move all ZIP related tests out of t5000 and finally skip testing symlinks if unzip doesn't support them. The first one allows running t5000 with the unzip from pkgsrc manually on NetBSD, which succeeds. The last one -- together with the archive-zip streaming patch I sent earlier today -- makes the ZIP tests succeed on that platform out of the box. René t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead t0024, t5000: use test_lazy_prereq for UNZIP t5000, t5002: move ZIP tests into their own script t5002: check if unzip supports symlinks t/t0024-crlf-archive.sh | 16 +++--- t/t5000-tar-tree.sh | 71 --- t/t5002-archive-zip.sh | 131 +++ t/t5002/infozip-symlinks.zip | Bin 0 - 328 bytes t/test-lib.sh| 2 + 5 files changed, 140 insertions(+), 80 deletions(-) create mode 100755 t/t5002-archive-zip.sh create mode 100644 t/t5002/infozip-symlinks.zip -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's unzip it would try to extract
from itself (because it treats the contents of $UNZIP as parameters),
which failed of course.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t0024-crlf-archive.sh | 6 +++---
t/t5000-tar-tree.sh | 10 +-
t/test-lib.sh | 2 ++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
index ec6c1b3..080fe5c 100755
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -3,7 +3,7 @@
test_description='respect crlf in git archive'
. ./test-lib.sh
-UNZIP=${UNZIP:-unzip}
+GIT_UNZIP=${GIT_UNZIP:-unzip}
test_expect_success setup '
@@ -26,7 +26,7 @@ test_expect_success 'tar archive' '
'
-$UNZIP -v /dev/null 21
+$GIT_UNZIP -v /dev/null 21
if [ $? -eq 127 ]; then
say Skipping ZIP test, because unzip was not found
else
@@ -37,7 +37,7 @@ test_expect_success UNZIP 'zip archive' '
git archive --format=zip HEAD test.zip
- ( mkdir unzipped cd unzipped unzip ../test.zip )
+ ( mkdir unzipped cd unzipped $GIT_UNZIP ../test.zip )
test_cmp sample unzipped/sample
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index ecf00ed..1f7593d 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,7 +25,7 @@ commit id embedding:
'
. ./test-lib.sh
-UNZIP=${UNZIP:-unzip}
+GIT_UNZIP=${GIT_UNZIP:-unzip}
GZIP=${GZIP:-gzip}
GUNZIP=${GUNZIP:-gzip -d}
@@ -37,9 +37,9 @@ check_zip() {
dir=$1
dir_with_prefix=$dir/$2
- test_expect_success UNZIP extract ZIP archive
- (mkdir $dir cd $dir $UNZIP ../$zipfile)
-
+ test_expect_success UNZIP extract ZIP archive '
+ (mkdir $dir cd $dir $GIT_UNZIP ../$zipfile)
+ '
test_expect_success UNZIP validate filenames
(cd ${dir_with_prefix}a find .) | sort $listfile
@@ -201,7 +201,7 @@ test_expect_success \
test_cmp a/substfile2 g/prefix/a/substfile2
'
-$UNZIP -v /dev/null 21
+$GIT_UNZIP -v /dev/null 21
if [ $? -eq 127 ]; then
say Skipping ZIP tests, because unzip was not found
else
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 8a12cbb..d8ec408 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -85,6 +85,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $($PERL_PATH -e '
.*_TEST
PROVE
VALGRIND
+ UNZIP
PERF_AGGREGATING_LATER
));
my @vars = grep(/^GIT_/ !/^GIT_($ok)/o, @env);
@@ -128,6 +129,7 @@ fi
unset CDPATH
unset GREP_OPTIONS
+unset UNZIP
case $(echo $GIT_TRACE |tr [A-Z] [a-z]) in
1|2|true)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
This change makes the code smaller and we can put it at the top of
the script, its rightful place as setup code.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t0024-crlf-archive.sh | 12 +---
t/t5000-tar-tree.sh | 12 +---
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
index 080fe5c..ba397bb 100755
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
. ./test-lib.sh
GIT_UNZIP=${GIT_UNZIP:-unzip}
+test_lazy_prereq UNZIP '
+ $GIT_UNZIP -v /dev/null 21
+ test $? -ne 127
+'
+
test_expect_success setup '
git config core.autocrlf true
@@ -26,13 +31,6 @@ test_expect_success 'tar archive' '
'
-$GIT_UNZIP -v /dev/null 21
-if [ $? -eq 127 ]; then
- say Skipping ZIP test, because unzip was not found
-else
- test_set_prereq UNZIP
-fi
-
test_expect_success UNZIP 'zip archive' '
git archive --format=zip HEAD test.zip
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 1f7593d..6702157 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -31,6 +31,11 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+test_lazy_prereq UNZIP '
+ $GIT_UNZIP -v /dev/null 21
+ test $? -ne 127
+'
+
check_zip() {
zipfile=$1.zip
listfile=$1.lst
@@ -201,13 +206,6 @@ test_expect_success \
test_cmp a/substfile2 g/prefix/a/substfile2
'
-$GIT_UNZIP -v /dev/null 21
-if [ $? -eq 127 ]; then
- say Skipping ZIP tests, because unzip was not found
-else
- test_set_prereq UNZIP
-fi
-
test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD d.zip'
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] t5002: check if unzip supports symlinks
Only add a symlink to the repository if both the filesystem and
unzip support symlinks. To check the latter, add a ZIP file
containing a symlink, created like this with InfoZIP zip 3.0:
$ echo sample text textfile
$ ln -s textfile symlink
$ zip -y infozip-symlinks.zip textfile symlink
If we can extract it successfully, we add a symlink to the test
repository for git archive --format=zip, or otherwise skip that
step. Users can see the skipped test and perhaps run it again
with a different unzip version.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t5002-archive-zip.sh | 26 +++---
t/t5002/infozip-symlinks.zip | Bin 0 - 328 bytes
2 files changed, 19 insertions(+), 7 deletions(-)
create mode 100644 t/t5002/infozip-symlinks.zip
diff --git a/t/t5002-archive-zip.sh b/t/t5002-archive-zip.sh
index ac9c6d4..d35aa24 100755
--- a/t/t5002-archive-zip.sh
+++ b/t/t5002-archive-zip.sh
@@ -12,6 +12,15 @@ test_lazy_prereq UNZIP '
test $? -ne 127
'
+test_lazy_prereq UNZIP_SYMLINKS '
+ (
+ mkdir unzip-symlinks
+ cd unzip-symlinks
+ $GIT_UNZIP $TEST_DIRECTORY/t5002/infozip-symlinks.zip
+ test -h symlink
+ )
+'
+
check_zip() {
zipfile=$1.zip
listfile=$1.lst
@@ -40,15 +49,18 @@ test_expect_success \
cp /bin/sh a/bin
printf A\$Format:%s\$O $SUBSTFORMAT a/substfile1
printf A not substituted O a/substfile2
- if test_have_prereq SYMLINKS; then
- ln -s a a/l1
- else
- printf %s a a/l1
- fi
(p=long_path_to_a_file cd a
for depth in 1 2 3 4 5; do mkdir $p cd $p; done
- echo text file_with_long_path)
- (cd a find .) | sort a.lst'
+ echo text file_with_long_path)
+'
+
+test_expect_success SYMLINKS,UNZIP_SYMLINKS 'add symlink' '
+ ln -s a a/symlink_to_a
+'
+
+test_expect_success 'prepare file list' '
+ (cd a find .) | sort a.lst
+'
test_expect_success \
'add ignored file' \
diff --git a/t/t5002/infozip-symlinks.zip b/t/t5002/infozip-symlinks.zip
new file mode 100644
index
..065728c631cf1f7ab20a045a83abc3e08455eeba
GIT binary patch
literal 328
zcmWIWW@h1H0D(ty)tzkeJdg4K*xipAj43ST2YdgnUfkC!pXp_F7Y}5gi9;985mh!
zFf%Z)qyW_wC*~I9q$+@vas|LmdjM@9kbsh4zNiK4D3MDiYs$-GV`**hM5Bm0%0`6
zU={{=Gcw6B8qh;`^jMj32x7rg@*~oQY;CvT2wOgO~;~=j}p2APILS@e1c
U4De=U11V+#!r4H2I*7vn0CeC%rvLx|
literal 0
HcmV?d1
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
On Sun, Jan 06, 2013 at 06:49:00PM +0100, René Scharfe wrote:
This change makes the code smaller and we can put it at the top of
the script, its rightful place as setup code.
Would it be better to add the setting of GIT_UNZIP and
test_lazy_prereq to test-lib.sh so they aren't duplicated in both
t0024-crlf-archive.sh and t5000-tar-tree.sh, something like the
following (modulo UNZIP/GIT_UNZIP)?
--
Matt Kraai
https://ftbfs.org/kraai
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
index ec6c1b3..084f33c 100755
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -3,7 +3,6 @@
test_description='respect crlf in git archive'
. ./test-lib.sh
-UNZIP=${UNZIP:-unzip}
test_expect_success setup '
@@ -26,13 +25,6 @@ test_expect_success 'tar archive' '
'
-$UNZIP -v /dev/null 21
-if [ $? -eq 127 ]; then
- say Skipping ZIP test, because unzip was not found
-else
- test_set_prereq UNZIP
-fi
-
test_expect_success UNZIP 'zip archive' '
git archive --format=zip HEAD test.zip
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index ecf00ed..85b64ae 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,7 +25,6 @@ commit id embedding:
'
. ./test-lib.sh
-UNZIP=${UNZIP:-unzip}
GZIP=${GZIP:-gzip}
GUNZIP=${GUNZIP:-gzip -d}
@@ -201,13 +200,6 @@ test_expect_success \
test_cmp a/substfile2 g/prefix/a/substfile2
'
-$UNZIP -v /dev/null 21
-if [ $? -eq 127 ]; then
- say Skipping ZIP tests, because unzip was not found
-else
- test_set_prereq UNZIP
-fi
-
test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD d.zip'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 8a12cbb..4ceabad 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -752,6 +752,13 @@ test_lazy_prereq AUTOIDENT '
git var GIT_AUTHOR_IDENT
'
+UNZIP=${UNZIP:-unzip}
+
+test_lazy_prereq UNZIP '
+ $UNZIP -v /dev/null 21
+ test $? -ne 127
+'
+
# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
test -w / || test_set_prereq SANITY
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Jonathan Nieder jrnie...@gmail.com writes: 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.) Hmph, so we might see somebody who cares about Cygwin to come up with a solution based on cygcheck (not on uname) to update this part, perhaps on top of Peff's split default settings based on uname into separate file patch? If I understood what Mark and Torsten wrote correctly, you will have the new win32api if you install 1.7.17 (or newer) from scratch, but if you are on older 1.7.x then you can update the win32api part as a package update (as opposed to the whole-system upgrade). A test based on uname -r cannot notice that an older 1.7.x (say 1.7.14) installation has a newer win32api because the user updated it from the package (hence the user should not define CYGWIN_V15_WIN32API). Am I on the same page as you guys, or am I still behind? In the meantime, perhaps we would need something like this? diff --git a/Makefile b/Makefile index 8e225ca..b45b06d 100644 --- a/Makefile +++ b/Makefile @@ -281,6 +281,9 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than +# 1.7.x (this typically is true on Cygwin older than 1.7.17) +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
Adam Spiers g...@adamspiers.org writes:
On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:
Adam Spiers g...@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.
Unless I was mistaken, I never objected to the EXC_CMDL, etc
appearing in the text of the calling site of add_exclude().
The objection was about the .ary[0] bit. From the point of view of
a caller of the API, it:
- calls add_exclude_list() to declare I now start adding new
patterns that come from a new source of patterns; then
- calls add_exclude() repeatedly to add the patterns that come
from that source.
no? Why does the latter has to keep repeating Here is the new
pattern for the EXC_CMDL group; it comes from the latest source I
earlier declared, by the way, instead of just Here is the new
pattern for the EXC_CMDL group? The ary[0] part always using 0
(not 4 or ix) is what repeats that by the way.
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
That is part of the implementation of the machinery. If the API
for the outside callers are to call add_exclude_list() to declare
that patterns added by subsequent calls to add_exclude() are from
one new source of the patterns (e.g. .gitignore file in a new
directory level), and then call add_exclude() to add each pattern,
then the callers to add_exclude() shouldn't have to care about the
implementation detail that individual sources in exclude_list_group
is implemented as an array in that sructure, and the latest ones
should go to its -array[0].
The implementation of the machinery may find it more convenient if
they can add one or more sources to an exclude_list_group before
starting to add patterns to -array[0] or -array[1] or -array[2],
and a finer grained internal API that lets the caller pass an
instance of struct exclude_list regardless of where in an
exclude_list_group's ary[] that instance sits may be necessary to do
so.
But that does not mean other existing callers has to be aware of
such inner detail. If the implementation of the machinery needs a
helper function that adds an element to any struct exclude_list, not
necessarily the one at the tip of an exclude_list_group, we can
still do that by having the bulk of the logic in the internal, finer
grained helper, say, add_pattern_to_exclude_list(), and keep the
external API simpler by making it a thin wrapper around it, perhaps
like:
static void add_pattern_to_exclude_list(const char *pattern,
const char *base, int baselen,
struct exclude_list *el);
void add_exclude(const char *pattern,
const char *base, int baselen,
struct exclude_list_group *group) {
add_pattern_to_exclude_list(pattern, base, baselen, group-ary[0]);
}
no?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] api-allocation-growing.txt: encourage better variable naming
Adam Spiers g...@adamspiers.org writes: The documentation for the ALLOC_GROW API implicitly encouraged developers to use ary as the variable name for the array which is dynamically grown. However ary is an unusual abbreviation hardly used anywhere else in the source tree, and it is also better to name variables based on their contents not on their type. Sounds good. To follow not type but contents, a further rewrite with s/array/item/ is even better, no? I can obviously squash it in without resending, if you agree, or you can point out why item[] is not a good idea and array[] is better. Signed-off-by: Adam Spiers g...@adamspiers.org --- Documentation/technical/api-allocation-growing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 43dbe09..3894815 100644 --- a/Documentation/technical/api-allocation-growing.txt +++ b/Documentation/technical/api-allocation-growing.txt @@ -5,7 +5,9 @@ Dynamically growing an array using realloc() is error prone and boring. Define your array with: -* a pointer (`ary`) that points at the array, initialized to `NULL`; +* a pointer (`array`) that points at the array, initialized to `NULL` + (although please name the variable based on its contents, not on its + type); * an integer variable (`alloc`) that keeps track of how big the current allocation is, initialized to `0`; @@ -13,22 +15,22 @@ Define your array with: * another integer variable (`nr`) to keep track of how many elements the array currently has, initialized to `0`. -Then before adding `n`th element to the array, call `ALLOC_GROW(ary, n, +Then before adding `n`th element to the array, call `ALLOC_GROW(array, n, alloc)`. This ensures that the array can hold at least `n` elements by calling `realloc(3)` and adjusting `alloc` variable. -sometype *ary; +sometype *array; size_t nr; size_t alloc for (i = 0; i nr; i++) - if (we like ary[i] already) + if (we like array[i] already) return; /* we did not like any existing one, so add one */ -ALLOC_GROW(ary, nr + 1, alloc); -ary[nr++] = value you like; +ALLOC_GROW(array, nr + 1, alloc); +array[nr++] = value you like; You are responsible for updating the `nr` variable. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 06.01.13 20:54, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: 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.) Hmph, so we might see somebody who cares about Cygwin to come up with a solution based on cygcheck (not on uname) to update this part, perhaps on top of Peff's split default settings based on uname into separate file patch? If I understood what Mark and Torsten wrote correctly, you will have the new win32api if you install 1.7.17 (or newer) from scratch, but if you are on older 1.7.x then you can update the win32api part as a package update (as opposed to the whole-system upgrade). A test based on uname -r cannot notice that an older 1.7.x (say 1.7.14) installation has a newer win32api because the user updated it from the package (hence the user should not define CYGWIN_V15_WIN32API). Am I on the same page as you guys, or am I still behind? In the meantime, perhaps we would need something like this? diff --git a/Makefile b/Makefile index 8e225ca..b45b06d 100644 --- a/Makefile +++ b/Makefile @@ -281,6 +281,9 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than +# 1.7.x (this typically is true on Cygwin older than 1.7.17) +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # Hm, I haven't understood the connection between the dll (cygwin1.dll ?) which is used in runtime, and the header files which are used when compiling. Are they updated at the same time when updating from 1.7.16 to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks recommendation) this did the trick for me: +ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h //dev/null 2/dev/null echo y),y) + CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be easier to read? +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] api-allocation-growing.txt: encourage better variable naming
On Sun, Jan 06, 2013 at 12:29:33PM -0800, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: The documentation for the ALLOC_GROW API implicitly encouraged developers to use ary as the variable name for the array which is dynamically grown. However ary is an unusual abbreviation hardly used anywhere else in the source tree, and it is also better to name variables based on their contents not on their type. Sounds good. To follow not type but contents, a further rewrite with s/array/item/ is even better, no? I can obviously squash it in without resending, if you agree, or you can point out why item[] is not a good idea and array[] is better. I agree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] api-allocation-growing.txt: encourage better variable naming
Adam Spiers g...@adamspiers.org writes: Sounds good. To follow not type but contents, a further rewrite with s/array/item/ is even better, no? I agree. Thanks for a quick response; let's do this then. -- 8 -- From: Adam Spiers g...@adamspiers.org The documentation for the ALLOC_GROW API implicitly encouraged developers to use ary as the variable name for the array which is dynamically grown. However ary is an unusual abbreviation hardly used anywhere else in the source tree, and it is also better to name variables based on their contents not on their type. Signed-off-by: Adam Spiers g...@adamspiers.org Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/technical/api-allocation-growing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 43dbe09..542946b 100644 --- a/Documentation/technical/api-allocation-growing.txt +++ b/Documentation/technical/api-allocation-growing.txt @@ -5,7 +5,9 @@ Dynamically growing an array using realloc() is error prone and boring. Define your array with: -* a pointer (`ary`) that points at the array, initialized to `NULL`; +* a pointer (`item`) that points at the array, initialized to `NULL` + (although please name the variable based on its contents, not on its + type); * an integer variable (`alloc`) that keeps track of how big the current allocation is, initialized to `0`; @@ -13,22 +15,22 @@ Define your array with: * another integer variable (`nr`) to keep track of how many elements the array currently has, initialized to `0`. -Then before adding `n`th element to the array, call `ALLOC_GROW(ary, n, +Then before adding `n`th element to the item, call `ALLOC_GROW(item, n, alloc)`. This ensures that the array can hold at least `n` elements by calling `realloc(3)` and adjusting `alloc` variable. -sometype *ary; +sometype *item; size_t nr; size_t alloc for (i = 0; i nr; i++) - if (we like ary[i] already) + if (we like item[i] already) return; /* we did not like any existing one, so add one */ -ALLOC_GROW(ary, nr + 1, alloc); -ary[nr++] = value you like; +ALLOC_GROW(item, nr + 1, alloc); +item[nr++] = value you like; You are responsible for updating the `nr` variable. -- 1.8.1.302.g0f4eaa7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 02:54 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: 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.) Hmph, so we might see somebody who cares about Cygwin to come up with a solution based on cygcheck (not on uname) to update this part, perhaps on top of Peff's split default settings based on uname into separate file patch? If I understood what Mark and Torsten wrote correctly, you will have the new win32api if you install 1.7.17 (or newer) from scratch, but if you are on older 1.7.x then you can update the win32api part as a package update (as opposed to the whole-system upgrade). A test based on uname -r cannot notice that an older 1.7.x (say 1.7.14) installation has a newer win32api because the user updated it from the package (hence the user should not define CYGWIN_V15_WIN32API). Am I on the same page as you guys, or am I still behind? In the meantime, perhaps we would need something like this? diff --git a/Makefile b/Makefile index 8e225ca..b45b06d 100644 --- a/Makefile +++ b/Makefile @@ -281,6 +281,9 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than +# 1.7.x (this typically is true on Cygwin older than 1.7.17) +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # Looking at a current setup.ini, the obsolete win32 api is a single package w32api with last version 3.17-2, and is now replaced by the new win32 api is in two packages, w32api-headers + w32api-runtime, both at version 3.0b_svn5496-1. If setup.exe updated an older installation of w32api, the old package is not deleted, but replaced by a special empty package with (as of today) version -1. Note that all of this could change at any time. Also, note that the new w32api packages have version numbers that are lower than the older obsoleted version. Running cygcheck -c w32api w32api-headers w32api-runtime on one machine gives Cygwin Package Information Package VersionStatus w32api -1 OK w32api-headers 3.0b_svn5496-1 OK w32api-runtime 3.0b_svn5496-1 OK So now, what do folks propose checking for? a) w32api is installed? Nope - the package is not removed, it was updated to a special empty version to delete its former contents, but a new fresh installation won't have this. b) w32api-headers is installed? Nope - what happens on the next repackaging? c) w32api version is -1? Maybe, but that number could change. etc. There is no documented, reliable, future-proof, method of determining the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. I really think the only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. So, in the makefile, you might add: +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. But, the recommended approach is to +# update your installation if compilation errors occur. +# Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Mark Levedahl Sent: Sunday, January 06, 2013 16:10 To: Junio C Hamano Cc: Jonathan Nieder; Torsten Bögershausen; Stephen Linda Smith; Jason Pyeron; git@vger.kernel.org; Eric Blake Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14 On 01/06/2013 02:54 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: 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.) Hmph, so we might see somebody who cares about Cygwin to come up with a solution based on cygcheck (not on uname) to update this part, perhaps on top of Peff's split default settings based on uname into separate file patch? If I understood what Mark and Torsten wrote correctly, you will have the new win32api if you install 1.7.17 (or newer) from scratch, but if you are on older 1.7.x then you can update the win32api part as a package update (as opposed to the whole-system upgrade). A test based on uname -r cannot notice that an older 1.7.x (say 1.7.14) installation has a newer win32api because the user updated it from the package (hence the user should not define CYGWIN_V15_WIN32API). Am I on the same page as you guys, or am I still behind? In the meantime, perhaps we would need something like this? diff --git a/Makefile b/Makefile index 8e225ca..b45b06d 100644 --- a/Makefile +++ b/Makefile @@ -281,6 +281,9 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older +than # 1.7.x (this typically is true on Cygwin older than 1.7.17) # # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # Looking at a current setup.ini, the obsolete win32 api is a single package w32api with last version 3.17-2, and is now replaced by the new win32 api is in two packages, w32api-headers + w32api-runtime, both at version 3.0b_svn5496-1. If setup.exe updated an older installation of w32api, the old package is not deleted, but replaced by a special empty package with (as of today) version -1. Note that all of this could change at any time. Also, note that the new w32api packages have version numbers that are lower than the older obsoleted version. I would not rely on that information as it is not designed to convey the information the git build needs. Running cygcheck -c w32api w32api-headers w32api-runtime on one machine gives Cygwin Package Information Package VersionStatus w32api -1 OK w32api-headers 3.0b_svn5496-1 OK w32api-runtime 3.0b_svn5496-1 OK So now, what do folks propose checking for? a) w32api is installed? Nope - the package is not removed, it was updated to a special empty version to delete its former contents, but a new fresh installation won't have this. b) w32api-headers is installed? Nope - what happens on the next repackaging? c) w32api version is -1? Maybe, but that number could change. etc. This is what is typically done in a configure script by test compiling. There is no documented, reliable, future-proof, method of determining the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. I really think the only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. So, in the makefile, you might add: +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. But, the recommended approach is +to # update your installation if compilation errors occur. +# -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - -
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 03:51 PM, Torsten Bögershausen wrote: Hm, I haven't understood the connection between the dll (cygwin1.dll ?) which is used in runtime, and the header files which are used when compiling. Are they updated at the same time when updating from 1.7.16 to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks recommendation) this did the trick for me: +ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h //dev/null 2/dev/null echo y),y) + CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be easier to read? +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16 The cygwin distribution has a very large number of packages, each with its own unique version number and update rhythm, just as in any linux distro. There is no cygwin version, just a version for each individual package. So, Cygwin version 1.7.16 is really nonsensical: there is only cygwin.dll version 1.7.16. What folks are noticing is a coincidence in the time when the cygwin dll package updated and when the old w32api was obsoleted. uname -r reports the cygwin dll version, not the version of any other package. Note that the cygwin api is stable, meaning a package compiled against the 1.7.1 dll will still run against the current one: updating the cygwin dll does not require other packages to update. The only hard linkage here is that the Cygwin developers are maintaining a legacy cygwin version (v1.5.x) as the newer dll series (v.1.7.x) dropped support for all Windows versions predating (I think) WinXP. So, someone on an old Windows version must use the legacy cygwin version which has not been updated since the first v1.7 dll was released, nor are there any plans by the developers to ever update the v1.5 packages. Cygwin 1.5 lives in a separate distribution repository, with packages frozen in time as of the last updates prior to going to v1.7 (packages compiled against v1.7 will not run on v.1.5). So, encountering a v1.5.x dll is a guarantee of using the older w32api shared with the mingw project, rather than the current one now maintained by the mingw64 project. However, a cygwin with any v1.7.x dll could in theory have either w32api installed, or in theory yet another newer one we don't know about yet. Unless and until the w32api establishes a version number (independent of the Windows API version), we have nothing reliable to use. Therefore, if using the v1.7 series, *update* Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Thanks; so perhaps you can give me an OK to forge your S-o-b to the following? -- 8 -- From: Mark Levedahl mleved...@gmail.com Date: Sun, 6 Jan 2013 11:56:33 -0800 Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. The only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. Signed-off-by: Mark Levedahl mleved...@gmail.com --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4d47af5..52e298a 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,10 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. The recommended approach, however, +# is to update your installation if compilation errors occur. +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # -- 1.8.1.302.g0f4eaa7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] struct pathspec conversion
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This is another step towards the pathspec unification. This series introduces a get_pathspec() alternative: parse_pathspec(). The new function intializes struct pathspec directly. Many builtin commands (except mv) are converted to use this function. As a result, struct pathspec is used from the start for many commands. The next step would be dealing with pathspec manipulation code blocks that use raw field, init_pathspec or get_pathspec(). add.c, dir.c, rm.c and mv.c are hot places. And perhaps move pathspec code from dir.c and setup.c to pathspec.c after as/check-ignore enters master. This series shares a patch (the first one) with nd/pathspec-wildcard. I put the patch in the series to avoid dependency. This series also disables wildcards in the prefix part, but it's only effective in combination with nd/pathspec-wildcard. And of course it's not fully effective until all raw use is eliminated. Yay! Thanks, looking forward to reading it through. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
-Original Message- From: Junio C Hamano Sent: Sunday, January 06, 2013 16:36 Thanks; so perhaps you can give me an OK to forge your S-o-b to the following? I am personally fine with it, because cygwin is used by developers not production systems and I expect my developers to upgrade their environment for security fixes, etc. If I ever had a situation where I am using git, in production, on cygwin, where I could not upgrade I would effort to make a compile test based patch to the make file to accommodate the issue. -- 8 -- From: Mark Levedahl mleved...@gmail.com Date: Sun, 6 Jan 2013 11:56:33 -0800 Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. The only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. Signed-off-by: Mark Levedahl mleved...@gmail.com --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4d47af5..52e298a 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,10 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. The recommended approach, however, +# is to update your installation if compilation errors occur. +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # -- 1.8.1.302.g0f4eaa7 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 04:35 PM, Junio C Hamano wrote: Thanks; so perhaps you can give me an OK to forge your S-o-b to the following? -- 8 -- From: Mark Levedahl mleved...@gmail.com Date: Sun, 6 Jan 2013 11:56:33 -0800 Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. The only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. Signed-off-by: Mark Levedahl mleved...@gmail.com --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4d47af5..52e298a 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,10 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. The recommended approach, however, +# is to update your installation if compilation errors occur. +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # Absolutely, that is ok by me. Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] status: always report ignored tracked directories
Tracked directories (i.e. directories containing tracked files) that
are ignored must be reported as ignored if they contain untracked files.
Currently, files in the index can't be reported as ignored and are
automatically dropped from the list:
- When core.ignorecase is false, directories (which are not directly
tracked) are not listed as part of the index, and the directory can be
shown as ignored.
- When core.ignorecase is true on the other hand, directories are
reported as part of the index, and the directory is dropped, thus not
displayed as ignored.
Fix that behavior by allowing indexed file to be added when looking for
ignored files.
- Ignored tracked and untracked directories are treated the same way
when looking for ignored files, so we should not care about their index
status.
- Files are dismissed by treat_file() if they belong to the
index, so that step would have been a no-op anyway.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
dir.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index 9b80348..f836590 100644
--- a/dir.c
+++ b/dir.c
@@ -672,7 +672,8 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (cache_name_exists(pathname, len, ignore_case))
+ if (!(dir-flags DIR_SHOW_IGNORED)
+ cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -877,11 +878,7 @@ static int treat_file(struct dir_struct *dir, struct
strbuf *path, int exclude,
if (exclude)
exclude_file = !(dir-flags DIR_SHOW_IGNORED);
else if (dir-flags DIR_SHOW_IGNORED) {
- /*
-* Optimization:
-* Don't spend time on indexed files, they won't be
-* added to the list anyway
-*/
+ /* Always exclude indexed files */
struct cache_entry *ce = index_name_exists(the_index,
path-buf, path-len, ignore_case);
--
1.7.12.4.3.g90f5e2d
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
On Sun, Jan 06, 2013 at 12:25:48PM -0800, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:
Adam Spiers g...@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.
Unless I was mistaken, I never objected to the EXC_CMDL, etc
appearing in the text of the calling site of add_exclude().
The objection was about the .ary[0] bit. From the point of view of
a caller of the API, it:
- calls add_exclude_list() to declare I now start adding new
patterns that come from a new source of patterns; then
- calls add_exclude() repeatedly to add the patterns that come
from that source.
no?
Correct.
Why does the latter has to keep repeating Here is the new
pattern for the EXC_CMDL group; it comes from the latest source I
earlier declared, by the way, instead of just Here is the new
pattern for the EXC_CMDL group?
Mainly because there is no guarantee that such a group exists.
unpack_trees() has:
if (add_excludes_from_file_to_list(git_path(info/sparse-checkout),
, 0, el, 0) 0)
so if you change the signature of add_exclude() to require an
exclude_list_group, then there is no way to implement
add_excludes_from_file_to_list().
Even if you could, you still haven't reduced the number of parameters
add_exclude() requires, so I'm dubious of the benefits of this
simplification.
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
That is part of the implementation of the machinery. If the API
for the outside callers are to call add_exclude_list() to declare
that patterns added by subsequent calls to add_exclude() are from
one new source of the patterns (e.g. .gitignore file in a new
directory level), and then call add_exclude() to add each pattern,
then the callers to add_exclude() shouldn't have to care about the
implementation detail that individual sources in exclude_list_group
is implemented as an array in that sructure, and the latest ones
should go to its -array[0].
That's a valid point. However, the ary[0] part which assumes external
knowledge of the internal implementation can trivially be avoided by
squashing this patch onto the commit we are discussing:
diff --git a/builtin/clean.c b/builtin/clean.c
index dd89737..6e21ca6 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -45,6 +45,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+ struct exclude_list *el;
const char *qname;
char *seen = NULL;
struct option options[] = {
@@ -97,10 +98,9 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (!ignored)
setup_standard_excludes(dir);
- add_exclude_list(dir, EXC_CMDL);
+ el = 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_group[EXC_CMDL].el[0]);
+ add_exclude(exclude_list.items[i].string, , 0, el);
pathspec = get_pathspec(prefix, argv);
and by adopting the same approach for ls-files.c:
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 0ca9d8e..0406adc 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -420,10 +420,11 @@ 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_group *group = opt-value;
+ struct string_list
Re: [PATCH] git-fast-import(1): reorganise options
John Keeping j...@keeping.me.uk writes: On Sun, Jan 06, 2013 at 05:51:09AM -0800, Jonathan Nieder wrote: ... 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 Sounds sensible and I like the direction in which this discussion is progressing. 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. I'll leave it to others to decide which individual options would fall into that catch-all category, but the idea you outlined above sounds sensible overall. 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 Again, sounds sensible. 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). I tend to agree with Jonathan that verbosity options are less important ones than the ones that affect how things work. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: forbid --bare --separate-git-dir dir
Jonathan Nieder jrnie...@gmail.com writes: 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 pclo...@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? I do not necessarily think we must say it happens not to work already for such and such reasons, lucky us!, but it is indeed a good idea to think things through, justifying why this cannot be a regression, and record the fact that we did that thinking, in the log message. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
On Sun, Jan 06, 2013 at 10:53:11PM +, Adam Spiers wrote:
That's a valid point. However, the ary[0] part which assumes external
knowledge of the internal implementation can trivially be avoided by
squashing this patch onto the commit we are discussing:
[snipped]
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 0ca9d8e..0406adc 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -420,10 +420,11 @@ 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_group *group = opt-value;
+ struct string_list *exclude_list = opt-value;
exc_given = 1;
- add_exclude(arg, , 0, group-el[0]);
+ string_list_append(exclude_list, arg);
+ fprintf(stderr, append %s\n, arg);
Whoops :-)
[snipped]
@@ -524,9 +527,13 @@ int cmd_ls_files(int argc, const char **argv, const char
*cmd_prefix)
if (read_cache() 0)
die(index file corrupt);
- add_exclude_list(dir, EXC_CMDL);
argc = parse_options(argc, argv, prefix, builtin_ls_files_options,
ls_files_usage, 0);
+ el = add_exclude_list(dir, EXC_CMDL);
+ for (i = 0; i exclude_list.nr; i++) {
+ fprintf(stderr, adding exclude: %s\n,
exclude_list.items[i].string);
Excluding those two fprintf() calls, of course :-)
I've removed them, and pushed to my github fork a new version of v4
with the fixed version of this patch inserted in the appropriate place
(and labelled with a [SQUASH] prefix):
git://github.com/aspiers/git.git
https://github.com/aspiers/git/commits/check-ignore
Since I sent v4 earlier today, to avoid spamming this list, I won't
resend the whole series yet - not until we have made some progress in
reviewing v4.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
Adam Spiers g...@adamspiers.org writes:
That's a valid point. However, the ary[0] part which assumes external
knowledge of the internal implementation can trivially be avoided by
squashing this patch onto the commit we are discussing:
diff --git a/builtin/clean.c b/builtin/clean.c
index dd89737..6e21ca6 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -45,6 +45,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+ struct exclude_list *el;
const char *qname;
char *seen = NULL;
struct option options[] = {
@@ -97,10 +98,9 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (!ignored)
setup_standard_excludes(dir);
- add_exclude_list(dir, EXC_CMDL);
+ el = 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_group[EXC_CMDL].el[0]);
+ add_exclude(exclude_list.items[i].string, , 0, el);
pathspec = get_pathspec(prefix, argv);
and by adopting the same approach for ls-files.c:
That is _much_ more readable and easier to explain in the API
documentation, I think.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: manpage XML depends on asciidoc.conf
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] git-clean: Display more accurate delete messages
(1) Only print out the names of the files and directories that got
actually deleted.
(2) Show warning message for ignored untracked git repositories
Consider the following repo layout:
test.git/
|-- tracked_dir/
| |-- some_tracked_file
| |-- some_untracked_file
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| |-- frotz.tx
|-- untracked_some.git/
|-- some.txt
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/
Removing untracked_some.git/
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
to run in both dry_run and delete modes with the delete logic as
follows:
(a) Check if the current directory to be deleted is an untracked
git repository. If it is and --force --force option is not set
do not touch this directory, print ignore message, set dir_gone
flag to false for the caller and return.
(b) Otherwise for each item in current directory:
(i) If current directory cannot be accessed, print warning,
set dir_gone flag to false and return.
(ii) If the item is a subdirectory recurse into it,
check for the returned value of the dir_gone flag.
If the subdirectory is gone, add the name of the deleted
directory to a list of successfully removed items 'dels'.
Else set the dir_gone flag as the current directory
cannot be removed because we have at least one subdirectory
hanging around.
(iii) If it is a file try to remove it. If success add the
file name to the 'dels' list, else print error and set
dir_gone flag to false.
(c) After we finished deleting all items in the current directory and
the dir_gone flag is still true, remove the directory itself.
If failed set the dir_gone flag to false.
(d) If the current directory cannot be deleted because the dir_gone flag
has been set to false, print out all the successfully deleted items
for this directory from the 'dels' list.
(e) We're done with the current directory, return.
(2) Modify the cmd_clean() function to:
(a) call the recursive delete function 'remove_dirs()' for each
topmost directory it wants to remove
(b) check for the returned value of dir_gone flag. If it's true
print the name of the directory as being removed.
Consider the output of the improved version:
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
warning: ignoring untracked git repository untracked_foo/frotz.git
Removing untracked_foo/bar
Removing untracked_foo/emptydir
warning: ignoring untracked git repository untracked_some.git/
Now it displays only the file and directory names that got actually
deleted and shows warnings about ignored untracked git repositories.
Reported-by: Soren Brinkmann soren.brinkm...@xilinx.com
Signed-off-by: Zoltan Klinger zoltan.klin...@gmail.com
---
builtin/clean.c | 158 +--
1 file changed, 129 insertions(+), 29 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..1714546 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -10,6 +10,7 @@
#include cache.h
#include dir.h
#include parse-options.h
+#include refs.h
#include string-list.h
#include quote.h
@@ -20,6 +21,12 @@ static const char *const builtin_clean_usage[] = {
NULL
};
+static const char *msg_remove = N_(Removing %s\n);
+static const char *msg_would_remove = N_(Would remove %s\n);
+static const char *msg_would_ignore_git_dir = N_(Would ignore untracked git
repository %s\n);
+static const char
Re: [PATCH v4] git-clean: Display more accurate delete messages
Zoltan Klinger wrote: $ git clean -fd Removing tracked_dir/some_untracked_file Removing untracked_file Removing untracked_foo/ Removing untracked_some.git/ The message displayed to the user is slightly misleading. The foo/ directory has not been removed because of foo/frotz.git still exists. On the other hand the subdirectories 'bar' and 'emptydir' have been deleted but they're not mentioned anywhere. Also, untracked_some.git has not been removed either. [...] Consider the output of the improved version: $ git clean -fd Removing tracked_dir/some_untracked_file Removing untracked_file warning: ignoring untracked git repository untracked_foo/frotz.git Removing untracked_foo/bar Removing untracked_foo/emptydir warning: ignoring untracked git repository untracked_some.git/ Thanks, this looks like a nice improvement. I wonder whether it's possible to make the output more consistent, as in: Removing tracked_dir/some_untracked_file Removing untracked_file Skipping repository untracked_foo/frotz.git Removing untracked_foo/bar Removing untracked_foo/emptydir Skipping repository untracked_some.git or similar. What do you think? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Moving (renaming) submodules, recipe/script
Today I had to move my first submodule, and I discovered that Git's support for this is pretty limited. There have been a few patch series attempting to address this [1,2], but none of them seems to have pushed through into master (although I can't put my finger on a reason for why). There are also some SO postings discussing this [3,4]. It would be nice if `git mv` worked out of the box on submodules. Failing that, there could be a `git submodule mv` command that casts the appropriate spell. Failing that, there could be a recipe in Documentation/git-submodule.txt. Here's the best I could come up with for a `git-submodule-mv.sh`: #!/bin/sh # usage: git-submodule-mv.sh OLD NEW OLD=$(realpath --relative-to . $1) NEW=$(realpath --relative-to . $2) SHA=$(git ls-files -s $OLD | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|') NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' $OLD | sed -e 's|^submodule.||' -e s|.path $OLD\$||) GITDIR=$(realpath --relative-to $NEW .git/modules/$NAME) git config -f .gitmodules submodule.$NAME.path $NEW git config -f .git/modules/$NAME/config core.worktree ../../../$NEW git rm --cached $OLD mv $OLD $NEW echo gitdir: $GITDIR $NEW/.git git update-index --add --cacheinfo 16 $SHA $NEW This only works from the repository root directory, and I'm sure makes a number of poor assumptions (e.g. old-style submodules that don't use `gitdir` links are not supported). It does work for some simple test cases. The tricky parts (e.g. path - name conversion) are already worked out more robustly git-submodule.sh, so adding a new cmd_mv shouldn't be very difficult. Could something like this live somewhere in Git, or are we waiting for a more integrated solution? Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720 [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250 [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH 03/21] pathspec: make sure the prefix part is wildcard-clean
On Sun, Jan 6, 2013 at 1:20 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: --- a/setup.c +++ b/setup.c @@ -250,6 +250,8 @@ static unsigned prefix_pathspec(struct pathspec_item *item, *raw = item-match; item-len = strlen(item-match); item-nowildcard_len = simple_length(item-match); + if (item-nowildcard_len prefixlen) + item-nowildcard_len = prefixlen; return magic; } This is wrong (so much for the last-minute patch). Prefix length depends on actual pathspec (e.g. abc, ../abc and ../../abc use different prefix length). This patch should be discarded (it does not have any real impacts anyway). -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: forbid --bare --separate-git-dir dir
On Mon, Jan 7, 2013 at 6:13 AM, Junio C Hamano gits...@pobox.com wrote: 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? I do not necessarily think we must say it happens not to work already for such and such reasons, lucky us!, but it is indeed a good idea to think things through, justifying why this cannot be a regression, and record the fact that we did that thinking, in the log message. Thanks. I wanted to give a day or two or think about the explanation here. Does Thanks. mean you have picked up the patch and adjusted the commit message appropriately, or should I go with my original plan and resend it later with explanantion there? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving (renaming) submodules, recipe/script
(just cc-ing Jens and Peter, who might be interested) W. Trevor King wrote: Today I had to move my first submodule, and I discovered that Git's support for this is pretty limited. There have been a few patch series attempting to address this [1,2], but none of them seems to have pushed through into master (although I can't put my finger on a reason for why). There are also some SO postings discussing this [3,4]. It would be nice if `git mv` worked out of the box on submodules. Failing that, there could be a `git submodule mv` command that casts the appropriate spell. Failing that, there could be a recipe in Documentation/git-submodule.txt. Here's the best I could come up with for a `git-submodule-mv.sh`: #!/bin/sh # usage: git-submodule-mv.sh OLD NEW OLD=$(realpath --relative-to . $1) NEW=$(realpath --relative-to . $2) SHA=$(git ls-files -s $OLD | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|') NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' $OLD | sed -e 's|^submodule.||' -e s|.path $OLD\$||) GITDIR=$(realpath --relative-to $NEW .git/modules/$NAME) git config -f .gitmodules submodule.$NAME.path $NEW git config -f .git/modules/$NAME/config core.worktree ../../../$NEW git rm --cached $OLD mv $OLD $NEW echo gitdir: $GITDIR $NEW/.git git update-index --add --cacheinfo 16 $SHA $NEW This only works from the repository root directory, and I'm sure makes a number of poor assumptions (e.g. old-style submodules that don't use `gitdir` links are not supported). It does work for some simple test cases. The tricky parts (e.g. path - name conversion) are already worked out more robustly git-submodule.sh, so adding a new cmd_mv shouldn't be very difficult. Could something like this live somewhere in Git, or are we waiting for a more integrated solution? Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720 [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250 [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggested improvements to the git-p4 documentation (branch-related)
2013/1/5 Pete Wyckoff p...@padd.com: sh...@keba.be wrote on Thu, 03 Jan 2013 15:58 -0500: While struggling to get git-p4 to work properly with branches, I thought the documentation on http://git-scm.com/docs/git-p4 could use some improvements: Thanks, I definitely appreciate the constructive comments here. 1. At the end of the Branch detection section, the following commands are provided (for when you want to explicitly provide branch mappings to git-p4): git config git-p4.branchList main:branch1 git p4 clone --detect-branches //depot@all The second command should end with a dot (.) because the first command only works if you are already in a git-initialized folder. Thus I would also suggest to add git init as first command to type. That is confusing. I'll make it this: git init depot cd depot git config git-p4.branchList main:branch1 git p4 clone --detect-branches //depot@all . Sounds good, thanks. 2. Even though having a main branch is standard in Perforce, it would be worth mentioning what happens when you don't: there is a message Could not detect main branch. No checkout/master branch created output by the git p4 clone command. However, it will still work if you manually set the master branch (git checkout -b master remotes/p4/my_custom_main_branch). This feels like a bug to me, and indeed I had an old patch series that planned to fix it. Let me knock that into shape, instead of changing the documentation. It will automatically do the checkout step you did. Sounds good as well. 3. I don't know what I missed for that one, but I haven't been able to get the example for the --branch option to work. It says that after git init, we can import a p4 branch with: git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 However, after doing this, followed by git checkout -b proj2 remotes/p4/proj2, I am unable to properly use git p4 sync or git p4 submit from this branch, as git complains about a missing refs/remotes/p4/master. Yes, also annoying. I have a failing test case for this, but haven't fixed it yet. The idea is that git p4 sync --branch=proj2 will sync refs/remotes/p4/proj2. If there is no p4/master, and you don't specify --branch, it will fail with a more useful error message. Good too! For submit, there is code that walks from your current branch back in history until it finds a commit on a known p4 remote branch. This is sort of like the merge-base calculation in git, but restricted to a linear history. I haven't tested that recently, but will add a test and fix it if needed too. Please do feel welcome to to rearrange or expand the documentation so it makes more sense, if you are so inspired. I'm afraid I'm not familiar enough with git documentation to dig into it myself, but anyway that's about what I had for now. I'll send more comments to the mailing list if I have more suggestions in the future. Thanks for a great tool! :) -=- Olivier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-send-email: treat field names as case-independent
Field names like To:, Cc:, etc should be treated as case-independent;
use a case-insensitive regexp to match them as such. Previously,
git-send-email would send email messages with a lowercase cc: line in
the body without actually sending a copy of the message to that address.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
git-send-email.perl | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94c7f76..be809e5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1285,10 +1285,10 @@ foreach my $t (@files) {
}
if (defined $input_format $input_format eq 'mbox') {
- if (/^Subject:\s+(.*)$/) {
+ if (/^Subject:\s+(.*)$/i) {
$subject = $1;
}
- elsif (/^From:\s+(.*)$/) {
+ elsif (/^From:\s+(.*)$/i) {
($author, $author_encoding) =
unquote_rfc2047($1);
next if $suppress_cc{'author'};
next if $suppress_cc{'self'} and $author eq
$sender;
@@ -1296,14 +1296,14 @@ foreach my $t (@files) {
$1, $_) unless $quiet;
push @cc, $1;
}
- elsif (/^To:\s+(.*)$/) {
+ elsif (/^To:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
printf((mbox) Adding to: %s from line
'%s'\n,
$addr, $_) unless $quiet;
push @to, $addr;
}
}
- elsif (/^Cc:\s+(.*)$/) {
+ elsif (/^Cc:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
if (unquote_rfc2047($addr) eq $sender) {
next if ($suppress_cc{'self'});
@@ -1325,7 +1325,7 @@ foreach my $t (@files) {
elsif (/^Message-Id: (.*)/i) {
$message_id = $1;
}
- elsif (!/^Date:\s/ /^[-A-Za-z]+:\s+\S/) {
+ elsif (!/^Date:\s/i /^[-A-Za-z]+:\s+\S/) {
push @xh, $_;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: forbid --bare --separate-git-dir dir
Duy Nguyen pclo...@gmail.com writes: On Mon, Jan 7, 2013 at 6:13 AM, Junio C Hamano gits...@pobox.com wrote: 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? I do not necessarily think we must say it happens not to work already for such and such reasons, lucky us!, but it is indeed a good idea to think things through, justifying why this cannot be a regression, and record the fact that we did that thinking, in the log message. Thanks. I wanted to give a day or two or think about the explanation here. Does Thanks. mean you have picked up the patch and adjusted the commit message appropriately, or should I go with my original plan and resend it later with explanantion there? The latter, Thanks for a review. I may have picked it up in 'pu', but that merely means, as usual, that I wanted to add a reminder in What's cooking to expect a reroll, and nothing more. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git push --force to update tag
about git 1.8.2 * git push now requires -f to update a tag, even if it is a fast-forward, as tags are meant to be fixed points. Does the server side validate this? Do we need to upgrade git on server side to support this? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jan 2013, #03; Sun, 6)
What's cooking in git.git (Jan 2013, #03; Sun, 6) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of 'next' will be rewound and rebuilt shortly, kicking a couple of topics back to 'pu' and reordering the remainder as needed. As usual, this cycle is expected to last for 8 to 10 weeks. To ensure the quality of the end result, let's merge topics in flight earlier than previous cycles to 'next' and fix issues in-tree. 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] * 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. * 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 Various updates to fast-export used in the context of the remote helper interface. * 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. * 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. * 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. * 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 fooTAB into a refname that begins with foo. * jk/error-const-return (2012-12-15) 2 commits (merged to 'next' on 2012-12-22 at bf2b1cd) + 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. * 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 * 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. * 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
Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
I forgot to say that tonight's 'pu' seems to break t0008 and does not pass the self-test. I didn't try figuring out if this is the result of some mismerge, or one (or more) of the topics are broken. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: treat field names as case-independent
Nickolai Zeldovich nicko...@csail.mit.edu writes:
Field names like To:, Cc:, etc should be treated as case-independent;
use a case-insensitive regexp to match them as such. Previously,
git-send-email would send email messages with a lowercase cc: line in
the body without actually sending a copy of the message to that address.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
While I think this patch is a sensible thing to do, I at the same
time wonder who is writing cc: in the lowercase in the first
place, and if that is one of our tools, we should fix that part as
well. Such a header would leak out to the payload given to the
underlying sendmail, doesn't it?
Leaking such lowercased headers of course is not a crime (the
headers are case insensitive), but they look ugly.
git-send-email.perl | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94c7f76..be809e5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1285,10 +1285,10 @@ foreach my $t (@files) {
}
if (defined $input_format $input_format eq 'mbox') {
- if (/^Subject:\s+(.*)$/) {
+ if (/^Subject:\s+(.*)$/i) {
$subject = $1;
}
- elsif (/^From:\s+(.*)$/) {
+ elsif (/^From:\s+(.*)$/i) {
($author, $author_encoding) =
unquote_rfc2047($1);
next if $suppress_cc{'author'};
next if $suppress_cc{'self'} and $author eq
$sender;
@@ -1296,14 +1296,14 @@ foreach my $t (@files) {
$1, $_) unless $quiet;
push @cc, $1;
}
- elsif (/^To:\s+(.*)$/) {
+ elsif (/^To:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
printf((mbox) Adding to: %s from line
'%s'\n,
$addr, $_) unless $quiet;
push @to, $addr;
}
}
- elsif (/^Cc:\s+(.*)$/) {
+ elsif (/^Cc:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
if (unquote_rfc2047($addr) eq $sender) {
next if ($suppress_cc{'self'});
@@ -1325,7 +1325,7 @@ foreach my $t (@files) {
elsif (/^Message-Id: (.*)/i) {
$message_id = $1;
}
- elsif (!/^Date:\s/ /^[-A-Za-z]+:\s+\S/) {
+ elsif (!/^Date:\s/i /^[-A-Za-z]+:\s+\S/) {
push @xh, $_;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: treat field names as case-independent
On Sun, Jan 6, 2013 at 10:27 PM, Junio C Hamano gits...@pobox.com wrote: While I think this patch is a sensible thing to do, I at the same time wonder who is writing cc: in the lowercase in the first place, and if that is one of our tools, we should fix that part as well. Such a header would leak out to the payload given to the underlying sendmail, doesn't it? In my case, I wrote the cc: headers by hand; it was not a result of any automated tool. (Yes, the header makes it into the message payload. This makes the bug all the more annoying: other people's replies get cc:ed to the right address, but the original message never gets sent there.) Nickolai. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push --force to update tag
On Sun, Jan 6, 2013 at 8:23 PM, 乙酸鋰 ch3co...@gmail.com wrote: about git 1.8.2 * git push now requires -f to update a tag, even if it is a fast-forward, as tags are meant to be fixed points. Does the server side validate this? Do we need to upgrade git on server side to support this? This check is made by the side doing the push. There is no additional validation done on the remote side so it does not need an updated version of Git for this feature to work correctly. Chris -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
recovering a corrupted git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have not had any issue until I ran a git fsck recently, which repored gzip and crc errors in some pack files. git fsck does not seem to repair the errors, only report them. I would like to try to rebuild my repository, without downloading any more from the origin than I have to. All of the commits I have added seem to still be intact, so I assume the corruption in somewhere in the upstream history packs. How can I correct the errors, and fetch the corrupted upstream history, while preserving my patches? So far I have exported my patches as bundles, and made a fresh clone from upstream, then pulled the bundles back in, but there must be a better way that only fetches the corrupted bits from upstream? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ6kS6AAoJEJrBOlT6nu75tFgIAJCI+DEWDVxddEQM5qhmz1y8 3JuqjTHp7gIXmQv6WGbEIehJrRfTBudQn+Ip2jLMwavvL16oZe+cf/uuLo393Z+T pxEcWHOtjdU/XZeQOV//R/Cfo7PY5n8wfasgFYZuFesJchInwFocTI6S5x2B9kIB dvLonoiDQwe9JqQaoAxM0OLTWe9aj0gc3c36+WUlRgRZijUhEogYQwU8aEoa+TMq s2p+tbaNYKocRAafQ4824DMnuQTWb+HJVU4uI1pH2yB964Urq9ELSX2jxeSRdlaH d+AoJ8oMdymmUwPeuyivcmQQHEGGsxxgCOuLSSHh1hcxMaytZNcEkVQ6OzuGyZk= =yUr4 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
René Scharfe wrote:
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's unzip it would try to extract
from itself (because it treats the contents of $UNZIP as parameters),
which failed of course.
That would only happen if the UNZIP variable was already exported,
right?
The patch makes sense and takes care of all uses of ${UNZIP} I can
find, and it even makes the quoting consistent so a person can put
their copy of unzip under /Program Files. For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Nike Air Max Shop
Is there a practical way to eliminate the spam here? Could vger.kernel.org use a postini (list maintainers contact me offline about this) account? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
-Original Message- From: Mark Levedahl Sent: Sunday, January 06, 2013 17:17 On 01/06/2013 02:54 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: 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.) Hmph, so we might see somebody who cares about Cygwin to come up with a solution based on cygcheck (not on uname) to update this part, perhaps on top of Peff's split default settings based on uname into separate file patch? If I understood what Mark and Torsten wrote correctly, you will have the new win32api if you install 1.7.17 (or newer) from scratch, but if you are on older 1.7.x then you can update the win32api part as a package update (as opposed to the whole-system upgrade). A test based on uname -r cannot notice that an older 1.7.x (say 1.7.14) installation has a newer win32api because the user updated it from the package (hence the user should not define CYGWIN_V15_WIN32API). Am I on the same page as you guys, or am I still behind? In the meantime, perhaps we would need something like this? It's perhaps worth noting how we got into this mess. The problems have their root in adbc0b6b6e57c11ca49779d01f549260a920a97d Cygwin's entire goal is a completely POSIX compliant environment running under Windows. The above commit circumvents some of Cygwin's API regarding stat/fstat to make things perhaps a bit faster, and definitely not POSIX Ug! compliant (The commit message is wrong, the commit definitely breaks POSIX compliance). That code is also what will not compile on different w32api versions. It is curious: the Cygwin mailing list has been absolutely silent since the w32api change was introduced last summer, this is the only piece of code I am aware of that was broken by the new headers, and of course the purpose of this code is to Um, going out on a limb here, but those headers are used internally as cygwin apps are most likely to now know about those headers. circumvent the Cygwin API (and by extension, Cygwin project goals). So, perhaps a better path forward is to disable / remove the above code by default. (Those wanting a native Win32 git should just use the native Win32 git). Or a make option... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving (renaming) submodules, recipe/script
Am 07.01.2013 02:39, schrieb Jonathan Nieder: (just cc-ing Jens and Peter, who might be interested) I´m currently working on teaching mv to move submodules and intend to send those patches to the list after finishing submodule deinit. Please see https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules for the current state of this series. W. Trevor King wrote: Today I had to move my first submodule, and I discovered that Git's support for this is pretty limited. There have been a few patch series attempting to address this [1,2], but none of them seems to have pushed through into master (although I can't put my finger on a reason for why). There are also some SO postings discussing this [3,4]. It would be nice if `git mv` worked out of the box on submodules. Failing that, there could be a `git submodule mv` command that casts the appropriate spell. Failing that, there could be a recipe in Documentation/git-submodule.txt. Here's the best I could come up with for a `git-submodule-mv.sh`: #!/bin/sh # usage: git-submodule-mv.sh OLD NEW OLD=$(realpath --relative-to . $1) NEW=$(realpath --relative-to . $2) SHA=$(git ls-files -s $OLD | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|') NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' $OLD | sed -e 's|^submodule.||' -e s|.path $OLD\$||) GITDIR=$(realpath --relative-to $NEW .git/modules/$NAME) git config -f .gitmodules submodule.$NAME.path $NEW git config -f .git/modules/$NAME/config core.worktree ../../../$NEW git rm --cached $OLD mv $OLD $NEW echo gitdir: $GITDIR $NEW/.git git update-index --add --cacheinfo 16 $SHA $NEW This only works from the repository root directory, and I'm sure makes a number of poor assumptions (e.g. old-style submodules that don't use `gitdir` links are not supported). It does work for some simple test cases. The tricky parts (e.g. path - name conversion) are already worked out more robustly git-submodule.sh, so adding a new cmd_mv shouldn't be very difficult. Could something like this live somewhere in Git, or are we waiting for a more integrated solution? Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720 [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250 [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Jason Pyeron jpye...@pdinc.us writes: [administrivia: please never cull CC list when you respond to a message on this list without a good reason] circumvent the Cygwin API (and by extension, Cygwin project goals). So, perhaps a better path forward is to disable / remove the above code by default. (Those wanting a native Win32 git should just use the native Win32 git). Or a make option... It already is a runtime option, isn't it? I do not have much stake in this personally, but IIRC, the (l)stat workaround was back then found to make Cygwin version from unusably slow to slow but torelable, as our POSIX-y codebase assumes that lstat is fairly efficient, which Cygwin cannot satisify because it has call many win32 calls to collect bits that we do not even look at, in order to give faithful emulation. It does place extra maintenance burden (e.g. conditional compilation depending on the header file the particular version of Cygwin installation the user has at hand) on us, but as long as it works, the ugly hack is fairly isolated and I do not see a reason to unconditionally rip it out, especially if the reasoning behind such move is on All programs that run in Cygwin environment has to be POSIX only and must not use Win32 API directly, even in a controlled way. It is a completely different matter if the direct win32 calls we make, bypassing (l)stat emulation, somehow change the internal state of win32 resources Cygwin controls and violates the invariants Cygwin API implemenation expects, breaking later calls to it. I do not know that is the case here, but I doubt it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving (renaming) submodules, recipe/script
Jens Lehmann jens.lehm...@web.de writes: Am 07.01.2013 02:39, schrieb Jonathan Nieder: (just cc-ing Jens and Peter, who might be interested) I´m currently working on teaching mv to move submodules and intend to send those patches to the list after finishing submodule deinit. Thanks for a heads-up. As a couple of recent What's cooking message has stated, I'll shortly kick jl/submodule-deinit topic out of 'next' back to 'pu', so please make an update a replacement, not an incremental. If I recall the discussion correctly, I think we agreed that deinit should clear the slate, which means the submodule working tree should be removed and made into an empty directory without .git in it, and the last round we saw on the list didn't do that. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email: treat field names as case-independent
Nickolai Zeldovich nicko...@csail.mit.edu writes: On Sun, Jan 6, 2013 at 10:27 PM, Junio C Hamano gits...@pobox.com wrote: While I think this patch is a sensible thing to do, I at the same time wonder who is writing cc: in the lowercase in the first place, and if that is one of our tools, we should fix that part as well. Such a header would leak out to the payload given to the underlying sendmail, doesn't it? In my case, I wrote the cc: headers by hand; it was not a result of any automated tool. Ok, thanks for shrinking the list of things that worries me by one ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
