What's cooking in git.git (Jun 2013, #05; Sat, 15)
What's cooking in git.git (Jun 2013, #05; Sat, 15) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * bp/mediawiki-credential (2013-06-05) 1 commit (merged to 'next' on 2013-06-05 at ea07ec1) + git-remote-mediawiki: use Git.pm functions for credentials The bridge to MediaWiki has been updated to use the credential helper interface in Git.pm, losing its own and the original implementation the former was based on. * kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits (merged to 'next' on 2013-06-05 at 193242b) + revision.c: make default history consider bottom commits + revision.c: don't show all merges for --parents + revision.c: discount side branches when computing TREESAME + revision.c: add BOTTOM flag for commits + simplify-merges: drop merge from irrelevant side branch + simplify-merges: never remove all TREESAME parents + t6012: update test for tweaked full-history traversal + revision.c: Make --full-history consider more merges + Documentation: avoid uninteresting + rev-list-options.txt: correct TREESAME for P + t6111: add parents to tests + t6111: allow checking the parents as well + t6111: new TREESAME test set + t6019: test file dropped in -s ours merge + decorate.c: compact table when growing Major update to a very core part of the revision traversal logic to improve culling of irrelevant parents while traversing a mergy history. * mh/reflife (2013-06-02) 25 commits (merged to 'next' on 2013-06-05 at 291d863) + refs: document the lifetime of the args passed to each_ref_fn + register_ref(): make a copy of the bad reference SHA-1 + exclude_existing(): set existing_refs.strdup_strings + string_list_add_refs_by_glob(): add a comment about memory management + string_list_add_one_ref(): rename first parameter to refname + show_head_ref(): rename first parameter to refname + show_head_ref(): do not shadow name of argument + add_existing(): do not retain a reference to sha1 + do_fetch(): clean up existing_refs before exiting + do_fetch(): reduce scope of peer_item + object_array_entry: fix memory handling of the name field + find_first_merges(): remove unnecessary code + find_first_merges(): initialize merges variable using initializer + fsck: don't put a void*-shaped peg in a char*-shaped hole + object_array_remove_duplicates(): rewrite to reduce copying + revision: use object_array_filter() in implementation of gc_boundary() + object_array: add function object_array_filter() + revision: split some overly-long lines + cmd_diff(): make it obvious which cases are exclusive of each other + cmd_diff(): rename local variable list - entry + cmd_diff(): use an object_array for holding trees + builtin_diff_tree(): make it obvious that function wants two entries + add_rev_cmdline(): make a copy of the name argument + fetch: make own copies of refnames + describe: make own copy of refname (this branch is used by mh/ref-races.) Define memory ownership and lifetime rules for what for-each-ref feeds to its callbacks (in short, you do not own it, so make a copy if you want to keep it). * mt/send-email-cc-match-fix (2013-06-05) 7 commits (merged to 'next' on 2013-06-06 at e4d0831) + test-send-email: test for pre-sanitized self name + t/send-email: test suppress-cc=self with non-ascii + t/send-email: add test with quoted sender + send-email: make --suppress-cc=self sanitize input + t/send-email: test suppress-cc=self on cccmd + send-email: fix suppress-cc=self on cccmd + t/send-email.sh: add test for suppress-cc=self Logic git-send-email used to suppress cc mishandled names like A U. Thor aut...@example.xz, where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * rr/complete-difftool-fixup (2013-06-09) 2 commits (merged to 'next' on 2013-06-11 at fe91170) + completion: show can take both revlist and paths + completion: difftool takes both revs and files (this branch is tangled with rr/complete-difftool.) git difftool can take both revs to be compared and pathspecs. git show takes revs, revs:path and pathspecs. * rr/remove-contrib-some (2013-06-12) 2 commits (merged to 'next' on 2013-06-12 at 797644c) + contrib: drop blameview/ directory (merged to 'next' on 2013-06-05 at fc15705) + contrib: remove continuous/ and patches/ Remove stale contrib/ material. -- [New Topics] * rr/prompt-rebase-breakage-fix (2013-06-14) 1 commit - prompt: squelch error
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: [...] I have no desire to argue incessantly. I just want a solution to the problem! A rerolled series that does: - Tweak wt-status.c to take information not from reflog, when detached during rebase (this may need to tweak existing tests, as different rebase modes may use 'checkout' liberally in different ways); Please be more specific, and tell me what it should print when a rebase is in progress. Would a constant # rebase in progress; onto $ONTO be sufficient? - Teach builtin/commit.c to pay attention to reflog-action; thanks to the previous step, this will not have to change the tests; Where did builtin/commit.c enter into the equation? Doesn't it already respect GIT_REFLOG_ACTION? See line 1461. - Update the reflog message rebase uses, but again this will not affect wt-status.c at all. Okay. -- 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: What's cooking in git.git (Jun 2013, #05; Sat, 15)
Junio C Hamano wrote:
* rr/am-quit-empty-then-abort-fix (2013-06-14) 2 commits
- SQUASH???
- am: handle stray $dotest directory
Please pick up the latest iteration.
http://thread.gmane.org/gmane.comp.version-control.git/227946
* rr/triangle-push-fix (2013-06-09) 4 commits
- t/push-default: test pushdefault with all modes
- t/push-default: generalize test_push_{success, commit}
- push: make upstream, simple work with pushdefault
- t/push-default: remove redundant test_config lines
Tries to apply the 'push.default = upstream' semantics to
triangular workflow where it does not quite apply.
Waiting for a reroll.
Still haven't figured out a solution; will hopefully come up with
something in a few days. Discard if necessary.
There are some other topics I posted awaiting responses. Take some
time out to read especially the for-each-ref enhancement series that
Duy and I wrote.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] am: handle stray $dotest directory
Ramkumar Ramachandra wrote: Can you tell me how to get shell-script-mode to indent the case statement properly? (I used the default indentation) Never mind; I figured it out: (setq sh-indent-for-case-label 0) (setq sh-indent-for-case-alt '+) Maybe we should dump the relevant parts of my .emacs somewhere in-tree? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] checkout: respect GIT_REFLOG_ACTION
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git checkout -
to work as expected after any rebase operation.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/checkout.c | 11 ---
t/t2012-checkout-last.sh | 8
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f5b50e5..1e2af85 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -587,7 +587,7 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
struct branch_info *new)
{
struct strbuf msg = STRBUF_INIT;
- const char *old_desc;
+ const char *old_desc, *reflog_msg;
if (opts-new_branch) {
if (opts-new_orphan_branch) {
if (opts-new_branch_log !log_all_ref_updates) {
@@ -620,8 +620,13 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
old_desc = old-name;
if (!old_desc old-commit)
old_desc = sha1_to_hex(old-commit-object.sha1);
- strbuf_addf(msg, checkout: moving from %s to %s,
- old_desc ? old_desc : (invalid), new-name);
+
+ reflog_msg = getenv(GIT_REFLOG_ACTION);
+ if (!reflog_msg)
+ strbuf_addf(msg, checkout: moving from %s to %s,
+ old_desc ? old_desc : (invalid), new-name);
+ else
+ strbuf_insert(msg, 0, reflog_msg, strlen(reflog_msg));
if (!strcmp(new-name, HEAD) !new-path !opts-force_detach) {
/* Nothing to do. */
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 6ad6edf..e7ba8c5 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -116,7 +116,7 @@ test_expect_success 'master...' '
test z$(git rev-parse --verify HEAD) = z$(git rev-parse --verify
master^)
'
-test_expect_failure 'checkout - works after a rebase A' '
+test_expect_success 'checkout - works after a rebase A' '
git checkout master
git checkout other
git rebase master
@@ -124,7 +124,7 @@ test_expect_failure 'checkout - works after a rebase A' '
test z$(git symbolic-ref HEAD) = zrefs/heads/master
'
-test_expect_failure 'checkout - works after a rebase A B' '
+test_expect_success 'checkout - works after a rebase A B' '
git branch moodle master~1
git checkout master
git checkout other
@@ -133,7 +133,7 @@ test_expect_failure 'checkout - works after a rebase A B'
'
test z$(git symbolic-ref HEAD) = zrefs/heads/master
'
-test_expect_failure 'checkout - works after a rebase -i A' '
+test_expect_success 'checkout - works after a rebase -i A' '
git checkout master
git checkout other
git rebase -i master
@@ -141,7 +141,7 @@ test_expect_failure 'checkout - works after a rebase -i
A' '
test z$(git symbolic-ref HEAD) = zrefs/heads/master
'
-test_expect_failure 'checkout - works after a rebase -i A B' '
+test_expect_success 'checkout - works after a rebase -i A B' '
git branch foodle master~1
git checkout master
git checkout other
--
1.8.3.1.443.g4fd77b9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] rebase -i: prepare to write reflog message for checkout
The branch-flipping rebase -i internally does is not 'checkout' as far as the end-user is concerned; therefore, rebase -i should never write checkout: messages to the reflog. To achieve this, set a sensible GIT_REFLOG_ACTION; checkout does not respect this variable yet, but a future patch will change this. After that patch, rebase -i will write the following line to the reflog when started: rebase -i (start): checkout master This is much better than the confusing message it currently writes: checkout: moving from master to 1462b67 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-rebase--interactive.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index f953d8d..0f04425 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -838,6 +838,7 @@ comment_for_reflog start if test ! -z $switch_to then + GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $switch_to output git checkout $switch_to -- || die Could not checkout $switch_to fi @@ -981,6 +982,7 @@ has_action $todo || test -d $rewritten || test -n $force_rebase || skip_unnecessary_picks +GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name output git checkout $onto || die_abort could not detach HEAD git update-ref ORIG_HEAD $orig_head do_rest -- 1.8.3.1.443.g4fd77b9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] status: do not depend on rebase reflog messages
b397ea4 (status: show more info than currently not on any branch, 2013-03-13) made the output of 'git status' richer in the case of a detached HEAD. Before this patch, with a detached HEAD: $ git status # Not currently on any branch. After the patch: $ git checkout v1.8.2 $ git status # HEAD detached at v1.8.2. It works by digging the reflog for the most recent message of the form checkout: moving from to . It then asserts that HEAD and are the same, and displays this message. When they aren't equal, it displays: $ git status # HEAD detached from fe11db. In case of a rebase [-i] operation in progress, this message depends on the implementation of rebase writing checkout: messages to the reflog. To remove this dependency so that rebase can be updated to write better reflog messages, replace this HEAD detached from message with the constant: # rebase in progress; onto $ONTO The issue is not isolated to rebase at all. Several other scripts like bisect write checkout: messages to the reflog, and the tests in t/status-help depend on them. Fixing them is left as an exercise to other contributors. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t7512-status-help.sh | 37 + wt-status.c| 5 - 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index bf08d4e..739624e 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -77,7 +77,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' ONTO=$(git rev-parse --short HEAD^^) test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -EOF - # HEAD detached at $ONTO + # rebase in progress; onto $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) @@ -104,7 +104,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' echo three main.txt git add main.txt cat expected -EOF - # HEAD detached at $ONTO + # rebase in progress; onto $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # @@ -136,7 +136,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' ONTO=$(git rev-parse --short rebase_i_conflicts) test_must_fail git rebase -i rebase_i_conflicts cat expected -EOF - # HEAD detached at $ONTO + # rebase in progress; onto $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) @@ -162,7 +162,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' test_must_fail git rebase -i rebase_i_conflicts git add main.txt cat expected -EOF - # HEAD detached at $ONTO + # rebase in progress; onto $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # @@ -188,10 +188,9 @@ test_expect_success 'status when rebasing -i in edit mode' ' export FAKE_LINES test_when_finished git rebase --abort ONTO=$(git rev-parse --short HEAD~2) - TGT=$(git rev-parse --short two_rebase_i) git rebase -i HEAD~2 cat expected -EOF - # HEAD detached from $TGT + # rebase in progress; onto $ONTO # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) @@ -216,9 +215,8 @@ test_expect_success 'status when splitting a commit' ' ONTO=$(git rev-parse --short HEAD~3) git rebase -i HEAD~3 git reset HEAD^ - TGT=$(git rev-parse --short HEAD) cat expected -EOF - # HEAD detached at $TGT + # rebase in progress; onto $ONTO # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''. # (Once your working directory is clean, run git rebase --continue) # @@ -246,11 +244,10 @@ test_expect_success 'status after editing the last commit with --amend during a export FAKE_LINES test_when_finished git rebase --abort ONTO=$(git rev-parse --short HEAD~3) - TGT=$(git rev-parse --short three_amend) git rebase -i HEAD~3 git commit --amend -m foo cat expected -EOF - # HEAD detached from $TGT + # rebase in
[PATCH v2 4/6] wt-status: remove unused field in grab_1st_switch_cbdata
The struct grab_1st_switch_cbdata has the field found, which is set in
grab_1st_switch() when a match is found. This information is redundant
and unused by any caller: the return value of the function serves to
communicate this information anyway. Remove the field.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
wt-status.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index bf84a86..2511270 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1035,7 +1035,6 @@ got_nothing:
}
struct grab_1st_switch_cbdata {
- int found;
struct strbuf buf;
unsigned char nsha1[20];
};
@@ -1059,7 +1058,6 @@ static int grab_1st_switch(unsigned char *osha1, unsigned
char *nsha1,
for (end = target; *end *end != '\n'; end++)
;
strbuf_add(cb-buf, target, end - target);
- cb-found = 1;
return 1;
}
--
1.8.3.1.443.g4fd77b9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] Fix checkout-dash to work with rebase
So after extensive discussions with Junio, I have updated [5/6] to special-case rebase and rebase -i instead of dropping the HEAD detached from message altogether. Also, [1/6] includes two more tests, as suggested by Junio. Junio: The message is now the constant rebase in progress; onto $ONTO. Feel free to tweak it before applying. Thanks. Ramkumar Ramachandra (6): t/checkout-last: checkout - doesn't work after rebase rebase: prepare to write reflog message for checkout rebase -i: prepare to write reflog message for checkout wt-status: remove unused field in grab_1st_switch_cbdata status: do not depend on rebase reflog messages checkout: respect GIT_REFLOG_ACTION builtin/checkout.c | 11 --- git-rebase--interactive.sh | 2 ++ git-rebase.sh | 2 ++ t/t2012-checkout-last.sh | 34 ++ t/t7512-status-help.sh | 37 + wt-status.c| 7 --- 6 files changed, 67 insertions(+), 26 deletions(-) -- 1.8.3.1.443.g4fd77b9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] rebase: prepare to write reflog message for checkout
The branch-flipping rebase internally does is not 'checkout' as far as the end-user is concerned; therefore, rebase should never write checkout: messages to the reflog. To achieve this, set a sensible GIT_REFLOG_ACTION; checkout does not respect this variable yet, but a future patch will change this. After that patch, rebase will write the following line to the reflog when started: rebase: checkout master This is much better than the confusing message it currently writes: checkout: moving from master to 1462b67 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-rebase.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-rebase.sh b/git-rebase.sh index d0c11a9..6587019 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -568,6 +568,8 @@ test $type = interactive run_specific_rebase # Detach HEAD and reset the tree say $(gettext First, rewinding head to replay your work on top of it...) + +GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name git checkout -q $onto^0 || die could not detach HEAD git update-ref ORIG_HEAD $orig_head -- 1.8.3.1.443.g4fd77b9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/6] t/checkout-last: checkout - doesn't work after rebase
The following command $ git checkout - does not work as expected after a rebase. Every kind of rebase must behave in the exactly same way: for the purposes of checkout -, the rebase event should be inconsequential. Add four failing tests documenting this bug: two for a normal rebase, and another two for an interactive rebase. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t2012-checkout-last.sh | 34 ++ 1 file changed, 34 insertions(+) diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh index b44de9d..6ad6edf 100755 --- a/t/t2012-checkout-last.sh +++ b/t/t2012-checkout-last.sh @@ -116,4 +116,38 @@ test_expect_success 'master...' ' test z$(git rev-parse --verify HEAD) = z$(git rev-parse --verify master^) ' +test_expect_failure 'checkout - works after a rebase A' ' + git checkout master + git checkout other + git rebase master + git checkout - + test z$(git symbolic-ref HEAD) = zrefs/heads/master +' + +test_expect_failure 'checkout - works after a rebase A B' ' + git branch moodle master~1 + git checkout master + git checkout other + git rebase master moodle + git checkout - + test z$(git symbolic-ref HEAD) = zrefs/heads/master +' + +test_expect_failure 'checkout - works after a rebase -i A' ' + git checkout master + git checkout other + git rebase -i master + git checkout - + test z$(git symbolic-ref HEAD) = zrefs/heads/master +' + +test_expect_failure 'checkout - works after a rebase -i A B' ' + git branch foodle master~1 + git checkout master + git checkout other + git rebase master foodle + git checkout - + test z$(git symbolic-ref HEAD) = zrefs/heads/master +' + test_done -- 1.8.3.1.443.g4fd77b9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git ignore logic does not work as advertised
On Saturday, June 15, 2013 06:07:59 PM John Keeping wrote: Which version of Git are you using? You may be hitting a regression that was introduced in Git 1.8.3 and is fixed in Git 1.8.3.1. updated from 1.8.3 to 1.8.3.1 and solved. Thank you. Thomas Koch, http://www.koch.ro -- 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 V3 0/4] git-remote-mediawiki: new tool to preview local changes without pushing
benoit.per...@ensimag.fr wrote: Subject: [PATCH V3 0/4] git-remote-mediawiki: new tool to preview local changes without pushing Quick tip: use git format-patch -v3. The uppercase 'V' indicates that you probably typed it out yourself, or used --subject-prefix=PATCH V3. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Junio C Hamano wrote:
I view the two codepaths touched by these patches the other way
around.
I see. Thanks for the early feedback. I have some doubts.
An abbreviated unique SHA-1 you have today may not be unique
tomorrow. There is no reason to deliberately lose information
(e.g. by using Then, instead of the absolute minimum, let's record
a bit more bytes heuristics) when we record. The reflog recording
code in checkout writes full 40-characters on purpose and there is
no reason not to do so (i.e. the codepath that is the topic of 2/2).
When did we guarantee that the messages written by the reflog are invariant?
$ git checkout @^
$ git reflog | head -n 1
b1d94f2 HEAD@{2 seconds ago}: checkout: moving from checkout-dash to HEAD^
What does HEAD^ even mean? What guarantees that checkout-dash will
not be something else tomorrow? If you want invariance, isn't that
what the first field is for (b1d94f2)? As I understand it, the
messages are purely to convey end-user information about the
breadcrumb trail: they were later made semi-semantic (like the @{-N}
parser using them).
Once we accept that design principle of not losing information when
we do not have to, it naturally follows that the writing side should
write full 40-hex, and also the reading side (i.e. the codepath that
is the topic of 1/2) should make sure that it reads 40-hex and
nothing else. This also reduces the risk of a funny branch name
that consists only of [0-9a-f] getting mistaken as an object name,
but that is not the primary point.
As I already explained, I don't know what information loss you're
talking about. And yes, I noticed advice.object_name_warning.
So I am fairly strongly negative on both changes.
Okay, but please explain it for me.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] config doc: rewrite push.default section
Design by Junio.
By detaching descriptions from the implementation, we're only confusing
users. I've chosen to use the term central workflow to make the
descriptions terse and readable, although I've stayed way from
triangular workflow (referred to as non-central workflow).
Yes, I hate writing documentation but I have no choice if I want to
update the implementations to do something sane in triangular workflows.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I'll send in the implementation once we can agree that this is what
we want.
Documentation/config.txt | 51
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7fd4035..30350a3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1832,33 +1832,32 @@ push.default::
line. Possible values are:
+
--
-* `nothing` - do not push anything.
-* `matching` - push all branches having the same name in both ends.
- This is for those who prepare all the branches into a publishable
- shape and then push them out with a single command. It is not
- appropriate for pushing into a repository shared by multiple users,
- since locally stalled branches will attempt a non-fast forward push
- if other users updated the branch.
- +
- This is currently the default, but Git 2.0 will change the default
- to `simple`.
-* `upstream` - push the current branch to its upstream branch
- (`tracking` is a deprecated synonym for this).
- With this, `git push` will update the same remote ref as the one which
- is merged by `git pull`, making `push` and `pull` symmetrical.
- See branch.name.merge for how to configure the upstream branch.
-* `simple` - like `upstream`, but refuses to push if the upstream
- branch's name is different from the local one. This is the safest
- option and is well-suited for beginners. It will become the default
- in Git 2.0.
-* `current` - push the current branch to a branch of the same name.
+* `nothing` - error out unless a refspec is explicitly given.
+
+* `current` - push the refspec $HEAD. HEAD is resolved early to a
+ branch name (referred to as $HEAD). In other words, push the
+ current branch to update a branch with the same name on the pushing
+ side.
+
+* `upstream` - push the refspec $HEAD:branch.$HEAD.merge, and error
+ out if the push destination is not the same as branch.$HEAD.remote.
+ The name upstream refers to the revision @{u[pstream]} in
+ linkgit:gitrevisions[7]. It is useful in central workflows, to make
+ the `push` symmetrical to `pull`.
+
+* `simple` - in central workflows, behaves like `upstream`, except
+ that it errors out unless branch.$HEAD.merge is equal to $HEAD. In
+ non-central workflows, behaves like `current`. It will become the
+ default in Git 2.0.
+
+* `matching` - push the refspec :. In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for those who prepare all the
+ branches into a publishable shape and then push them out with a
+ single command. Dangerous, and inappropriate unless you are the
+ only person updating your push destination. This is currently the
+ default, but Git 2.0 will change the default to `simple`.
--
-+
-The `simple`, `current` and `upstream` modes are for those who want to
-push out a single branch after finishing work, even when the other
-branches are not yet ready to be pushed out. If you are working with
-other people to push into the same shared repository, you would want
-to use one of these.
rebase.stat::
Whether to show a diffstat of what changed upstream since the last
--
1.8.3.1.443.g4fd77b9
--
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] rebase -i: fixup fixup! fixup!
Junio C Hamano gits...@pobox.com writes:
Andrew Pimlott and...@pimlott.net writes:
Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
It happened to work and I added a test. But then it occurred to me that
it might have been better to fix commit --fixup/--squash to strip the
fixup! or squash! from the referenced commit in the first place.
Anyhow, below is my patch for --autosquash, but unles someone has an
objection to doing it in commit, I'll work on that.
Is it always true that you would squash and fixup in the same order
as these follow-up commits happened?
That is, if you did this (time flows from top to bottom):
1 A
2 B
3 fixup A
4 squash B
5 fixup fixup A
6 fixup A
I am wondering if applying 6 on top of 5 is always what you want, or
you would want to apply it to 3 instead. Otherwise you would have
written
6 fixup fixup fixup A
instead.
The two reordering possibilities are:
1 A1 A
3 fixup A 3 fixup A
5 fixup fixup A6 fixup A
6 fixup A 5 fixup fixup A
2 B2 B
4 squash B 4 squash B
If you strip out the prefix when you make commits, you may lose the
information if you want to use in order to express these different
orders. I am not sure if it matters in practice, but I am not yet
convinced it is a good idea.
Isn't it a bit of an academic question?
All 'fixup* A' are clearly intended to be squashed into A eventually.
You could reorder them, but unless you arranged your fixups as nonlinear
history (does anyone do that?) they have been built sequentially. So at
best the extra reordering does not buy you anything, because you're
going to fix up A anyways. You may even get extra conflicts during the
reordering, which make the process less automatic and more error-prone.
[If you did actually arrange things nonlinearly, so that you have
* A
|\
| * fixup A
| |
* | fixup A
|/
* M (you need M so that you can rebase both fixups simultaneously)
then you might actually use the number of 'fixup' prefixes to determine
their order. However, if you actually generate such history, you have
to go out of your way to look at the other branches too, and make sure
that the number of prefixes is sufficiently unique to disambiguate the
order as far as you want it to do that, etc. It sounds like too much of
a headache to be worth using like that.]
And once you have that, it seems a nicer and cleaner idea to generate
'fixup! A' each time, instead of a successive sequence of
fixup! A
fixup! fixup! A
fixup! fixup! fixup! A
...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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] config doc: rewrite push.default section
From: Ramkumar Ramachandra artag...@gmail.com
Sent: Sunday, June 16, 2013 11:06 AM
Design by Junio.
By detaching descriptions from the implementation, we're only
confusing
users. I've chosen to use the term central workflow to make the
descriptions terse and readable, although I've stayed way from
triangular workflow (referred to as non-central workflow).
A sentence, in the Documentation/config.txt, is needed to clarify the
Central workflow and any distinction with the non-central workflow(s).
We cannot assume the new reader has the same world view of that concept
(they may be thinking it means we do a centralised VCS, not a DVCS with
a chosen central primary repo - assuming I have understood it
correctly).
It took a while to bottom out the issues, so it is worth summarising the
key point(s) in the documentation to avoid having to repeat the
disussions ;-)
Yes, I hate writing documentation but I have no choice if I want to
update the implementations to do something sane in triangular
workflows.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I'll send in the implementation once we can agree that this is what
we want.
Documentation/config.txt | 51
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7fd4035..30350a3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1832,33 +1832,32 @@ push.default::
line. Possible values are:
+
--
-* `nothing` - do not push anything.
-* `matching` - push all branches having the same name in both ends.
- This is for those who prepare all the branches into a publishable
- shape and then push them out with a single command. It is not
- appropriate for pushing into a repository shared by multiple users,
- since locally stalled branches will attempt a non-fast forward push
- if other users updated the branch.
- +
- This is currently the default, but Git 2.0 will change the default
- to `simple`.
-* `upstream` - push the current branch to its upstream branch
- (`tracking` is a deprecated synonym for this).
- With this, `git push` will update the same remote ref as the one
which
- is merged by `git pull`, making `push` and `pull` symmetrical.
- See branch.name.merge for how to configure the upstream branch.
-* `simple` - like `upstream`, but refuses to push if the upstream
- branch's name is different from the local one. This is the safest
- option and is well-suited for beginners. It will become the default
- in Git 2.0.
-* `current` - push the current branch to a branch of the same name.
+* `nothing` - error out unless a refspec is explicitly given.
+
+* `current` - push the refspec $HEAD. HEAD is resolved early to a
+ branch name (referred to as $HEAD). In other words, push the
s/In other words,/That is,/
'In other words' often indicates poor wording, while here the extra
words explicitly explain the effect.
+ current branch to update a branch with the same name on the pushing
+ side.
s/pushing side/push destination/ for consistency with upstream wording
used below.
+
+* `upstream` - push the refspec $HEAD:branch.$HEAD.merge, and error
+ out if the push destination is not the same as branch.$HEAD.remote.
+ The name upstream refers to the revision @{u[pstream]} in
+ linkgit:gitrevisions[7]. It is useful in central workflows, to
make
+ the `push` symmetrical to `pull`.
+
+* `simple` - in central workflows, behaves like `upstream`, except
+ that it errors out unless branch.$HEAD.merge is equal to $HEAD. In
+ non-central workflows, behaves like `current`. It will become the
+ default in Git 2.0.
+
+* `matching` - push the refspec :. In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for those who prepare all the
+ branches into a publishable shape and then push them out with a
+ single command. Dangerous, and inappropriate unless you are the
Dangerous and innappropriate (which it maybe for some) is too
judgemental.
Perhaps turn it around to a positive (unless - only if).
Useful if you are the..
+ only person updating your push destination. This is currently the
+ default, but Git 2.0 will change the default to `simple`.
--
-+
-The `simple`, `current` and `upstream` modes are for those who want
to
-push out a single branch after finishing work, even when the other
-branches are not yet ready to be pushed out. If you are working with
-other people to push into the same shared repository, you would want
-to use one of these.
rebase.stat::
Whether to show a diffstat of what changed upstream since the last
--
1.8.3.1.443.g4fd77b9
--
regards
Philip
--
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/2] sha1_name: stop hard-coding 40-character hex checks
On Sat, Jun 15, 2013 at 1:38 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
In two places, get_sha1_basic() assumes that strings are possibly sha1
hexes if they are 40 characters long, and calls get_sha1_hex() in these
two cases. This 40-character check is ugly and wrong: there is nothing
preventing a revision or branch name from being exactly 40 characters.
Replace it with a call to the more robust get_short_sha1().
I share your disdain for the bare '40's in the code. But I think this
code is less clear than the previous version with the magic number.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 90419ef..d862af3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -451,7 +451,7 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
int refs_found = 0;
int at, reflog_len, nth_prior = 0;
- if (len == 40 !get_sha1_hex(str, sha1)) {
+ if (!get_short_sha1(str, strlen(str), sha1, GET_SHA1_QUIETLY)) {
Use len instead of strlen(str) here. It's faster and more correct.
But also get_short_sha1 is much heavier than get_sha1_hex and does not
seem appropriate here.
refs_found = dwim_ref(str, len, tmp_sha1, real_ref);
if (refs_found 0 warn_ambiguous_refs) {
warning(warn_msg, len, str);
@@ -492,9 +492,9 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
int detached;
if (interpret_nth_prior_checkout(str, buf) 0) {
- detached = (buf.len == 40 !get_sha1_hex(buf.buf,
sha1));
+ detached = get_short_sha1(buf.buf, buf.len, sha1,
GET_SHA1_QUIETLY);
strbuf_release(buf);
- if (detached)
+ if (detached != SHORT_NAME_NOT_FOUND)
The semantic meaning of 'detached' seems less clear now if you have to
compare against an enumerated constant to determine the result. But
also, I do not see why you have to test '!= SHORT_NAME_NOT_FOUND' here
but you did not have to in the other instance.
I think it would be improved if you did this comparison in the
assignment of detached so 'detached' could keep its original boolean
meaning.
But anyway, having looked inside get_short_sha1, it really does seem
to do much more than you want here.
return 0;
}
}
--
1.8.3.1.438.g96d34e8
--
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
[PATCH v4 1/6] t7401: make indentation consistent
Only leading whitespace is changed in this patch. Signed-off-by: John Keeping j...@keeping.me.uk --- t/t7401-submodule-summary.sh | 80 ++-- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh index 30b429e..c328726 100755 --- a/t/t7401-submodule-summary.sh +++ b/t/t7401-submodule-summary.sh @@ -76,8 +76,8 @@ head3=$( ) test_expect_success 'modified submodule(backward)' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head2...$head3 (2): Add foo3 Add foo2 @@ -89,8 +89,8 @@ EOF head4=$(add_file sm1 foo4 foo5) head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD) test_expect_success 'modified submodule(backward and forward)' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head2...$head4 (4): Add foo5 Add foo4 @@ -102,15 +102,15 @@ EOF test_expect_success '--summary-limit' -git submodule summary -n 3 actual -cat expected -EOF + git submodule summary -n 3 actual + cat expected -EOF * sm1 $head2...$head4 (4): Add foo5 Add foo4 Add foo3 EOF -test_cmp expected actual + test_cmp expected actual commit_file sm1 @@ -122,8 +122,8 @@ rm -f sm1 mv sm1-bak sm1 test_expect_success 'typechanged submodule(submodule-blob), --cached' -git submodule summary --cached actual -cat expected -EOF + git submodule summary --cached actual + cat expected -EOF * sm1 $head4(submodule)-$head5(blob) (3): Add foo5 @@ -132,59 +132,59 @@ EOF test_expect_success 'typechanged submodule(submodule-blob), --files' -git submodule summary --files actual -cat expected -EOF + git submodule summary --files actual + cat expected -EOF * sm1 $head5(blob)-$head4(submodule) (3): Add foo5 EOF -test_i18ncmp actual expected + test_i18ncmp actual expected rm -rf sm1 git checkout-index sm1 test_expect_success 'typechanged submodule(submodule-blob)' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head4(submodule)-$head5(blob): EOF -test_i18ncmp actual expected + test_i18ncmp actual expected rm -f sm1 test_create_repo sm1 head6=$(add_file sm1 foo6 foo7) test_expect_success 'nonexistent commit' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head4...$head6: Warn: sm1 doesn't contain commit $head4_full EOF -test_i18ncmp actual expected + test_i18ncmp actual expected commit_file test_expect_success 'typechanged submodule(blob-submodule)' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head5(blob)-$head6(submodule) (2): Add foo7 EOF -test_i18ncmp expected actual + test_i18ncmp expected actual commit_file sm1 rm -rf sm1 test_expect_success 'deleted submodule' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head6...000: EOF -test_cmp expected actual + test_cmp expected actual test_create_repo sm2 @@ -192,43 +192,43 @@ head7=$(add_file sm2 foo8 foo9) git add sm2 test_expect_success 'multiple submodules' -git submodule summary actual -cat expected -EOF + git submodule summary actual + cat expected -EOF * sm1 $head6...000: * sm2 000...$head7 (2): Add foo9 EOF -test_cmp expected actual + test_cmp expected actual test_expect_success 'path filter' -git submodule summary sm2 actual -cat expected -EOF + git submodule summary sm2 actual + cat expected -EOF * sm2 000...$head7 (2): Add foo9 EOF -test_cmp expected actual + test_cmp expected actual commit_file sm2 test_expect_success 'given commit' -git submodule summary HEAD^ actual -cat expected -EOF + git submodule summary HEAD^ actual + cat expected -EOF * sm1 $head6...000: * sm2 000...$head7 (2): Add foo9 EOF -test_cmp expected actual + test_cmp expected actual test_expect_success '--for-status' -git submodule summary --for-status HEAD^ actual -test_i18ncmp actual - EOF + git submodule summary --for-status HEAD^ actual + test_i18ncmp actual - EOF # Submodule changes to be committed: # # * sm1 $head6...000: @@ -240,14 +240,14 @@ EOF test_expect_success 'fail when using --files together with --cached' -test_must_fail git submodule summary --files --cached + test_must_fail git submodule summary --files --cached
[PATCH v4 0/6] submodule: drop the top-level requirement
Changes since v3: * There are four new patches, three of which are style fixes for existing tests and one fixes an existing error message to return a more accurate path when recursing. * You now cannot run git submodule add relative URL from a subdirectory. Because the interpretation of the URL changes depending on whether or not remote.origin.url is configured, I have decided to just ban this for now. If someone comes up with a sensible way to handle this then we can lift this restriction later. * The path variable exported in submodule foreach now uses the relative path and matches the sm_path variable. * I audited the code again and fixed a few more cases that weren't printing relative paths (notably submodule init and submodule foreach). * More tests. John Keeping (6): t7401: make indentation consistent t7403: modernize style t7403: add missing chaining submodule: show full path in error message rev-parse: add --prefix option submodule: drop the top-level requirement Documentation/git-rev-parse.txt | 16 ++ builtin/rev-parse.c | 24 ++- git-submodule.sh| 135 ++ t/t1513-rev-parse-prefix.sh | 96 ++ t/t7400-submodule-basic.sh | 80 + t/t7401-submodule-summary.sh| 116 +++- t/t7403-submodule-sync.sh | 388 ++-- t/t7406-submodule-update.sh | 15 ++ t/t7407-submodule-foreach.sh| 16 ++ 9 files changed, 673 insertions(+), 213 deletions(-) create mode 100755 t/t1513-rev-parse-prefix.sh -- 1.8.3.779.g691e267 -- 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 v4 2/6] t7403: modernize style
Change the indentation to use tabs consistently and start content on the line after the paren opening a subshell. Also don't put a space in file and remove : from : file to be consistent with the majority of tests elsewhere. Signed-off-by: John Keeping j...@keeping.me.uk --- t/t7403-submodule-sync.sh | 316 +++--- 1 file changed, 183 insertions(+), 133 deletions(-) diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh index 94e26c4..38f6cc4 100755 --- a/t/t7403-submodule-sync.sh +++ b/t/t7403-submodule-sync.sh @@ -11,216 +11,266 @@ These tests exercise the git submodule sync subcommand. . ./test-lib.sh test_expect_success setup ' - echo file file + echo file file git add file test_tick git commit -m upstream git clone . super git clone super submodule - (cd submodule -git submodule add ../submodule sub-submodule -test_tick -git commit -m sub-submodule + ( + cd submodule + git submodule add ../submodule sub-submodule + test_tick + git commit -m sub-submodule ) - (cd super -git submodule add ../submodule submodule -test_tick -git commit -m submodule + ( + cd super + git submodule add ../submodule submodule + test_tick + git commit -m submodule ) git clone super super-clone - (cd super-clone git submodule update --init --recursive) + ( + cd super-clone + git submodule update --init --recursive + ) git clone super empty-clone - (cd empty-clone git submodule init) + ( + cd empty-clone + git submodule init + ) git clone super top-only-clone git clone super relative-clone - (cd relative-clone git submodule update --init --recursive) + ( + cd relative-clone + git submodule update --init --recursive + ) git clone super recursive-clone - (cd recursive-clone git submodule update --init --recursive) + ( + cd recursive-clone + git submodule update --init --recursive + ) ' test_expect_success 'change submodule' ' - (cd submodule -echo second line file -test_tick -git commit -a -m change submodule + ( + cd submodule + echo second line file + test_tick + git commit -a -m change submodule ) ' test_expect_success 'change submodule url' ' - (cd super -cd submodule -git checkout master -git pull + ( + cd super + cd submodule + git checkout master + git pull ) mv submodule moved-submodule - (cd moved-submodule -git config -f .gitmodules submodule.sub-submodule.url ../moved-submodule -test_tick -git commit -a -m moved-sub-submodule + ( + cd moved-submodule + git config -f .gitmodules submodule.sub-submodule.url ../moved-submodule + test_tick + git commit -a -m moved-sub-submodule ) - (cd super -git config -f .gitmodules submodule.submodule.url ../moved-submodule -test_tick -git commit -a -m moved-submodule + ( + cd super + git config -f .gitmodules submodule.submodule.url ../moved-submodule + test_tick + git commit -a -m moved-submodule ) ' test_expect_success 'git submodule sync should update submodule URLs' ' - (cd super-clone -git pull --no-recurse-submodules -git submodule sync + ( + cd super-clone + git pull --no-recurse-submodules + git submodule sync ) - test -d $(cd super-clone/submodule -git config remote.origin.url + test -d $( + cd super-clone/submodule + git config remote.origin.url ) - test ! -d $(cd super-clone/submodule/sub-submodule -git config remote.origin.url + test ! -d $( + cd super-clone/submodule/sub-submodule + git config remote.origin.url ) - (cd super-clone/submodule -git checkout master -git pull + ( + cd super-clone/submodule + git checkout master + git pull ) - (cd super-clone -test -d $(git config submodule.submodule.url) + ( + cd super-clone + test -d $(git config submodule.submodule.url) ) ' test_expect_success 'git submodule sync --recursive
[PATCH v4 4/6] submodule: show full path in error message
When --recursive was added to submodule foreach in commit 15fc56a (git submodule foreach: Add --recursive to recurse into nested submodules, 2009-08-19), the error message when the script returns a non-zero status was not updated to contain $prefix to show the full path. Fix this. Signed-off-by: John Keeping j...@keeping.me.uk --- git-submodule.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index 79bfaac..bdb438b 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -485,7 +485,7 @@ cmd_foreach() cmd_foreach --recursive $@ fi ) 3 3- || - die $(eval_gettext Stopping at '\$sm_path'; script returned non-zero status.) + die $(eval_gettext Stopping at '\$prefix\$sm_path'; script returned non-zero status.) fi done } -- 1.8.3.779.g691e267 -- 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 v4 6/6] submodule: drop the top-level requirement
Use the new rev-parse --prefix option to process all paths given to the
submodule command, dropping the requirement that it be run from the
top-level of the repository.
Since the interpretation of a relative submodule URL depends on whether
or not remote.origin.url is configured, explicitly block relative URLs
in git submodule add when not at the top level of the working tree.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-submodule.sh | 135 ---
t/t7400-submodule-basic.sh | 80 +
t/t7401-submodule-summary.sh | 36
t/t7403-submodule-sync.sh| 72 +++
t/t7406-submodule-update.sh | 15 +
t/t7407-submodule-foreach.sh | 16 +
6 files changed, 319 insertions(+), 35 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index bdb438b..7756d81 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -14,10 +14,13 @@ USAGE=[--quiet] add [-b branch] [-f|--force] [--name
name] [--reference re
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
OPTIONS_SPEC=
+SUBDIRECTORY_OK=Yes
. git-sh-setup
. git-sh-i18n
. git-parse-remote
require_work_tree
+wt_prefix=$(git rev-parse --show-prefix)
+cd_to_toplevel
command=
branch=
@@ -106,12 +109,48 @@ resolve_relative_url ()
echo ${is_relative:+${up_path}}${remoteurl#./}
}
+# Resolve a path to be relative to another path. This is intended for
+# converting submodule paths when git-submodule is run in a subdirectory
+# and only handles paths where the directory separator is '/'.
+#
+# The output is the first argument as a path relative to the second argument,
+# which defaults to $wt_prefix if it is omitted.
+relative_path ()
+{
+ local target curdir result
+ target=$1
+ curdir=${2-$wt_prefix}
+ curdir=${curdir%/}
+ result=
+
+ while test -n $curdir
+ do
+ case $target in
+ $curdir/*)
+ target=${target#$curdir/}
+ break
+ ;;
+ esac
+
+ result=${result}../
+ if test $curdir = ${curdir%/*}
+ then
+ curdir=
+ else
+ curdir=${curdir%/*}
+ fi
+ done
+
+ echo $result$target
+}
+
#
# Get submodule info for registered submodules
# $@ = path to limit submodule list
#
module_list()
{
+ eval set $(git rev-parse --sq --prefix $wt_prefix -- $@)
(
git ls-files --error-unmatch --stage -- $@ ||
echo unmatched pathspec exists
@@ -282,6 +321,7 @@ isnumber()
cmd_add()
{
# parse $args after submodule ... add.
+ reference_path=
while test $# -ne 0
do
case $1 in
@@ -298,11 +338,11 @@ cmd_add()
;;
--reference)
case $2 in '') usage ;; esac
- reference=--reference=$2
+ reference_path=$2
shift
;;
--reference=*)
- reference=$1
+ reference_path=${1#--reference=}
;;
--name)
case $2 in '') usage ;; esac
@@ -323,6 +363,14 @@ cmd_add()
shift
done
+ if test -n $reference_path
+ then
+ is_absolute_path $reference_path ||
+ reference_path=$wt_prefix$reference_path
+
+ reference=--reference=$reference_path
+ fi
+
repo=$1
sm_path=$2
@@ -335,9 +383,14 @@ cmd_add()
usage
fi
+ is_absolute_path $sm_path || sm_path=$wt_prefix$sm_path
+
# assure repo is absolute or relative to parent
case $repo in
./*|../*)
+ test -z $wt_prefix ||
+ die $(gettext Relative path can only be used from the
toplevel of the working tree)
+
# dereference source url relative to parent's url
realrepo=$(resolve_relative_url $repo) || exit
;;
@@ -471,21 +524,23 @@ cmd_foreach()
die_if_unmatched $mode
if test -e $sm_path/.git
then
- say $(eval_gettext Entering '\$prefix\$sm_path')
+ displaypath=$(relative_path $sm_path)
+ say $(eval_gettext Entering '\$prefix\$displaypath')
name=$(module_name $sm_path)
(
prefix=$prefix$sm_path/
clear_local_git_env
- # we make $path available to scripts ...
- path=$sm_path
cd $sm_path
+
[PATCH v4 3/6] t7403: add missing chaining
Signed-off-by: John Keeping j...@keeping.me.uk --- t/t7403-submodule-sync.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh index 38f6cc4..bf90098 100755 --- a/t/t7403-submodule-sync.sh +++ b/t/t7403-submodule-sync.sh @@ -174,7 +174,7 @@ test_expect_success 'git submodule sync handles origin URL of the form foo/bar cd submodule #actual foo/submodule test $(git config remote.origin.url) = ../foo/submodule - ) + ) ( cd submodule/sub-submodule test $(git config remote.origin.url) != ../../foo/submodule @@ -191,7 +191,7 @@ test_expect_success 'git submodule sync --recursive propagates changes in orig cd submodule #actual foo/submodule test $(git config remote.origin.url) = ../foo/submodule - ) + ) ( cd submodule/sub-submodule test $(git config remote.origin.url) = ../../foo/submodule -- 1.8.3.779.g691e267 -- 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 v4 5/6] rev-parse: add --prefix option
This makes 'git rev-parse' behave as if it were invoked from the
specified subdirectory of a repository, with the difference that any
file paths which it prints are prefixed with the full path from the top
of the working tree.
This is useful for shell scripts where we may want to cd to the top of
the working tree but need to handle relative paths given by the user on
the command line.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Documentation/git-rev-parse.txt | 16 +++
builtin/rev-parse.c | 24 ---
t/t1513-rev-parse-prefix.sh | 96 +
3 files changed, 131 insertions(+), 5 deletions(-)
create mode 100755 t/t1513-rev-parse-prefix.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 947d62f..993903c 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -59,6 +59,22 @@ OPTIONS
If there is no parameter given by the user, use `arg`
instead.
+--prefix arg::
+ Behave as if 'git rev-parse' was invoked from the `arg`
+ subdirectory of the working tree. Any relative filenames are
+ resolved as if they are prefixed by `arg` and will be printed
+ in that form.
++
+This can be used to convert arguments to a command run in a subdirectory
+so that they can still be used after moving to the top-level of the
+repository. For example:
++
+
+prefix=$(git rev-parse --show-prefix)
+cd $(git rev-parse --show-toplevel)
+eval set -- $(git rev-parse --sq --prefix $prefix $@)
+
+
--verify::
Verify that exactly one parameter is provided, and that it
can be turned into a raw 20-byte SHA-1 that can be used to
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index f267a1d..de894c7 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -212,11 +212,17 @@ static void show_datestring(const char *flag, const char
*datestr)
show(buffer);
}
-static int show_file(const char *arg)
+static int show_file(const char *arg, int output_prefix)
{
show_default();
if ((filter (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV)) {
- show(arg);
+ if (output_prefix) {
+ const char *prefix = startup_info-prefix;
+ show(prefix_filename(prefix,
+prefix ? strlen(prefix) : 0,
+arg));
+ } else
+ show(arg);
return 1;
}
return 0;
@@ -470,6 +476,7 @@ N_(git rev-parse --parseopt [options] -- [args...]\n
int cmd_rev_parse(int argc, const char **argv, const char *prefix)
{
int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0;
+ int output_prefix = 0;
unsigned char sha1[20];
const char *name = NULL;
@@ -503,7 +510,7 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
const char *arg = argv[i];
if (as_is) {
- if (show_file(arg) as_is 2)
+ if (show_file(arg, output_prefix) as_is 2)
verify_filename(prefix, arg, 0);
continue;
}
@@ -527,7 +534,7 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
as_is = 2;
/* Pass on the -- if we show anything but
files.. */
if (filter (DO_FLAGS | DO_REVS))
- show_file(arg);
+ show_file(arg, 0);
continue;
}
if (!strcmp(arg, --default)) {
@@ -535,6 +542,13 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
i++;
continue;
}
+ if (!strcmp(arg, --prefix)) {
+ prefix = argv[i+1];
+ startup_info-prefix = prefix;
+ output_prefix = 1;
+ i++;
+ continue;
+ }
if (!strcmp(arg, --revs-only)) {
filter = ~DO_NOREV;
continue;
@@ -754,7 +768,7 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
if (verify)
die_no_single_rev(quiet);
as_is = 1;
- if (!show_file(arg))
+ if (!show_file(arg, output_prefix))
continue;
verify_filename(prefix, arg, 1);
}
diff --git a/t/t1513-rev-parse-prefix.sh b/t/t1513-rev-parse-prefix.sh
new file mode 100755
index 000..87ec3ae
---
[PATCH 1/2] Documentation/Makefile: fix spaces around assignments
A simple style fix; no functional change. Signed-off-by: John Keeping j...@keeping.me.uk --- Nothing in maint..pu is touching this at the moment, so hopefully this is a good time to fix the whitespace here. Documentation/Makefile | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 62dbd9a..af3d8a4 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -31,11 +31,11 @@ MAN7_TXT += gittutorial.txt MAN7_TXT += gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) -MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) -MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) +MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) +MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) OBSOLETE_HTML = git-remote-helpers.html -DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML) +DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) ARTICLES = howto-index ARTICLES += everyday @@ -74,35 +74,35 @@ SP_ARTICLES += technical/api-index DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) -DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT)) -DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT)) -DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT)) +DOC_MAN1 = $(patsubst %.txt,%.1,$(MAN1_TXT)) +DOC_MAN5 = $(patsubst %.txt,%.5,$(MAN5_TXT)) +DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT)) -prefix?=$(HOME) -bindir?=$(prefix)/bin -htmldir?=$(prefix)/share/doc/git-doc -pdfdir?=$(prefix)/share/doc/git-doc -mandir?=$(prefix)/share/man -man1dir=$(mandir)/man1 -man5dir=$(mandir)/man5 -man7dir=$(mandir)/man7 -# DESTDIR= +prefix ?= $(HOME) +bindir ?= $(prefix)/bin +htmldir ?= $(prefix)/share/doc/git-doc +pdfdir ?= $(prefix)/share/doc/git-doc +mandir ?= $(prefix)/share/man +man1dir = $(mandir)/man1 +man5dir = $(mandir)/man5 +man7dir = $(mandir)/man7 +# DESTDIR = ASCIIDOC = asciidoc ASCIIDOC_EXTRA = MANPAGE_XSL = manpage-normal.xsl XMLTO = xmlto XMLTO_EXTRA = -INSTALL?=install +INSTALL ?= install RM ?= rm -f MAN_REPO = ../../git-manpages HTML_REPO = ../../git-htmldocs -infodir?=$(prefix)/share/info -MAKEINFO=makeinfo -INSTALL_INFO=install-info -DOCBOOK2X_TEXI=docbook2x-texi -DBLATEX=dblatex +infodir ?= $(prefix)/share/info +MAKEINFO = makeinfo +INSTALL_INFO = install-info +DOCBOOK2X_TEXI = docbook2x-texi +DBLATEX = dblatex ifndef PERL_PATH PERL_PATH = /usr/bin/perl endif -- 1.8.3.779.g691e267 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Documentation/Makefile: move infodir to be with other '*dir's
Signed-off-by: John Keeping j...@keeping.me.uk --- Documentation/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index af3d8a4..0cfdc36 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -81,6 +81,7 @@ DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT)) prefix ?= $(HOME) bindir ?= $(prefix)/bin htmldir ?= $(prefix)/share/doc/git-doc +infodir ?= $(prefix)/share/info pdfdir ?= $(prefix)/share/doc/git-doc mandir ?= $(prefix)/share/man man1dir = $(mandir)/man1 @@ -98,7 +99,6 @@ RM ?= rm -f MAN_REPO = ../../git-manpages HTML_REPO = ../../git-htmldocs -infodir ?= $(prefix)/share/info MAKEINFO = makeinfo INSTALL_INFO = install-info DOCBOOK2X_TEXI = docbook2x-texi -- 1.8.3.779.g691e267 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/3] enable color prompt in non-pcmode
The use of colors in a prompt is only possible in pcmode (using the variable PROMPT_COMMAND). Make color prompt work in non-pcmode (using the variable PS1) for both Bash and ZSH. This requires editing __git_ps1() and __git_ps1_colorize_gitstring(), which have duplicate code to handle the prompt gitstring and color codes. Prior to enable colors in non-pcmode, refactor __git_ps1() and __git_ps1_colorize_gitstring(). Eduardo R. D'Avila (3): t9903: add tests for git-prompt pcmode git-prompt.sh: refactor colored prompt code git-prompt.sh: enable color prompt in non-pcmode contrib/completion/git-prompt.sh | 91 + t/t9903-bash-prompt.sh | 269 +++ 2 files changed, 301 insertions(+), 59 deletions(-) -- 1.8.3.1.440.g82707f8 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 2/3] git-prompt.sh: refactor colored prompt code
Remove duplication of logic to build gitstring.
__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.
Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring() and __git_ps1().
Leave in __git_ps1_colorize_gitstring() only logic
to set color codes.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
26 59 contrib/completion/git-prompt.sh
6 6 t/t9903-bash-prompt.sh
contrib/completion/git-prompt.sh | 85
t/t9903-bash-prompt.sh | 12 +++---
2 files changed, 32 insertions(+), 65 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 86a4f3f..70515cc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -225,8 +225,8 @@ __git_ps1_show_upstream ()
}
# Helper function that is meant to be called from __git_ps1. It
-# builds up a gitstring injecting color codes into the appropriate
-# places.
+# injects color codes into the appropriate gitstring variables used
+# to build a gitstring.
__git_ps1_colorize_gitstring ()
{
if [[ -n ${ZSH_VERSION-} ]]; then
@@ -234,74 +234,40 @@ __git_ps1_colorize_gitstring ()
local c_green='%F{green}'
local c_lblue='%F{blue}'
local c_clear='%f'
- local bad_color=$c_red
- local ok_color=$c_green
- local branch_color=$c_clear
- local flags_color=$c_lblue
- local branchstring=$c${b##refs/heads/}
-
- if [ $detached = no ]; then
- branch_color=$ok_color
- else
- branch_color=$bad_color
- fi
-
- gitstring=$branch_color$branchstring$c_clear
-
- if [ -n $w$i$s$u$r$p ]; then
- gitstring=$gitstring$z
- fi
- if [ $w = * ]; then
- gitstring=$gitstring$bad_color$w
- fi
- if [ -n $i ]; then
- gitstring=$gitstring$ok_color$i
- fi
- if [ -n $s ]; then
- gitstring=$gitstring$flags_color$s
- fi
- if [ -n $u ]; then
- gitstring=$gitstring$bad_color$u
- fi
- gitstring=$gitstring$c_clear$r$p
- return
+ else
+ # Using \[ and \] around colors
+ # is necessary to prevent wrapping issues!
+ local c_red='\[\e[31m\]'
+ local c_green='\[\e[32m\]'
+ local c_lblue='\[\e[1;34m\]'
+ local c_clear='\[\e[0m\]'
fi
- local c_red='\e[31m'
- local c_green='\e[32m'
- local c_lblue='\e[1;34m'
- local c_clear='\e[0m'
local bad_color=$c_red
local ok_color=$c_green
- local branch_color=$c_clear
local flags_color=$c_lblue
- local branchstring=$c${b##refs/heads/}
+ local branch_color=
if [ $detached = no ]; then
branch_color=$ok_color
else
branch_color=$bad_color
fi
+ c=$branch_color$c
- # Setting gitstring directly with \[ and \] around colors
- # is necessary to prevent wrapping issues!
- gitstring=\[$branch_color\]$branchstring\[$c_clear\]
-
- if [ -n $w$i$s$u$r$p ]; then
- gitstring=$gitstring$z
- fi
+ z=$c_clear$z
if [ $w = * ]; then
- gitstring=$gitstring\[$bad_color\]$w
+ w=$bad_color$w
fi
if [ -n $i ]; then
- gitstring=$gitstring\[$ok_color\]$i
+ i=$ok_color$i
fi
if [ -n $s ]; then
- gitstring=$gitstring\[$flags_color\]$s
+ s=$flags_color$s
fi
if [ -n $u ]; then
- gitstring=$gitstring\[$bad_color\]$u
+ u=$bad_color$u
fi
- gitstring=$gitstring\[$c_clear\]$r$p
+ r=$c_clear$r
}
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
@@ -443,19 +409,20 @@ __git_ps1 ()
fi
local z=${GIT_PS1_STATESEPARATOR- }
+
+ # NO color option unless in PROMPT_COMMAND mode
+ if [ $pcmode = yes ] [ -n ${GIT_PS1_SHOWCOLORHINTS-} ];
then
+ __git_ps1_colorize_gitstring
+ fi
+
local f=$w$i$s$u
+ local gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
+
if [ $pcmode = yes ]; then
- local gitstring=
- if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
- __git_ps1_colorize_gitstring
- else
-
[PATCH/RFC 3/3] git-prompt.sh: enable color prompt in non-pcmode
The use of colors in a prompt is only possible in
pcmode (using the variable PROMPT_COMMAND).
Enable color prompt in non-pcmode (using the variable
PS1) for both Bash and ZSH.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
15 9 contrib/completion/git-prompt.sh
19 0 t/t9903-bash-prompt.sh
contrib/completion/git-prompt.sh | 24 +++-
t/t9903-bash-prompt.sh | 19 +++
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 70515cc..c5c75e7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -13,7 +13,7 @@
#3a) Change your PS1 to call __git_ps1 as
#command-substitution:
#Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
-#ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#ZSH: setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
#the optional argument will be used as format string.
#3b) Alternatively, if you are using bash, __git_ps1 can be
#used for PROMPT_COMMAND with two parameters, pre and
@@ -235,12 +235,18 @@ __git_ps1_colorize_gitstring ()
local c_lblue='%F{blue}'
local c_clear='%f'
else
- # Using \[ and \] around colors
- # is necessary to prevent wrapping issues!
- local c_red='\[\e[31m\]'
- local c_green='\[\e[32m\]'
- local c_lblue='\[\e[1;34m\]'
- local c_clear='\[\e[0m\]'
+ local c_red='\e[31m'
+ local c_green='\e[32m'
+ local c_lblue='\e[1;34m'
+ local c_clear='\e[0m'
+ if [ $pcmode = yes ]; then
+ # Using \[ and \] around colors
+ # is necessary to prevent wrapping issues!
+ c_red=\[$c_red\]
+ c_green=\[$c_green\]
+ c_lblue=\[$c_lblue\]
+ c_clear=\[$c_clear\]
+ fi
fi
local bad_color=$c_red
local ok_color=$c_green
@@ -411,7 +417,7 @@ __git_ps1 ()
local z=${GIT_PS1_STATESEPARATOR- }
# NO color option unless in PROMPT_COMMAND mode
- if [ $pcmode = yes ] [ -n ${GIT_PS1_SHOWCOLORHINTS-} ];
then
+ if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
__git_ps1_colorize_gitstring
fi
@@ -422,7 +428,7 @@ __git_ps1 ()
gitstring=$(printf -- $printf_format $gitstring)
PS1=$ps1pc_start$gitstring$ps1pc_end
else
- printf -- $printf_format $gitstring
+ printf -- ${printf_format//%s/%b} $gitstring
fi
fi
}
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 22484c1..63abc72 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -785,4 +785,23 @@ test_expect_success 'prompt - zsh color pc mode -
untracked files status indicat
test_cmp expected $actual
'
+test_expect_success 'prompt - bash color ps1 mode - untracked files status
indicator' '
+ printf (\e[32mmaster\e[0m) expected
+ (
+ GIT_PS1_SHOWCOLORHINTS=y
+ __git_ps1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - zsh color ps1 mode - untracked files status
indicator' '
+ printf (%%F{green}master%%f) expected
+ (
+ GIT_PS1_SHOWCOLORHINTS=y
+ ZSH_VERSION=5.0.0
+ __git_ps1 $actual
+ )
+ test_cmp expected $actual
+'
+
test_done
--
1.8.3.1.440.g82707f8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/3] t9903: add tests for git-prompt pcmode
git-prompt.sh lacks tests for PROMPT_COMMAND mode. Add tests for: * pcmode prompt without colors * pcmode prompt with colors for bash * pcmode prompt with colors for zsh Having these tests enables an upcoming refactor in a safe way. Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com --- 250 0 t/t9903-bash-prompt.sh t/t9903-bash-prompt.sh | 250 + 1 file changed, 250 insertions(+) diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index 15521cc..ebca9de 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -535,4 +535,254 @@ test_expect_success 'prompt - format string starting with dash' ' test_cmp expected $actual ' +test_expect_success 'prompt - pc mode' ' + printf BEFORE: (master):AFTER expected + printf expected_output + ( + __git_ps1 BEFORE: :AFTER $actual + test_cmp expected_output $actual + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - branch name' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER expected + ( + GIT_PS1_SHOWCOLORHINTS=y + __git_ps1 BEFORE: :AFTER $actual + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - detached head' ' + printf BEFORE: (\\\[\\\e[31m\\\](%s...)\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER $(git log -1 --format=%h b1^) expected + git checkout b1^ + test_when_finished git checkout master + ( + GIT_PS1_SHOWCOLORHINTS=y + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\] \\\[\\\e[31m\\\]*\\\[\\\e[0m\\\]):AFTER expected + echo dirty file + test_when_finished git reset --hard + ( + GIT_PS1_SHOWDIRTYSTATE=y + GIT_PS1_SHOWCOLORHINTS=y + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\] \\\[\\\e[32m\\\]+\\\[\\\e[0m\\\]):AFTER expected + echo dirty file + test_when_finished git reset --hard + git add -u + ( + GIT_PS1_SHOWDIRTYSTATE=y + GIT_PS1_SHOWCOLORHINTS=y + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\] \\\[\\\e[31m\\\]*\\\[\\\e[32m\\\]+\\\[\\\e[0m\\\]):AFTER expected + echo dirty index file + test_when_finished git reset --hard + git add -u + echo dirty worktree file + ( + GIT_PS1_SHOWCOLORHINTS=y + GIT_PS1_SHOWDIRTYSTATE=y + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\] \\\[\\\e[32m\\\]#\\\[\\\e[0m\\\]):AFTER expected + ( + GIT_PS1_SHOWDIRTYSTATE=y + GIT_PS1_SHOWCOLORHINTS=y + cd otherrepo + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - inside .git directory' ' + printf BEFORE: (\\\[\\\e[32m\\\]GIT_DIR!\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER expected + echo dirty file + test_when_finished git reset --hard + ( + GIT_PS1_SHOWDIRTYSTATE=y + GIT_PS1_SHOWCOLORHINTS=y + cd .git + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color pc mode - stash status indicator' ' + printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\] \\\[\\\e[1;34m\\\]$\\\[\\\e[0m\\\]):AFTER expected + echo 2 file + git stash + test_when_finished git stash drop + ( + GIT_PS1_SHOWSTASHSTATE=y + GIT_PS1_SHOWCOLORHINTS=y + __git_ps1 BEFORE: :AFTER + printf %s $PS1 $actual + ) + test_cmp expected $actual +' + +test_expect_success 'prompt - bash color
[PATCH] mergetool--lib: refactor {diff,merge}_cmd logic
Instead of needing a wrapper to call the diff/merge command, simply
provide the diff_cmd and merge_cmd functions for user-specified tools in
the same way as we do for built-in tools.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 82 ++-
1 file changed, 35 insertions(+), 47 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index e338be5..6a72106 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -114,6 +114,33 @@ valid_tool () {
test -n $cmd
}
+setup_user_tool () {
+ merge_tool_cmd=$(get_merge_tool_cmd $tool)
+ test -n $merge_tool_cmd || return 1
+
+ diff_cmd () {
+ ( eval $merge_tool_cmd )
+ status=$?
+ return $status
+ }
+
+ merge_cmd () {
+ trust_exit_code=$(git config --bool \
+ mergetool.$1.trustExitCode || echo false)
+ if test $trust_exit_code = false
+ then
+ touch $BACKUP
+ ( eval $merge_tool_cmd )
+ status=$?
+ check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ return $status
+ }
+}
+
setup_tool () {
tool=$1
@@ -142,15 +169,15 @@ setup_tool () {
if ! test -f $MERGE_TOOLS_DIR/$tool
then
- # Use a special return code for this case since we want to
- # source defaults even when an explicit tool path is
- # configured since the user can use that to override the
- # default path in the scriptlet.
- return 2
+ setup_user_tool
+ return $?
fi
# Load the redefined functions
. $MERGE_TOOLS_DIR/$tool
+ # Now let the user override the default command for the tool. If
+ # they have not done so then this will return 1 which we ignore.
+ setup_user_tool
if merge_mode ! can_merge
then
@@ -187,20 +214,7 @@ run_merge_tool () {
status=0
# Bring tool-specific functions into scope
- setup_tool $1
- exitcode=$?
- case $exitcode in
- 0)
- :
- ;;
- 2)
- # The configured tool is not a built-in tool.
- test -n $merge_tool_path || return 1
- ;;
- *)
- return $exitcode
- ;;
- esac
+ setup_tool $1 || return 1
if merge_mode
then
@@ -213,38 +227,12 @@ run_merge_tool () {
# Run a either a configured or built-in diff tool
run_diff_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -n $merge_tool_cmd
- then
- ( eval $merge_tool_cmd )
- status=$?
- return $status
- else
- diff_cmd $1
- fi
+ diff_cmd $1
}
# Run a either a configured or built-in merge tool
run_merge_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -n $merge_tool_cmd
- then
- trust_exit_code=$(git config --bool \
- mergetool.$1.trustExitCode || echo false)
- if test $trust_exit_code = false
- then
- touch $BACKUP
- ( eval $merge_tool_cmd )
- status=$?
- check_unchanged
- else
- ( eval $merge_tool_cmd )
- status=$?
- fi
- return $status
- else
- merge_cmd $1
- fi
+ merge_cmd $1
}
list_merge_tool_candidates () {
--
1.8.3.779.g691e267
--
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] config doc: rewrite push.default section
Ramkumar Ramachandra artag...@gmail.com writes: +* `current` - push the refspec $HEAD. HEAD is resolved early to a + branch name (referred to as $HEAD). In other words, push the + current branch to update a branch with the same name on the pushing + side. I'd put it the other way around: the intuitive explanation first, and the technical one after. For people not totally familiar with Git, the first part does not make much sense (and when I learn a new tool, I really don't like when the doc assumes I already know too much about it). Also, this $HEAD Vs HEAD doesn't seem very clear to me. I don't have a really good proposal for a better wording, but maybe replacing $HEAD with $branch would make a bit more sense, as having $HEAD != HEAD is weird. +* `simple` - in central workflows, behaves like `upstream`, except + that it errors out unless branch.$HEAD.merge is equal to $HEAD. I'd reverse the sentense too. In your wording, I get the feeling that erroring out is the normal flow, and pushing is the exception (unless). ... except that it errors out if branch.$HEAD.merge is not equal to $HEAD. ? + single command. Dangerous, and inappropriate unless you are the + only person updating your push destination. Here also, I'd have said Dangerous, and inappropriate if you are not -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] git-mw: Adding git-mw.perl script
Benoît Person benoit.per...@ensimag.fr writes: I think you need an equivalent of Git's toplevel bin-wrappers/git, or perhaps use the same bin-wrapper/git but let make install in contrib/mw-to-git/ install GitMediawiki.pm in perl/blib/lib Typo s/make install/make/ ? Yes. For that one, I am not really sure Git::Mediawiki makes more sense than GitMediawiki. The point of the GitMediawiki.pm package is to contain all the stuff for the bidirectionnal-thingy. So they are not really Git-related, nor Mediawiki-related. I'd say they are related to both, not to neither. Making it part of a Git directory / namespace does not really feels right, even if it's how it's done for SVN :/ . Well, it's the part of Git's perl library which deals with SVN interaction, so it makes sense to have it be a subdirectory of Git. I'd say it makes as much sense for Mediawiki interaction. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 V3 1/4] git-mw: Introduction of GitMediawiki.pm
benoit.per...@ensimag.fr writes: changes from the V2: - Add a way to test, without installation, code that uses GitMediawiki.pm. This still needs to be documented, even very quickly, somewhere in the code (e.g a comment in the Makefile). -build install clean: +copy_pm: + cp $(GIT_MEDIAWIKI_PM) $(GIT_ROOT_DIR)/perl/blib/lib/ I already commented on this: http://thread.gmane.org/gmane.comp.version-control.git/227711/focus=227721 Also, it seems to be only part of the solution. With your change, from contrib/mw-to-git/ and after running only make, ./git-mw takes the installed version of GitMediawiki.pm in priority ../../bin-wrappers/git takes the installed version of git-mw only (i.e. does not know git mw if make install hasn't been ran). perlcritic: - perlcritic -2 *.perl + perlcritic -2 *.perl \ No newline at end of file Please, avoid these whitespace-only changes. They create noise during review, and more potential conflicts. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] git-remote-mediawiki: push-by-rev
From: Célestin Matte celestin.ma...@ensimag.fr This patch intends to introduce the by_rev strategy for the push command, as already available for the fetch one. This uses subroutines used by the fetch-by-rev strategy. I'm not sure it's actually complete: can it be that simple? However, I tested on a local wiki and it seemed to work perfectly. Should I add associate tests? Célestin Matte (1): git-remote-mediawiki: push-by-rev contrib/mw-to-git/git-remote-mediawiki.perl | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) -- 1.8.3.1.522.gd761f2b.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 RFC] git-remote-mediawiki: push-by-rev
From: Célestin Matte celestin.ma...@ensimag.fr
Add the push-by-rev option
This allows one to look for changes by revision instead of by page.
The result is a much faster push on little-activity wikis. Indeed, instead of
sending one request by page to check that the remote revision is our local
latest revision, we only send one request for every new local revision.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 9ff45fd..fa49882 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -102,6 +102,15 @@ if (!$fetch_strategy) {
$fetch_strategy = 'by_page';
}
+my $push_strategy = run_git(config --get remote.${remotename}.pushStrategy);
+if (!$push_strategy) {
+ $push_strategy = run_git('config --get mediawiki.pushStrategy');
+}
+chomp($push_strategy);
+if (!$push_strategy) {
+ $push_strategy = 'by_page';
+}
+
# Remember the timestamp corresponding to a revision id.
my %basetimestamps;
@@ -512,7 +521,7 @@ sub get_last_local_revision {
# Get the last remote revision without taking in account which pages are
# tracked or not. This function makes a single request to the wiki thus
# avoid a loop onto all tracked pages. This is useful for the fetch-by-rev
-# option.
+# and the push-by-rev options.
sub get_last_global_remote_rev {
mw_connect_maybe();
@@ -1160,8 +1169,19 @@ sub mw_push_revision {
my $local = shift;
my $remote = shift; # actually, this has to be refs/heads/master at
this point.
my $last_local_revid = get_last_local_revision();
+ my $last_remote_revid;
print {*STDERR} .\n; # Finish sentence started by
get_last_local_revision()
- my $last_remote_revid = get_last_remote_revision();
+ if ($push_strategy eq 'by_page') {
+ print {*STDERR} Pushing export data by pages...\n;
+ $last_remote_revid = get_last_remote_revision();
+ } elsif ($push_strategy eq 'by_rev') {
+ print {*STDERR} Pushing export data by revs...\n;
+ $last_remote_revid = get_last_global_remote_rev();
+ } else {
+ print {*STDERR} qq(fatal: invalid push strategy
${push_strategy}.\n);
+ print {*STDERR} Check your configuration variables
remote.${remotename}.pushStrategy and mediawiki.pushStrategy\n;
+ exit 1;
+ }
my $mw_revision = $last_remote_revid;
# Get sha1 of commit pointed by local HEAD
--
1.8.3.1.522.gd761f2b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 4/4] git-mw: Add preview subcommand into git mw.
[ Just a quick look, no time for a detailed review ]
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
Add the subcommand to 'git-mw.perl'.
That's already said in the Subject field.
Add a new constant in GitMediawiki.pm 'HTTP_CODE_PAGE_NOT_FOUND'.
And this brings zero information compared to
--- a/contrib/mw-to-git/GitMediawiki.pm
+++ b/contrib/mw-to-git/GitMediawiki.pm
- EMPTY HTTP_CODE_OK);
+ EMPTY HTTP_CODE_OK HTTP_CODE_PAGE_NOT_FOUND);
I'd say your commit messages looks like a GNU-style changelog entry,
which I do not consider a compliment ;-).
Still, after removing rendundant information, you may notice that the
reader has no idea what preview is or does, and *why* it is a good
thing to have it. How about:
In the current state, a user of git-remote-mediawiki can edit the markup
text locally, but has to push to the remote wiki to see how the page is
rendered. Add a new git mw preview command that allows rendering the
markup text on the remote wiki without actually doing any change on the
wiki.
This uses MediaWiki's API to render the markup, and inserts the result
in an actual HTML page from the wiki so that CSS be rendered properly.
?
(The first paragraph answers *why* did you do this? and the second
*why* did you do it this way?)
(did I put enough emphasis on the why? ;-) )
+ # file_name argumeent is mandatory
argumeent - argument
+ if (!defined $file_name) {
+ die File not set, see `git mw help` \n;
Perhaps missing file argument?
+ # Search all possibles mediawiki remotes
+ if (! $remote_url) {
The why thing about commit message also applies to comments: when you
start saying what you're doing in a comment, it usually means your code
should be refactored.
Wouldn't it better to add a function here? The name of the function
would probably carry the same information as the comment.
+ print {*STDERR} do you want ? Use the -r
option to specify the remote\n;
Missing period (.).
+ }) or die No response from distant mediawiki\n;
distant - remote.
+ $template_content_id = Git::config('mediawiki.IDContent')
+ || $template_content_id;
It would be cool to have also remote.name.IDContent or something like
this in case you have several remotes with different div ids. But this
can be added later.
@@ -41,6 +341,7 @@ usage: git mw command args
git mw commands are:
helpDisplay help information about git mw
+preview Parse and render local file into HTML
Space/tab mix after preview.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] git-remote-mediawiki: push-by-rev
Célestin Matte celestin.ma...@ensimag.fr writes:
This uses subroutines used by the fetch-by-rev strategy. I'm not sure it's
actually complete: can it be that simple?
The function says:
# Get the last remote revision without taking in account which pages are
# tracked or not. This function makes a single request to the wiki thus
# avoid a loop onto all tracked pages. This is useful for the fetch-by-rev
# option.
sub get_last_global_remote_rev {
...
So I don't think this would work when you track only a subset of pages.
If an untracked page has been modified, then the global last revision
has increased and you'll get a non-fast forward. If you try to pull,
it'll tell you there's nothing to import.
You'd have to iterate through revisions between the one given by
get_last_global_remote_rev and the last one the local repo knows about,
and remove ones touching untracked pages from the list.
However, I tested on a local wiki and it seemed to work perfectly.
Should I add associate tests?
See what t/t9364-pull-by-rev.sh does. You can set pushStrategy too in
the same file (this won't test all push/pull combinations, but push and
pull should be independant enough, so testing both unset and both set
should be enough).
Not sure we have enough test for push with a subset of pages though.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: English/German terminology, git.git's de.po, and pro-git
On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:
Not sure if German users would know what hunk means, in case we
leave it untranslated. And I'm not sure if I would understand Kontext.
I tend to leave it untranslated.
Anyone found a German translation of the Patch manpage? Translating the
English word-play here, I'd suggest Block or Patch-Block.
Hunk is like a chunk, and the dictionary offers some fun too:
dickes Stück; Brocken {m} :: chunk
(Holz)klotz {m} :: chunk (of wood)
and that is what many patches feel like indeed, especially
when they generate rejects :)
--
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 V3 1/4] git-mw: Introduction of GitMediawiki.pm
On 16 June 2013 22:18, Matthieu Moy matthieu@grenoble-inp.fr wrote: benoit.per...@ensimag.fr writes: changes from the V2: - Add a way to test, without installation, code that uses GitMediawiki.pm. This still needs to be documented, even very quickly, somewhere in the code (e.g a comment in the Makefile). Well, I think I will have to re-read some docs (and some earlier reviews) about what to write in commit messages, in the emails, in the code as comments and in the documentation ... I am just totally lost right now :/ . -build install clean: +copy_pm: + cp $(GIT_MEDIAWIKI_PM) $(GIT_ROOT_DIR)/perl/blib/lib/ I already commented on this: http://thread.gmane.org/gmane.comp.version-control.git/227711/focus=227721 Oops, I forgot that one, so sorry :/ . Also, it seems to be only part of the solution. With your change, from contrib/mw-to-git/ and after running only make, ./git-mw takes the installed version of GitMediawiki.pm in priority ../../bin-wrappers/git takes the installed version of git-mw only (i.e. does not know git mw if make install hasn't been ran). Same thing as the documentation point, I think I am a bit lost in that whole thing. I will re-look into it for the next version :/ . perlcritic: - perlcritic -2 *.perl + perlcritic -2 *.perl \ No newline at end of file Please, avoid these whitespace-only changes. They create noise during review, and more potential conflicts. For that one, I don't know why git assumes there is a change in it : from what I see there is absolutely no whitespaces changes but maybe my editor added some weird character somewhere ? I will look into that for the next version ... Thank you, Benoit Person -- 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
[RFC] speed up git submodule
I've been playing a bit with lua. It's an embedded scripting language
with strong c integration. It's small and fast.
The interesting feature would be to run C-functions direct inside lua. I
suppose that would increase speed even more, at the same time as we have
the convinence of a interpreted language. Lua is smaller and faster
(well as always, it depends on what you're doing) than python and ruby.
Perl is a really pain for the windows folks (I've heard).
A correct implementation for lua support would be to start a
lua-interpreter from inside git.c (or somewhere) and load the lua code
for a specific command. That would make us independent of any target
installation of lua (althought the git binary would increase with the
lua library around 300 kb).
However I did a quick test using lua as a replacement for sh (without
direct calls to c-functions) and the result is impressive. (However this
is the wrong way of using lua, shell scripting is not something lua is
good at).
I did some runs on a project with 52 submodules (or 53 if you count the
ones in .gitmodules). These results are pretty typical:
iveqy@kolya:~/projects/eracle_core$ time
/home/iveqy/projects/git/git-submodule.lua /dev/null
real0m1.665s
user0m0.276s
sys 0m0.452s
iveqy@kolya:~/projects/eracle_core$ time git submodule /dev/null
real0m3.413s
user0m0.476s
sys 0m1.224s
For me, that speedup does matter.
NOTICE!!!
This code is experimental. It does have some known bugs, it does have
some style issues. A state of the art complete implementation would
contain a few more tests/jumps and less concat (which is extremely
expensive in lua) and less git-invokation.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
git-submodule.lua | 104 ++
1 file changed, 104 insertions(+)
create mode 100755 git-submodule.lua
diff --git a/git-submodule.lua b/git-submodule.lua
new file mode 100755
index 000..14f71e6
--- /dev/null
+++ b/git-submodule.lua
@@ -0,0 +1,104 @@
+#!/usr/bin/lua
+
+function run_cmd(cmd)
+ local f = io.popen(cmd, 'r');
+ local out = f:read('*a');
+ f:close()
+ return out
+end
+
+function fwrite(fmt, ...)
+ return io.write(string.format(fmt, ...))
+end
+
+function read_gitmodules()
+ local inf = assert(io.open('.gitmodules', 'r'))
+ local config = inf:read(*all)
+ gitmodules = {}
+ for sm in string.gmatch(config, '%[[^]]*%][^%[]*') do
+ local thismod = {}
+ local name = string.match(sm, '%[%s-submodule%s-(.+)%s-%]')
+ thismod[name] = name
+ local path = ''
+ for k, v in string.gmatch(sm, '\n%s*([^=^%s]*)%s*=%s*([^\n]*)')
do
+ if k == 'path' then
+ path = v
+ else
+ thismod[k] = v
+ end
+ end
+ if path == '' then
+ fwrite(No path found for %s in .gitmodules\n, name)
+ os.exit(1)
+ end
+ gitmodules[path] = thismod
+ end
+
+ return gitmodules
+end
+
+function module_list()
+ local lsfiles = 'git ls-files --stage --error-unmatch -z || echo
#unmatched'
+ local out = run_cmd(lsfiles)
+ local unmerged = ''
+ local subs = read_gitmodules()
+
+ for row in string.gmatch(out, '.-\0') do
+ if row == '#unmatched' then
+ os.exit(1)
+ end
+
+ local mode, sha1, stage, path = string.match(row,
'(%d+)%s([0-9a-f]+)%s(.)%s(.*)\0')
+ if mode == '16' then
+ if stage == '0' then
+ subs[path][sha1] = sha1
+ subs[path][stage] = stage
+ else
+ if unmerged ~= path then
+ local null_sha1 =
''
+ subs[path][sha1] = null_sha1
+ subs[path][stage] = 'U'
+ end
+ unmerged = path
+ end
+ end
+ end
+ return subs
+end
+
+function get_name_rev(path, sha1)
+ if sha1 == nil then sha1= end
+ local cmd = cd \ .. path .. \ (git describe .. sha1 ..
+2/dev/null || git describe --tags .. sha1
..
+2/dev/null || git describe --contains ..
sha1 ..
+2/dev/null || git describe --all --always
.. sha1 ..
+2/dev/null)
+ return string.gsub(run_cmd(cmd), '\n', '')
+end
+
+function cmd_status()
+ subs = module_list()
+ for smpath in pairs(subs) do
+ if (subs[smpath].sha1)
Re: [PATCH] rebase -i: fixup fixup! fixup!
Thomas Rast tr...@inf.ethz.ch writes: Isn't it a bit of an academic question? ... And once you have that, it seems a nicer and cleaner idea to generate 'fixup! A' each time, instead of a successive sequence of fixup! A fixup! fixup! A fixup! fixup! fixup! A ... As to reordering, you are absolutely correct. If you are going to apply all three anyway, then the end result either does not change at all (when none of them overlap textually), or you will end up with unnecessary conflicts (when they do). But if you were to pick (and drop some), all three labeled with fixup A vs later ones having more fixup in front will make a difference in identification and usability. When you want to drop the second fixup, fixup fixup A can be chosen unambiguously in your editor among fixup A, fixup fixup A and fixup fixup fixup A. It also somewhat feels wrong when the user sees this: $ git log --oneline -2 A fixup! A and asks to do this: $ git commit --fixup and if you end up with fixup! A, not fixup! fixup! A. The user is asking to follow-up on the fixup! A, not on the original A. Does dropping these leading fixup! (or squash!) at commit time make the application in rebase -i --autosquash significantly easier to do? -- 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 v3 1/2] am: handle stray $dotest directory
Ramkumar Ramachandra artag...@gmail.com writes: else + # Possible stray $dotest directory in the independent-run + # case; in the --rebasing case, it is upto the caller + # (git-rebase--am) to take care of stray directories. + if test -d $dotest test -z $rebasing The $rebasing variable is set only when the command line of git am has --rebasing, i.e. only when it is driven by git rebase. So this will not affect what happens to git am --abort that is run by the end user. That sounds like a safe thing to do as far as am is concerned. Will replace what has been queued on '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 3/3] rebase: use peel_committish() where appropriate
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: You can also specify the commit at the end of the history to be rebased (very useful while trial runs to see where a series should apply): git rebase foo :/Add B This is already handled properly because it first gets turned into an object name $orig_head and then we use it (without ^0) to update the ORIG_HEAD. Correct, but what sense does it make unless branch is a ref to update? It often is necessary, after applying a patch series that was prepared against commit that is unnecessarily new (e.g. a bugfix that should apply to 'maint' prepared against 'next'), to see if the result rebases on older codebase. Giving a commit (not branch) to the command to force rebasing the commit on a detached HEAD is a very handy technique to do so without damaging the original branch. $ git checkout mater^0 $ git am -s mbox Applying A Applying B Applying C $ git rebase --onto maint master :/B would see if the earlier two commits that are pure bugfix cleanly applies to 'maint' (and then I can rebuild the topic by forking a branch from 'maint', queue A and B, and if C is not needed for that fix, fork another from that point, possibly merge 'master' to it and then queue C). What would happen when you are given --onto :/f...o is somewhat interesting, but that may be a separate topic, I think. At that point, it is probably in the realm of don't do it then ;-) The utility of this very series can be questioned. I've rarely wanted to use the :/fommery with rebase, so this mostly an exercise in theoretical correctness (something I usually stay away from). We are saying the same thing: don't do it then. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: I view the two codepaths touched by these patches the other way around. I see. Thanks for the early feedback. I have some doubts. An abbreviated unique SHA-1 you have today may not be unique tomorrow. When did we guarantee that the messages written by the reflog are invariant? That is not the point. From the proposed log message for your 2/2: f855138: checkout: moving from bdff0e3a374617dce784f801b97500d9ba2e4705 to co-reflog f855138: checkout: moving from bdff0e3 to co-reflog The bdff0e3 may be a unique abbreviation to identify the commit bdff0e3a374617dce784f801b97500d9ba2e4705 when the reflog entry was written. But the latter can become meaningless once you have an unrelated commit in your history that shares the prefix. That is the deliberate loss of information I saw in the proposal. Recording full 40-hex does not have to worry about that issue; you do not even have to argue but in this case we do not even have to have unique SHA-1, nobody uses it vs. some other codepaths you are not aware of may want to take advantage and start using it. In other words, we will have one less thing we have to worry about. -- 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/2] show-ref.c: Add missing call to git_config()
Ramsay Jones ram...@ramsay1.demon.co.uk writes: At present, 'git show-ref' ignores any attempt to set config variables (e.g. core.checkstat) from the command line using the -c option to git. I think what you really want to see is not giving -c and have it honored. git show-ref does not honor configuration variables at all, but at least core configuration variables read by git_default_config (most importantly core.checkstat) should be read and honored, because ... would be more appropriate. What are the variables that matter to show-ref, and what are the reasons why they should be honored? I thought show-ref was just a way to enumerate refs, and does not read the index nor checks if there are modifications in the working tree, so I do not see any reason offhand for it to honor core.checkstat (and I think that is the reason why we don't have the call there in the current code). Exactly the same comment applies to 2/2. Note that I am _not_ opposing these changes. You brought them up because you saw some reason why these should honor some core variables. I just want that reason to be explained in the log for the future developers. -- 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] config doc: rewrite push.default section
Ramkumar Ramachandra artag...@gmail.com writes:
Design by Junio.
Not necessary. The conclusion of discussion is a result of
collaboration.
Thanks for writing it down. It is a good start, but I agree with
reviews by Philip Oakley and Matthieu Moy we already saw.
- To understand if central, works as upstream, otherwise works as
current, the readers need to know if their workflow is 'central'
or not, so we need to say how that is decided upfront (probably
immediately before Possible values are: in the introductory
paragraph for push.default;
- For each of these choices, what it means is more important to the
readers than how the implementation achieves that semantics
(e.g. current uses refs/heads/foo:refs/heads/foo when you are on
foo branch). I think the ideal is a description of the meaning
that is clear enough not to require any implementation detail.
I do no think the remainder (snipped) belongs to the log message.
As this is an attempt to _define_ the semantics of what should
happen in triangular workflow, I think it would be healthy to wait
for a week or so in order for others (not just two of us) can see if
we have defined a sane semantics we would want to go forward with.
I am reasonably sure 'current' would be the best default for
triangular (and that is why I suggested 'simple' to fall back to
it), but I do not think others had a chance to see what design our
discussion settled, think if that makes sense, and think of a better
alternative.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7fd4035..30350a3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1832,33 +1832,32 @@ push.default::
line. Possible values are:
+
--
-* `nothing` - do not push anything.
-* `matching` - push all branches having the same name in both ends.
- This is for those who prepare all the branches into a publishable
- shape and then push them out with a single command. It is not
- appropriate for pushing into a repository shared by multiple users,
- since locally stalled branches will attempt a non-fast forward push
- if other users updated the branch.
- +
- This is currently the default, but Git 2.0 will change the default
- to `simple`.
-* `upstream` - push the current branch to its upstream branch
- (`tracking` is a deprecated synonym for this).
- With this, `git push` will update the same remote ref as the one which
- is merged by `git pull`, making `push` and `pull` symmetrical.
- See branch.name.merge for how to configure the upstream branch.
-* `simple` - like `upstream`, but refuses to push if the upstream
- branch's name is different from the local one. This is the safest
- option and is well-suited for beginners. It will become the default
- in Git 2.0.
-* `current` - push the current branch to a branch of the same name.
+* `nothing` - error out unless a refspec is explicitly given.
I do not think 'error out' is the primary effect of this mode.
Wouldn't do not push anything be much better?
+* `current` - push the refspec $HEAD. HEAD is resolved early to a
+ branch name (referred to as $HEAD). In other words, push the
+ current branch to update a branch with the same name on the pushing
+ side.
As already pointed out, dropping everything before and including In
other words, would be better. Also push the current branch is
talking about the branch on the pushing side (you, the one who is
running git push), and the side that is getting updated is at the
receiving end, not pushing side.
+* `upstream` - push the refspec $HEAD:branch.$HEAD.merge, and error
+ out if the push destination is not the same as branch.$HEAD.remote.
+ The name upstream refers to the revision @{u[pstream]} in
+ linkgit:gitrevisions[7]. It is useful in central workflows, to make
+ the `push` symmetrical to `pull`.
+
+* `simple` - in central workflows, behaves like `upstream`, except
+ that it errors out unless branch.$HEAD.merge is equal to $HEAD. In
+ non-central workflows, behaves like `current`. It will become the
+ default in Git 2.0.
I think listing 'simple' at the end would be easier to read. The
above already swaps the order to make sure current and upstream are
described before it, which is good.
But I do not see a reason to move 'matching' which was next to
'nothing' here. The
+* `matching` - push the refspec :. In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for those who prepare all the
+ branches into a publishable shape and then push them out with a
+ single command. Dangerous, and inappropriate unless you are the
+ only person updating your push destination.
It was already pointed out that unnecessary negativity needs to be
fixed, but more importantly the above Dangerous is not even
correct.
If you are I am done with this one branch, I want to push it out,
the other
Re: [PATCH/RFC 1/3] t9903: add tests for git-prompt pcmode
Eduardo R. D'Avila erdav...@gmail.com writes:
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
250 0 t/t9903-bash-prompt.sh
t/t9903-bash-prompt.sh | 250
+
1 file changed, 250 insertions(+)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 15521cc..ebca9de 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -535,4 +535,254 @@ test_expect_success 'prompt - format string starting
with dash' '
test_cmp expected $actual
'
+test_expect_success 'prompt - pc mode' '
+ printf BEFORE: (master):AFTER expected
Style; redirected filename immediately follows the redirection
operator, i.e.
command expected
+ printf expected_output
+ (
+ __git_ps1 BEFORE: :AFTER $actual
+ test_cmp expected_output $actual
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - branch name' '
+ printf BEFORE:
(\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER expected
With these escape codes that are hardcoded everywhere, the tests
look pretty much unreadable. Could they be improved to something
like this (two ${reset} and some other characters may want to be
there):
printf BEFORE: (${C_green}master${C_reset}):AFTER
by adding variable definitions early in this test file?
[the rest of the original left unsnipped for reference; my comments
end here]
+ (
+ GIT_PS1_SHOWCOLORHINTS=y
+ __git_ps1 BEFORE: :AFTER $actual
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - detached head' '
+ printf BEFORE:
(\\\[\\\e[31m\\\](%s...)\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER $(git log -1
--format=%h b1^) expected
+ git checkout b1^
+ test_when_finished git checkout master
+ (
+ GIT_PS1_SHOWCOLORHINTS=y
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator -
dirty worktree' '
+ printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]
\\\[\\\e[31m\\\]*\\\[\\\e[0m\\\]):AFTER expected
+ echo dirty file
+ test_when_finished git reset --hard
+ (
+ GIT_PS1_SHOWDIRTYSTATE=y
+ GIT_PS1_SHOWCOLORHINTS=y
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator -
dirty index' '
+ printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]
\\\[\\\e[32m\\\]+\\\[\\\e[0m\\\]):AFTER expected
+ echo dirty file
+ test_when_finished git reset --hard
+ git add -u
+ (
+ GIT_PS1_SHOWDIRTYSTATE=y
+ GIT_PS1_SHOWCOLORHINTS=y
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator -
dirty index and worktree' '
+ printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]
\\\[\\\e[31m\\\]*\\\[\\\e[32m\\\]+\\\[\\\e[0m\\\]):AFTER expected
+ echo dirty index file
+ test_when_finished git reset --hard
+ git add -u
+ echo dirty worktree file
+ (
+ GIT_PS1_SHOWCOLORHINTS=y
+ GIT_PS1_SHOWDIRTYSTATE=y
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator -
before root commit' '
+ printf BEFORE: (\\\[\\\e[32m\\\]master\\\[\\\e[0m\\\]
\\\[\\\e[32m\\\]#\\\[\\\e[0m\\\]):AFTER expected
+ (
+ GIT_PS1_SHOWDIRTYSTATE=y
+ GIT_PS1_SHOWCOLORHINTS=y
+ cd otherrepo
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - inside .git directory' '
+ printf BEFORE:
(\\\[\\\e[32m\\\]GIT_DIR!\\\[\\\e[0m\\\]\\\[\\\e[0m\\\]):AFTER expected
+ echo dirty file
+ test_when_finished git reset --hard
+ (
+ GIT_PS1_SHOWDIRTYSTATE=y
+ GIT_PS1_SHOWCOLORHINTS=y
+ cd .git
+ __git_ps1 BEFORE: :AFTER
+ printf %s $PS1 $actual
+ )
+ test_cmp expected $actual
+'
+
[PATCH] wt-status: give better advice when cherry-pick is in progress
When cherry-pick is in progress, 'git status' gives the advice to
run git commit to finish the cherry-pick. However, this won't continue
the sequencer.
git status should give the advice of running git cherry-pick --continue
or git cherry-pick --abort.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
t/t7512-status-help.sh | 6 --
wt-status.c| 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index bf08d4e..4f09bec 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -632,7 +632,8 @@ test_expect_success 'status when cherry-picking before
resolving conflicts' '
cat expected -\EOF
# On branch cherry_branch
# You are currently cherry-picking.
- # (fix conflicts and run git commit)
+ # (fix conflicts and run git cherry-pick --continue)
+ # (use git cherry-pick --abort to cancel the cherry-pick operation)
#
# Unmerged paths:
# (use git add file... to mark resolution)
@@ -655,7 +656,8 @@ test_expect_success 'status when cherry-picking after
resolving conflicts' '
cat expected -\EOF
# On branch cherry_branch
# You are currently cherry-picking.
- # (all conflicts fixed: run git commit)
+ # (all conflicts fixed: run git cherry-pick --continue)
+ # (use git cherry-pick --abort to cancel the cherry-pick operation)
#
# Changes to be committed:
#
diff --git a/wt-status.c b/wt-status.c
index bf84a86..438a40d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -955,10 +955,12 @@ static void show_cherry_pick_in_progress(struct wt_status
*s,
if (advice_status_hints) {
if (has_unmerged(s))
status_printf_ln(s, color,
- _( (fix conflicts and run \git commit\)));
+ _( (fix conflicts and run \git cherry-pick
--continue\)));
else
status_printf_ln(s, color,
- _( (all conflicts fixed: run \git
commit\)));
+ _( (all conflicts fixed: run \git
cherry-pick --continue\)));
+ status_printf_ln(s, color,
+ _( (use \git cherry-pick --abort\ to cancel the
cherry-pick operation)));
}
wt_status_print_trailer(s);
}
--
1.8.3.1.3.gf2b4626.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log: Add a switch to limit the number of displayed lines from the commit messages
Jonathan Nieder jrnie...@gmail.com writes: there are people out there disliking elaborate commit messages, as going over `git log` is tedious as you have to scroll a lot. As I do not like the suggestion to make commit messages shorter by omitting certain details, a way to limit the number displayed lines of the commit messages would be nice to have. Have you tried gitk or tig? They split the screen so you can browse through commits, one per line, in one half and read the corresponding commit messages and patches in the other. Or inside less that is spawned by git log -p, I often say this: /^commit .*|^diff --git .*ENTER and navigate with 'n' and 'p'. -- 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: REQUEST PULL: git-gui
Pulled (but I won't really work on Sunday night so the integration and pushout will be done tomorrow). 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 v2 0/6] Fix checkout-dash to work with rebase
Ramkumar Ramachandra artag...@gmail.com writes: So after extensive discussions with Junio, I have updated [5/6] to special-case rebase and rebase -i instead of dropping the HEAD detached from message altogether. Also, [1/6] includes two more tests, as suggested by Junio. Junio: The message is now the constant rebase in progress; onto $ONTO. That message is better than I was anticipating. I was actually assuming that you would leave them as they are i.e. # HEAD detached at xxx, as we agreed that we will see them improved anyway by the other topic. I am still puzzled to see that the change to checkout comes at the very end. With do not depend on rebase reflog messages done before the checkout: respect reflog-action, I was hoping that we can have changes to the actual reflog message made to rebase (patch 2 and 3) can be done at the very end. Was I missing something else? In other words, the order I was anticipating to see after the discussion (this is different from saying A series that is not ordered like this is unacceptable) was: wt-status: remove unused field in grab_1st_switch_cbdata This is an unrelated clean-up, and can be done before anything else. t/checkout-last: checkout - doesn't work after rebase This spells out what we want to happen at the end and marks the current breakage. status: do not depend on rebase reflog messages This compensates for fallouts from the next change. checkout: respect GIT_REFLOG_ACTION And this is the fix, the most important step. rebase: prepare to write reflog message for checkout rebase -i: prepare to write reflog message for checkout And these are icing on the cake, but that cannot be done before status is fixed. -- 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] mergetool--lib: refactor {diff,merge}_cmd logic
On Sun, Jun 16, 2013 at 10:51 AM, John Keeping j...@keeping.me.uk wrote:
Instead of needing a wrapper to call the diff/merge command, simply
provide the diff_cmd and merge_cmd functions for user-specified tools in
the same way as we do for built-in tools.
Signed-off-by: John Keeping j...@keeping.me.uk
---
This is a nice cleanup.
Acked-by: David Aguilar dav...@gmail.com
git-mergetool--lib.sh | 82
++-
1 file changed, 35 insertions(+), 47 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index e338be5..6a72106 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -114,6 +114,33 @@ valid_tool () {
test -n $cmd
}
+setup_user_tool () {
+ merge_tool_cmd=$(get_merge_tool_cmd $tool)
+ test -n $merge_tool_cmd || return 1
+
+ diff_cmd () {
+ ( eval $merge_tool_cmd )
+ status=$?
+ return $status
+ }
+
+ merge_cmd () {
+ trust_exit_code=$(git config --bool \
+ mergetool.$1.trustExitCode || echo false)
+ if test $trust_exit_code = false
+ then
+ touch $BACKUP
+ ( eval $merge_tool_cmd )
+ status=$?
+ check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ return $status
+ }
+}
+
setup_tool () {
tool=$1
@@ -142,15 +169,15 @@ setup_tool () {
if ! test -f $MERGE_TOOLS_DIR/$tool
then
- # Use a special return code for this case since we want to
- # source defaults even when an explicit tool path is
- # configured since the user can use that to override the
- # default path in the scriptlet.
- return 2
+ setup_user_tool
+ return $?
fi
# Load the redefined functions
. $MERGE_TOOLS_DIR/$tool
+ # Now let the user override the default command for the tool. If
+ # they have not done so then this will return 1 which we ignore.
+ setup_user_tool
if merge_mode ! can_merge
then
@@ -187,20 +214,7 @@ run_merge_tool () {
status=0
# Bring tool-specific functions into scope
- setup_tool $1
- exitcode=$?
- case $exitcode in
- 0)
- :
- ;;
- 2)
- # The configured tool is not a built-in tool.
- test -n $merge_tool_path || return 1
- ;;
- *)
- return $exitcode
- ;;
- esac
+ setup_tool $1 || return 1
if merge_mode
then
@@ -213,38 +227,12 @@ run_merge_tool () {
# Run a either a configured or built-in diff tool
run_diff_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -n $merge_tool_cmd
- then
- ( eval $merge_tool_cmd )
- status=$?
- return $status
- else
- diff_cmd $1
- fi
+ diff_cmd $1
}
# Run a either a configured or built-in merge tool
run_merge_cmd () {
- merge_tool_cmd=$(get_merge_tool_cmd $1)
- if test -n $merge_tool_cmd
- then
- trust_exit_code=$(git config --bool \
- mergetool.$1.trustExitCode || echo false)
- if test $trust_exit_code = false
- then
- touch $BACKUP
- ( eval $merge_tool_cmd )
- status=$?
- check_unchanged
- else
- ( eval $merge_tool_cmd )
- status=$?
- fi
- return $status
- else
- merge_cmd $1
- fi
+ merge_cmd $1
}
list_merge_tool_candidates () {
--
1.8.3.779.g691e267
--
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
Nike Free Run
Nike Free Run 2 http://www.freerunschuheonline.de/ Es ist immer wieder erstaunlich, welche eine Menge Käufer behaupten die Schuhe eine gute Sache. Der Hersteller, die Nike Eigenkapital umfasst jeder der den noch dazu führt, daß die Ware zuverlässig und begehrt. Wenn Sie ein Ergebnis gibt, durch die mehrere Arbeiten Jahren hat Nike Air Maximum habe richtig nach rechts in eine grundlegende transformiert für ziemlich einigen Sportarten Athleten und Tag für Tag Menschen auf der ganzen world.Incredible! Sieht gut aus mit dem organischen Köper Sommer-Outfit. Eine extrem hochwertige und komfortable Nike Free Run Boot, ohne over-the-top. Ich kaufte unser Wochenende andauern und zusätzlich war äußerst zufrieden mit ihnen. Sie können perfekt und sie sind sehr komfortabel, nie zu erwähnen, modisch. Ich habe sie mit Khaki und Jeans verwendet durch eine Übung Mantel. Immer, wenn ich wollte auf den Schuhen versuchen das Paar waren sehr komfortabel. Im Vergleich zu den täglichen Schuhe oder Stiefel waren diese Menschen die gleichen Länge, da mein Favorit Adidas und Puma in einer Größe zwölf. Wenn bei Ihnen eine flache, billige Reparaturverfahren ruuning Stiefel, eine paar Kissen tut begünstigen kann die nike free run für Sie sein. Dies könnte die größten Schuhe, die ich jemals in haben, sowie der beste Weg, um für eine geringfügige Schuhe, wer Sie sind in der Lage könnte sich in alltäglichen laufen gehen laufen sein. Merkmale legitimen Nike Free Online Männer. Schuhe padding-System, um die höchstmögliche Polsterung Komfort für Ihre müden Zoll bieten und liefern auch gute Stoßdämpfung Die obere aufgebaut ist in Ordnung, verbesserte Zähigkeit, Lüftungs-und auch Stärken zu versorgen. TPU-Sperre, Phylon-Mittelsohle und zusätzlich DRC Sohlen sind tatsächlich einige der effektive Funktionen in diesem Nike Free three.0 Männliche Schuhe entwickelt, um eine erhöhte Stabilität, Komfort, Robustheit, Halt und vor allem große funktionale Leistung. Barfuß fließenden hat sich ganz ein Trend heutzutage. Einzelpersonen, die in Betrieb sein muss. Das Bewusstsein für die Vorteile des fließenden einfacher und zusätzlich in einer Weise free.Nike ist bei weitem die größte Sportswear-Marke in diesem Bereich und auch die unglaublichen Leistungen des Unternehmens, in Beaverton, Oregon basiert auf der ständigen Entwicklung und Innovation in allen Teilen formuliert der Leichtathletik Kleidung. Besonders in Stiefel Nike gedeihen immer instabil Meilensteine und auch diese wird die Einführung von Air Unit Tech sein im Jahr 1982 vertritt die Basketball-Stiefel Air Force 1 war der Fuß Polsterung zum ersten Mal mit Hilfe gebaut rechts in die Sohle Blase und auch unterstützt. Die Schuhe Kultstatus in der Basketball-Szene zusammen mit den kürzlich entwickelten Technologien bleibt eine solide grundsätzlich innerhalb der Entwicklung neuer Modelle. Der eigentliche Tanz Schlägerkopf besitzen Sie von 1025 Leistungsstarke Co2 Stahl und zusätzlich kann es eine CNC-gefräste Gesicht sein sowie bieten gegen eine in der Breite Rückenlehne und gewichtigeren der großen Zehe. AA Menge von Individuen können sich bewusst sein, der Krankheit und zusätzlich aus der Nike Free Run 3 http://www.freerunschuheonline.de/ Bewegung zu bleiben, so ist dies sicherlich definitiv aaa Teil der Aspekte seiner geneigt, in der Wahrheit. Ob es die Entwicklung diskutieren Sie mit Kleid in den exakten Nike Free 3.0 V2 Männer Turnschuhe individuellen Anforderungen ausgeführt werden. In dieser wunderbaren Zeit, ist es die Luft übertragen Tempo Einrichtung verbessert, erfordern einen erheblichen permeableness. Die Moderatoren Veranstaltung kann von allen Kindern in der Klasse bei nur etwa jeder Zeit mit dem Einsatz von einem kleinen robusten Handheld-Projektor nike free run 2 gelesen werden. Größere Bilder mit einem Bildschirm oder anderen flachen Oberflächen durch einen DLP-Projektor oder LCD-Projektor entwickelt wurden, können von den Studierenden selbst innerhalb der Rückseite Reihen gesehen fühlen, zu sehen und zusätzlich wissen Manuskript oder vielleicht andere Materialien. Der Projektor kann verwendet werden, um kleine Grafik oder vielleicht Standorte in der Karte angezeigt werden, wie Ansprüche, Hauptstädte, Inseln etc Nike Free Run Nike Free 5.0 v4 in enger Details. Klassenzimmer um DLP / LCD-Projektoren strukturiert bringt Themen zum Leben, indem Manuskript, Audio Nike Free 5.0 v4 mens, Bilder und Bewegung zusätzlich Videoclips. Darüber hinaus gewinnen College-Studenten die Möglichkeit, interaktive Simulationen, Web-Ausflüge und auch Online-Imaging-basierte Präsentationen und auch sehr viel deutlich mehr haben, wenn Sie Compact modernen Projektoren nike free run verwenden. nike free four.0 Schnürsenkel, sollten Sie überprüfen, und spüren Sie die Zunge in den Nike SB Dunks. Nike SB Dunk gehen, authentisch zu sein, dann ist ihre Klöppel sollte dicht sein, muss sie zu biegen die Sechste ist v oder U Kontur. Gefälschte die Zungen ist Matte zusammen mit square.Then Menschen
[bug, git-svn] error: too many matches for svn-remote.svn.added-placeholder
When trying to clone a big svn repository using git-svn, with many empty folders, after a while I started getting many error: too many matches for svn-remote.svn.added-placeholder errors. The following url has a suggestion for a temporary fix: http://stackoverflow.com/questions/14512292/git-svn-clone-prints-hundreds-of-error-too-many-matches-for-svn-remote-svn-add Still I think this should be fixed in git. I don't think a limit of less then 512 empty folders is a realistic limit. Is it even a good idea to store lists that are this big in .git/config? Shouldn't this get it's own file? Andrei -- 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
