Re: [PATCH] git clone depth of 0 not possible.
Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano gits...@pobox.com wrote: Sounds buggy. Would anything break if we were to make --depth=1 mean 1 deep, including the tip commit? As long as we do not change the meaning of the shallow count going over the wire (i.e. the number we receive from the user will be fudged, so that user's depth 1 that used to mean the tip and one behind it is expressed as depth 2 at the end-user level, and we send over the wire the number that corresponded to the old depth 1), I do not think anything will break, and then --depth=0 may magically start meaning only the tip; its immediate parents will not be transferred and recorded as the shallow boundary in the receiving repository. I'd rather we reserve 0 for unlimited fetch, something we haven't done so far [1]. And because unlimited clone with --depth does not make sense, --depth=0 should be rejected by git-clone. I actually was thinking about changing --depth=1 to mean the tip, with zero commits behind it (and that was consistent with my description of fudging), but ended up saying --depth=0 by mistake. I too think --depth=0 or --depth0 does not make sense, so we are in agreement. Thanks for a sanity check. -- 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 warning for depth=0 in git clone.
Hi,
I am struggling a little with the development process,
is a sign-off strictly required for git as it is for kernel development?
If so here would be my sign-off:
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
This adds a warning and the previous patch adds the documentation.
However I agree to Junio, that the meaning should actually
depth=0 - just the tip and no (0) other commits before.
depth=n - the tip and n other commits before.
On 01/08/2013 09:07 AM, Stefan Beller wrote:
---
builtin/clone.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index ec2f75b..5e91c1e 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -818,6 +818,9 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
remote = remote_get(option_origin);
transport = transport_get(remote, remote-url[0]);
+ if (option_depth transport-smart_options-depth 1)
+ die(_(--depth less or equal 0 makes no sense; read manpage.));
+
if (!is_local) {
if (!transport-get_refs_list || !transport-fetch)
die(_(Don't know how to clone %s), transport-url);
--
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 warning for depth=0 in git clone.
Stefan Beller wrote: I am struggling a little with the development process, is a sign-off strictly required for git as it is for kernel development? Yes. Documentation/SubmittingPatches has more hints. Signed-off-by: Stefan Beller stefanbel...@googlemail.com This adds a warning and the previous patch adds the documentation. Thanks for your work on this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git clone depth of 0 not possible.
Junio C Hamano gits...@pobox.com writes: I think we need a protocol update to fix this; instead of sending Now I want your tips and N commits behind it, please update my shallow bottom accordingly, which creates the above by giving you Z and 3 generations back and updates your cut-off point to W, the receiving end should be able to ask I have a shallow history that cuts off at these commits. I want to get the history leading up to your tips, and also deepen the history further back from my current cut-off points by N commits, so that you would instead end up with something like this: (you) o---o---o---A---B---C---D---E---F---...---W---X---Y---Z That is, truly deepen my history by 3. We could call that git fetch --deepen=3 or something. I take that back. If you start from (upstream) ---o---o---o---A---B (you) A---B and you are interested in peeking the history a bit deeper, you should be able to ask I have a shallow history that cuts off at these commits. I want my history deepened by N commits. I do not care where your current tips are, by the way. with git fetch --deepen=3 and end up with (you) o---o---o---A---B without getting the new history leading to the updated tip at the upstream. If you want the new history leading to the updated tip, you can just say: git fetch without any --depth nor --deepen option to end up with: (you) A---B---C---D---E---F---...---W---X---Y---Z instead. -- 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
Junio C Hamano gits...@pobox.com writes: The question was about the lossage of the blank line, which does not seem to be related to what this patch wants to do. Ah, missed that. -# 25 +#25 Why the lossage of a SP? I think this got fixed later in the series. That is not a good excuse to introduce breakages in the first place, no? Oh, I agree. I wasn't making excuses. :) It may make sense to lose these # num that will have to be touched every time somebody inserts new test pieces in the middle, as a preparatory step before any of these patches, by the way. That will reduce noise in the patches for real changes. Yeah, I know, but it makes it really easy to find a test when something goes wrong. That is what t-*.sh -i is for, isn't it? Oh, I didn't know about that! -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 2/8] Add --unannotate
Junio C Hamano gits...@pobox.com writes: gree...@obbligato.org writes: In the meantime, will you apply the patch or do you prefer a new design? The --unannotate option will become a baggage you will have to keep working until the end of time, if we applied it. I think it is not too uch a baggage, so it probably is OK. Ok. I think it's worth applying since people find it useful. It's not very complicated. -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] upload-pack: only accept commits from shallow line
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 pclo...@gmail.com --- 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; -- 1.8.0.rc0.19.g7bbb31d -- 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
Revised git-subtree Patches
Here is the set of revised patches to git-subtree. I think I've got everything cleaned up now. -- 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 1/7] Remove Test Number Comments
From: David A. Greene gree...@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 gree...@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 21 @@ -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 21 @@ -219,7 +197,6 @@ test_expect_success 'Check that the prefix exists for a split' ' #rm -f expected actual '
[PATCH 3/7] contrib/subtree: Add --unannotate
From: James Nylen jny...@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 jny...@gmail.com
Signed-off-by: David A. Greene gree...@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
--
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
[PATCH 5/7] contrib/subtree: Fix Synopsis
From: David A. Greene gree...@obbligato.org
Fix the documentation of add to show that a repository can be
specified along with a commit.
Suggested by Yann Dirson dir...@bertin.fr.
Signed-off-by: David A. Greene gree...@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
--
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/7] contrib/subtree: Make the Manual Directory if Needed
From: Jesper L. Nielsen lya...@gmail.com Before install git-subtree documentation, make sure the manpage directory exists. Signed-off-by: Jesper L. Nielsen lya...@gmail.com Signed-off-by: David A. Greene gree...@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 -- 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/7] contrib/subtree: Honor DESTDIR
From: Adam Tkac at...@redhat.com Teach git-subtree's Makefile to honor DESTDIR. Signed-off-by: Adam Tkac at...@redhat.com Signed-off-by: David A. Greene gree...@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 -- 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] fetch,upload-pack: make --depth=0 or --depth=inf for infinite depth
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 pclo...@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 0x7fff, 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 0x7fff
+
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
Understanding When to Use Branches
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. -- 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] clone: forbid --bare --separate-git-dir dir
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 --
--
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 clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano gits...@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 -- 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: Moving (renaming) submodules, recipe/script
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 signature.asc Description: OpenPGP digital signature
Re: [PATCH] git clone depth of 0 not possible.
On 01/08/2013 03:28 PM, Duy Nguyen wrote: On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano gits...@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? -- 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 clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller stefanbel...@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 gits...@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 -- 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] remote-hg: Fix biridectionality - bidirectionality typos
Signed-off-by: W. Trevor King wk...@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
signature.asc
Description: OpenPGP digital signature
Re: Moving (renaming) submodules, recipe/script
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 signature.asc Description: OpenPGP digital signature
Re: GIT get corrupted on lustre
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 -- 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] wincred: improve compatibility with windows versions
Am 04.01.2013 22:57, schrieb Erik Faye-Lund:
On Fri, Jan 4, 2013 at 9:28 PM, Karsten Blees karsten.bl...@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 bl...@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://m...@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
git push --recurse-submodules=on-demand with submodule push tag
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. -- 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
Invitation to use Google Talk
--- You've been invited by Sahil Mittal to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-b92f427051-793d4f02e1-Nt7jcnrXzIehJM3I3KZwb4sRS9c To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/a-b92f427051-793d4f02e1-Nt7jcnrXzIehJM3I3KZwb4sRS9c?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team -- 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: Moving (renaming) submodules, recipe/script
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. -- 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] clone: forbid --bare --separate-git-dir dir
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Understanding When to Use Branches
On Tue, 08 Jan 2013 08:46:21 -0500 gw1500 wtriker@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 -- 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] upload-pack: only accept commits from shallow line
Nguyễn Thái Ngọc Duy pclo...@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 pclo...@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; -- 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] remote-hg: Fix biridectionality - bidirectionality typos
W. Trevor King wk...@tremily.us writes:
Signed-off-by: W. Trevor King wk...@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:
Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
multipart but send patches in plain text?
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
--
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] clone: forbid --bare --separate-git-dir dir
Jens Lehmann jens.lehm...@web.de writes: 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). I agree that these are totally unrelated issues. After all, Jonathan's suggestion to forbid it was because the combination does not make sense and does not have practical uses, and forbidding it would make the command easier to explain than leaving it accepted from the command line. If you choose to go in the opposite direction and make clone --bare --separate-git-dir do something useful, it should be explained very well in the documentation part of the patch why such a combination is a good idea, and in what situation the behaviour is useful and the user may want to consider using it, I think. -- 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: Moving (renaming) submodules, recipe/script
On Tue, Jan 08, 2013 at 06:12:13PM +0100, Jens Lehmann wrote: Am 08.01.2013 15:32, schrieb W. Trevor King: 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. My git-submodule-mv.sh script does update core.worktree. The problem is that `git checkout`, `git merge`, etc. do not. 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. Sounds like a fix will be in here. I'll definitely help put the branch through its paces ;). 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH v4] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/01/2013 21:23, Marc Khouzam ha scritto: [...] 4- Completion choices include their entire path, which is not what bash does by default. For example: cd git/contrib ls completion/git-tab git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh but git rm completion/git-tab completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh notice the extra 'completion/' before each completion. This can get pretty large when completing with many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am not sure if it can be fixed for bash. I personally don't think this is regression, just an slight annoyance. After some searching, I found how this is supposed to be done. It is possible to use the -o filenames option to tell Bash completion that the compspec generates filenames, so it can perform any filename-specific processing. Unfortunately this option must be passed to the complete builtin command, and we can not do this, since the comspec not always contains filenames. [...] Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDsXUEACgkQscQJ24LbaURMlgCdEyeSRTRktKtGuDxq4HX1meWt IV4AmwS6wasCip+1u4vS2FwG8AlXXB7r =pN8F -END PGP SIGNATURE- -- 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] remote-hg: Fix biridectionality - bidirectionality typos
W. Trevor King wk...@tremily.us writes: On Tue, Jan 08, 2013 at 09:32:07AM -0800, Junio C Hamano wrote: Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP multipart but send patches in plain text? Gah. I need to tell myself to reread that every time I send a patch :p. No need to worry; thanks for a patch---applied to 'maint'. -- 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 v4] git-completion.bash: add support for path completion
On Tue, Jan 08, 2013 at 06:54:09PM +0100, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/01/2013 21:23, Marc Khouzam ha scritto: [...] 4- Completion choices include their entire path, which is not what bash does by default. For example: cd git/contrib ls completion/git-tab git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh but git rm completion/git-tab completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh notice the extra 'completion/' before each completion. This can get pretty large when completing with many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am not sure if it can be fixed for bash. I personally don't think this is regression, just an slight annoyance. After some searching, I found how this is supposed to be done. It is possible to use the -o filenames option to tell Bash completion that the compspec generates filenames, so it can perform any filename-specific processing. Unfortunately this option must be passed to the complete builtin command, and we can not do this, since the comspec not always contains filenames. You should also be able to pass it to 'compopt' during completion in order to change the behaviour for only the current completion. John -- 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 v4] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 08/01/2013 19:05, John Keeping ha scritto: [...] After some searching, I found how this is supposed to be done. It is possible to use the -o filenames option to tell Bash completion that the compspec generates filenames, so it can perform any filename-specific processing. Unfortunately this option must be passed to the complete builtin command, and we can not do this, since the comspec not always contains filenames. You should also be able to pass it to 'compopt' during completion in order to change the behaviour for only the current completion. Thanks, compopt is what I wanted. I was reading an old Bash manual (for Bash 3.1), and compopt is only available starting from Bash 4.0. I will do some test, being careful to not break the code for Bash 4.0 and the other supported shells. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDsZVgACgkQscQJ24LbaUQlAACdGbhOuGICCYFwkRTPJla+3JGT EcQAoINEGvdwtOz1QFbAA4FqoI3c7VSa =5Oqw -END PGP SIGNATURE- -- 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: submodule name and path
On Wed, Jan 09, 2013 at 02:17:42AM +0800, 乙酸鋰 wrote: In doc, submodule name is not clearly mentioned? What is the purpose of submodule name? Must be same as submodule path? submodule path can be repeated, while submodule name unique? The submodule name starts out the same as the submodule path, but the name stays constant through submodule moves, replacements, etc. The constant name is useful because out-of-tree configuration (e.g. stuff in .git/config and .git/modules/) won't have to adjust to submodule renames (except for core.worktree in .git/modules/*/config). See: http://article.gmane.org/gmane.comp.version-control.git/49621 http://article.gmane.org/gmane.comp.version-control.git/206659 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
David A. Greene gree...@obbligato.org writes:
From: Techlive Zheng techlivezh...@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 techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
This time (only), I'll try to fix them up at my end, but please
check your toolchain, find out where the extra blank line between
S-o-b: lines we see above come from, and fix that, so that I won't
have to do so again.
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 |
The new format template is fine, but I do not think the comment
should be there. It does not give any useful information to people
who are reading the end result of applying this patch and is useful
only in the context of comparing the old and new templates, iow, it
belongs to the commit log message.
(
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
We'd need to clean up these no-op '' from this, but not doing so in
this patch is perfectly fine (and is even preferred).
+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
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
troublesome branch name in remote repo causes .git/config inconsistency in cloned repo
Hi, I think I came across a bug. I use git version 1.7.10.4 on Ubuntu 12.10. I haven't tried to find out if it's a known bug. Reproduction scenario: 1. create a git repo: $ mkdir -p tmp/bezdek $ cd tmp/bezdek/ $ echo *.swp .gitignore $ git init $ git add . $ git commit -m Initial commit 2. clone the remote repo: $ cd ../.. $ mkdir -p tmp/cloned $ git clone ../bezdek/ 3. create the troublesome branch in the remote repo $ cd ../bezdek $ git checkout -b MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek $ echo *.bak .gitignore $ git add . $ git commit -m Some changes 4. pull and checkout to the MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek branch in the cloned repo $ cd ../cloned/bezdek $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = /home/pospispa/tmp/tmp/cloned/../bezdek/ [branch master] remote = origin merge = refs/heads/master $ git pull remote: Counting objects: 5, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 33% (1/3) Unpacking objects: 66% (2/3) Unpacking objects: 100% (3/3) Unpacking objects: 100% (3/3), done. From /home/pospispa/tmp/tmp/cloned/../bezdek * [new branch] MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek - origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek Already up-to-date. $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = /home/pospispa/tmp/tmp/cloned/../bezdek/ [branch master] remote = origin merge = refs/heads/master $ git checkout MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek fatal: bad config file line 12 in .git/config $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = /home/pospispa/tmp/tmp/cloned/../bezdek/ [branch master] remote = origin merge = refs/heads/master [branch MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek] remote = origin I think that the problem may be with the branch name length. I think that git branch allows to created branches with very long names, however, such long name are not allowed in .git/config or the git checkout very-long-remote-branch-name has some problems with it. I recovered from this problem in this way: 1. deleted last two lines in tmp/cloned/bezdek/.git/config file and deleted index and working tree $ git reset HEAD * $ git checkout -- * 2. renamed the troublesome branch in remote repo: $ cd ../../bezdek $ git branch -m MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek 3. pull from remote to cloned again $ cd ../cloned/bezdek $ git pull From /home/pospispa/tmp/tmp/cloned/../bezdek * [new branch] MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek - origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek Already up-to-date. $ git branch -r origin/HEAD - origin/master origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek origin/master $ git checkout MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek Branch MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek set up to track remote branch MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek from origin. Switched to a new branch 'MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek' Best regards, Pavel Pospisil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] contrib/subtree: Add --unannotate
David A. Greene gree...@obbligato.org writes: 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. I think this paragraph inherits existing breakage from the beginning of time, but I do not think the above will format the second and subsequent paragraphs correctly. I've applied all seven patches in the series with minor fix-ups, and will merge it to 'pu'. 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 4/7] contrib/subtree: Better Error Handling for add
David A. Greene gree...@obbligato.org writes:
From: David A. Greene gree...@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 gree...@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
Where do these uneven indentation come from? Is it mimicking
existing breakage in the script?
+
+ 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
}
--
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: [RFH] NetBSD 6?
Junio C Hamano gits...@pobox.com writes: [OLD_ICONV] It refers to the type of the second parameter to iconv(); OLD_ICONV makes it take const char *, as opposed to char *, the latter of which matches http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html I just wanted to follow up on this. It turns out that the old POSIX standard was buggy (header file and function spec were different), and they resolved it in favor of non-const. NetBSD followed the const way, and just now documented that with links to the standards email archives. Interestingly, GNU iconv 1.14 seems to define it as const also: https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html (which matches man/iconv.3 in the tarball). When I build libiconv-1.14, it produces a .h with const. But it has a configure test to check if there is a host include file with const, and puts the const in the built header file or not to match! In include/iconv.h.in, there is: extern size_t iconv (iconv_t cd, @ICONV_CONST@ char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); Someday, it would be nice to have the configure test not fail an iconv implementation just because of the const, unless the presence of const is causing a real problem. But I can understand that no one thinks that's important enough to get around to. pgpP2BDPxvhEM.pgp Description: PGP signature
Re: [RFH] NetBSD 6?
Greg Troxel g...@ir.bbn.com writes: Junio C Hamano gits...@pobox.com writes: [OLD_ICONV] It refers to the type of the second parameter to iconv(); OLD_ICONV makes it take const char *, as opposed to char *, the latter of which matches http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html I just wanted to follow up on this. It turns out that the old POSIX standard was buggy (header file and function spec were different), and they resolved it in favor of non-const. NetBSD followed the const way, and just now documented that with links to the standards email archives. Interestingly, GNU iconv 1.14 seems to define it as const also: https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html (which matches man/iconv.3 in the tarball). When I build libiconv-1.14, it produces a .h with const. But it has a configure test to check if there is a host include file with const, and puts the const in the built header file or not to match! In include/iconv.h.in, there is: extern size_t iconv (iconv_t cd, @ICONV_CONST@ char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); Someday, it would be nice to have the configure test not fail an iconv implementation just because of the const, unless the presence of const is causing a real problem. But I can understand that no one thinks that's important enough to get around to. Interesting. Don't get too offended by the OLD_ prefix to that symbol, by the way. I do not think old means old and broken hence fixed in newer version and you are low life if you live on a platform that has to define it ;-). We just needed to have a boolean to tell which variant it is to let the compiler build objects without complaining, and we named that switch as OLD_ICONV. -- 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: [RFH] NetBSD 6?
Junio C Hamano gits...@pobox.com writes: Don't get too offended by the OLD_ prefix to that symbol, by the way. I do not think old means old and broken hence fixed in newer version and you are low life if you live on a platform that has to define it ;-). Thanks - it did throw me at the beginning, because I expected that it lead to using a copy of GNU iconv and not using the native one. But it will probably confuse few enough people that changing to CONST_ICONV is not warranted... We just needed to have a boolean to tell which variant it is to let the compiler build objects without complaining, and we named that switch as OLD_ICONV. I get that, now that I read utf8.c. It's amusing that git's own function is const, and on non-OLD_ICONV platforms has to cast away the const for standards-compliant iconv. pgpMmmRFXFcvN.pgp Description: PGP signature
[PATCH v3] git-fast-import(1): remove duplicate '--done' option
The '--done' option to git-fast-import is documented twice in its manual page. Combine the best bits of each description, keeping the location of the instance that was added first. Signed-off-by: John Keeping j...@keeping.me.uk --- The commit description gained some noise in v2; this version should be the really correct, final version. Sorry for the noise. Documentation/git-fast-import.txt | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 68bca1a..4ef5721 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -39,10 +39,6 @@ OPTIONS See ``Date Formats'' below for details about which formats are supported, and their syntax. --- done:: - Terminate with error if there is no 'done' command at the - end of the stream. - --force:: Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does @@ -108,7 +104,8 @@ OPTIONS output. --done:: - Require a `done` command at the end of the stream. + Terminate with error if there is no `done` command at the + end of the stream. This option might be useful for detecting errors that cause the frontend to terminate before it has started to write a stream. -- 1.8.0.2 -- 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] wincred: improve compatibility with windows versions
On Tue, Jan 8, 2013 at 5:20 PM, Karsten Blees karsten.bl...@gmail.com wrote:
Am 04.01.2013 22:57, schrieb Erik Faye-Lund:
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.
Thanks for the background-info.
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://m...@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 :-)
Right, thanks for clearing that up.
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.
Nah, I don't think it's worth the trouble. It's a bit unfortunate that
people might get stale credentials clogging up the system, but I don't
really thing this is a big deal.
static int match_cred(const CREDENTIALW *cred)
{
- return (!wusername || !wcscmp(wusername, cred-UserName))
- match_attr(cred, Lgit_protocol, protocol)
- match_attr(cred, Lgit_host, host)
- match_attr(cred, Lgit_path, path);
+ LPCWSTR target = cred-TargetName;
+ if (wusername wcscmp(wusername, cred-UserName))
+ return 0;
+
+ return match_part(target, Lgit, 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)
I can kind of make up some theoretical reasons, but they are a bit exotic ;)
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.
I don't think breaking this is a good idea. It just feels a bit silly,
but I see now that other applications does the same duplication. So
let's just stick to it, even if it's a bit icky ;)
--
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] commit: make default of cleanup option configurable
The default of the cleanup option in git commit
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option commit.cleanup which can be used
to change the default of the cleanup option in
git commit.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Documentation/config.txt | 4
builtin/commit.c | 29 ++---
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 53c4ca1..3f76cd1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -917,6 +917,10 @@ column.tag::
Specify whether to output tag listing in `git tag` in columns.
See `column.ui` for details.
+commit.cleanup::
+ This setting overrides the default of the `--cleanup` option in
+ `git commit`. See linkgit:git-commit[1] for details.
+
commit.status::
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
diff --git a/builtin/commit.c b/builtin/commit.c
index d6dd3df..42acde7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -103,7 +103,7 @@ static enum {
CLEANUP_NONE,
CLEANUP_ALL
} cleanup_mode;
-static char *cleanup_arg;
+const static char *cleanup_arg;
static enum commit_whence whence;
static int use_editor = 1, include_status = 1;
@@ -966,6 +966,20 @@ static const char *read_commit_message(const char *name)
return out;
}
+static void parse_cleanup_arg()
+{
+ if (!cleanup_arg || !strcmp(cleanup_arg, default))
+ cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, verbatim))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, whitespace))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, strip))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die(_(Invalid cleanup mode %s), cleanup_arg);
+}
+
static int parse_and_validate_options(int argc, const char *argv[],
const struct option *options,
const char * const usage[],
@@ -1044,18 +1058,9 @@ static int parse_and_validate_options(int argc, const
char *argv[],
only_include_assumed = _(Clever... amending the last one with
dirty index.);
if (argc 0 !also !only)
only_include_assumed = _(Explicit paths specified without -i
nor -o; assuming --only paths...);
- if (!cleanup_arg || !strcmp(cleanup_arg, default))
- cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, verbatim))
- cleanup_mode = CLEANUP_NONE;
- else if (!strcmp(cleanup_arg, whitespace))
- cleanup_mode = CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, strip))
- cleanup_mode = CLEANUP_ALL;
- else
- die(_(Invalid cleanup mode %s), cleanup_arg);
handle_untracked_files_arg(s);
+ parse_cleanup_arg();
if (all argc 0)
die(_(Paths with -a does not make sense.));
@@ -1320,6 +1325,8 @@ static int git_commit_config(const char *k, const char
*v, void *cb)
include_status = git_config_bool(k, v);
return 0;
}
+ if (!strcmp(k, commit.cleanup))
+ return git_config_string(cleanup_arg, k, v);
status = git_gpg_config(k, v, NULL);
if (status)
--
1.8.1.165.gd94bd4e.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t1402: work around shell quoting issue on NetBSD
The test fails for me on NetBSD 6.0.1 and reports:
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
error: bug in the test script: not 2 or 3 parameters to
test-expect-success
The alleged bug is in this line:
invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
invalid_ref() constructs a test case description using its last argument,
but the shell seems to split it up into two pieces if it contains a
space. Minimal test case:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t=x; a ${t:+$t}
1-x-
$ t=x y; a ${t:+$t}
2-x-y
$ t=x y; a ${t:+x y}
1-x y-
# and with bash
$ t=x y; a ${t:+$t}
1-x y-
$ t=x y; a ${t:+x y}
1-x y-
This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t1402-check-ref-format.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 1ae4d87..1a5a5f3 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -11,7 +11,8 @@ valid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq ref name '$1' is valid${2:+ with options
$2}
+ desc=ref name '$1' is valid${2:+ with options $2}
+ test_expect_success $prereq $desc
git check-ref-format $2 '$1'
}
@@ -22,7 +23,8 @@ invalid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq ref name '$1' is invalid${2:+ with options
$2}
+ desc=ref name '$1' is invalid${2:+ with options $2}
+ test_expect_success $prereq $desc
test_must_fail git check-ref-format $2 '$1'
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t1402: work around shell quoting issue on NetBSD
René Scharfe rene.scha...@lsrfire.ath.cx writes:
The test fails for me on NetBSD 6.0.1 and reports:
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
error: bug in the test script: not 2 or 3 parameters to
test-expect-success
The alleged bug is in this line:
invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
invalid_ref() constructs a test case description using its last argument,
but the shell seems to split it up into two pieces if it contains a
space. Minimal test case:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t=x; a ${t:+$t}
1-x-
$ t=x y; a ${t:+$t}
2-x-y
$ t=x y; a ${t:+x y}
1-x y-
# and with bash
$ t=x y; a ${t:+$t}
1-x y-
$ t=x y; a ${t:+x y}
1-x y-
This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().
Interesting. I notice that t0008 added recently to 'pu' has the
same construct.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
t/t1402-check-ref-format.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 1ae4d87..1a5a5f3 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -11,7 +11,8 @@ valid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq ref name '$1' is valid${2:+ with options
$2}
+ desc=ref name '$1' is valid${2:+ with options $2}
+ test_expect_success $prereq $desc
git check-ref-format $2 '$1'
}
@@ -22,7 +23,8 @@ invalid_ref() {
prereq=$1
shift
esac
- test_expect_success $prereq ref name '$1' is invalid${2:+ with options
$2}
+ desc=ref name '$1' is invalid${2:+ with options $2}
+ test_expect_success $prereq $desc
test_must_fail git check-ref-format $2 '$1'
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t1402: work around shell quoting issue on NetBSD
Am 08.01.2013 21:39, schrieb Junio C Hamano:
René Scharfe rene.scha...@lsrfire.ath.cx writes:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t=x; a ${t:+$t}
1-x-
$ t=x y; a ${t:+$t}
2-x-y
$ t=x y; a ${t:+x y}
1-x y-
# and with bash
$ t=x y; a ${t:+$t}
1-x y-
$ t=x y; a ${t:+x y}
1-x y-
This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().
Interesting. I notice that t0008 added recently to 'pu' has the
same construct.
A quick check shows that subtests 64-68 and 89-93 of t0008 fail for me
on Debian (10 in total) and subtests 64 and 89 fail on NetBSD (2 in
total). Unlike t1402 they don't report bug in the test script.
t0008 only uses ${:+} substitution on variables that don't contain
spaces. With the test changed to store the description in a variable
first I still get the same 2 failures.
There must be something else going on here. The different results are
interesting, especially the higher number of failures on Debian.
René
--
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] commit: make default of cleanup option configurable
Ralf Thielow ralf.thie...@gmail.com writes:
The default of the cleanup option in git commit
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option commit.cleanup which can be used
to change the default of the cleanup option in
git commit.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
The idea makes sense, but I am not sure the implementation is
correct. Does the code already know the final value of use_editor
at the point where it calls git_commit_config? I think you do not
know at least until you call parse_and_validate_options().
Once you got the implementation right, we would want to make sure
that future changes will not break it by adding some tests that
verify:
- Without configuration and without option, the command keeps the
built-in default;
- Without configuration but with option, the command uses the
command line option (we may already have this test, I didn't
check);
- With configuration and without option, the command uses the
configured default (what this patch adds); and
- With configuration and with option, the command uses the command
line option.
The latter two probably needs a few variants, one with --edit (with
EDITOR set to something like true), another with --no-edit, one
without --edit nor --no-edit but with -m $msg to implicitly turn
use_editor off, and one without --edit, --no-edit, nor -m but with
EDITOR set to a scriptlet that writes a message to the file to
implicitly turn use_editor on.
Also, the readers of the documentation for commit --cleanup will
wonder the same thing you wondered before you wrote this patch;
mentioning the configuration variable in its documentation will help
them.
Thanks.
Documentation/config.txt | 4
builtin/commit.c | 29 ++---
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 53c4ca1..3f76cd1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -917,6 +917,10 @@ column.tag::
Specify whether to output tag listing in `git tag` in columns.
See `column.ui` for details.
+commit.cleanup::
+ This setting overrides the default of the `--cleanup` option in
+ `git commit`. See linkgit:git-commit[1] for details.
+
commit.status::
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
diff --git a/builtin/commit.c b/builtin/commit.c
index d6dd3df..42acde7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -103,7 +103,7 @@ static enum {
CLEANUP_NONE,
CLEANUP_ALL
} cleanup_mode;
-static char *cleanup_arg;
+const static char *cleanup_arg;
static enum commit_whence whence;
static int use_editor = 1, include_status = 1;
@@ -966,6 +966,20 @@ static const char *read_commit_message(const char *name)
return out;
}
+static void parse_cleanup_arg()
+{
+ if (!cleanup_arg || !strcmp(cleanup_arg, default))
+ cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, verbatim))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, whitespace))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, strip))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die(_(Invalid cleanup mode %s), cleanup_arg);
+}
+
static int parse_and_validate_options(int argc, const char *argv[],
const struct option *options,
const char * const usage[],
@@ -1044,18 +1058,9 @@ static int parse_and_validate_options(int argc, const
char *argv[],
only_include_assumed = _(Clever... amending the last one with
dirty index.);
if (argc 0 !also !only)
only_include_assumed = _(Explicit paths specified without -i
nor -o; assuming --only paths...);
- if (!cleanup_arg || !strcmp(cleanup_arg, default))
- cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, verbatim))
- cleanup_mode = CLEANUP_NONE;
- else if (!strcmp(cleanup_arg, whitespace))
- cleanup_mode = CLEANUP_SPACE;
- else if (!strcmp(cleanup_arg, strip))
- cleanup_mode = CLEANUP_ALL;
- else
- die(_(Invalid cleanup mode %s), cleanup_arg);
handle_untracked_files_arg(s);
+ parse_cleanup_arg();
if (all argc 0)
die(_(Paths with -a does not make sense.));
@@ -1320,6 +1325,8 @@ static int git_commit_config(const char *k, const char
*v, void *cb)
include_status = git_config_bool(k, v);
return 0;
}
+ if (!strcmp(k, commit.cleanup))
Re: [PATCH] t1402: work around shell quoting issue on NetBSD
René Scharfe rene.scha...@lsrfire.ath.cx writes:
A quick check shows that subtests 64-68 and 89-93 of t0008 fail for me
on Debian (10 in total) and subtests 64 and 89 fail on NetBSD (2 in
total). Unlike t1402 they don't report bug in the test script.
t0008 only uses ${:+} substitution on variables that don't contain
spaces. With the test changed to store the description in a variable
first I still get the same 2 failures.
There must be something else going on here. The different results are
interesting, especially the higher number of failures on Debian.
I forgot to mention that some of them seem to be broken under dash
but pass under bash.
--
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
Enabling scissors by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering why am's scissors option is not enabled by default. It seems a very handy feature, but I'm reluctant to use it when sending patches because the recipient has to notice the scissors and remember to pass --scissors to git am. Could this be made the default? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7JLGAAoJEJrBOlT6nu75iDYIANFiiH50RlL9WKEfaoybeA5K ZLodBze1TcAYIx2/ad6qY+XCoq98+nVXTkv2IAleDiNlfeIhKD24UTWNCysT8p1J 5KeFfR4paxLJLJKkmSL5s3DJbyjLlJWcxD7vGku6F4k35NmY3VYR4rJ/CVv0YRrs p4nNG/EXWBo3/ngiL9QS4E65N0CfcOOjn48RQUmk1DGXSFNHP4L1KuJ4dA9cs9BC 5KmNwh5X6OOal0Lf+ezbxzvoGMwQmhBAxx3t8JQR3E22dLQlUq7stlPl5LDd+Cis XWfNk3B4NuFTum9LqWnM5TN89WCCFh4/pskdRd5ONF51G0jbuF/hBFbwU05qL/4= =Qd94 -END PGP SIGNATURE- -- 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 11/10] doc: push.default is no longer matching
The documentation for the command said that `push.default` is the default without referring to the releavant manual page. Now `simple` is the default behaviour. Document it right there where we say we take the default value from `push.default`, and remove the description of old default being 'matching'. Also reword cryptic desription of `--all`. Signed-off-by: Junio C Hamano gits...@pobox.com --- * I skimmed our two tutorials, just to be sure, but they do not discuss 'git push', so there was nothing to update there. I *think* we are minimally ready to switch the default behaviour now, but there may be other places that need similar adjustment. An independent audit is highly appreciated. Documentation/git-push.txt | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 8b637d3..f326afb 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -36,10 +36,14 @@ OPTIONS[[OPTIONS]] The format of a refspec parameter is an optional plus `+`, followed by the source ref src, followed by a colon `:`, followed by the destination ref dst. - It is used to specify with what src object the dst ref - in the remote repository is to be updated. If not specified, + It is used to specify what src object the dst ref + in the remote repository is to be updated to. If no + refspec is specified on the command line, and if no + refspec is configured for the repository, the behavior of the command is controlled by the `push.default` - configuration variable. + configuration variable, and if it is unset, the `simple` + behaviour is used (see lingit:git-config[1] and look + for `push.default`). + The src is often the name of the branch you would want to push, but it can be any arbitrary SHA-1 expression, such as `master~4` or @@ -65,14 +69,11 @@ the remote repository. The special refspec `:` (or `+:` to allow non-fast-forward updates) directs git to push matching branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name -already exists on the remote side. This is the default operation mode -if no explicit refspec is found (that is neither on the command line -nor in any Push line of the corresponding remotes file---see below) and -no `push.default` configuration variable is set. +already exists on the remote side. --all:: - Instead of naming each ref to push, specifies that all - refs under `refs/heads/` be pushed. + Push all branches (i.e. refs under `refs/heads/`); cannot be + used with other refspec. --prune:: Remove remote branches that don't have a local counterpart. For example -- 1.8.1.317.ga1ba510 -- 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: Enabling scissors by default?
Phillip Susi ps...@ubuntu.com writes: I was wondering why am's scissors option is not enabled by default. It is very easy to miss misidentification of scissors line; as a dangerous, potentially information losing option, I do not think it should be on by default. Another reason (and this is the original one) why it is not enabled is to discourage the contributors from overusing scissors -- 8 -- line. If you always have to write too much stuff before the proper explanation of your patch, so that the integrator has to use -c option all the time, you are explaining your patches wrong. -- 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
trouble using cherry pick
I am trying to accomplish the diagram below: * ??? Merge (or cherry-pick) all changes after 68fb8df from the task1prep branch? |\ |* ??? Change ... |* ??? Change 3 |* ??? Change 2 |* ??? Change 1 |* ??? Merge branch 'task1' into task1prep ||\ || * 5e51e26 v1.01 - fixed a typo || * 208296f v1.00 || * 3393bd6 git commit -m 'start of work, created task1widget' || * 45dd30d Task 1 Branch (from commit 68fb8df) [orphan] |* 68fb8df file name cleanup |* 6f21852 redacted the sensitiveplan.txt for task1 |/ [task1prep branching] * 9ea54ff the widget template for the widget team to use * c0b4454 a plan was made * aa61f73 first commit: readme.txt Any suggestions? primary-2013-01-08_17-35-23-pre-task1-merge-back.tgz Description: application/compressed smime.p7s Description: S/MIME cryptographic signature
Git and Large Binaries: A Proposed Solution - current situation?
Hello git devs! We are currently trying to deal with the large-binaries-in-git problem, and I found this conversation from 2011 on this mailing list: http://git.661346.n2.nabble.com/Fwd-Git-and-Large-Binaries-A-Proposed-Solution-td5948908.html I was also motivated by finding this git GSoC 2012 proposal: Git copies and stores every object from a remote repository when cloning. For large objects, this can consume a lot of bandwidth and disk space, especially for older versions of large objects which are unlikely to be accessed. Git could learn a new alternate repository format where these seldom-used objects are stored on a remote server and only accessed on demand. What both this proposal and the email discussion proposed (among others), i.e. storing large binaries outside of git, and especially fetching them from somewhere else only on demand, sounds like it would solve our problem pretty well. My question (I asked first in the git-devel IRC channel) is if there was any more activity on this, and/or if this is on a roadmap or similar? sparse clone sounds like something similar, but this has been pushed far back, right? I am aware of external mechanisms (e.g. git-annex, git-media), but we would prefer something git-internal: Our userbase is heavily cross-platform (including windows), but there's no windows support for git-annex (which otherwise sounds like we could use it). thank you for any input, all the best, Christoph -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
2013/1/8 David A. Greene gree...@obbligato.org:
From: Techlive Zheng techlivezh...@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 techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@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
+'
+
This test is not test the correct thing, I am currently working on it.
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
--
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: Enabling scissors by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/08/2013 05:42 PM, Junio C Hamano wrote: It is very easy to miss misidentification of scissors line; as a dangerous, potentially information losing option, I do not think it should be on by default. I suppose if it only requires one instance of 8 or 8 and one -, it might be *slightly* dangerous, but if it required a slightly longer minimum line length, it would be pretty darn unlikely to get triggered by accident, and of course, is easily disabled. Another reason (and this is the original one) why it is not enabled is to discourage the contributors from overusing scissors -- 8 -- line. If you always have to write too much stuff before the proper explanation of your patch, so that the integrator has to use -c option all the time, you are explaining your patches wrong. I often see patches being tweaked in response to feedback and resubmitted, usually with a description of what has changed since the previous version. Such descriptions don't need to be in the change log when it is finally applied and seem a perfect use of scissors. Usually such version to version descriptions are put in a cover letter, but if you are only submitting a single patch instead of an entire series, using a cover letter seems silly when you could just put the comments in one email and clearly mark them as not needing to go into the final changelog. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7KriAAoJEJrBOlT6nu755UkIALIT3T5yHH5i+0HOrXLlXzQR +S2jJfFZ8Kcc+kleiEJ3uLFVGTLMpRyjJFKceOuB4/TdJFUivrYJHWJxcKmW8WzK BJKZOjt/jv9r8Qt/AB7KA45S7awfQnOWkg6KQlJa1IM0nUPbo4upgMlWar9l7vjz Hkr7geuHY4fsVUJ7R0rYPcT3pue8ywsT4a9o/ocstfXmC05IrLKQtzO4TuvfiaTb yBG+rAPKz36zfxCN5NyKExZO6v/LnCKym/PH4a6wYIeTUz1EvuaPy5lQOo6ORQ4h xbSyBRDPN4yiVgNXfSQmGKwd9XPqs6h8Z0q3X5mGZyOXurw0JFRJlJ3v8hHIvqg= =Rn7z -END PGP SIGNATURE- -- 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] clone: forbid --bare --separate-git-dir dir
On Wed, Jan 9, 2013 at 12:45 AM, Junio C Hamano gits...@pobox.com wrote: Jens Lehmann jens.lehm...@web.de writes: 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). I agree that these are totally unrelated issues. After all, Jonathan's suggestion to forbid it was because the combination does not make sense and does not have practical uses, and forbidding it would make the command easier to explain than leaving it accepted from the command line. If you choose to go in the opposite direction and make clone --bare --separate-git-dir do something useful, it should be explained very well in the documentation part of the patch why such a combination is a good idea, and in what situation the behaviour is useful and the user may want to consider using it, I think. It is more like postponing the usefulness evaluation of the combination until later (maybe someone will come up with an actual use case). As of now, --separate-git-dir --bare is a valid combination. Jens' patch fixes one case but leave the other case broken, which is why I think it should be in one patch. It's rather ducking head in the sand than actually declaring that the combination is useful. -- 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: Enabling scissors by default?
Phillip Susi ps...@ubuntu.com writes: On 01/08/2013 05:42 PM, Junio C Hamano wrote: It is very easy to miss misidentification of scissors line; as a dangerous, potentially information losing option, I do not think it should be on by default. I suppose if it only requires one instance of 8 or 8 and one -, it might be *slightly* dangerous, but if it required a slightly longer minimum line length, it would be pretty darn unlikely to get triggered by accident, and of course, is easily disabled. Easily disabled is never a good enough reason to change the long established default of not doing anything funky unless the user explicitly asks it to do things differently. You could introduce a new configuration variable am.scissors and personally turn it on, though. Setting that variable *does* count as the user explicitly asking for it. I often see patches being tweaked in response to feedback and resubmitted, usually with a description of what has changed since the previous version. Such descriptions don't need to be in the change log when it is finally applied and seem a perfect use of scissors. Putting such small logs under --- line is the accepted practice. -- 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] clone: forbid --bare --separate-git-dir dir
Duy Nguyen pclo...@gmail.com writes: After all, Jonathan's suggestion to forbid it was because the combination does not make sense and does not have practical uses, and forbidding it would make the command easier to explain than leaving it accepted from the command line. If you choose to go in the opposite direction and make clone --bare --separate-git-dir do something useful, it should be explained very well in the documentation part of the patch why such a combination is a good idea, and in what situation the behaviour is useful and the user may want to consider using it, I think. It is more like postponing the usefulness evaluation of the combination until later (maybe someone will come up with an actual use case). As of now, --separate-git-dir --bare is a valid combination. Jens' patch fixes one case but leave the other case broken, which is why I think it should be in one patch. It's rather ducking head in the sand than actually declaring that the combination is useful. When a user comes and asks how git clone --bare --separate-git-dir is meant to be used, you are saying that your answer will be Eh, it does something random that I cannot explain, and I cannot even suggest a good use case for it, but somebody may find it useful.? If we get rid of it, we do not have to explain what such a useless combination would/should do, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
郑文辉(Techlive Zheng) techlivezh...@gmail.com writes: +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 +' + This test is not test the correct thing, I am currently working on it. Will keep the topic branch out of 'next' for now. David, how would you like to handle a reroll of this piece? -- 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
What's cooking (interim report)
I'll do the next issue of What's cooking after tomorrow's integration cycle, but here are the highlights. The following topics that have already graduated to the 'master' branch have been merged to the 'maint' branch (see the last What's cooking for details of individual topics): ms/subtree-fixlets ss/nedmalloc-compilation jc/maint-fnmatch-old-style-definition jc/test-portability jc/maint-fbsd-sh-ifs-workaround jc/mkstemp-more-careful-error-reporting jc/test-cvs-no-init-in-existing-dir jc/maint-test-portability In addition, the following two patches have been directly applied to the 'maint' branch: t1402: work around shell quoting issue on NetBSD remote-hg: Fix biridectionality - bidirectionality typos We will have other bugfix topics merged to 'maint' and hopefully can tag v1.8.1.1 sometime next week. The following topics that have been cooking on 'next' have been merged to the 'master' branch: kb/maint-bundle-doc as/test-name-alias-uniquely ta/remove-stale-translated-tut tb/test-t9810-no-sed-i tb/test-t9020-no-which jk/maint-fast-import-doc-dedup-done jk/pathspec-literal Most of these will later be merged to 'maint'. These topics have been merged to the 'next' branch: rs/zip-with-uncompressed-size-in-the-header rs/zip-tests jn/xml-depends-on-asciidoc-conf jc/comment-cygwin-win32api-in-makefile as/api-allocation-doc jk/unify-exit-code-by-receiving-signal rs/leave-base-name-in-name-field-of-tar jl/interrupt-clone-remove-separate-git-dir jc/merge-blobs mo/cvs-server-updates as/dir-c-cleanup jk/config-uname Also several new topics are parked in 'pu' and I think they are all ready for 'next'. 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] add warning for depth=0 in git clone.
On Tue, Jan 8, 2013 at 3:07 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
---
builtin/clone.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index ec2f75b..5e91c1e 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -818,6 +818,9 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
remote = remote_get(option_origin);
transport = transport_get(remote, remote-url[0]);
+ if (option_depth transport-smart_options-depth 1)
+ die(_(--depth less or equal 0 makes no sense; read
manpage.));
+
Isn't this too early for the check? The following code is
if (!is_local) {
if (!transport-get_refs_list || !transport-fetch)
die(_(Don't know how to clone %s), transport-url);
transport_set_option(transport, TRANS_OPT_KEEP, yes);
if (option_depth)
transport_set_option(transport, TRANS_OPT_DEPTH,
option_depth);
where transport_set_option() calls set_git_option() to initialize
transport-smart_options-depth. A check should be done after this
point.
--
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] t1402: work around shell quoting issue on NetBSD
René Scharfe rene.scha...@lsrfire.ath.cx writes: invalid_ref() constructs a test case description using its last argument, but the shell seems to split it up into two pieces if it contains a space. Minimal test case: This is indeed a bug in NetBSD's shell, which I reported after finding this test case problem, and I think someone is working on a fix. But because git does not intend to be a shell torture test, if it's possible to avoid bugs in a reasonable way, I think it's nice to do so. pgpeZdzuWnVQF.pgp Description: PGP signature
Re: [PATCH] t1402: work around shell quoting issue on NetBSD
René Scharfe rene.scha...@lsrfire.ath.cx writes: The test fails for me on NetBSD 6.0.1 and reports: ok 1 - ref name '' is invalid ok 2 - ref name '/' is invalid ok 3 - ref name '/' is invalid with options --allow-onelevel ok 4 - ref name '/' is invalid with options --normalize error: bug in the test script: not 2 or 3 parameters to test-expect-success The alleged bug is in this line: invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize' The bug in NetBSD's sh has been fixed in -current: http://gnats.netbsd.org/47361 and the change will almost certainly make it to the -6 and -5 release branches. With the fixed sh: 414c78c (with the workaround): t1402 passes 69637e5 (without the workaround): t1402 passes With the buggy sh, 414c78c (with the workaround): t1402 passes 69637e5 (without workaround): t1402 fails so I can confirm that the workaround is successful on NetBSD 5. Thanks for addressing this, and sorry I didn't mention it on this list. Greg pgpTeLAlCVU0y.pgp Description: PGP signature
On --depth=funny value
Here to outline my current thinking. Note that this is unrelated to the git clone --bottom=v1.2.3 to say I do not care about anything that happened before that version. * First, let's *not* do git fetch --depth=inf; if you want to unplug the bottom of your shallow clone, be more explicit and introduce a new option, e.g. git fetch --unshallow, or something. * Make git fetch and git clone die() when zero or negative number is given with --depth=$N, for the following reasons: - The --depth option is describe as: (git clone) ... a 'shallow' clone with a history truncated to the specified number of revisions. (git fetch) Limit fetching to ancestor-chains not longer than n. It is fairly clear from the above that negative $N does not make any sense. Technically, fetching the commits that were explicitly asked for and not there parents is the only possible ancestor-chain that is not longer than -4, so git fetch --depth=-4 ought to behave just like git fetch --depth=0, but you have to be very sick to read the documentation and expect things to work that way. Also there is no way to misread the git clone documentation and expect git clone --depth=-4 to create a history truncated to negative number of revisions. Which means that it is the right thing to do to die() when a negative number is given to --depth for these commands. - As people count from one, the natural way to ask for the tip commit without any history ought to be --depth=1. Let's declare the current behaviour of --depth=1 that gives the tip and one commit behind it a bug. Which means that these commands should be updated to die() when zero is given to their --depth option. Do not give me any history is inherenty incompatibe with clone or fetch. Because there is no configuration variable fetch.depth (or clone.depth) that forces all your cloned repositories to be shallow, git clone --depth=0 or git fetch --depth=0 couldn't have been ways for existing users to ask to defeat any funny configured depth value and clone or fetch everything. When they wanted to clone or fetch everything, they would have just used the command without any --depth option instead. Which means that nobody gets hurt if we change these commands to die() when zero is given to their --depth option. * We would like to update clone --depth=1 to end up with a tip only repository, but let's not to touch git fetch (and git clone) and make them send 0 over the wire when the command line tells them to use --depth=1 (i.e. let's not do the off-by-one thing). Instead, fix upload-pack (the bug is in get_shallow_commits() in shallow.c, I think), so that it counts correctly. When the other end asks for a history with 1-commit deep, it should return a history that is 1-commit deep, and tell the other end about the parents of the returned history, instead of returning a history that is 2 commmits deep. So when talking with a newer server, clients will get correct number of commits; when talkng with an older server, clients will get a bit more than they asked, but nothing will break. Can people sanity check the reasoning outlined here? Anything I missed? The above outline identifies three concrete tasks that different people can tackle more or less independently, each with updated code, documentation and test: 1. git fetch --unshallow that gives a pretty surface on Duy's --depth=inf; 2. Making git fetch and git clone die on --depth=0 or --depth=-4; 3 Updating upload-pack to count correctly. I'll refrain from saying Any takers? for now. -- 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: On --depth=funny value
On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano gits...@pobox.com wrote: * First, let's *not* do git fetch --depth=inf; if you want to unplug the bottom of your shallow clone, be more explicit and introduce a new option, e.g. git fetch --unshallow, or something. No problem. Something could be --no-depth or --no-shallow. I think any of them is better than --unshallow. * We would like to update clone --depth=1 to end up with a tip only repository, but let's not to touch git fetch (and git clone) and make them send 0 over the wire when the command line tells them to use --depth=1 (i.e. let's not do the off-by-one thing). You can't anyway. Depth 0 on the wire is considered invalid by upload-pack. Instead, fix upload-pack (the bug is in get_shallow_commits() in shallow.c, I think), so that it counts correctly. When the other end asks for a history with 1-commit deep, it should return a history that is 1-commit deep, and tell the other end about the parents of the returned history, instead of returning a history that is 2 commmits deep. So when talking with a newer server, clients will get correct number of commits; when talkng with an older server, clients will get a bit more than they asked, but nothing will break. I'll need to look at get_shallow_commits() anyway for the unshallow patch. I'll probably do this too. -- 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
Invitation to use Google Talk
--- You've been invited by Sahil Mittal to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-b92f427051-d9b5718875-hsYFzGz7Tf-0FB5xZ9uD5fZBj8E To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/a-b92f427051-d9b5718875-hsYFzGz7Tf-0FB5xZ9uD5fZBj8E?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team -- 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: On --depth=funny value
Duy Nguyen pclo...@gmail.com writes: On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano gits...@pobox.com wrote: ... * We would like to update clone --depth=1 to end up with a tip only repository, but let's not to touch git fetch (and git clone) and make them send 0 over the wire when the command line tells them to use --depth=1 (i.e. let's not do the off-by-one thing). You can't anyway. Depth 0 on the wire is considered invalid by upload-pack. Yes, that is a good point that we say if (0 opt-depth) do the shallow thing everywhere, so 0 is spcial in that sense. Which suggests that if we wanted to, we could update the fetch side to do the off-by-one thing against the current upload-pack when the given depth is two or more, and still send 1 when depth=1. When talking with an updated upload-pack that advertises exact-shallow protocol extension, it can disable that off-by-one for all values of depth. That way, the updated client gets history of wrong depth only for --depth=1 when talking with the current upload-pack; all other cases, it will get history of correct depth. Hmm? -- 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
Timberland Schuhe Herren
Diese letzten Jahre habe ich nur in Turnschuhen kleiden, ohne Schnürsenkel, obwohl ich so bekommen habe die Skechers in diesen Tagen setzen wir auf Timberland Schuhe Herren http://www.timberlandschuheoutlet.org/ aus dem Schnee. Die Wahrheit ist, wenn Sie extra für die Paar Stiefel Timberland Boots für Männer mit dem Computer, einer der härteren bezahlen entscheiden, ist eine der Dimensionen. Unabhängig von der Ihr Unternehmen wird über haben die Großhandel Schuhe waren wunderbare Alternativen für Sie. Wenn Sie günstige Timberland Shop http://www.timberlandschuheoutlet.org/ Schuhe kaufen, Ihre ft und Knöchel wird ultimative Unterstützung zu bekommen, kein Unterschied macht, ob man möglicherweise werden Spaziergänge, Wanderungen oder möglicherweise funktioniert, passt da kommt gemeinsam mit gemütlichen Einlagen zur gleichen Zeit, um vollständig für Typen Zehen . Diese timberland Steckdose aus hochwertigen Komponenten hergestellt und konnte in stilvollen Designs bestellt werden. Sie können wählen, viele Arten für die Wintersaison, Sommer oder zeigen. Es gibt Arten am besten für Männer, Frauen, jung Leute, Wanderer, Arbeiter, Jäger gleichzeitig auf andere geeignet. Die Stiefel sind auch völlig unterschiedliche Farben, Komponenten und Größen entwickelt. Timberland Schuhe Damen http://www.timberlandschuheoutlet.org/ sind über die zusätzlichen bekannten Arten von Turnschuhen für das Thema keinen Unterschied machen der Jungs. junge Erwachsene und gleichzeitig die Jungs und Mädchen das Äquivalent in erster Linie vor allem wegen einer zusätzlichen Stelle Produkt wählen. Web, sind die Stiefel sehr formidable gemeinsam mit robust, ausgestattet sowie komplett für die einzelnen Knöchel zu entwickeln entwickelt. Sie werden häufig extra ein von der Menge der jugendlichen Herde versorgt, die sie gegenwärtig eine ganze große Angebot innerhalb funk akzeptiert sowie Hip-Hop-Design und Design und Design durch Audiospuren Anweisung Filmen gleichzeitig Bewegung Bildern begünstigt. Jetzt Verbraucher sind hektisch dabei jeden Tag arbeiten, so Ausarbeitung ist besonders kritisch. Mitglieder der AFSCME Neighborhood 60 und Teamsters Regional 695 der Gundersons 'sind zweite Erzeugung Gewerkschaft. Mbt Schuhe Es ist wirklich bemerkt, welche Timberland Outlet http://www.timberlandschuheoutlet.org/ tatsächlich ehrlich mit viel von Schuhen auf dem Markt sind. Es ist Schuhe und Timberland Boot-Schuhe ganz großen Boot-Schuhe, sanfte Schuhe oder Stiefel, plus viel mehr Komfort und Leichtigkeit. Trotz der Schuhe sind in sehr hoher Qualität, aber du bist aus mollig Bauch gefertigt. Es ist richtig, wie die unfit Stiefel sollten schlechte Einfluss auf unser Wohlbefinden. Nun wird der Winter vor der Tür, so dass die Stiefel Timberland Boots Steckdose evalent sein. Sie wissen, gerade jetzt, ist es wichtig für Sie persönlich ein Paar kaufen. Timberland Stiefel für selber. Es ist wirklich zu allem, timberland boots erkannt können die meisten erfüllen Ihre Bedürfnisse. Und in meinem Kopf Timberland boots können die meisten Ihren Anforderungen entsprechen. Jeder ist für die Stiefel Matching. Sie geben den Frauen Timberland Stiefel und Herren Timberland Schuhe Outlet http://www.timberlandschuheoutlet.org/ zur gleichen Zeit. Das kann auf jeden Fall wirklich außergewöhnlich. - Timberland Schuhe Herren Timberland Shop Timberland Schuhe Damen Timberland Outlet Timberland Schuhe Outlet -- View this message in context: http://git.661346.n2.nabble.com/Timberland-Schuhe-Herren-tp7574557.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The overall Collecting Pandora jewellery Listed here
Danish jewelery thrown Pandora Add on ( pandora jewellery http://www.pandorajewellerycheap.co.uk ) so that you can actualize high-quality add on with dissipating various Side swept the modern world, all-around profits while in the third-largest add on make. Pandora Add on (Pandora), your brilliant technique to abduction terrific events around everyday living, so that you can actualize a nice, brilliant rings, around resetting so that you can accretion a enjoy with individuals for the community. Around 1982, Pandora Add on (Pandora) showed it has the aboriginal retail price food items around Copenhagen, Denmark, now includes increased as compared with eight million desks around forty seven locations, like 260 Pandora Add on (Pandora) thrown abstraction save. Pandora Add on (Pandora) thrown ruthless by way of Ancient mythology. www.pandorajewellerycheap.co.uk -- View this message in context: http://git.661346.n2.nabble.com/The-overall-Collecting-Pandora-jewellery-Listed-here-tp7574558.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: make default of cleanup option configurable
Hi,
Ralf Thielow wrote:
The default of the cleanup option in git commit
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it.
Could you give an example? I'm trying to get a sense of whether these
habitual --cleanup= passers would use --cleanup=verbatim or
--cleanup=strip.
I'm a bit worried that a setting like 'commit.cleanup = strip' would
be likely to break scripts. Yes, scripts using git commit instead
of commit-tree while caring about detailed semantics are asking for
trouble, but I'm worried about importers, for example, which are
sometimes written by new git users. Some scripts might assume that
git commit preserves the entire change description from their source
data, even when some lines happen to start by listing the ways the
author is #1.
I don't think that necessarily rules out this change, but:
1. We need more of an explanation of the purpose than this lets
people type less. What workflow does setting this option fit
into?
2. I would prefer to see a little thought about whether it's possible
to avoid silently impacting scripts. E.g., depending on the
answer to (1), maybe supporting verbatim but not strip would be
ok? Or alternatively, maybe a search of public code repositories
would reveal that new git users tend to write their importers in a
way that this doesn't break.
As a side effect, the information gathered to answer (1) and (2) could
have the potential to make the user-level documentation more useful,
by adding context to the description of the configuration item.
[...]
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -103,7 +103,7 @@ static enum {
CLEANUP_NONE,
CLEANUP_ALL
} cleanup_mode;
-static char *cleanup_arg;
+const static char *cleanup_arg;
Style nit: storage class comes first, then the type. Otherwise the
typename const char * is split up.
Hope that helps,
Jonathan
--
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
