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 p...@peff.net An: Junio C Hamano gits...@pobox.com 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 th.acke...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- 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
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 p...@peff.net An: Thomas Ackermann th.acke...@arcor.de 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
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 gits...@pobox.com: Ramsay Jones ram...@ramsay1.demon.co.uk 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
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: Fw: [git-users] How do I git-push to an FTP server?
Junio C Hamano wrote:
Thomas Ferris Nicolaisen tfn...@gmail.com writes:
On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher
philippe.vauc...@gmail.com 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
transport::address, 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 artag...@gmail.com
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
transport::address, 2010-04-06) added ftp[s] to the list of
supported protocols without justification. Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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: t4055 failure: see error
On Oct 2, 2012, at 3:09 PM, Junio C Hamano gits...@pobox.com 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: push.default documented in man git-push?
Junio C Hamano wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com 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.name.*) 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 artag...@gmail.com 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 artag...@gmail.com --- 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.name.remote +core.gitProxy +http.proxy +push.default +receive.autogc +receive.denyCurrentBranch +receive.denyDeleteCurrent +receive.denyDeletes +receive.denyNonFastForwards +receive.unpackLimit +receive.updateserverinfo +remote.name.mirror +remote.name.proxy +remote.name.push +remote.name.pushurl +remote.name.receivepack +remote.name.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: Fw: [git-users] How do I git-push to an FTP server?
Ramkumar Ramachandra wrote: Thomas Ferris Nicolaisen tfn...@gmail.com 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: [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
Is anyone working on a next-gen Git protocol?
On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com 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: push.default documented in man git-push?
Ramkumar Ramachandra artag...@gmail.com 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 artag...@gmail.com 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 artag...@gmail.com --- 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.name.remote +core.gitProxy +http.proxy +push.default +receive.autogc +receive.denyCurrentBranch +receive.denyDeleteCurrent +receive.denyDeletes +receive.denyNonFastForwards +receive.unpackLimit +receive.updateserverinfo +remote.name.mirror +remote.name.proxy +remote.name.push +remote.name.pushurl +remote.name.receivepack +remote.name.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
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
[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 gits...@pobox.com --- 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: Fw: [git-users] How do I git-push to an FTP server?
Jonathan Nieder jrnie...@gmail.com writes: Ramkumar Ramachandra wrote: Thomas Ferris Nicolaisen tfn...@gmail.com 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
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
Jeff King p...@peff.net 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: [Patch 3/5] Create html documents for all files in Documentation/RelNotes
Jeff King p...@peff.net 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: [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
[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 m...@acc.umu.se
---
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] 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: 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 p...@peff.net 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: 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
Jeff King p...@peff.net writes: On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net 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: 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: Is anyone working on a next-gen Git protocol?
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com 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: [PATCH] Allow generating a non-default set of documentation
Jeff King p...@peff.net 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: t4055 failure: see error
Brian Charles Gernhardt gernh...@cs.rochester.edu writes: On Oct 2, 2012, at 3:09 PM, Junio C Hamano gits...@pobox.com 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 p...@peff.net 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: [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: [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 p...@peff.net 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 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 - NO_STRLCPY =
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 attributes or config files
changed, we would consider the cache
Re: [PATCH 04/10] attr: more matching optimizations from .gitignore
On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 pclo...@gmail.com writes: On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano gits...@pobox.com 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
