On Sun, Jan 27, 2013 at 8:04 PM, Junio C Hamano wrote:
> Lars Hjemli writes:
>
>> The command also honours the option '--clean' which restricts the set of
>> repos to those which '--dirty' would skip, and '-x' which is used to
>> execute non-git commands.
>
> It might make sense to internally use
On Mon, Jan 28, 2013 at 1:36 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
>>
>> I think I went from one problem
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes
Duy Nguyen writes:
> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
>> Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
>
> I think I went from one problem to another and did not make it clear.
> The reason behind this p
On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen wrote:
> Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
I think I went from one problem to another and did not make it clear.
The reason behind this preference is security. With "a
Translate 11 new messages came from git.pot update
in 46bc403 (l10n: Update git.pot (11 new, 7 removed
messages)).
Signed-off-by: Ralf Thielow
---
po/de.po | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/po/de.po b/po/de.po
index 3779f4
Duy Nguyen writes:
>>> Another thing needs to be done for this to work. The current reading
>>
>> For *what* to work???
>
> The "forbid making our repository depend on objects we do not have but
> we know about afterwe peek submodule odb"
With your "when our object database is contaminated, chec
On Mon, Jan 28, 2013 at 12:54 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
>>> This is not a tangent, but if you want to go this "forbid making our
>>> repository depend on objects we do not have but we know about after
>>> we peek su
Duy Nguyen writes:
> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
>> This is not a tangent, but if you want to go this "forbid making our
>> repository depend on objects we do not have but we know about after
>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>> told
Junio C Hamano writes:
>> Is "grep -n" portable? I didn't find any uses of it elsewhere in the
>> testsuite.
>
> Yes, "-n" is in POSIX. Even though we use it ourselves, "git grep"
> supports it, too.
Ehh even though we *DONT* use it ourselves, ... that is.
I do not think we mind, if its use h
Jonathan Nieder writes:
> Brandon Casey wrote:
>
>> Round 3.
>
> Thanks for a pleasant read. My only remaining observations are
> cosmetic, except for a portability question in Duy's test script, a
> small behavior change when the commit message ends with an
> RFC2822-style header with no traili
On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano wrote:
> This is not a tangent, but if you want to go this "forbid making our
> repository depend on objects we do not have but we know about after
> we peek submodule odb" route [*1*], write_sha1_file() needs to be
> told about has_sha1_file_proper(
Jonathan Nieder writes:
> Brandon Casey wrote:
>
> [...]
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -1021,4 +1021,246 @@ test_expect_success 'cover letter using branch
>> description (6)' '
>> grep hello actual >/dev/null
>> '
>>
>> +append_signoff()
>> +{
>>
On Sun, Jan 27, 2013 at 6:51 PM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
>> Here's the tweak I suggested last time. I think its behavior is
>> slightly better in the "ends with incomplete line" case because it
>> limits the characters examined by is_rfc2822_line() and
>> is_cherry_picke
I'm working on an hg remote helper that uses git notes for the sha1
revision, so that git users can more easily refer to specific commits
when communicating with hg users. Since there may be multiple
concurrent fast-import streams, I write the notes to a private ref
(refs/notes/hg-REMOTE), to be m
รู้เท่าทันกับสถานการณ์ใต้
ต้องเรียกว่า“ยอม”กับการแผนการของกลุ่มก่อเหตุรุนแรงที่พยายามทำให้คนไทยพุทธกับมุสลิมแตกแยก
เข่นฆ่าล้างแค้นเนื่องจากเข้าใจผิด
ซึ่งถ้าหากทั้งสองฝ่ายหลงกลและกระทำการให้เป็นไปตามแผน
ที่วางไว้จะกลายเป็นการ ล้างแค้นที่ไม่มีวันสิ้นสุด
สุดท้ายจังหวัดชายแดนภาคใต
Brandon Casey wrote:
> Round 3.
Thanks for a pleasant read. My only remaining observations are
cosmetic, except for a portability question in Duy's test script, a
small behavior change when the commit message ends with an
RFC2822-style header with no trailing newline and the possibility of
tight
Brandon Casey wrote:
> --- a/log-tree.c
> +++ b/log-tree.c
[...]
> @@ -208,94 +207,6 @@ void show_decorations(struct rev_info *opt, struct
> commit *commit)
> putchar(')');
> }
>
> -/*
> - * Search for "^[-A-Za-z]+: [^@]+@" pattern. It usually matches
> - * Signed-off-by: and Acked-by: l
Brandon Casey wrote:
> From: Nguyễn Thái Ngọc Duy
>
> This is a preparation step for merging with append_signoff from
> sequencer.c
Avoids a small unfreed allocation, too. Neat.
Reviewed-by: Jonathan Nieder
(On the other hand, this means more malloc churn when running
"format-patch -s" on a
Brandon Casey wrote:
[...]
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -1021,4 +1021,246 @@ test_expect_success 'cover letter using branch
> description (6)' '
> grep hello actual >/dev/null
> '
>
> +append_signoff()
> +{
> + C=`git commit-tree HEAD^^{tree} -
Brandon Casey wrote:
> Teach append_signoff to detect whether a blank line exists at the position
> that the signed-off-by line will be added, and avoid adding an additional
> one if one already exists. This is necessary to allow format-patch to add a
> s-o-b to a patch with no commit message wit
Brandon Casey wrote:
> --- a/sequencer.c
> +++ b/sequencer.c
[...]
> @@ -1096,10 +1117,16 @@ void append_signoff(struct strbuf *msgbuf, int
> ignore_footer)
> strbuf_addch(&sob, '\n');
> for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1]
> != '\n'; i--)
>
Brandon Casey wrote:
> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This replaces the previous (slightly broken) logic that checked
whether the sign-off to be appended would be redundant and puts the
fixed logic further down the call-chain next to the rest of footer
David Aguilar writes:
> Okay, cool, so no need to reroll, ya?
It was more like "please don't switch to incremental yet"; I tweaked
the mode_ok in your v2 and pushed out the result on 'pu' again.
There may later be comments from others that make us realize some
patches need to be rerolled, but n
Jonathan Nieder wrote:
> Here's the tweak I suggested last time. I think its behavior is
> slightly better in the "ends with incomplete line" case because it
> limits the characters examined by is_rfc2822_line() and
> is_cherry_picked_from_line() not to include buf[len] (which would
> presumably
On Sun, Jan 27, 2013 at 6:27 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> On Sun, Jan 27, 2013 at 6:08 PM, Junio C Hamano wrote:
>>> I think our works crossed, while I was tweaking the previous series
>>> to push out as part of 'pu' you were already rerolling. Could you
>>> compare th
Brandon Casey wrote:
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -20,6 +20,67 @@
[...]
> static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
[...]
> + /* require at least one blank line */
> + if (!last_char_was_nl || buf[i] != '\n')
> + return 0;
Makes se
David Aguilar writes:
> On Sun, Jan 27, 2013 at 6:08 PM, Junio C Hamano wrote:
>> I think our works crossed, while I was tweaking the previous series
>> to push out as part of 'pu' you were already rerolling. Could you
>> compare this series with what I pushed out and see if anything you
>> mis
Brandon Casey wrote:
> Let's detect "(cherry picked from...)" as part of the footer so that we
> will produce this:
>
>Signed-off-by: A U Thor
>(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>Signed-off-by: C O Mmitter
>
> instead of this:
>
>Signed-off-by: A U Tho
On Sun, Jan 27, 2013 at 6:08 PM, Junio C Hamano wrote:
> I think our works crossed, while I was tweaking the previous series
> to push out as part of 'pu' you were already rerolling. Could you
> compare this series with what I pushed out and see if anything you
> missed? I think I fixed the (a &
David Aguilar writes:
> Use the show_tool_names() function to build lists of all
> the built-in tools supported by difftool and mergetool.
> This frees us from needing to update the documentation
> whenever a new tool is added.
>
> Signed-off-by: David Aguilar
> ---
> Adjusted to use show_tool_n
I think our works crossed, while I was tweaking the previous series
to push out as part of 'pu' you were already rerolling. Could you
compare this series with what I pushed out and see if anything you
missed? I think I fixed the (a && b || c && d) issue in the version
I pushed out, but it is stil
Brandon Casey wrote:
> --- /dev/null
> +++ b/t/t3511-cherry-pick-x.sh
> @@ -0,0 +1,111 @@
> +#!/bin/sh
> +
> +test_description='Test cherry-pick -x and -s'
> +
> +. ./test-lib.sh
> +
> +pristine_detach () {
> + git cherry-pick --quit &&
> + git checkout -f "$1^0" &&
> + git read-tree -
Brandon Casey writes:
> On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder wrote:
>> Brandon Casey wrote:
>>
>>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>>> This is in preparation to unify the append_signoff implementations in
>>> log-tree.c and sequencer.c.
>>
Brandon Casey wrote:
> sequencer.c | 6 --
> 1 file changed, 6 deletions(-)
Nice simplification.
Reviewed-by: Jonathan Nieder
--
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.o
Brandon Casey wrote:
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1024,16 +1024,19 @@ int sequencer_pick_revisions(struct replay_opts *opts)
> static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
> {
> int ch;
> - int hit = 0;
> + int last_char_was_nl, this_char_is
Hi,
Brandon Casey wrote:
> Let's detect "(cherry picked from...)" as part of the footer so that we
> will produce this:
>
>Signed-off-by: A U Thor
>(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>Signed-off-by: C O Mmitter
>
> instead of this:
>
>Signed-off-by: A
Reviewed-by: Jonathan Nieder
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Sun, Jan 27, 2013 at 6:55 PM, Jonathan Nieder wrote:
> For what it's worth, assuming this passes tests,
It passes the tests. Although I doubt the tests are written to catch
this.
builtin/branch.c | 11 ++-
1 f
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Split out from v3's 2/3 as Jonathan suggested.
builtin/branch.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..ea6498b 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ea6498b..30c4545 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -837,9 +837,11 @@ int cmd_branch(int argc, const c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 4 ++--
t/t3200-branch.sh | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 30c4545..ca61c5b 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -859,7 +859,7 @@ int c
From: Nguyễn Thái Ngọc Duy
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Brandon Casey
---
builtin/log.c | 13 +
log-tree.c| 17 +
revision.h| 2 +-
3 files changed, 15 insert
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. Unify on top of the
sequencer.c implementation.
Add a test in t4014 to demonstrate support for non-s-o-b elements in the
commit footer provided by sequence.c:append_sob. Mark test
Teach append_signoff to detect whether a blank line exists at the position
that the signed-off-by line will be added, and avoid adding an additional
one if one already exists. This is necessary to allow format-patch to add a
s-o-b to a patch with no commit message without adding an extra newline.
From: Nguyễn Thái Ngọc Duy
[bc: Squash the tests from Duy's original unify-appending-sob series.
Fix test 90 "signoff: some random signoff-alike" and mark as failing.
Correct behavior should insert a blank line after message body and
signed-off-by.
Add two additional tests:
Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.
Fixes test in t3511.
Signed-off-by: Brandon Casey
---
builtin/commit.c | 2 +-
sequencer.c | 47
Start treating the "(cherry picked from" line added by cherry-pick -x
the same way that the s-o-b lines are treated. Namely, separate them
from the main commit message body with an empty line.
This commit is mostly a code movement, but notice that
has_conforming_footer() was modified, in addition
Add some tests to ensure that 'cherry-pick -s' operates in the following
manner:
* Inserts a blank line before appending a s-o-b to a commit message that
does not contain a s-o-b footer
* Does not mistake first line "subject: description" as a s-o-b footer
* Does not mistake single
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry
picked commit, it does not currently detect the "(cherry picked from..."
that may have been appended by a previous 'cherry-pick -x' as part of the
s-o-b footer and it will insert a blank line before appending a new s-o-b.
Let
Starting with c1e01b0c (commit: More generous accepting of RFC-2822 footer
lines, 2009-10-28), "git commit -s" carefully parses the last paragraph of
each commit message to check if it consists only of RFC2822-style headers,
in which case the signoff will be added as a new line in the same list:
The part of test_commit() may not be appropriate for a tag name.
So let's allow test_commit to accept a fourth argument to specify the tag
name.
Signed-off-by: Brandon Casey
Reviewed-by: Jonathan Nieder
---
t/test-lib-functions.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
This code sequence is somewhat difficult to read. Let's rewrite it
using more descriptive variable names to try to make it easier to
understand.
Signed-off-by: Brandon Casey
---
sequencer.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
in
Round 3.
-Brandon
Brandon Casey (9):
sequencer.c: rework search for start of footer to improve clarity
commit, cherry-pick -s: remove broken support for multiline rfc2822
fields
t/test-lib-functions.sh: allow to specify the tag name to test_commit
t/t3511: add some tests of 'cherry-pi
Use the show_tool_names() function to build lists of all
the built-in tools supported by difftool and mergetool.
This frees us from needing to update the documentation
whenever a new tool is added.
Signed-off-by: David Aguilar
---
Adjusted to use show_tool_names() and reworked the makefile depend
Refactor show_tool_help() so that the tool-finding logic is broken out
into a separate show_tool_names() function.
Signed-off-by: David Aguilar
---
filter_tools renamed to show_tool_names() and simplfied
to use ls -1. show_tool_names() now has a preamble as discussed.
git-mergetool--lib.sh | 6
This code path is only activated when the user does not have a valid
configured tool. Add a message to guide new users towards configuring a
default tool.
Signed-off-by: David Aguilar
---
This now uses a cat << here-doc.
git-mergetool--lib.sh | 7 ++-
1 file changed, 6 insertions(+), 1 del
This is round two of this series.
I think this touched on everything brought up in the code review.
4/4 could use a review as I'm not completely familiar with the
makefile dependencies, though it seems to work correctly.
David Aguilar (4):
mergetool--lib: Simplify command expressions
mergetool
Update variable assignments to always use $(command "$arg")
in their RHS instead of "$(command "$arg")" as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding "echo" and $(command) substitutions completely.
Signed-off-by: David Aguilar
---
I reworded the commit message to
On Tue, Jan 22, 2013 at 12:38 AM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>
>> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
>> This is in preparation to unify the append_signoff implementations in
>> log-tree.c and sequencer.c.
> [...]
>> --- a/sequencer.c
>> ++
David Aguilar writes:
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 267dfe1..f595d26 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -226,13 +226,27 @@ cmd-list.made: cmd-list.perl ../command-list.txt
> $(MAN1_TXT)
> $(PERL_PATH) ./cmd-lis
On Sun, Jan 27, 2013 at 3:32 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> +filter_tools () {
>> + filter="$1"
>> + prefix="$2"
>> + (
>> + cd "$MERGE_TOOLS_DIR" &&
>> + for i in *
>> + do
>> + echo "$i"
>> +
On Tue, Jan 22, 2013 at 12:17 AM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>
>> --- /dev/null
>> +++ b/t/t3511-cherry-pick-x.sh
> [...]
>> +test_expect_failure 'cherry-pick -s inserts blank line after non-conforming
>> footer' '
>
> IIUC this is an illustration of false-positives from messa
Brandon Casey wrote:
>I'll tweak
> the string so it looks like this:
>
> The signed-off-by string should begin with the words Signed-off-by followed
> by a colon and space, and then the signers name and email address. e.g.
> Signed-off-by
David Aguilar writes:
> +filter_tools () {
> + filter="$1"
> + prefix="$2"
> + (
> + cd "$MERGE_TOOLS_DIR" &&
> + for i in *
> + do
> + echo "$i"
> + done
> + ) | sort | while read tool
> + do
> +
Junio C Hamano wrote:
> It is not about a rough estimate nor common commits, though. The
> "everything local" check in question is interested in only one
> thing: are we _clearly_ up to date without fetching anything from
> them?
[...]
> Jonathan Nieder writes:
>> * Why is 49bb805e ("Do not as
John Keeping writes:
> On Sun, Jan 27, 2013 at 12:47:09PM -0800, Junio C Hamano wrote:
>> I remember that I earlier asked somewhere if we want to say "Python
>> 3.x that is older than 3.y is unsupported"
>>
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/213920/focus=213926
>>
David Aguilar writes:
> This code path is only activated when the user does not have a valid
> configured tool. Add a message to guide new users towards configuring a
> default tool.
>
> Signed-off-by: David Aguilar
> ---
> git-mergetool--lib.sh | 9 -
> 1 file changed, 8 insertions(+)
On Sun, Jan 27, 2013 at 01:24:45PM -0800, David Aguilar wrote:
> +filter_tools () {
> + filter="$1"
> + prefix="$2"
> + (
> + cd "$MERGE_TOOLS_DIR" &&
> + for i in *
> + do
> + echo "$i"
> + done
> + ) | sort | whil
wookietreiber writes:
> I have a feature request for `git add` auto completion:
>
> `git add` auto completion suggests all files / directories,
> filtered by nothing. I guess it would be much nicer (as in
> increasing productivity) if it would only suggest unstaged
> content, as reported by `git
On Sun, Jan 27, 2013 at 01:24:46PM -0800, David Aguilar wrote:
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -1,5 +1,6 @@
> #!/bin/sh
> # git-mergetool--lib is a library for common merge tool functions
> +test -z "$MERGE_TOOLS_DIR" &&
> MERGE_TOOLS_DIR=$(git --exec-path)/merge
On Sun, Jan 27, 2013 at 12:47:09PM -0800, Junio C Hamano wrote:
> I remember that I earlier asked somewhere if we want to say "Python
> 3.x that is older than 3.y is unsupported"
>
> http://thread.gmane.org/gmane.comp.version-control.git/213920/focus=213926
>
> but I was told that we will sup
David Aguilar writes:
> +mergetools_txt = mergetools-diff.txt mergetools-merge.txt
> +
> +$(mergetools_txt): mergetools-list.made
> +
> +mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*)
> + $(QUIET_GEN)$(RM) $@ && \
> + $(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../merget
David Aguilar writes:
> Definitely. I learned this the hard way when the tests broke on me while
> working it ;-) My patch rewrites things to always use var=$(command)
> expressions with separate test "$var" evaluating them.
OK; that wasn't clear from the log message.
--
To unsubscribe from t
David Aguilar writes:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into separate functions.
>
> Signed-off-by: David Aguilar
> ---
> git-mergetool--lib.sh | 60
> +--
> 1 file changed, 34 insertions(+), 26 deletions(
Am 27.01.2013 22:24, schrieb David Aguilar:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into separate functions.
>
> Signed-off-by: David Aguilar
> ---
> git-mergetool--lib.sh | 60
> +--
> 1 file changed, 34 inserti
David Aguilar writes:
> Use $(command "$arg") instead of "$(command "$arg")" as the latter is
> harder to read.
Did you miss my comment that this is about RHS of an assignment?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
On Sun, Jan 27, 2013 at 2:08 PM, Johannes Sixt wrote:
> Am 27.01.2013 22:24, schrieb David Aguilar:
>> Use $(command "$arg") instead of "$(command "$arg")" as the latter is
>> harder to read.
>
> If at all, you should restrict yourself to simplify only variable
> assignments. Because this case:
>
Am 27.01.2013 22:24, schrieb David Aguilar:
> Use $(command "$arg") instead of "$(command "$arg")" as the latter is
> harder to read.
If at all, you should restrict yourself to simplify only variable
assignments. Because this case:
> - if test -z "$(get_merge_tool_cmd "$merge_tool")" &&
> +
Refactor show_tool_help() so that the tool-finding logic is broken out
into separate functions.
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 60 +--
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/git-mergetool--lib.sh b
Use the new filter_tools() function to build lists of all
the built-in tools supported by difftool and mergetool.
This frees us from needing to update the documentation
whenever a new tool is added.
Signed-off-by: David Aguilar
---
Documentation/.gitignore | 1 +
Documentation/Makefile
This code path is only activated when the user does not have a valid
configured tool. Add a message to guide new users towards configuring a
default tool.
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/git-merge
Use $(command "$arg") instead of "$(command "$arg")" as the latter is
harder to read. Make the expression in get_merge_tool_cmd() even
simpler by avoiding "echo" completely.
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 40
1 file changed, 16
Refactor the mergetool-lib so that we can reuse it in
Documentation/Makefile. The end result is that the
diff.tool and merge.tool documentation now includes
an auto-generated list of all available tools.
This applies on top of jk/mergetool in pu.
David Aguilar (4):
mergetool--lib: Simplify com
On Sun, Jan 27, 2013 at 12:13 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> I think I'd want to do this with a suffix if at all, so the output would
>> be like this:
>>
>> 'git mergetool --tool=' may be set to one of the following:
>>
>> araxis
>> gvimdiff
>>
Junio C Hamano writes:
> John Keeping writes:
>
>> So I think the answer is "habit, but I probably shouldn't have put it
>> in in this case".
>
> OK, then I'll queue with a local amend to drop the leading
> underscore.
So this is what I will be queuing (I'd appreciate the second set of
eyes, th
John Keeping writes:
> On Sun, Jan 27, 2013 at 12:11:20PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> >> Thanks; will queue and wait for an Ack from Michael.
>> >>
>> >> Does the helper function need to be named with leading underscore,
>> >> though?
>> >
>> > ... Since this is
Matthieu Moy writes:
> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
> below.
I do not think we should aim for easy cut-and-paste, especially when
the real purpose of the change is to train people's fingers; the
message should discouraging cut-and-paste in a case like th
Junio C Hamano writes:
> If we did not care about incurring runtime performance cost, we
> could arrange:
> ...
> Then you can wrap commands whose use we want to limit, perhaps like
> this, in the test framework:
> ...
> sed () {
> ...
> done
> if test -z "$must_
On Sun, Jan 27, 2013 at 12:11:20PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> >> Thanks; will queue and wait for an Ack from Michael.
> >>
> >> Does the helper function need to be named with leading underscore,
> >> though?
> >
> > ... Since this is a script
> > not a library modul
John Keeping writes:
> I think I'd want to do this with a suffix if at all, so the output would
> be like this:
>
> 'git mergetool --tool=' may be set to one of the following:
>
> araxis
> gvimdiff
> gvimdiff2
> mytool(user-defined)
>
John Keeping writes:
>> Thanks; will queue and wait for an Ack from Michael.
>>
>> Does the helper function need to be named with leading underscore,
>> though?
>
> ... Since this is a script
> not a library module I don't feel strongly about it in this case.
That is exactly why I asked.
--
To
Jonathan Nieder writes:
> Jeff King wrote:
>
>> When we look up a sha1 object for reading, we first check
>> packfiles, and then loose objects. If we still haven't found
>> it, we re-scan the list of packfiles in `objects/pack`. This
>> final step ensures that we can co-exist with a simultaneous
On Sun, Jan 27, 2013 at 11:49:39AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > When this change was originally made (0846b0c - git-remote-testpy: hash
> > bytes explicitly , I didn't realised that the "hex" encoding we chose is
> > a "bytes to bytes" encoding so it just fails with a
On Sun, Jan 27, 2013 at 10:03:19AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > 'git mergetool --tool-help' only lists builtin tools, not those that the
> > user has configured via a 'mergetool..cmd' config value. Fix this
> > by inspecting the tools configured in this way and addin
- Ursprungligt meddelande -
> Robin Rosenberg writes:
>
> > Thanks. Feeling a bit studid now.
> >
> > I was actually thinking about using merge to implement stash apply
> > in JGit. What we have is broken so I tried using merge to implement
> > it and them compared to git merge --no-com
John Keeping writes:
> When this change was originally made (0846b0c - git-remote-testpy: hash
> bytes explicitly , I didn't realised that the "hex" encoding we chose is
> a "bytes to bytes" encoding so it just fails with an error on Python 3
> in the same way as the original code.
>
> It is not
John Keeping writes:
> On Sun, Jan 27, 2013 at 11:04:08AM -0800, Junio C Hamano wrote:
>> One more thing that nobody brought up during the previous reviews is
>> if we want to support subset of repositories by allowing the
>> standard pathspec match mechanism. For example,
>>
>> git for-ea
On Sun, Jan 27, 2013 at 11:04:08AM -0800, Junio C Hamano wrote:
> One more thing that nobody brought up during the previous reviews is
> if we want to support subset of repositories by allowing the
> standard pathspec match mechanism. For example,
>
> git for-each-repo -d git diff --name-on
Robin Rosenberg writes:
> Thanks. Feeling a bit studid now.
>
> I was actually thinking about using merge to implement stash apply
> in JGit. What we have is broken so I tried using merge to implement
> it and them compared to git merge --no-commit.. FAIL.
Do you have "cherry-pick"?
In short, "
Thanks. Feeling a bit studid now.
I was actually thinking about using merge to implement stash apply
in JGit. What we have is broken so I tried using merge to implement
it and them compared to git merge --no-commit.. FAIL.
The main difference is of course that I set the merge base to
stash^1, whi
1 - 100 of 129 matches
Mail list logo
