Re: [PATCH] rebase -i: fixup fixup! fixup!
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.
Here is a patch for commit.c that does this.
Andrew
When building the commit message for --fixup/--squash, ignore a leading
fixup! or squash! on the referenced commit. Handy in case the user referred
to an earlier squash/fixup commit instead of the original commit, for
example with :/msg.
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
builtin/commit.c | 18 ++
t/t7500-commit.sh | 36
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1621dfc..370df88 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -601,8 +601,13 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
if (!c)
die(_(could not lookup commit %s),
squash_message);
ctx.output_encoding = get_commit_output_encoding();
- format_commit_message(c, squash! %s\n\n, sb,
- ctx);
+ format_commit_message(c, %s\n\n, sb, ctx);
+ if (!prefixcmp(sb.buf, fixup! )) {
+ strbuf_remove(sb, 0, strlen(fixup! ));
+ } else if (!prefixcmp(sb.buf, squash! )) {
+ strbuf_remove(sb, 0, strlen(squash! ));
+ }
+ strbuf_insert(sb, 0, squash! , strlen(squash! ));
}
}
@@ -634,8 +639,13 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
if (!commit)
die(_(could not lookup commit %s), fixup_message);
ctx.output_encoding = get_commit_output_encoding();
- format_commit_message(commit, fixup! %s\n\n,
- sb, ctx);
+ format_commit_message(commit, %s\n\n, sb, ctx);
+ if (!prefixcmp(sb.buf, fixup! )) {
+ strbuf_remove(sb, 0, strlen(fixup! ));
+ } else if (!prefixcmp(sb.buf, squash! )) {
+ strbuf_remove(sb, 0, strlen(squash! ));
+ }
+ strbuf_insert(sb, 0, fixup! , strlen(fixup! ));
hook_arg1 = message;
} else if (!stat(git_path(MERGE_MSG), statbuf)) {
if (strbuf_read_file(sb, git_path(MERGE_MSG), 0) 0)
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 436b7b6..ecdf74a 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -320,4 +320,40 @@ test_expect_success 'invalid message options when using
--fixup' '
test_must_fail git commit --fixup HEAD~1 -F log
'
+test_expect_success 'commit --fixup of existing fixup' '
+ commit_for_rebase_autosquash_setup
+ git commit --fixup HEAD~1
+ echo fourth content line foo
+ git add foo
+ git commit --fixup HEAD
+ commit_msg_is fixup! target message subject line
+'
+
+test_expect_success 'commit --fixup of existing squash' '
+ commit_for_rebase_autosquash_setup
+ git commit --squash HEAD~1
+ echo fourth content line foo
+ git add foo
+ git commit --fixup HEAD
+ commit_msg_is fixup! target message subject line
+'
+
+test_expect_success 'commit --squash of existing squash' '
+ commit_for_rebase_autosquash_setup
+ git commit --squash HEAD~1
+ echo fourth content line foo
+ git add foo
+ git commit --squash HEAD
+ commit_msg_is squash! target message subject linecommit message
+'
+
+test_expect_success 'commit --squash of existing fixup' '
+ commit_for_rebase_autosquash_setup
+ git commit --fixup HEAD~1
+ echo fourth content line foo
+ git add foo
+ git commit --squash HEAD
+ commit_msg_is squash! target message subject linecommit message
+'
+
test_done
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote:
wt-status.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index bf84a86..403d48d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)
branch_name += 11;
else if (!strcmp(branch_name, HEAD)) {
branch_status_color = color(WT_STATUS_NOBRANCH, s);
- if (state.detached_from) {
+
+ if (state.rebase_in_progress) {
+ on_what = _(HEAD detached at );
+ branch_name = state.onto;
+ } else if (state.detached_from) {
unsigned char sha1[20];
branch_name = state.detached_from;
Good. You have proposed a solution to the problem. However, it is
wrong for the following reasons:
1. It shows a pseudo HEAD detached at message. Everywhere else,
when the user sees a HEAD detached at $committish message, git
rev-parse $committish = git rev-parse HEAD. A rebase-in-progress
seems to be the only exception, and the user has no idea this is
happened.
2. The following no longer updates status:
# in the middle of a rebase
$ git reset @~2
The constant HEAD detached at $onto message is misleading and Bad.
Besides, wasn't this the primary usecase you wanted?
You previously wrote:
*1* One thing I could think of is to start sightseeing or (more
realistically) manually bisecting at a given release point,
reset the detached HEAD around several times, and then want to
be reminded where the session started from. I do not think it
is particularly a very good example, though.
Whether the HEAD is detached by bisect or rebase is irrelevant.
3. The problem is not unique to rebase at all; yet you have
special-cased it. If this isn't a band-aid, what is? The larger
problem, as I have stated previously, is that 'git status' output
depends on the _implementations_ of various commands (do they write a
checkout: message to the reflog or not?). Therefore, a future
contributor who updates a command to write more sensible reflog
messages will have to apply a similar band-aid.
If you want to take the band-aid approach, I think this is the right
way to do it:
diff --git a/wt-status.c b/wt-status.c
index bf84a86..99c55e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)
if (!get_sha1(HEAD, sha1)
!hashcmp(sha1, state.detached_sha1))
on_what = _(HEAD detached at );
- else
+ else if (!state.rebase_in_progress)
on_what = _(HEAD detached from );
} else {
branch_name = ;
You have already mentioned that there is a topic cooking to improve
this first-line in the case of rebase, so this regression from a
senseless message isn't a problem.
The problem with this bad-aid, as with all band aids, is that this
will soon explode to become else if(!state.rebase_in_progress
!state.bisect_in_progress ) when people update those scripts.
If you don't want to go with the band-aid, I have no choice but to
smudge the first-line.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: I am only saying that the last test the commit adds must be kept unbroken. I am also saying that, even though that commit did not add a test for detached from case, we should add something like the attached to protect the behaviour. These two are sacred. What happens to be shown during a stopped git rebase is not. I have been assuming the main thing Duy wanted to do was the last test (and the one below), but was this meant as an improvement for git status output during that state? On what basis are you making that assumption? b397ea4 did not add a test for detached HEAD from, and there is no evidence of what the author wanted in the commit message. What has happened has happened; the question is: what do _you_ want now? Read the various HEAD detached from/to messages in the rebase tests in t/status-help and tell me that they make some sense. It does _not_ show a constant HEAD detached from $onto, contrary to your assumption (evidenced by your patch in the later email). Look at these hunk added by b397ea4, and tell me that it's not a monkey-patch: @@ -187,9 +187,10 @@ 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 - # Not currently on any branch. + # HEAD detached from $TGT # 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) @@ -214,8 +215,9 @@ 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 - # Not currently on any branch. + # HEAD detached at $TGT # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''. # (Once your working directory is clean, run git rebase --continue) # @@ -243,10 +245,11 @@ 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 - # Not currently on any branch. + # HEAD detached from $TGT # You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''$ONTO'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) Showing $ONTO certainly makes some sense, and from that point of view, the change we are discussing _will_ be a regression if it just shows a random thing. If showing $ONTO were the intent of the patch, this is no way to go about it. Reliable information is readily available in .git/rebase-apply; no parsing is required, and it is ready for consumption. Your argument now is: because the patch _incidentally_ shows $ONTO in many cases (as evidenced by the hunks above), the objective of the patch _must_ have been to show $ONTO. Should I laugh or cry? If you want to avoid regression, the codepath in wt-status.c should compensate for the change to rebase so that it checks $dotest/onto and show what is recorded in there. Now you want to achieve the exact same accidental behavior after patching rebase/checkout. This is a never-ending nightmare. You are misreading me. I am not defending every bit at all. I am not misreading anything. Despite me having repeatedly shown that b397ea4 is poorly done with far-reaching unintended consequences, you are unwilling to admit it. Instead, you are trying to somehow preserve this accidental behavior. And you still haven't been able to show me how to do that. As a result, checkout-dash is stalled. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: I am only saying that the last test the commit adds must be kept unbroken. I am also saying that, even though that commit did not add a test for detached from case, we should add something like the attached to protect the behaviour. These two are sacred. What happens to be shown during a stopped git rebase is not. ... The question is: what do _you_ want now? It should be fairly clear what _I_ want now. Re-read the first four lines you quoted above. Read the various HEAD detached from/to messages in the rebase tests in t/status-help and tell me that they make some sense. Again, re-read the part you did _not_ quote before those four lines. I do not think all of them make lot of sense; some of them may. Unless you are also tackling the topic of the other thread: http://thread.gmane.org/gmane.comp.version-control.git/227432/focus=227469 (which I would not suggest to do in this topic), what these lines say during rebase does not really matter, as far as your topic is concerned. Two possibilities: (1) Assume that the other thread will produce a more reasonable semantics when finished; perhaps the first line will go away entirely, or maybe it would say something like # Rebasing; head at $commit. Your topic does not _care_ what it would say, so you tweak the status test that is done during rebase so that they ignore the first lines; or (2) Starting from the same assumption as above, but try to minimize the semantics change to user-visible behaviour this series makes. That means that even though the _primary_ thing you want to do is to tweak rebase and its internal use of checkout in such a way that reflog will not record the implementation-detail checkout (because that will affect the next checkout -), make sure that status while doing rebase reports where the internal checkout of $ONTO detached HEAD from/at. The something along this line patch was an illustration of how the beginning of the effort for (2) would look like. As I already said, I could see us going either way. If we can do (2), that may be better, but at end it would not matter that much as long as we will be doing the other topic, too. -- 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
Youur wiif will bee the happieeest lady on the plllaaneeet
Get beetter sex lifee withh ttthese gggreat piills http://ozdecor.com/admin/popups/6e71.php -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra artag...@gmail.com writes: 2. The following no longer updates status: # in the middle of a rebase $ git reset @~2 The constant HEAD detached at $onto message is misleading and Bad. Besides, wasn't this the primary usecase you wanted? See the other message. The first line from status in the middle of a rebase is secondary. End-user initiated checkout to detach is the primary thing. You previously wrote: *1* One thing I could think of is to start sightseeing or (more realistically) manually bisecting at a given release point, reset the detached HEAD around several times, and then want to be reminded where the session started from. I do not think it is particularly a very good example, though. Whether the HEAD is detached by bisect or rebase is irrelevant. You read and reacted to bisect too literally and missed manually. The scenario I had in mind does _not_ use git bisect command, which may _internally_ run git checkout to detach, but for exactly the same reason why you want to touch git rebase in this series, its use of checkout should not count for the next checkout -. The sequence of manually bisecting is like $ git checkout v1.8.3 ... test $ git status $ git log --oneline --first-parent v1.8.2..$detached_from ... pick a likely point $ git reset --hard $that_point ... go back to test further which I actually do fairly often, as I tend to know more about the likely place something may have been broken than a mechanical split the history into about the same number of commits bisection. 3. The problem is not unique to rebase at all; yet you have special-cased it. If this isn't a band-aid, what is? It is an illustration for approach (2) in the other message. In the longer term, you would want richer status output for various detached state, and that how about this patch shows where new code to support other cases should be added. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra artag...@gmail.com writes: I have been assuming the main thing Duy wanted to do was the last test (and the one below), but was this meant as an improvement for git status output during that state? On what basis are you making that assumption? List archive helps. http://thread.gmane.org/gmane.comp.version-control.git/217342/focus=217444 Not just that single message, but a few messages in the discussion that led to the design shows that we wanted both at and from to mean something sensible, when a checkout initiated by the end-user detached HEAD and we are not on any branch, even after making commits or doing resets. -- 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
Angebot sehr dringlich
guten Tag! ich bin ein privater Darlehensgeber, und ich mache die Darlehen zu all jenen, die im Bedürfnis sind und die bestimmte Bedingungen erfüllen. ich mache gehende Darlehen von 2000 Euro zu 50.000.000 Euro zu sehr interessanten Zinssätzen (3%; 3,7%). all jene, die ein Darlehen benötigen, schreiben Sie mich an die folgende Adresse. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote:
Two possibilities:
(1) Assume that the other thread will produce a more reasonable
semantics when finished; perhaps the first line will go away
entirely, or maybe it would say something like # Rebasing;
head at $commit.
Your topic does not _care_ what it would say, so you tweak the
status test that is done during rebase so that they
ignore the first lines; or
You said you didn't want to regress to show senseless information, and
I agreed with that. What is wrong with the patch I showed in the
previous email? Smudging is a bad hack, and must only be used as a
last resort: when an another topics updates status to say something
sensible, it will have to unsmudge the tests.
diff --git a/wt-status.c b/wt-status.c
index bf84a86..99c55e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s)
if (!get_sha1(HEAD, sha1)
!hashcmp(sha1, state.detached_sha1))
on_what = _(HEAD detached at );
- else
+ else if (!state.rebase_in_progress)
on_what = _(HEAD detached from );
} else {
branch_name = ;
(2) Starting from the same assumption as above, but try to minimize
the semantics change to user-visible behaviour this series
makes.
The try to minimize is a somewhat admirable goal, but I have shown
that your midway solution is wrong. Either dedicate a lot of time and
effort towards improving status for rebase, or don't attempt it.
That means that even though the _primary_ thing you want to do
is to tweak rebase and its internal use of checkout in such
a way that reflog will not record the implementation-detail
checkout (because that will affect the next checkout -), make
sure that status while doing rebase reports where the
internal checkout of $ONTO detached HEAD from/at.
Unless we change the first line drastically to say: rebase in
progress: rebasing onto $ONTO (or something), I don't think this
makes sense. And if we were to do that, why not do it properly like
rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH?
Other people on a different thread are already handling that, and I am
not interested.
So, you have three simple choices now:
1. Accept the simple patch I proposed above.
2. Propose an alternative patch quickly. *Patch*. No more English.
3. Reject all patches, and leave me no choice but to smudge.
Which one is it going to be?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Junio C Hamano wrote: The first line from status in the middle of a rebase is secondary. End-user initiated checkout to detach is the primary thing. 3. The problem is not unique to rebase at all; yet you have special-cased it. If this isn't a band-aid, what is? It is an illustration for approach (2) in the other message. In the longer term, you would want richer status output for various detached state, and that how about this patch shows where new code to support other cases should be added. Fine. If that is what you want, we'll have to special-case every known script-in-progress to stop writing the usual HEAD detached from message. That'll leave out only the end-user cases, where you argue that the message is helpful. -- 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
Junio C Hamano wrote: I _think_ the new check you added may be too loose. Yep, I totally forgot about the case when git-am.sh is called from an existing script. In that case, it is upto the caller to handle whatever stray directories; we have no business meddling with that. A fix-up may look like this. No, don't leak autostash detail. Just change that condition to if test -d $dotest test -z $rebasing and we're done. I'll send in a re-roll. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] t/am: use test_path_is_missing() where appropriate
Replace instances of ! test -d with test_path_is_missing. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t4150-am.sh | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/t/t4150-am.sh b/t/t4150-am.sh index 6c2cc3e..5edb79a 100755 --- a/t/t4150-am.sh +++ b/t/t4150-am.sh @@ -147,7 +147,7 @@ test_expect_success 'am applies patch correctly' ' git checkout first test_tick git am patch1 - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code second test $(git rev-parse second) = $(git rev-parse HEAD) test $(git rev-parse second^) = $(git rev-parse HEAD^) @@ -158,7 +158,7 @@ test_expect_success 'am applies patch e-mail not in a mbox' ' git reset --hard git checkout first git am patch1.eml - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code second test $(git rev-parse second) = $(git rev-parse HEAD) test $(git rev-parse second^) = $(git rev-parse HEAD^) @@ -169,7 +169,7 @@ test_expect_success 'am applies patch e-mail not in a mbox with CRLF' ' git reset --hard git checkout first git am patch1-crlf.eml - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code second test $(git rev-parse second) = $(git rev-parse HEAD) test $(git rev-parse second^) = $(git rev-parse HEAD^) @@ -180,7 +180,7 @@ test_expect_success 'am applies patch e-mail with preceding whitespace' ' git reset --hard git checkout first git am patch1-ws.eml - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code second test $(git rev-parse second) = $(git rev-parse HEAD) test $(git rev-parse second^) = $(git rev-parse HEAD^) @@ -206,7 +206,7 @@ test_expect_success 'am changes committer and keeps author' ' git reset --hard git checkout first git am patch2 - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply test $(git rev-parse master^^) = $(git rev-parse HEAD^^) git diff --exit-code master..HEAD git diff --exit-code master^..HEAD^ @@ -258,7 +258,7 @@ test_expect_success 'am --keep really keeps the subject' ' git reset --hard git checkout HEAD^ git am --keep patch4 - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git cat-file commit HEAD actual grep Re: Re: Re: \[PATCH 1/5 v2\] \[foo\] third actual ' @@ -268,7 +268,7 @@ test_expect_success 'am --keep-non-patch really keeps the non-patch part' ' git reset --hard git checkout HEAD^ git am --keep-non-patch patch4 - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git cat-file commit HEAD actual grep ^\[foo\] third actual ' @@ -283,7 +283,7 @@ test_expect_success 'am -3 falls back to 3-way merge' ' test_tick git commit -m copied stuff git am -3 lorem-move.patch - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code lorem ' @@ -297,7 +297,7 @@ test_expect_success 'am -3 -p0 can read --no-prefix patch' ' test_tick git commit -m copied stuff git am -3 -p0 lorem-zero.patch - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code lorem ' @@ -307,7 +307,7 @@ test_expect_success 'am can rename a file' ' git reset --hard git checkout lorem^0 git am rename.patch - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git update-index --refresh git diff --exit-code rename ' @@ -318,7 +318,7 @@ test_expect_success 'am -3 can rename a file' ' git reset --hard git checkout lorem^0 git am -3 rename.patch - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git update-index --refresh git diff --exit-code rename ' @@ -329,7 +329,7 @@ test_expect_success 'am -3 can rename a file after falling back to 3-way merge' git reset --hard git checkout lorem^0 git am -3 rename-add.patch - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git update-index --refresh git diff --exit-code rename ' @@ -358,7 +358,7 @@ test_expect_success 'am pauses on conflict' ' test_expect_success 'am --skip works' ' echo goodbye expected git am --skip - ! test -d .git/rebase-apply + test_path_is_missing .git/rebase-apply git diff --exit-code lorem2^^ -- file test_cmp expected another
[PATCH v3 0/2] Fix am with stray $dotest directory
The test in [1/2] was too loose in the previous iteration: guard it with test -z $rebasing. Also fix a couple of minor problems pointed out by Junio (extra indentation, $-unescaped). Thanks. Ramkumar Ramachandra (2): am: handle stray $dotest directory t/am: use test_path_is_missing() where appropriate git-am.sh | 17 + t/t4150-am.sh | 40 +++- 2 files changed, 40 insertions(+), 17 deletions(-) -- 1.8.3.1.383.g8881048.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 v3 1/2] am: handle stray $dotest directory
The following bug has been observed: $ git am # no input file ^C $ git am --abort Resolve operation not in progress, we are not resuming. This happens because the following test fails: test -d $dotest test -f $dotest/last test -f $dotest/next and the codepath for an am in-progress is not executed. It falls back to the codepath that treats this as a fresh execution. Before rr/rebase-autostash, this condition was test -d $dotest It would incorrectly execute the normal am --abort codepath: git read-tree --reset -u HEAD ORIG_HEAD git reset ORIG_HEAD by incorrectly assuming that an am is in progress (i.e. ORIG_HEAD etc. was written during the previous execution). Notice that $ git am ^C executes nothing of significance, is equivalent to $ mkdir .git/rebase-apply Therefore, the correct solution is to treat .git/rebase-apply as a stray directory and remove it on --abort in the fresh-execution codepath. Also ensure that we're not called with --rebasing from git-rebase--am.sh; in that case, it is the responsibility of the caller to handle and stray directories. While at it, tell the user to run git am --abort to get rid of the stray $dotest directory, if she attempts anything else. Reported-by: Junio C Hamano gits...@pobox.com Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-am.sh | 17 + t/t4150-am.sh | 6 ++ 2 files changed, 23 insertions(+) diff --git a/git-am.sh b/git-am.sh index 1cf3d1d..91a2bcc 100755 --- a/git-am.sh +++ b/git-am.sh @@ -506,6 +506,23 @@ then esac rm -f $dotest/dirtyindex 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 + then + case $skip,$resolved,$abort in + ,,t) + rm -fr $dotest + exit 0 + ;; + *) + die $(eval_gettext Stray \$dotest directory found. +Use \git am --abort\ to remove it.) + ;; + esac + fi + # Make sure we are not given --skip, --resolved, nor --abort test $skip$resolved$abort = || die $(gettext Resolve operation not in progress, we are not resuming.) diff --git a/t/t4150-am.sh b/t/t4150-am.sh index 12f6b02..6c2cc3e 100755 --- a/t/t4150-am.sh +++ b/t/t4150-am.sh @@ -363,6 +363,12 @@ test_expect_success 'am --skip works' ' test_cmp expected another ' +test_expect_success 'am --abort removes a stray directory' ' + mkdir .git/rebase-apply + git am --abort + test_path_is_missing .git/rebase-apply +' + test_expect_success 'am --resolved works' ' echo goodbye expected rm -fr .git/rebase-apply -- 1.8.3.1.383.g8881048.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] diff: add --ignore-blank-lines option
The goal of the patch is to introduce the GNU diff -B/--ignore-blank-lines as closely as possible. The short option is not available because it's already used for break-rewrites. When this option is used, git-diff will not create hunks that simply add or remove empty lines, but will still show empty lines addition/suppression if they are close enough to valuable changes. There are two differences between this option and GNU diff -B option: - GNU diff doesn't have --inter-hunk-context, so this must be handled - The following sequence looks like a bug (context is displayed twice): $ seq 5 file1 $ cat EOF file2 change 1 2 3 4 5 change EOF $ diff -u -B file1 file2 --- file1 2013-06-08 22:13:04.471517834 +0200 +++ file2 2013-06-08 22:13:23.275517855 +0200 @@ -1,5 +1,7 @@ +change 1 2 + 3 4 5 @@ -3,3 +5,4 @@ 3 4 5 +change So here is a more thorough description of the option: - real changes are interesting - blank lines that are close enough (less than context size) to interesting changes are considered interesting (recursive definition) - context lines are used around each hunk of interesting changes - If two hunks are separated by less than inter-hunk-context, they will be merged into one. The current implementation does the interesting changes selection in a single pass. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- Hey, OK I think this version should be fine (I don't have any bug that comes to mind). Please review the between changes test as I made a choice there that can be controversial. Thanks, Antoine Documentation/diff-options.txt |3 + diff.c |2 + t/t4015-diff-whitespace.sh | 308 xdiff/xdiff.h |2 + xdiff/xdiffi.c | 29 +++- xdiff/xdiffi.h |1 + xdiff/xemit.c | 50 ++- xdiff/xemit.h |2 +- xdiff/xutils.c | 13 ++ xdiff/xutils.h |1 + 10 files changed, 403 insertions(+), 8 deletions(-) diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index b8a9b86..4e042d9 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -439,6 +439,9 @@ endif::git-format-patch[] differences even if one line has whitespace where the other line has none. +--ignore-blank-lines:: + Ignore changes whose lines are all blank. + --inter-hunk-context=lines:: Show the context between diff hunks, up to the specified number of lines, thereby fusing hunks that are close to each other. diff --git a/diff.c b/diff.c index f0b3e7c..208094f 100644 --- a/diff.c +++ b/diff.c @@ -3593,6 +3593,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac) DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE); else if (!strcmp(arg, --ignore-space-at-eol)) DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL); + else if (!strcmp(arg, --ignore-blank-lines)) + DIFF_XDL_SET(options, IGNORE_BLANK_LINES); else if (!strcmp(arg, --patience)) options-xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF); else if (!strcmp(arg, --histogram)) diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh index cc3db13..6ed6934 100755 --- a/t/t4015-diff-whitespace.sh +++ b/t/t4015-diff-whitespace.sh @@ -142,6 +142,314 @@ EOF git diff --ignore-space-at-eol out test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out' +test_expect_success 'ignore-blank-lines: only new lines' ' + test_seq 5 x + git update-index x + test_seq 5 | sed /3/i \\ + x + git diff --ignore-blank-lines out + expect + test_cmp out expect +' + +test_expect_success 'ignore-blank-lines: only new lines with space' ' + test_seq 5 x + git update-index x + test_seq 5 | sed /3/i \ x + git diff -w --ignore-blank-lines out + expect + test_cmp out expect +' + +test_expect_success 'ignore-blank-lines: after change' ' + cat -\EOF x + 1 + 2 + + 3 + 4 + 5 + + 6 + 7 + EOF + git update-index x + cat -\EOF x + change + + 1 + 2 + 3 + 4 + 5 + 6 + + 7 + EOF + git diff --inter-hunk-context=100 --ignore-blank-lines out.tmp + cat -\EOF expected + diff --git a/x b/x + --- a/x + +++ b/x + @@ -1,6 +1,7 @@ + +change + + +1 +2 + - +3 +4 +5 + EOF + compare_diff_patch expected out.tmp +' + +test_expect_success 'ignore-blank-lines: before change' ' + cat -\EOF x + 1 + 2 + + 3 + 4 + 5 + 6 + 7 +
[PATCH v3 1/5] stash doc: add a warning about using create
Add a note saying that the user probably wants save in the create description. While at it, document that it can optionally take a message in the synopsis. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-stash.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 711ffe1..cb0c1a6 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -16,7 +16,7 @@ SYNOPSIS 'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [message]] 'git stash' clear -'git stash' create +'git stash' create [message] DESCRIPTION --- @@ -151,6 +151,8 @@ create:: Create a stash (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace. + This is intended to be useful for scripts. It is probably not + the command you want to use; see save above. DISCUSSION -- 1.8.3.1.441.gd7d6b72.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 v3 2/5] stash doc: document short form -p in synopsis
'git stash save' can take -p, the short form of --patch, as an option. Document this. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-stash.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index cb0c1a6..632d4fb 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -13,7 +13,7 @@ SYNOPSIS 'git stash' drop [-q|--quiet] [stash] 'git stash' ( pop | apply ) [--index] [-q|--quiet] [stash] 'git stash' branch branchname [stash] -'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] +'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [message]] 'git stash' clear 'git stash' create [message] -- 1.8.3.1.441.gd7d6b72.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 v3 4/5] stash: introduce 'git stash store'
save_stash() contains the logic for doing two potentially independent
operations; the first is preparing the stash merge commit, and the
second is updating the stash ref/ reflog accordingly. While the first
operation is abstracted out into a create_stash() for callers to access
via 'git stash create', the second one is not. Fix this by factoring
out the logic for storing the stash into a store_stash() that callers
can access via 'git stash store'.
Like create, store is not intended for end user interactive use, but for
callers in other scripts. We can simplify the logic in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 7 +++
git-stash.sh| 47 +++--
t/t3903-stash.sh| 19 ++
3 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 632d4fb..db7e803 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[-u|--include-untracked] [-a|--all] [message]]
'git stash' clear
'git stash' create [message]
+'git stash' store [-m|--message message] [-q|--quiet] commit
DESCRIPTION
---
@@ -154,6 +155,12 @@ create::
This is intended to be useful for scripts. It is probably not
the command you want to use; see save above.
+store::
+
+ Store a given stash created via 'git stash create' (which is a
+ dangling merge commit) in the stash ref, updating the stash
+ reflog. This is intended to be useful for scripts. It is
+ probably not the command you want to use; see save above.
DISCUSSION
--
diff --git a/git-stash.sh b/git-stash.sh
index 64800b8..62e8cb6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -156,6 +156,41 @@ create_stash () {
die $(gettext Cannot record working tree state)
}
+store_stash () {
+ while test $# != 0
+ do
+ case $1 in
+ -m|--message)
+ shift
+ stash_msg=$1
+ ;;
+ -q|--quiet)
+ quiet=t
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+ test $# == 1 ||
+ die $(eval_gettext \$dashless store\ requires one commit
argument)
+
+ w_commit=$1
+ if test -z $stash_msg
+ then
+ stash_msg=Created via \git stash store\.
+ fi
+
+ # Make sure the reflog for stash is kept.
+ : $GIT_DIR/logs/$ref_stash
+ git update-ref -m $stash_msg $ref_stash $w_commit
+ ret=$?
+ test $ret != 0 test -z $quiet
+ die $(eval_gettext Cannot update \$ref_stash with \$w_commit)
+ return $ret
+}
+
save_stash () {
keep_index=
patch_mode=
@@ -227,12 +262,8 @@ save_stash () {
clear_stash || die $(gettext Cannot initialize stash)
create_stash $stash_msg $untracked
-
- # Make sure the reflog for stash is kept.
- : $GIT_DIR/logs/$ref_stash
-
- git update-ref -m $stash_msg $ref_stash $w_commit ||
- die $(gettext Cannot save the current status)
+ store_stash -m $stash_msg -q $w_commit ||
+ die $(gettext Cannot save the current status)
say Saved working directory and index state $stash_msg
if test -z $patch_mode
@@ -549,6 +580,10 @@ create)
shift
create_stash $* echo $w_commit
;;
+store)
+ shift
+ store_stash $@
+ ;;
drop)
shift
drop_stash $@
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 5dfbda7..75189ec 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -637,4 +637,23 @@ test_expect_success 'stash where working directory
contains HEAD file' '
test_cmp output expect
'
+test_expect_success 'store called with invalid commit' '
+ test_must_fail git stash store foo
+'
+
+test_expect_success 'store updates stash ref and reflog' '
+ git stash clear
+ git reset --hard
+ echo quux bazzy
+ git add bazzy
+ STASH_ID=$(git stash create)
+ git reset --hard
+ ! grep quux bazzy
+ git stash store -m quuxery $STASH_ID
+ test $(cat .git/refs/stash) = $STASH_ID
+ grep $STASH_ID .git/logs/refs/stash
+ git stash pop
+ grep quux bazzy
+'
+
test_done
--
1.8.3.1.441.gd7d6b72.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 v3 3/5] stash: simplify option parser for create
The option parser for create unnecessarily checks $1 inside a case statement that matches $1 in the first place. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- git-stash.sh | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index bbefdf6..64800b8 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -546,10 +546,7 @@ clear) clear_stash $@ ;; create) - if test $# -gt 0 test $1 = create - then - shift - fi + shift create_stash $* echo $w_commit ;; drop) -- 1.8.3.1.441.gd7d6b72.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 v3 0/5] Write a good 'stash store' for autostash
The interface actually makes sense in this iteration, thanks to Junio. Also fix minor nits pointed out by Phil Hord. Thanks. Ramkumar Ramachandra (5): stash doc: add a warning about using create stash doc: document short form -p in synopsis stash: simplify option parser for create stash: introduce 'git stash store' rebase: use 'git stash store' to simplify logic Documentation/git-stash.txt | 13 ++-- git-rebase.sh | 7 ++ git-stash.sh| 52 - t/t3903-stash.sh| 19 + 4 files changed, 74 insertions(+), 17 deletions(-) -- 1.8.3.1.441.gd7d6b72.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 v3 5/5] rebase: use 'git stash store' to simplify logic
rebase has no reason to know about the implementation of the stash. In
the case when applying the autostash results in conflicts, replace the
relevant code in finish_rebase () to simply call 'git stash store'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d0c11a9..17be392 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -153,11 +153,8 @@ finish_rebase () {
then
echo $(gettext 'Applied autostash.')
else
- ref_stash=refs/stash
- $GIT_DIR/logs/$ref_stash
- git update-ref -m autostash $ref_stash $stash_sha1 ||
- die $(eval_gettext 'Cannot store $stash_sha1')
-
+ git stash store -m autostash -q $stash_sha1 ||
+ die $(eval_gettext Cannot store \$stash_sha1)
gettext 'Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run git stash pop or git stash drop it at any time.
--
1.8.3.1.441.gd7d6b72.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/RFC 3/4] git-mw: Adding git-mw.perl script
The V3 is ready, but I am still not sure about what is the best way to do it for this issue though. On 13 June 2013 15:01, Matthieu Moy matthieu@grenoble-inp.fr wrote: benoit.per...@ensimag.fr writes: How does the make Vs make install work? How does a developer run the tool without installing? Well it does not work without installing but I think you know that now :) I first tried: $ ../../bin-wrappers/git mw git: 'mw' is not a git command. See 'git --help'. Then, this first seem OK: $ ./git-mw usage: git mw command args git mw commands are: HelpDisplay help information about git mw Preview Parse and render local file into HTML BUT, this will take the installed GitMediawiki.pm if it is available, and we don't want this (if one hacks GitMediawiki.pm locally, one wants the new hacked to be taken into account without make installing it). To understand better how it works, try adding this in git-mw.perl: print $_\n for @INC; I get this: /home/moy/local/usr-squeeze/share/perl/5.14.2 /home/moy/local/usr-squeeze/src/MediaWiki-API-0.39/blib/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . The '.' is there, but it comes after the hardcoded /home/moy/local/usr-squeeze/share/perl/5.14.2 (which has to comes first, to let the install version be robust to whatever comes after). Thanks for the explanations 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/ ? For now, I have implemented that one : each time you do `make`, if there is changes in GitMediawiki.pm, it gets copied to $GITPERLLIB (perl/blib/lib). But I am not sure it's the best approach here. If we want something entirely self-contained for GitMediawiki, creating a new git wrapper seems like the best way. But then, we could say that since GitMediawiki Makefile uses Git toplevel Makefile, it's not entirely self-contained :/ maybe it's the copying file that makes it weird ? BTW, I just noticed we had a Git::SVN, so perhaps GitMediawiki should be Git::MediaWiki. 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. Making it part of a Git directory / namespace does not really feels right, even if it's how it's done for SVN :/ . Thank you for the all the reviews, (it works for Ensiwiki now \o/) 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
Re: [PATCH 3/3] rebase: use peel_committish() where appropriate
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? $ git rebase master :/v1.8.1 First, rewinding head to replay your work on top of it... Fast-forwarded :/v1.8.1 to master. Huh? The message is wrong, and no end-user can figure out what happened. Even after this patch, there is git checkout -q $onto^0 when detaching the HEAD to that commit. Can that peeling be dropped now (I am not suggesting to drop it in this patch)? Yeah, that can be dropped. 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). -- 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] prompt: squelch error output from cat
Hi Junio,
I see you picked up this patch in branch
'rr/prompt-autostash-breakage-fix'. This patch has actually nothing
to do with autostash, it is a fix for b71dc3e1 (bash-prompt.sh: show
where rebase is at when stopped, 2013-04-25).
Gábor
On Thu, Jun 13, 2013 at 07:16:49PM +0530, Ramkumar Ramachandra wrote:
The files $g/rebase-{merge,apply}/{head-name,msgnum,end} are not
guaranteed to exist. When attempting to cat them, squelch the error
output to get rid of messages like these:
cat: .git/rebase-merge/msgnum: No such file or directory
cat: .git/rebase-merge/end: No such file or directory
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 86a4f3f..07a6218 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -347,9 +347,9 @@ __git_ps1 ()
local step=
local total=
if [ -d $g/rebase-merge ]; then
- b=$(cat $g/rebase-merge/head-name)
- step=$(cat $g/rebase-merge/msgnum)
- total=$(cat $g/rebase-merge/end)
+ b=$(cat $g/rebase-merge/head-name 2/dev/null)
+ step=$(cat $g/rebase-merge/msgnum 2/dev/null)
+ total=$(cat $g/rebase-merge/end 2/dev/null)
if [ -f $g/rebase-merge/interactive ]; then
r=|REBASE-i
else
@@ -357,10 +357,10 @@ __git_ps1 ()
fi
else
if [ -d $g/rebase-apply ]; then
- step=$(cat $g/rebase-apply/next)
- total=$(cat $g/rebase-apply/last)
+ step=$(cat $g/rebase-apply/next 2/dev/null)
+ total=$(cat $g/rebase-apply/last 2/dev/null)
if [ -f $g/rebase-apply/rebasing ]; then
- b=$(cat $g/rebase-apply/head-name)
+ b=$(cat $g/rebase-apply/head-name
2/dev/null)
r=|REBASE
elif [ -f $g/rebase-apply/applying ]; then
r=|AM
--
1.8.3.1.384.g7cec0b4
--
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: support mixed-case aliases
To support mixed-case aliases like:
bM = branch -M
bD = branch -D
add an argument to git_config_with_options() to block the tolower()
calls on key characters.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
The static variable is somewhat disturbing, but it's the most obvious
choice to avoid refactoring config.c heavily. What do you think?
alias.c| 2 +-
builtin/config.c | 8
cache.h| 2 +-
config.c | 13 ++---
t/t1300-repo-config.sh | 7 +++
5 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/alias.c b/alias.c
index eb9f08b..c428592 100644
--- a/alias.c
+++ b/alias.c
@@ -18,7 +18,7 @@ char *alias_lookup(const char *alias)
{
alias_key = alias;
alias_val = NULL;
- git_config(alias_lookup_cb, NULL);
+ git_config_with_options(alias_lookup_cb, NULL, NULL, 1, 1);
return alias_val;
}
diff --git a/builtin/config.c b/builtin/config.c
index 19ffcaf..633b38a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -218,7 +218,7 @@ static int get_value(const char *key_, const char *regex_)
}
git_config_with_options(collect_config, values,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
ret = !values.nr;
@@ -302,7 +302,7 @@ static void get_color(const char *def_color)
get_color_found = 0;
parsed_color[0] = '\0';
git_config_with_options(git_get_color_config, NULL,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
if (!get_color_found def_color)
color_parse(def_color, command line, parsed_color);
@@ -330,7 +330,7 @@ static int get_colorbool(int print)
get_colorbool_found = -1;
get_diff_color_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
- given_config_file, respect_includes);
+ given_config_file, respect_includes, 0);
if (get_colorbool_found 0) {
if (!strcmp(get_colorbool_slot, color.diff))
@@ -438,7 +438,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (git_config_with_options(show_all_config, NULL,
given_config_file,
- respect_includes) 0) {
+ respect_includes, 0) 0) {
if (given_config_file)
die_errno(unable to read config file '%s',
given_config_file);
diff --git a/cache.h b/cache.h
index 820aa05..27d201e 100644
--- a/cache.h
+++ b/cache.h
@@ -1161,7 +1161,7 @@ extern void git_config_push_parameter(const char *text);
extern int git_config_from_parameters(config_fn_t fn, void *data);
extern int git_config(config_fn_t fn, void *);
extern int git_config_with_options(config_fn_t fn, void *,
- const char *filename, int respect_includes);
+ const char *filename, int respect_includes, int
respect_mixedcase);
extern int git_config_early(config_fn_t fn, void *, const char *repo_config);
extern int git_parse_ulong(const char *, unsigned long *);
extern int git_config_int(const char *, const char *);
diff --git a/config.c b/config.c
index 7a85ebd..53ad448 100644
--- a/config.c
+++ b/config.c
@@ -23,6 +23,7 @@ typedef struct config_file {
static config_file *cf;
static int zlib_compression_seen;
+static int allow_mixedcase_keys;
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
@@ -270,7 +271,9 @@ static int get_value(config_fn_t fn, void *data, struct
strbuf *name)
break;
if (!iskeychar(c))
break;
- strbuf_addch(name, tolower(c));
+ if (!allow_mixedcase_keys)
+ c = tolower(c);
+ strbuf_addch(name, c);
}
while (c == ' ' || c == '\t')
@@ -1005,7 +1008,8 @@ int git_config_early(config_fn_t fn, void *data, const
char *repo_config)
}
int git_config_with_options(config_fn_t fn, void *data,
- const char *filename, int respect_includes)
+ const char *filename, int respect_includes,
+ int respect_mixedcase)
{
char *repo_config = NULL;
int ret;
@@ -1018,6 +1022,9 @@ int git_config_with_options(config_fn_t fn, void *data,
data = inc;
}
+ /* For mixed-case aliases */
+ allow_mixedcase_keys = respect_mixedcase ? 1 : 0;
+
/*
* If we have a specific filename, use it. Otherwise, follow the
* regular
git ignore logic does not work as advertised
Hi, I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore file referenced by core.excludesfile that looks like this: # ignore everything by default * # but do not ignore emacs stuff !.emacs.d/ # but than again please ignore backup files inside the .emacs.d folder .emacs.d/backups Now I'd expect git status to show everything in .emacs.d but not to show .emacs.d/backups. However the .emacs.d/backups folder is still shown in git status. I'd say that this is not in line with the man page and might be considered a bug. [1] https://github.com/RichiH/vcsh 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: git ignore logic does not work as advertised
On Sat, Jun 15, 2013 at 06:18:46PM +0200, Thomas Koch wrote: I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore file referenced by core.excludesfile that looks like this: # ignore everything by default * # but do not ignore emacs stuff !.emacs.d/ # but than again please ignore backup files inside the .emacs.d folder .emacs.d/backups Now I'd expect git status to show everything in .emacs.d but not to show .emacs.d/backups. However the .emacs.d/backups folder is still shown in git status. I'd say that this is not in line with the man page and might be considered a bug. 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. -- 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] checkout: do not write full sha1 to reflog
A snippet from a typical git session may look like this: $ git checkout @~3 ... $ git checkout - The reflog entries corresponding to the two checkouts look like: f855138: checkout: moving from bdff0e3a374617dce784f801b97500d9ba2e4705 to co-reflog bdff0e3: checkout: moving from co-reflog to HEAD~3 There is no need to write the full SHA-1 to the user-visible reflog; use find_unique_abbrev() to shorten the first line like: f855138: checkout: moving from bdff0e3 to co-reflog Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- builtin/checkout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index f5b50e5..41b1929 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -619,7 +619,7 @@ 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); + old_desc = find_unique_abbrev(old-commit-object.sha1, DEFAULT_ABBREV); strbuf_addf(msg, checkout: moving from %s to %s, old_desc ? old_desc : (invalid), new-name); -- 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
[PATCH 0/2] Slightly prettier reflog message from checkout
[1/2] is important. [2/2] is a minor prettification, that wouldn't have been possible without [1/2]. Thanks. Ramkumar Ramachandra (2): sha1_name: stop hard-coding 40-character hex checks checkout: do not write full sha1 to reflog builtin/checkout.c | 2 +- sha1_name.c| 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 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
[PATCH 1/2] sha1_name: stop hard-coding 40-character hex checks
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().
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)) {
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)
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
Re: [PATCH 0/2] Slightly prettier reflog message from checkout
Ramkumar Ramachandra wrote: [1/2] is important. [2/2] is a minor prettification, that wouldn't have been possible without [1/2]. I forgot to mention: some tests fail, and I'm investigating. This is an early preview. -- 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
git log: Add a switch to limit the number of displayed lines from the commit messages
Dear git folks, 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. The switch `--format=oneline` exists already. Unfortunately a lot of commits do not have a informative enough summary, so the first lines of the commit message are still needed/desired to understand the commit more. Could a switch be added, like `--commit-message-lines` (sorry for not coming up with something better) to limit the number of displayed lines? That would be great! For older git versions, do you know of editor/pager options to achieve this? Thanks, Paul signature.asc Description: This is a digitally signed message part
Re: git log: Add a switch to limit the number of displayed lines from the commit messages
Hi Paul, Paul Menzel wrote: 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. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SSL socks proxy list: CONNECTABLE 100%
24.21.139.76:9855 173.57.153.187:62189 96.43.245.75:26101 24.107.48.229:8169 75.136.147.231:4351 SSL socks proxy list: CONNECTABLE 100% More socks at: http://actualproxy.biz/ -- View this message in context: http://git.661346.n2.nabble.com/Using-socks-proxy-with-git-for-http-s-transport-tp7579041p7589492.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] show-ref.c: Add missing call to git_config()
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. In order to enable such usage, add the missing call to git_config() from cmd_show_ref(). Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- builtin/show-ref.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/show-ref.c b/builtin/show-ref.c index 8d9b76a..95f5ca9 100644 --- a/builtin/show-ref.c +++ b/builtin/show-ref.c @@ -191,6 +191,8 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix) if (argc == 2 !strcmp(argv[1], -h)) usage_with_options(show_ref_usage, show_ref_options); + git_config(git_default_config, NULL); + argc = parse_options(argc, argv, prefix, show_ref_options, show_ref_usage, PARSE_OPT_NO_INTERNAL_HELP); -- 1.8.3 -- 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] pack-refs.c: Add missing call to git_config()
At present, 'git pack-refs' ignores any attempt to set config variables (e.g. core.checkstat) from the command line using the -c option to git. In order to enable such usage, add the missing call to git_config() from cmd_pack_refs(). Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- builtin/pack-refs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c index b20b1ec..ade1ae5 100644 --- a/builtin/pack-refs.c +++ b/builtin/pack-refs.c @@ -15,6 +15,9 @@ int cmd_pack_refs(int argc, const char **argv, const char *prefix) OPT_BIT(0, prune, flags, N_(prune loose refs (default)), PACK_REFS_PRUNE), OPT_END(), }; + + git_config(git_default_config, NULL); + if (parse_options(argc, argv, prefix, opts, pack_refs_usage, 0)) usage_with_options(pack_refs_usage, opts); return pack_refs(flags); -- 1.8.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add missing calls to git_config()
Hi Junio,
I recently had need to use the '-c' option to git in order to
set some config variables from the command line; specifically
with 'git show-ref' and 'git pack-refs'. I haven't looked to
see if any other commands need similar attention, but:
$ git grep 'cmd_.*(int argc' -- builtin | wc -l
109
$ git grep 'git_config(' -- builtin | wc -l
80
$
... maybe. ;-)
[I did think about separating the command line processing from
the config file processing; maybe some commands could accept
config settings from the command line, but do not need/want
the regular config file processing? *dunno*.]
ATB,
Ramsay Jones
Ramsay Jones (2):
show-ref.c: Add missing call to git_config()
pack-refs.c: Add missing call to git_config()
builtin/pack-refs.c | 3 +++
builtin/show-ref.c | 2 ++
2 files changed, 5 insertions(+)
--
1.8.3
--
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 00/12] Fix some reference-related races
Michael Haggerty wrote:
*This patch series must be built on top of mh/reflife.*
[...]
The other problem was that the for_each_ref() functions will die if
the ref cache that they are iterating over is freed out from under
them. This problem is solved by using reference counts to avoid
freeing the old packed ref cache (even if it is no longer valid) until
all users are done with it.
Yes, I found exactly this happened to me on cygwin, earlier this week,
with the previous version of this code. After seeing this mail, I had
decided not to describe the failure on the old version, but wait and
test this version instead.
This version is a great improvement, but it still has some failures on
cygwin. So, it may be worth (briefly) describing the old failure anyway!
Note that several tests failed, but I will only mention t3211-peel-ref.sh
tests #7-8.
$ pwd
/home/ramsay/git/t/trash directory.t3211-peel-ref
$
$ ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
5 [main] git 3540 _cygtls::handle_exceptions: Error while dumping state
(p
robably corrupted stack)
Segmentation fault (core dumped)
$
The stack-trace for the faulting code looks something like:
cmd_show_ref()
for_each_ref(show_ref, NULL)
do_for_each_ref(ref_cache, , show_ref, 0, 0, NULL)
do_for_each_entry(ref_cache, , do_one_ref, data)
do_for_each_entry_in_dirs(packed_dir, loose_dir, do_one_ref, data)
*dfeeid() recursive calls*
do_one_ref(entry, data)
show_ref(refs/outside/foo, sha1, NULL) [2nd match]
peel_ref(refs/outside/foo, sha1)
peel_entry(entry, 0)
peel_object(name, sha1)
deref_tag_noverify(o)
parse_object(sha1 eb0e854c2...)
lookup_replace_object(sha1)
do_lookup_replace_object(sha1)
prepare_replace_object()
[un-indent here!]
for_each_replace_ref(register_replace_ref, NULL)
do_for_each_ref(ref_cache, refs/replace, fn, 13, 0, NULL)
do_for_each_entry(ref_cache, refs/replace, fn, data)
get_packed_refs(ref_cache)
clear_packed_ref_cache(ref_cache) *free_ref_entries etc*
** return to show_ref() [2nd match] above **
** return to recursive dfeeid() call in original iteration
** dir1-entries has been free()-ed and reused = segmentation fault
[dir1-entries == 0x64633263 = dc2c = part of sha1 for refs/outside/foo]
So, the nested replace-reference-iteration causes the ref_cache to be
freed out from under the initial show-ref iteration, so this works:
$ GIT_NO_REPLACE_OBJECTS=1 ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
You may be wondering why clear_packed_ref_cache() is called? Well, that
is because stat_validity_check() *incorrectly* indicates that the
packed-refs file has changed. Why does it do that? Well, this is one
more example of the problems caused by the cygwin schizophrenic stat()
functions. :( [ARGH]
At this point, I tried running 'git show-ref' with core.checkstat set
on the command line; but that didn't work! I had to fix show-ref and
re-build git, and then, this works:
$ ../../bin-wrappers/git -c core.checkstat=minimal -c core.trustctime=f
alse show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
Now, turning to the new code, t3211-peel-ref.sh test #7 now works, but
test #8 still fails...
$ ./t3211-peel-ref.sh -i -v
...
ok 7 - refs are peeled outside of refs/tags (old packed)
expecting success:
git pack-refs --all
cp .git/packed-refs fully-peeled
git branch yadda
git pack-refs --all
git branch -d yadda
test_cmp fully-peeled .git/packed-refs
fatal: internal error: packed-ref cache cleared while locked
not ok 8 - peeled refs survive deletion of packed ref
#
# git pack-refs --all
# cp .git/packed-refs fully-peeled
# git branch yadda
# git pack-refs --all
# git branch -d yadda
[PATCH] tests: allow sha1's as part of the path
When running 'make test' from a path such as
.../daily-build/master@bdff0e3a374617dce784f801b97500d9ba2e4705, the
logic in fuzz.sed as generated by t5105-request-pull.sh was backwards,
replacing object names before replacing urls, making the test fail.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
t/t5150-request-pull.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 432f98c..1afa0d5 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -80,12 +80,12 @@ test_expect_success 'setup: two scripts for reading pull
requests' '
cat -EOT fuzz.sed
#!/bin/sed -nf
+ s/$downstream_url_for_sed/URL/g
s/$_x40/OBJECT_NAME/g
s/A U Thor/AUTHOR/g
s/[-0-9]\{10\} [:0-9]\{8\} [-+][0-9]\{4\}/DATE/g
s/[^ ].*/SUBJECT/g
s/ [^ ].* (DATE)/ SUBJECT (DATE)/g
- s/$downstream_url_for_sed/URL/g
s/for-upstream/BRANCH/g
s/mnemonic.txt/FILENAME/g
s/^version [0-9]/VERSION/
--
1.8.2.4.g940421e
--
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] GIT-VERSION-GEN: support non-standard $GIT_DIR path
make and make test both work when $GIT_DIR isn't .git, but make dist included a bogus GIT-VERSION-FILE. Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- I'm doing daily builds of git, using many workers and a shared git.git, with per-worker checkouts, it would be really useful if GIT-VERSION-GEN actually supports this and doesn't generate a fairly bogus GIT-VERSION-FILE. GIT-VERSION-GEN | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 390782f..7dcca28 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -11,7 +11,7 @@ LF=' if test -f version then VN=$(cat version) || VN=$DEF_VER -elif test -d .git -o -f .git +elif test -d .git -o -f .git -o test -d $GIT_DIR VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null) case $VN in *$LF*) (exit 1) ;; -- 1.8.2.4.g940421e -- 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
REQUEST PULL: git-gui
The following changes since commit f6dd784ed4c1705d465b1238f9a5971f2733e582: git-gui 0.17 (2012-10-17 21:57:29 +0100) are available in the git repository at: git://repo.or.cz/git-gui.git tags/gitgui-0.18.0 for you to fetch changes up to 8a383db4b28059becc3ebfd1b402299e34c3151f: git-gui 0.18 (2013-06-15 23:53:34 +0100) git-gui 0.18.0 Christian Couder (1): Makefile: replace echo 1... with echo ... Grahack (1): French translation:Â copy - copie. Heiko Voigt (1): git-gui: allow \ No newline at end of file for linewise staging John Keeping (1): git-gui: fix file name handling with non-empty prefix Kirill Smelkov (1): git-gui: Fix parsing of rev path-which-not-present-in-worktree Pat Thoyts (4): git-gui: fix the mergetool launcher for the Beyond Compare tool. git-gui: change dialog button positions for Windows to suit platform. git-gui: avoid an error message when removing the last remote git-gui 0.18 Stefan Haller (1): git-gui: bring wish process to front on Mac GIT-VERSION-GEN | 2 +- Makefile | 6 +++--- git-gui.sh| 27 +-- lib/choose_repository.tcl | 4 +++- lib/diff.tcl | 11 +-- lib/mergetool.tcl | 4 ++-- lib/remote.tcl| 6 -- po/fr.po | 2 +- 8 files changed, 40 insertions(+), 22 deletions(-) -- 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] git-gui: bring Wish process to front on Mac
On 14 June 2013 18:54, Junio C Hamano gits...@pobox.com wrote: Stefan Haller ste...@haller-berlin.de writes: On Mac OS X, any application that is started from the Terminal will open behind all running applications; as a work-around, manually bring ourselves to the front. (Stolen from gitk, commit 76bf6ff93e.) We do this as the very first thing, so that any message boxes that might pop up during the rest of the startup sequence are actually seen by the user. Signed-off-by: Stefan Haller ste...@haller-berlin.de --- Pat, is there any progress on this? I do not mind, and I actually would prefer, a pull request early in the development cycle. yep - I applied this and a couple of others and sent up a pull request now. I see there are some commits in git's tree that I don't have on this side so I'll merge those in here shortly. -- 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] unpack-trees: don't shift conflicts left and right
If o-merge is set, the struct traverse_info member conflicts is shifted
left in unpack_callback, then passed through traverse_trees_recursive
to unpack_nondirectories, where it is shifted right before use. Stop
the shifting and just pass the conflict bit mask as is. Rename the
member to df_conflicts to prove that it isn't used anywhere else.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
tree-walk.h| 2 +-
unpack-trees.c | 18 +++---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/tree-walk.h b/tree-walk.h
index 2bf0db9..ae04b64 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -46,7 +46,7 @@ struct traverse_info {
int pathlen;
struct pathspec *pathspec;
- unsigned long conflicts;
+ unsigned long df_conflicts;
traverse_callback_t fn;
void *data;
int show_all_errors;
diff --git a/unpack-trees.c b/unpack-trees.c
index 57b4074..b27f2a6 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -464,7 +464,7 @@ static int traverse_trees_recursive(int n, unsigned long
dirmask,
newinfo.pathspec = info-pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p) + 1;
- newinfo.conflicts |= df_conflicts;
+ newinfo.df_conflicts |= df_conflicts;
for (i = 0; i n; i++, dirmask = 1) {
const unsigned char *sha1 = NULL;
@@ -565,17 +565,12 @@ static int unpack_nondirectories(int n, unsigned long
mask,
{
int i;
struct unpack_trees_options *o = info-data;
- unsigned long conflicts;
+ unsigned long conflicts = info-df_conflicts | dirmask;
/* Do we have *only* directories? Nothing to do */
if (mask == dirmask !src[0])
return 0;
- conflicts = info-conflicts;
- if (o-merge)
- conflicts = 1;
- conflicts |= dirmask;
-
/*
* Ok, we've filled in up to any potential index entry in src[0],
* now do the rest.
@@ -807,13 +802,6 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
/* Now handle any directories.. */
if (dirmask) {
- unsigned long conflicts = mask ~dirmask;
- if (o-merge) {
- conflicts = 1;
- if (src[0])
- conflicts |= 1;
- }
-
/* special case: diff-index --cached looking at a tree */
if (o-diff_index_cached
n == 1 dirmask == 1 S_ISDIR(names-mode)) {
@@ -832,7 +820,7 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
}
}
- if (traverse_trees_recursive(n, dirmask, conflicts,
+ if (traverse_trees_recursive(n, dirmask, mask ~dirmask,
names, info) 0)
return -1;
return mask;
--
1.8.3
--
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] unpack-trees: don't shift conflicts left and right
René Scharfe rene.scha...@lsrfire.ath.cx writes:
If o-merge is set, the struct traverse_info member conflicts is shifted
left in unpack_callback, then passed through traverse_trees_recursive
to unpack_nondirectories, where it is shifted right before use.
@@ -807,13 +802,6 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
/* Now handle any directories.. */
if (dirmask) {
- unsigned long conflicts = mask ~dirmask;
- if (o-merge) {
- conflicts = 1;
- if (src[0])
- conflicts |= 1;
- }
-
/* special case: diff-index --cached looking at a tree */
if (o-diff_index_cached
n == 1 dirmask == 1 S_ISDIR(names-mode)) {
@@ -832,7 +820,7 @@ static int unpack_callback(int n, unsigned long mask,
unsigned long dirmask, str
}
}
- if (traverse_trees_recursive(n, dirmask, conflicts,
+ if (traverse_trees_recursive(n, dirmask, mask ~dirmask,
names, info) 0)
return -1;
return mask;
This loses the bottom bit (i.e. are we merging and do have an index
entry?) passed to traverse_trees_recursive(), but when that bitmask
comes back to our callback, we immediately discard the bottom bit by
shifting before using it in unpack_nondirectories(), so this seems a
valid clean-up.
One thing renaming df_conficts to conflicts really proves is that
this field is not used by the traverse_trees machinery at all.
Before this patch, the bits in conflicts (now df_conflicts) mask had
the semantics that is not consistent with the dirmask/mask the
tree-walk machinery uses to communicate with its callers and
callbacks. Everything in tree-walk.[ch] is about walk N trees,
and bit 0 of dirmask and mask always means the first tree, not
first tree, or in index if the callback is doing a merge, which
is used in the conflicts field before this patch.
I think the true source of the confusion is that the conflicts
field does not logically belong there. It is not needed in the
general walk N trees machinery.
The information is only useful for the unpack_trees callback, and
info-data is a more appropriate place to hang such a callback
specific data.
Perhaps we should use info-data field to point at
struct {
struct unpack_trees_options *o;
unsigned long df_conflict;
};
and get rid of info-conflicts field?
--
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. ... 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. One design principle I would use as a yardstick is to see any code that deliberately lose information to achieve something as highly suspicious. You can discard extra information when you read and use, if you do not need it, but if you do not record it in the first place, you cannot later enhance the reader to take advantage of it. In general, whenever you see yourself _discarding_ information to solve an issue, you should carefully ask yourself if that is the right solution. I wish we can make sure contributors can learn various design principles we have benefited from over the course of this project much better. But it is a bit difficult to _teach_ others. Writing them down is difficult, not because the rules are vague, but because they are like air. I am sure regular contributors with good design taste share this sentiment. You will know a violation of them when you see one, you naturally stick to them yourself without even having to think about them, but enumerating them without seeing concrete issues takes effort. And this lets squash multiple --fixup/--squash happened to realize that we try not to deliberately lose information is one of them. 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 v3 0/5] Write a good 'stash store' for autostash
Ramkumar Ramachandra artag...@gmail.com writes: Ramkumar Ramachandra (5): stash doc: add a warning about using create stash doc: document short form -p in synopsis stash: simplify option parser for create stash: introduce 'git stash store' rebase: use 'git stash store' to simplify logic Looked sensible overall. I briefly debated myself if git stash store even needs its own error message that needs to be squelched with -q (as there is no reason for the end user to invoke it), but I think it does not matter that much, and we can remove that part fairly easily before it hits 'next'. Will queue (but I am not on my main machine today, so not very soon). 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 0/2] Slightly prettier reflog message from checkout
Ramkumar Ramachandra artag...@gmail.com writes: [1/2] is important. [2/2] is a minor prettification, that wouldn't have been possible without [1/2]. Thanks. Ramkumar Ramachandra (2): sha1_name: stop hard-coding 40-character hex checks checkout: do not write full sha1 to reflog builtin/checkout.c | 2 +- sha1_name.c| 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) I view the two codepaths touched by these patches the other way around. 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). That is a more important design decision between the two codepaths. 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. So I am fairly strongly negative on both changes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 4/4] git-mw: Add preview subcommand into git mw.
From: Benoit Person benoit.per...@ensimag.fr
Add the subcommand to 'git-mw.perl'.
Add a new constant in GitMediawiki.pm 'HTTP_CODE_PAGE_NOT_FOUND'.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
changes from V2:
- Remove the --blob option, distinction between files and blobs is now
automatic.
- Add a --verbose option to output more information on what's going on.
- Rewrote the doc and the commit message.
- Rewrote of the template retrieving code (see 'get_template' sub).
- Use a configuration variable to define the content ID search in the
template. Default value set as 'bodyContent' since it seems more standard
than 'mw-content-text'.
- Final content is now saved as utf-8 to solve encoding issues.
- Perlcritic changes:
- All 'print's specify their output streams.
-- Same useless warnings left in git-remote-mediawiki.perl after
célestin's
work and git-mw.perl after this patch :) .
contrib/mw-to-git/GitMediawiki.pm | 3 +-
contrib/mw-to-git/git-mw.perl | 303 +-
2 files changed, 304 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
index beae6d0..d1f2c41 100644
--- a/contrib/mw-to-git/GitMediawiki.pm
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -19,7 +19,7 @@ require Exporter;
# Methods which can be called as standalone functions as well:
@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
- EMPTY HTTP_CODE_OK);
+ EMPTY HTTP_CODE_OK HTTP_CODE_PAGE_NOT_FOUND);
}
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
@@ -30,6 +30,7 @@ use constant EMPTY = q{};
# HTTP codes
use constant HTTP_CODE_OK = 200;
+use constant HTTP_CODE_PAGE_NOT_FOUND = 404;
sub clean_filename {
my $filename = shift;
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
index 320c00e..0b83108 100644
--- a/contrib/mw-to-git/git-mw.perl
+++ b/contrib/mw-to-git/git-mw.perl
@@ -12,10 +12,41 @@ use strict;
use warnings;
use Getopt::Long;
+use URI::URL qw(url);
+use LWP::UserAgent;
+use HTML::TreeBuilder;
+
+use Git;
+use MediaWiki::API;
+use GitMediawiki qw(smudge_filename connect_maybe
+ EMPTY HTTP_CODE_PAGE_NOT_FOUND);
+
+# By default, use UTF-8 to communicate with Git and the user
+binmode STDERR, ':encoding(UTF-8)';
+binmode STDOUT, ':encoding(UTF-8)';
+
+#preview parameters
+my $file_name = EMPTY;
+my $remote_name = EMPTY;
+my $preview_file_name = EMPTY;
+my $autoload = 0;
+my $verbose = 0;
+sub file {
+ $file_name = shift;
+ return $file_name;
+}
my %commands = (
'help' =
- [\help, {}, \help]
+ [\help, {}, \help],
+ 'preview' =
+ [\preview, {
+ '' = \file,
+ 'output|o=s' = \$preview_file_name,
+ 'remote|r=s' = \$remote_name,
+ 'autoload|a' = \$autoload,
+ 'verbose|v' = \$verbose
+ }, \preview_help]
);
# Search for sub-command
@@ -33,6 +64,275 @@ GetOptions( %{$cmd-[1]},
# Launch command
{$cmd-[0]};
+# Preview Functions
+
+# @TODO : add documentation for verbose option
+sub preview_help {
+ print {*STDOUT} 'END';
+USAGE: git mw preview [--remote|-r remote name] [--autoload|-a]
+ [--output|-o output filename] [--verbose|-v]
+ blob | filename
+
+DESCRIPTION:
+Preview is an utiliy to preview local content of a mediawiki repo as if it was
+pushed on the remote.
+
+For that, preview searches for the remote name of the current branch's upstream
+if --remote is not set. If that remote is not found or if it is not a
mediawiki,
+it lists all mediawiki remotes configured and asks you to replay your command
+with the --remote option set properly.
+
+Then, it searches for a file named 'filename'. If it's not found in the current
+dir, it will assume it's a blob.
+
+The content retrieved in the file (or in the blob) will then be parsed by the
+distant mediawiki and combined with a template retrieved from the mediawiki.
+
+Finally, preview will save the HTML result in a file. and autoload it in your
+default web browser if the option --autoload is present.
+
+OPTIONS:
+ -r remote name, --remote remote name
+ If the remote is a mediawiki, the template and the parse engine
used for
+ the preview will be those of that remote.
+ If not, a list of valid remotes will be shown.
+
+ -a, --autoload
+ Try to load the HTML output in a new tab (or new window) of
your default
+ web browser.
+
+ -o output filename, --output output
[PATCH V3 1/4] git-mw: Introduction of GitMediawiki.pm
From: Benoit Person benoit.per...@ensimag.fr
GitMediawiki.pm enable code factoring between several scripts in mw-to-git.
To make it usable in scripts (ie: accessible in @INC) it adds two targets
(copy_pm install_pm) into the Makefile, one for tests and one for
installation.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
changes from the V2:
- Add a way to test, without installation, code that uses GitMediawiki.pm.
contrib/mw-to-git/GitMediawiki.pm | 24
contrib/mw-to-git/Makefile| 26 +++---
2 files changed, 47 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/GitMediawiki.pm
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
new file mode 100644
index 000..8a0ffc7
--- /dev/null
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -0,0 +1,24 @@
+package GitMediawiki;
+
+use 5.008;
+use strict;
+use Git;
+
+BEGIN {
+
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
+
+# Totally unstable API.
+$VERSION = '0.01';
+
+require Exporter;
+
+@ISA = qw(Exporter);
+
+@EXPORT = ();
+
+# Methods which can be called as standalone functions as well:
+@EXPORT_OK = ();
+}
+
+1; # Famous last words
\ No newline at end of file
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index 1fb2424..b0c7cf2 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -4,16 +4,36 @@
#
## Build git-remote-mediawiki
+GIT_MEDIAWIKI_PM=GitMediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+INSTLIBDIR=$(shell $(MAKE) -C $(GIT_ROOT_DIR)/perl \
+-s --no-print-directory instlibdir)
all: build
-build install clean:
+copy_pm:
+ cp $(GIT_MEDIAWIKI_PM) $(GIT_ROOT_DIR)/perl/blib/lib/
+
+install_pm:
+ cp $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)
+
+build: copy_pm
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+build-perl-script
+
+install: install_pm
$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
-$@-perl-script
+install-perl-script
+
+clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+clean-perl-script
+ rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM) \
+ $(GIT_ROOT_DIR)/perl/blib/lib/$(GIT_MEDIAWIKI_PM)
+
perlcritic:
- perlcritic -2 *.perl
+ perlcritic -2 *.perl
\ No newline at end of file
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/4] git-mw: Adding git-mw command
From: Benoit Person benoit.per...@ensimag.fr
Add the new git-mw command, with its 'help' subcommand as an example. Argument
parsing and subcommand choice is based on git-svn.perl.
Update Makefile to build, install and clean both scripts now (git-mw.perl and
git-remote-mediawiki.perl).
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
changes from V2:
- Perlcritic changes:
- Update for loops style to a more perlish one.
- All 'print's specify their output streams.
contrib/mw-to-git/Makefile| 7 ---
contrib/mw-to-git/git-mw.perl | 46 +++
2 files changed, 50 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/git-mw.perl
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index b0c7cf2..fe02c7e 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -6,6 +6,7 @@
GIT_MEDIAWIKI_PM=GitMediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
+SCRIPT_PERL+=git-mw.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
@@ -22,15 +23,15 @@ install_pm:
cp $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)
build: copy_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
build-perl-script
install: install_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
install-perl-script
clean:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
clean-perl-script
rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM) \
$(GIT_ROOT_DIR)/perl/blib/lib/$(GIT_MEDIAWIKI_PM)
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..320c00e
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+# Copyright (C) 2013
+# Benoit Person benoit.per...@ensimag.imag.fr
+# Celestin Matte celestin.ma...@ensimag.imag.fr
+# License: GPL v2 or later
+
+# Set of tools for git repo with a mediawiki remote.
+# Documentation bugtracker: https://github.com/moy/Git-Mediawiki/
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+
+my %commands = (
+ 'help' =
+ [\help, {}, \help]
+);
+
+# Search for sub-command
+my $cmd = $commands{'help'};
+for (0..@ARGV) {
+ if (defined $commands{$ARGV[$_]}) {
+ $cmd = $commands{$ARGV[$_]};
+ splice @ARGV, $_, 1;
+ last;
+ }
+};
+GetOptions( %{$cmd-[1]},
+ 'help|h' = \{$cmd-[2]});
+
+# Launch command
+{$cmd-[0]};
+
+## Help Functions
##
+
+sub help {
+ print {*STDOUT} 'END';
+usage: git mw command args
+
+git mw commands are:
+helpDisplay help information about git mw
+END
+ exit;
+}
\ No newline at end of file
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/4] git-mw: Move some functions from git-remote-mediawiki.perl to GitMediawiki.pm
From: Benoit Person benoit.per...@ensimag.fr
Move and rename subs 'mediawiki_clean_filename' into 'clean_filename',
'mediawiki_smudge_filename' into 'smudge_filename' and
'mw_connect_maybe' into 'connect_maybe' since we have a cleaner namespace in
a perl module.
Move constants 'EMPTY', 'SLASH_REPLACEMENT' and 'HTTP_CODE_OK'.
Remove side effects in those functions to provide a cleaner API.
Update git-remote-mediawiki for those changes.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
changes from the V2:
- Move more constants to GitMediawiki.pm.
- Remove the encapsulation of Git::config calls into a git_cmd_try one.
contrib/mw-to-git/GitMediawiki.pm | 77 +-
contrib/mw-to-git/git-remote-mediawiki.perl | 85 +
2 files changed, 89 insertions(+), 73 deletions(-)
diff --git a/contrib/mw-to-git/GitMediawiki.pm
b/contrib/mw-to-git/GitMediawiki.pm
index 8a0ffc7..beae6d0 100644
--- a/contrib/mw-to-git/GitMediawiki.pm
+++ b/contrib/mw-to-git/GitMediawiki.pm
@@ -18,7 +18,82 @@ require Exporter;
@EXPORT = ();
# Methods which can be called as standalone functions as well:
-@EXPORT_OK = ();
+@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
+}
+
+# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
+use constant SLASH_REPLACEMENT = '%2F';
+
+# Used to test for empty strings
+use constant EMPTY = q{};
+
+# HTTP codes
+use constant HTTP_CODE_OK = 200;
+
+sub clean_filename {
+ my $filename = shift;
+ $filename =~ s{@{[SLASH_REPLACEMENT]}}{/}g;
+ # [, ], |, {, and } are forbidden by MediaWiki, even URL-encoded.
+ # Do a variant of URL-encoding, i.e. looks like URL-encoding,
+ # but with _ added to prevent MediaWiki from thinking this is
+ # an actual special character.
+ $filename =~ s/[\[\]\{\}\|]/sprintf(_%%_%x, ord($))/ge;
+ # If we use the uri escape before
+ # we should unescape here, before anything
+
+ return $filename;
+}
+
+sub smudge_filename {
+ my $filename = shift;
+ $filename =~ s{/}{@{[SLASH_REPLACEMENT]}}g;
+ $filename =~ s/ /_/g;
+ # Decode forbidden characters encoded in clean_filename
+ $filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf('%c', hex($1))/ge;
+ return $filename;
+}
+
+sub connect_maybe {
+ my $wiki = shift;
+ if ($wiki) {
+ return $wiki;
+ }
+
+ my $remote_name = shift;
+ my $remote_url = shift;
+ my ($wiki_login, $wiki_password, $wiki_domain);
+
+ $wiki_login = Git::config(remote.${remote_name}.mwLogin);
+ $wiki_password = Git::config(remote.${remote_name}.mwPassword);
+ $wiki_domain = Git::config(remote.${remote_name}.mwDomain);
+
+ $wiki = MediaWiki::API-new;
+ $wiki-{config}-{api_url} = ${remote_url}/api.php;
+ if ($wiki_login) {
+ my %credential = (
+ 'url' = $remote_url,
+ 'username' = $wiki_login,
+ 'password' = $wiki_password
+ );
+ Git::credential(\%credential);
+ my $request = {lgname = $credential{username},
+ lgpassword = $credential{password},
+ lgdomain = $wiki_domain};
+ if ($wiki-login($request)) {
+ Git::credential(\%credential, 'approve');
+ print {*STDERR} qq(Logged in mediawiki user
$credential{username}.\n);
+ } else {
+ print {*STDERR} qq(Failed to log in mediawiki user
$credential{username} on ${remote_url}\n);
+ print {*STDERR} ' (error ' .
+ $wiki-{error}-{code} . ': ' .
+ $wiki-{error}-{details} . )\n;
+ Git::credential(\%credential, 'reject');
+ exit 1;
+ }
+ }
+
+ return $wiki;
}
1; # Famous last words
\ No newline at end of file
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 9ff45fd..3b6422b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -14,6 +14,8 @@
use strict;
use MediaWiki::API;
use Git;
+use GitMediawiki qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
use DateTime::Format::ISO8601;
use warnings;
@@ -23,9 +25,6 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
-# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT = '%2F';
-
# It's not always possible to delete pages (may require some
#
[PATCH V3 0/4] git-remote-mediawiki: new tool to preview local changes without pushing
From: Benoit Person benoit.per...@ensimag.fr The #7 issue on git-mediawiki's issue tracker [1] states that the ability to preview content without pushing would be a nice thing to have. changes from V2: - Add a way to test, without installation, code that uses GitMediawiki.pm. - Move more constants to GitMediawiki.pm - Remove the encapsulation of Git::config calls into a git_cmd_try one. - Remove the --blob option, distinction between files and blobs is now automatic. - Add a --verbose option to output more information on what's going on. - Rewrote the doc and the commit message. - Rewrote of the template retrieving code (see 'get_template' sub). - Use a configuration variable to define the content ID search in the template. Default value set as 'bodyContent' since it seems more standard than 'mw-content-text'. - Final content is now saved as utf-8 to solve encoding issues. - Perlcritic changes: - Update for loops style to a more perlish one. - All 'print's specify their output streams. -- Same useless warnings left in git-remote-mediawiki.perl after célestin's work and git-mw.perl after this patch :) . changes from V1: - add new package GitMediawiki - move some of git-remote-mediawiki functions into the package - update git-remote-mediawiki to use those moved functions - add a hacky-way to install it in the Makefile - use it in the new git mw tool - add a way to give to the preview tool blobs as argument - add a fallback when the upstream's branch remote is not a mediawiki remote - update the `autoload` option to use `git web--browse` and not `xdg-open` - update the way we find the upstream's branch remote name This serie is based on the 'master' branch merged with célestin's patch series. [1] https://github.com/moy/Git-Mediawiki/issues/7 Benoit Person (4): git-mw: Introduction of GitMediawiki.pm git-mw: Move some functions from git-remote-mediawiki.perl to GitMediawiki.pm git-mw: Adding git-mw command git-mw: Add preview subcommand into git mw. contrib/mw-to-git/GitMediawiki.pm | 100 contrib/mw-to-git/Makefile | 29 ++- contrib/mw-to-git/git-mw.perl | 347 contrib/mw-to-git/git-remote-mediawiki.perl | 85 ++- 4 files changed, 485 insertions(+), 76 deletions(-) create mode 100644 contrib/mw-to-git/GitMediawiki.pm create mode 100644 contrib/mw-to-git/git-mw.perl -- 1.8.3.GIT -- 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/3] rebase: guard against missing files in read_basic_state()
On Thu, Jun 13, 2013 at 3:29 PM, Junio C Hamano gits...@pobox.com wrote: Ramkumar Ramachandra artag...@gmail.com writes: A more troublesome is that nobody seems to check the return value of this function. If head-name, onto or orig-head is missing, is that an error condition that should make the callers of read_basic_state stop and refuse to proceed? Since we unconditionally write those three (and 'quiet'), it seems reasonable to require all of them to be there when continuing, so I think you're right that we should fail fast. The way the cascade is used seems to indicate that, but up to the point where it sents $verbose. If and only if head-name, onto, orig-head and quiet can be read in state-dir, verbose in state-dir is checked and only then $verbose is set. Martin, this seems to be from your series around early Feburary 2011. Do you recall why these checks are cascaded this way? I do not offhand think of a good reason. Neither do I. I think the cascading after 'quiet' is just a mistake on my part. The consequences are probably close to none, since if one of earlier commands fail, the other files will probably not be there either. (Not defending it; I'm happy if it gets fixed, e.g. by making it fail fast.) -- 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 00/12] Fix some reference-related races
Thanks for all of the information.
On 06/15/2013 10:13 PM, Ramsay Jones wrote:
Michael Haggerty wrote:
*This patch series must be built on top of mh/reflife.*
[...]
The other problem was that the for_each_ref() functions will die if
the ref cache that they are iterating over is freed out from under
them. This problem is solved by using reference counts to avoid
freeing the old packed ref cache (even if it is no longer valid) until
all users are done with it.
Yes, I found exactly this happened to me on cygwin, earlier this week,
with the previous version of this code. After seeing this mail, I had
decided not to describe the failure on the old version, but wait and
test this version instead.
This version is a great improvement, but it still has some failures on
cygwin. So, it may be worth (briefly) describing the old failure anyway!
Note that several tests failed, but I will only mention t3211-peel-ref.sh
tests #7-8.
$ pwd
/home/ramsay/git/t/trash directory.t3211-peel-ref
$
$ ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
5 [main] git 3540 _cygtls::handle_exceptions: Error while dumping
state (p
robably corrupted stack)
Segmentation fault (core dumped)
$
The stack-trace for the faulting code looks something like:
cmd_show_ref()
for_each_ref(show_ref, NULL)
do_for_each_ref(ref_cache, , show_ref, 0, 0, NULL)
do_for_each_entry(ref_cache, , do_one_ref, data)
do_for_each_entry_in_dirs(packed_dir, loose_dir, do_one_ref, data)
*dfeeid() recursive calls*
do_one_ref(entry, data)
show_ref(refs/outside/foo, sha1, NULL) [2nd match]
peel_ref(refs/outside/foo, sha1)
peel_entry(entry, 0)
peel_object(name, sha1)
deref_tag_noverify(o)
parse_object(sha1 eb0e854c2...)
lookup_replace_object(sha1)
do_lookup_replace_object(sha1)
prepare_replace_object()
[un-indent here!]
for_each_replace_ref(register_replace_ref, NULL)
do_for_each_ref(ref_cache, refs/replace, fn, 13, 0, NULL)
do_for_each_entry(ref_cache, refs/replace, fn, data)
get_packed_refs(ref_cache)
clear_packed_ref_cache(ref_cache) *free_ref_entries etc*
** return to show_ref() [2nd match] above **
** return to recursive dfeeid() call in original iteration
** dir1-entries has been free()-ed and reused = segmentation fault
[dir1-entries == 0x64633263 = dc2c = part of sha1 for refs/outside/foo]
So, the nested replace-reference-iteration causes the ref_cache to be
freed out from under the initial show-ref iteration, so this works:
$ GIT_NO_REPLACE_OBJECTS=1 ../../bin-wrappers/git show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
You may be wondering why clear_packed_ref_cache() is called? Well, that
is because stat_validity_check() *incorrectly* indicates that the
packed-refs file has changed. Why does it do that? Well, this is one
more example of the problems caused by the cygwin schizophrenic stat()
functions. :( [ARGH]
At this point, I tried running 'git show-ref' with core.checkstat set
on the command line; but that didn't work! I had to fix show-ref and
re-build git, and then, this works:
$ ../../bin-wrappers/git -c core.checkstat=minimal -c core.trustctime=f
alse show-ref -d
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/heads/master
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/outside/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/outside/foo^{}
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/base
eb0e854c2cd2511c7571b1a5e3c8b8146193fb30 refs/tags/foo
d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e refs/tags/foo^{}
$
So if I understand correctly, all of the above is *without* the
refcounting changes introduced in mh/ref-races? Is so, then it is not
surprising, as this is exactly the sort of problem that the reference
counting is meant to solve.
Now, turning to the new code, t3211-peel-ref.sh test #7 now works, but
test #8 still fails...
$ ./t3211-peel-ref.sh -i -v
...
ok 7 - refs are peeled outside of refs/tags (old packed)
expecting success:
git pack-refs --all
cp .git/packed-refs fully-peeled
git branch yadda
git pack-refs
Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Two possibilities: (1) Assume that the other thread will produce a more reasonable semantics when finished; perhaps the first line will go away entirely, or maybe it would say something like # Rebasing; head at $commit. Your topic does not _care_ what it would say, so you tweak the status test that is done during rebase so that they ignore the first lines; or You said you didn't want to regress to show senseless information,... Go back and read it again. If you want to avoid regression, the codepath in wt-status.c should compensate for the change to rebase so that it checks $dotest/onto and show what is recorded in there. I agreed with that. What is wrong with the patch I showed in the previous email? Which previous? My message you are responding to was a response to your non-patch message, and tangling the In-reply-to backwards will reach your original patch. Puzzled Smudging is a bad hack, and must only be used as a last resort: when an another topics updates status to say something sensible, it will have to unsmudge the tests. Yes. I just got an impression, from your incessant arguing, that you are resisting the ignore the top as extra work that is not interesting to _me_, while I was trying to see what is the best way to go forward for the _project_. Honestly, I didn't want to waste my time and was trying to come up with a compromise, which would be a small regression to the tests that we will need to fix with the other topic. Because you already said that you are not interested in that topic, I was anticipating that the work to polish the topic would be a lot easier than anything I would have to do with you in this topic, because others are a lot easier to collaborate with than you are, and that is where that suggestion comes from. diff --git a/wt-status.c b/wt-status.c index bf84a86..99c55e3 100644 --- a/wt-status.c +++ b/wt-status.c @@ -1182,7 +1182,7 @@ void wt_status_print(struct wt_status *s) if (!get_sha1(HEAD, sha1) !hashcmp(sha1, state.detached_sha1)) on_what = _(HEAD detached at ); - else + else if (!state.rebase_in_progress) on_what = _(HEAD detached from ); Is this supposed to be on top of your original patch? The primary reason I suggested to special case rebase-in-progress in the how about this patch was because that way, you can have the have builtin/commit.c honor reflog-action much earlier in the series, because what this part of the code would say will not be affected by what is recorded in the reflog. If the above, together with the original patch, makes the code match the expectation of the rebase stops in the middle and then status runs tests, that's also fine. The other topic needs to redo it in either case anyway. Unless we change the first line drastically to say: rebase in progress: rebasing onto $ONTO (or something), I don't think this makes sense. And if we were to do that, why not do it properly like rebase ($N/$M): onto $ONTO, upstream $UPSTREAM, branch $BRANCH? Other people on a different thread are already handling that,... That is the thread I was referring to. So, you have three simple choices now: 1. Accept the simple patch I proposed above. 2. Propose an alternative patch quickly. *Patch*. No more English. 3. Reject all patches, and leave me no choice but to smudge. Which one is it going to be? None of the above. After going back and forth this long, I won't want to pick an incremental from the middle of discussion, so (1) is out. This is not my itch and I am only helping you in a way that the result will not hurt the project, so (2) is not it. But assuming that checkout that is done as an implementation detail in rebase is _not_ checkout from end user's point of view is where we want to go, discarding this series is not something we want to see, either. 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); - Teach builtin/commit.c to pay attention to reflog-action; thanks to the previous step, this will not have to change the tests; - Update the reflog message rebase uses, but again this will not affect wt-status.c at all. would be one way to go. -- 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
