Re: [PATCH 1/8] Use %B for Split Subject/Body
gree...@obbligato.org writes: > "David A. Greene" writes: > >> From: Techlive Zheng >> >> Use %B to format the commit message and body to avoid an extra newline >> if a commit only has a subject line. > > Wow. So that was a spectacular fail. Sorry about th duplicate patch > e-mails. I have no idea how that happened. > > -David Also, please be careful about the subject line. I doubt that these 8 patches will stand out as relating to "contrib/subtree", when mixed in 200 line output of "git shortlog --no-merges". Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
"David A. Greene" writes: > From: Techlive Zheng > > Use %B to format the commit message and body to avoid an extra newline > if a commit only has a subject line. Is this an unconditional improvement, or is it generally an improvement but for some users it may be a regression? I am guessing it is the former but am just making sure. > Author:Techlive Zheng > > Signed-off-by: David A. Greene Please don't do "Author: " which does not add anything new. That is what "From: " is for. Instead it needs to be a sign-off. Also, is that a real name, I have to wonder? 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 subtree error (just how do you expect me to merge 0 trees?)
gree...@obbligato.org writes: > Junio C Hamano writes: > >>> With one positional option, git-subtree add simply assumes >>> it's a refspec. Is there an easy way to check whether a string is a >>> proper refspec? Even better would be a way to check if a string is a >>> path to a git repository. >> >> Do you literally mean "a path to a repository" in the above, or do >> you mean "a remote that is like what is accepted by 'git fetch'"? > > It's the latter as git-subtree calls git-fetch to do the work of > getting revisions. If that is the case, t should behave similar to 'git fetch' for consistency. If you want to name "current repository", you can simply give "." as the repository parameter; this has long been supported by 'git fetch' (as 'git pull . $branch' has been the way to say 'git merge' for a long time). -- 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: [RFC] pack-objects: compression level for non-blobs
On Tue, Jan 1, 2013 at 1:06 AM, Shawn Pearce wrote: >> 3. Dropping the "commits" file and just using the pack-*.idx as the >> index. The problem is that it is sparse in the commit space. So >> just naively storing 40 bytes per entry is going to waste a lot of >> space. If we had a separate index as in (1) above, that could be >> dropped to (say) 4 bytes of offset per object. But still, right now >> the commits file for linux-2.6 is about 7.2M (20 bytes times ~376K >> commits). There are almost 3 million total objects, so even storing >> 4 bytes per object is going to be worse. > > Fix pack-objects to behave the way JGit does, cluster commits first in > the pack stream. Now you have a dense space of commits. If I remember > right this has a tiny positive improvement for most rev-list > operations with very little downside. I was going to suggest a similar thing. The current state of C Git's pack writing is not bad. We mix commits and tags together, but tags are few usually. Once we get the upper and lower bound, in terms of object position in the pack, of the commit+tag region, we could reduce the waste significantly. That is if you sort the cache by the object order in the pack. -- 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 1/8] Use %B for Split Subject/Body
"David A. Greene" writes: > From: Techlive Zheng > > Use %B to format the commit message and body to avoid an extra newline > if a commit only has a subject line. Wow. So that was a spectacular fail. Sorry about th duplicate patch e-mails. I have no idea how that happened. -David -- 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 subtree error (just how do you expect me to merge 0 trees?)
Junio C Hamano writes: >> With one positional option, git-subtree add simply assumes >> it's a refspec. Is there an easy way to check whether a string is a >> proper refspec? Even better would be a way to check if a string is a >> path to a git repository. > > Do you literally mean "a path to a repository" in the above, or do > you mean "a remote that is like what is accepted by 'git fetch'"? It's the latter as git-subtree calls git-fetch to do the work of getting revisions. > On the other hand, if you mean the command takes a remote and an > optional list of refspecs just like "git fetch" does, then I am not > sure it is a good design in the first place to allow "refspecs > only", if only to keep the interface similar to "git fetch" (you > cannot omit remote and give refspecs, as you cannot interpret > refspecs without knowing in the context of which remote they are to > be interpreted). If just a refspec is given, git-subtree does a rev-parse in the current directory and that seems to work fine. It's what I as a user would expect to happen. > I would imagine you could disambiguate and default to "origin" or > something when you guessed that remote was omitted if you really > wanted to, with a syntacitical heuristics, such as "a refspec will > never have two colons in it", "a URL tends to begin with a short > alphabet word, a colon and double-slash", etc. Hmm...I haven't added code to verify the repository/remote argument if given. I suppose a rev-parse --verify would suffice? -David -- 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] subtree.sh: Use raw subject and body modifier "%B" instead of "%s%n%n%b"
gree...@obbligato.org writes: > I've applied this patch to my working copy but I'm not finding that I > can recreate the original problem when the patch is disabled. ^ not -David -- 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 7/8] Ignore git-subtree
From: Michael Schubert Add the git-subtree command executable to .gitignore. Author:Michael Schubert Signed-off-by:Michael Schubert Signed-off-by: David A. Greene --- contrib/subtree/.gitignore |1 + 1 file changed, 1 insertion(+) diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore index 7e77c9d..91360a3 100644 --- a/contrib/subtree/.gitignore +++ b/contrib/subtree/.gitignore @@ -1,4 +1,5 @@ *~ +git-subtree git-subtree.xml git-subtree.1 mainline -- 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
[PATCH 6/8] Make the Manual Directory if Needed
From: "Jesper L. Nielsen" Before install git-subtree documentation, make sure the manpage directory exists. Author:Jesper L. Nielsen Signed-off-by:Jesper L. Nielsen Signed-off-by: David A. Greene --- contrib/subtree/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 36ae3e4..52d6fb9 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -35,6 +35,7 @@ install: $(GIT_SUBTREE) install-doc: install-man install-man: $(GIT_SUBTREE_DOC) + mkdir -p $(man1dir) $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) -- 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
[PATCH 8/8] Fix Documentation Typo
From: Michael Schubert "split" is documented below "push" so fix the reference to it in push's documentation. Author:Michael Schubert Signed-off-by:Michael Schubert Signed-off-by: David A. Greene --- contrib/subtree/git-subtree.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index 89c2d6e..078d4ac 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -94,7 +94,7 @@ pull:: repository. push:: - Does a 'split' (see above) using the supplied + Does a 'split' (see below) using the supplied and then does a 'git push' to push the result to the repository and refspec. This can be used to push your subtree to different branches of the remote repository. -- 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
[PATCH 4/8] Fix Synopsis
From: "David A. Greene" Fix the documentation of add to show that a repository can be specified along with a commit. Change "commit" to "refspec" in the synopsis for add. Suggested by Yann Dirson . Signed-off-by: David A. Greene --- contrib/subtree/git-subtree.sh |3 ++- contrib/subtree/git-subtree.txt |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index b8a807a..ad62dfb 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -8,7 +8,8 @@ if [ $# -eq 0 ]; then set -- -h fi OPTS_SPEC="\ -git subtree add --prefix= +git subtree add --prefix= +git subtree add --prefix= git subtree merge --prefix= git subtree pull --prefix= git subtree push --prefix= diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index ae420aa..89c2d6e 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -9,7 +9,8 @@ git-subtree - Merge subtrees together and split repository into subtrees SYNOPSIS [verse] -'git subtree' add -P +'git subtree' add -P +'git subtree' add -P 'git subtree' pull -P 'git subtree' push -P 'git subtree' merge -P -- 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
[PATCH 5/8] Honor DESTDIR
From: Adam Tkac Teach git-subtree's Makefile to honor DESTDIR. Author:Adam Tkac Signed-off-by:Adam Tkac Signed-off-by: David A. Greene --- contrib/subtree/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 05cdd5c..36ae3e4 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH) doc: $(GIT_SUBTREE_DOC) install: $(GIT_SUBTREE) - $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir) + $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir) install-doc: install-man install-man: $(GIT_SUBTREE_DOC) - $(INSTALL) -m 644 $^ $(man1dir) + $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) xmlto -m $(MANPAGE_NORMAL_XSL) man $^ -- 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
[PATCH 3/8] Better Error Handling for add
From: "David A. Greene" Check refspecs for validity before passing them on to other commands. This lets us generate more helpful error messages. Signed-off-by: David A. Greene --- contrib/subtree/git-subtree.sh | 12 1 file changed, 12 insertions(+) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 7ceb413..b8a807a 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -509,8 +509,20 @@ cmd_add() ensure_clean if [ $# -eq 1 ]; then + ref=$(git check-ref-format --normalize "refs/heads/$1") || +die "'$1' is not a valid refspec. Are you missing a branch?" + + rev=$(git rev-parse --verify $1) || +die "'$1' is not a valid refspec. Are you missing a branch?" + "cmd_add_commit" "$@" elif [ $# -eq 2 ]; then + ref=$(git check-ref-format --normalize "refs/heads/$2") || +die "'$2' is not a valid refspec." + + rev=$(git rev-parse --verify $2) || +die "'$2' is not a valid refspec." + "cmd_add_repository" "$@" else say "error: parameters were '$@'" -- 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
[PATCH 2/8] Add --unannotate
From: James Nylen
Teach git-subtree about --unannotate. This option strips a prefix
from a commit message when doing a subtree split.
Author:James Nylen
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh | 11 +-
contrib/subtree/git-subtree.txt| 15
contrib/subtree/t/t7900-subtree.sh | 73
3 files changed, 65 insertions(+), 34 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index f2b6d4a..7ceb413 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge commit
options for 'split'
annotate= add a prefix to commit message of new commits
+unannotate= remove a prefix from new commit messages (supports bash globbing)
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,6 +44,7 @@ onto=
rejoin=
ignore_joins=
annotate=
+unannotate=
squash=
message=
@@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
-d) debug=1 ;;
--annotate) annotate="$1"; shift ;;
--no-annotate) annotate= ;;
+ --unannotate) unannotate="$1"; shift ;;
+ --no-unannotate) unannotate= ;;
-b) branch="$1"; shift ;;
-P) prefix="$1"; shift ;;
-m) message="$1"; shift ;;
@@ -315,8 +319,11 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n "$annotate"; cat ) |
- git commit-tree "$2" $3 # reads the rest of stdin
+ (
+ read FIRST_LINE
+ echo "$annotate${FIRST_LINE#$unannotate}"
+ cat # reads the rest of stdin
+ ) | git commit-tree "$2" $3
) || die "Can't copy commit $1"
}
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..ae420aa 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -198,6 +198,21 @@ OPTIONS FOR split
git subtree tries to make it work anyway, particularly
if you use --rejoin, but it may not always be effective.
+--unannotate=::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+from each commit message (using bash's "strip
+ shortest match from beginning" command, which supports
+ globbing). This makes sense if you format library commits
+ like "library: Change something or other" when you're working
+ in your project's repository, but you want to remove this
+ prefix when pushing back to the library's upstream repository.
+ (In this case --unannotate='*: ' would work well.)
+
+ Like --annotate, you need to use the same
+ whenever you split, or you may run into problems.
+
-b ::
--branch=::
This option is only valid for the split command.
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 93eeb09..9816da5 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -157,7 +157,7 @@ test_expect_success 'merge fetched subproj' '
# 14
test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
-git commit -m "main-sub5"
+git commit -m "subproj: main-sub5"
'
# 15
test_expect_success 'add main6' '
@@ -168,7 +168,7 @@ test_expect_success 'add main6' '
# 16
test_expect_success 'add main-sub7' '
create subdir/main-sub7 &&
-git commit -m "main-sub7"
+git commit -m "subproj: main-sub7"
'
# 17
@@ -238,7 +238,7 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
-#25
+# 25
test_expect_success 'check hash of split' '
spl1=$(git subtree split --prefix subdir) &&
undo &&
@@ -251,6 +251,15 @@ test_expect_success 'check hash of split' '
'
# 26
+test_expect_success 'check --unannotate' '
+spl1=$(git subtree split --unannotate='"subproj:"' --prefix subdir
--onto FETCH_HEAD --message "Split & rejoin" --rejoin) &&
+undo &&
+git subtree split --unannotate='"subproj:"' --prefix subdir --onto
FETCH_HEAD --branch splitunann &&
+check_equal ''"$(git rev-parse splitunann)"'' "$spl1" &&
+check_equal ''"$(git log splitunann | grep subproj)"'' ""
+'
+
+# 27
test_expect_success 'check split with --branch for an existing branch' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto
FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -259,13 +26
[PATCH 1/8] Use %B for Split Subject/Body
From: Techlive Zheng
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Author:Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |5 +++
contrib/subtree/t/t7900-subtree.sh | 73 ++--
2 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..f2b6d4a 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -296,7 +296,12 @@ copy_commit()
# We're going to set some environment vars here, so
# do it in a subshell to get rid of them safely later
debug copy_commit "{$1}" "{$2}" "{$3}"
+ # Use %B rather than %s%n%n%b to handle the special case of a
+ # commit that only has a subject line. We don't want to
+ # introduce a newline after the subject, causing generation of
+ # a new hash.
git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b'
"$1" |
+# git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
(
read GIT_AUTHOR_NAME
read GIT_AUTHOR_EMAIL
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index bc2eeb0..93eeb09 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -76,6 +76,10 @@ test_expect_success 'add sub1' '
git branch -m master subproj
'
+# Save this hash for testing later.
+
+subdir_hash=`git rev-parse HEAD`
+
# 3
test_expect_success 'add sub2' '
create sub2 &&
@@ -155,7 +159,6 @@ test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
git commit -m "main-sub5"
'
-
# 15
test_expect_success 'add main6' '
create main6 &&
@@ -235,7 +238,19 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
-# 25
+#25
+test_expect_success 'check hash of split' '
+spl1=$(git subtree split --prefix subdir) &&
+undo &&
+git subtree split --prefix subdir --branch splitbr1test &&
+check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1"
+git checkout splitbr1test &&
+new_hash=$(git rev-parse HEAD~2) &&
+git checkout mainline &&
+check_equal ''"$new_hash"'' "$subdir_hash"
+'
+
+# 26
test_expect_success 'check split with --branch for an existing branch' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto
FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -244,13 +259,13 @@ test_expect_success 'check split with --branch for an
existing branch' '
check_equal ''"$(git rev-parse splitbr2)"'' "$spl1"
'
-# 26
+# 27
test_expect_success 'check split with --branch for an incompatible branch' '
test_must_fail git subtree split --prefix subdir --onto FETCH_HEAD
--branch subdir
'
-# 27
+# 28
test_expect_success 'check split+rejoin' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto
FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -258,7 +273,7 @@ test_expect_success 'check split+rejoin' '
check_equal ''"$(last_commit_message)"'' "Split '"'"'subdir/'"'"' into
commit '"'"'"$spl1"'"'"'"
'
-# 28
+# 29
test_expect_success 'add main-sub8' '
create subdir/main-sub8 &&
git commit -m "main-sub8"
@@ -267,14 +282,14 @@ test_expect_success 'add main-sub8' '
# To the subproject!
cd ./subproj
-# 29
+# 30
test_expect_success 'merge split into subproj' '
git fetch .. spl1 &&
git branch spl1 FETCH_HEAD &&
git merge FETCH_HEAD
'
-# 30
+# 31
test_expect_success 'add sub9' '
create sub9 &&
git commit -m "sub9"
@@ -283,19 +298,19 @@ test_expect_success 'add sub9' '
# Back to mainline
cd ..
-# 31
+# 32
test_expect_success 'split for sub8' '
split2=''"$(git subtree split --annotate='"'*'"' --prefix subdir/
--rejoin)"''
git branch split2 "$split2"
'
-# 32
+# 33
test_expect_success 'add main-sub10' '
create subdir/main-sub10 &&
git commit -m "main-sub10"
'
-# 33
+# 34
test_expect_success 'split for sub10' '
spl3=''"$(git subtree split --annotate='"'*'"' --prefix subdir
--rejoin)"'' &&
git branch spl3 "$spl3"
@@ -304,7 +319,7 @@ test_expect_success 'split for sub10' '
# To the subproject!
cd ./subproj
-# 34
+# 35
test_expect_success 'merge split into subproj' '
git fetch .. spl3 &&
git branch spl3 FETCH_HEAD &&
@@ -318,13 +333,13 @@ chkms_sub=$(echo $chkms | multiline | sed 's,^,subdir/,'
| fixnl)
chks="sub1 sub2 sub3 sub9"
chks_sub=$(echo $chks | multiline | sed 's,^,subdir/,' | fixnl)
-# 35
+# 36
test_expect_success 'make sure exactly the right set of files ends up in the
subproj' '
subfiles=''"$(g
git-subtree Patches to Apply
Here are all of the patches for git-subtree that have been posted to the mailing list that I could apply and test in a reasonable amount of time. These are all rebased from trunk as of tonight. Many apologies for being *so* behind. Work has been a bear but I'm hoping things will ease up in the new year and I can be more regularly active. But still, don't expect same-day service. :) These are also available on branch "toupstream" via git clone gitol...@sources.obbligato.org:git.git and http://sources.obbligato.org http://sources.obbligato.org/?p=git.git;a=summary Junio, can you apply these? Thanks! -David -- 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 subtree error (just how do you expect me to merge 0 trees?)
gree...@obbligato.org writes: > git-subtree add accepts either a refspec or a path to a repository and a > refspec. > With one positional option, git-subtree add simply assumes > it's a refspec. Is there an easy way to check whether a string is a > proper refspec? Even better would be a way to check if a string is a > path to a git repository. Do you literally mean "a path to a repository" in the above, or do you mean "a remote that is like what is accepted by 'git fetch'"? If you literary mean it is is a path to a git repository, you could obviously use "cd $there && git rev-parse --git-dir" or something. On the other hand, if you mean the command takes a remote and an optional list of refspecs just like "git fetch" does, then I am not sure it is a good design in the first place to allow "refspecs only", if only to keep the interface similar to "git fetch" (you cannot omit remote and give refspecs, as you cannot interpret refspecs without knowing in the context of which remote they are to be interpreted). I would imagine you could disambiguate and default to "origin" or something when you guessed that remote was omitted if you really wanted to, with a syntacitical heuristics, such as "a refspec will never have two colons in it", "a URL tends to begin with a short alphabet word, a colon and double-slash", etc. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-subtree: ignore git-subtree executable
Michael Schubert writes: > Signed-off-by: Michael Schubert Obviously good. Applied and will send for integration. -David -- 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] For git-subtree, when installing docs (make install-doc), create man1 folder first.
"Jesper L. Nielsen" writes: > So, small patch to create the folder first in the Makefile. Hope > everything is right with the patch and submitting of the patch. I've applied this to my local copy and will send it to the list for integration. Thanks for fixing this! -David -- 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/7] format-patch --reroll-count
On Sat, Dec 22, 2012 at 3:33 PM, Junio C Hamano wrote: > The --reroll-count=$N option, when given a positive integer: > > - Adds " v$N" to the subject prefix specified. As the default >subject prefix string is "PATCH", --reroll-count=2 makes it >"PATCH v2". > > - Prefixes "v$N-" to the names used for output files. The cover >letter, whose name is usually -cover-letter.patch, becomes >v2--cover-letter.patch when given --reroll-count=2. On the same subject of format-patch improvements, perhaps we should also: - Keep subject line in branch.%s.description too. No point in keeping writing the subject on every reroll. - Perhaps an option to save the current tip in reflog with reroll count so one can easily diff between two rerolls. -- 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] For git-subtree, when installing docs (make install-doc), create man1 folder first.
Junio C Hamano writes: > "Jesper L. Nielsen" writes: > >> From: "Jesper L. Nielsen" >> >> Hi.. >> >> I installed Git subtree and discovered that the if the man1dir doesn't exist >> the man-page for Git Subtree is just called man1. >> >> So, small patch to create the folder first in the Makefile. Hope everything >> is right with the patch and submitting of the patch. >> >> Best Regards >> Jesper >> >> Signed-off-by: Jesper L. Nielsen >> --- > > Thanks. David, Ack? Yep. I can add it to my queue which I'll send to you tomorrow. Otherwise, feel free to apply it to your copy. -David -- 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] DESTDIR support in contrib/subtree/Makefile
Adam Tkac writes: > Signed-off-by: Adam Tkac > --- > > It is a good habit in Makefiles to honor DESTDIR variable to support > > `make DESTDIR=/instalroot install` > > syntax. > > Comments are welcomed. Applied. I'll be sending this to the mailing list tonight or tomorrow. -David -- 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: [DOCBUG] git subtree synopsis needs updating
Yann Dirson writes: > As the examples in git-subtree.txt show, the synopsis in the same file should > surely get a patch along the lines of: > > -'git subtree' add -P > +'git subtree' add -P > > Failure to specify the repository (by just specifying a local commit) fails > with > the cryptic: > > warning: read-tree: emptying the index with no arguments is deprecated; use > --empty > fatal: just how do you expect me to merge 0 trees? Specifying a local branch works fine, though, as does a raw commit hash. What do you mean by "local commit?" I have updated the documentation and will submit it tonight or tomorrow. Any invalid refspec should be caught early and a more useful message will be displayed. > Furthermore, the doc paragraph for add, aside from mentionning , > also > mentions a which the synopsis does not show either. Fixed. > As a sidenote it someone wants to do some maintainance, using "." as > repository when > the branch to subtree-add is already locally available does not work well > either > (fails with "could not find ref myremote/myhead"). Seems to work for me. Can you give me the command you're using when you see the problem? Thanks for the report! -David -- 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 10/10] Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
This is similar to NO_FNMATCH but it uses wildmatch instead of
compat/fnmatch. This is an intermediate step to let wildmatch be used
as fnmatch replacement for wider audience before it replaces fnmatch
completely and compat/fnmatch is removed.
fnmatch in test-wildmatch is not impacted by this and is the only
place that NO_FNMATCH or NO_FNMATCH_CASEFOLD remain active when
USE_WILDMATCH is set.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 6 ++
git-compat-util.h | 13 +
test-wildmatch.c | 3 +++
3 files changed, 22 insertions(+)
diff --git a/Makefile b/Makefile
index bc868d1..24e2774 100644
--- a/Makefile
+++ b/Makefile
@@ -99,6 +99,9 @@ all::
# Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
# FNM_CASEFOLD GNU extension.
#
+# Define USE_WILDMATCH if you want to use Git's wildmatch
+# implementation as fnmatch
+#
# Define NO_GECOS_IN_PWENT if you don't have pw_gecos in struct passwd
# in the C library.
#
@@ -1625,6 +1628,9 @@ ifdef NO_FNMATCH_CASEFOLD
COMPAT_OBJS += compat/fnmatch/fnmatch.o
endif
endif
+ifdef USE_WILDMATCH
+ COMPAT_CFLAGS += -DUSE_WILDMATCH
+endif
ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..b2c7638 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -106,7 +106,9 @@
#include
#include
#include
+#ifndef USE_WILDMATCH
#include
+#endif
#include
#include
#include
@@ -238,6 +240,17 @@ extern char *gitbasename(char *);
#include "compat/bswap.h"
+#ifdef USE_WILDMATCH
+#include "wildmatch.h"
+#define FNM_PATHNAME WM_PATHNAME
+#define FNM_CASEFOLD WM_CASEFOLD
+#define FNM_NOMATCH WM_NOMATCH
+static inline int fnmatch(const char *pattern, const char *string, int flags)
+{
+ return wildmatch(pattern, string, flags, NULL);
+}
+#endif
+
/* General helper functions */
extern void vreportf(const char *prefix, const char *err, va_list params);
extern void vwritef(int fd, const char *prefix, const char *err, va_list
params);
diff --git a/test-wildmatch.c b/test-wildmatch.c
index ac86800..a3e2643 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -1,3 +1,6 @@
+#ifdef USE_WILDMATCH
+#undef USE_WILDMATCH /* We need real fnmatch implementation here */
+#endif
#include "cache.h"
#include "wildmatch.h"
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/10] wildmatch: advance faster in + patterns
Normally when we match "*X" on "abcX", we call dowild("X", "abcX"),
dowild("X", "bcX"), dowild("X", "cX") and dowild("X", "X"). Only the
last call may have a chance of matching. By skipping the text before
"X", we can eliminate the first three useless calls.
compat, '*/*/*' on linux-2.6.git file list 2000 times, before:
wildmatch 7s 985049us
fnmatch 2s 735541us or 34.26% faster
and after:
wildmatch 4s 492549us
fnmatch 0s 888263us or 19.77% slower
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t3070-wildmatch.sh | 8
wildmatch.c | 23 +++
2 files changed, 31 insertions(+)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 97f1daf..4c37057 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -207,6 +207,11 @@ match 0 x foo '*/*/*'
match 0 x foo/bar '*/*/*'
match 1 x foo/bba/arr '*/*/*'
match 0 x foo/bb/aa/rr '*/*/*'
+match 1 x foo/bb/aa/rr '**/**/**'
+match 1 x abcXdefXghi '*X*i'
+match 0 x ab/cXd/efXg/hi '*X*i'
+match 1 x ab/cXd/efXg/hi '*/*X*/*/*i'
+match 1 x ab/cXd/efXg/hi '**/*X*/**/*i'
pathmatch 1 foo foo
pathmatch 0 foo fo
@@ -226,5 +231,8 @@ pathmatch 0 foo '*/*/*'
pathmatch 0 foo/bar '*/*/*'
pathmatch 1 foo/bba/arr '*/*/*'
pathmatch 1 foo/bb/aa/rr '*/*/*'
+pathmatch 1 abcXdefXghi '*X*i'
+pathmatch 1 ab/cXd/efXg/hi '*/*X*/*/*i'
+pathmatch 1 ab/cXd/efXg/hi '*Xg*i'
test_done
diff --git a/wildmatch.c b/wildmatch.c
index bb42522..7192bdc 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -133,6 +133,29 @@ static int dowild(const uchar *p, const uchar *text,
unsigned int flags)
while (1) {
if (t_ch == '\0')
break;
+ /*
+* Try to advance faster when an asterisk is
+* followed by a literal. We know in this case
+* that the the string before the literal
+* must belong to "*".
+* If match_slash is false, do not look past
+* the first slash as it cannot belong to '*'.
+*/
+ if (!is_glob_special(*p)) {
+ p_ch = *p;
+ if ((flags & WM_CASEFOLD) &&
ISUPPER(p_ch))
+ p_ch = tolower(p_ch);
+ while ((t_ch = *text) != '\0' &&
+ (match_slash || t_ch != '/')) {
+ if ((flags & WM_CASEFOLD) &&
ISUPPER(t_ch))
+ t_ch = tolower(t_ch);
+ if (t_ch == p_ch)
+ break;
+ text++;
+ }
+ if (t_ch != p_ch)
+ return WM_NOMATCH;
+ }
if ((matched = dowild(p, text, flags)) !=
WM_NOMATCH) {
if (!match_slash || matched !=
WM_ABORT_TO_STARSTAR)
return matched;
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/10] wildmatch: make a special case for "*/" with FNM_PATHNAME
Normally we need recursion for "*". In this case we know that it
matches everything until "/" so we can skip the recursion.
glibc, '*/*/*' on linux-2.6.git file list 2000 times
before:
wildmatch 8s 74513us
fnmatch 1s 97042us or 13.59% faster
after:
wildmatch 3s 521862us
fnmatch 3s 488616us or 99.06% slower
Same test with compat/fnmatch:
wildmatch 8s 110763us
fnmatch 2s 980845us or 36.75% faster
wildmatch 3s 522156us
fnmatch 1s 544487us or 43.85% slower
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t3070-wildmatch.sh | 8
wildmatch.c | 12
2 files changed, 20 insertions(+)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 5c9601a..97f1daf 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -203,6 +203,10 @@ match 1 1
'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/
match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1'
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
+match 0 x foo '*/*/*'
+match 0 x foo/bar '*/*/*'
+match 1 x foo/bba/arr '*/*/*'
+match 0 x foo/bb/aa/rr '*/*/*'
pathmatch 1 foo foo
pathmatch 0 foo fo
@@ -218,5 +222,9 @@ pathmatch 0 foo/bba/arr 'foo/*z'
pathmatch 0 foo/bba/arr 'foo/**z'
pathmatch 1 foo/bar 'foo?bar'
pathmatch 1 foo/bar 'foo[/]bar'
+pathmatch 0 foo '*/*/*'
+pathmatch 0 foo/bar '*/*/*'
+pathmatch 1 foo/bba/arr '*/*/*'
+pathmatch 1 foo/bb/aa/rr '*/*/*'
test_done
diff --git a/wildmatch.c b/wildmatch.c
index 536470b..bb42522 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -117,6 +117,18 @@ static int dowild(const uchar *p, const uchar *text,
unsigned int flags)
return WM_NOMATCH;
}
return WM_MATCH;
+ } else if (!match_slash && *p == '/') {
+ /*
+* _one_ asterisk followed by a slash
+* with WM_PATHNAME matches the next
+* directory
+*/
+ const char *slash = strchr((char*)text, '/');
+ if (!slash)
+ return WM_NOMATCH;
+ text = (const uchar*)slash;
+ /* the slash is consumed by the top-level for
loop */
+ break;
}
while (1) {
if (t_ch == '\0')
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] wildmatch: support "no FNM_PATHNAME" mode
So far, wildmatch() has always honoured directory boundary and there
was no way to turn it off. Make it behave more like fnmatch() by
requiring all callers that want the FNM_PATHNAME behaviour to pass
that in the equivalent flag WM_PATHNAME. Callers that do not specify
WM_PATHNAME will get wildcards like ? and * in their patterns matched
against '/', just like not passing FNM_PATHNAME to fnmatch().
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c| 2 +-
t/t3070-wildmatch.sh | 27 +++
test-wildmatch.c | 6 --
wildmatch.c | 13 +
wildmatch.h | 1 +
5 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/dir.c b/dir.c
index 175a182..6ef0396 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,7 @@ int match_pathname(const char *pathname, int pathlen,
}
return wildmatch(pattern, name,
-ignore_case ? WM_CASEFOLD : 0,
+WM_PATHNAME | (ignore_case ? WM_CASEFOLD : 0),
NULL) == 0;
}
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index af54c83..5c9601a 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -29,6 +29,18 @@ match() {
fi
}
+pathmatch() {
+if [ $1 = 1 ]; then
+ test_expect_success "pathmatch:match '$2' '$3'" "
+ test-wildmatch pathmatch '$2' '$3'
+ "
+else
+ test_expect_success "pathmatch: no match '$2' '$3'" "
+ ! test-wildmatch pathmatch '$2' '$3'
+ "
+fi
+}
+
# Basic wildmat features
match 1 1 foo foo
match 0 0 foo bar
@@ -192,4 +204,19 @@ match 0 0
'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
+pathmatch 1 foo foo
+pathmatch 0 foo fo
+pathmatch 1 foo/bar foo/bar
+pathmatch 1 foo/bar 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/*'
+pathmatch 1 foo/bba/arr 'foo/**'
+pathmatch 1 foo/bba/arr 'foo*'
+pathmatch 1 foo/bba/arr 'foo**'
+pathmatch 1 foo/bba/arr 'foo/*arr'
+pathmatch 1 foo/bba/arr 'foo/**arr'
+pathmatch 0 foo/bba/arr 'foo/*z'
+pathmatch 0 foo/bba/arr 'foo/**z'
+pathmatch 1 foo/bar 'foo?bar'
+pathmatch 1 foo/bar 'foo[/]bar'
+
test_done
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 4bb23b4..a5f4833 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,11 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
- return !!wildmatch(argv[3], argv[2], 0, NULL);
+ return !!wildmatch(argv[3], argv[2], WM_PATHNAME, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
- return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
+ return !!wildmatch(argv[3], argv[2], WM_PATHNAME | WM_CASEFOLD,
NULL);
+ else if (!strcmp(argv[1], "pathmatch"))
+ return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 1b5bbac..536470b 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -78,14 +78,17 @@ static int dowild(const uchar *p, const uchar *text,
unsigned int flags)
continue;
case '?':
/* Match anything but '/'. */
- if (t_ch == '/')
+ if ((flags & WM_PATHNAME) && t_ch == '/')
return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
const uchar *prev_p = p - 2;
while (*++p == '*') {}
- if ((prev_p < pattern || *prev_p == '/') &&
+ if (!(flags & WM_PATHNAME))
+ /* without WM_PATHNAME, '*' == '**' */
+ match_slash = 1;
+ else if ((prev_p < pattern || *prev_p == '/') &&
(*p == '\0' || *p == '/' ||
(p[0] == '\\' && p[1] == '/'))) {
/*
@@ -104,7 +107,8 @@ static int dowild(const uchar *p, const uchar *text,
unsigned int flags)
} else
return WM_ABORT_MALFORMED;
} else
- match_slash = 0;
+ /* without WM_PATHNAME, '*' == '**' */
+ match_slash = flags & WM_PATHNAME ? 0 : 1;
if (*p == '\0') {
/* Trailing "**" matches everything. Trailing
"*" matches
* only if there ar
[PATCH v3 07/10] test-wildmatch: add "perf" command to compare wildmatch and fnmatch
It takes a text file, a pattern, a number and pathname flag. Each
line in the text file is matched against the pattern times. If
"pathname" is given, FNM_PATHNAME is used.
test-wildmatch is built with -O2 and tested against glibc 2.14.1 (also
-O2) and compat/fnmatch. The input file is linux-2.6.git file list.
is 2000. The complete command list is at the end.
wildmatch is beaten in the following cases. Apparently it needs some
improvement in FNM_PATHNAME case:
glibc, '*/*/*' with FNM_PATHNAME:
wildmatch 8s 1559us
fnmatch 1s 11877us or 12.65% faster
compat, '*/*/*' with FNM_PATHNAME:
wildmatch 7s 922458us
fnmatch 2s 905111us or 36.67% faster
compat, '*/*/*' without FNM_PATHNAME:
wildmatch 7s 264201us
fnmatch 2s 1897us or 27.56% faster
compat, '[a-z]*/[a-z]*/[a-z]*' with FNM_PATHNAME:
wildmatch 8s 742827us
fnmatch 0s 922943us or 10.56% faster
compat, '[a-z]*/[a-z]*/[a-z]*' without FNM_PATHNAME:
wildmatch 8s 284520us
fnmatch 0s 6936us or 0.08% faster
The rest of glibc numbers
-
'Documentation/*'
wildmatch 1s 529479us
fnmatch 1s 98263us or 71.81% slower
'drivers/*'
wildmatch 1s 988288us
fnmatch 1s 192049us or 59.95% slower
'Documentation/*' pathname
wildmatch 1s 557507us
fnmatch 1s 93696us or 70.22% slower
'drivers/*' pathname
wildmatch 2s 161626us
fnmatch 1s 230372us or 56.92% slower
'[Dd]ocu[Mn]entation/*'
wildmatch 1s 776581us
fnmatch 1s 471693us or 82.84% slower
'[Dd]o?u[Mn]en?ati?n/*'
wildmatch 1s 770770us
fnmatch 1s 555727us or 87.86% slower
'[Dd]o?u[Mn]en?ati?n/*' pathname
wildmatch 1s 783507us
fnmatch 1s 537029us or 86.18% slower
'[A-Za-z][A-Za-z]??*'
wildmatch 4s 110386us
fnmatch 4s 926306us or 119.85% slower
'[A-Za-z][A-Za-z]??'
wildmatch 3s 918114us
fnmatch 3s 686175us or 94.08% slower
'[A-Za-z][A-Za-z]??*' pathname
wildmatch 4s 453746us
fnmatch 4s 955856us or 111.27% slower
'[A-Za-z][A-Za-z]??' pathname
wildmatch 3s 896646us
fnmatch 3s 733828us or 95.82% slower
'*/*/*'
wildmatch 7s 287985us
fnmatch 1s 74083us or 14.74% slower
'[a-z]*/[a-z]*/[a-z]*' pathname
wildmatch 8s 796659us
fnmatch 1s 568409us or 17.83% slower
'[a-z]*/[a-z]*/[a-z]*'
wildmatch 8s 316559us
fnmatch 3s 430652us or 41.25% slower
The rest of compat numbers
--
'Documentation/*'
wildmatch 1s 520389us
fnmatch 0s 62579us or 4.12% slower
'drivers/*'
wildmatch 1s 955354us
fnmatch 0s 190109us or 9.72% slower
'Documentation/*' pathname
wildmatch 1s 561675us
fnmatch 0s 55336us or 3.54% slower
'drivers/*' pathname
wildmatch 2s 106100us
fnmatch 0s 219680us or 10.43% slower
'[Dd]ocu[Mn]entation/*'
wildmatch 1s 750810us
fnmatch 0s 542721us or 31.00% slower
'[Dd]o?u[Mn]en?ati?n/*'
wildmatch 1s 724791us
fnmatch 0s 538948us or 31.25% slower
'[Dd]o?u[Mn]en?ati?n/*' pathname
wildmatch 1s 731403us
fnmatch 0s 537474us or 31.04% slower
'[A-Za-z][A-Za-z]??*'
wildmatch 4s 28555us
fnmatch 1s 67297us or 26.49% slower
'[A-Za-z][A-Za-z]??'
wildmatch 3s 838279us
fnmatch 0s 880005us or 22.93% slower
'[A-Za-z][A-Za-z]??*' pathname
wildmatch 4s 379476us
fnmatch 1s 55643us or 24.10% slower
'[A-Za-z][A-Za-z]??' pathname
wildmatch 3s 830910us
fnmatch 0s 849699us or 22.18% slower
The following commands are used:
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'Documentation/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'drivers/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'Documentation/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt 'drivers/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]ocu[Mn]entation/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??*' 2000
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[A-Za-z][A-Za-z]??' 2000
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '*/*/*' 2000
LANG=C ./test-wildmatch perf /tmp/filelist.txt '*/*/*' 2000 pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[a-z]*/[a-z]*/[a-z]*' 2000
pathname
LANG=C ./test-wildmatch perf /tmp/filelist.txt '[a-z]*/[a-z]*/[a-z]*' 2000
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-wildmatch.c | 73
1 file changed, 73 insertions(+)
diff --git a/test-wildmatch.c b/test-wildmatch.c
index a5f4833..ac86800 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -1,9 +1,82 @@
#include "cache.h"
#include "wildmatch.h"
+static int perf(int ac, char **av)
+{
+ struct timeval tv1, tv2;
+ struct stat st;
+ int fd, i, n, flags1 = 0, flags2 = 0;
+ char *buffer, *p;
+ uint32_t usec1, usec2;
+ const char *lang;
+ const char *file = av[0];
+ const
[PATCH v3 05/10] wildmatch: make dowild() take arbitrary flags
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index 2a655fa..1b5bbac 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -52,7 +52,7 @@ typedef unsigned char uchar;
#define ISXDIGIT(c) (ISASCII(c) && isxdigit(c))
/* Match pattern "p" against "text" */
-static int dowild(const uchar *p, const uchar *text, int force_lower_case)
+static int dowild(const uchar *p, const uchar *text, unsigned int flags)
{
uchar p_ch;
const uchar *pattern = p;
@@ -62,9 +62,9 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
return WM_ABORT_ALL;
- if (force_lower_case && ISUPPER(t_ch))
+ if ((flags & WM_CASEFOLD) && ISUPPER(t_ch))
t_ch = tolower(t_ch);
- if (force_lower_case && ISUPPER(p_ch))
+ if ((flags & WM_CASEFOLD) && ISUPPER(p_ch))
p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
@@ -98,7 +98,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
* both foo/bar and foo/a/bar.
*/
if (p[0] == '/' &&
- dowild(p + 1, text,
force_lower_case) == WM_MATCH)
+ dowild(p + 1, text, flags) ==
WM_MATCH)
return WM_MATCH;
match_slash = 1;
} else
@@ -117,7 +117,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text,
force_lower_case)) != WM_NOMATCH) {
+ if ((matched = dowild(p, text, flags)) !=
WM_NOMATCH) {
if (!match_slash || matched !=
WM_ABORT_TO_STARSTAR)
return matched;
} else if (!match_slash && t_ch == '/')
@@ -228,6 +228,5 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
int wildmatch(const char *pattern, const char *text,
unsigned int flags, struct wildopts *wo)
{
- return dowild((const uchar*)pattern, (const uchar*)text,
- flags & WM_CASEFOLD ? 1 :0);
+ return dowild((const uchar*)pattern, (const uchar*)text, flags);
}
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/10] wildmatch: rename constants and update prototype
- All exported constants now have a prefix WM_
- Do not rely on FNM_* constants, use the WM_ counterparts
- Remove TRUE and FALSE to follow Git's coding style
- While at it, turn flags type from int to unsigned int
- Add an (unused yet) argument to carry extra information
so that we don't have to change the prototype again later
when we need to pass other stuff to wildmatch
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c| 3 +-
test-wildmatch.c | 4 +--
wildmatch.c | 88 +++-
wildmatch.h | 22 +-
4 files changed, 62 insertions(+), 55 deletions(-)
diff --git a/dir.c b/dir.c
index cb7328b..175a182 100644
--- a/dir.c
+++ b/dir.c
@@ -595,7 +595,8 @@ int match_pathname(const char *pathname, int pathlen,
}
return wildmatch(pattern, name,
-ignore_case ? FNM_CASEFOLD : 0) == 0;
+ignore_case ? WM_CASEFOLD : 0,
+NULL) == 0;
}
/* Scan the list and let the last match determine the fate.
diff --git a/test-wildmatch.c b/test-wildmatch.c
index e384c8e..4bb23b4 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -12,9 +12,9 @@ int main(int argc, char **argv)
argv[i] += 3;
}
if (!strcmp(argv[1], "wildmatch"))
- return !!wildmatch(argv[3], argv[2], 0);
+ return !!wildmatch(argv[3], argv[2], 0, NULL);
else if (!strcmp(argv[1], "iwildmatch"))
- return !!wildmatch(argv[3], argv[2], FNM_CASEFOLD);
+ return !!wildmatch(argv[3], argv[2], WM_CASEFOLD, NULL);
else if (!strcmp(argv[1], "fnmatch"))
return !!fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 2d3ed84..2a655fa 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -18,9 +18,6 @@ typedef unsigned char uchar;
#define NEGATE_CLASS '!'
#define NEGATE_CLASS2 '^'
-#define FALSE 0
-#define TRUE 1
-
#define CC_EQ(class, len, litmatch) ((len) == sizeof (litmatch)-1 \
&& *(class) == *(litmatch) \
&& strncmp((char*)class, litmatch, len) ==
0)
@@ -64,7 +61,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
int matched, match_slash, negated;
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
- return ABORT_ALL;
+ return WM_ABORT_ALL;
if (force_lower_case && ISUPPER(t_ch))
t_ch = tolower(t_ch);
if (force_lower_case && ISUPPER(p_ch))
@@ -77,12 +74,12 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
/* FALLTHROUGH */
default:
if (t_ch != p_ch)
- return NOMATCH;
+ return WM_NOMATCH;
continue;
case '?':
/* Match anything but '/'. */
if (t_ch == '/')
- return NOMATCH;
+ return WM_NOMATCH;
continue;
case '*':
if (*++p == '*') {
@@ -101,135 +98,136 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
* both foo/bar and foo/a/bar.
*/
if (p[0] == '/' &&
- dowild(p + 1, text,
force_lower_case) == MATCH)
- return MATCH;
- match_slash = TRUE;
+ dowild(p + 1, text,
force_lower_case) == WM_MATCH)
+ return WM_MATCH;
+ match_slash = 1;
} else
- return ABORT_MALFORMED;
+ return WM_ABORT_MALFORMED;
} else
- match_slash = FALSE;
+ match_slash = 0;
if (*p == '\0') {
/* Trailing "**" matches everything. Trailing
"*" matches
* only if there are no more slash characters.
*/
if (!match_slash) {
if (strchr((char*)text, '/') != NULL)
- return NOMATCH;
+ return WM_NOMATCH;
}
- return MATCH;
+ return WM_MATCH;
[PATCH v3 02/10] compat/fnmatch: respect NO_FNMATCH* even on glibc
Signed-off-by: Nguyễn Thái Ngọc Duy --- compat/fnmatch/fnmatch.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c index 9473aed..6f7387d 100644 --- a/compat/fnmatch/fnmatch.c +++ b/compat/fnmatch/fnmatch.c @@ -55,7 +55,8 @@ program understand `configure --with-gnu-libc' and omit the object files, it is simpler to just do this in the source for each such file. */ -#if defined _LIBC || !defined __GNU_LIBRARY__ +#if defined NO_FNMATCH || defined NO_FNMATCH_CASEFOLD || \ +defined _LIBC || !defined __GNU_LIBRARY__ # if defined STDC_HEADERS || !defined isascii -- 1.8.0.rc2.23.g1fb49df -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/10] wildmatch: replace variable 'special' with better named ones
'special' is too generic and is used for two different purposes.
Replace it with 'match_slash' to indicate "**" pattern and 'negated'
for "[!...]" and "[^...]".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index 5f976e9..2d3ed84 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -61,7 +61,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
const uchar *pattern = p;
for ( ; (p_ch = *p) != '\0'; text++, p++) {
- int matched, special;
+ int matched, match_slash, negated;
uchar t_ch, prev_ch;
if ((t_ch = *text) == '\0' && p_ch != '*')
return ABORT_ALL;
@@ -103,15 +103,15 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
if (p[0] == '/' &&
dowild(p + 1, text,
force_lower_case) == MATCH)
return MATCH;
- special = TRUE;
+ match_slash = TRUE;
} else
return ABORT_MALFORMED;
} else
- special = FALSE;
+ match_slash = FALSE;
if (*p == '\0') {
/* Trailing "**" matches everything. Trailing
"*" matches
* only if there are no more slash characters.
*/
- if (!special) {
+ if (!match_slash) {
if (strchr((char*)text, '/') != NULL)
return NOMATCH;
}
@@ -121,9 +121,9 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
if (t_ch == '\0')
break;
if ((matched = dowild(p, text,
force_lower_case)) != NOMATCH) {
- if (!special || matched !=
ABORT_TO_STARSTAR)
+ if (!match_slash || matched !=
ABORT_TO_STARSTAR)
return matched;
- } else if (!special && t_ch == '/')
+ } else if (!match_slash && t_ch == '/')
return ABORT_TO_STARSTAR;
t_ch = *++text;
}
@@ -135,8 +135,8 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
p_ch = NEGATE_CLASS;
#endif
/* Assign literal TRUE/FALSE because of "matched"
comparison. */
- special = p_ch == NEGATE_CLASS? TRUE : FALSE;
- if (special) {
+ negated = p_ch == NEGATE_CLASS? TRUE : FALSE;
+ if (negated) {
/* Inverted character class. */
p_ch = *++p;
}
@@ -218,7 +218,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
} else if (t_ch == p_ch)
matched = TRUE;
} while (prev_ch = p_ch, (p_ch = *++p) != ']');
- if (matched == special || t_ch == '/')
+ if (matched == negated || t_ch == '/')
return NOMATCH;
continue;
}
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/10] wildmatch: fix "**" special case
"**" is adjusted to only be effective when surrounded by slashes, in
40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
the commit did it wrong:
1. when it checks for "the preceding slash unless ** is at the
beginning", it compares to wrong pointer. It should have compared
to the beginning of the pattern, not the text.
2. prev_p points to the character before "**", not the first "*". The
correct comparison must be "prev_p < pattern" or
"prev_p + 1 == pattern", not "prev_p == pattern".
3. The pattern must be surrounded by slashes unless it's at the
beginning or the end of the pattern. We do two checks: one for the
preceding slash and one the trailing slash. Both checks must be
met. The use of "||" is wrong.
This patch fixes all above.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t3070-wildmatch.sh | 2 +-
wildmatch.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index d5bafef..af54c83 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -83,7 +83,7 @@ match 0 0 'deep/foo/bar/baz/' '**/bar/*'
match 1 0 'deep/foo/bar/baz/' '**/bar/**'
match 0 0 'deep/foo/bar' '**/bar/*'
match 1 0 'deep/foo/bar/' '**/bar/**'
-match 1 0 'foo/bar/baz' '**/bar**'
+match 0 0 'foo/bar/baz' '**/bar**'
match 1 0 'foo/bar/baz/x' '*/bar/**'
match 0 0 'deep/foo/bar/baz/x' '*/bar/**'
match 1 0 'deep/foo/bar/baz/x' '**/bar/*/*'
diff --git a/wildmatch.c b/wildmatch.c
index 3972e26..5f976e9 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -58,6 +58,7 @@ typedef unsigned char uchar;
static int dowild(const uchar *p, const uchar *text, int force_lower_case)
{
uchar p_ch;
+ const uchar *pattern = p;
for ( ; (p_ch = *p) != '\0'; text++, p++) {
int matched, special;
@@ -87,7 +88,7 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
if (*++p == '*') {
const uchar *prev_p = p - 2;
while (*++p == '*') {}
- if ((prev_p == text || *prev_p == '/') ||
+ if ((prev_p < pattern || *prev_p == '/') &&
(*p == '\0' || *p == '/' ||
(p[0] == '\\' && p[1] == '/'))) {
/*
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/10] fnmatch replacement
The first patch actually belongs to nd/wildmatch as it fixes how "**" is only effective when it's surrounded by slashes. Other fixes from v2 are WM_PATHNAME check is replaced by match_slash (or "special" previously) in 8/10 and 9/10. WM_PATHNAME is only used to set match_slash. If we rely on (the lack of) WM_PATHNAME, we may miss "**" with WM_PATHNAME on. Nguyễn Thái Ngọc Duy (10): wildmatch: fix "**" special case compat/fnmatch: respect NO_FNMATCH* even on glibc wildmatch: replace variable 'special' with better named ones wildmatch: rename constants and update prototype wildmatch: make dowild() take arbitrary flags wildmatch: support "no FNM_PATHNAME" mode test-wildmatch: add "perf" command to compare wildmatch and fnmatch wildmatch: make a special case for "*/" with FNM_PATHNAME wildmatch: advance faster in + patterns Makefile: add USE_WILDMATCH to use wildmatch as fnmatch Makefile | 6 ++ compat/fnmatch/fnmatch.c | 3 +- dir.c| 3 +- git-compat-util.h| 13 t/t3070-wildmatch.sh | 45 +- test-wildmatch.c | 82 +- wildmatch.c | 150 +-- wildmatch.h | 23 +--- 8 files changed, 257 insertions(+), 68 deletions(-) -- 1.8.0.rc2.23.g1fb49df -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree error (just how do you expect me to merge 0 trees?)
Drew Crawford writes: > Ideally it would be better to emit an error-message from a script > higher up the calling chain that would be more descriptive about the > problem (such as suggesting no branch is specified).-- Ok, I used git rev-parse --verify and I have this working now. Will send to Junio in the batch with fixes from other folks. Thanks for catching this! -David -- 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 subtree error (just how do you expect me to merge 0 trees?)
Drew Crawford writes: > Ideally it would be better to emit an error-message from a script > higher up the calling chain that would be more descriptive about the > problem (such as suggesting no branch is specified).-- I'm looking at implementing this but I need a bit of help from the git experts. git-subtree add accepts either a refspec or a path to a repository and a refspec. With one positional option, git-subtree add simply assumes it's a refspec. Is there an easy way to check whether a string is a proper refspec? Even better would be a way to check if a string is a path to a git repository. -David -- 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: [DOCBUG] git subtree synopsis needs updating
Yann Dirson writes: > Ah, it's nice to see subtree updates. Any plans to get them merged anytime > soon ? As soon as there is one patch per feature that applies cleanly to contrib/ and testcases use the native git test facility. These patches should be submitted to the mailing list for review. -David -- 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 subtree error (just how do you expect me to merge 0 trees?)
Drew Crawford writes: > I noticed today that if you leave off the branch name from git subtree like > so: > > $ git subtree add --prefix somewhere -m "adding CDH as subtree" path/to/repo > warning: read-tree: emptying the index with no arguments is deprecated; use > --empty > fatal: just how do you expect me to merge 0 trees? > > The error message is not particularly helpful (and seems to actually be in > read-subtree?) The solution in my case was to add the branch name on the end > of the command. > > Ideally it would be better to emit an error-message from a script higher up > the calling chain that would be more descriptive about the problem (such as > suggesting no branch is specified).-- Good idea. I'll code it up. -David -- 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?] git-subtree behavior when the -P tree is removed and recreated
Junio C Hamano writes: > Maybe it is a seasonal thing, just before the holiday season, but > this has been unresponded for a couple of months, not even with a > "That combination is not supported", or "Thanks for a bug report". I did finally see this message. I totally admit that I've been pretty absent. It just happens that I have a ton of paid work to do and voluteer work unfortunately comes last, after family and after paid work. For this bug I honestly don't know what is supposed to happen. I'm still learning the code. It's a bit of a shell-script mess to be honest, very hard to follow. That's why it's still in contrib/ and will remain so for a while. I am more than happy for others to jump in and help out. I'm not a gatekeeper. -David -- 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?] git-subtree behavior when the -P tree is removed and recreated
Tomi Belan writes: > Thanks. Here's one more bump. Avery? David? I don't know how this is supposed to work, unfortunately. I'm still in the middle of learning the code... -David -- 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] git fetch --all --tags doesn't fetch remote branches, only tags
Dear Mr. Hamano, so i /did/ misunderstand the documentation – my fault. Thank you very much for your rapid clarification! With grateful greetings, Dennis Heidsiek -- 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] Add --unannotate option to git-subtree
James Nylen writes: > Rather than adding a marker to each commit when splitting out the > commits back to the subproject, --unannotate removes the specified > string (or bash glob pattern) from the beginning of the first line of > the commit message. This enables the following workflow: I applied the patch to my working copy but it doesn't seem to do what I'd expect. The test script does something like this: - create project A - add file to project A with message "subproj: add F1" - add file to project A with message "subproj: add F2" - add project A as a subtree of project B under directory subdir - add a file to subdir with message "subproj: add F3" - do a split --unannotate="subproj:" I expected to see a log with no mention of "subproj" anywhere. Instead I get: add F3 subproj: add F2 subproj: add F1 Is this as you intend? Is --unannotate only supposed to strip the string for commits added when A was a subtree of B? I guess this behavior makes sense in that the user would want to see the same commits that existed before A became a subproject. -David -- 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] git fetch --all --tags doesn't fetch remote branches, only tags
Dennis Heidsiek writes: > i think there may be a bug in the fetch command: The command > >> $ git fetch --all --tags >> Fetching origin > > doesn’t fetch new commits from origin/master, while i see via the > web browser of my remote repository that they exist. The "--all" option asks to fetch from all remotes, and "--tags" option asks to disable the configured fetch refspecs and instead grab only the tags. It appears that what you observed is exactly what should happen and in line with the documentation: $ git help fetch | sed -ne '/^ .*-t.*--tags/,/^$/p' -t, --tags This is a short-hand for giving "refs/tags/:refs/tags/" refspec from the command line, to ask all tags to be fetched and stored locally. Because this acts as an explicit refspec, the default refspecs (configured with the remote.$name.fetch variable) are overridden and not used. -- 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
[BUG] git fetch --all --tags doesn't fetch remote branches, only tags
Dear Git community, i think there may be a bug in the fetch command: The command $ git fetch --all --tags Fetching origin doesn’t fetch new commits from origin/master, while i see via the web browser of my remote repository that they exist. The same with verbose: $ git fetch --all --tags --verbose Fetching origin From git://repo.or.cz/wortliste = [up to date] Trennmuster-20071020 -> Trennmuster-20071020 = [up to date] Trennmuster-20071223 -> Trennmuster-20071223 = [up to date] Trennmuster-20080601 -> Trennmuster-20080601 = [up to date] dehyph-exptl-v0.1 -> dehyph-exptl-v0.1 = [up to date] dehyph-exptl-v0.11 -> dehyph-exptl-v0.11 = [up to date] dehyph-exptl-v0.12 -> dehyph-exptl-v0.12 = [up to date] dehyph-exptl-v0.12.1 -> dehyph-exptl-v0.12.1 = [up to date] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13 = [up to date] dehyph-exptl-v0.20 -> dehyph-exptl-v0.20 = [up to date] dehyph-exptl-v0.22 -> dehyph-exptl-v0.22 = [up to date] dehyph-exptl-v0.23 -> dehyph-exptl-v0.23 Only if i omit the --tags commit, fetch does what i expect: $ git fetch --all --verbose Fetching origin remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done. remote: Total 8 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (8/8), done. From git://repo.or.cz/wortliste 7c71430..176027b master -> origin/master = [up to date] Keine-Haupttrennstellen-in-zweisilbigen-Wörtern -> origin/Keine-Haupttrennstellen-in-zweisilbigen-Wörtern = [up to date] python-skripts -> origin/python-skripts I think this may be a bug; i’m using my git alias fa = fetch --all --tags --verbose quite often, and it worked in previous versions of Git. Finnally, i’m using Git 1.8.0.3 under Ubuntu 10.04.4 LTS x86_64 via this PPA: https://launchpad.net/~git-core/+archive/ppa Thank you for your time reading this and of cause a happy new year! With best greetings, Dennis Heidsiek PS: I’m no subscriber of the Git mailing list. -- 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
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address . You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits. The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.3. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on th
What's cooking in git.git (Dec 2012, #08; Mon, 31)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' branch is at 1.8.1; the tip of 'next' will be rewound soonish to reorder topics that are already well cooked during the pre-release freeze earlier than the others so that they can orderly be merged to 'master' after the dust settles, probably towards the end of this week. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * so/prompt-command (2012-12-26) 1 commit (merged to 'next' on 2012-12-26 at 27c5683) + make __git_ps1 accept a third parameter in pcmode Gives the same degree of customizability to the new prompt command mode users as the command substitution mode has. -- [New Topics] * ap/status-ignored-in-ignored-directory (2012-12-26) 1 commit - wt-status: Show ignored files in untracked dirs A topic still in flux; will be redone. * ta/remove-stale-translated-tut (2012-12-27) 1 commit - Remove Documentation/pt_BR/gittutorial.txt Remove a translation of a document that was left stale. * er/stop-recommending-parsecvs (2012-12-28) 1 commit - Remove the suggestion to use parsecvs, which is currently broken. Stop recommending a defunct third-party software. * as/test-name-alias-uniquely (2012-12-28) 1 commit - Use longer alias names in subdirectory tests A few short-and-bland aliases used in the tests were interfering with git-custom command in user's $PATH. * jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit - merge --no-edit: do not credit people involved in the side branch Stop spending cycles to compute information to be placed on commented lines in "merge --no-edit". -- [Stalled] * jc/doc-maintainer (2012-11-27) 1 commit - update "howto maintain git" An early draft that is still incomplete. * fc/remote-bzr (2012-12-13) 10 commits - (fixup) test-bzr.sh: fix multi-line string assignment - remote-bzr: detect local repositories - remote-bzr: add support for older versions of bzr - remote-bzr: add support to push special modes - remote-bzr: add support for fecthing special modes - remote-bzr: add simple tests - remote-bzr: update working tree upon pushing - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - Add new remote-bzr transport helper New remote helper for bzr (v3). With minor fixes, this may be ready for 'next'. * mo/cvs-server-updates (2012-12-09) 18 commits - t9402: Use TABs for indentation - t9402: Rename check.cvsCount and check.list - t9402: Simplify git ls-tree - t9402: Add missing &&; Code style - t9402: No space after IO-redirection - t9402: Dont use test_must_fail cvs - t9402: improve check_end_tree() and check_end_full_tree() - t9402: sed -i is not portable - cvsserver Documentation: new cvs ... -r support - cvsserver: add t9402 to test branch and tag refs - cvsserver: support -r and sticky tags for most operations - cvsserver: Add version awareness to argsfromdir - cvsserver: generalize getmeta() to recognize commit refs - cvsserver: implement req_Sticky and related utilities - cvsserver: add misc commit lookup, file meta data, and file listing functions - cvsserver: define a tag name character escape mechanism - cvsserver: cleanup extra slashes in filename arguments - cvsserver: factor out git-log parsing logic Needs review by folks interested in cvsserver. * aw/rebase-am-failure-detection (2012-10-11) 1 commit - rebase: Handle cases where format-patch fails I am unhappy a bit about the possible performance implications of having to store the output in a temporary file only for a rare case of format-patch aborting. * jk/lua-hackery (2012-10-07) 6 commits - pretty: fix up one-off format_commit_message calls - Minimum compilation fixup - Makefile: make "lua" a bit more configurable - add a "lua" pretty format - add basic lua infrastructure - pretty: make some commit-parsing helpers more public Interesting exercise. When we do this for real, we probably would want to wrap a commit to make it more like an "object" with methods like "parents", etc. * fc/remote-testgit-feature-done (2012-10-29) 1 commit - remote-testgit: properly check for errors Needs review and Ack (or Nack) from people involved in the remote helper interface for this to move forward. * rc/maint-complete-git-p4 (2012-09-24) 1 commit (merged to 'next' on 2012-10-29 at af52cef) + Teach git-completion about git p4 Comment from Pete will need to be addressed in a follow-up patch. * jc/maint-name-rev (2012-09-17) 7 commits - describe --contains: use "name-rev --algorithm=weight" - name-rev --algorithm=weight:
[ANNOUNCE] Git v1.8.1
The latest feature release Git v1.8.1 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ac8dced9c3232c0ec6a88d04600a4d0eaf2ba4e3 git-1.8.1.tar.gz a256fc56c89dc3c8d58b81a2c02dc89299f1f29b git-htmldocs-1.8.1.tar.gz a9ab9de3fa1781bb5009f5a215374dfc694feb30 git-manpages-1.8.1.tar.gz Also the following public repositories all have a copy of the v1.8.1 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.1 Release Notes Backward compatibility notes In the next major release (not *this* one), we will change the behavior of the "git push" command. When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the "simple" semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable "push.default" to change this, and "git push" will warn about the upcoming change until you set this variable in this release. "git branch --set-upstream" is deprecated and may be removed in a relatively distant future. "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments to replace it. Updates since v1.8.0 UI, Workflows & Features * Command-line completion scripts for tcsh and zsh have been added. * "git-prompt" scriptlet (in contrib/completion) can be told to paint pieces of the hints in the prompt string in colors. * Some documentation pages that used to ship only in the plain text format are now formatted in HTML as well. * We used to have a workaround for a bug in ancient "less" that causes it to exit without any output when the terminal is resized. The bug has been fixed in "less" version 406 (June 2007), and the workaround has been removed in this release. * When "git checkout" checks out a branch, it tells the user how far behind (or ahead) the new branch is relative to the remote tracking branch it builds upon. The message now also advises how to sync them up by pushing or pulling. This can be disabled with the advice.statusHints configuration variable. * "git config --get" used to diagnose presence of multiple definitions of the same variable in the same configuration file as an error, but it now applies the "last one wins" rule used by the internal configuration logic. Strictly speaking, this may be an API regression but it is expected that nobody will notice it in practice. * A new configuration variable "diff.context" can be used to give the default number of context lines in the patch output, to override the hardcoded default of 3 lines. * "git format-patch" learned the "--notes=" option to give notes for the commit after the three-dash lines in its output. * "git log -p -S" now looks for the after applying the textconv filter (if defined); earlier it inspected the contents of the blobs without filtering. * "git log --grep=" learned to honor the "grep.patterntype" configuration set to "perl". * "git replace -d " now interprets as an extended SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex object name. * "git rm $submodule" used to punt on removing a submodule working tree to avoid losing the repository embedded in it. Because recent git uses a mechanism to separate the submodule repository from the submodule working tree, "git rm" learned to detect this case and removes the submodule working tree when it is safe to do so. * "git send-email" used to prompt for the sender address, even when the committer identity is well specified (e.g. via user.name and user.email configuration variables). The command no longer gives this prompt when not necessary. * "git send-email" did not allow non-address garbage strings to appear after addresses on Cc: lines in the patch files (and when told to pick them up to find more recipients), e.g. Cc: Stable Kernel # for v3.2 and up The command now strips " # for v3.2 and up" part before adding the remainder of this line to the list of recipients. * "git submodule add" learned to add a new submodule at the same path as the path where an unrelated submodule was bound to in an existing revision via the "--name" option. * "git submodule sync" learned the "--recursive" option. * "diff.submodule" configuration variable can be used to give custom
Re: [PATCH v2 2/2] Provide better guidance for submitting patches against upstream utilities
Jason Holden writes: > git-gui, gitk, and git-po are maintained upstream of git. > Document this, and the procedure for submitting patches to these tools > > Signed-off-by: Jason Holden > --- > Documentation/SubmittingPatches | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 75935d5..30b95a8 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -58,6 +58,17 @@ Checklist (and a short version for the impatient): > please test it first by sending email to yourself. > - see below for instructions specific to your mailer > > + Improving upstream utilities (gitk, git-gui, git-po) > + - gitk, git-gui, and git-po are maintained upstream of Git > + despite being included in Git's git repository > + - Patches should be made against the upstream gui repository, GUI? > + and not against the version in Git's git repository > + - The resulting patch should still be emailed for review > + to the git mailing list (git@vger.kernel.org), cc'ing the > + applicable gui maintainer > + - Please see the MAINTAINER's file for the gui maintainer's contact GUI? Perhaps "parts with sub-maintainers' with their own repositories". In any case, I think it is probably much better not to add a new file at the top of the tree only to hold twenty-or-so lines. Instead, add the contents as a footnote to this file and refer to it from here. -- 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] gitk: Replaced "green" with "#00FF00".
On Thu, Dec 27, 2012 at 09:27:37AM -0800, Junio C Hamano wrote: > Peter Hofmann writes: > > > Subject: Re: [PATCH] gitk: Replaced "green" with "#00FF00". > > > gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now > > because it has changed from "#00FF00" to "#008000". > > Your observation "awkward" is somewhat subjective and I am hesitant > to recommend this change without a better justification. Given the > reasoning behind the change Tcl/Tk people made, I wouldn't be > surprised if people coming from webapp world view the "green" color > rendered by updated Tcl/Tk more natural. Given that "green" is used as the background color in some places, e.g. for the boxes containing the names of heads, and that the general scheme is dark foreground on light background, I agree that #008000 is too dark in those places. > Besides, if we are declaring with this patch that we will stick to > X11 colors and will not adopt W3C colors, the patch shouldn't update > only "green", but set all the other colors in stone, no? "purple", > for example, is also different between X11 and W3C. Purple is only used for octopus merges. I'd like to think of a better way to use color in representing octopus merges if possible. > > One could also use "lime" instead of "#00FF00" but that would break > > compatibility with older versions of Tk. > > A better solution might be to make these colors customizable. Indeed. Some people prefer to have all their windows to have light foregrounds on dark backgrounds, so they would also benefit from having more of the colors customizable. Paul. -- 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] Add --unannotate option to git-subtree
Herman van Rink writes: >> Has anybody looked at this? >> >> It has been very useful for me. I am looking at it now. > The version of subtree in contrib is rather out-dated unfortunately. It is the official version. What's missing? You have a bunch of changes that need rework to include into "mainline" but other than that I am not aware of any major missing pieces. If there are such changes I would very much like to get them integrated > Your patch looks interesting though. I can see how this could be useful. > I've collected a bunch of patches in > https://github.com/helmo/git/tree/subtree-updates I hope you will submit your changes for inclusion. Again, I'm not a gatekeeper but I do want the patches to have proper testcases and integrate into contrib/subtree. -David -- 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] subtree.sh: Use raw subject and body modifier "%B" instead of "%s%n%n%b"
gree...@obbligato.org writes:
> Techlive Zheng writes:
>
>> "%s%n%n%b" is not always equal to "%B". If the commit msg does not have
>> a body, this will append an extra new-line character to the msg title
>> which would cause the splited commit has a new sha1 hash. In most cases,
>> this does not matter, but for a project which did not merged using this
>> script initially, the 'split' command would not genereate the same
>> commits as the orginal which may cause conflicts.
>>
>> Signed-off-by: Techlive Zheng
>> ---
>> contrib/subtree/git-subtree.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index 920c664..5598210 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -296,7 +296,7 @@ copy_commit()
>> # We're going to set some environment vars here, so
>> # do it in a subshell to get rid of them safely later
>> debug copy_commit "{$1}" "{$2}" "{$3}"
>> -git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b'
>> "$1" |
>> +git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
>> (
>> read GIT_AUTHOR_NAME
>> read GIT_AUTHOR_EMAIL
>
> This looks good to me. I assume this passes all the tests. Can you add
> a test for this bug so we don't regress? Junio, I am good with this
> patch as soon as we get a test for the problem.
I've applied this patch to my working copy but I'm not finding that I
can recreate the original problem when the patch is disabled.
I assumed the scenario you're trying to fix is:
- Make some commit C to project A with a one-line message
- work, commit, work...
- Add project A as a subproject
- work, commit, work...
- Split project A off into a separate repository
After this, commit C with the one-line message in the split-off projet
should have the same hash it had before project A was incorporated as a
subproject.
As I understad it, you saw the post-split commit having a different
hash?
Is that right? I am not seeing that problem even without your patch.
I want to make sure I understand what the problem is so I can test for
it.
Thanks!
-David
--
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/Enhancement: contrib/subtree should ship with manpage
Neil writes: > Actual: git-subtree.1 fails to be generated because my system doesn't ship > asciidoc and xmlto. Well, you need those tools to build ANY git documentation. I just ran a test to build git-subtree and its documentation and it went just fine. This is not a bug. -Dave -- 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 1/2] Add top-level maintainers file with email/canonical repository information
One minor grammar nit below. On Mon, Dec 31, 2012 at 2:19 PM, Jason Holden wrote: > Certain parts of git have a semi-formalized workflow for > incoming patches. This file documents the maintainers, their area of > specialization, their email address, and their canonical repository against > which patches should be submitted. > > Signed-off-by: Jason Holden > --- > MAINTAINERS | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 MAINTAINERS > > diff --git a/MAINTAINERS b/MAINTAINERS > new file mode 100644 > index 000..c3a96b4 > --- /dev/null > +++ b/MAINTAINERS > @@ -0,0 +1,21 @@ > +Core Git/Overall Maintainer: > + Junio C Hamano > + git://git.kernel.org/pub/scm/git/git.git > + > + > +Certain utilities packaged with git (git-gui, gitk, and git-po) are > maintained > +upstream of the core git repository. Their contact information > +and canonical repositories are below. Patches to improve these utilities > +should be made against the tree's referenced below Should be "trees", not "tree's" (plural vs. possessive/contraction). > + > +gitk: > + Paul Mackerras > + git://ozlabs.org/~paulus/gitk > + > +git-gui: > + Pat Thoyts > + git://repo.or.cz/git-gui > + > +git-po: > + Jiang Xin > + https://github.com/git-l10n/git-po/ > -- > 1.8.1.rc3.28.g0ab5d1f > -- Jacob Helwig http://technosorcery.net/about/me -- 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: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote: > > Thanks for the patch. I have a couple of comments about it. First, > the exec command waits for the process to complete, which means that > the initial gitk GUI will be unresponsive until the user quits the > gitk window showing the merge, which could be quite confusing for the > user. Good catch. Adding an ampersand on to the exec looks like it fixes the unresponsiveness. Any issues with that approach? > > Secondly, gitk already has support for showing multiple views of a > repository, that is, different subsets of the commits. Wouldn't it be > much better to have your new menu item simply create a new view > showing the merge, rather than creating a whole new window? I've found when using this feature that I tend to use it in a stack-like fashion. I tend to want to "push" a merge-view onto the stack, investigate that view of history for a bit, then "pop" back to my old view. But you're correct that you can end up with a lot of windows pretty quick. Any support for stack-like views in the current gui that I missed? I've got another feature brewing, similiar to the merge-view, where you can right-click on a file and a new window pops up with the history of just that file. I tend to use that feature in a stack-like fashion as well. Maybe the seperate-window/new-view-in-same-window should be a new user preference? -- 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] merge --no-edit: do not add comments meant for "--edit" mode
The credit lines "By" and "Via" to credit authors and committers for
their contributions on the side branch are meant as a hint to the
integrator to decide whom to mention in the log message text. After
the integrator saves the message in the editor, they are meant to go
away and that is why they are commented out.
When a merge is recorded without editing the generated message,
however, its contents do not go through the normal stripspace()
and these lines are left in the merge.
Stop producing them when we know the merge is going to be recorded
without editing, i.e. when --no-edit is given.
Signed-off-by: Junio C Hamano
---
builtin.h | 3 ++-
builtin/fmt-merge-msg.c | 21 ++---
builtin/merge.c | 1 +
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/builtin.h b/builtin.h
index dffb34e..3ad8d19 100644
--- a/builtin.h
+++ b/builtin.h
@@ -16,7 +16,8 @@ extern const char git_more_info_string[];
extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
- unsigned add_title:1;
+ unsigned add_title:1,
+ credit_people:1;
int shortlog_len;
};
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 2c4d435..dd1f363 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -232,8 +232,9 @@ static void record_person(int which, struct string_list
*people,
{
char *name_buf, *name, *name_end;
struct string_list_item *elem;
- const char *field = (which == 'a') ? "\nauthor " : "\ncommitter ";
+ const char *field;
+ field = (which == 'a') ? "\nauthor " : "\ncommitter ";
name = strstr(commit->buffer, field);
if (!name)
return;
@@ -323,7 +324,8 @@ static void add_people_info(struct strbuf *out,
static void shortlog(const char *name,
struct origin_data *origin_data,
struct commit *head,
-struct rev_info *rev, int limit,
+struct rev_info *rev,
+struct fmt_merge_msg_opts *opts,
struct strbuf *out)
{
int i, count = 0;
@@ -335,6 +337,7 @@ static void shortlog(const char *name,
int flags = UNINTERESTING | TREESAME | SEEN | SHOWN | ADDED;
struct strbuf sb = STRBUF_INIT;
const unsigned char *sha1 = origin_data->sha1;
+ int limit = opts->shortlog_len;
branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
if (!branch || branch->type != OBJ_COMMIT)
@@ -351,13 +354,15 @@ static void shortlog(const char *name,
if (commit->parents && commit->parents->next) {
/* do not list a merge but count committer */
- record_person('c', &committers, commit);
+ if (opts->credit_people)
+ record_person('c', &committers, commit);
continue;
}
- if (!count)
+ if (!count && opts->credit_people)
/* the 'tip' committer */
record_person('c', &committers, commit);
- record_person('a', &authors, commit);
+ if (opts->credit_people)
+ record_person('a', &authors, commit);
count++;
if (subjects.nr > limit)
continue;
@@ -372,7 +377,8 @@ static void shortlog(const char *name,
string_list_append(&subjects, strbuf_detach(&sb, NULL));
}
- add_people_info(out, &authors, &committers);
+ if (opts->credit_people)
+ add_people_info(out, &authors, &committers);
if (count > limit)
strbuf_addf(out, "\n* %s: (%d commits)\n", name, count);
else
@@ -635,7 +641,7 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
for (i = 0; i < origins.nr; i++)
shortlog(origins.items[i].string,
origins.items[i].util,
-head, &rev, opts->shortlog_len, out);
+head, &rev, opts, out);
}
strbuf_complete_line(out);
@@ -690,6 +696,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const
char *prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !message;
+ opts.credit_people = 1;
opts.shortlog_len = shortlog_len;
ret = fmt_merge_msg(&input, &output, &opts);
diff --git a/builtin/merge.c b/builtin/merge.c
index e81fde6..c5d3551 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1324,6 +1324,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
memset(&opts, 0, sizeof(opts));
opts.add_title = !have_message;
opts.shortlog_len = shortlog_len;
+ opts.credit_people = (0 < option_ed
Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
Thomas Ackermann writes: >> Thanks; I just realized that nothing in Documentation/ hierarchy >> mentions these; they are only mentioned in "A Note from the >> Maintainer" I send out every once in a while (kept in MaintNotes of >> 'todo' branch): > > Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation? Perhaps. It started as a living document that discusses the state of affairs as of the time of posting (there are mentions to "the most recent such release was ...", etc), and because I wanted to keep it that way (and also I needed somewhere to keep track of it), I deliberately kept it outside the source tree. It is an addendum to howto-maintain-git, and what it covers overlaps with it, so it will need some clean-ups if we want to go the route you suggest. Having said all that, I think it is still a good idea to keep the occasional "A note from he Maintainer" posting on list, and a version that needs to rever to another document after losing overlaps with howto-maintain-git will no longer will be suitable source for it, so... -- 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 filter-branch doesn't dereference annotated tags
Grégory Pakosz writes:
> 1) either make git-filter-branch dereference annotated tags and do
> the verification itself then use the two arguments version of git
> update-ref
> 2) in the case of an annotated tag, pass another to git
> update-ref
>
> Please find below a patch that implements solution 1).
> ...
> echo "Ref '$ref' was deleted"
> - git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
> + test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git
> update-ref -m "filter-branch: delete" -d "$ref" ||
Thanks. A few comments.
At the design level. Where does this $sha1 come from in the first
place? If a ref that named the annotated tag was deleted, shouldn't
we arrange things so this part of the code receives the $sha1 of the
tag that corresponds to the $ref so that "update-ref -d" can check
that nobody tampered with the repository while the script was
working?
At the implementation level. When the ref being deleted pointed at
a tree or a blob, the original would have correctly removed it, but
will the updated one?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
On Mon, Dec 31, 2012 at 09:40:19AM +, Thomas Ackermann wrote: > Junio C Hamano pobox.com> writes: > > > > > Thanks; I just realized that nothing in Documentation/ hierarchy > > mentions these; they are only mentioned in "A Note from the > > Maintainer" I send out every once in a while (kept in MaintNotes of > > 'todo' branch): > > > > Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation? > > --- > Thomas Putting it in Documentation/ would add one more outlier file (Along w/ SubmittingPatches and CodingGuidelines). Documentation/technical seems too deep. I've got a patch that incorporates the content into the existing README, but that seems a bit out of place, as the previous content of README was primarily pointers to other docs. What about a README.developers at the toplevel? -- 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: [RFC] pack-objects: compression level for non-blobs
This thread is pretty interesting. Unfortunately the holidays have kept me busy. But I am excited by the work David and Peff are doing. :-) On Sun, Dec 30, 2012 at 1:31 PM, Jeff King wrote: > On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote: > >> > $ cd objects/pack && ls >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.commits >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.idx >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.pack >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.parents >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.timestamps >> > pack-a3e262f40d95fc0cc97d92797ff9988551367b75.trees >> > >> > Each file describes the objects in the matching pack. If a new pack is >> > generated, you'd throw away the old cache files along with the old pack, >> > and generate new ones. Or not. These are totally optional, and an older >> > version of git will just ignore them. A newer version will use them if >> > they're available, and otherwise fallback to the existing code (i.e., >> > reading the whole object from the pack). So you can generate them at >> >> You have probably thought about this (and I don't have the source to >> check first), but we may need to version these extra files so we can >> change the format later if needed. Git versions that do not recognize >> new versions simply ignore the cahce. > > Agreed. The current code has a 4-byte magic, followed by a 4-byte > version number, followed by a 4-byte record size[1]. Then the data, > followed by the pack sha1, followed by a sha1 of all of the preceding > data. So you can verify the validity of any cache file (both its > checksum, and that it matches the right packfile), just as you can with > a ".idx" file. Put the pack sha1 into the header, rather than the trailer. Its really annoying that you read the header, determine you probably understand this file, and then have to seek to END-40 to read the pack sha1 and verify it matches the pack. In an ideal world the pack sha1 would have been the file name, making this less of an issue, but someone didn't anticipate repacking the same object set with possibly different results. :-( The idx format is kind of wrong here, I wish we had put the pack sha1 into the header. Given that we mmap the files the 20 bytes in front vs. 20 bytes in the trailer wouldn't have made any difference on access cost. >> > Each file is a set of fixed-length records. The "commits" file contains >> > the sha1 of every commit in the pack (sorted). A binary search of the >> > mmap'd file gives the position of a particular commit within the list, >> >> I think we could avoid storing sha-1 in the cache with Shawn's idea >> [1]. But now I read it again I fail to see it :( >> >> [1] http://article.gmane.org/gmane.comp.version-control.git/206485 > > Right. My implementation is very similar to what Shawn said there. I.e., > the timestamps file is literally 4 bytes times the number of commits. > The parents file is 40 bytes per commit (2 parents, with a marker to > indicate "more or less than 2"), though a lot of it is zero bytes. Hmm, after re-reading [1] I still like my idea better. But I won't find the time to code it myself, so I'll have to go with whatever someone else writes. :-) Since tree pointers are also required when parsing a commit (even if they might not get used e.g. `git log master`) maybe this should be 16 bytes per commit storing the commit time, tree pointer, and 2 parents, with the last 3 fields using the N-th object in the sorted sha1 list in the idx. Sorting the file by pack stream ordering gives you good locality during rev-list operations and makes it compact if pack-objects adheres to writing commits before other objects. Unfortunately this ordering requires the pack reverse index in memory to translate from sha1 to position in the cache file. Making the reverse index is a non-trivial cost that may dominate the running time for smaller traversals, or the startup time for `git log` outputting to the pager. > Some alternatives I'm thinking about are: > > 1. Using non-fixed-size records, which would allow trivial compression > of entries like null sha1s. This would mean adding a separate > lookup table, though, mapping sha1s to offsets. Still, even a > 32-bit offset is only 4 bytes per commit. If it meant dropping 40 > bytes of zeroes from the 2nd parent field out of half of all > commits, that would be a win space-wise. It would be a > double-indirect lookup, but it's constant effort, and only two page > hits (which would be warm after the first lookup anyway). Or use a 16 byte fixed width record (see above). > 2. Storing offsets to objects in the packfile rather than their sha1s. > This would save a lot of space, but would mean we couldn't refer to > parents outside of the pack, but that may be OK. This is an > optimization, and the case we want to target is a fully (or mostly) > packed repo. I
Re: git.wiki.kernel.org spam ...
Hi Rupert, On Sat, 29 Dec 2012, rupert THURNER wrote: > ich hab gesehen, du bist ober-meister des kernle.org git wikis. da > gibt es ganz schön viel neue user und spam derzeit, zb: > https://git.wiki.kernel.org/index.php?title=User_talk:Bridgetevans0521&redirect=no > > möchtest du das erzeugen von user accounts erschweren, wie zb hier: > http://kiwix.org/index.php/Special:UserLogin?type=signup&returnto=Main_Page/en > > falls du noch leute als admin haben willst, ich melde mich freiwillig, > ThurnerRupert ist mein account. Since my trustworthiness was questioned, I have stopped completely with the maintenance of the Wiki. The mailing list (Cc:ed) may have additional comments. Ciao, Johannes
git filter-branch doesn't dereference annotated tags
Please disregard the previous email that contains an incorrect fix
suggestion. I wish my first contribution was flawless.
Here is what's happening.
git-filter-branch let git-update-ref -d verify that the value for $ref
matches $sha1.
However, when $ref points to an annotated tag that is being deleted,
that verification fails because $sha1 is the commit underneath.
I think there are two possible fixes:
1) either make git-filter-branch dereference annotated tags and do
the verification itself then use the two arguments version of git
update-ref
2) in the case of an annotated tag, pass another to git update-ref
Please find below a patch that implements solution 1). Please note the
patch doesn't contain a unit test for this situation as I wasn't sure
how to provide one. Yet I tested it on the repository I'm working on.
Gregory
>From 9d21960088a61bfbac1ffdb4b13e3038f88ab4d6 Mon Sep 17 00:00:00 2001
From: Gregory Pakosz
Date: Mon, 31 Dec 2012 15:30:36 +0100
Subject: [PATCH] git-filter-branch: support annotated tags deletion
git-filter-branch let git-update-ref -d verify that the value for $ref matches
$sha1. However, when $ref is an annotated tag being deleted that verfication
fails because $sha1 corresponds to a commit object.
Instead of asking git-update-ref to verify values actually match, dereference
$ref ourselves and test against $sha1 first. Then invoke git-update-ref with two
arguments.
Signed-off-by: Gregory Pakosz
---
git-filter-branch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..bbee6d0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ do
case "$rewritten" in
'')
echo "Ref '$ref' was deleted"
- git update-ref -m "filter-branch: delete" -d "$ref" $sha1 ||
+ test $(git rev-parse --verify "$ref^{commit}") = $sha1 && git
update-ref -m "filter-branch: delete" -d "$ref" ||
die "Could not delete $ref"
;;
$_x40)
--
1.8.0.1
0001-git-filter-branch-support-annotated-tags-deletion.patch
Description: Binary data
git filter-branch doesn't dereference annotated tags
Hello,
I noticed git-filter-branch doesn't dereference annotated tags prior
to invoking git update-ref -d.
Please find a patch attached that changes the call to git update-ref:
-git update-ref -m "filter-branch: delete" -d "$ref" $sha1
+git update-ref -m "filter-branch: delete" -d $(git rev-parse --verify
"$ref^{commit}") $sha1
Regards,
Gregory
0001-git-filter-branch-Dereference-annotated-tags-upon-de.patch
Description: Binary data
Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote: > It concerns me that git uses any locking at all, even for > refs since it has the potential to leave around stale > locks. > ... > [a previous not so great attempt to fix this] > ... I may have finally figured out a working loose ref update mechanism which I think can avoid stale locks. Unfortunately it requires atomic directory renames and universally unique identifiers (uuids). These may be no-go criteria? But I figure it is worth at least exploring this idea because of the potential benefits? The general approach is to setup a transaction and either commit or abort it. A transaction can be setup by renaming an appropriately setup directory to the "ref.lock" name. If the rename succeeds, the transaction is begun. Any actor can abort the transaction (up until it is committed) by simply deleting the "ref.lock" directory, so it is not at risk of going stale. However, once the actor who sets up the transaction commits it, deleting the "ref.lock" directory simply aids in cleaning it up for the next transaction (instead of aborting it). One important piece of the transaction is the use of uuids. The uuids provide a mechanism to tie the atomic commit pieces to the transactions and thus to prevent long sleeping process from inadvertently performing actions which could be out of date when they wake finally up. In each case, the atomic commit piece is the renaming of a file. For the create and update pieces, a file is renamed from the "ref.lock" dir to the "ref" file resulting in an update to the sha for the ref. However, in the delete case, the "ref" file is instead renamed to end up in the "ref.lock" directory resulting in a delete of the ref. This scheme does not affect the way refs are read today, To prepare for a transaction, an actor first generates a uuid (an exercise I will delay for now). Next, a tmp directory named after the uuid is generated in the parent directory for the ref to be updated, perhaps something like: ".lock_uuid". In this directory is places either a file or a directory named after the uuid, something like: ".lock_uuid/,uuid". In the case of a create or an update, the new sha is written to this file. In the case of a delete, it is a directory. Once the tmp directory is setup, the initiating actor attempts to start the transaction by renaming the tmp directory to "ref.lock". If the rename fails, the update fails. If the rename succeeds, the actor can then attempt to commit the transaction (before another actor aborts it). In the case of a create, the actor verifies that "ref" does not currently exist, and then renames the now named "ref.lock/uuid" file to "ref". On success, the ref was created. In the case of an update, the actor verifies that "ref" currently contains the old sha, and then also renames the now named "ref.lock/uuid" file to "ref". On success, the ref was updated. In the case of a delete, the actor may verify that "ref" currently contains the sha to "prune" if it needs to, and then renames the "ref" file to "ref.lock/uuid/delete". On success, the ref was deleted. Whether successful or not, the actor may now simply delete the "ref.lock" directory, clearing the way for a new transaction. Any other actor may delete this directory at any time also, likely either on conflict (if they are attempting to initiate a transaction), or after a grace period just to cleanup the FS. Any actor may also safely cleanup the tmp directories, preferably also after a grace period. One neat part about this scheme is that I believe it would be backwards compatible with the current locking mechanism since the transaction directory will simply appear to be a lock to older clients. And the old lock file should continue to lock out these newer transactions. Due to this backwards compatibility, I believe that this could be incrementally employed today without affecting very much. It could be deployed in place of any updates which only hold ref.locks to update the loose ref. So for example I think it could replace step 4a below from Michael Haggerty's description of today's loose ref pruning during ref packing: > * Pack references: ... > 4. prune_refs(): for each ref in the ref_to_prune list, > call prune_ref(): > > a. Lock the reference using lock_ref_sha1(), > verifying that the recorded SHA1 is still valid. If it > is, unlink the loose reference file then free the lock; > otherwise leave the loose reference file untouched. I think it would also therefore be able to replace the loose ref locking in Michael's new ref-packing scheme as well as the locking in Michael's new ref deletion scheme (again steps 4): > * Delete reference foo: ... > 4. Delete loose ref for "foo": > > a. Acquire the lock $GIT_DIR/refs/heads/foo.lock > > b. Unlink $GIT_DIR/refs/heads/foo if it is unchanged. > If it is changed, leave
Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
Junio C Hamano pobox.com> writes: > > Thanks; I just realized that nothing in Documentation/ hierarchy > mentions these; they are only mentioned in "A Note from the > Maintainer" I send out every once in a while (kept in MaintNotes of > 'todo' branch): > Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation? --- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Aw: Re: [PATCH 0/3] Move CodingGuidelines and SubmittingPatches to ./Documentation/technical
> > Implementation details are part of API; CG and SP are social not > technical. > This depends on your definition of "social" ;-) > > Also CG and SP are in the part of the documents that are not > installed for end-users and that is their right place. They matter > only to the people who grab our source code. > But isn't that true for all files in ./technical? CG and SP currently are in ./Documentation which contains *only* files which are installed for end-users with CG and SP the only exception ... --- 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
