* Revised git-subtree Patches
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git
Here is the set of revised patches to git-subtree. I think I've
got everything cleaned up now.
^ permalink raw reply
* [PATCH 1/7] Remove Test Number Comments
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Delete the comments indicating test numbers as it causes maintenance
headaches. t*.sh -i will help us find any broken tests.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/t/t7900-subtree.sh | 55 ------------------------------------
1 file changed, 55 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index bc2eeb0..6cf9fb9 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -60,7 +60,6 @@ last_commit_message()
git log --pretty=format:%s -1
}
-# 1
test_expect_success 'init subproj' '
test_create_repo subproj
'
@@ -68,7 +67,6 @@ test_expect_success 'init subproj' '
# To the subproject!
cd subproj
-# 2
test_expect_success 'add sub1' '
create sub1 &&
git commit -m "sub1" &&
@@ -76,14 +74,12 @@ test_expect_success 'add sub1' '
git branch -m master subproj
'
-# 3
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2" &&
git branch sub2
'
-# 4
test_expect_success 'add sub3' '
create sub3 &&
git commit -m "sub3" &&
@@ -93,7 +89,6 @@ test_expect_success 'add sub3' '
# Back to mainline
cd ..
-# 5
test_expect_success 'add main4' '
create main4 &&
git commit -m "main4" &&
@@ -101,101 +96,85 @@ test_expect_success 'add main4' '
git branch subdir
'
-# 6
test_expect_success 'fetch subproj history' '
git fetch ./subproj sub1 &&
git branch sub1 FETCH_HEAD
'
-# 7
test_expect_success 'no subtree exists in main tree' '
test_must_fail git subtree merge --prefix=subdir sub1
'
-# 8
test_expect_success 'no pull from non-existant subtree' '
test_must_fail git subtree pull --prefix=subdir ./subproj sub1
'
-# 9
test_expect_success 'check if --message works for add' '
git subtree add --prefix=subdir --message="Added subproject" sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject" &&
undo
'
-# 10
test_expect_success 'check if --message works as -m and --prefix as -P' '
git subtree add -P subdir -m "Added subproject using git subtree" sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject using git subtree" &&
undo
'
-# 11
test_expect_success 'check if --message works with squash too' '
git subtree add -P subdir -m "Added subproject with squash" --squash sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject with squash" &&
undo
'
-# 12
test_expect_success 'add subproj to mainline' '
git subtree add --prefix=subdir/ FETCH_HEAD &&
check_equal ''"$(last_commit_message)"'' "Add '"'subdir/'"' from commit '"'"'''"$(git rev-parse sub1)"'''"'"'"
'
-# 13
# this shouldn't actually do anything, since FETCH_HEAD is already a parent
test_expect_success 'merge fetched subproj' '
git merge -m "merge -s -ours" -s ours FETCH_HEAD
'
-# 14
test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
git commit -m "main-sub5"
'
-# 15
test_expect_success 'add main6' '
create main6 &&
git commit -m "main6 boring"
'
-# 16
test_expect_success 'add main-sub7' '
create subdir/main-sub7 &&
git commit -m "main-sub7"
'
-# 17
test_expect_success 'fetch new subproj history' '
git fetch ./subproj sub2 &&
git branch sub2 FETCH_HEAD
'
-# 18
test_expect_success 'check if --message works for merge' '
git subtree merge --prefix=subdir -m "Merged changes from subproject" sub2 &&
check_equal ''"$(last_commit_message)"'' "Merged changes from subproject" &&
undo
'
-# 19
test_expect_success 'check if --message for merge works with squash too' '
git subtree merge --prefix subdir -m "Merged changes from subproject using squash" --squash sub2 &&
check_equal ''"$(last_commit_message)"'' "Merged changes from subproject using squash" &&
undo
'
-# 20
test_expect_success 'merge new subproj history into subdir' '
git subtree merge --prefix=subdir FETCH_HEAD &&
git branch pre-split &&
check_equal ''"$(last_commit_message)"'' "Merge commit '"'"'"$(git rev-parse sub2)"'"'"' into mainline"
'
-# 21
test_expect_success 'Check that prefix argument is required for split' '
echo "You must provide the --prefix option." > expected &&
test_must_fail git subtree split > actual 2>&1 &&
@@ -207,7 +186,6 @@ test_expect_success 'Check that prefix argument is required for split' '
rm -f expected actual
'
-# 22
test_expect_success 'Check that the <prefix> exists for a split' '
echo "'"'"'non-existent-directory'"'"'" does not exist\; use "'"'"'git subtree add'"'"'" > expected &&
test_must_fail git subtree split --prefix=non-existent-directory > actual 2>&1 &&
@@ -219,7 +197,6 @@ test_expect_success 'Check that the <prefix> exists for a split' '
# rm -f expected actual
'
-# 23
test_expect_success 'check if --message works for split+rejoin' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
git branch spl1 "$spl1" &&
@@ -227,7 +204,6 @@ test_expect_success 'check if --message works for split+rejoin' '
undo
'
-# 24
test_expect_success 'check split with --branch' '
spl1=$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin) &&
undo &&
@@ -235,7 +211,6 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
-# 25
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 +219,10 @@ test_expect_success 'check split with --branch for an existing branch' '
check_equal ''"$(git rev-parse splitbr2)"'' "$spl1"
'
-# 26
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
test_expect_success 'check split+rejoin' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -258,7 +230,6 @@ test_expect_success 'check split+rejoin' '
check_equal ''"$(last_commit_message)"'' "Split '"'"'subdir/'"'"' into commit '"'"'"$spl1"'"'"'"
'
-# 28
test_expect_success 'add main-sub8' '
create subdir/main-sub8 &&
git commit -m "main-sub8"
@@ -267,14 +238,12 @@ test_expect_success 'add main-sub8' '
# To the subproject!
cd ./subproj
-# 29
test_expect_success 'merge split into subproj' '
git fetch .. spl1 &&
git branch spl1 FETCH_HEAD &&
git merge FETCH_HEAD
'
-# 30
test_expect_success 'add sub9' '
create sub9 &&
git commit -m "sub9"
@@ -283,19 +252,16 @@ test_expect_success 'add sub9' '
# Back to mainline
cd ..
-# 31
test_expect_success 'split for sub8' '
split2=''"$(git subtree split --annotate='"'*'"' --prefix subdir/ --rejoin)"''
git branch split2 "$split2"
'
-# 32
test_expect_success 'add main-sub10' '
create subdir/main-sub10 &&
git commit -m "main-sub10"
'
-# 33
test_expect_success 'split for sub10' '
spl3=''"$(git subtree split --annotate='"'*'"' --prefix subdir --rejoin)"'' &&
git branch spl3 "$spl3"
@@ -304,7 +270,6 @@ test_expect_success 'split for sub10' '
# To the subproject!
cd ./subproj
-# 34
test_expect_success 'merge split into subproj' '
git fetch .. spl3 &&
git branch spl3 FETCH_HEAD &&
@@ -318,13 +283,11 @@ chkms_sub=$(echo $chkms | multiline | sed 's,^,subdir/,' | fixnl)
chks="sub1 sub2 sub3 sub9"
chks_sub=$(echo $chks | multiline | sed 's,^,subdir/,' | fixnl)
-# 35
test_expect_success 'make sure exactly the right set of files ends up in the subproj' '
subfiles=''"$(git ls-files | fixnl)"'' &&
check_equal "$subfiles" "$chkms $chks"
'
-# 36
test_expect_success 'make sure the subproj history *only* contains commits that affect the subdir' '
allchanges=''"$(git log --name-only --pretty=format:'"''"' | sort | fixnl)"'' &&
check_equal "$allchanges" "$chkms $chks"
@@ -333,20 +296,17 @@ test_expect_success 'make sure the subproj history *only* contains commits that
# Back to mainline
cd ..
-# 37
test_expect_success 'pull from subproj' '
git fetch ./subproj subproj-merge-spl3 &&
git branch subproj-merge-spl3 FETCH_HEAD &&
git subtree pull --prefix=subdir ./subproj subproj-merge-spl3
'
-# 38
test_expect_success 'make sure exactly the right set of files ends up in the mainline' '
mainfiles=''"$(git ls-files | fixnl)"'' &&
check_equal "$mainfiles" "$chkm $chkms_sub $chks_sub"
'
-# 39
test_expect_success 'make sure each filename changed exactly once in the entire history' '
# main-sub?? and /subdir/main-sub?? both change, because those are the
# changes that were split into their own history. And subdir/sub?? never
@@ -355,12 +315,10 @@ test_expect_success 'make sure each filename changed exactly once in the entire
check_equal "$allchanges" ''"$(echo $chkms $chkm $chks $chkms_sub | multiline | sort | fixnl)"''
'
-# 40
test_expect_success 'make sure the --rejoin commits never make it into subproj' '
check_equal ''"$(git log --pretty=format:'"'%s'"' HEAD^2 | grep -i split)"'' ""
'
-# 41
test_expect_success 'make sure no "git subtree" tagged commits make it into subproj' '
# They are meaningless to subproj since one side of the merge refers to the mainline
check_equal ''"$(git log --pretty=format:'"'%s%n%b'"' HEAD^2 | grep "git-subtree.*:")"'' ""
@@ -370,14 +328,12 @@ test_expect_success 'make sure no "git subtree" tagged commits make it into subp
mkdir test2
cd test2
-# 42
test_expect_success 'init main' '
test_create_repo main
'
cd main
-# 43
test_expect_success 'add main1' '
create main1 &&
git commit -m "main1"
@@ -385,14 +341,12 @@ test_expect_success 'add main1' '
cd ..
-# 44
test_expect_success 'init sub' '
test_create_repo sub
'
cd sub
-# 45
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2"
@@ -402,7 +356,6 @@ cd ../main
# check if split can find proper base without --onto
-# 46
test_expect_success 'add sub as subdir in main' '
git fetch ../sub master &&
git branch sub2 FETCH_HEAD &&
@@ -411,7 +364,6 @@ test_expect_success 'add sub as subdir in main' '
cd ../sub
-# 47
test_expect_success 'add sub3' '
create sub3 &&
git commit -m "sub3"
@@ -419,20 +371,17 @@ test_expect_success 'add sub3' '
cd ../main
-# 48
test_expect_success 'merge from sub' '
git fetch ../sub master &&
git branch sub3 FETCH_HEAD &&
git subtree merge --prefix subdir sub3
'
-# 49
test_expect_success 'add main-sub4' '
create subdir/main-sub4 &&
git commit -m "main-sub4"
'
-# 50
test_expect_success 'split for main-sub4 without --onto' '
git subtree split --prefix subdir --branch mainsub4
'
@@ -442,19 +391,16 @@ test_expect_success 'split for main-sub4 without --onto' '
# have been sub3, but it was not, because its cache was not set to
# itself)
-# 51
test_expect_success 'check that the commit parent is sub3' '
check_equal ''"$(git log --pretty=format:%P -1 mainsub4)"'' ''"$(git rev-parse sub3)"''
'
-# 52
test_expect_success 'add main-sub5' '
mkdir subdir2 &&
create subdir2/main-sub5 &&
git commit -m "main-sub5"
'
-# 53
test_expect_success 'split for main-sub5 without --onto' '
# also test that we still can split out an entirely new subtree
# if the parent of the first commit in the tree is not empty,
@@ -487,7 +433,6 @@ joincommits()
echo "$commit $all"
}
-# 54
test_expect_success 'verify one file change per commit' '
x= &&
list=''"$(git log --pretty=format:'"'commit: %H'"' | joincommits)"'' &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Techlive Zheng, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: Techlive Zheng <techlivezheng@gmail.com>
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 6 +++++-
contrib/subtree/t/t7900-subtree.sh | 15 +++++++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..5341b36 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -296,7 +296,11 @@ 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" |
+ # 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%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 6cf9fb9..3f17f55 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -74,6 +74,10 @@ test_expect_success 'add sub1' '
git branch -m master subproj
'
+# Save this hash for testing later.
+
+subdir_hash=`git rev-parse HEAD`
+
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2" &&
@@ -211,6 +215,17 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
+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"
+'
+
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 &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/7] contrib/subtree: Better Error Handling for add
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
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 <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index cac0680..d53eaee 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -508,12 +508,18 @@ cmd_add()
ensure_clean
if [ $# -eq 1 ]; then
- "cmd_add_commit" "$@"
+ git rev-parse -q --verify "$1^{commit}" >/dev/null ||
+ die "'$1' does not refer to a commit"
+
+ "cmd_add_commit" "$@"
elif [ $# -eq 2 ]; then
- "cmd_add_repository" "$@"
+ git rev-parse -q --verify "$2^{commit}" >/dev/null ||
+ die "'$2' does not refer to a commit"
+
+ "cmd_add_repository" "$@"
else
say "error: parameters were '$@'"
- die "Provide either a refspec or a repository and refspec."
+ die "Provide either a commit or a repository and commit."
fi
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/7] contrib/subtree: Make the Manual Directory if Needed
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Jesper L. Nielsen, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "Jesper L. Nielsen" <lyager@gmail.com>
Before install git-subtree documentation, make sure the manpage
directory exists.
Signed-off-by: Jesper L. Nielsen <lyager@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 36ae3e4..b507505 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)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/7] contrib/subtree: Fix Synopsis
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Fix the documentation of add to show that a repository can be
specified along with a commit.
Suggested by Yann Dirson <dirson@bertin.fr>.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 6 ++++++
contrib/subtree/git-subtree.txt | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index d53eaee..0e9ea0f 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -9,6 +9,7 @@ if [ $# -eq 0 ]; then
fi
OPTS_SPEC="\
git subtree add --prefix=<prefix> <commit>
+git subtree add --prefix=<prefix> <repository> <commit>
git subtree merge --prefix=<prefix> <commit>
git subtree pull --prefix=<prefix> <repository> <refspec...>
git subtree push --prefix=<prefix> <repository> <refspec...>
@@ -513,6 +514,11 @@ cmd_add()
"cmd_add_commit" "$@"
elif [ $# -eq 2 ]; then
+ # Technically we could accept a refspec here but we're
+ # just going to turn around and add FETCH_HEAD under the
+ # specified directory. Allowing a refspec might be
+ # misleading because we won't do anything with any other
+ # branches fetched via the refspec.
git rev-parse -q --verify "$2^{commit}" >/dev/null ||
die "'$2' does not refer to a commit"
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 75aa690..078d4ac 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 <prefix> <commit>
+'git subtree' add -P <prefix> <refspec>
+'git subtree' add -P <prefix> <repository> <refspec>
'git subtree' pull -P <prefix> <repository> <refspec...>
'git subtree' push -P <prefix> <repository> <refspec...>
'git subtree' merge -P <prefix> <commit>
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/7] contrib/subtree: Honor DESTDIR
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Adam Tkac, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: Adam Tkac <atkac@redhat.com>
Teach git-subtree's Makefile to honor DESTDIR.
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
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
^ permalink raw reply related
* [PATCH 3/7] contrib/subtree: Add --unannotate
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: James Nylen, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: James Nylen <jnylen@gmail.com>
Teach git-subtree about --unannotate. This option strips a prefix
from a commit message when doing a subtree split.
Signed-off-by: James Nylen <jnylen@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 11 +++++++++--
contrib/subtree/git-subtree.txt | 15 +++++++++++++++
contrib/subtree/t/t7900-subtree.sh | 12 ++++++++++--
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 5341b36..cac0680 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 ;;
@@ -314,8 +318,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 c5bce41..75aa690 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=<annotation>::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+ <annotation> 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 <annotation>
+ whenever you split, or you may run into problems.
+
-b <branch>::
--branch=<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 3f17f55..de45e34 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -143,7 +143,7 @@ test_expect_success 'merge fetched subproj' '
test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
- git commit -m "main-sub5"
+ git commit -m "subproj: main-sub5"
'
test_expect_success 'add main6' '
@@ -153,7 +153,7 @@ test_expect_success 'add main6' '
test_expect_success 'add main-sub7' '
create subdir/main-sub7 &&
- git commit -m "main-sub7"
+ git commit -m "subproj: main-sub7"
'
test_expect_success 'fetch new subproj history' '
@@ -226,6 +226,14 @@ test_expect_success 'check hash of split' '
check_equal ''"$new_hash"'' "$subdir_hash"
'
+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)"'' ""
+'
+
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 &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH] fetch,upload-pack: make --depth=0 or --depth=inf for infinite depth
From: Nguyễn Thái Ngọc Duy @ 2013-01-08 12:19 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
The user can do fetch --depth=2147483647 for infinite depth now. But
it's hard to remember. Any other large numbers would also do if it's
longer than the longest commit chain in repository (some guessing may
be involved). Make --depth=0 or --depth=inf an alias for
--depth=2147483647. JGit and older C Git store depth as "int" so both
are OK with this number. Dulwich does not support shallow clone.
fetch-pack is not changed because it's a plumbing and the plumber is
expected to write this number explicitly.
Make upload-pack recognize this special number as infinite depth. The
effect is essentially the same as before, except that upload-pack is
more efficient in this case as it does not have to traverse the commit
DAG to the bottom any more. The chance of a user actually wanting
exactly 2147483647 commits depth, not infinite, is probably too small
to consider.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This is a patch from the graveyard, the third patch of a series [1].
The series, nd/clone-depth-zero, has been merged. Although I don't know
only the first patch in the original series got in.
http://thread.gmane.org/gmane.comp.version-control.git/154267/focus=154268
Documentation/fetch-options.txt | 2 ++
Documentation/technical/shallow.txt | 3 +++
commit.h | 3 +++
t/t5500-fetch-pack.sh | 8 ++++++++
transport.c | 5 +++++
upload-pack.c | 13 ++++++++++---
6 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 6e98bdf..140d0cd 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -12,6 +12,8 @@
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
to the specified number of commits from the tip of each remote
branch history. Tags for the deepened commits are not fetched.
+ Depth 0 or "inf" is infinite, which may turn repository to a
+ non-shallow one again.
ifndef::git-pull[]
--dry-run::
diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt
index 0502a54..ea2f69f 100644
--- a/Documentation/technical/shallow.txt
+++ b/Documentation/technical/shallow.txt
@@ -53,3 +53,6 @@ It also writes an appropriate $GIT_DIR/shallow.
You can deepen a shallow repository with "git-fetch --depth 20
repo branch", which will fetch branch from repo, but stop at depth
20, updating $GIT_DIR/shallow.
+
+The special depth 2147483647 (or 0x7fffffff, the largest positive
+number a signed 32-bit integer can contain) means infinite depth.
diff --git a/commit.h b/commit.h
index 0f469e5..fbde106 100644
--- a/commit.h
+++ b/commit.h
@@ -162,6 +162,9 @@ extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *r
extern struct commit_list *get_merge_bases_many(struct commit *one, int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
+/* largest postive number a signed 32-bit integer can contain */
+#define INFINITE_DEPTH 0x7fffffff
+
extern int register_shallow(const unsigned char *sha1);
extern int unregister_shallow(const unsigned char *sha1);
extern int for_each_commit_graft(each_commit_graft_fn, void *);
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 6322e8a..2d40073 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -264,6 +264,14 @@ test_expect_success 'clone shallow object count' '
grep "^count: 52" count.shallow
'
+test_expect_success 'infinite deepening (full repo)' '
+ (
+ cd shallow &&
+ git fetch --depth=inf &&
+ ! test -f .git/shallow
+ )
+'
+
test_expect_success 'clone shallow without --no-single-branch' '
git clone --depth 1 "file://$(pwd)/." shallow2
'
diff --git a/transport.c b/transport.c
index 2673d27..a938ba0 100644
--- a/transport.c
+++ b/transport.c
@@ -12,6 +12,7 @@
#include "url.h"
#include "submodule.h"
#include "string-list.h"
+#include "commit.h"
/* rsync support */
@@ -475,11 +476,15 @@ static int set_git_option(struct git_transport_options *opts,
} else if (!strcmp(name, TRANS_OPT_DEPTH)) {
if (!value)
opts->depth = 0;
+ else if (!strcmp(value, "inf"))
+ opts->depth = INFINITE_DEPTH;
else {
char *end;
opts->depth = strtol(value, &end, 0);
if (*end)
die("transport: invalid depth option '%s'", value);
+ if (opts->depth == 0)
+ opts->depth = INFINITE_DEPTH;
}
return 0;
}
diff --git a/upload-pack.c b/upload-pack.c
index 6142421..88f0029 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -670,10 +670,17 @@ static void receive_needs(void)
if (depth == 0 && shallows.nr == 0)
return;
if (depth > 0) {
- struct commit_list *result, *backup;
+ struct commit_list *result = NULL, *backup = NULL;
int i;
- backup = result = get_shallow_commits(&want_obj, depth,
- SHALLOW, NOT_SHALLOW);
+ if (depth == INFINITE_DEPTH)
+ for (i = 0; i < shallows.nr; i++) {
+ struct object *object = shallows.objects[i].item;
+ object->flags |= NOT_SHALLOW;
+ }
+ else
+ backup = result =
+ get_shallow_commits(&want_obj, depth,
+ SHALLOW, NOT_SHALLOW);
while (result) {
struct object *object = &result->item->object;
if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Understanding When to Use Branches
From: gw1500 @ 2013-01-08 13:46 UTC (permalink / raw)
To: git@vger.kernel.org
As a git noobie I am beginning get get my head around git's version
control philosophy. I am now trying to understand the purposes of
branches or rather when to use them. In my case I have a Java
application under version control with git. I am planning to port it
into a mobile app. Is that an appropriate use of branches or should it
be created as a new repository? What is the relationship between the
same source code in different branches? Do changes to code in one branch
get ported to another branch somehow or do all changes then have to be
made twice? The documentation tells how to branch but not the general
philosophy behind it from a best practices standpoint. Thanks in advance
for any insight.
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Duy Nguyen @ 2013-01-08 14:16 UTC (permalink / raw)
To: Jonathan Nieder, Jens Lehmann
Cc: git, Junio C Hamano, Heiko Voigt, Manlio Perillo, W. Trevor King
In-Reply-To: <20130106101948.GD10956@elie.Belkin>
On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
> Unfortunately we forgot to forbid the --bare
> --separate-git-dir combination. In practice, we know no one
> could be using --bare with --separate-git-dir because it is
> broken in the following way: <explanation here>. So it is
> safe to make good on our mistake and forbid the combination,
> making the command easier to explain.
>
> I don't know what would go in the <explanation here> blank above,
> though. Is it possible that some people are relying on this option
> combination?
I can't say it's broken in what way. Maybe it's easier to just support
this case, it's not much work anyway. Jens, maybe squash this to your
original patch?
-- 8< --
diff --git a/builtin/clone.c b/builtin/clone.c
index 8d23a62..c8b09ad 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -375,6 +375,7 @@ static void clone_local(const char *src_repo, const char *dest_repo)
static const char *junk_work_tree;
static const char *junk_git_dir;
+static const char *junk_git_file;
static pid_t junk_pid;
static void remove_junk(void)
@@ -392,6 +393,8 @@ static void remove_junk(void)
remove_dir_recursively(&sb, 0);
strbuf_reset(&sb);
}
+ if (junk_git_file)
+ unlink(junk_git_file);
}
static void remove_junk_on_signal(int signo)
@@ -772,6 +775,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
set_git_dir_init(git_dir, real_git_dir, 0);
if (real_git_dir) {
+ if (option_bare)
+ junk_git_file = git_dir;
git_dir = real_git_dir;
junk_git_dir = real_git_dir;
}
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
index 4435693..231bc8a 100755
--- a/t/t5600-clone-fail-cleanup.sh
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -49,4 +49,14 @@ test_expect_success 'failed clone --separate-git-dir should not leave any direct
rmdir foo/.git/objects.bak
'
+test_expect_success 'failed clone --separate-git-dir --bare should not leave any directories' '
+ mkdir foo/.git/objects.bak/ &&
+ mv foo/.git/objects/* foo/.git/objects.bak/ &&
+ test_must_fail git clone --bare --separate-git-dir gitdir foo baaar &&
+ test_must_fail test -e gitdir &&
+ test_must_fail test -e baaar &&
+ mv foo/.git/objects.bak/* foo/.git/objects/ &&
+ rmdir foo/.git/objects.bak
+'
+
test_done
-- 8< --
^ permalink raw reply related
* Re: [PATCH] git clone depth of 0 not possible.
From: Duy Nguyen @ 2013-01-08 14:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Stefan Beller, schlotter, Ralf.Wildenhues, git
In-Reply-To: <7vd2xggm8a.fsf@alter.siamese.dyndns.org>
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Speaking of --depth, I think in Git 2.0 we should fix the semantics
> of "deepening" done with "git fetch".
Speaking of 2.0, we should support depth per ref. Well we don't have
to wait until 2.0 because we could just add shallow2 extension to the
pack protocol. We should also apply depth to new refs when fetching
them the first time.
--
Duy
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 14:32 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <50EA7269.1080006@web.de>
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]
On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote:
> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
> > (just cc-ing Jens and Peter, who might be interested)
>
> I´m currently working on teaching mv to move submodules and intend
> to send those patches to the list after finishing submodule deinit.
> Please see
> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
> for the current state of this series.
Thinking about this a bit more, I'm not clear on how out-of-tree
updates (i.e. worktree in .git/modules/*/config) propogated during
branch checkouts (merges, rebases, etc.). I just got a broken rebase
trying to move a trivial patch back before the submodule move, and Git
was confused about what had happened to the submodules. Here's a
simple script that illustrates the problem:
#!/bin/sh
rm -rf a b c
mkdir a
(cd a
git init
echo a > README
git add README
git commit -am 'a'
)
git clone a b
(cd b
git submodule add ../a submod-1
git commit -am 'add submodule at submod-1'
)
git clone b c
(cd c
git submodule update --init
)
(cd b
git-submodule-mv.sh submod-1 submod-2
git commit -am 'move submodule from submod-1 to submod-2'
)
(cd c
git pull
ls -d .git/modules/*
cat .git/modules/submod-1/config
ls -a submod*
)
The end result is that `c` gets the `.gitmodules` path updates and new
gitlinked directory from the submodule move in `b` (using my
git-submodule-mv.sh posted earlier in this thread), but `submod-1` is
left lying around (because Git doesn't know that it can remove
submod-1/.git and submod-1/README). The Git directory for the
submodule stays in .git/modules/submod-1/ (good), but the worktree in
.git/modules/submod-1/config still points to ../../../submod-1 (bad).
This means that submodule moves are possible, but anyone trying to
share them between several repositories (or trying to rebase across
the move within their own repository) is in for a world of suffering
;). I'm not sure how this should be addressed, but I didn't see
anything handling it in Jens' new series.
Thanks,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Stefan Beller @ 2013-01-08 14:32 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <CACsJy8BJ3eBv-wjq=eTzR4SeEXW2MF5k1w5SFRt7fWRU4vKb_Q@mail.gmail.com>
On 01/08/2013 03:28 PM, Duy Nguyen wrote:
> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>> of "deepening" done with "git fetch".
>
> Speaking of 2.0, we should support depth per ref. Well we don't have
> to wait until 2.0 because we could just add shallow2 extension to the
> pack protocol. We should also apply depth to new refs when fetching
> them the first time.
>
Would this mean I could do something along?
$ git clone --since v1.8.0 git://github.com/gitster/git.git
So tags would be allowed as anchors?
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Duy Nguyen @ 2013-01-08 14:45 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EC2DE5.2050704@googlemail.com>
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller
<stefanbeller@googlemail.com> wrote:
> On 01/08/2013 03:28 PM, Duy Nguyen wrote:
>> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>>> of "deepening" done with "git fetch".
>>
>> Speaking of 2.0, we should support depth per ref. Well we don't have
>> to wait until 2.0 because we could just add shallow2 extension to the
>> pack protocol. We should also apply depth to new refs when fetching
>> them the first time.
>>
>
> Would this mean I could do something along?
> $ git clone --since v1.8.0 git://github.com/gitster/git.git
>
> So tags would be allowed as anchors?
No. This is what I had in mind:
git clone --branch=master --depth=2 git.git # get branch master with depth 2
git fetch --depth=10 origin next # get branch next with depth 10
# master's depth remains 2
git fetch origin # get (new) branch 'pu' with default depth 2
But your case is interesting. We could specify --depth=v1.8.0.. or
even --depth=v1.8.0~200.. (200 commits before v1.8.0). Somebody may
even go crazy and make --depth=v1.6.0..v1.8.0 work. --depth is
probably not the right name anymore. Any SHA-1 would be allowed as
anchor. But I think we need to wait for reachability bitmap feature to
come first so that we can quickly verify the anchor is reachable from
the public refs.
--
Duy
^ permalink raw reply
* [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: W. Trevor King @ 2013-01-08 15:47 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20121128202320.GA22522@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Signed-off-by: W. Trevor King <wking@tremily.us>
---
I was looking for one of my older messages to the Git list, and I
found this, which seems to have fallen through the cracks:
On Wed, Nov 28, 2012 at 03:23:20PM -0500, W. Trevor King wrote:
> I'm not sure if this is the most recent patch iteration for this
> feature, but I just saw this typo in `pu`.
>
> On Sun, Nov 04, 2012 at 03:13:29AM +0100, Felipe Contreras wrote:
> > +# Commits are modified to preserve hg information and allow biridectionality.
> ^^^^^^^^
> s/biridectionality/bidirectionality/
This fixes that instance (which has since landed in master) and
another similar typo.
contrib/remote-helpers/git-remote-hg | 2 +-
contrib/remote-helpers/test-hg-bidi.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 016cdad..c700600 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -31,7 +31,7 @@ import urllib
# hg:
# Emulate hg-git.
# Only hg bookmarks are exported as git branches.
-# Commits are modified to preserve hg information and allow biridectionality.
+# Commits are modified to preserve hg information and allow bidirectionality.
#
NAME_RE = re.compile('^([^<>]+)')
diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
index a94eb28..1d61982 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -6,7 +6,7 @@
# https://bitbucket.org/durin42/hg-git/src
#
-test_description='Test biridectionality of remote-hg'
+test_description='Test bidirectionality of remote-hg'
. ./test-lib.sh
--
1.8.1.151.g32238ae
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 15:59 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <20121023220955.GA30442@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
On Tue, Jan 08, 2013 at 09:32:14AM -0500, W. Trevor King wrote:
> Thinking about this a bit more, I'm not clear on how out-of-tree
> updates (i.e. worktree in .git/modules/*/config) propogated during
> branch checkouts (merges, rebases, etc.).
Actually, I don't understand why storing `worktree` in
.git/modules/*/config is useful at all…. This may be related to my
lack of clarity on the "why can't we have multiple working directories
checked out at the same time" issue:
On Tue, Oct 23, 2012 at 06:09:55PM -0400, W. Trevor King wrote:
> On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote:
> > Am 22.10.2012 14:37, schrieb W. Trevor King:
> > > but cloning a remote repository (vs. checking out a local branch)
> > > seems to be baked into the submodule implementation. Should I be
> > > thinking about generalizing git-submodule.sh, or am I looking under
> > > the wrong rock? My ideal syntax would be something like
> > >
> > > $ git submodule add -b c --local dir-for-c/
> >
> > But then we'd have to be able to have two (or more) work trees using
> > the same git directory, which current submodule code can't.
>
> And that's the problem I'm trying to solve ;).
Can someone with a better feeling for why this won't work. Is is just
that there's only one `.git/HEAD`?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-01-08 16:11 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: git
In-Reply-To: <50D870A0.90205@interlinx.bc.ca>
On 12/24/2012 10:11 AM, Brian J. Murrell wrote:
> Have you tried adding a "-q" to the git command line to quiet down git's
> "feedback" messages?
>
Ok, I have modified my crontab to use "-q" and I will wait to see if the
problem occurs from now.
> I discovered other oddities with using git on Lustre which I described
> in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/208886
>
> I found that by simply disabling the feedback (which disables the
> copious SIGALRM processing) I could alleviate the issue.
>
> I wonder if your issues are more of the same.
>
> I filed Lustre bug LU-2276 about it at:
>
> http://jira.whamcloud.com/browse/LU-2276
Thank you for these informations. I see the bug is unresolved!...
Eric
^ permalink raw reply
* Re: [PATCH] wincred: improve compatibility with windows versions
From: Karsten Blees @ 2013-01-08 16:20 UTC (permalink / raw)
To: kusmabite; +Cc: git, msysgit, Jeff King
In-Reply-To: <CABPQNSYcOrOZJd0vK=4ESC4qPpcj7RRdhVt3R0dAE-ouhOb5YA@mail.gmail.com>
Am 04.01.2013 22:57, schrieb Erik Faye-Lund:
> On Fri, Jan 4, 2013 at 9:28 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>> On WinXP, the windows credential helper doesn't work at all (due to missing
>> Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used
>> by wincred is incompatible with native Windows tools (such as the control
>> panel applet or 'cmdkey.exe /generic'). These Windows tools only set the
>> TargetName, UserName and CredentialBlob members of the CREDENTIAL
>> structure (where CredentialBlob is the UTF-16-encoded password).
>>
>> Remove the unnecessary packing / unpacking of the password, along with the
>> related API definitions, for compatibility with Windows XP.
>>
>> Don't use CREDENTIAL_ATTRIBUTEs to identify credentials for compatibility
>> with Windows credential manager tools. Parse the protocol, username, host
>> and path fields from the credential's target name instead.
>>
>> While we're at it, optionally accept CRLF (instead of LF only) to simplify
>> debugging in bash / cmd.
>>
>> Signed-off-by: Karsten Blees <blees@dcon.de>
>> ---
>>
>> Hi,
>>
>> I tried the windows credential helper yesterday and found that it doesn't work on XP at all, and doesn't work properly in combination with Win7 credential manager tools. So here's a patch that reduces it to the functionality provided / expected by Windows.
>>
>> @Erik, Jeff: Please let me know if I'm missing something and the use of Cred[Un]PackAuthenticationBuffer or CREDENTIAL_ATTRIBUTEs actually served a useful purpose.
>>
>
> The only reason why I used Cred[Un]PackAuthenticationBuffer, were that
> I wasn't aware that it was possible any other way. I didn't even know
> there was a Windows Credential Manager in Windows XP.
>
I believe the Cred* API was introduced in Win2k. The XP control panel applet supports domain credentials only, but cmdkey.exe from Windows Server 2003 can be used on XP to manage generic credentials.
> The credential attributes were because they were convenient, and I'm
> not sure I understand what you mean about the Win7 credential manager
> tools. I did test my code with it - in fact, it was a very useful tool
> for debugging the helper.
>
> Are you referring to the credentials not *looking* like normal
> HTTP-credentials?
No, I was referring to creating / editing git credentials with Windows tools manually. For example, changing your password in control panel removes all credential attributes, so the current wincred won't find them any longer...same for git credentials created e.g. via 'cmdkey /generic:git:http://me@example.com /user:me /pass:secret'.
The 'puzzling' part is that those credentials *look* exactly the same as if created by wincred, but they don't work. And wincred isn't exactly verbose in its error messages :-)
> But, if we do any of these changes, does this mean I will lose my
> existing credentials? It's probably not a big deal, but it's worth a
> mention, isn't it?
>
Yes, existing stored credentials are lost after this patch. Will add a note to the commit message.
We _could_ try to detect the old format, but I don't think it's worth the trouble.
>> @@ -67,20 +61,14 @@ typedef struct _CREDENTIALW {
>> #define CRED_MAX_ATTRIBUTES 64
>>
>> typedef BOOL (WINAPI *CredWriteWT)(PCREDENTIALW, DWORD);
>> -typedef BOOL (WINAPI *CredUnPackAuthenticationBufferWT)(DWORD, PVOID, DWORD,
>> - LPWSTR, DWORD *, LPWSTR, DWORD *, LPWSTR, DWORD *);
>> typedef BOOL (WINAPI *CredEnumerateWT)(LPCWSTR, DWORD, DWORD *,
>> PCREDENTIALW **);
>> -typedef BOOL (WINAPI *CredPackAuthenticationBufferWT)(DWORD, LPWSTR, LPWSTR,
>> - PBYTE, DWORD *);
>> typedef VOID (WINAPI *CredFreeT)(PVOID);
>> typedef BOOL (WINAPI *CredDeleteWT)(LPCWSTR, DWORD, DWORD);
>>
>> static HMODULE advapi, credui;
>
> Perhaps get rid of credui also?
>
Good catch
>> static CredWriteWT CredWriteW;
>> -static CredUnPackAuthenticationBufferWT CredUnPackAuthenticationBufferW;
>> static CredEnumerateWT CredEnumerateW;
>> -static CredPackAuthenticationBufferWT CredPackAuthenticationBufferW;
>> static CredFreeT CredFree;
>> static CredDeleteWT CredDeleteW;
>>
>> @@ -88,74 +76,64 @@ static void load_cred_funcs(void)
>> {
>> /* load DLLs */
>> advapi = LoadLibrary("advapi32.dll");
>> - credui = LoadLibrary("credui.dll");
>> - if (!advapi || !credui)
>> + if (!advapi)
>> die("failed to load DLLs");
>
> It's not multiple DLLs any more, so perhaps "failed to load
> advapi32.dll" instead?
>
Certainly
>> -static char target_buf[1024];
>> -static char *protocol, *host, *path, *username;
>> -static WCHAR *wusername, *password, *target;
>> +static WCHAR *wusername, *password, *protocol, *host, *path, target[1024];
>>
>> -static void write_item(const char *what, WCHAR *wbuf)
>> +static void write_item(const char *what, LPCWSTR wbuf, int wlen)
>> {
>> char *buf;
>> - int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, NULL, 0, NULL,
>> + int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, NULL, 0, NULL,
>> FALSE);
>> buf = xmalloc(len);
>>
>> - if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, buf, len, NULL, FALSE))
>> + if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, buf, len, NULL, FALSE))
>> die("WideCharToMultiByte failed!");
>>
>> printf("%s=", what);
>> - fwrite(buf, 1, len - 1, stdout);
>> + fwrite(buf, 1, len, stdout);
>> putchar('\n');
>> free(buf);
>> }
>>
>
> When the password-blob is simply UTF-16 encoded, are the
> zero-termination not included? That's the reason for this change,
> right?
>
Yes, the Windows tools store the password without trailing \0.
>> -static int match_attr(const CREDENTIALW *cred, const WCHAR *keyword,
>> - const char *want)
>> +static int match_part(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
>> {
>> - int i;
>> - if (!want)
>> - return 1;
>> -
>> - for (i = 0; i < cred->AttributeCount; ++i)
>> - if (!wcscmp(cred->Attributes[i].Keyword, keyword))
>> - return !strcmp((const char *)cred->Attributes[i].Value,
>> - want);
>> -
>> - return 0; /* not found */
>> + LPCWSTR start = *ptarget;
>> + LPCWSTR end = *delim ? wcsstr(start, delim) : start + wcslen(start);
>> + int len = end ? end - start : wcslen(start);
>> + /* update ptarget if we either found a delimiter or need a match */
>> + if (end || want)
>> + *ptarget = end ? end + wcslen(delim) : start + len;
>> + return !want || (!wcsncmp(want, start, len) && !want[len]);
>> }
>>
>
> I'm a bit tired now, but I'm having a hard time reading this code.
> Right now it seems it's a bit too ternary-expression heavy for my
> taste, though.
>
OK, I'll flesh that out a bit. Perhaps a few more comments wouldn't hurt either.
>> static int match_cred(const CREDENTIALW *cred)
>> {
>> - return (!wusername || !wcscmp(wusername, cred->UserName)) &&
>> - match_attr(cred, L"git_protocol", protocol) &&
>> - match_attr(cred, L"git_host", host) &&
>> - match_attr(cred, L"git_path", path);
>> + LPCWSTR target = cred->TargetName;
>> + if (wusername && wcscmp(wusername, cred->UserName))
>> + return 0;
>> +
>> + return match_part(&target, L"git", L":") &&
>> + match_part(&target, protocol, L"://") &&
>> + match_part(&target, wusername, L"@") &&
>> + match_part(&target, host, L"/") &&
>> + match_part(&target, path, L"");
>> }
>>
>
> Ugh, it feels a bit wrong to store and verify the username twice. Do
> we really have to?
>
> The target needs to be unique, even if two different usernames are
> stored for the same site under the same conditions. So probably. It
> just doesn't feel quite right.
>
I don't really see why you would need several usernames to connect to the same target. I can imagine different credentials for reading / writing, but then the protocol would usually be different as well, wouldn't it? (e.g. http vs. ssh)
One of my interim solutions was to remove the username part from the URL entirely. That enabled me to change credentials in control panel (including the username), and wincred would use them. However, that version failed the 'helper can store multiple users' test, so I ended up with storing / checking username twice.
>> @@ -165,44 +143,15 @@ static void get_credential(void)
>> /* search for the first credential that matches username */
>> for (i = 0; i < num_creds; ++i)
>> if (match_cred(creds[i])) {
>> - cred = creds[i];
>> + write_item("username", creds[i]->UserName,
>> + wcslen(creds[i]->UserName));
>> + write_item("password",
>> + (LPCWSTR)creds[i]->CredentialBlob,
>> + creds[i]->CredentialBlobSize / sizeof(WCHAR));
>> break;
>> }
>> - if (!cred)
>> - return;
>> -
>> - CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
>> - cred->CredentialBlobSize, NULL, &user_buf_size, NULL, NULL,
>> - NULL, &pass_buf_size);
>> -
>> - user_buf = xmalloc(user_buf_size * sizeof(WCHAR));
>> - pass_buf = xmalloc(pass_buf_size * sizeof(WCHAR));
>> -
>> - if (!CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
>> - cred->CredentialBlobSize, user_buf, &user_buf_size, NULL, NULL,
>> - pass_buf, &pass_buf_size))
>> - die("CredUnPackAuthenticationBuffer failed");
>>
>> CredFree(creds);
>> -
>> - /* zero-terminate (sizes include zero-termination) */
>> - user_buf[user_buf_size - 1] = L'\0';
>> - pass_buf[pass_buf_size - 1] = L'\0';
>> -
>> - write_item("username", user_buf);
>> - write_item("password", pass_buf);
>> -
>> - free(user_buf);
>> - free(pass_buf);
>> -}
>
> Nice!
>
>> -
>> -static void write_attr(CREDENTIAL_ATTRIBUTEW *attr, const WCHAR *keyword,
>> - const char *value)
>> -{
>> - attr->Keyword = (LPWSTR)keyword;
>> - attr->Flags = 0;
>> - attr->ValueSize = strlen(value) + 1; /* store zero-termination */
>> - attr->Value = (LPBYTE)value;
>> }
>>
>> static void store_credential(void)
>> @@ -215,40 +164,18 @@ static void store_credential(void)
>> if (!wusername || !password)
>> return;
>>
>> - /* query buffer size */
>> - CredPackAuthenticationBufferW(0, wusername, password,
>> - NULL, &auth_buf_size);
>> -
>> - auth_buf = xmalloc(auth_buf_size);
>> -
>> - if (!CredPackAuthenticationBufferW(0, wusername, password,
>> - auth_buf, &auth_buf_size))
>> - die("CredPackAuthenticationBuffer failed");
>> -
>> cred.Flags = 0;
>> cred.Type = CRED_TYPE_GENERIC;
>> cred.TargetName = target;
>> cred.Comment = L"saved by git-credential-wincred";
>> - cred.CredentialBlobSize = auth_buf_size;
>> - cred.CredentialBlob = auth_buf;
>> + cred.CredentialBlobSize = (wcslen(password)) * sizeof(WCHAR);
>> + cred.CredentialBlob = (LPVOID)password;
>> cred.Persist = CRED_PERSIST_LOCAL_MACHINE;
>> - cred.AttributeCount = 1;
>> - cred.Attributes = attrs;
>> + cred.AttributeCount = 0;
>> + cred.Attributes = NULL;
>> cred.TargetAlias = NULL;
>> cred.UserName = wusername;
>>
>> - write_attr(attrs, L"git_protocol", protocol);
>> -
>> - if (host) {
>> - write_attr(attrs + cred.AttributeCount, L"git_host", host);
>> - cred.AttributeCount++;
>> - }
>> -
>> - if (path) {
>> - write_attr(attrs + cred.AttributeCount, L"git_path", path);
>> - cred.AttributeCount++;
>> - }
>> -
>> if (!CredWriteW(&cred, 0))
>> die("CredWrite failed");
>> }
>
> Nice.
>
>> @@ -284,10 +211,13 @@ static void read_credential(void)
>>
>> while (fgets(buf, sizeof(buf), stdin)) {
>> char *v;
>> + int len = strlen(buf);
>> + /* strip trailing CR / LF */
>> + while (len && strchr("\r\n", buf[len - 1]))
>> + buf[--len] = 0;
>>
>> - if (!strcmp(buf, "\n"))
>> + if (!*buf)
>> break;
>> - buf[strlen(buf)-1] = '\0';
>>
>> v = strchr(buf, '=');
>> if (!v)
>
> I think this part deserves a separate patch, no?
>
Sigh...I thought I could get away without doing a patch series :-)
>> @@ -295,13 +225,12 @@ static void read_credential(void)
>> *v++ = '\0';
>>
>> if (!strcmp(buf, "protocol"))
>> - protocol = xstrdup(v);
>> + protocol = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "host"))
>> - host = xstrdup(v);
>> + host = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "path"))
>> - path = xstrdup(v);
>> + path = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "username")) {
>> - username = xstrdup(v);
>> wusername = utf8_to_utf16_dup(v);
>> } else if (!strcmp(buf, "password"))
>> password = utf8_to_utf16_dup(v);
>
> So, you need the strings as UTF-16 instead so you can match against them...
>
Exactly
>> @@ -330,22 +259,20 @@ int main(int argc, char *argv[])
>> return 0;
>>
>> /* prepare 'target', the unique key for the credential */
>> - strncat(target_buf, "git:", sizeof(target_buf));
>> - strncat(target_buf, protocol, sizeof(target_buf));
>> - strncat(target_buf, "://", sizeof(target_buf));
>> - if (username) {
>> - strncat(target_buf, username, sizeof(target_buf));
>> - strncat(target_buf, "@", sizeof(target_buf));
>> + wcscpy(target, L"git:");
>> + wcsncat(target, protocol, ARRAY_SIZE(target));
>> + wcsncat(target, L"://", ARRAY_SIZE(target));
>> + if (wusername) {
>> + wcsncat(target, wusername, ARRAY_SIZE(target));
>> + wcsncat(target, L"@", ARRAY_SIZE(target));
>> }
>> if (host)
>> - strncat(target_buf, host, sizeof(target_buf));
>> + wcsncat(target, host, ARRAY_SIZE(target));
>> if (path) {
>> - strncat(target_buf, "/", sizeof(target_buf));
>> - strncat(target_buf, path, sizeof(target_buf));
>> + wcsncat(target, L"/", ARRAY_SIZE(target));
>> + wcsncat(target, path, ARRAY_SIZE(target));
>> }
>>
>> - target = utf8_to_utf16_dup(target_buf);
>> -
>
> ...Which means that you are composing a UTF-16 target directly rather
> than ASCII. Looks sane.
>
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* git push --recurse-submodules=on-demand with submodule push tag
From: 乙酸鋰 @ 2013-01-08 16:35 UTC (permalink / raw)
To: git
Hi,
In superproject, can I call git push --recurse-submodules=on-demand
that pushes submodule with the submodule's tags?
Very often I change version and tag the submodule
and change version and tag the superproject at the same time.
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Jens Lehmann @ 2013-01-08 17:12 UTC (permalink / raw)
To: W. Trevor King; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <20130108143214.GA3755@odin.tremily.us>
Am 08.01.2013 15:32, schrieb W. Trevor King:
> On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote:
>> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
>>> (just cc-ing Jens and Peter, who might be interested)
>>
>> I´m currently working on teaching mv to move submodules and intend
>> to send those patches to the list after finishing submodule deinit.
>> Please see
>> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
>> for the current state of this series.
>
> Thinking about this a bit more, I'm not clear on how out-of-tree
> updates (i.e. worktree in .git/modules/*/config) propogated during
> branch checkouts (merges, rebases, etc.). I just got a broken rebase
> trying to move a trivial patch back before the submodule move, and Git
> was confused about what had happened to the submodules. Here's a
> simple script that illustrates the problem:
>
> #!/bin/sh
> rm -rf a b c
> mkdir a
> (cd a
> git init
> echo a > README
> git add README
> git commit -am 'a'
> )
> git clone a b
> (cd b
> git submodule add ../a submod-1
> git commit -am 'add submodule at submod-1'
> )
> git clone b c
> (cd c
> git submodule update --init
> )
> (cd b
> git-submodule-mv.sh submod-1 submod-2
> git commit -am 'move submodule from submod-1 to submod-2'
> )
> (cd c
> git pull
> ls -d .git/modules/*
> cat .git/modules/submod-1/config
> ls -a submod*
> )
>
> The end result is that `c` gets the `.gitmodules` path updates and new
> gitlinked directory from the submodule move in `b` (using my
> git-submodule-mv.sh posted earlier in this thread), but `submod-1` is
> left lying around (because Git doesn't know that it can remove
> submod-1/.git and submod-1/README).
That's just what current git does with removed submodules (but my
recursive submodule update series will handle that just fine).
> The Git directory for the
> submodule stays in .git/modules/submod-1/ (good), but the worktree in
> .git/modules/submod-1/config still points to ../../../submod-1 (bad).
You'll not only have to update the gitfile but also the core.worktree
setting in the repo. Sorry I missed that when you posted your script.
> This means that submodule moves are possible, but anyone trying to
> share them between several repositories (or trying to rebase across
> the move within their own repository) is in for a world of suffering
> ;). I'm not sure how this should be addressed, but I didn't see
> anything handling it in Jens' new series.
If you adjust core.worktree properly you'll just have the old
submodule work tree lying around (just like you do after you rm'd
it) and everything apart from that should just work.
As I mentioned that will be fixed by recursive submodule checkout.
I'll see if I can polish my preliminary branch so that interested
people can play around with it if anyone is interested.
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Jens Lehmann @ 2013-01-08 17:15 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jonathan Nieder, git, Junio C Hamano, Heiko Voigt, Manlio Perillo,
W. Trevor King
In-Reply-To: <20130108141650.GA18637@lanh>
Am 08.01.2013 15:16, schrieb Duy Nguyen:
> On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
>> Unfortunately we forgot to forbid the --bare
>> --separate-git-dir combination. In practice, we know no one
>> could be using --bare with --separate-git-dir because it is
>> broken in the following way: <explanation here>. So it is
>> safe to make good on our mistake and forbid the combination,
>> making the command easier to explain.
>>
>> I don't know what would go in the <explanation here> blank above,
>> though. Is it possible that some people are relying on this option
>> combination?
>
> I can't say it's broken in what way. Maybe it's easier to just support
> this case, it's not much work anyway. Jens, maybe squash this to your
> original patch?
I'd be fine with that, though my gut feeling is that this should
be a patch of its own (My patch handles the git dir, your's handles
a work tree issue). But I don't care much either way, what do others
think?
> -- 8< --
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 8d23a62..c8b09ad 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -375,6 +375,7 @@ static void clone_local(const char *src_repo, const char *dest_repo)
>
> static const char *junk_work_tree;
> static const char *junk_git_dir;
> +static const char *junk_git_file;
> static pid_t junk_pid;
>
> static void remove_junk(void)
> @@ -392,6 +393,8 @@ static void remove_junk(void)
> remove_dir_recursively(&sb, 0);
> strbuf_reset(&sb);
> }
> + if (junk_git_file)
> + unlink(junk_git_file);
> }
>
> static void remove_junk_on_signal(int signo)
> @@ -772,6 +775,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> set_git_dir_init(git_dir, real_git_dir, 0);
> if (real_git_dir) {
> + if (option_bare)
> + junk_git_file = git_dir;
> git_dir = real_git_dir;
> junk_git_dir = real_git_dir;
> }
> diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
> index 4435693..231bc8a 100755
> --- a/t/t5600-clone-fail-cleanup.sh
> +++ b/t/t5600-clone-fail-cleanup.sh
> @@ -49,4 +49,14 @@ test_expect_success 'failed clone --separate-git-dir should not leave any direct
> rmdir foo/.git/objects.bak
> '
>
> +test_expect_success 'failed clone --separate-git-dir --bare should not leave any directories' '
> + mkdir foo/.git/objects.bak/ &&
> + mv foo/.git/objects/* foo/.git/objects.bak/ &&
> + test_must_fail git clone --bare --separate-git-dir gitdir foo baaar &&
> + test_must_fail test -e gitdir &&
> + test_must_fail test -e baaar &&
> + mv foo/.git/objects.bak/* foo/.git/objects/ &&
> + rmdir foo/.git/objects.bak
> +'
> +
> test_done
> -- 8< --
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Understanding When to Use Branches
From: Konstantin Khomoutov @ 2013-01-08 17:08 UTC (permalink / raw)
To: gw1500; +Cc: git@vger.kernel.org
In-Reply-To: <50EC232D.90009@yahoo.com>
On Tue, 08 Jan 2013 08:46:21 -0500
gw1500 <wtriker.ffe@gmail.com> wrote:
> As a git noobie I am beginning get get my head around git's version
> control philosophy. I am now trying to understand the purposes of
> branches or rather when to use them. In my case I have a Java
> application under version control with git. I am planning to port it
> into a mobile app. Is that an appropriate use of branches or should it
> be created as a new repository? What is the relationship between the
> same source code in different branches? Do changes to code in one
> branch get ported to another branch somehow or do all changes then
> have to be made twice? The documentation tells how to branch but not
> the general philosophy behind it from a best practices standpoint.
> Thanks in advance for any insight.
Supposedly you should start with the chapter on branching in
The Book [1] and then read two classic blog posts [2, 3] describing two
different branching models. The branching models described there are
not the only two possible models to use with Git, but they are different
enough to give you a good overview of possibilities.
Note that mere googling for "git branching model" would yield a fair
number of blog posts on people's pet branching models; these two
documents just appear to be more "classic" than others.
If you have difficulty to even grasping the concept of branches and [1]
feeld hard to digest, try first reading "The Git Parable" [4] which, I
think, is the friendliest possible introduction to the basics of DVCS,
branching included.
1. http://git-scm.com/book/en/Git-Branching
2. http://nvie.com/posts/a-successful-git-branching-model/
3. http://scottchacon.com/2011/08/31/github-flow.html
4. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Junio C Hamano @ 2013-01-08 17:24 UTC (permalink / raw)
To: Stefan Beller
Cc: Duy Nguyen, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EC2DE5.2050704@googlemail.com>
Stefan Beller <stefanbeller@googlemail.com> writes:
> On 01/08/2013 03:28 PM, Duy Nguyen wrote:
>> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>>> of "deepening" done with "git fetch".
>>
>> Speaking of 2.0, we should support depth per ref. Well we don't have
>> to wait until 2.0 because we could just add shallow2 extension to the
>> pack protocol. We should also apply depth to new refs when fetching
>> them the first time.
>
> Would this mean I could do something along?
> $ git clone --since v1.8.0 git://github.com/gitster/git.git
>
> So tags would be allowed as anchors?
As the end-user facing UI, I think it would be much easier to use
for users who want to get only the recent part of history that is
relevant to their development if you allowed them to ask "starting
from this one, I do not care anything older than that" with such an
interface. The current "count how many more generations you want"
interface is crazy in that it forces you to count what you have not
even seen; I suspect the only reason it was done in such a hacky
manner was implementation expediency.
At the syntax level, however, I do not think we can use --since
there, because the keyword has a very different meaning already.
I personally do not think "depth per ref" deserves "it would be nice
to support in 2.0", let alone "2.0 *should* support", label. Some
may find it an interesting mental exercise to think about corner
cases it will introduce and have to deal with (e.g. you ask 100 from
master and 2 from maint, but maint is behind master by less than
100---what should happen?), but I do not particularly see any
practical use cases, and I highly doubt that there is much value in
bringing in extra complexity such a "feature" requires to do it
right.
^ permalink raw reply
* Re: [PATCH] upload-pack: only accept commits from "shallow" line
From: Junio C Hamano @ 2013-01-08 17:27 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1357644756-18205-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We only allow cuts at commits, not arbitrary objects. upload-pack will
> fail eventually in register_shallow if a non-commit is given with a
> generic error "Object %s is a %s, not a commit". Check it early and
> give a more accurate error.
>
> This should never show up in an ordinary session. It's for buggy
> clients, or when the user manually edits .git/shallow.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks. I agree with you that while this is not wrong per-se, this
will not matter in real life.
> upload-pack.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/upload-pack.c b/upload-pack.c
> index 6142421..95d8313 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -603,6 +603,8 @@ static void receive_needs(void)
> object = parse_object(sha1);
> if (!object)
> die("did not find object for %s", line);
> + if (object->type != OBJ_COMMIT)
> + die("invalid shallow object %s", sha1_to_hex(sha1));
> object->flags |= CLIENT_SHALLOW;
> add_object_array(object, NULL, &shallows);
> continue;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox