* Re: [PATCH] submodule--helper: set alternateLocation for cloned submodules
From: Stefan Beller @ 2016-12-12 5:35 UTC (permalink / raw)
To: vi0oss; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <12000496-2191-2915-8a9e-fe7c314c5676@gmail.com>
On Sat, Dec 10, 2016 at 5:41 AM, vi0oss <vi0oss@gmail.com> wrote:
> On 12/08/2016 04:38 AM, vi0oss@gmail.com wrote:
>>
>> Third review: missing && in test fixed.
>>
>
> Shall something more be done about this or just wait until the patch gets
> reviewed and integrated?
I have no further comments and think the most recent version you sent
to the list
is fine. However others are invited to comment as well. :)
Thanks,
Stefan
^ permalink raw reply
* [PATCH] submodule--helper: set alternateLocation for cloned submodules
From: vi0oss @ 2016-12-12 2:45 UTC (permalink / raw)
To: gitster; +Cc: git, stefanbeller, Vitaly "_Vi" Shukela
From: "Vitaly \"_Vi\" Shukela" <vi0oss@gmail.com>
In 31224cbdc7 (clone: recursive and reference option triggers
submodule alternates, 2016-08-17) a mechanism was added to
have submodules referenced. It did not address _nested_
submodules, however.
This patch makes all not just the root repository, but also
all submodules (recursively) have submodule.alternateLocation
and submodule.alternateErrorStrategy configured, making Git
search for possible alternates for nested submodules as well.
As submodule's alternate target does not end in .git/objects
(rather .git/modules/qqqqqq/objects), this alternate target
path restriction for in add_possible_reference_from_superproject
relates from "*.git/objects" to just */objects".
New tests have been added to t7408-submodule-reference.
Signed-off-by: Vitaly _Vi Shukela <vi0oss@gmail.com>
---
Notes:
Reviewed by Stefan Beller <sbeller@google.com>
For "maint" branch.
builtin/submodule--helper.c | 19 ++++++++++--
t/t7408-submodule-reference.sh | 66 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 4beeda5..92fd676 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -498,9 +498,9 @@ static int add_possible_reference_from_superproject(
/*
* If the alternate object store is another repository, try the
- * standard layout with .git/modules/<name>/objects
+ * standard layout with .git/(modules/<name>)+/objects
*/
- if (ends_with(alt->path, ".git/objects")) {
+ if (ends_with(alt->path, "/objects")) {
char *sm_alternate;
struct strbuf sb = STRBUF_INIT;
struct strbuf err = STRBUF_INIT;
@@ -583,6 +583,7 @@ static int module_clone(int argc, const char **argv, const char *prefix)
struct strbuf rel_path = STRBUF_INIT;
struct strbuf sb = STRBUF_INIT;
struct string_list reference = STRING_LIST_INIT_NODUP;
+ char *sm_alternate = NULL, *error_strategy = NULL;
struct option module_clone_options[] = {
OPT_STRING(0, "prefix", &prefix,
@@ -672,6 +673,20 @@ static int module_clone(int argc, const char **argv, const char *prefix)
die(_("could not get submodule directory for '%s'"), path);
git_config_set_in_file(p, "core.worktree",
relative_path(path, sm_gitdir, &rel_path));
+
+ /* setup alternateLocation and alternateErrorStrategy in the cloned submodule if needed */
+ git_config_get_string("submodule.alternateLocation", &sm_alternate);
+ if (sm_alternate)
+ git_config_set_in_file(p, "submodule.alternateLocation",
+ sm_alternate);
+ git_config_get_string("submodule.alternateErrorStrategy", &error_strategy);
+ if (error_strategy)
+ git_config_set_in_file(p, "submodule.alternateErrorStrategy",
+ error_strategy);
+
+ free(sm_alternate);
+ free(error_strategy);
+
strbuf_release(&sb);
strbuf_release(&rel_path);
free(sm_gitdir);
diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
index 1c1e289..e159fc5 100755
--- a/t/t7408-submodule-reference.sh
+++ b/t/t7408-submodule-reference.sh
@@ -125,4 +125,70 @@ test_expect_success 'ignoring missing submodule alternates passes clone and subm
)
'
+test_expect_success 'preparing second superproject with a nested submodule plus partial clone' '
+ test_create_repo supersuper &&
+ (
+ cd supersuper &&
+ echo "I am super super." >file &&
+ git add file &&
+ git commit -m B-super-super-initial
+ git submodule add "file://$base_dir/super" subwithsub &&
+ git commit -m B-super-super-added &&
+ git submodule update --init --recursive &&
+ git repack -ad
+ ) &&
+ git clone supersuper supersuper2 &&
+ (
+ cd supersuper2 &&
+ git submodule update --init
+ )
+'
+
+# At this point there are three root-level positories: A, B, super and super2
+
+test_expect_success 'nested submodule alternate in works and is actually used' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ git clone --recursive --reference supersuper supersuper supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ # test superproject has alternates setup correctly
+ test_alternate_is_used .git/objects/info/alternates . &&
+ # immediate submodule has alternate:
+ test_alternate_is_used .git/modules/subwithsub/objects/info/alternates subwithsub &&
+ # nested submodule also has alternate:
+ test_alternate_is_used .git/modules/subwithsub/modules/sub/objects/info/alternates subwithsub/sub
+ )
+'
+
+check_that_two_of_three_alternates_are_used() {
+ test_alternate_is_used .git/objects/info/alternates . &&
+ # immediate submodule has alternate:
+ test_alternate_is_used .git/modules/subwithsub/objects/info/alternates subwithsub &&
+ # but nested submodule has no alternate:
+ test_must_fail test_alternate_is_used .git/modules/subwithsub/modules/sub/objects/info/alternates subwithsub/sub
+}
+
+
+test_expect_success 'missing nested submodule alternate fails clone and submodule update' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ test_must_fail git clone --recursive --reference supersuper2 supersuper2 supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ check_that_two_of_three_alternates_are_used &&
+ # update of the submodule fails
+ test_must_fail git submodule update --init --recursive
+ )
+'
+
+test_expect_success 'missing nested submodule alternate in --reference-if-able mode' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ git clone --recursive --reference-if-able supersuper2 supersuper2 supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ check_that_two_of_three_alternates_are_used &&
+ # update of the submodule succeeds
+ git submodule update --init --recursive
+ )
+'
+
test_done
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v4] gitk: Add Portuguese translation
From: Paul Mackerras @ 2016-12-12 0:35 UTC (permalink / raw)
To: Vasco Almeida; +Cc: git
In-Reply-To: <1462996893-24341-1-git-send-email-vascomalmeida@sapo.pt>
On Wed, May 11, 2016 at 08:01:33PM +0000, Vasco Almeida wrote:
> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
> ---
>
> Oops, fix typo.
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] Gitk Inotify support
From: Paul Mackerras @ 2016-12-12 1:58 UTC (permalink / raw)
To: Florian Schüller; +Cc: git@vger.kernel.org
In-Reply-To: <CAHdOBFpOm3hf4XPjpSZ0+8rVgyKj+e3qT0cecU4j9ms=+chnDg@mail.gmail.com>
On Sat, Jun 11, 2016 at 04:06:36PM +0200, Florian Schüller wrote:
> >From 74d2f4c1ec560b358fb50b8b7fe8282e7e1457b0 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Florian=20Sch=C3=BCller?= <florian.schueller@gmail.com>
> Date: Thu, 9 Jun 2016 22:54:43 +0200
> Subject: [PATCH] first support for inotify
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Just automatically update gitk when working in a terminal on the same repo
>
> Open points for now:
> - release watches for deleted directories seems to
> cause problems in tcl-inotify (so I don't)
> I'm not sure how often that happens in ".git/"
> - I only call "updatecommits" and I don't know if there is a usecase
> where I should be calling "reloadcommits"
Thanks for the patch. It's a nice idea. I think it needs a couple of
improvements, though, to make it work even better:
* Some users might not want this behaviour, so we need an option in
the preferences pane to enable/disable this.
* I would expect that the updates to the files in .git would come in
bursts, so we should probably do something like wait until (say) one
second has elapsed since the last notification, without any more
notifications, before starting the update.
* We probably want to rate-limit the updates, since on a large tree
(e.g. the Linux kernel) the update can take several seconds and the
UI is less responsive during that time.
Paul.
^ permalink raw reply
* Re: [PATCH v3] gitk: Fix missing commits when using -S or -G
From: Paul Mackerras @ 2016-12-12 0:39 UTC (permalink / raw)
To: Stefan Dotterweich; +Cc: git
In-Reply-To: <1f857709-3c47-d4a1-b858-3288347416f8@gmx.de>
On Sat, Jun 04, 2016 at 10:47:16AM +0200, Stefan Dotterweich wrote:
> When -S or -G is used as a filter option, the resulting commit list
> rarely contains all matching commits. Only a certain number of commits
> are displayed and the rest are missing.
>
> "git log --boundary -S" does not return as many boundary commits as you
> might expect. gitk makes up for this in closevargs() by adding missing
> parent (boundary) commits. However, it does not change $numcommits,
> which limits how many commits are shown. In the end, some commits at the
> end of the commit list are simply not shown.
>
> Change $numcommits whenever a missing parent is added.
>
> Signed-off-by: Stefan Dotterweich <stefandotterweich@gmx.de>
Thanks, applied, with slight tweaks to the commit message.
Paul.
^ permalink raw reply
* Re: [PATCH v2 0/2] gitk: Two improvements to the branch context menu
From: Paul Mackerras @ 2016-12-12 0:02 UTC (permalink / raw)
To: Rogier Goossens; +Cc: git
In-Reply-To: <10662590.KWXHt2RUKZ@wiske>
On Sat, Mar 19, 2016 at 07:31:32PM +0100, Rogier Goossens wrote:
> Hi,
>
> Hereby the revised patches.
>
> Changes since v1:
> - Rebased on latest master
> - Made the changes you suggested
> - Moved 'rename branch' menu option above 'delete branch'
> - Cleaned up some code duplication that the previous patches
> introduced.
Thanks, series applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Makefile: create install bin directory
From: Paul Mackerras @ 2016-12-12 0:01 UTC (permalink / raw)
To: Vasco Almeida; +Cc: git
In-Reply-To: <1462470392-19991-1-git-send-email-vascomalmeida@sapo.pt>
On Thu, May 05, 2016 at 05:46:32PM +0000, Vasco Almeida wrote:
> Force creation of destination bin directory. Before this commit, gitk
> would fail to install if this directory didn't already exist.
>
> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Thanks, applied (with slight tweak to commit message).
Paul.
^ permalink raw reply
* Re: [PATCH v3 1/2] gitk: alter the ordering for the "Tags and heads" view
From: Paul Mackerras @ 2016-12-11 23:25 UTC (permalink / raw)
To: Michael Rappazzo; +Cc: git
In-Reply-To: <1459091168-46908-2-git-send-email-rappazzo@gmail.com>
On Sun, Mar 27, 2016 at 11:06:07AM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> Because of this, the list of local refs (heads) can be interrupted by the
> list of remote refs. This change re-orders the view to be: local refs,
> remote refs tracked by local refs, remote refs, tags, and then other refs.
>
> Signed-off-by: Michael Rappazzo <rappazzo@gmail.com>
This all looks OK except for the fact that the loop immediately below
the code you've modified (the loop that adds or deletes lines from the
actual displayed list) relies on the entries being in sorted order.
With your patch the entries are no longer strictly in sorted order, so
that display update loop will have to become a bit smarter too. As it
is, I think that there will be cases where we will delete a lot of
lines and then re-add them. If the user had scrolled the list to a
particular point that was within these deleted lines, the display will
scroll away from that point, which will be annoying.
Paul.
^ permalink raw reply
* [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
We need to track the new commits in uniset, otherwise their and our code
get out of sync.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
Junio, these go on top of my bb/unicode-9.0 branch, please.
Thanks!
update_unicode.sh | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/update_unicode.sh b/update_unicode.sh
index 4c1ec8d..9ca7d8b 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -14,6 +14,11 @@ fi &&
http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
if ! test -d uniset; then
git clone https://github.com/depp/uniset.git
+ else
+ (
+ cd uniset &&
+ git pull
+ )
fi &&
(
cd uniset &&
--
2.7.2
^ permalink raw reply related
* [PATCH 3/3] update_unicode.sh: restore hexadecimal output
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
In-Reply-To: <1481499265-18361-1-git-send-email-dev+git@drbeat.li>
The uniset upstream has decided that decimal numbers are The True Way, so
let's convert them back to the usual format that's closer to the U+nnnn
standard.
The generated unicode_widths.h file again looks exactly the same as two
commits ago.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
update_unicode.sh | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index e595bf8..d7720d5 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -5,6 +5,12 @@
#Mn Nonspacing_Mark a nonspacing combining mark (zero advance width)
#Cf Format a format control character
#
+
+dec_to_hex() {
+ # convert any decimal numbers to 4-digit hex
+ perl -pe 's/(\d+)/sprintf("0x%04X", $1)/ge'
+}
+
UNICODEWIDTH_H=../unicode_width.h
if ! test -d unicode; then
mkdir unicode
@@ -29,7 +35,7 @@ fi &&
make
) &&
UNICODE_DIR=. && export UNICODE_DIR &&
- cat >$UNICODEWIDTH_H <<-EOF
+ dec_to_hex >$UNICODEWIDTH_H <<-EOF
static const struct interval zero_width[] = {
$(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD)
};
--
2.7.2
^ permalink raw reply related
* [PATCH 2/3] update_unicode.sh: remove the plane filters
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
In-Reply-To: <1481499265-18361-1-git-send-email-dev+git@drbeat.li>
The uniset upstream has accepted my patches that eliminate the Unicode
plane offsets from the output in '--32' mode.
Remove the corresponding filter in update_unicode.sh.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
update_unicode.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index 9ca7d8b..e595bf8 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -31,11 +31,10 @@ fi &&
UNICODE_DIR=. && export UNICODE_DIR &&
cat >$UNICODEWIDTH_H <<-EOF
static const struct interval zero_width[] = {
- $(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD |
- grep -v plane)
+ $(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD)
};
static const struct interval double_width[] = {
- $(uniset/uniset --32 eaw:F,W | grep -v plane)
+ $(uniset/uniset --32 eaw:F,W)
};
EOF
)
--
2.7.2
^ permalink raw reply related
* Draft of Git Rev News edition 22
From: Christian Couder @ 2016-12-11 22:24 UTC (permalink / raw)
To: git
Cc: Thomas Ferris Nicolaisen, Jakub Narebski, Markus Jansen,
Johannes Schindelin, Junio C Hamano, Jeff King, Michael Haggerty,
David Aguilar, Dun Peal, Stefan Beller, Robert Dailey,
Jacob Keller
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-22.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/208
You can also reply to this email.
I tried to cc everyone who appears in this edition but maybe I missed
some people, sorry about that.
Thomas, Jakub, Markus (who is now part of the team, welcome Markus!)
and myself plan to publish this edition on Wednesday December 14.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 0/1] Fix a long-standing isatty() problem on Windows
From: Junio C Hamano @ 2016-12-11 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Pranit Bauva
In-Reply-To: <cover.1481454992.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> I finally got a chance to debug the problems with the ever-timing-out
> test runs of `pu` on Windows. Turns out that pb/bisect uncovered a
> really old, really bad bug: on Windows, isatty() does not do what Git
> expects, at least not completely: it detects interactive terminals *and
> character devices*.
Sounds as if somebody who did Windows at Microsoft had a good sense
of humor to mimick the misnamed ENOTTY gotcha ;-)
This is a great find, and a very impactful fix, as redirecting from
/dev/null is how we try to force a "go interactive if talking to
tty" program to realize that it is not talking to a tty.
Thanks.
^ permalink raw reply
* Re: [BUG] Colon in remote urls
From: Philip Oakley @ 2016-12-11 14:51 UTC (permalink / raw)
To: Klaus Ethgen, git
In-Reply-To: <20161211110208.642unp7c2i653sav@ikki.ethgen.ch>
From: "Klaus Ethgen" <Klaus@Ethgen.ch>
To: <git@vger.kernel.org>
> Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:
>> On Sat, 10 Dec 2016, Klaus Ethgen wrote:
>> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:
>> > > There are too many systems out there that use a backslash in path
>> > > names. I
>> > > don't think it is wise to use it also as the quoting character.
>> > Well, the minority, I believe. And only the minority where the command
>> > line git is used anywhere.
>>
>> Please provide evidence for such bold assumptions.
>
> How is it "bold" to see that the majority of widows users does not use
> or even like command line tools. And as git is command line tool (most
> of them), users does use third party tools instead of the original.
>
> I know companies where the "developers" doesn't even know of the
> existent of a git command line use. They look with owe when they see
> that I use a shell to use git.
>
Hasn't this drifted a little off topic. The issue was typeable characters in
URLs and how that affects the accessibility of various paths.
We (Git) should be avoiding lock-in to particular systems where possible.
--
Philip
^ permalink raw reply
* Re: [PATCH 4/4] doc: omit needless "for"
From: Philip Oakley @ 2016-12-11 14:08 UTC (permalink / raw)
To: Kristoffer Haugsbakk, Git List; +Cc: Kristoffer Haugsbakk
In-Reply-To: <2645548666054ED5BD30436E9DA41C14@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org>
>> diff --git a/Documentation/gitcore-tutorial.txt
>> b/Documentation/gitcore-tutorial.txt
>> index 72ca9c1ef..22309cfb4 100644
>> --- a/Documentation/gitcore-tutorial.txt
>> +++ b/Documentation/gitcore-tutorial.txt
>> @@ -25,7 +25,7 @@ you want to understand Git's internals.
>> The core Git is often called "plumbing", with the prettier user
>
> If we are tidying up here, then perhaps
> s/core Git is often/Git commands are often/
> to better clarify what aspects are plumbing / porcelain.
>
accidentally dropped a word. Should have said
s/core Git is often/core Git commands are often/
^ permalink raw reply
* Re: [BUG] git crash for git remote update tip tip
From: Jiri Olsa @ 2016-12-11 13:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161211125116.xsabnud5tfwadndt@sigill.intra.peff.net>
On Sun, Dec 11, 2016 at 07:51:16AM -0500, Jeff King wrote:
> On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote:
>
> > I accidentaly added 2 remotes and git remote update
> > crashed, see the attached output.
> >
> > [jolsa@krava perf]$ git --version
> > git version 2.7.4
>
> This is fixed already by b7410f616 (builtin/fetch.c: don't free
> remote->name after fetch, 2016-06-14), which is in v2.9.1.
ugh, time to update my fedora ;-)
thanks,
jirka
^ permalink raw reply
* Re: [PATCH 4/4] doc: omit needless "for"
From: Philip Oakley @ 2016-12-11 13:04 UTC (permalink / raw)
To: Kristoffer Haugsbakk, Git List; +Cc: Kristoffer Haugsbakk
In-Reply-To: <20161209155112.2112-5-kristoffer.haugsbakk@gmail.com>
From: "Kristoffer Haugsbakk" <kristoffer.haugsbakk@gmail.com>
Sent: Friday, December 09, 2016 3:51 PM
> What was intended was perhaps "... plumbing does for you" ("you" added),
> but
> simply omitting the word "for" is more terse and gets the intended point
> across
> just as well, if not more so.
After some thought, I think the original is more 'right'.
Without the 'for' it suggests that understanding individual plumbing
commands would explain some issue being seen with a fancy porcelain command
which they probably don't. Rather the 'for' is forward looking toward using
the plumbing commands as tools to investigate and then re-plumb the
aestehetics to the desired output.
The whole porcelain euphemism makes for some awkward phrasing.
>
> I originally went with the approach of writing "for you", but Junio C
> Hamano suggested this approach instead.
>
> Signed-off-by: Kristoffer Haugsbakk <kristoffer.haugsbakk@gmail.com>
> ---
>
> Notes (kristoffers):
> The original patch was sent to the mailing list on 2016-11-04, and
> Junio
> replied with his suggested correction on 2016-11-10; see the cover
> letter.
>
> Documentation/gitcore-tutorial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index 72ca9c1ef..22309cfb4 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -25,7 +25,7 @@ you want to understand Git's internals.
> The core Git is often called "plumbing", with the prettier user
If we are tidying up here, then perhaps
s/core Git is often/Git commands are often/
to better clarify what aspects are plumbing / porcelain.
> interfaces on top of it called "porcelain". You may not want to use the
> plumbing directly very often, but it can be good to know what the
> -plumbing does for when the porcelain isn't flushing.
> +plumbing does when the porcelain isn't flushing.
I'm not so sure that the direct allusion to 'flushing' is exactly the right
tone. Part of the issue is the 'porcelain' is the initial euphemism. The
other part is that both porcelain and plumbing commands have the same level
of CLI un-prettiness, so the distinction isn't there.
In the end I strung together:
"
The core Git commands are often called "plumbing",
while those with the prettier user friendly
output are called "porcelain".
You may not want to use the plumbing directly very often,
but it can be good to know what the plumbing does
when either the porcelain isn't flushing, or different output aethetics are
desired.
"
Though having both prettier and friendly in the same phrase maybe overkill.
>
> Back when this document was originally written, many porcelain
> commands were shell scripts. For simplicity, it still uses them as
> --
> 2.11.0
>
--
Philip
^ permalink raw reply
* Re: git add -p with new file
From: Jeff King @ 2016-12-11 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ariel, git
In-Reply-To: <xmqq37hvphji.fsf@gitster.mtv.corp.google.com>
On Sat, Dec 10, 2016 at 02:04:33PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:
> > ...
> >> But it doesn't have to be that way. You could make add -p identical to add
> >> without options, except the -p prompts to review diffs first.
> >
> > The question is whether you would annoy people using "-p" if you started
> > including untracked files by default. I agree because it's inherently an
> > interactive process that we can be looser with backwards compatibility.
>
> It might be interactive, but it will be irritating that we suddenly
> have to see hundreds of lines in an untracked file before we are
> asked to say "no I do not want to add this file" and have to do so
> for all the untracked files that happen to match the given pathspec.
>
> It might make it less irritating if one of the interactive choices
> offered in the first prompt were N that tells the command: "No,
> ignore all the untracked paths", though. I dunno.
Yeah, I agree dumping the contents automatically is annoying. Ariel
suggested asking twice about each path, which sounds clunky to me. I'd
probably give a simple question, with an option to dump the contents.
Like:
$ echo foo >untracked
$ git add -p
New file: untracked
Stage this file [y,n,v,q,a,d,/,e,?]? v <-- user types 'v' for "view"
diff --git a/untracked b/untracked
index e69de29..257cc56 100644
--- a/untracked
+++ b/untracked
@@ -0,0 +1 @@
+foo
Stage this file [y,n,v,q,a,d,/,e?]? y
Alternatively, "v" could just run "$GIT_PAGER <file>". The point is to
refresh your memory on what is in it before making a decision.
I'd also probably add interactive.showUntracked to make the whole thing
optional (but I think it would be OK to default it to on).
Some thought would have to be given handling binary files, as we
wouldn't want to dump their contents (but maybe showing them in a pager
would be OK).. We skip them entirely right now. So a related feature may
be asking "Stage this file" for binary files, with an option to somehow
view the contents.
I don't have plans to work on any of this myself. Just dumping thoughts
on what I'd expect an implementation to deal with.
-Peff
^ permalink raw reply
* Re: [BUG] git crash for git remote update tip tip
From: Jeff King @ 2016-12-11 12:51 UTC (permalink / raw)
To: Jiri Olsa; +Cc: git
In-Reply-To: <20161211121744.GA1973@krava>
On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote:
> I accidentaly added 2 remotes and git remote update
> crashed, see the attached output.
>
> [jolsa@krava perf]$ git --version
> git version 2.7.4
This is fixed already by b7410f616 (builtin/fetch.c: don't free
remote->name after fetch, 2016-06-14), which is in v2.9.1.
-Peff
^ permalink raw reply
* [BUG] git crash for git remote update tip tip
From: Jiri Olsa @ 2016-12-11 12:17 UTC (permalink / raw)
To: git
hi,
I accidentaly added 2 remotes and git remote update
crashed, see the attached output.
[jolsa@krava perf]$ git --version
git version 2.7.4
thanks,
jirka
[jolsa@krava perf]$ git remote update tip tip
Fetching tip
Fetching tip
*** Error in `git': double free or corruption (fasttop): 0x000055afef92c560 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7570b)[0x7f1ff79b170b]
/lib64/libc.so.6(+0x7deaa)[0x7f1ff79b9eaa]
/lib64/libc.so.6(cfree+0x4c)[0x7f1ff79bd40c]
git(+0x13aa30)[0x55afed553a30]
git(+0x44936)[0x55afed45d936]
git(+0x1189f)[0x55afed42a89f]
git(+0x10970)[0x55afed429970]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f1ff795c731]
git(+0x10e59)[0x55afed429e59]
======= Memory map: ========
55afed419000-55afed5ed000 r-xp 00000000 fd:01 1321939 /usr/libexec/git-core/git
55afed7ec000-55afed7f0000 r--p 001d3000 fd:01 1321939 /usr/libexec/git-core/git
55afed7f0000-55afed7f8000 rw-p 001d7000 fd:01 1321939 /usr/libexec/git-core/git
55afed7f8000-55afed824000 rw-p 00000000 00:00 0
55afef106000-55afef946000 rw-p 00000000 00:00 0 [heap]
7f1fec000000-7f1fec021000 rw-p 00000000 00:00 0
7f1fec021000-7f1ff0000000 ---p 00000000 00:00 0
7f1ff0c61000-7f1ff0c77000 r-xp 00000000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0c77000-7f1ff0e76000 ---p 00016000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e76000-7f1ff0e77000 r--p 00015000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e77000-7f1ff0e78000 rw-p 00016000 fd:01 1311838 /usr/lib64/libgcc_s-6.2.1-20160916.so.1
7f1ff0e78000-7f1ff793c000 r--p 00000000 fd:01 1588307 /usr/lib/locale/locale-archive
7f1ff793c000-7f1ff7af5000 r-xp 00000000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7af5000-7f1ff7cf4000 ---p 001b9000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cf4000-7f1ff7cf8000 r--p 001b8000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cf8000-7f1ff7cfa000 rw-p 001bc000 fd:01 1316983 /usr/lib64/libc-2.23.so
7f1ff7cfa000-7f1ff7cfe000 rw-p 00000000 00:00 0
7f1ff7cfe000-7f1ff7d05000 r-xp 00000000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7d05000-7f1ff7f04000 ---p 00007000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f04000-7f1ff7f05000 r--p 00006000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f05000-7f1ff7f06000 rw-p 00007000 fd:01 1317075 /usr/lib64/librt-2.23.so
7f1ff7f06000-7f1ff7f1d000 r-xp 00000000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff7f1d000-7f1ff811c000 ---p 00017000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811c000-7f1ff811d000 r--p 00016000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811d000-7f1ff811e000 rw-p 00017000 fd:01 1315488 /usr/lib64/libpthread-2.23.so
7f1ff811e000-7f1ff8122000 rw-p 00000000 00:00 0
7f1ff8122000-7f1ff8137000 r-xp 00000000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8137000-7f1ff8336000 ---p 00015000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8336000-7f1ff8337000 r--p 00014000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8337000-7f1ff8338000 rw-p 00015000 fd:01 1312081 /usr/lib64/libz.so.1.2.8
7f1ff8338000-7f1ff83aa000 r-xp 00000000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff83aa000-7f1ff85a9000 ---p 00072000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85a9000-7f1ff85aa000 r--p 00071000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85aa000-7f1ff85ab000 rw-p 00072000 fd:01 1320777 /usr/lib64/libpcre.so.1.2.7
7f1ff85ab000-7f1ff85cf000 r-xp 00000000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff8705000-7f1ff87af000 rw-p 00000000 00:00 0
7f1ff87cc000-7f1ff87ce000 rw-p 00000000 00:00 0
7f1ff87ce000-7f1ff87cf000 r--p 00023000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff87cf000-7f1ff87d0000 rw-p 00024000 fd:01 1311836 /usr/lib64/ld-2.23.so
7f1ff87d0000-7f1ff87d1000 rw-p 00000000 00:00 0
7ffe37593000-7ffe375b4000 rw-p 00000000 00:00 0 [stack]
7ffe375e4000-7ffe375e6000 r--p 00000000 00:00 0 [vvar]
7ffe375e6000-7ffe375e8000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
error: fetch died of signal 6
^ permalink raw reply
* [PATCH 1/1] mingw: intercept isatty() to handle /dev/null as Git expects it
From: Johannes Schindelin @ 2016-12-11 11:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva
In-Reply-To: <cover.1481454992.git.johannes.schindelin@gmx.de>
When Git's source code calls isatty(), it really asks whether the
respective file descriptor is connected to an interactive terminal.
Windows' _isatty() function, however, determines whether the file
descriptor is associated with a character device. And NUL, Windows'
equivalent of /dev/null, is a character device.
Which means that for years, Git mistakenly detected an associated
interactive terminal when being run through the test suite, which
almost always redirects stdin, stdout and stderr to /dev/null.
This bug only became obvious, and painfully so, when the new
bisect--helper entered the `pu` branch and made the automatic build & test
time out because t6030 was waiting for an answer.
For details, see
https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/mingw.h | 3 +++
compat/winansi.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 034fff9479..3350169555 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -384,6 +384,9 @@ int mingw_raise(int sig);
* ANSI emulation wrappers
*/
+int winansi_isatty(int fd);
+#define isatty winansi_isatty
+
void winansi_init(void);
HANDLE winansi_get_osfhandle(int fd);
diff --git a/compat/winansi.c b/compat/winansi.c
index db4a5b0a37..cb725fb02f 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -7,6 +7,9 @@
#include <wingdi.h>
#include <winreg.h>
+/* In this file, we actually want to use Windows' own isatty(). */
+#undef isatty
+
/*
ANSI codes used by git: m, K
@@ -570,6 +573,36 @@ static void detect_msys_tty(int fd)
#endif
+int winansi_isatty(int fd)
+{
+ int res = isatty(fd);
+
+ if (res) {
+ /*
+ * Make sure that /dev/null is not fooling Git into believing
+ * that we are connected to a terminal, as "_isatty() returns a
+ * nonzero value if the descriptor is associated with a
+ * character device."; for more information, see
+ *
+ * https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
+ */
+ HANDLE handle = (HANDLE)_get_osfhandle(fd);
+ if (fd == STDIN_FILENO) {
+ DWORD dummy;
+
+ if (!GetConsoleMode(handle, &dummy))
+ res = 0;
+ } else if (fd == STDOUT_FILENO || fd == STDERR_FILENO) {
+ CONSOLE_SCREEN_BUFFER_INFO dummy;
+
+ if (!GetConsoleScreenBufferInfo(handle, &dummy))
+ res = 0;
+ }
+ }
+
+ return res;
+}
+
void winansi_init(void)
{
int con1, con2;
--
2.11.0.rc3.windows.1
^ permalink raw reply related
* [PATCH 0/1] Fix a long-standing isatty() problem on Windows
From: Johannes Schindelin @ 2016-12-11 11:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pranit Bauva
I finally got a chance to debug the problems with the ever-timing-out
test runs of `pu` on Windows. Turns out that pb/bisect uncovered a
really old, really bad bug: on Windows, isatty() does not do what Git
expects, at least not completely: it detects interactive terminals *and
character devices*.
Why is this such a big deal?
One such character device is NUL, Windows' equivalent of /dev/null. And
guess what happens when the new tests of the bisect--helper run, with
stdin redirected from /dev/null? Precisely. Git asks "the user" for
reassurance that it may really continue, waiting forever. Or for Ctrl+C.
As we know what Git's source code wants, we have to make extra certain
to test whether isatty() reports success for a Console. The common way
to do this is to run GetConsoleMode() for input file descriptors, and
GetConsoleScreenBufferInfo() for output file descriptors.
One additional note: the new winansi_isatty() function was put into this
particular spot not only because it vaguely makes sense to put
tty-related stuff into compat/winansi.c, but with required future
changes in mind:
The current way in which Git for Windows makes sure that isatty()
returns non-zero for Git Bash (which runs in a terminal emulator called
MinTTY that does *not* have any Windows Console associated with it, and
therefore Windows' _isatty() would actually return 0 if it was not for
our detect_msys_tty() function) is hacky and needs to be fixed properly.
It is hacky because it relies on internals of the MSVC runtime that do
not hold true for the new Universal runtimes, which are used when
compiling with Visual C.
We already have experimental code to future-proof this method, and we
use that already when compiling Git for Windows in Visual Studio.
The place in which winansi_isatty() now lives will hopefully make it
possible to unify the code paths again, so that both GCC and Visual C
use detect_msys_tty() through winansi_isatty().
This will also fix a bug where current Visual C-built Git may misdetect
a reopened stdin to be connected to an interactive terminal.
Johannes Schindelin (1):
mingw: intercept isatty() to handle /dev/null as Git expects it
compat/mingw.h | 3 +++
compat/winansi.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
base-commit: 8d7a455ed52e2a96debc080dfc011b6bb00db5d2
Published-As: https://github.com/dscho/git/releases/tag/mingw-isatty-v1
Fetch-It-Via: git fetch https://github.com/dscho/git mingw-isatty-v1
--
2.11.0.rc3.windows.1
^ permalink raw reply
* Re: [BUG] Colon in remote urls
From: Klaus Ethgen @ 2016-12-11 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.20.1612101918040.23160@virtualbox>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
Am Sa den 10. Dez 2016 um 19:18 schrieb Johannes Schindelin:
> On Sat, 10 Dec 2016, Klaus Ethgen wrote:
> > Am Fr den 9. Dez 2016 um 22:32 schrieb Johannes Sixt:
> > > There are too many systems out there that use a backslash in path names. I
> > > don't think it is wise to use it also as the quoting character.
> > Well, the minority, I believe. And only the minority where the command
> > line git is used anywhere.
>
> Please provide evidence for such bold assumptions.
How is it "bold" to see that the majority of widows users does not use
or even like command line tools. And as git is command line tool (most
of them), users does use third party tools instead of the original.
I know companies where the "developers" doesn't even know of the
existent of a git command line use. They look with owe when they see
that I use a shell to use git.
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Comment: Charset: ISO-8859-1
iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhNMioACgkQpnwKsYAZ
9qzPygv/ZZr+qW4y/JoTWP6BVu+qDFhean7mHoj5vCSgXwCPzZHSvWIDLdqcrboR
UR7K3oTz9yMaoMRiNq7pu/QBJlwRSJ8ByqSde8mzXOVTqvEC5kvLugU3Ehc1fs0u
ZpoQvXBy0SrpKcuNApMdTFMO9OmCwRNAt2JecCQqyQi6hs6Ws5xTCReOEry00wb/
RdLKOpXwOn5n3ESRAQcqLWhWGs9aUVrfQRCHR2rIYsjx1s/tt+NVWa0hzTnJZt3T
wcQDlGjgeXsu8gJHPNSxAJv5paiNK4JG5x6UUOUuAzmvIYmwd6kEiyNQctTRd0JM
ZCBEYnmZQhHbvrkyKsVvUYJhE9FT0hKMAJO791ZiLCN696EJR4BCOZ9I+7GePFtY
dxb3RNsI9imCXqAHyaguY5tQImzc7P5eQfvH4CdmI9DOmwMUlirvt7pjT94pLFNQ
pxFphD+gd5tUL6QL5fmoUFQVQacQ9Vfs2riTiHerWnBq8P1Hw4KWVYd6ImFo8u3o
aWvUfXFg
=1Yj3
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCHv2] git-p4: support git worktrees
From: Luke Diamand @ 2016-12-11 7:19 UTC (permalink / raw)
To: Git Users
Cc: Vinicius Kursancew, Lars Schneider, Junio C Hamano, Luke Diamand
In-Reply-To: <20161210215734.7468-2-luke@diamand.org>
On 10 December 2016 at 21:57, Luke Diamand <luke@diamand.org> wrote:
> git-p4 would attempt to find the git directory using
> its own specific code, which did not know about git
> worktrees. This caused git operations to fail needlessly.
>
> Rework it to use "git rev-parse --git-dir" instead, which
> knows about worktrees.
Actually this doesn't work as well as the original version. "git
rev-parse --git-dir" won't go and find the ".git" subdirectory. The
previous version would go looking for it, so this would introduce a
regression.
Luke
>
> Signed-off-by: Luke Diamand <luke@diamand.org>
> ---
> git-p4.py | 47 ++++++++++++++++++++++++++---------------------
> t/t9800-git-p4-basic.sh | 20 ++++++++++++++++++++
> 2 files changed, 46 insertions(+), 21 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index fd5ca52..6aa8957 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -49,6 +49,13 @@ defaultLabelRegexp = r'[a-zA-Z0-9_\-.]+$'
> # Grab changes in blocks of this many revisions, unless otherwise requested
> defaultBlockSize = 512
>
> +def gitdir():
> + d = read_pipe("git rev-parse --git-dir").strip()
> + if not d or len(d) == 0:
> + return None
> + else:
> + return d
> +
> def p4_build_cmd(cmd):
> """Build a suitable p4 command line.
>
> @@ -562,12 +569,6 @@ def currentGitBranch():
> else:
> return read_pipe(["git", "name-rev", "HEAD"]).split(" ")[1].strip()
>
> -def isValidGitDir(path):
> - if (os.path.exists(path + "/HEAD")
> - and os.path.exists(path + "/refs") and os.path.exists(path + "/objects")):
> - return True;
> - return False
> -
> def parseRevision(ref):
> return read_pipe("git rev-parse %s" % ref).strip()
>
> @@ -3462,7 +3463,7 @@ class P4Sync(Command, P4UserMap):
> if self.tempBranches != []:
> for branch in self.tempBranches:
> read_pipe("git update-ref -d %s" % branch)
> - os.rmdir(os.path.join(os.environ.get("GIT_DIR", ".git"), self.tempBranchLocation))
> + os.rmdir(os.path.join(gitdir(), self.tempBranchLocation))
>
> # Create a symbolic ref p4/HEAD pointing to p4/<branch> to allow
> # a convenient shortcut refname "p4".
> @@ -3678,23 +3679,27 @@ def main():
> (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
> global verbose
> verbose = cmd.verbose
> +
> if cmd.needsGit:
> - if cmd.gitdir == None:
> - cmd.gitdir = os.path.abspath(".git")
> - if not isValidGitDir(cmd.gitdir):
> - cmd.gitdir = read_pipe("git rev-parse --git-dir").strip()
> - if os.path.exists(cmd.gitdir):
> - cdup = read_pipe("git rev-parse --show-cdup").strip()
> - if len(cdup) > 0:
> - chdir(cdup);
> -
> - if not isValidGitDir(cmd.gitdir):
> - if isValidGitDir(cmd.gitdir + "/.git"):
> - cmd.gitdir += "/.git"
> - else:
> + if cmd.gitdir:
> + os.environ["GIT_DIR"] = cmd.gitdir
> +
> + # did we get a valid git dir on the command line or via $GIT_DIR?
> + if not gitdir():
> die("fatal: cannot locate git repository at %s" % cmd.gitdir)
>
> - os.environ["GIT_DIR"] = cmd.gitdir
> + else:
> + # already in a git directory?
> + if not gitdir():
> + die("fatal: not in a valid git repository")
> +
> + cdup = read_pipe("git rev-parse --show-cdup").strip()
> + if len(cdup) > 0:
> + chdir(cdup);
> +
> + # ensure subshells spawned in the p4 repo directory
> + # get the correct GIT_DIR
> + os.environ["GIT_DIR"] = os.path.abspath(gitdir())
>
> if not cmd.run(args):
> parser.print_help()
> diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
> index 0730f18..093e9bd 100755
> --- a/t/t9800-git-p4-basic.sh
> +++ b/t/t9800-git-p4-basic.sh
> @@ -257,6 +257,26 @@ test_expect_success 'submit from detached head' '
> )
> '
>
> +test_expect_success 'submit from worktree' '
> + test_when_finished cleanup_git &&
> + git p4 clone --dest="$git" //depot &&
> + (
> + cd "$git" &&
> + git worktree add ../worktree-test
> + ) &&
> + (
> + cd "$git/../worktree-test" &&
> + test_commit "worktree-commit" &&
> + git config git-p4.skipSubmitEdit true &&
> + git p4 submit
> + ) &&
> + (
> + cd "$cli" &&
> + p4 sync &&
> + test_path_is_file worktree-commit.t
> + )
> +'
> +
> test_expect_success 'kill p4d' '
> kill_p4d
> '
> --
> 2.8.2.703.g78b384c.dirty
>
^ permalink raw reply
* [PATCH] git-svn: document useLogAuthor and addAuthorFrom config keys
From: Eric Wong @ 2016-12-11 0:06 UTC (permalink / raw)
To: Juergen Kosel; +Cc: git
In-Reply-To: <6160a58b-5f86-384f-30b5-2a3826019157@gmx.de>
Juergen Kosel <juergen.kosel@gmx.de> wrote:
> Am 05.12.2016 um 23:54 schrieb Eric Wong:
> > So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor
> > config keys work and can be documented?
>
> yes, I can confirm, that adding this configuration keys works with git
> 2.1.4 work.
> I have added the config keys as follows:
>
> git config --add --bool svn.useLogAuthor true
> git config --add --bool svn.addAuthorFrom true
Thanks for testing, patch below.
> > Even better would be for you to provide a patch to the
> > documentation :) Otherwise, I can write one up sometime this week.
>
> My English is not that well. So I prefer, if you update the
> documentation :-)
No problem, my asciidoc is a bit rusty, but I think
the formatted result will be fine.
(Btw, list convention here is to reply-to-all;
it prevents vger from being a single-point-of-failure)
-------8<-------
Subject: [PATCH] git-svn: document useLogAuthor and addAuthorFrom config keys
We've always supported these config keys in git-svn,
so document them so users won't have to respecify them
on every invocation.
Reported-by: Juergen Kosel <juergen.kosel@gmx.de>
Signed-off-by: Eric Wong <e@80x24.org>
---
Documentation/git-svn.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5f9e65b0c..9bee9b0c4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -664,13 +664,19 @@ creating the branch or tag.
When retrieving svn commits into Git (as part of 'fetch', 'rebase', or
'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
in the log message and use that as the author string.
++
+[verse]
+config key: svn.useLogAuthor
+
--add-author-from::
When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit'
operations), if the existing log message doesn't already have a
`From:` or `Signed-off-by:` line, append a `From:` line based on the
Git commit's author string. If you use this, then `--use-log-author`
will retrieve a valid author string for all commits.
-
++
+[verse]
+config key: svn.addAuthorFrom
ADVANCED OPTIONS
----------------
--
EW
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox