Re: "git am" crash (builtin/apply.c:2108) + small repro
On Wed, Oct 3, 2012 at 10:44 PM, Alexey Spiridonov wrote: > Thanks a lot for trying this. > > My hashes match. I just re-reproduced it on two flavors of Linux (64 > and 32-bit), with two different Git versions (see below). What > platform are you using? x86, 32 bit. Perhaps it has something to do with your configuration (config files, hooks, attributes). Assuming you use standard repository templates, you create new repo in your test so hooks and attributes are out. Is there anything suspicuous in "git config -l"? -- 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
[PATCH v3] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase
"a shell glob suitable for consumption by fnmatch(3)". So it may not
be obvious how one can get literal # or ! at the beginning of pattern.
Add a few lines on how to work around the magic characters.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Back to spelling out, which works with 8.2.6. No examples for \#
because '\' in '\#example#.txt' is eaten.
Documentation/gitignore.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 96639e0..90106c4 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -74,11 +74,15 @@ PATTERN FORMAT
for readability.
- A line starting with # serves as a comment.
+ Put a backslash ("`\`") in front of the first hash for patterns
+ that begin with a hash.
- - An optional prefix '!' which negates the pattern; any
+ - An optional prefix "`!`" which negates the pattern; any
matching file excluded by a previous pattern will become
included again. If a negated pattern matches, this will
override lower precedence patterns sources.
+ Put a backslash ("`\`") in front of the first "`!`" for patterns
+ that begin with a literal "`!`", for example, "`\!important!.txt`".
- If the pattern ends with a slash, it is removed for the
purpose of the following description, but it would only find
--
1.7.12.1.406.g6ab07c4
--
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 10/6/12 8:31 AM, Jeff King wrote:
On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.
But you have asked for an impossible state. You have said "this file
cannot have CR when you check it in, because we erase them". And yet the
version of the file in HEAD has CRs in it. So it must appear modified
with respect to HEAD. And the solution is to make a commit with the
normalized content.
I guess I'd really like to see git ignore all line endings of text files
in the repository. Text files would then never be marked as "modified"
for this reason and there would be no need to "fix" the line endings. I
think that should be the default, but just having the option would be nice.
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. It's also
very inconvenient to have to deal with this issue when you're in the
middle of a complex rebase operation.
I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as "unmodified". It just
doesn't make sense to me that files are considered modified
immediately after checkout.
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?
I wonder if this is a fundamental misunderstanding of how the CRLF
handling in git works. It is not "magically make me not care about line
endings anymore". It is "the canonical version in the repo is LF-only.
Strip anything coming into the repository to match that, and
(optionally) add CR to anything going out to the filesystem for my
convenience". But you need a flag day to update the in-repository
versions to the new scheme.
-Peff
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).
Maybe my above suggestion is more of a feature request than a bug, 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 {} \;".
--
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
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 -- 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/RFC] test: work around SVN 1.7 mishandling of svn:special changes
Subversion represents symlinks as ordinary files with content
starting with "link " and the svn:special property set to "*". Thus a
file can switch between being a symlink and a non-symlink simply by
toggling its svn:special property, and new checkouts will
automatically write a file of the appropriate type. Likewise, in
subversion 1.6 and older, running "svn update" would notice changes
in filetype and update the working copy appropriately.
Unfortunately, starting in subversion 1.7 ,changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
This is a known bug in "svn update" (Subversion issue 4091) and for
the sake of old repositories it will need to be fixed some day.
Revisions prepared with ordinary svn commands ("svn add" and not "svn
propset") don't trip this because they represent filetype changes
using a replace operation, which is approximately equivalent to
removal followed by adding a new file and works fine. Perhaps "git
svn" should mimic that, but for now let's teach the test suite to
recover from the bug by testing the content of HEAD with a new
checkout.
After this change, tests t9100.11-13 pass again.
Signed-off-by: Jonathan Nieder
---
Hi Eric,
Michael G. Schwern wrote:
> At this point SVN 1.7 passes except for 3 tests in
> t9100-git-svn-basic.sh that look like an SVN bug to do with
> symlinks.
How about this patch?
I didn't add a new xfail test for "svn up" working because I'm not yet
sure what good git-svn behavior would be. Probably it would be better
to track down that svn bug and get a fix backported to the 1.7.x
branch.
Reference: http://subversion.tigris.org/issues/show_bug.cgi?id=4160
t/t9100-git-svn-basic.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 749b75e8..34d3485f 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -19,6 +19,15 @@ case "$GIT_SVN_LC_ALL" in
;;
esac
+svn_up_avoiding_issue4091 () {
+ if ! svn_cmd_up "$SVN_TREE"
+ then
+ # work around Subversion issue 4091
+ rm -r "$SVN_TREE" &&
+ svn_cmd checkout "$svnrepo" "$SVN_TREE"
+ fi
+}
+
test_expect_success \
'initialize git svn' '
mkdir import &&
@@ -148,7 +157,7 @@ test_expect_success "$name" '
git commit -m "$name" &&
git svn set-tree --find-copies-harder --rmdir \
${remotes_git_svn}..mybranch5 &&
- svn_cmd up "$SVN_TREE" &&
+ svn_up_avoiding_issue4091 &&
test -h "$SVN_TREE"/exec.sh'
name='new symlink is added to a file that was also just made executable'
@@ -173,7 +182,7 @@ test_expect_success "$name" '
git commit -m "$name" &&
git svn set-tree --find-copies-harder --rmdir \
${remotes_git_svn}..mybranch5 &&
- svn_cmd up "$SVN_TREE" &&
+ svn_up_avoiding_issue4091 &&
test -f "$SVN_TREE"/exec-2.sh &&
test ! -h "$SVN_TREE"/exec-2.sh &&
test_cmp help "$SVN_TREE"/exec-2.sh'
--
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] MALLOC_CHECK: Allow checking to be disabled from config.mak
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? -- 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
On Sat, Oct 06, 2012 at 05:55:58PM +0200, Thomas Ackermann wrote: > - create html for all release note files > [...] > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 86594f6..80eb06d 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual > SP_ARTICLES += howto/revert-branch-rebase > SP_ARTICLES += howto/using-merge-subtree > SP_ARTICLES += howto/using-signed-tag-in-pull-request > +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) > API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt > technical/api-index.txt, $(wildcard technical/api-*.txt))) > API_DOCS += technical/index-format > API_DOCS += technical/pack-format > @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git > API_DOCS += technical/send-pack-pipeline > API_DOCS += technical/shallow > API_DOCS += technical/trivial-merge > +API_DOCS += $(RELNOTES) Yuck. This means that anyone generating the html documentation will have to format all of the release notes, too, even though they are much less likely to be useful[1]. If this is only useful for the fullpdf target, can we omit it from the regular html target (and maybe add a "relnotes" target or something for people who really want them formatted)? -Peff [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. -- 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 5/5] Create pdf from all html files
On Sat, Oct 06, 2012 at 05:58:01PM +0200, Thomas Ackermann wrote: > - use wkhtmltopdf to combine all html files into a single pdf file > "git-doc.pdf" > - provide make target "fullpdf" to create "git-doc.pdf" > > Signed-off-by: Thomas Ackermann > --- > Documentation/.gitignore | 1 + > Documentation/Makefile| 9 + > Documentation/footerend.txt | 4 > Documentation/footerstart.txt | 7 +++ > Documentation/makedocpdf.sh | 25 + > Makefile | 6 ++ > 6 files changed, 52 insertions(+) > create mode 100644 Documentation/footerend.txt > create mode 100644 Documentation/footerstart.txt > create mode 100644 Documentation/makedocpdf.sh The makedocpdf script has no execute bit, but... > diff --git a/Documentation/Makefile b/Documentation/Makefile > index abd27b5..c4c2a30 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -189,6 +189,9 @@ info: git.info gitman.info > > pdf: user-manual.pdf > > +fullpdf: pdf all > + ./makedocpdf.sh Here we try to run it. -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 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 -- 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 Sat, Oct 06, 2012 at 11:32:51AM -0700, Conrad Irwin wrote: > I think I messed up sending somehow: Thanks for resending. > > What state should the "add -p" interaction start from for path F? > > Should you be picking from a patch between the state you previously > > "git add"ed to the index and the working tree, or should the entire > > difference between HEAD and the working tree eligible to be picked > > or deferred during the "add -p" session? Starting from a temporary > > index that matches HEAD essentially means that you lose the earlier > > "git add F" [*1*]. > > Two questions are easier answered: > > What should git commit --only --patch F do? > => It should start you from the state of HEAD. Are you sure? Does "--only" mean "only the changes I am about to mark" or "only the paths I am about to tell you about"? Without partial hunk selection (i.e., "commit -p"), they were the same; a path you mention is a path which will be either be staged in its entirety or not. Specifying (or omitting) the path was sufficient to say what you wanted. But with "-p", I can see three useful possibilities: 1. Do not include F in the commit, even if changes are staged in the index (i.e., take HEAD exactly). 2. Include F in the commit, and stage partial changes on top of what is already staged. 3. Include F in the commit, and stage partial changes on top of HEAD. In cases 2 and 3, we are still taking "only the path" F. But we are not taking "only what is about to be staged" in 2. And I can see both being useful (2 because it is more convenient not to re-approve staged changes, and 3 because there is no way to unstage changes via "-p"). > What should git commit --include --patch F do? > => It should start you from the state of the index. This one is much easier. The distinction between cases 2 and 3 above does not exist here, because we always start from the current index state. So there are two questions: 1. How does --only interact with partial staging (whether paths are specified or not)? 2. What should the default for "-p" be, between "--only" and "--include"? I think the answer to the second is "--only"; but a prerequisite to that is making "--only" work at all (it currently just barfs). And a prerequisite to that is figuring out what the right semantics are. > The question that's harder to ponder, is "what should the default be". Interestingly, I came to the exact opposite conclusion of which question is harder. :) > The big UI problem with --only is not figuring out what should go in the > commit, > but rather ensuring that the index is in the expected state after the commit > (it's the problems solved by 2888605c649ccd423232161186d72c0e6c458a48 but for > hunks instead of files). If file F has hunks (H, J, K) then I stage hunk J > with > git add --interactive; then I commit hunks H & K with git commit > --interactive, > the resulting index should contain H, J, K. Unfortunately, git add > --interactive > allows me to edit hunks, and so if I instead commit H & J2 (where J2 is an > edited version of J) then the index would contain (H, J) and the commit (H, > J2); > the working tree would contain H, J, K still. Yeah, that's a gross-ness I hadn't even considered. > All in all, I think supporting --only --interactive is well beyond what I'm > capable of doing, and probably pushing the limits of what's sane. (it would be > nice for warm fuzzy completeness reasons though). 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. > On Fri, Oct 5, 2012 at 3:57 PM, Jeff King wrote: > > We should probably also support explicit "-i -p" and "-o -p" options, as > > well (the former would give people who really want the existing behavior > > a way to get it). And the same for "--interactive". I can't say I'm > > excited about making all that work, though. Like you, I think it is more > > sane to use existing tools to inspect and tweak the index to your > > liking, and then commit. > > You made the same thinko as me :). --include isn't defined to mean "include > the > index as well", but rather "include these files when committing the index". > Flipping that around makes a lot of sense and then --include can be used > semantically with --patch, --interactive or even --all. (patch attac
Re: [Patch 3/5] Create html documents for all files in Documentation/RelNotes
From: "Thomas Ackermann" - create html for all release note files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann --- Documentation/Makefile | 2 ++ Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 6 files changed, 2 insertions(+), 25 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 86594f6..80eb06d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format API_DOCS += technical/pack-format @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git API_DOCS += technical/send-pack-pipeline API_DOCS += technical/shallow API_DOCS += technical/trivial-merge +API_DOCS += $(RELNOTES) Again, is this the right docs list? SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 2/5] Create html documents for all files in Documentation/technical
From: "Thomas Ackermann" - add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann --- Documentation/Makefile| 12 ++- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 6 files changed, 45 insertions(+), 28 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..86594f6 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -25,6 +25,16 @@ SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) +API_DOCS += technical/index-format Would it not be better to create a separate TECH_DOCS list, rather than confuse the API_DOCS list? +API_DOCS += technical/pack-format +API_DOCS += technical/pack-heuristics +API_DOCS += technical/pack-protocol +API_DOCS += technical/protocol-capabilities +API_DOCS += technical/protocol-common +API_DOCS += technical/racy-git +API_DOCS += technical/send-pack-pipeline +API_DOCS += technical/shallow +API_DOCS += technical/trivial-merge SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index @@ -231,7 +241,7 @@ clean: $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/5] Fix some asciidoc layout problems
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? The synopsis section of git-fetch-pack manual is a long single line which is unsightly. A fix to that issue is indeed needed. Please make a separate patch only for that issue. Is git-fetch-pack the only one whose synopsis section is overlong, by the way? Thanks. > > diff --git a/Documentation/git-bisect-lk2009.txt > b/Documentation/git-bisect-lk2009.txt > index 8a2ba37..99bdb46 100644 > --- a/Documentation/git-bisect-lk2009.txt > +++ b/Documentation/git-bisect-lk2009.txt > @@ -248,7 +248,7 @@ Bisecting: 5480 revisions left to test after this > (roughly 13 steps) > And after a few more steps like that, "git bisect" will eventually > find a first bad commit: > > -- > + > $ git bisect bad > 2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit > commit 2ddcca36c8bcfa251724fe342c8327451988be0d > @@ -257,8 +257,8 @@ Date: Sat May 3 11:59:44 2008 -0700 > > Linux 2.6.26-rc1 > > -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > -- > +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > + > > At this point we can see what the commit does, check it out (if it's > not already checked out) or tinker with it, for example: > @@ -305,7 +305,7 @@ to launch a script or command at each bisection step to > know if the > current commit is "good" or "bad". To do that, we use the "git bisect > run" command. For example: > > -- > + > $ git bisect start v2.6.27 v2.6.25 > Bisecting: 10928 revisions left to test after this (roughly 14 steps) > [2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn > on 32-bit > @@ -331,9 +331,9 @@ Date: Sat May 3 11:59:44 2008 -0700 > > Linux 2.6.26-rc1 > > -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 > 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile > bisect run success > -- > + > > In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as > parameter to "git bisect run". This means that at each step, the grep > diff --git a/Documentation/git-fetch-pack.txt > b/Documentation/git-fetch-pack.txt > index 474fa30..12cd8a2 100644 > --- a/Documentation/git-fetch-pack.txt > +++ b/Documentation/git-fetch-pack.txt > @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another > repository > SYNOPSIS > > [verse] > -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] > [--upload-pack=] [--depth=] [--no-progress] [-v] > [:] [...] > +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] > + [--upload-pack=] > + [--depth=] [--no-progress] > + [-v] [:] [...] > > DESCRIPTION > --- -- 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"
I think I messed up sending somehow: On Fri, Oct 5, 2012 at 11:26 PM, Junio C Hamano wrote: > Suppose you have two paths E and F, both of which have differences > between HEAD and the index, and the index and the working tree file > (i.e. you earlier edited E and F, did "git add E F" and further > edited them). > > You say "git commit -p F". [...] > > What state should the "add -p" interaction start from for path F? > Should you be picking from a patch between the state you previously > "git add"ed to the index and the working tree, or should the entire > difference between HEAD and the working tree eligible to be picked > or deferred during the "add -p" session? Starting from a temporary > index that matches HEAD essentially means that you lose the earlier > "git add F" [*1*]. Two questions are easier answered: What should git commit --only --patch F do? => It should start you from the state of HEAD. What should git commit --include --patch F do? => It should start you from the state of the index. The question that's harder to ponder, is "what should the default be". Historically it's been '--include', but that was for the sake of easy implementation (6cbf07efc5702351897dee4742525c9b9f7828ac). Using '--only' seems good for consistency with other forms of git commit and the current documentation; inventing a third way (i.e. depending on which paths are specified) seems worst of all. The big UI problem with --only is not figuring out what should go in the commit, but rather ensuring that the index is in the expected state after the commit (it's the problems solved by 2888605c649ccd423232161186d72c0e6c458a48 but for hunks instead of files). If file F has hunks (H, J, K) then I stage hunk J with git add --interactive; then I commit hunks H & K with git commit --interactive, the resulting index should contain H, J, K. Unfortunately, git add --interactive allows me to edit hunks, and so if I instead commit H & J2 (where J2 is an edited version of J) then the index would contain (H, J) and the commit (H, J2); the working tree would contain H, J, K still. This gets a bit mind-bending to resolve; the first solution I came up with "don't touch the index if the index differs from HEAD" will give unexpected results in the case that extra non-conflicting chunks are added to the commit. The next idea is to do a three-way merge between the new commit and the index with the old HEAD as the base, and resolve conflicts in favour of the index. I think that works, but it sounds pretty horrific to implement and still leaves you in a pretty confusing state (though no more confusing than using edit in git add --interactive normally is). The other cases to consider are files that aren't in HEAD. At the moment git add --patch and git commit --patch cannot include new files, though that's fixable by treating new files as 1 hunk instead of 0. All in all, I think supporting --only --interactive is well beyond what I'm capable of doing, and probably pushing the limits of what's sane. (it would be nice for warm fuzzy completeness reasons though). On Fri, Oct 5, 2012 at 3:57 PM, Jeff King wrote: > We should probably also support explicit "-i -p" and "-o -p" options, as > well (the former would give people who really want the existing behavior > a way to get it). And the same for "--interactive". I can't say I'm > excited about making all that work, though. Like you, I think it is more > sane to use existing tools to inspect and tweak the index to your > liking, and then commit. You made the same thinko as me :). --include isn't defined to mean "include the index as well", but rather "include these files when committing the index". Flipping that around makes a lot of sense and then --include can be used semantically with --patch, --interactive or even --all. (patch attached). > > Unless somebody who cares about "commit -p" does so to come up with > reasonable semantics, and updates the code to match that desired > behaviour, the responsible thing to do is to error out "-p" when > your index is different from HEAD, I think. That would be a shame; instead we should just document that "--interactive" and "--patch" add to the existing index like they always have. If we still worry about users shooting themselves in the foot, then we can require "--include" to use --interactive or --patch on a dirty index. (not done) Conrad 8<-- Flip the meaning of 'git commit --include' from 'include these files' to 'include the index' to reduce the number of concepts in the manpage. Clarify that --interactive/--patch add to the existing index to avoid confusion like [1]. [1] http://thread.gmane.org/gmane.comp.version-control.git/207108 Signed-off-by: Conrad Irwin --- Documentation/git-commit.txt | 20 +++- builtin/commit.c | 10 ++ 2 files changed, 17 insertions(+), 13 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 9594ac8..a2d4a6d 100644
Re: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
On Sat, Oct 06, 2012 at 11:22:50AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Another option is to leave it with "-i" semantics in the meantime, which > > are at least easy to explain: it is simply a shorthand for running "git > > add -p && git commit". That may be inconsistent with other aspects of > > commit, but people have (apparently) been happy with it, and there has > > not been a rash of complaints. > > Yeah, that would be the safest and possibly the sanest way forward. > Did the documentation update patch by Conrad on the other subthread > look sane to you? I haven't read it very carefully yet. I didn't notice any documentation patch, and I can't find one looking through the archive. Do you have a link? -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 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
Sven Strickroth writes: > Am 04.01.2012 01:12 schrieb Junio C Hamano: >> Now "prompt" is no longer a method but is merely a helper function, so >> I've queued this (and 1/2 rewrite we discussed in a separate thread) to >> 'pu' after rewording the commit log message. >> >> Thanks. > > Is there a reason why these changes did not get merged? The issues are > still there. It is either that it was simply forgotten, or after I wrote the part you quoted early in January there were discussions later that showed the patch was not desirable for some reason. I do not recall which. -- 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] gitignore.txt: suggestions how to get literal # or ! at the beginning
Jeff King writes: > I'd be slightly worried that we are hurting other people who do care and > are on older versions of asciidoc. It would be nice if we actually knew > the cause of the different behaviors we saw and if there was a way to > work around it (it might not even be old asciidoc, but rather old > docbook). > > Part of me wants to just take the change and see if anybody complains. > But that is probably the wrong thing to do, and just my general > frustration with our doc toolchain talking. Yeah, I do not think we would want to introduce such a regression especially when the proposed update is not the only (or best) way to give us the intended benefit. I think the "spell the character name out" approach you showed in the other message was far more readable anyway. 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: git 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
Jeff King writes: > Another option is to leave it with "-i" semantics in the meantime, which > are at least easy to explain: it is simply a shorthand for running "git > add -p && git commit". That may be inconsistent with other aspects of > commit, but people have (apparently) been happy with it, and there has > not been a rash of complaints. Yeah, that would be the safest and possibly the sanest way forward. Did the documentation update patch by Conrad on the other subthread look sane to you? I haven't read it very carefully yet. -- 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] MALLOC_CHECK: Allow checking to be disabled from config.mak
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. Signed-off-by: Ramsay Jones --- Hi Junio, Now that the malloc checks have been enabled, running the tests has become somewhat noisy with "malloc: using debugging hooks" messages spewing continuously to the terminal. [I usually run the tests like so: ramsay$ time $(make test >test-out 2>&1) malloc: using debugging hooks malloc: using debugging hooks ... malloc: using debugging hooks real16m11.408s user5m17.412s sys 4m54.786s ramsay$ ] strace tells me that the controlling terminal, /dev/tty, is being opened directly in order to write these messages. I find this annoying, so I tried to disable the malloc checks from config.mak ... Note that I decided not to write the TEST_NO_MALLOC_CHECK setting to the GIT-BUILD-OPTIONS file, since I prefer to enable/disable the malloc checks myself when running the test script directly. ATB, Ramsay Jones Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8413606..f69979e 100644 --- a/Makefile +++ b/Makefile @@ -2636,6 +2636,7 @@ bin-wrappers/%: wrap-for-bin.sh # with that. export NO_SVN_TESTS +export TEST_NO_MALLOC_CHECK ### Testing rules -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] add a "lua" pretty format
On Mon, Sep 24, 2012 at 08:25:39PM -0400, Jeff King wrote: > @@ -1168,7 +1180,11 @@ void format_commit_message(const struct commit *commit, > free(enc); > } > > - strbuf_expand(sb, format, format_commit_item, &context); > + if (pretty_ctx->fmt == CMIT_FMT_USERFORMAT) > + strbuf_expand(sb, format, format_commit_item, &context); > + else if (pretty_ctx->fmt == CMIT_FMT_LUA) > + lua_commit_format(sb, &context); > + This hunk breaks lots of tests. I know we are not seriously considering the lua series as-is, but in case anybody wants to play with it, here is the fix (and we would need the same fix regardless of language, anyway). You might want to queue this on jk/lua-hackery (probably it would be squashed in for a real series). -- >8 -- Subject: [PATCH] pretty: fix up one-off format_commit_message calls If the usual pretty-print code invokes format_commit_message, the "fmt" field of the pretty_print_context will always have either CMIT_FMT_USERFORMAT or CMIT_FMT_LUA in it, and we can just choose which to use. However, many call sites invoke format_commit_message directly without bothering to set the "fmt" field of the context; they expect format_commit_message to just default to CMIT_FMT_USERFORMAT in that case, since previously that was the only format it handled. The recent addition of the lua formatter broke that assumption. Rather than require each caller to be more strict, let's just default to USERFORMAT when the format is set to something nonsensical. Signed-off-by: Jeff King --- pretty.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pretty.c b/pretty.c index fdd4258..7289590 100644 --- a/pretty.c +++ b/pretty.c @@ -1180,10 +1180,10 @@ void format_commit_message(const struct commit *commit, free(enc); } - if (pretty_ctx->fmt == CMIT_FMT_USERFORMAT) - strbuf_expand(sb, format, format_commit_item, &context); - else if (pretty_ctx->fmt == CMIT_FMT_LUA) + if (pretty_ctx->fmt == CMIT_FMT_LUA) lua_commit_format(sb, &context); + else + strbuf_expand(sb, format, format_commit_item, &context); rewrap_message_tail(sb, &context, 0, 0, 0); -- 1.8.0.rc0.22.g285fd2d -- 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 5/5] Create pdf from all html files
- use wkhtmltopdf to combine all html files into a single pdf file "git-doc.pdf" - provide make target "fullpdf" to create "git-doc.pdf" Signed-off-by: Thomas Ackermann --- Documentation/.gitignore | 1 + Documentation/Makefile| 9 + Documentation/footerend.txt | 4 Documentation/footerstart.txt | 7 +++ Documentation/makedocpdf.sh | 25 + Makefile | 6 ++ 6 files changed, 52 insertions(+) create mode 100644 Documentation/footerend.txt create mode 100644 Documentation/footerstart.txt create mode 100644 Documentation/makedocpdf.sh diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd..fba4730 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -10,3 +10,4 @@ howto-index.txt doc.dep cmds-*.txt manpage-base-url.xsl +docfiles.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index abd27b5..c4c2a30 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -189,6 +189,9 @@ info: git.info gitman.info pdf: user-manual.pdf +fullpdf: pdf all + ./makedocpdf.sh + install: install-man install-man: man @@ -213,6 +216,10 @@ install-pdf: pdf $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) +install-fullpdf: fullpdf install-pdf + $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) + $(INSTALL) -m 644 git-doc.pdf $(DESTDIR)$(pdfdir) + install-html: html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) @@ -252,6 +259,8 @@ clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf + $(RM) docfiles.txt + $(RM) RelNotes/*.html $(RM) howto-index.txt howto/*.html doc.dep $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made diff --git a/Documentation/footerend.txt b/Documentation/footerend.txt new file mode 100644 index 000..ed16923 --- /dev/null +++ b/Documentation/footerend.txt @@ -0,0 +1,4 @@ + + + + diff --git a/Documentation/footerstart.txt b/Documentation/footerstart.txt new file mode 100644 index 000..a2746ef --- /dev/null +++ b/Documentation/footerstart.txt @@ -0,0 +1,7 @@ + + + + + + + diff --git a/Documentation/makedocpdf.sh b/Documentation/makedocpdf.sh new file mode 100644 index 000..fd9f5bb --- /dev/null +++ b/Documentation/makedocpdf.sh @@ -0,0 +1,25 @@ +#!/bin/sh + +rm -f git-doc.pdf + +cat /dev/null >docfiles.txt + +ls gittutorial.html >>docfiles.txt +ls gittutorial-2.html>>docfiles.txt +ls everyday.html >>docfiles.txt +ls gitworkflows.html >>docfiles.txt +ls git-*.html>>docfiles.txt +ls git[acdghikmnr]*.html >>docfiles.txt +ls gitweb*.html >>docfiles.txt +ls howto-index.html >>docfiles.txt +ls howto/*.html >>docfiles.txt +ls technical/*.html >>docfiles.txt +ls RelNotes/*.html >>docfiles.txt + +cat /dev/null >footer.html + +cat footerstart.txt >>footer.html +cat ../GIT-VERSION-FILE >>footer.html +cat footerend.txt>> footer.html + +cat docfiles.txt | xargs cat | wkhtmltopdf --book --footer-html footer.html --disable-external-links - git-doc.pdf diff --git a/Makefile b/Makefile index 8413606..2ddb3c9 100644 --- a/Makefile +++ b/Makefile @@ -2485,6 +2485,9 @@ info: pdf: $(MAKE) -C Documentation pdf +fullpdf: + $(MAKE) -C Documentation fullpdf + XGETTEXT_FLAGS = \ --force-po \ --add-comments \ @@ -2796,6 +2799,9 @@ install-info: install-pdf: $(MAKE) -C Documentation install-pdf +install-fullpdf: + $(MAKE) -C Documentation install-fullpdf + quick-install-doc: $(MAKE) -C Documentation quick-install -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 4/5] Create html documents for all files in Documentation/howto
- add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann --- Documentation/Makefile | 10 + Documentation/howto/maintain-git.txt | 4 ++ .../howto/rebase-from-internal-branch.txt | 11 ++--- Documentation/howto/rebuild-from-update-hook.txt | 4 ++ .../howto/recover-corrupted-blob-object.txt| 10 + Documentation/howto/revert-a-faulty-merge.txt | 4 ++ Documentation/howto/separating-topic-branches.txt | 4 ++ Documentation/howto/setup-git-server-over-http.txt | 4 ++ Documentation/howto/update-hook-example.txt| 50 +++--- Documentation/howto/use-git-daemon.txt | 3 ++ .../howto/using-signed-tag-in-pull-request.txt | 4 +- 11 files changed, 76 insertions(+), 32 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 80eb06d..abd27b5 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,16 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37..58fd809 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you "how to" do it. +Content-type: text/asciidoc + +Maintain Git + The maintainer's git time is spent on three activities. diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 74a1c0c..577b9a7 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the the "master" branch, and how "rebase" works. Also discussed is how this applies to individual developers who sends patches upstream. +Content-type: text/asciidoc +Rebase from internal branch +=== + +-- Petr Baudis writes: > Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter @@ -19,6 +24,7 @@ Petr Baudis writes: >> > branch to the real branches. >> > Actually, wouldn't this be also precisely for what StGIT is intended to? +-- Exactly my feeling. I was sort of waiting for Catalin to speak up. With its basing philosophical ancestry on quilt, this is @@ -156,8 +162,3 @@ you continue on starting from the new "master" head, which is the #1' commit. -jc - -- -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 diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 48c6756..7aa13ac 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -5,6 +5,10 @@ Date: Fri, 26 Aug 2005 18:19:10 -0700 Abstract: In this how-to article, JC talks about how he uses the post-update hook to automate git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/. +Content-type: text/asciidoc + +Rebuild from update hook + The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 323b513..2af4ad7 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -3,11 +3,17 @@ From: Linus Torvalds Subject: corrupt object on git-gc Abstract: Some tricks to reconstruct blob objects in order to fix a corrupted repository. +Content-type: text/asciid
[Patch 3/5] Create html documents for all files in Documentation/RelNotes
- create html for all release note files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann --- Documentation/Makefile | 2 ++ Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 6 files changed, 2 insertions(+), 25 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 86594f6..80eb06d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format API_DOCS += technical/pack-format @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git API_DOCS += technical/send-pack-pipeline API_DOCS += technical/shallow API_DOCS += technical/trivial-merge +API_DOCS += $(RELNOTES) SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index diff --git a/Documentation/RelNotes/1.5.2.1.txt b/Documentation/RelNotes/1.5.2.1.txt index ebf20e2..d41984d 100644 --- a/Documentation/RelNotes/1.5.2.1.txt +++ b/Documentation/RelNotes/1.5.2.1.txt @@ -45,9 +45,3 @@ Fixes since v1.5.2 - git-fastimport --import-marks was broken; fixed. - A lot of documentation updates, clarifications and fixes. - --- -exec >/var/tmp/1 -O=v1.5.2-65-g996e2d6 -echo O=`git describe refs/heads/maint` -git shortlog --no-merges $O..refs/heads/maint diff --git a/Documentation/RelNotes/1.6.0.2.txt b/Documentation/RelNotes/1.6.0.2.txt index e1e24b3..7d8fb85 100644 --- a/Documentation/RelNotes/1.6.0.2.txt +++ b/Documentation/RelNotes/1.6.0.2.txt @@ -79,9 +79,3 @@ Fixes since v1.6.0.1 packfile. Also contains many documentation updates. - --- -exec >/var/tmp/1 -O=v1.6.0.1-78-g3632cfc -echo O=$(git describe maint) -git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes/1.6.1.3.txt b/Documentation/RelNotes/1.6.1.3.txt index 6f0bde1..cd08d81 100644 --- a/Documentation/RelNotes/1.6.1.3.txt +++ b/Documentation/RelNotes/1.6.1.3.txt @@ -26,7 +26,3 @@ Fixes since v1.6.1.2 * RPM binary package installed the html manpages in a wrong place. Also includes minor documentation fixes and updates. - - --- -git shortlog --no-merges v1.6.1.2-33-gc789350.. diff --git a/Documentation/RelNotes/1.6.1.4.txt b/Documentation/RelNotes/1.6.1.4.txt index 0ce6316..ccbad79 100644 --- a/Documentation/RelNotes/1.6.1.4.txt +++ b/Documentation/RelNotes/1.6.1.4.txt @@ -39,6 +39,3 @@ Fixes since v1.6.1.3 This fix was first merged to 1.6.2.3. Also includes minor documentation fixes and updates. - --- -git shortlog --no-merges v1.6.1.3.. diff --git a/Documentation/RelNotes/1.6.1.txt b/Documentation/RelNotes/1.6.1.txt index adb7cca..7b152a6 100644 --- a/Documentation/RelNotes/1.6.1.txt +++ b/Documentation/RelNotes/1.6.1.txt @@ -278,9 +278,3 @@ release, unless otherwise noted. * "gitweb" did not mark non-ASCII characters imported from external HTML fragments correctly. - --- -exec >/var/tmp/1 -O=v1.6.1-rc3-74-gf66bc5f -echo O=$(git describe master) -git shortlog --no-merges $O..master ^maint -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 2/5] Create html documents for all files in Documentation/technical
- add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann --- Documentation/Makefile| 12 ++- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 6 files changed, 45 insertions(+), 28 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..86594f6 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -25,6 +25,16 @@ SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) +API_DOCS += technical/index-format +API_DOCS += technical/pack-format +API_DOCS += technical/pack-heuristics +API_DOCS += technical/pack-protocol +API_DOCS += technical/protocol-capabilities +API_DOCS += technical/protocol-common +API_DOCS += technical/racy-git +API_DOCS += technical/send-pack-pipeline +API_DOCS += technical/shallow +API_DOCS += technical/trivial-merge SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index @@ -231,7 +241,7 @@ clean: $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format All binary numbers are in network byte order. Version 2 is described here unless stated otherwise. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64..a7871fb 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -1,7 +1,7 @@ GIT pack format === -= pack-*.pack files have the following format: +== pack-*.pack files have the following format: - A header appears at the beginning and consists of the following: @@ -34,7 +34,7 @@ GIT pack format - The trailer records 20-byte SHA1 checksum of all of the above. -= Original (version 1) pack-*.idx files have the following format: +== Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of @@ -123,8 +123,8 @@ Pack file entry: <+ -= Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: +== Version 2 pack-*.idx files support packs larger than 4 GiB, and + have some other reorganizations. They have the format: - A 4-byte magic number '\377tOc' which is an unreasonable fanout[0] value. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index d51e20f..25e1fbe 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -117,7 +117,7 @@ A few things to remember here: - The repository path is always quoted with single quotes. Fetching Data From a Server -=== +--- When one Git repository wants to get data that a second repository has, the first can 'fetch' from the second. This operation determines @@ -134,7 +134,8 @@ with the object name that each reference currently points to. $ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | nc -v example.com 9418 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack +side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 @@ -421,7 +422,7 @@ entire packfile without multiplexing. Pushing Data To a Server - + Pushing data to a server will invoke the 'receive-pack' process on the server, which will allow the client to tell it which references it should diff --git a/Documentation/technical/shall
[Patch 1/5] Fix some asciidoc layout problems
Signed-off-by: Thomas Ackermann --- Documentation/git-bisect-lk2009.txt | 12 ++-- Documentation/git-fetch-pack.txt| 5 - 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37..99bdb46 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -248,7 +248,7 @@ Bisecting: 5480 revisions left to test after this (roughly 13 steps) And after a few more steps like that, "git bisect" will eventually find a first bad commit: -- + $ git bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit commit 2ddcca36c8bcfa251724fe342c8327451988be0d @@ -257,8 +257,8 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile -- +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile + At this point we can see what the commit does, check it out (if it's not already checked out) or tinker with it, for example: @@ -305,7 +305,7 @@ to launch a script or command at each bisection step to know if the current commit is "good" or "bad". To do that, we use the "git bisect run" command. For example: -- + $ git bisect start v2.6.27 v2.6.25 Bisecting: 10928 revisions left to test after this (roughly 14 steps) [2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit @@ -331,9 +331,9 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile bisect run success -- + In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as parameter to "git bisect run". This means that at each step, the grep diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 474fa30..12cd8a2 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=] [--depth=] [--no-progress] [-v] [:] [...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=] + [--depth=] [--no-progress] + [-v] [:] [...] DESCRIPTION --- -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 0/5] Create single PDF for all HTML files
Hi, 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. The resulting PDF file "git-doc.pdf" is created by a new make target called "fullpdf". Hope anybody finds that useful. --- 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 v2] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 06, 2012 at 08:51:24PM +0700, Nguyen Thai Ngoc Duy wrote: > We support backslash escape, but we hide the details behind the phrase > "a shell glob suitable for consumption by fnmatch(3)". So it may not > be obvious how one can get literal # or ! at the beginning of pattern. > Add a few lines on how to work around the magic characters. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > On Sat, Oct 6, 2012 at 8:21 PM, Jeff King wrote: > > It works fine for me with asciidoc 8.6.7. > > 8.6.5 works. I don't care deeply as I read .txt anyway. Here it goes > again with examples. I'd be slightly worried that we are hurting other people who do care and are on older versions of asciidoc. It would be nice if we actually knew the cause of the different behaviors we saw and if there was a way to work around it (it might not even be old asciidoc, but rather old docbook). Part of me wants to just take the change and see if anybody complains. But that is probably the wrong thing to do, and just my general frustration with our doc toolchain talking. -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 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
Am 04.01.2012 01:12 schrieb Junio C Hamano: > Now "prompt" is no longer a method but is merely a helper function, so > I've queued this (and 1/2 rewrite we discussed in a separate thread) to > 'pu' after rewording the commit log message. > > Thanks. Is there a reason why these changes did not get merged? The issues are still there. -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase "a shell glob suitable for consumption by fnmatch(3)". So it may not be obvious how one can get literal # or ! at the beginning of pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy --- On Sat, Oct 6, 2012 at 8:21 PM, Jeff King wrote: > It works fine for me with asciidoc 8.6.7. 8.6.5 works. I don't care deeply as I read .txt anyway. Here it goes again with examples. Documentation/gitignore.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..0bcf079 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -73,12 +73,16 @@ PATTERN FORMAT - A blank line matches no files, so it can serve as a separator for readability. - - A line starting with # serves as a comment. + - A line starting with "`#`" serves as a comment. + Use "`\#`" instead for patterns that begin with "`#`", + for example, "`\#backup#.txt`". - - An optional prefix '!' which negates the pattern; any + - An optional prefix "`!`" which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. + Use "`\!`" instead for patterns that begin with "`!`", + for example, "`\!important!.txt`". - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- 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 Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote: > Thank you for your response. I do see the dilemma, but having > no possible "unmodified" state is extremely inconvenient and, > as shown, breaks basic git operations. But you have asked for an impossible state. You have said "this file cannot have CR when you check it in, because we erase them". And yet the version of the file in HEAD has CRs in it. So it must appear modified with respect to HEAD. And the solution is to make a commit with the normalized content. 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. > I guess my thought is that if git doesn't allow CRs to be checked > in, then it should strip the CRs when checking the file out, and > consider that form (or both forms) as "unmodified". It just > doesn't make sense to me that files are considered modified > immediately after checkout. 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. I wonder if this is a fundamental misunderstanding of how the CRLF handling in git works. It is not "magically make me not care about line endings anymore". It is "the canonical version in the repo is LF-only. Strip anything coming into the repository to match that, and (optionally) add CR to anything going out to the filesystem for my convenience". But you need a flag day to update the in-repository versions to the new scheme. -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] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 06, 2012 at 06:43:50PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sat, Oct 6, 2012 at 6:33 PM, Philip Oakley wrote:
> >> Asciidoc 8.2.6 does not like me writing
> >> "Put \# if you need a literal #.." so I go with "backslash" and
> >> "hash" instead. `\!` displays fine both in man page and html format.
> >> '!' changed to `!` because it looks clearer in monospace.
> >
> >
> > Why not put the backslash-hash in back quotes as well to give the same
> > look/feel consistency?
>
> Because asciidoc does not like \#, '\#' nor `\#`. It just shows \
> without # and I don't want to master asciidoc just to make it show \#.
It works fine for me with asciidoc 8.6.7.
I would think the "inline literal" syntax started in 8.2.5 would take
care of it; maybe there were some bug fixes, considering how new it was
in your version.
I also think switching "!" to `!` is a slight regression; it will change
fonts in the HTML version, but usually not in the manpage, and the loss
of the quotes makes things harder to read. I would use both, and it does
not hurt to also spell out the name of the punctuation.
So this:
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 96639e0..c0a5851 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -73,12 +73,15 @@ PATTERN FORMAT
- A blank line matches no files, so it can serve as a separator
for readability.
- - A line starting with # serves as a comment.
+ - A line starting with "`#`" serves as a comment.
+ Put a backslash ("`\`") in front of the first hash for the patterns
+ that start with a hash (i.e., "`\#`").
- - An optional prefix '!' which negates the pattern; any
+ - An optional prefix "`!`" which negates the pattern; any
matching file excluded by a previous pattern will become
included again. If a negated pattern matches, this will
- override lower precedence patterns sources.
+ override lower precedence patterns sources. Use "`\!`" if
+ you need a literal "`!`" at the beginning of the pattern.
- If the pattern ends with a slash, it is removed for the
purpose of the following description, but it would only find
renders to:
· A line starting with "#" serves as a comment. Put a
backslash ("\") in front of the first hash for the patterns
that start with a hash (i.e., "\#").
· An optional prefix "!" which negates the pattern; any
matching file excluded by a previous pattern will become
included again. If a negated pattern matches, this will
override lower precedence patterns sources. Use "\!" if you
need a literal "!" at the beginning of the pattern.
-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 Fri, Oct 05, 2012 at 11:26:47PM -0700, Junio C Hamano wrote: > In the case of "add/commit --interactive", it is much more clear > what state the index is in when the command gave interactive control > to the user. The short-cut "add/commit -p" interface, however, does > not give you an access to its s)tatus subcommand, making the user > experience somewhat different. > > That makes the problem much more severe for "-p" compared to > "--interactive", but the fundamental UI consistency it introduces is > the same as the issue under discussion in this thread. Agreed. > Suppose you have two paths E and F, both of which have differences > between HEAD and the index, and the index and the working tree file > (i.e. you earlier edited E and F, did "git add E F" and further > edited them). > > You say "git commit -p F". > > What should happen? It is clear that the resulting commit should > record no change since its parent commit at path E (that is what > "only" semantics mean). > > What state should the "add -p" interaction start from for path F? > Should you be picking from a patch between the state you previously > "git add"ed to the index and the working tree, or should the entire > difference between HEAD and the working tree eligible to be picked > or deferred during the "add -p" session? Starting from a temporary > index that matches HEAD essentially means that you lose the earlier > "git add F" [*1*]. > > Another case to consider is to start from the same condition, and > instead to say "git commit -p" without any pathspec. What should > happen? Hmm. Good questions. In the former case, I would have said you should definitely omit E and then start from the staged point of F, as that is almost certainly what the user meant. But that is utterly inconsistent with what we are discussing for the no-pathspec case. I have a gut feeling that what I would expect for "-p" is roughly: 1. Feed add--interactive the current index state. 2. Feed add--interactive the set of pathspecs on the command line to limit its work. 3. For any path that is updated by the interactive session, keep the result. 4. For other paths, revert to HEAD. I think that would "do what I mean" most of the time. But it is a horrible set of rules to try to explain to someone (and it is off the top of my head; I wouldn't be surprised if you can come up with a situation where those rules do not behave well). > Just doing "use a temporary index that is initialized to HEAD" may > be an expedient thing to do, but I suspect that I will be saying the > same "I should have said 'You cannot have a pony' back then" again > in a not so distant future if we did so without thinking these > things through. > > As I do not see any practical value in "commit -p", I do not think > it is worth my time thinking these things through thoroughly myself. > > Unless somebody who cares about "commit -p" does so to come up with > reasonable semantics, and updates the code to match that desired > behaviour, the responsible thing to do is to error out "-p" when > your index is different from HEAD, I think. Yeah. I did not agree with your conclusion here when we started the conversation, but I am starting to now. I am not opposed at all to somebody working out the semantics, but I do not really care to work on it myself. In the meantime, I would rather not do any halfway fixes that will just make things worse. Another option is to leave it with "-i" semantics in the meantime, which are at least easy to explain: it is simply a shorthand for running "git add -p && git commit". That may be inconsistent with other aspects of commit, but people have (apparently) been happy with it, and there has not been a rash of complaints. As a non-user of "commit -p" myself, I don't have a strong opinion either way. -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 pull takes ~8 seconds on up-to-date Linux git tree
On Fri, Oct 05, 2012 at 10:20:37PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > @@ -617,6 +618,8 @@ static struct commit_list
> >> > *paint_down_to_common(struct commit *one, int n, struc
> >> >
> >> > one->object.flags |= PARENT1;
> >> > commit_list_insert_by_date(one, &list);
> >> > +if (!n)
> >> > +return list;
> >> > for (i = 0; i < n; i++) {
> >> > twos[i]->object.flags |= PARENT2;
> >> > commit_list_insert_by_date(twos[i], &list);
> >
> > This seems like an obvious optimization, but does it really have
> > anything to do with the patch at hand?
>
> The function picks one and paints it against all others, but the
> logic assumes there must be at least one other to paint against;
> otherwise the traversal will not ever find a node that is painted
> with both PARENT1 and PARENT2 to stop, leading us to traverse all
> the way down to root.
Ah, OK. I was thinking it was just a way to skip the further logic,
which would come to the same answer (it does, just not quickly). Makes
sense.
-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] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 6, 2012 at 6:33 PM, Philip Oakley wrote: >> Asciidoc 8.2.6 does not like me writing >> "Put \# if you need a literal #.." so I go with "backslash" and >> "hash" instead. `\!` displays fine both in man page and html format. >> '!' changed to `!` because it looks clearer in monospace. > > > Why not put the backslash-hash in back quotes as well to give the same > look/feel consistency? Because asciidoc does not like \#, '\#' nor `\#`. It just shows \ without # and I don't want to master asciidoc just to make it show \#. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
From: "Nguyễn Thái Ngọc Duy" We support backslash escape, but we hide the details behind the phrase "a shell glob suitable for consumption by fnmatch(3)". So it may not be obvious how one can get literal # or ! at the beginning of a pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy --- Asciidoc 8.2.6 does not like me writing "Put \# if you need a literal #.." so I go with "backslash" and "hash" instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Why not put the backslash-hash in back quotes as well to give the same look/feel consistency? Documentation/gitignore.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..8c03ed4 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -74,11 +74,14 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + A line starting with `#` serves as a comment. + Put a backslash in front of the first hash for the patterns + that start with a hash. + Use `\#` if you need a literal `#` at the beginning of the pattern. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will - override lower precedence patterns sources. + override lower precedence patterns sources. Use `\!` if + you need a literal `!` at the beginning of the pattern. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- 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 08/10] Integrate wildmatch to git
Thiago Farina wrote:
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy
wrote:
This makes wildmatch.c part of libgit.a and builds test-wildmatch;
the dependency on libpopt in the original has been replaced with the
use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramsay Jones
Signed-off-by: Junio C Hamano
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88
++-- wildmatch.c
| 26 +--- 5 files changed, 75 insertions(+), 70
deletions(-) create mode 100755 t/t3070-wildmatch.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include "lib/wildmatch.c"
+#include "cache.h"
+#include "parse-options.h"
+#include "wildmatch.h"
-#include
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include "compat/strlcpy.c"
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc
*/
- {"iterations", 'i', POPT_ARG_NONE, &output_iterations, 0,
0, 0},
- {"empties",'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {"explode",'x', POPT_ARG_INT,&explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
Isn't static variables like this initialized to zero by default? There
is a high chance that I might be wrong though.
C99,
5.1.2.1: All objects with static storage duration shall be initialized (set
to their initial values) before program startup.
6.2.4.2: An object whose identifier is declared with external or internal
linkage, or with the storage-class specifier static has static storage
duration. Its lifetime is the entire execution of the program and its stored
value is initialized only once, prior to program startup.
6.7.8.10: If an object that has automatic storage duration is not
initialized explicitly, its value is indeterminate. If an object that has
static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned)
zero;
— if it is an aggregate, every member is initialized (recursively) according
to these rules;
— if it is a union, the first named member is initialized (recursively)
according to these rules.
So seems you're right ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase "a shell glob suitable for consumption by fnmatch(3)". So it may not be obvious how one can get literal # or ! at the beginning of a pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy --- Asciidoc 8.2.6 does not like me writing "Put \# if you need a literal #.." so I go with "backslash" and "hash" instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Documentation/gitignore.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..8c03ed4 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -74,11 +74,14 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + Put a backslash in front of the first hash for the patterns + that start with a hash. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will - override lower precedence patterns sources. + override lower precedence patterns sources. Use `\!` if + you need a literal `!` at the beginning of the pattern. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- 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
Proposed function path_in_directory() [was: Re: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths]
On 10/01/2012 06:51 AM, Michael Haggerty wrote:
> I think I would advocate that the prefix has to match the front of the
> path exactly (including any trailing slashes) and either
>
> strlen(prefix) == 0
> or the prefix ended with a '/'
> or the prefix and path are identical
> or the character in path following the matching part is a '/'
>
> This would allow the "is path its own prefix" policy to be decided by
> the caller by either including or omitting a trailing slash on the
> prefix argument.
Thinking about this more, I don't think it will work. As usual, the
special cases around "/" and "//" make things awkward. I think it is
necessary to have a separate argument to specify whether "path is its
own prefix".
So I am trying to decide how a function path_in_directory() should work,
and would like to get some feedback, especially on the following two points:
1. How should "//" be handled? I don't really have experience with the
peculiar paths that start with "//", so I'm not sure how they should be
handled (or even if the handling needs to be platform-dependent). My
working hypothesis is that the inputs should be normalized by the
caller, so if the caller wants "//" to be treated as equivalent to "/"
then the caller should normalize them *before* calling this function.
Conversely, if the caller passes "//" to the function, that implies that
"//" is distinct from "/" and "//" is considered a proper subdirectory
of "/". See the cases marked with "??" below.
2. Does there need to be any special related to DOS paths?
> /*
> * Return true iff path is within dir. The comparison is textual,
> * meaning that path and dir should be normalized and either both be
> * absolute or both be relative to the same directory. If path and
> * dir represent the *same* path, then return true iff allow_equal is
> * true. Single trailing slashes on either path or dir are ignored,
> * (except for the special case "//"); i.e., "a/b" and "a/b/" are
> * treated equivalently, as are "" and "/". Examples (* means "don't
> * care"):
> *
> * - path_in_directory("a/b", "a", *) -> true
> * - path_in_directory("a", "a/b", *) -> false
> * - path_in_directory("ab", "a", *) -> false
> * - path_in_directory("a/b", "a/b", 0) -> false
> * (same if either argument is replaced with "a/b/")
> * - path_in_directory("a/b", "a/b", 1) -> true
> * (same if either argument is replaced with "a/b/")
> * - path_in_directory(*, "/", 1) -> true
> * - path_in_directory("/", "/", 0) -> false
> * - path_in_directory("//", "/", 0) -> true??
> * - path_in_directory("//", "/", 1) -> true
> * - path_in_directory("/", "//", 0) -> false
> * - path_in_directory("/", "//", 1) -> false ??
> * - path_in_directory("/a/b", "//", *) -> false
> */
> int path_in_directory(const char *path, const char *dir, int allow_equal);
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] attr: allow pattern escape using backslash
On Sat, Oct 6, 2012 at 2:54 PM, Junio C Hamano wrote: > Shouldn't we do the same for quoting fnmatch(3) metacharacters? To > match a path component 'a' followed by an asterisk followed by 'b', > you could then write 'a\*b'. Same for quoting the backslash itself. I think my patch does that too. The thing it does not do is optimize this case so that we can do strcmp() instead of fnmatch() if the entire pattern does not contain any metacharacters but backslashes. I don't think it'll become popular enough to deserve an optimization. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] attr: allow pattern escape using backslash
Nguyễn Thái Ngọc Duy writes: > .gitattributes pattern syntax is supposed to be the same as .gitignore > (except a few things that do not make sense in attr context, but > that's a different issue). .gitignore uses fnmatch() as the matching > machinery and "\" is accepted as an escape code. In theory the pattern > 'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one > would write 'foo\ bar' in .gitignore when 'foo bar' should > suffice. > > Regardless, 'foo\ bar attr' does not (but should) attach "attr" to > path "foo bar" because pattern/attr parse code does not understand > backslash escape. It parses the line as path 'foo\' and attributes > 'bar' and 'attr'. This patch teaches attr code to recognize the > backslash in patterns (not macro names) and pass 'foo\ bar' down to > fnmatch(). > > This changes the attr behavior. "foo\ attr", if exists in the field, > would match nothing because path "foo\" is invalid in UNIX and is a > directory in Windows, which we do not accept attaching attributes > to. With this patch, that line becomes invalid and is rejected. So > it's not really bad (i.e. no silent changes in behavior). > > Other subtle behavioral changes may happen. Still, I think we should > do this as it seems like a correct thing to do. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > We discussed the "spaces in path names in attr" before and I remember > using quotes or double quotes, even substituting spaces with > dots, were raised. I don't remember if backslashes were mentioned. My knee-jerk reaction, without thinking things through, is that this makes sense and doing the same for .gitignore would, too (even though the one-item-per-line nature of .gitignore makes "\ " and " " practically equivalent). Shouldn't we do the same for quoting fnmatch(3) metacharacters? To match a path component 'a' followed by an asterisk followed by 'b', you could then write 'a\*b'. Same for quoting the backslash itself. -- 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/RFC] attr: allow pattern escape using backslash
.gitattributes pattern syntax is supposed to be the same as .gitignore
(except a few things that do not make sense in attr context, but
that's a different issue). .gitignore uses fnmatch() as the matching
machinery and "\" is accepted as an escape code. In theory the pattern
'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one
would write 'foo\ bar' in .gitignore when 'foo bar' should
suffice.
Regardless, 'foo\ bar attr' does not (but should) attach "attr" to
path "foo bar" because pattern/attr parse code does not understand
backslash escape. It parses the line as path 'foo\' and attributes
'bar' and 'attr'. This patch teaches attr code to recognize the
backslash in patterns (not macro names) and pass 'foo\ bar' down to
fnmatch().
This changes the attr behavior. "foo\ attr", if exists in the field,
would match nothing because path "foo\" is invalid in UNIX and is a
directory in Windows, which we do not accept attaching attributes
to. With this patch, that line becomes invalid and is rejected. So
it's not really bad (i.e. no silent changes in behavior).
Other subtle behavioral changes may happen. Still, I think we should
do this as it seems like a correct thing to do.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
We discussed the "spaces in path names in attr" before and I remember
using quotes or double quotes, even substituting spaces with
dots, were raised. I don't remember if backslashes were mentioned.
attr.c| 12 +++-
t/t0003-attributes.sh | 5 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/attr.c b/attr.c
index 887a9ae..173d51d 100644
--- a/attr.c
+++ b/attr.c
@@ -221,8 +221,18 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
return NULL;
}
}
- else
+ else {
is_macro = 0;
+ namelen = 0;
+ while (name[namelen] != '\0' &&
+ !strchr(blank, name[namelen])) {
+ if (name[namelen] == '\\' &&
+ name[namelen + 1] != '\0')
+ namelen += 2;
+ else
+ namelen++;
+ }
+ }
states = name + namelen;
states += strspn(states, blank);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index febc45c..16b419e 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,6 +24,7 @@ test_expect_success 'setup' '
echo "offon -test test"
echo "no notest"
echo "A/e/F test=A/e/F"
+ echo "A\\ b test=space"
) >.gitattributes &&
(
echo "g test=a/g" &&
@@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
attr_check subdir/a/i unspecified
'
+test_expect_success 'quoting in pattern' '
+ attr_check "A b" space
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
--
1.7.12.1.406.g6ab07c4
--
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 04/10] attr: more matching optimizations from .gitignore
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. -- 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
