Re: [PATCH 04/10] attr: more matching optimizations from .gitignore
On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +Unlike `.gitignore`, negative patterns are not supported. >> +Patterns that match directories are also not supported. > > Is "are not supported" the right phrasing? > > I think it makes perfect sense not to forbid "!path attr1", because > it is unclear what it means (e.g. "path -attr1" vs "path !attr1"). > So I would say "Negative patterns are forbidden as they do not make > any sense". !path/sub/ alone does not mean anything. It must be used together with a positive pattern to define the set of paths the same attribute assignment statement applies to. This makes sense (attr, -attr1 or !attr1 are all OK): *.c attr1 !foo.c attr1 But this does not (actually "!foo.c" line has no effects because of different attribute assignments): *.c attr1 !foo.c attr2 It could be even more confusing in multiple attribute manipulation: *.c attr1 *.h -attr2 !foo.[ch] attr1 -attr2 So "not supported" and "forbidden" are equally OK. I just want to raise a point that it has some use before we go for "forbidden". > Nguyen Thai Ngoc Duy writes: > >> On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano wrote: Or the user might think "path/ attr1" sets attr1 for all files under "path/" because it does not make sense to attach attributes to a directory in git. >>> >>>... >>> >>>We may not have a need to assign a real attribute to a directory >>>right now, because nothing in Git asks for an attribute for a >>>directory. But that does not necessarily mean we would never need a >>>way to give an attribute to a directory but not to its contents. >> >> Exactly why we should not make "path/ attr" no-op. If we want to make >> it meaningful some day in future, I don't think we want those no-ops >> lay around and suddenly cause changes in behavior with a new version >> of git. > > I do not think you understood. "path/ attr" is a no-op from the > point of view of the *users* of the current versions of Git. It is > perfectly fine to accept and apply attr to "path/"; no codepath in > Git should be asking about path/ anyway, so it ends up to be a > no-op. You shouldn't be erroring out at the syntactic level, i.e. > when these lines are parsed. My objection is no-op lines are timed bombs. But users can already do "dir attr" (no slashes), which is no-op. So yeah, no-op is fine. -- 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: Bug report
On Sat, Oct 06, 2012 at 09:23:59PM -0500, John Whitney wrote:
> >You said in your test script:
> >
> > # Committing test.txt or clearing .gitattributes does clear
> > # the "modified" status, but those options are undesirable
> >
> >Why is the commit undesirable? You have decided that CRs will no longer
> >be tolerated in your repository (by setting .gitattributes). Now you
> >need to record that change in history with a commit that strips out the
> >CRs.
> In some cases it's undesirable. In my example, all I want to do is
> merge in the change that deletes the file, so I don't want to have to
> add that extra commit when I'm just going to delete the file anyway.
Yes, but that is conflating two operations. You only don't want to do
the commit because you are anticipating what is coming next (the
cherry-picked deletion). But if you want to conflate, then you could
also realize that you can simply delete the file, CRs or no, and you do
not need to care about its modified state.
I think a much stronger argument for your position is that the cherry
pick would not happen without a conflict after such a commit, because it
would be deleting files with two different sets of content (the
cherry-pick would want to delete the CR version, but you would not have
that version).
In other words, you want the cherry-pick to happen and ignore the
modification that could be committed, because you know the modification
is not relevant (but git does not). But there is not a way to do that
(even once you overcome the confusion), because the usual way to do so
is to drop the local modification with "git reset" (which would not work
in this case).
> >It is not about having CRs in the working tree file. Those are now
> >considered uninteresting and stripped by git when comparing to the HEAD.
> >The problem is that what's in your _repository_ has CRs.
> Yes, but does that really have to be an issue? Is there any technical
> or practical reason you can think of that the repository shouldn't
> ignore those CRs?
It's significantly less efficient. Right now git only has to do the
conversion when updating the index cache of what's on the filesystem
(i.e., when it would be doing a sha1 over the file contents _anyway_).
And then it can compare sha1s internally, because it knows that all of
the sha1s it has computed are for the canonical in-repo versions of the
file.
If we assume that the in-repo file might need to have CRs stripped, then
we need to actually follow up every sha1 mismatch with an actual content
diff in order to discover if it really is different or not. We could
cache the "true" sha1 of the canonical stripped version to avoid this,
but now we are getting much more complex. In most cases it is sufficient
to just commit the cleaned up contents and then never worry about it
again.
> You're right, we can't magically avoid all the line ending issues
> that people will run into. In this case, though, I think git can
> sidestep a fairly obnoxious problem. My example was simple, but when
> you've got multiple branches that need to be rebased/merged, it can
> get pretty hairy. The repository will never be truly "clean" unless
> you rewrite the whole thing (using filter-branch, for instance).
Right. Git's current approach is very hairy when you are looking at
history that crosses a CRLF flag-day boundary. It's definitely a
weakness of the canonicalization approach. But other approaches also
have downsides; I don't want to catalogue them all here, but you can
certainly search the archive for various discussions and flamewars about
how line endings are handled.
> Maybe my above suggestion is more of a feature request than a bug,
Fair enough. I think your complaint is real, but I think nobody has been
clever enough yet to devise a solution that does not have too many other
downsides. And of course you are free to propose such an approach if you
have thought of one. :)
> but there is the obvious bug that after changing .gitattributes, git
> still doesn't notice that files are "modified" until you modify them
> again in some way (touch works). I only noticed the CRs in our own
> repository after I tried to rebase a branch and got strange errors.
> To make git notice all the files, I had to "find . -type f -exec
> touch {} \;".
I think the idea has been floated before of unconditionally refreshing
the index when you update the crlf config via "git config". But of
course that can only fix a fraction of the cases. You might edit it with
an editor. Or they may be new lines in .gitattributes. Or a change of
wildcard lines in .gitattributes.
Really, the issue is that the index contains a cache of what's in the
files that is considered valid unless the stat information of the file
changes. But that is obviously not the full story, as the
canonicalization rules (CRLF handling or smudge/clean filters) can
change, too, and that is not considered as part of the cache's validity.
Doing it "right" would mean that anytime the attribut
Re: [PATCH] Allow generating a non-default set of documentation
Jeff King writes: > On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote: > >> Yeah, modulo that the "defaults" is tracked and does not have to >> have the dash before "include" (it is an error if it is missing, >> no?). It may want to be named with s/defaults/autodetect/, though. >> >> > diff --git a/Makefile b/Makefile >> > index e3e3cd5..c00fd32 100644 >> > --- a/Makefile >> > +++ b/Makefile >> > ... >> > -endif >> > - >> > +-include config.mak.defaults >> > -include config.mak.autogen >> > -include config.mak > > Yeah, sorry, mindless copying on my part from the lines below. It > clearly should not have the "-". > > I'm fine with something besides "defaults". I meant it to be "these are > the config defaults before you tweak them", but yeah, it is more like > "these are the config options we picked up from uname". Let's put this on hold in the "possibly a good direction to go in" pile, and defer it to post 1.8.0; I haven't even looked at (and do not plan to before the release) these "auto-detect" bits are all safe to be included in Makefiles in subdirectories. -- 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] Allow generating a non-default set of documentation
On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote: > Yeah, modulo that the "defaults" is tracked and does not have to > have the dash before "include" (it is an error if it is missing, > no?). It may want to be named with s/defaults/autodetect/, though. > > > diff --git a/Makefile b/Makefile > > index e3e3cd5..c00fd32 100644 > > --- a/Makefile > > +++ b/Makefile > > ... > > -endif > > - > > +-include config.mak.defaults > > -include config.mak.autogen > > -include config.mak Yeah, sorry, mindless copying on my part from the lines below. It clearly should not have the "-". I'm fine with something besides "defaults". I meant it to be "these are the config defaults before you tweak them", but yeah, it is more like "these are the config options we picked up from uname". -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] Allow generating a non-default set of documentation
Jeff King writes: > On Sun, Oct 07, 2012 at 07:07:03PM -0400, Jeff King wrote: > >> Would it make sense to pull all of our platform-specific tweaks out into >> a config.mak.platform (right before config.mak.autogen)? That would be >> less surprising for cases like this, and I think it would make the >> Makefile a lot more readable. > > Something like the patch below. Note that you could then base even more > decisions on the existing DEFAULT_HELP_FORMAT that is already in the > Makefile (and after my patch, in config.mak.defaults). For example, when > it is set to html, make both the default build and install targets in > Documentation/Makefile do html instead of man. Yeah, modulo that the "defaults" is tracked and does not have to have the dash before "include" (it is an error if it is missing, no?). It may want to be named with s/defaults/autodetect/, though. > diff --git a/Makefile b/Makefile > index e3e3cd5..c00fd32 100644 > --- a/Makefile > +++ b/Makefile > ... > -endif > - > +-include config.mak.defaults > -include config.mak.autogen > -include config.mak -- 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] Allow generating a non-default set of documentation
On Sun, Oct 07, 2012 at 07:07:03PM -0400, Jeff King wrote: > Would it make sense to pull all of our platform-specific tweaks out into > a config.mak.platform (right before config.mak.autogen)? That would be > less surprising for cases like this, and I think it would make the > Makefile a lot more readable. Something like the patch below. Note that you could then base even more decisions on the existing DEFAULT_HELP_FORMAT that is already in the Makefile (and after my patch, in config.mak.defaults). For example, when it is set to html, make both the default build and install targets in Documentation/Makefile do html instead of man. diff --git a/Makefile b/Makefile index e3e3cd5..c00fd32 100644 --- a/Makefile +++ b/Makefile @@ -326,19 +326,6 @@ GIT-VERSION-FILE: FORCE @$(SHELL_PATH) ./GIT-VERSION-GEN -include GIT-VERSION-FILE -uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not') -uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not') -uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not') -uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not') -uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not') -uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not') - -ifdef MSVC - # avoid the MingW and Cygwin configuration sections - uname_S := Windows - uname_O := Windows -endif - # CFLAGS and LDFLAGS are for the users to override from the command line. CFLAGS = -g -O2 -Wall @@ -976,513 +963,7 @@ GIT_USER_AGENT = git/$(GIT_VERSION) GIT_USER_AGENT = git/$(GIT_VERSION) -# -# Platform specific tweaks -# - -# We choose to avoid "if .. else if .. else .. endif endif" -# because maintaining the nesting to match is a pain. If -# we had "elif" things would have been much nicer... - -ifeq ($(uname_M),x86_64) - XDL_FAST_HASH = YesPlease -endif -ifeq ($(uname_S),OSF1) - # Need this for u_short definitions et al - BASIC_CFLAGS += -D_OSF_SOURCE - SOCKLEN_T = int - NO_STRTOULL = YesPlease - NO_NSEC = YesPlease -endif -ifeq ($(uname_S),Linux) - NO_STRLCPY = YesPlease - NO_MKSTEMPS = YesPlease - HAVE_PATHS_H = YesPlease - LIBC_CONTAINS_LIBINTL = YesPlease - HAVE_DEV_TTY = YesPlease -endif -ifeq ($(uname_S),GNU/kFreeBSD) - NO_STRLCPY = YesPlease - NO_MKSTEMPS = YesPlease - HAVE_PATHS_H = YesPlease - DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease - LIBC_CONTAINS_LIBINTL = YesPlease -endif -ifeq ($(uname_S),UnixWare) - CC = cc - NEEDS_SOCKET = YesPlease - NEEDS_NSL = YesPlease - NEEDS_SSL_WITH_CRYPTO = YesPlease - NEEDS_LIBICONV = YesPlease - SHELL_PATH = /usr/local/bin/bash - NO_IPV6 = YesPlease - NO_HSTRERROR = YesPlease - NO_MKSTEMPS = YesPlease - BASIC_CFLAGS += -Kthread - BASIC_CFLAGS += -I/usr/local/include - BASIC_LDFLAGS += -L/usr/local/lib - INSTALL = ginstall - TAR = gtar - NO_STRCASESTR = YesPlease - NO_MEMMEM = YesPlease -endif -ifeq ($(uname_S),SCO_SV) - ifeq ($(uname_R),3.2) - CFLAGS = -O2 - endif - ifeq ($(uname_R),5) - CC = cc - BASIC_CFLAGS += -Kthread - endif - NEEDS_SOCKET = YesPlease - NEEDS_NSL = YesPlease - NEEDS_SSL_WITH_CRYPTO = YesPlease - NEEDS_LIBICONV = YesPlease - SHELL_PATH = /usr/bin/bash - NO_IPV6 = YesPlease - NO_HSTRERROR = YesPlease - NO_MKSTEMPS = YesPlease - BASIC_CFLAGS += -I/usr/local/include - BASIC_LDFLAGS += -L/usr/local/lib - NO_STRCASESTR = YesPlease - NO_MEMMEM = YesPlease - INSTALL = ginstall - TAR = gtar -endif -ifeq ($(uname_S),Darwin) - NEEDS_CRYPTO_WITH_SSL = YesPlease - NEEDS_SSL_WITH_CRYPTO = YesPlease - NEEDS_LIBICONV = YesPlease - ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2) - OLD_ICONV = UnfortunatelyYes - endif - ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2) - NO_STRLCPY = YesPlease - endif - NO_MEMMEM = YesPlease - USE_ST_TIMESPEC = YesPlease - HAVE_DEV_TTY = YesPlease - COMPAT_OBJS += compat/precompose_utf8.o - BASIC_CFLAGS += -DPRECOMPOSE_UNICODE -endif -ifeq ($(uname_S),SunOS) - NEEDS_SOCKET = YesPlease - NEEDS_NSL = YesPlease - SHELL_PATH = /bin/bash - SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin - NO_STRCASESTR = YesPlease - NO_MEMMEM = YesPlease - NO_MKDTEMP = YesPlease - NO_MKSTEMPS = YesPlease - NO_REGEX = YesPlease - NO_FNMATCH_CASEFOLD = YesPlease - NO_MSGFMT_EXTENDED_OPTIONS = YesPlease - HAVE_DEV_TTY = YesPlease - ifeq ($(uname_R),5.6) - SOCKLEN_T = int - NO_HSTRERROR = YesPlease - NO_IPV6 = YesPlease - NO_SOCKADDR_STORAGE = YesPlease - NO_UNSETENV = YesPlease - NO_SETENV = YesPlease -
Re: [PATCH] Allow generating a non-default set of documentation
On Sun, Oct 07, 2012 at 03:40:19PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote: > > ... > >> but it is not so far-fetched to imagine that Windows users may want to > >> omit manpages with > >> > >> $ DEFAULT_DOC_TARGET=html make doc > > > > That use case makes a lot more sense to me (or more likely setting it in > > config.mak). > > I actually had "ifeq ($(uname_S),Windows)" at the top-level in mind, > not config.mak. I think that is far more important use case than > going down to Documentation yourself and run make there (which is > not a workflow I deeply care about in the first place). Hmm. Unfortunately that does not work from within Documentation, because Documentation/Makefile never gets to see our default-system tweaks (it sees only config.mak). I know it is a case you do not care about (and nor do I; if I use this at all, it would be to limit my build by setting the variable in my config.mak), but it highlights a subtle issue. The subdir Makefiles receive their config from config.mak.autogen and config.mak, but never get to see any of the default tweaks we do based on $(uname). Which the contents of config.mak could very well depend on, if somebody were trying to be very clever. Would it make sense to pull all of our platform-specific tweaks out into a config.mak.platform (right before config.mak.autogen)? That would be less surprising for cases like this, and I think it would make the Makefile a lot more readable. -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] Allow generating a non-default set of documentation
On Sun, Oct 07, 2012 at 03:45:52PM -0700, Junio C Hamano wrote: > So here is a proposed update based on your idea, to be squashed on > top (i.e. the change to the top-level Makefile in the posted patch > is not reverted). > > Does it make sense? The change to Documentation/Makefile makes sense, but what then is the point of the second half of this hunk from your original: @@ -2468,10 +2476,10 @@ $(XDIFF_LIB): $(XDIFF_OBJS) $(VCSSVN_LIB): $(VCSSVN_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS) -export DEFAULT_EDITOR DEFAULT_PAGER +export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET doc: - $(MAKE) -C Documentation all + $(MAKE) -C Documentation $(DEFAULT_DOC_TARGET) man: $(MAKE) -C Documentation man We know that "all" is simply a redirect to DEFAULT_DOC_TARGET internally within the documentation Makefile, and we know that it is propagated by the export line above. I do not think it creates the wrong behavior, but it is unnecessary, and omitting a target at all demonstrates to a reader how they can get the same behavior from within Documentation (namely by running just "make"). -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: Re: [Patch 0/5] Create single PDF for all HTML files
On Sun, Oct 07, 2012 at 10:14:28AM +0200, Thomas Ackermann wrote: > There are "patched QT" and "unpatched QT" versions of wkhtmltopdf > (see http://code.google.com/p/wkhtmltopdf/). I am using V0.9.9 for Windows > which is "patched QT". That's a definite compatibility question for taking your patches into upstream git. > There is one drawback with wkhtmltopdf: At least on my Netbook (Win7 64bit, > Pentium 1.5GHz) it is very slow. It takes more than 3 hrs to create > git-doc.pdf. > > If you want to have a quick look on the resulting pdf just clone > https://github.com/tacker66/git-docpdf.git. This repo contains > a current version of user.manual.pdf and git-doc.pdf It does look better than the output generated by the "man -Tdvi" loop I posted. It retains more styling from the HTML and it has a nice table of contents. But 3 hours? Yeesh. Mine took 11 seconds. I wonder if a more sane route is to drop HTML entirely, convert the asciidoc to docbook (which we already do for manpages), and then create a docbook document that is a collection of all elements, which can then be converted to pdf, epub, or whatever. I would not be surprised if somebody has solved this problem before (but it is not really my itch, so I did not look very far). -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] Allow generating a non-default set of documentation
Junio C Hamano writes: > Jeff King writes: > >> Why not do it like this: >> >> diff --git a/Documentation/Makefile b/Documentation/Makefile >> index 267dfe1..ca10313 100644 >> --- a/Documentation/Makefile >> +++ b/Documentation/Makefile >> @@ -152,7 +152,8 @@ endif >> endif >> endif >> >> -all: html man >> +DEFAULT_DOC_TARGET ?= html man >> +all: $(DEFAULT_DOC_TARGET) >> >> html: $(DOC_HTML) >> >> >> which covers both cases? That is also how we handle DEFAULT_TEST_TARGET. > > Surely, and thanks. So here is a proposed update based on your idea, to be squashed on top (i.e. the change to the top-level Makefile in the posted patch is not reverted). Does it make sense? Documentation/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git c/Documentation/Makefile w/Documentation/Makefile index 063fa69..0f8fdf8 100644 --- c/Documentation/Makefile +++ w/Documentation/Makefile @@ -1,3 +1,6 @@ +# The default target of this Makefile is... +all:: + MAN1_TXT= \ $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ $(wildcard git-*.txt)) \ @@ -65,6 +68,8 @@ endif -include ../config.mak.autogen -include ../config.mak +DEFAULT_DOC_TARGET ?= html man + # # For docbook-xsl ... # -1.68.1,no extra settings are needed? @@ -151,7 +156,7 @@ ifndef V endif endif -all: html man +all:: $(DEFAULT_DOC_TARGET) html: $(DOC_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: [PATCH] Allow generating a non-default set of documentation
Jeff King writes: > On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote: > ... >> but it is not so far-fetched to imagine that Windows users may want to >> omit manpages with >> >> $ DEFAULT_DOC_TARGET=html make doc > > That use case makes a lot more sense to me (or more likely setting it in > config.mak). I actually had "ifeq ($(uname_S),Windows)" at the top-level in mind, not config.mak. I think that is far more important use case than going down to Documentation yourself and run make there (which is not a workflow I deeply care about in the first place). >> Makefile | 12 ++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) > > No change to Documentation/Makefile? So this will work: > > $ echo DEFAULT_DOC_TARGET=html >config.mak > $ make doc > > but this will not: > > $ cd Documentation > $ make > > Why not do it like this: > > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 267dfe1..ca10313 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -152,7 +152,8 @@ endif > endif > endif > > -all: html man > +DEFAULT_DOC_TARGET ?= html man > +all: $(DEFAULT_DOC_TARGET) > > html: $(DOC_HTML) > > > which covers both cases? That is also how we handle DEFAULT_TEST_TARGET. > > -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: t4055 failure: see error
Brian Charles Gernhardt writes: > On Oct 2, 2012, at 3:09 PM, Junio C Hamano wrote: > >> I'll find a brown paper bag big enough to hide in. Please disregard >> it. >> >> -- >8 -- >> Subject: [PATCH] t4055: avoid use of sed 'a' command > > Sorry about being slow to respond. The patch does work for me. I > see it's already been committed, but thought the confirmation > would be nice. 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] Allow generating a non-default set of documentation
Jeff King writes: > Why not do it like this: > > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 267dfe1..ca10313 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -152,7 +152,8 @@ endif > endif > endif > > -all: html man > +DEFAULT_DOC_TARGET ?= html man > +all: $(DEFAULT_DOC_TARGET) > > html: $(DOC_HTML) > > > which covers both cases? That is also how we handle DEFAULT_TEST_TARGET. Surely, and 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: Is anyone working on a next-gen Git protocol?
Ævar Arnfjörð Bjarmason writes: > On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> >>> I'm creating a system where a lot of remotes constantly fetch from a >>> central repository for deployment purposes, but I've noticed that even >>> with a remote.$name.fetch configuration to only get certain refs a >>> "git fetch" will still call git-upload pack which will provide a list >>> of all references. >> >> It has been observed that the sender has to advertise megabytes of >> refs because it has to speak first before knowing what the receiver >> wants, even when the receiver is interested in getting updates from >> only one of them, or worse yet, when the receiver is only trying to >> peek the ref it is interested has been updated. > > Has anyone started working on a next-gen Git protocol as a result of > this discussion? I and Shawn helped privately somebody from Gerrit circle, where the initial ref advertisement is a huge problem (primarily because they add tons of refs to one commit that eventually goes to their integration branch), to coming up with a problem description and proposal document to kick-start a discussion some time ago, but not much has happened since. Unless I hear from them soonish, I'll send a cleaned-up version of the draft before I leave for my vacation. The gist of it is that the current protocol cannot be upgraded in place because "who speaks first" is not something you can update with capability, so we would need upload-pack-v2 that lets the fetching side speak first. "What is spoken in the first message" is a separate issue, and one of the things it can address is to allow the ends to reduce the amount of ref advertisement that ends up not getting used in the end, but once we allow the fetcher to speak first, we have much wider possibilities. -- 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 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
On Sun, Oct 07, 2012 at 03:23:31PM -0700, Junio C Hamano wrote: > >> Yeah, I agree with the reasoning. This is an unessential feature > >> that is with the problem for a long time, so let's go the route #1 > >> first before we do anything else. > > > > OK. I think Conrad's patch takes us most of the way there. I had a few > > minor comments, but I think another round should do it. Conrad? > > I'd rather want to see a patch that _only_ documents the current > behaviour to unconfuse people first. I definitely do not want any > patch that changes the command line parsing or any other behaviour > change with problems that have to take time from reviewers to point > them out mixed in it. Sorry, I should have been more clear. I want to see a re-roll of only the documentation bits of Conrad's patch, for which I had only minor comments. The code part had major problems. :) -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: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
Jeff King writes: > On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Which is obviously one of: >> > >> > 1. Keep defaulting to "--include", as that is what we have been doing. >> > >> > 2. Forbid the cases where it would matter (i.e., when the index and >> > HEAD differ). >> > >> > The former is more convenient, but the latter is safer against >> > future breakage. I'm OK either way, but option (1) clearly needs a >> > documentation update. >> >> Yeah, I agree with the reasoning. This is an unessential feature >> that is with the problem for a long time, so let's go the route #1 >> first before we do anything else. > > OK. I think Conrad's patch takes us most of the way there. I had a few > minor comments, but I think another round should do it. Conrad? I'd rather want to see a patch that _only_ documents the current behaviour to unconfuse people first. I definitely do not want any patch that changes the command line parsing or any other behaviour change with problems that have to take time from reviewers to point them out mixed in 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: Is anyone working on a next-gen Git protocol?
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote: > Has anyone started working on a next-gen Git protocol as a result of > this discussion? If not I thought I'd give it a shot if/when I have > time. I haven't, and don't really plan on it soon (I have a few smaller things I'm working on, then I'd like to look into the EWAH bitmap stuff from Shawn next). > The current protocol is basically (S = Server, C = Client) > > S: Spew out first ref > S: Advertisement of capabilities > S: Dump of all our refs > C/S: Declare wanted refs, negotiate with server > S: Send pack to client, if needed In the "C" portion there, there is also "client acknowledges a subset of capabilities shown by server" while it is declaring wanted refs. > And I thought I'd basically turn it into: > > C: Connect to server, declare what protocol we understand > C: Advertisement of capabilities > S: Advertisement of capabilities The capability negotiation right now is that the server offers and the client accepts. Are you swapping that so that the client offers and the server accepts? Or are you thinking that they would be sent simultaneously here? That could drop one round-trip (it's probably not that important for git-over-tcp, but smart-http cares a lot about round trips). But it also introduces a complexity with future additions (one side may not know how to present its capabilities until understanding what the other side can do). > C/S: Negotiate what we want Refs we want, or capabilities we want? > C/S: Same as v1, without the advertisement of capabilities, and maybe > don't dump refs at all > > Basically future-proofing it by having the client say what it supports > to begin with along with what it can handle (like in HTTP). I feel like this "maybe..." bit needs more fleshed out before designing the first part. I like the idea of future-proofing first and then adding new features second, but what does the "don't advertise all refs" protocol look like? Presumably the client is going to say "I'm interested in refs/heads/* and refs/tags/*" or something. Does that come with the capabilities? Or is it a new protocol phase? I think we need to know what the second half of the two-step process will look like to be sure the first half will accommodate it (and the answer may be as simple as saying "they're not sending capabilities, they're sending arbitrary key/value items, with the knowledge that the other side may not understand particular keys, and we have to be prepared to handle both cases). > Then in the negotiation phase the client & server would go back & > forth about what they want & how they want it. I'd planned to > implement something like: > > C: want_refs refs/heads/* > S: OK to that > C: want_refs refs/tags/* > S: OK to that > > Or: > > C: want_refs refs/heads/master > S: OK to that > C: want_refs refs/tags/v* > S: OK to that That seems simple. But how will it work over smart-http? Are we adding a round-trip to do want_refs negotiation? -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: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Yes. The more we talk about it, the more turned off I am by the idea. > > Above I posed my questions as "what _should_ we do when...". And I still > > think we _should_ default to --only with interactive, if we can find > > sane semantics. But until we can find them, it obviously does not make > > sense to enable it, and the whole discussion is stalled. And we must > > come up with an interim solution that is the least bad. > > > > Which is obviously one of: > > > > 1. Keep defaulting to "--include", as that is what we have been doing. > > > > 2. Forbid the cases where it would matter (i.e., when the index and > > HEAD differ). > > > > The former is more convenient, but the latter is safer against > > future breakage. I'm OK either way, but option (1) clearly needs a > > documentation update. > > Yeah, I agree with the reasoning. This is an unessential feature > that is with the problem for a long time, so let's go the route #1 > first before we do anything else. OK. I think Conrad's patch takes us most of the way there. I had a few minor comments, but I think another round should do it. Conrad? -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] Allow generating a non-default set of documentation
On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote: > By default, "make doc" generates the manpages and htmldocs in the > Documentation directory, but you may want to change this depending > on the target environment, e.g. to include 'pdf'. Introduce a new > Makefile variable DEFAULT_DOC_TARGET to allow customizing this. Makes sense (we have DEFAULT_TEST_TARGET for similar reasons). > The primary motivation is to let us check documentation patches with > > $ DEFAULT_DOC_TARGET=git-push.1 make doc Wouldn't it be just as easy to say: $ make -C Documentation git-push.1 ? > but it is not so far-fetched to imagine that Windows users may want to > omit manpages with > > $ DEFAULT_DOC_TARGET=html make doc That use case makes a lot more sense to me (or more likely setting it in config.mak). > Makefile | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) No change to Documentation/Makefile? So this will work: $ echo DEFAULT_DOC_TARGET=html >config.mak $ make doc but this will not: $ cd Documentation $ make Why not do it like this: diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..ca10313 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -152,7 +152,8 @@ endif endif endif -all: html man +DEFAULT_DOC_TARGET ?= html man +all: $(DEFAULT_DOC_TARGET) html: $(DOC_HTML) which covers both cases? That is also how we handle DEFAULT_TEST_TARGET. -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] git-gui: Few issues with using full path name
Could we look into getting these two patches into git/git-gui? On 10/02/12 12:25, Andrew Wong wrote: > I ran into a file name parsing issue in git-gui. If I'm in a subfolder and try > to pass a full path to "git-gui blame", then "git-gui" will fail to detect the > argument as a valid path. The first patch will handle this scenario. > > The second patch just another issue that I noticed when "git-gui" fails to > detect the file name. It'll then try to use the previously detected "head" as > the file name, while prepending it with "prefix". This is incorrect if "head" > is actually a full path. > > There is also an issue when using a full path along with a rev argument, but I > don't have time to look it right now. I'll try to get to that issue another > time. > > Andrew Wong (2): > git-gui: Detect full path when parsing arguments > git-gui: Don't prepend the prefix if value looks like a full path > > git-gui.sh | 20 +--- > 1 file changed, 17 insertions(+), 3 deletions(-) > -- 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] gitk: Fix crash when not using themed widgets
When configured not to use themed widgets gitk may crash on launch with
a message that says that the image "bm-left disabled bm-left-gray"
doesn't exist. This happens when the left and right arrow buttons are
created.
The crash can be avoided by configuring the buttons differently
depending on whether or not themed widgets are used. If themed widgets
are not used then only set the images to bm-left and bm-right
respectively, and keep the old behavior when themed widgets are used.
The previous behaviour was added in f062e50f to work around a bug in Tk
on OS X where the disabled state did not display properly. The buttons
may still not display correctly, however the workaround added in
f062e50f will still apply if gitk is used with themed widgets.
Make gitk not crash on launch when not using themed widgets.
Signed-off-by: Marcus Karlsson
---
gitk | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 379582a..02ffd9b 100755
--- a/gitk
+++ b/gitk
@@ -2182,11 +2182,19 @@ proc makewindow {} {
image create bitmap bm-right -data $bm_right_data
image create bitmap bm-right-gray -data $bm_right_data -foreground "#999"
-${NS}::button .tf.bar.leftbut -image [list bm-left disabled bm-left-gray] \
- -command goback -state disabled -width 26
+${NS}::button .tf.bar.leftbut -command goback -state disabled -width 26
+if {$use_ttk} {
+ .tf.bar.leftbut configure -image [list bm-left disabled bm-left-gray]
+} else {
+ .tf.bar.leftbut configure -image bm-left
+}
pack .tf.bar.leftbut -side left -fill y
-${NS}::button .tf.bar.rightbut -image [list bm-right disabled
bm-right-gray] \
- -command goforw -state disabled -width 26
+${NS}::button .tf.bar.rightbut -command goforw -state disabled -width 26
+if {$use_ttk} {
+ .tf.bar.rightbut configure -image [list bm-right disabled bm-right-gray]
+} else {
+ .tf.bar.rightbut configure -image bm-right
+}
pack .tf.bar.rightbut -side left -fill y
${NS}::label .tf.bar.rowlabel -text [mc "Row"]
--
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 v2 0/2] Re: gitk: can't reload commits with new key binding
Could we look into getting this patch into git/gitk? On 10/02/12 11:04, Andrew Wong wrote: > Refactored the code for binding modified function keys as Junio suggested. > > Andrew Wong (2): > gitk: Refactor code for binding modified function keys > gitk: Use bindshiftfunctionkey to bind Shift-F5 > > gitk | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > -- 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 0/5] Create single PDF for all HTML files
Jeff King writes: > Another way of doing this would be to format the individual troff > manpages into dvi or postscript, convert that into pdf, and then > concatenate that. Something like: > > for i in *.[157]; do > man -Tdvi -l "$i" >"$i.dvi" > dvipdfm "$i" > done > pdftk *.[157].pdf cat output full.pdf > > works for me, though obviously that does not handle some of the non-man > items you included. No idea on how the output compares to yours, but > it's something you may want to look at. Yes, that would be far more straight-forward and less error prone way to do 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
Re: [Patch 3/5] Create html documents for all files in Documentation/RelNotes
Jeff King writes: > [1] I would not be surprised if they do not actually format all that > well. Though they are written in an asciidoc-ish style, they have > not traditionally been formatted, and I suspect there are many small > errors (like improper quoting of metacharacters) in them. They aren't even "errors". As far as I (who writes the release notes) am concerned, they are straight text without any asciidoc or markdown mark-up. -- 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 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
Jeff King writes: > Yes. The more we talk about it, the more turned off I am by the idea. > Above I posed my questions as "what _should_ we do when...". And I still > think we _should_ default to --only with interactive, if we can find > sane semantics. But until we can find them, it obviously does not make > sense to enable it, and the whole discussion is stalled. And we must > come up with an interim solution that is the least bad. > > Which is obviously one of: > > 1. Keep defaulting to "--include", as that is what we have been doing. > > 2. Forbid the cases where it would matter (i.e., when the index and > HEAD differ). > > The former is more convenient, but the latter is safer against > future breakage. I'm OK either way, but option (1) clearly needs a > documentation update. Yeah, I agree with the reasoning. This is an unessential feature that is with the problem for a long time, so let's go the route #1 first before we do anything else. -- 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: Fw: [git-users] How do I git-push to an FTP server?
Jonathan Nieder writes: > Ramkumar Ramachandra wrote: >>> Thomas Ferris Nicolaisen writes: > At least according to the documentation[1], "Git natively supports [...] ftp". This could need some clarification if pushing over ftp is not supported. > [...] >> -Git natively supports ssh, git, http, https, ftp, ftps, and rsync >> -protocols. The following syntaxes may be used with them: >> +Git natively supports ssh, git, http, https, and rsync protocols. The >> +following syntaxes may be used with them: > > Perhaps the initial list should not be exhaustive, in which case we > could say: > > Git natively supports ssh, git, http, and https protocols. The > following syntaxes may be used with them: > > ... > > Git also has (less efficient) support for fetching and pushing > over rsync protocol and fetching over ftp or ftps, using the > same "protocol://host/path/to/repo.git/" syntax. Yeah, that, possibly with "These are deprecated; do not use them.", would be a better way forward. As we deprecated "rsync" long time ago, perhaps we should remove it at Git 2.0 or somewhere around that. By the way, that old patch by Ram in question was *not* incorrect per-se back then when dumb http was still more prevalent option between the two http transports. Fetching over dumb http and dumb ftp were both equally bad ;-) It just has become less relevant as more people start equating http with the smart http, where there is no equivalent "smart ftp". -- 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] Allow generating a non-default set of documentation
By default, "make doc" generates the manpages and htmldocs in the Documentation directory, but you may want to change this depending on the target environment, e.g. to include 'pdf'. Introduce a new Makefile variable DEFAULT_DOC_TARGET to allow customizing this. The primary motivation is to let us check documentation patches with $ DEFAULT_DOC_TARGET=git-push.1 make doc but it is not so far-fetched to imagine that Windows users may want to omit manpages with $ DEFAULT_DOC_TARGET=html make doc or somesuch; this lets interested people to enhance the install-doc target in a similar way. Signed-off-by: Junio C Hamano --- Makefile | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git c/Makefile w/Makefile index 8413606..250b87a 100644 --- c/Makefile +++ w/Makefile @@ -299,6 +299,12 @@ all:: # DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR', # DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork' # +# You can define DEFAULT_DOC_TARGET to something other than "all" to change it +# from the built-in default of generating manpages and htmldocs. e.g. +# +# DEFAULT_DOC_TARGET='man html info pdf' +# DEFAULT_DOC_TARGET='html' +# # Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on # header files to be automatically computed, to avoid rebuilding objects when # an unrelated header file changes. Define it to "no" to use the hard-coded @@ -1496,6 +1502,8 @@ ifneq (,$(SOCKLEN_T)) BASIC_CFLAGS += -Dsocklen_t=$(SOCKLEN_T) endif +DEFAULT_DOC_TARGET ?= all + ifeq ($(uname_S),Darwin) ifndef NO_FINK ifeq ($(shell test -d /sw/lib && echo y),y) @@ -2468,10 +2476,10 @@ $(XDIFF_LIB): $(XDIFF_OBJS) $(VCSSVN_LIB): $(VCSSVN_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS) -export DEFAULT_EDITOR DEFAULT_PAGER +export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET doc: - $(MAKE) -C Documentation all + $(MAKE) -C Documentation $(DEFAULT_DOC_TARGET) man: $(MAKE) -C Documentation man -- 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: Is anyone working on a next-gen Git protocol?
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote: > > Has anyone started working on a next-gen Git protocol as a result of > this discussion? If not I thought I'd give it a shot if/when I have > time. Unfortunately, client signaling the version is nasty to do in ways that wouldn't cause current servers to hang up or do other undesirable things. git://: Git-daemon will hang up[1] if it receives command it won't understand (and one can't add arguments either). ssh://: Commands are NAKed in non-standard ways (e.g. Gitolite vs. shell) and one can't add arguments. file://: That's easy. CONNECT: The helper needs to be told that v2 is supported (helper doing the rest). Maybe with git://, one could hack the stuff in similar way as virtual hosting was added. But that won't work with SSH (nor one can use environment with SSH). :-/ [1] And there is no guarantee that the server end of git:// is git-daemon. There's at least one git:// server implemetation that responds to unknown commands by ERR packet followed by hangup. -Ilari -- 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: push.default documented in "man git-push"?
Ramkumar Ramachandra writes: > Junio C Hamano wrote: >> >> With a weaker phrase, e.g. "These configuration variables may be of >> interest", such a list may not hurt readers, but personally I do not >> think it adds much value to have a list of variables without even a >> single line description of what each is used for. > > Okay. Does this work? Hrm, is it useful without even a single line description of what each is used for? Besides, how does it appear in the formatted documents? A thick paragraph that lists names of variables enumerated without comma in between? > -- 8< -- > From: Ramkumar Ramachandra > Date: Sun, 7 Oct 2012 17:24:36 +0530 > Subject: [PATCH] Documentation/git-push: add a configuration variables > section > > The list of configuration variables that affect the operation of a git > command can often be hard to find. As a first step, add a > "Configuration variables" section to git-push. The intent is to > create similar sections in all manpages. > > Signed-off-by: Ramkumar Ramachandra > --- > Documentation/git-push.txt | 24 > 1 file changed, 24 insertions(+) > > diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt > index cb97cc1..a125536 100644 > --- a/Documentation/git-push.txt > +++ b/Documentation/git-push.txt > @@ -426,6 +426,30 @@ Commits A and B would no longer belong to a > branch with a sy > and so would be unreachable. As such, these commits would be removed by > a `git gc` command on the origin repository. > > +Configuration variables > +--- > + > +These configuration variables may be of interest. For more > +information see linkgit:git-config[1]. > + > +branch..remote > +core.gitProxy > +http.proxy > +push.default > +receive.autogc > +receive.denyCurrentBranch > +receive.denyDeleteCurrent > +receive.denyDeletes > +receive.denyNonFastForwards > +receive.unpackLimit > +receive.updateserverinfo > +remote..mirror > +remote..proxy > +remote..push > +remote..pushurl > +remote..receivepack > +remote..url > + > GIT > --- > Part of the linkgit:git[1] suite -- 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
Is anyone working on a next-gen Git protocol?
On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> I'm creating a system where a lot of remotes constantly fetch from a >> central repository for deployment purposes, but I've noticed that even >> with a remote.$name.fetch configuration to only get certain refs a >> "git fetch" will still call git-upload pack which will provide a list >> of all references. > > It has been observed that the sender has to advertise megabytes of > refs because it has to speak first before knowing what the receiver > wants, even when the receiver is interested in getting updates from > only one of them, or worse yet, when the receiver is only trying to > peek the ref it is interested has been updated. Has anyone started working on a next-gen Git protocol as a result of this discussion? If not I thought I'd give it a shot if/when I have time. The current protocol is basically (S = Server, C = Client) S: Spew out first ref S: Advertisement of capabilities S: Dump of all our refs C/S: Declare wanted refs, negotiate with server S: Send pack to client, if needed And I thought I'd basically turn it into: C: Connect to server, declare what protocol we understand C: Advertisement of capabilities S: Advertisement of capabilities C/S: Negotiate what we want C/S: Same as v1, without the advertisement of capabilities, and maybe don't dump refs at all Basically future-proofing it by having the client say what it supports to begin with along with what it can handle (like in HTTP). Then in the negotiation phase the client & server would go back & forth about what they want & how they want it. I'd planned to implement something like: C: want_refs refs/heads/* S: OK to that C: want_refs refs/tags/* S: OK to that Or: C: want_refs refs/heads/master S: OK to that C: want_refs refs/tags/v* S: OK to that As a proof of concept (and also something that'll solve the issue I had), but by adding an initial negotiation phase the protocol should be open to any future extensions without making assumptions about the client wanting to know about all of the server's refs, unlike the current protocol. -- 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 3/5] diff: acknowledge --submodule=short command-line option
Am 07.10.2012 21:49, schrieb Jens Lehmann:
> I forgot to mention that testing submodule_format_cfg would have to
> happen in cmd_diff() (between reading the config and parsing the
> command line options) instead of builtin_diff(). Something like this
> should do the trick (untested):
>
> diff --git a/builtin/diff.c b/builtin/diff.c
> index 9650be2..180bf44 100644
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -297,6 +297,9 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix
> DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
> DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
>
> + if (submodule_format_cfg && !strcmp(submodule_format_cfg, "log"))
> + DIFF_OPT_SET(options, SUBMODULE_LOG);
Obviously not even compile tested, the line above should read:
+ DIFF_OPT_SET(&rev.diffopt, SUBMODULE_LOG);
> +
> if (nongit)
> die(_("Not a git repository"));
> argc = setup_revisions(argc, argv, &rev, NULL);
--
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 3/5] diff: acknowledge --submodule=short command-line option
Am 07.10.2012 17:22, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
>>> Currently, the diff code does not differentiate between an explicit
>>> '--submodule=short' being passed, and no submodule option being passed
>>> on the command line. Making this differentiation will be important
>>> when the command-line option can be used to override a
>>> "diff.submoduleFormat" configuration variable introduced in the next
>>> patch.
>>
>> Wouldn't it be sufficient here to simply reset the log flag by using
>> "DIFF_OPT_CLR(options, SUBMODULE_LOG)"? This would avoid having to
>> use the last bit of the diffopt flags. And if I read the code correctly,
>> diff_opt_parse() is called by setup_revisions() which is called after
>> git_config(), so that should be safe. (And "textconv" uses the same
>> approach)
>
> How is it sufficient? In git_diff_ui_config(), I set
> submodule_format_cfg, which has nothing to do with SUBMODULE_LOG. In
> builtin_diff(), I'll have to check SUBMODULE_LOG and
> submodule_format_cfg. The tricky bit is that I should check
> submodule_format_cfg if and only if "--submodule=short" was NOT passed
> on the command line- now, that's not the same thing is checking if
> SUBMODULE_LOG is unset, because SUBMODULE_LOG is unset (or cleared) if
> no argument was passed or if "--submodule=short" is passed.
> Therefore, I need a SUBMODULE_SHORT to differentiate between the two
> cases.
>
> What am I missing?
I forgot to mention that testing submodule_format_cfg would have to
happen in cmd_diff() (between reading the config and parsing the
command line options) instead of builtin_diff(). Something like this
should do the trick (untested):
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..180bf44 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -297,6 +297,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
+ if (submodule_format_cfg && !strcmp(submodule_format_cfg, "log"))
+ DIFF_OPT_SET(options, SUBMODULE_LOG);
+
if (nongit)
die(_("Not a git repository"));
argc = setup_revisions(argc, argv, &rev, NULL);
--
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: Fw: [git-users] How do I git-push to an FTP server?
Ramkumar Ramachandra wrote: >> Thomas Ferris Nicolaisen writes: >>> At least according to the documentation[1], "Git natively supports [...] >>> ftp". >>> >>> This could need some clarification if pushing over ftp is not supported. [...] > -Git natively supports ssh, git, http, https, ftp, ftps, and rsync > -protocols. The following syntaxes may be used with them: > +Git natively supports ssh, git, http, https, and rsync protocols. The > +following syntaxes may be used with them: Perhaps the initial list should not be exhaustive, in which case we could say: Git natively supports ssh, git, http, and https protocols. The following syntaxes may be used with them: ... Git also has (less efficient) support for fetching and pushing over rsync protocol and fetching over ftp or ftps, using the same "protocol://host/path/to/repo.git/" syntax. -- 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: push.default documented in "man git-push"?
Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra >> wrote: >>> On second thought, it might not be such a good idea. There are *lots* >>> of variables that control the operation of each command, and it's hard >>> to decide which ones to list and which ones to omit. I've listed all >>> the relevant variables for git-push, except the advice.* variables- I >>> don't know how useful such a long list might be. >> >> I think listing receive.* and advice.* (and maybe even >> remove..*) is still ok. The goal is to give users a clue. >> They'll need to look up in config.txt anyway for explanation. If we >> name the config keys (and groups) well then users should be able to >> guess what those keys may be for before deciding whether to look into >> details. > > Please do not label the list as "These variables affect this > command" to give a false impression that it is the complete list if > it isn't. > > Unless somebody promises to keep an up-to-date complete list there > (or even better, come up with a mechanism to help us keep that > promise automatically, perhaps by annotating pieces with structured > comments in config.txt and automatically appending such a section to > manual pages of relevant commands), that is. > > With a weaker phrase, e.g. "These configuration variables may be of > interest", such a list may not hurt readers, but personally I do not > think it adds much value to have a list of variables without even a > single line description of what each is used for. Okay. Does this work? -- 8< -- From: Ramkumar Ramachandra Date: Sun, 7 Oct 2012 17:24:36 +0530 Subject: [PATCH] Documentation/git-push: add a configuration variables section The list of configuration variables that affect the operation of a git command can often be hard to find. As a first step, add a "Configuration variables" section to git-push. The intent is to create similar sections in all manpages. Signed-off-by: Ramkumar Ramachandra --- Documentation/git-push.txt | 24 1 file changed, 24 insertions(+) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index cb97cc1..a125536 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -426,6 +426,30 @@ Commits A and B would no longer belong to a branch with a sy and so would be unreachable. As such, these commits would be removed by a `git gc` command on the origin repository. +Configuration variables +--- + +These configuration variables may be of interest. For more +information see linkgit:git-config[1]. + +branch..remote +core.gitProxy +http.proxy +push.default +receive.autogc +receive.denyCurrentBranch +receive.denyDeleteCurrent +receive.denyDeletes +receive.denyNonFastForwards +receive.unpackLimit +receive.updateserverinfo +remote..mirror +remote..proxy +remote..push +remote..pushurl +remote..receivepack +remote..url + GIT --- Part of the linkgit:git[1] suite -- 1.7.12.1.428.g652398a.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: t4055 failure: see error
On Oct 2, 2012, at 3:09 PM, Junio C Hamano wrote: > I'll find a brown paper bag big enough to hide in. Please disregard > it. > > -- >8 -- > Subject: [PATCH] t4055: avoid use of sed 'a' command Sorry about being slow to respond. The patch does work for me. I see it's already been committed, but thought the confirmation would be nice. ~~ Brian Gernhardt -- 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: Fw: [git-users] How do I git-push to an FTP server?
Junio C Hamano wrote:
> Thomas Ferris Nicolaisen writes:
>
>> On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher
>> wrote:
>>>
>>> > On the git-users mailing list we're trying someone to help with
>>> > running `git push` over FTP. That person is runnig Git 1.7.9.5
>>> > on Ubuntu 12.04.
>>>
>>> I don't think vanilla git supports pushing over ftp.
>>>
>>
>> At least according to the documentation[1], "Git natively supports [...]
>> ftp".
>>
>> This could need some clarification if pushing over ftp is not supported.
>
> The commit 5ce4f4e (Documentation/urls: Rewrite to accomodate
> ::, 2010-04-06) that came from
>
> http://thread.gmane.org/gmane.comp.version-control.git/145196/focus=145205
>
> was supposed to be just a clarification of the document, but it
> added ftp to the list without justification.
Hm, my bad. Would this fix the problem?
-- 8< --
From: Ramkumar Ramachandra
Date: Sun, 7 Oct 2012 20:57:15 +0530
Subject: [PATCH] Documentation/urls: git does not natively support ftp
5ce4f4e (Documentation/urls: Rewrite to accomodate
::, 2010-04-06) added ftp[s] to the list of
supported protocols without justification. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/urls.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 2890194..a65e894 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -6,13 +6,12 @@ address of the remote server, and the path to the repository.
Depending on the transport protocol, some of this information may be
absent.
-Git natively supports ssh, git, http, https, ftp, ftps, and rsync
-protocols. The following syntaxes may be used with them:
+Git natively supports ssh, git, http, https, and rsync protocols. The
+following syntaxes may be used with them:
- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
- git://host.xz{startsb}:port{endsb}/path/to/repo.git/
- http{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/
-- ftp{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/
- rsync://host.xz/path/to/repo.git/
An alternative scp-like syntax may also be used with the ssh protocol:
--
1.7.12.1.428.g652398a.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: [PATCH 3/5] diff: acknowledge --submodule=short command-line option
Jens Lehmann wrote: > Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra: >> Currently, the diff code does not differentiate between an explicit >> '--submodule=short' being passed, and no submodule option being passed >> on the command line. Making this differentiation will be important >> when the command-line option can be used to override a >> "diff.submoduleFormat" configuration variable introduced in the next >> patch. > > Wouldn't it be sufficient here to simply reset the log flag by using > "DIFF_OPT_CLR(options, SUBMODULE_LOG)"? This would avoid having to > use the last bit of the diffopt flags. And if I read the code correctly, > diff_opt_parse() is called by setup_revisions() which is called after > git_config(), so that should be safe. (And "textconv" uses the same > approach) How is it sufficient? In git_diff_ui_config(), I set submodule_format_cfg, which has nothing to do with SUBMODULE_LOG. In builtin_diff(), I'll have to check SUBMODULE_LOG and submodule_format_cfg. The tricky bit is that I should check submodule_format_cfg if and only if "--submodule=short" was NOT passed on the command line- now, that's not the same thing is checking if SUBMODULE_LOG is unset, because SUBMODULE_LOG is unset (or cleared) if no argument was passed or if "--submodule=short" is passed. Therefore, I need a SUBMODULE_SHORT to differentiate between the two cases. What am I missing? Ram -- 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] MALLOC_CHECK: Allow checking to be disabled from config.mak
Hi Julio. No, i don't know this message before. Difficult that can be related to a recent glibc change, i think. Perhaps eglibc ? I tomorrow take a look, i am on travel now. Best 2012/10/6, Junio C Hamano : > Ramsay Jones writes: > >> The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK >> variable, either from the environment or command line of an >> 'make test' invocation. In order to allow the malloc checks to be >> disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK >> to the environment using an export directive. > > We would want to encourage people to test with cheap but effective > checks when available. I do not see "malloc: using debugging hooks" > message anywhere when I run tests, but if you do, I'd rather see us > check if we can tell glibc to stop doing so first without disabling > the whole test. Your patch feels like the first step to a slipperly > slope whose destination would make us say "we get too many messages > so let's do nothing in "make test" with this configuration." when > taken to the extreme, and obviously we would not want to go there > ;-). > > Elia, you brought the MALLOC_CHECK_ up. Did you hear about this > issue elsewhere before, and if you did, do you know how other > projects solves it? > > Besides, doesn't a simple instruction to export TEST_NO_MALLOC_CHECK > to your environment before running "make test" suffice? > > -- Inviato dal mio dispositivo mobile -- 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
Aw: Re: [Patch 0/5] Create single PDF for all HTML files
There are "patched QT" and "unpatched QT" versions of wkhtmltopdf (see http://code.google.com/p/wkhtmltopdf/). I am using V0.9.9 for Windows which is "patched QT". There is one drawback with wkhtmltopdf: At least on my Netbook (Win7 64bit, Pentium 1.5GHz) it is very slow. It takes more than 3 hrs to create git-doc.pdf. If you want to have a quick look on the resulting pdf just clone https://github.com/tacker66/git-docpdf.git. This repo contains a current version of user.manual.pdf and git-doc.pdf - Original Nachricht Von: Jeff King An: Thomas Ackermann Datum: 06.10.2012 21:32 Betreff: Re: [Patch 0/5] Create single PDF for all HTML files > On Sat, Oct 06, 2012 at 05:51:15PM +0200, Thomas Ackermann wrote: > > > I wanted to have a single PDF file which contains the complete Git > documentation > > (except user-manual) for easier reading on my tablet. The simplest way to > do > > this was by using wkhtmltopdf which can combine a set of HTML files into a > sinlge > > PDF file and also apply some reformatting. To this end HTML files for all > the missing > > files in Documentation/technical and Documentation/howto and also for all > the > > release notes in Documentation/RelNotes were created. > > It seems like a reasonable goal. I do not have a strong opinion on the > approach or how the final output looks, but I wasn't able to actually > get output at all after applying your patches. Running "make fullpdf" > (after installing dblatex) got me: > > The switch --book, is not support using unpatched qt, and will be > ignored.The switch --footer-html, is not support using unpatched qt, > and will be ignored.The switch --disable-external-links, is not > support using unpatched qt, and will be ignored. > > after which wkhtmltopdf began pegging my CPU. I let it run for 10 > minutes before giving up. > > Another way of doing this would be to format the individual troff > manpages into dvi or postscript, convert that into pdf, and then > concatenate that. Something like: > > for i in *.[157]; do > man -Tdvi -l "$i" >"$i.dvi" > dvipdfm "$i" > done > pdftk *.[157].pdf cat output full.pdf > > works for me, though obviously that does not handle some of the non-man > items you included. No idea on how the output compares to yours, but > it's something you may want to look at. > > -Peff > --- Thomas -- 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
Aw: Re: [Patch 1/5] Fix some asciidoc layout problems
Making the dashed lines longer was unnecessary and I will remove this. There were in general the following "layout problems" I encountered while trying to create git-doc.pdf: - Wrong sectioning syntax (e.g. "===" instead of "---") - Left-over shell scripting commands (in some release notes files) - Over-long lines which caused very wide right margins in the resulting pdf The later is the case here and I tried to fix this by either splitting the offending line in several lines or removing as much spaces as possible. I will be more specific about these things in my commit messages. - Original Nachricht Von: Jeff King An: Junio C Hamano Datum: 06.10.2012 21:10 Betreff: Re: [Patch 1/5] Fix some asciidoc layout problems > On Sat, Oct 06, 2012 at 11:39:13AM -0700, Junio C Hamano wrote: > > > Thomas Ackermann writes: > > > > > Signed-off-by: Thomas Ackermann > > > --- > > > Documentation/git-bisect-lk2009.txt | 12 ++-- > > > Documentation/git-fetch-pack.txt| 5 - > > > 2 files changed, 10 insertions(+), 7 deletions(-) > > > > You didn't say what "layout problem" you are fixing, or what the > > approach you took to "fix" it. From the patch, I can guess that the > > latter is to lengthen the lines that surround the displayed examples, > > but as far as I know and can tell, the existing ones are long enough > > so I cannot tell why you needed such a change to the source in the > > first place. > > > > A better explanation, please? > > I had the same question. Also, some of the lines convert tabs in literal > output into spaces, which is actively wrong (or maybe they were > converted already to spaces in the current code, but they should at > least align with 8-space tabstops): > > > > -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > > > +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > > -Peff > --- Thomas -- 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
