* Re: [PATCH] i18n: fix small typos
From: Eric Sunshine @ 2018-11-28 21:51 UTC (permalink / raw)
To: Jean-Noel Avila; +Cc: Git List
In-Reply-To: <20181128214309.23523-1-jn.avila@free.fr>
On Wed, Nov 28, 2018 at 4:43 PM Jean-Noël Avila <jn.avila@free.fr> wrote:
> Translating the new strings introduced for v2.20 showed some typos.
Hard to spot by eyeball when looking at the diff, but both fixes make
sense. Thanks.
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
^ permalink raw reply
* [PATCH] i18n: fix small typos
From: Jean-Noël Avila @ 2018-11-28 21:43 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila
Translating the new strings introduced for v2.20 showed some typos.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
http.c | 2 +-
midx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index 3dc8c560d6..eacc2a75ef 100644
--- a/http.c
+++ b/http.c
@@ -834,7 +834,7 @@ static CURL *get_curl_handle(void)
#if LIBCURL_VERSION_NUM >= 0x072c00
curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
#else
- warning(_("CURLSSLOPT_NO_REVOKE not suported with cURL < 7.44.0"));
+ warning(_("CURLSSLOPT_NO_REVOKE not supported with cURL < 7.44.0"));
#endif
}
diff --git a/midx.c b/midx.c
index 730ff84dff..2a6a24fcd7 100644
--- a/midx.c
+++ b/midx.c
@@ -202,7 +202,7 @@ int prepare_midx_pack(struct multi_pack_index *m, uint32_t pack_int_id)
struct strbuf pack_name = STRBUF_INIT;
if (pack_int_id >= m->num_packs)
- die(_("bad pack-int-id: %u (%u total packs"),
+ die(_("bad pack-int-id: %u (%u total packs)"),
pack_int_id, m->num_packs);
if (m->packs[pack_int_id])
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/2] git-reset.txt: render tables correctly under Asciidoctor
From: Martin Ågren @ 2018-11-28 20:37 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Git Mailing List, Paweł Samoraj, Jeff King
In-Reply-To: <877egxyojp.fsf@evledraar.gmail.com>
On Wed, 28 Nov 2018 at 20:45, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Wed, Nov 28 2018, Martin Ågren wrote:
>
> > Asciidoctor removes the indentation of each line in these tables, so the
> > last lines of each table have a completely broken alignment.
>
> Earlier I was trying to get the Documentation/doc-diff script to diff
> the asciidoc and asciidoctor docs without much success (hadn't used it
> before, just hacking the Makefile to turn on asciidoctor yielded syntax
> errors or something).
>
> Is something like that a thing we could make into a regression test?
Interesting idea. I just tried a gross hack:
* Use `make --always-make ... install-man` in doc-diff.
* ./doc-diff -f HEAD HEAD # note -f
* Add empty commit and tweak config.mak
* ./doc-diff HEAD^ HEAD # note no -f
There are lots of irrelevant differences in the headers and footers,
which is a bit unfortunate.
Also, lots of annoying differences originating in Asciidoctor's
inclination to render a space after linkgit:foo . There are those
differences themselves, obviously, but also follow-on differences such
as entire paragraphs that wrap differently.
I could spot a few things that should be fixable on our side, but on a
quick skimming, I didn't spot too many "huge" differences, which feels
good. The one which this patch fixes, obviously, and there's some work
to do in git-status.txt and git-column.txt (at least).
Tacking on `--stat` to the call to `git diff --no-index` singles out
git-config.txt, but it seems like lots of small or maybe even irrelevant
differences, plus lots of spaces around linkgit: , as already mentioned.
Martin
^ permalink raw reply
* Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files
From: Stefan Beller @ 2018-11-28 20:30 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, git, Junio C Hamano,
Thomas Gummerer
In-Reply-To: <CACsJy8Cv9ZwWEs-wsOtms3JCXo7x8fL_PBatcb0TgvrrQuMUdg@mail.gmail.com>
On Wed, Nov 28, 2018 at 12:09 PM Duy Nguyen <pclouds@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen <pclouds@gmail.com> wrote:
> > should we do
> > something about detached HEAD in this switch-branch command (or
> > whatever its name will be)?
> >
> > This is usually a confusing concept to new users
>
> And it just occurred to me that perhaps we should call this "unnamed
> branch" (at least at high UI level) instead of detached HEAD. It is
> technically not as accurate, but much better to understand.
or 'direct' branch? I mean 'detached HEAD' itself is also not correct
as the HEAD points to a valid commit/tag usually, so it is attached to
that content. The detachment comes from the implicit "from a branch".
^ permalink raw reply
* Re: Git pull confusing output
From: Stefan Beller @ 2018-11-28 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Duclot, git
In-Reply-To: <xmqq36rlsofp.fsf@gitster-ct.c.googlers.com>
On Tue, Nov 27, 2018 at 10:31 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Will <william.duclot@gmail.com> writes:
>
> > I’m far from being a guru, but I consider myself a competent Git
> > user. Yet, here’s my understanding of the output of one the most-used
> > commands, `git push`:
> >> Counting objects: 6, done.
> > No idea what an “object” is. Apparently there’s 6 of them
> > here. What does “counting” them means? Should I care?
>
> You vaguely recall that the last time you pushed you saw ~400
> objects counted there, so you get the feeling how active you were
> since then.
>
> It is up to you if you are interested in such a feel of the level of
> activity. "git fetch" (hence "git pull") would also give you a
> similar "feel", e.g. "the last fetch was ~1200 objects and today's
> is mere ~200, so it seems it is a relatively slow day".
>
> As to "what is an object?", there are plenty of Git tutorials and
> books to learn the basics from. Again, it is up to you if you care.
While this is very interesting to the experienced git user, the
approximation of activity by object count is very coarse to say at least.
As It approximates changes in the DAG object count and nothing
about the deltas (which as we learn comes later and it comes with
a progress meter in bytes), it only provides the basics.
>
> I think we have "--quiet" option for those who do not care.
I think some users are not focused as much on the version control as
much as they are focused on another problem that is solved with
the content inside the repo.
Which means they only care about 'actionable' output, such as
* errors
* information provided by remote
(e.g. links to click to start a code review)
* too long waiting time
(so they can abort and inspect the problem)
I would suggest we come up with a mode that is "not quiet", but
cuts down to only the basic actionable items [and make that
the default eventually].
Now these actionable items depend on the workflow used,
for which I think an email based maintainers workflow is not
the norm. The vast majority of people uses git-push to
upload their change to a code review system instead.
And for such a workflow the size (as proxied by
object/delta count) is not as important as the target ref
that you push to or potentially the diffstat output of
a potential merge to a target branch.
TLDR: I still think making git-push a bit more quiet is
beneficial to the user base at large.
Stefan
^ permalink raw reply
* [PATCH 1/2] format-patch: add test for --range-diff diff output
From: Ævar Arnfjörð Bjarmason @ 2018-11-28 20:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Sunshine,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqk1l32jo2.fsf@gitster-ct.c.googlers.com>
As noted in 43dafc4172 ("format-patch: don't include --stat with
--range-diff output", 2018-11-22) the diff options provided on the
command-line currently affect both the range-diff and the patch
output, but there was no test for checking this with output where we'd
show a patch diff. Let's add one.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t3206-range-diff.sh | 60 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index 90def330bd..bc5facc1cd 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-range-diff.sh
@@ -267,4 +267,64 @@ test_expect_success 'format-patch --range-diff as commentary' '
test_i18ngrep "^Range-diff:$" actual
'
+test_expect_success 'format-patch with <common diff option>' '
+ # No diff options
+ git format-patch --cover-letter --stdout --range-diff=topic~..topic \
+ changed~..changed >actual.raw &&
+ sed -ne "/^1:/,/^--/p" <actual.raw >actual.range-diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
+ 1: a63e992 ! 1: d966c5c s/12/B/
+ @@ -8,7 +8,7 @@
+ @@
+ 9
+ 10
+ - B
+ + BB
+ -12
+ +B
+ 13
+ -- :
+ EOF
+ test_cmp expect actual.range-diff &&
+ sed -ne "/^--- /,/^--/p" <actual.raw >actual.diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
+ --- a/file
+ +++ b/file
+ @@ -9,7 +9,7 @@ A
+ 9
+ 10
+ BB
+ -12
+ +B
+ 13
+ 14
+ 15
+ -- :
+ EOF
+ test_cmp expect actual.diff &&
+
+ # -U0
+ git format-patch --cover-letter --stdout -U0 \
+ --range-diff=topic~..topic changed~..changed >actual.raw &&
+ sed -ne "/^1:/,/^--/p" <actual.raw >actual.range-diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
+ 1: a63e992 ! 1: d966c5c s/12/B/
+ @@ -11 +11 @@
+ - B
+ + BB
+ -- :
+ EOF
+ test_cmp expect actual.range-diff &&
+ sed -ne "/^--- /,/^--/p" <actual.raw >actual.diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
+ --- a/file
+ +++ b/file
+ @@ -12 +12 @@ BB
+ -12
+ +B
+ -- :
+ EOF
+ test_cmp expect actual.diff
+'
+
test_done
--
2.20.0.rc1.387.gf8505762e3
^ permalink raw reply related
* [PATCH 0/2] format-patch: fix root cause of recent regression
From: Ævar Arnfjörð Bjarmason @ 2018-11-28 20:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Sunshine,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqk1l32jo2.fsf@gitster-ct.c.googlers.com>
As noted in 2/2 this fixes the root cause of the bug I plastered over
in
https://public-inbox.org/git/20181122211248.24546-3-avarab@gmail.com/
(that patch is sitting in 'next').
1/2 is a test for existing behavior, to make it more easily understood
what's being changed.
Junio: I know it's late, but unless Eric has objections to this UI
change I'd really like to have this in 2.20 since this is a change to
a new command-line UI that's newly added in 2.20.
As noted in 2/2 the current implementation is inherently limited, you
can't tweak diff options for the range-diff in the cover-letter and
the patch independently, now you can, and the implementation is much
less nasty now that we're not having to share diffopts across two
different modes of operation.
Ævar Arnfjörð Bjarmason (2):
format-patch: add test for --range-diff diff output
format-patch: allow for independent diff & range-diff options
Documentation/git-format-patch.txt | 10 ++-
builtin/log.c | 42 +++++++++---
t/t3206-range-diff.sh | 101 +++++++++++++++++++++++++++++
3 files changed, 142 insertions(+), 11 deletions(-)
--
2.20.0.rc1.387.gf8505762e3
^ permalink raw reply
* [PATCH 2/2] format-patch: allow for independent diff & range-diff options
From: Ævar Arnfjörð Bjarmason @ 2018-11-28 20:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Sunshine,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqk1l32jo2.fsf@gitster-ct.c.googlers.com>
Change the semantics of the "--range-diff" option so that the regular
diff options can be provided separately for the range-diff and the
patch. This allows for supplying e.g. --range-diff-U0 and -U1 to
"format-patch" to provide different context for the range-diff and the
patch. This wasn't possible before.
Ever since the "--range-diff" option was added in
31e2617a5f ("format-patch: add --range-diff option to embed diff in
cover letter", 2018-07-22) the "rev->diffopt" we pass down to the diff
machinery has been the one we get from "format-patch"'s own
setup_revisions().
This sort of thing is unique among the log-like commands in
builtin/log.c, no command than format-patch will embed the output of
another log-like command. Since the "rev->diffopt" is reused we need
to munge it before we pass it to show_range_diff(). See
43dafc4172 ("format-patch: don't include --stat with --range-diff
output", 2018-11-22) for a related regression fix which is being
mostly reverted here.
Implementation notes: 1) We're not bothering with the full teardown
around die() and will leak memory, but it's too much boilerplate to do
all the frees with/without the die() and not worth it. 2) We call
repo_init_revisions() for "rd_rev" even though we could get away with
a shallow copy like the code we're replacing (and which
show_range_diff() itself does). This is to make this code more easily
understood.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Documentation/git-format-patch.txt | 10 ++++++-
builtin/log.c | 42 +++++++++++++++++++++++-------
t/t3206-range-diff.sh | 41 +++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index aba4c5febe..6c048f415f 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -24,7 +24,8 @@ SYNOPSIS
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
[--interdiff=<previous>]
- [--range-diff=<previous> [--creation-factor=<percent>]]
+ [--range-diff=<previous> [--creation-factor=<percent>]
+ [--range-diff<common diff option>]]
[--progress]
[<common diff options>]
[ <since> | <revision range> ]
@@ -257,6 +258,13 @@ feeding the result to `git send-email`.
creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
for details.
+--range-diff<common diff option>::
+ Other options prefixed with `--range-diff` are stripped of
+ that prefix and passed as-is to the diff machinery used to
+ generate the range-diff, e.g. `--range-diff-U0` and
+ `--range-diff--no-color`. This allows for adjusting the format
+ of the range-diff independently from the patch itself.
+
--notes[=<ref>]::
Append the notes (see linkgit:git-notes[1]) for the commit
after the three-dash line.
diff --git a/builtin/log.c b/builtin/log.c
index 02d88fa233..7658e56ecc 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1023,7 +1023,8 @@ static void show_diffstat(struct rev_info *rev,
fprintf(rev->diffopt.file, "\n");
}
-static void make_cover_letter(struct rev_info *rev, int use_stdout,
+static void make_cover_letter(struct rev_info *rev, struct rev_info *rd_rev,
+ int use_stdout,
struct commit *origin,
int nr, struct commit **list,
const char *branch_name,
@@ -1095,13 +1096,9 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
}
if (rev->rdiff1) {
- struct diff_options opts;
- memcpy(&opts, &rev->diffopt, sizeof(opts));
- opts.output_format &= ~(DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY);
-
fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
show_range_diff(rev->rdiff1, rev->rdiff2,
- rev->creation_factor, 1, &opts);
+ rev->creation_factor, 1, &rd_rev->diffopt);
}
}
@@ -1485,6 +1482,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
struct commit *commit;
struct commit **list = NULL;
struct rev_info rev;
+ struct rev_info rd_rev;
struct setup_revision_opt s_r_opt;
int nr = 0, total, i;
int use_stdout = 0;
@@ -1603,6 +1601,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
init_log_defaults();
git_config(git_format_config, NULL);
repo_init_revisions(the_repository, &rev, prefix);
+ repo_init_revisions(the_repository, &rd_rev, prefix);
rev.commit_format = CMIT_FMT_EMAIL;
rev.expand_tabs_in_log_default = 0;
rev.verbose_header = 1;
@@ -1689,8 +1688,32 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.preserve_subject = keep_subject;
argc = setup_revisions(argc, argv, &rev, &s_r_opt);
- if (argc > 1)
- die(_("unrecognized argument: %s"), argv[1]);
+ if (argc > 1) {
+ struct argv_array args = ARGV_ARRAY_INIT;
+ const char *prefix = "--range-diff";
+ int have_prefix = 0;
+
+ for (i = 0; i < argc; i++) {
+ struct strbuf sb = STRBUF_INIT;
+ char *str;
+
+ strbuf_addstr(&sb, argv[i]);
+ if (starts_with(argv[i], prefix)) {
+ have_prefix = 1;
+ strbuf_remove(&sb, 0, strlen(prefix));
+ }
+ str = strbuf_detach(&sb, NULL);
+ strbuf_release(&sb);
+
+ argv_array_push(&args, str);
+ }
+
+ if (!have_prefix)
+ die(_("unrecognized argument: %s"), argv[1]);
+ argc = setup_revisions(args.argc, args.argv, &rd_rev, NULL);
+ if (argc > 1)
+ die(_("unrecognized argument: %s"), argv[1]);
+ }
if (rev.diffopt.output_format & DIFF_FORMAT_NAME)
die(_("--name-only does not make sense"));
@@ -1702,7 +1725,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (!use_patch_format &&
(!rev.diffopt.output_format ||
rev.diffopt.output_format == DIFF_FORMAT_PATCH))
- /* Needs to be mirrored in show_range_diff() invocation */
rev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_SUMMARY;
if (!rev.diffopt.stat_width)
rev.diffopt.stat_width = MAIL_DEFAULT_WRAP;
@@ -1877,7 +1899,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (cover_letter) {
if (thread)
gen_message_id(&rev, "cover");
- make_cover_letter(&rev, use_stdout,
+ make_cover_letter(&rev, &rd_rev, use_stdout,
origin, nr, list, branch_name, quiet);
print_bases(&bases, rev.diffopt.file);
print_signature(rev.diffopt.file);
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index bc5facc1cd..6916103888 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-range-diff.sh
@@ -308,6 +308,35 @@ test_expect_success 'format-patch with <common diff option>' '
--range-diff=topic~..topic changed~..changed >actual.raw &&
sed -ne "/^1:/,/^--/p" <actual.raw >actual.range-diff &&
sed -e "s|:$||" >expect <<-\EOF &&
+ 1: a63e992 ! 1: d966c5c s/12/B/
+ @@ -8,7 +8,7 @@
+ @@
+ 9
+ 10
+ - B
+ + BB
+ -12
+ +B
+ 13
+ -- :
+ EOF
+ test_cmp expect actual.range-diff &&
+ sed -ne "/^--- /,/^--/p" <actual.raw >actual.diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
+ --- a/file
+ +++ b/file
+ @@ -12 +12 @@ BB
+ -12
+ +B
+ -- :
+ EOF
+ test_cmp expect actual.diff &&
+
+ # -U0 & --range-diff-U0
+ git format-patch --cover-letter --stdout -U0 --range-diff-U0 \
+ --range-diff=topic~..topic changed~..changed >actual.raw &&
+ sed -ne "/^1:/,/^--/p" <actual.raw >actual.range-diff &&
+ sed -e "s|:$||" >expect <<-\EOF &&
1: a63e992 ! 1: d966c5c s/12/B/
@@ -11 +11 @@
- B
@@ -327,4 +356,16 @@ test_expect_success 'format-patch with <common diff option>' '
test_cmp expect actual.diff
'
+test_expect_success 'format-patch option parsing with --range-diff-*' '
+ test_must_fail git format-patch --stdout --unknown \
+ master..unmodified 2>stderr &&
+ test_i18ngrep "unrecognized argument: --unknown" stderr &&
+ test_must_fail git format-patch --stdout --range-diff-unknown \
+ master..unmodified 2>stderr &&
+ test_i18ngrep "unrecognized argument: --range-diff-unknown" stderr &&
+ test_must_fail git format-patch --stdout --unknown --range-diff-unknown \
+ master..unmodified 2>stderr &&
+ test_i18ngrep "unrecognized argument: --unknown" stderr
+'
+
test_done
--
2.20.0.rc1.387.gf8505762e3
^ permalink raw reply related
* Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files
From: Duy Nguyen @ 2018-11-28 20:09 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano, Stefan Beller, Thomas Gummerer
In-Reply-To: <CACsJy8D2gxPj4u0_eEg-_x-Z3S3+5FdTU6Su4VQM113nQq=PYg@mail.gmail.com>
On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen <pclouds@gmail.com> wrote:
> should we do
> something about detached HEAD in this switch-branch command (or
> whatever its name will be)?
>
> This is usually a confusing concept to new users
And it just occurred to me that perhaps we should call this "unnamed
branch" (at least at high UI level) instead of detached HEAD. It is
technically not as accurate, but much better to understand.
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files
From: Duy Nguyen @ 2018-11-28 20:01 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano, Stefan Beller, Thomas Gummerer
In-Reply-To: <20181127165211.24763-1-pclouds@gmail.com>
On Tue, Nov 27, 2018 at 5:53 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>
> v2 is just a bit better to look at than v1. This is by no means final.
> If you think the command name is bad, the default behavior should
> change, or something else, speak up. It's still very "RFC".
>
> v2 breaks down the giant patch in v1 and starts adding some changes in
> these new commands:
>
> - restore-paths is renamed to checkout-paths. I wrote I didn't like
> "checkout" because of completion conflict. But who am I kidding,
> I'll use aliases anyway. "-files" instead of "-paths" because we
> already have ls-files.
> - both commands will not accept no arguments. There is no "git
> checkout" equivalent.
> - ambiguation rules are now aware that "switch-branch" for example
> can't take pathspec...
Another thing. Since we start with a clean slate, should we do
something about detached HEAD in this switch-branch command (or
whatever its name will be)?
This is usually a confusing concept to new users and I've seen some
users have a hard time getting out of it. I'm too comfortable with
detached HEAD to see this from new user's perspective and a better way
to deal with it.
--
Duy
^ permalink raw reply
* Re: [BUG REPORT] t5322: demonstrate a pack-objects bug
From: Derrick Stolee @ 2018-11-28 19:55 UTC (permalink / raw)
To: git; +Cc: Derrick Stolee
In-Reply-To: <20181128194536.57019-1-dstolee@microsoft.com>
On 11/28/2018 2:45 PM, Derrick Stolee wrote:
> I was preparing a new "sparse" algorithm for calculating the
> interesting objects to send on push. The important steps happen
> during 'git pack-objects', so I was creating test cases to see
> how the behavior changes in narrow cases. Specifically, when
> copying a directory across sibling directories (see test case),
> the new logic would accidentally send that object as an extra.
>
> However, I found a bug in the existing logic. The included test
> demonstrates this during the final 'git index-pack' call. It
> fails with the message
>
> 'fatal: pack has 1 unresolved delta'
I realize now that I've gone through this effort that the problem is me
(of course it is).
> + git pack-objects --stdout --thin --revs <packinput.txt >nonsparse.pack &&
Since I'm packing thin packs, the index operation is complaining about
deltas. So, I need to use a different mechanism to list the objects in
the pack (say, 'git verify-pack -v').
Sorry for the noise!
Thanks,
-Stolee
^ permalink raw reply
* [BUG REPORT] t5322: demonstrate a pack-objects bug
From: Derrick Stolee @ 2018-11-28 19:45 UTC (permalink / raw)
To: git; +Cc: Derrick Stolee
I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
copying a directory across sibling directories (see test case),
the new logic would accidentally send that object as an extra.
However, I found a bug in the existing logic. The included test
demonstrates this during the final 'git index-pack' call. It
fails with the message
'fatal: pack has 1 unresolved delta'
It is probable that this is not a minimal test case, but happens
to be the test I had created before discovering the problem.
I compiled v2.17.0 and v2.12.0 as checks to see if I could find
a "good" commit with which to start a bisect, but both failed.
This is an old bug!
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
t/t5322-pack-objects-sparse.sh | 94 ++++++++++++++++++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100755 t/t5322-pack-objects-sparse.sh
diff --git a/t/t5322-pack-objects-sparse.sh b/t/t5322-pack-objects-sparse.sh
new file mode 100755
index 0000000000..36faa70fe9
--- /dev/null
+++ b/t/t5322-pack-objects-sparse.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+
+test_description='pack-objects object selection using sparse algorithm'
+. ./test-lib.sh
+
+test_expect_success 'setup repo' '
+ test_commit initial &&
+ for i in $(test_seq 1 3)
+ do
+ mkdir f$i &&
+ for j in $(test_seq 1 3)
+ do
+ mkdir f$i/f$j &&
+ echo $j >f$i/f$j/data.txt
+ done
+ done &&
+ git add . &&
+ git commit -m "Initialized trees" &&
+ for i in $(test_seq 1 3)
+ do
+ git checkout -b topic$i master &&
+ echo change-$i >f$i/f$i/data.txt &&
+ git commit -a -m "Changed f$i/f$i/data.txt"
+ done &&
+ cat >packinput.txt <<-EOF &&
+ topic1
+ ^topic2
+ ^topic3
+ EOF
+ git rev-parse \
+ topic1 \
+ topic1^{tree} \
+ topic1:f1 \
+ topic1:f1/f1 \
+ topic1:f1/f1/data.txt | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+ git pack-objects --stdout --thin --revs <packinput.txt >nonsparse.pack &&
+ git index-pack -o nonsparse.idx nonsparse.pack &&
+ git show-index <nonsparse.idx | awk "{print \$2}" >nonsparse_objects.txt &&
+ test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+# Demonstrate that both algorithms send "extra" objects because
+# they are not in the frontier.
+
+test_expect_success 'duplicate a folder from f3 and commit to topic1' '
+ git checkout topic1 &&
+ echo change-3 >f3/f3/data.txt &&
+ git commit -a -m "Changed f3/f3/data.txt" &&
+ git rev-parse \
+ topic1~1 \
+ topic1~1^{tree} \
+ topic1^{tree} \
+ topic1 \
+ topic1:f1 \
+ topic1:f1/f1 \
+ topic1:f1/f1/data.txt \
+ topic1:f3 \
+ topic1:f3/f3 \
+ topic1:f3/f3/data.txt | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+ git pack-objects --stdout --thin --revs <packinput.txt >nonsparse.pack &&
+ git index-pack -o nonsparse.idx nonsparse.pack &&
+ git show-index <nonsparse.idx | awk "{print \$2}" >nonsparse_objects.txt &&
+ test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+test_expect_success 'duplicate a folder from f3 and commit to topic1' '
+ mkdir f3/f4 &&
+ cp -r f1/f1/* f3/f4 &&
+ git add f3/f4 &&
+ git commit -m "Copied f1/f1 to f3/f4" &&
+ cat >packinput.txt <<-EOF &&
+ topic1
+ ^topic1~1
+ EOF
+ git rev-parse \
+ topic1 \
+ topic1^{tree} \
+ topic1:f3 | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+ git pack-objects --stdout --thin --revs <packinput.txt >nonsparse.pack &&
+ git index-pack -o nonsparse.idx nonsparse.pack &&
+ git show-index <nonsparse.idx | awk "{print \$2}" >nonsparse_objects.txt &&
+ test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+test_done
--
2.20.0.rc1
^ permalink raw reply related
* Re: [PATCH 1/2] git-reset.txt: render tables correctly under Asciidoctor
From: Ævar Arnfjörð Bjarmason @ 2018-11-28 19:44 UTC (permalink / raw)
To: Martin Ågren; +Cc: git, Paweł Samoraj, Jeff King
In-Reply-To: <1596a9ff9fa6849f53590de1b15eb18ee6b41e4d.1543429054.git.martin.agren@gmail.com>
On Wed, Nov 28 2018, Martin Ågren wrote:
> Asciidoctor removes the indentation of each line in these tables, so the
> last lines of each table have a completely broken alignment.
>
> Similar to 379805051d ("Documentation: render revisions correctly under
> Asciidoctor", 2018-05-06), use an explicit literal block to indicate
> that we want to keep the leading whitespace in the tables.
>
> Because this gives us some extra indentation, we can remove the one that
> we have been carrying explicitly. That is, drop the first six spaces of
> indentation on each line. With Asciidoc (8.6.10), this results in
> identical rendering before and after this commit, both for git-reset.1
> and git-reset.html.
>
> Reported-by: Paweł Samoraj <samoraj.pawel@gmail.com>
> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Earlier I was trying to get the Documentation/doc-diff script to diff
the asciidoc and asciidoctor docs without much success (hadn't used it
before, just hacking the Makefile to turn on asciidoctor yielded syntax
errors or something).
Is something like that a thing we could make into a regression test?
^ permalink raw reply
* Re: [bug report] git-gui child windows are blank
From: Stefan Beller @ 2018-11-28 19:28 UTC (permalink / raw)
To: kenn; +Cc: git
In-Reply-To: <CAABTFJPpmThrrwP6pb5gZ82fb8yKteLpDcXTCQS8p_7WZ0Ne5Q@mail.gmail.com>
On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta <kenn@eissq.com> wrote:
>
> v2.19.2, installed from brew on macOS Mojave 14.2.1.
>
> `git-gui` is my much beloved go-to tool for everything git.
> Unfortunately, on my new Macbook Air it seems to have a bug. When I
> first load the program, the parent window populates normally with the
> stage/unstaged and diff panes. However, when I click Push, the child
> window is completely blank. The frame is there, but there is no
> content.
>
> This same behavior is seen if I do a `git gui blame`, where the
> primary blame window opens normally but all the children windows are
> empty.
>
> I have googled but was unsuccessful in finding a solution. Is this a
> known issue?
Looking through the mailing list archive, this
seemed to be one of the last relevant messges
https://public-inbox.org/git/20180724065120.7664-1-sunshine@sunshineco.com/
>
>
> --Kenn
^ permalink raw reply
* Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files
From: Duy Nguyen @ 2018-11-28 19:18 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
Git Mailing List, Thomas Gummerer
In-Reply-To: <CAGZ79kbWqfMHZeYFXNh00N5xSSkW0_Mzja1EtuzxQxrhESoZxQ@mail.gmail.com>
On Wed, Nov 28, 2018 at 8:08 PM Stefan Beller <sbeller@google.com> wrote:
>
> On Wed, Nov 28, 2018 at 7:31 AM Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> > >
> > > > The good old "git checkout" command is still here and will be until
> > > > all (or most of users) are sick of it.
> > >
> > > Two comments on the goal (the implementation looked reasonable
> > > assuming the reader agrees with the gaol).
> > >
> > > At least to me, the verb "switch" needs two things to switch
> > > between, i.e. "switch A and B", unless it is "switch to X".
> > > Either "switch-to-branch" or simply "switch-to", perhaps?
> > >
> > > As I already hinted in my response to Stefan (?) about
> > > checkout-from-tree vs checkout-from-index, a command with multiple
> > > modes of operation is not confusing to people with the right mental
> > > model, and I suspect that having two separate commands for "checking
> > > out a branch" and "checking out paths" that is done by this step
> > > would help users to form the right mental model.
> >
> > Since the other one is already "checkout-files", maybe this one could
> > just be "checkout-branch".
>
> I dislike the checkout-* names, as we already have checkout-index
> as plumbing, so it would be confusing as to which checkout-* command
> should be used when and why as it seems the co-index moves
> content *from index* to the working tree, but the co-files moves content
> *to files*, whereas checkout-branch is neither 'moving' to or from a branch
> but rather 'switching' to that branch.
OK back to square one. Another thing I noticed, not sure if it
matters, is that these two commands will be the only ones with a
hyphen in them in "git help". But I guess it's even harder to find
one-word command names for these.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files
From: Stefan Beller @ 2018-11-28 19:08 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git,
Thomas Gummerer
In-Reply-To: <CACsJy8Bzs=FYKrR6h1cqVH32eEt2t8rUMtE2yFNvt+W55u=sDA@mail.gmail.com>
On Wed, Nov 28, 2018 at 7:31 AM Duy Nguyen <pclouds@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> >
> > > The good old "git checkout" command is still here and will be until
> > > all (or most of users) are sick of it.
> >
> > Two comments on the goal (the implementation looked reasonable
> > assuming the reader agrees with the gaol).
> >
> > At least to me, the verb "switch" needs two things to switch
> > between, i.e. "switch A and B", unless it is "switch to X".
> > Either "switch-to-branch" or simply "switch-to", perhaps?
> >
> > As I already hinted in my response to Stefan (?) about
> > checkout-from-tree vs checkout-from-index, a command with multiple
> > modes of operation is not confusing to people with the right mental
> > model, and I suspect that having two separate commands for "checking
> > out a branch" and "checking out paths" that is done by this step
> > would help users to form the right mental model.
>
> Since the other one is already "checkout-files", maybe this one could
> just be "checkout-branch".
I dislike the checkout-* names, as we already have checkout-index
as plumbing, so it would be confusing as to which checkout-* command
should be used when and why as it seems the co-index moves
content *from index* to the working tree, but the co-files moves content
*to files*, whereas checkout-branch is neither 'moving' to or from a branch
but rather 'switching' to that branch.
^ permalink raw reply
* [PATCH 2/2] git-reset.txt: render literal examples as monospace
From: Martin Ågren @ 2018-11-28 19:02 UTC (permalink / raw)
To: git; +Cc: Paweł Samoraj
In-Reply-To: <cover.1543429054.git.martin.agren@gmail.com>
Large parts of this document do not use `backticks` around literal
examples such as branch names (`topic/wip`), git usages, `HEAD` and
`<commit-ish>` so they render as ordinary text. Fix that.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Documentation/git-reset.txt | 131 ++++++++++++++++++------------------
1 file changed, 66 insertions(+), 65 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 7c925e3a29..9f69ae8b69 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -14,14 +14,14 @@ SYNOPSIS
DESCRIPTION
-----------
-In the first and second form, copy entries from <tree-ish> to the index.
-In the third form, set the current branch head (HEAD) to <commit>, optionally
-modifying index and working tree to match. The <tree-ish>/<commit> defaults
-to HEAD in all forms.
+In the first and second form, copy entries from `<tree-ish>` to the index.
+In the third form, set the current branch head (`HEAD`) to `<commit>`,
+optionally modifying index and working tree to match.
+The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
'git reset' [-q] [<tree-ish>] [--] <paths>...::
- This form resets the index entries for all <paths> to their
- state at <tree-ish>. (It does not affect the working tree or
+ This form resets the index entries for all `<paths>` to their
+ state at `<tree-ish>`. (It does not affect the working tree or
the current branch.)
+
This means that `git reset <paths>` is the opposite of `git add
@@ -36,7 +36,7 @@ working tree in one go.
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]::
Interactively select hunks in the difference between the index
- and <tree-ish> (defaults to HEAD). The chosen hunks are applied
+ and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied
in reverse to the index.
+
This means that `git reset -p` is the opposite of `git add -p`, i.e.
@@ -44,16 +44,16 @@ you can use it to selectively reset hunks. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
'git reset' [<mode>] [<commit>]::
- This form resets the current branch head to <commit> and
- possibly updates the index (resetting it to the tree of <commit>) and
- the working tree depending on <mode>. If <mode> is omitted,
- defaults to "--mixed". The <mode> must be one of the following:
+ This form resets the current branch head to `<commit>` and
+ possibly updates the index (resetting it to the tree of `<commit>`) and
+ the working tree depending on `<mode>`. If `<mode>` is omitted,
+ defaults to `--mixed`. The `<mode>` must be one of the following:
+
--
--soft::
Does not touch the index file or the working tree at all (but
- resets the head to <commit>, just like all modes do). This leaves
- all your changed files "Changes to be committed", as 'git status'
+ resets the head to `<commit>`, just like all modes do). This leaves
+ all your changed files "Changes to be committed", as `git status`
would put it.
--mixed::
@@ -66,24 +66,24 @@ linkgit:git-add[1]).
--hard::
Resets the index and working tree. Any changes to tracked files in the
- working tree since <commit> are discarded.
+ working tree since `<commit>` are discarded.
--merge::
Resets the index and updates the files in the working tree that are
- different between <commit> and HEAD, but keeps those which are
+ different between `<commit>` and `HEAD`, but keeps those which are
different between the index and working tree (i.e. which have changes
which have not been added).
- If a file that is different between <commit> and the index has unstaged
- changes, reset is aborted.
+ If a file that is different between `<commit>` and the index has
+ unstaged changes, reset is aborted.
+
-In other words, --merge does something like a 'git read-tree -u -m <commit>',
+In other words, `--merge` does something like a `git read-tree -u -m <commit>`,
but carries forward unmerged index entries.
--keep::
Resets index entries and updates files in the working tree that are
- different between <commit> and HEAD.
- If a file that is different between <commit> and HEAD has local changes,
- reset is aborted.
+ different between `<commit>` and `HEAD`.
+ If a file that is different between `<commit>` and `HEAD` has local
+ changes, reset is aborted.
--
If you want to undo a commit other than the latest on a branch,
@@ -116,15 +116,15 @@ $ git pull git://info.example.com/ nitfol <4>
+
<1> You are happily working on something, and find the changes
in these files are in good order. You do not want to see them
-when you run "git diff", because you plan to work on other files
+when you run `git diff`, because you plan to work on other files
and changes with these files are distracting.
<2> Somebody asks you to pull, and the changes sound worthy of merging.
<3> However, you already dirtied the index (i.e. your index does
-not match the HEAD commit). But you know the pull you are going
-to make does not affect frotz.c or filfre.c, so you revert the
+not match the `HEAD` commit). But you know the pull you are going
+to make does not affect `frotz.c` or `filfre.c`, so you revert the
index changes for these two files. Your changes in working tree
remain there.
-<4> Then you can pull and merge, leaving frotz.c and filfre.c
+<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
changes still in the working tree.
Undo a commit and redo::
@@ -140,11 +140,11 @@ $ git commit -a -c ORIG_HEAD <3>
just committed is incomplete, or you misspelled your commit
message, or both. Leaves working tree as it was before "reset".
<2> Make corrections to working tree files.
-<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
+<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
commit by starting with its log message. If you do not need to
-edit the message further, you can give -C option instead.
+edit the message further, you can give `-C` option instead.
+
-See also the --amend option to linkgit:git-commit[1].
+See also the `--amend` option to linkgit:git-commit[1].
Undo a commit, making it a topic branch::
+
@@ -155,11 +155,11 @@ $ git checkout topic/wip <3>
------------
+
<1> You have made some commits, but realize they were premature
-to be in the "master" branch. You want to continue polishing
-them in a topic branch, so create "topic/wip" branch off of the
-current HEAD.
+to be in the `master` branch. You want to continue polishing
+them in a topic branch, so create `topic/wip` branch off of the
+current `HEAD`.
<2> Rewind the master branch to get rid of those three commits.
-<3> Switch to "topic/wip" branch and keep working.
+<3> Switch to `topic/wip` branch and keep working.
Undo commits permanently::
+
@@ -168,7 +168,7 @@ $ git commit ...
$ git reset --hard HEAD~3 <1>
------------
+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
and you do not want to ever see them again. Do *not* do this if
you have already given these commits to somebody else. (See the
"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
@@ -191,14 +191,14 @@ $ git reset --hard ORIG_HEAD <4>
<1> Try to update from the upstream resulted in a lot of
conflicts; you were not ready to spend a lot of time merging
right now, so you decide to do that later.
-<2> "pull" has not made merge commit, so "git reset --hard"
-which is a synonym for "git reset --hard HEAD" clears the mess
+<2> "pull" has not made merge commit, so `git reset --hard`
+which is a synonym for `git reset --hard HEAD` clears the mess
from the index file and the working tree.
<3> Merge a topic branch into the current branch, which resulted
in a fast-forward.
<4> But you decided that the topic branch is not ready for public
consumption yet. "pull" or "merge" always leaves the original
-tip of the current branch in ORIG_HEAD, so resetting hard to it
+tip of the current branch in `ORIG_HEAD`, so resetting hard to it
brings your index file and the working tree back to that state,
and resets the tip of the branch to that commit.
@@ -214,14 +214,14 @@ $ git reset --merge ORIG_HEAD <2>
------------
+
<1> Even if you may have local modifications in your
-working tree, you can safely say "git pull" when you know
+working tree, you can safely say `git pull` when you know
that the change in the other branch does not overlap with
them.
<2> After inspecting the result of the merge, you may find
that the change in the other branch is unsatisfactory. Running
-"git reset --hard ORIG_HEAD" will let you go back to where you
+`git reset --hard ORIG_HEAD` will let you go back to where you
were, but it will discard your local changes, which you do not
-want. "git reset --merge" keeps your local changes.
+want. `git reset --merge` keeps your local changes.
Interrupted workflow::
@@ -287,13 +287,13 @@ $ git checkout -b branch2 <2>
$ git reset --keep start <3>
------------
+
-<1> This commits your first edits in branch1.
+<1> This commits your first edits in `branch1`.
<2> In the ideal world, you could have realized that the earlier
commit did not belong to the new topic when you created and switched
- to branch2 (i.e. "git checkout -b branch2 start"), but nobody is
+ to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is
perfect.
-<3> But you can use "reset --keep" to remove the unwanted commit after
- you switched to "branch2".
+<3> But you can use `reset --keep` to remove the unwanted commit after
+ you switched to `branch2`.
Split a commit apart into a sequence of commits::
+
@@ -317,26 +317,27 @@ $ git commit ... <8>
+
<1> First, reset the history back one commit so that we remove the original
commit, but leave the working tree with all the changes. The -N ensures
- that any new files added with HEAD are still marked so that git add -p
+ that any new files added with `HEAD` are still marked so that `git add -p`
will find them.
-<2> Next, we interactively select diff hunks to add using the git add -p
+<2> Next, we interactively select diff hunks to add using the `git add -p`
facility. This will ask you about each diff hunk in sequence and you can
use simple commands such as "yes, include this", "No don't include this"
or even the very powerful "edit" facility.
<3> Once satisfied with the hunks you want to include, you should verify what
- has been prepared for the first commit by using git diff --cached. This
+ has been prepared for the first commit by using `git diff --cached`. This
shows all the changes that have been moved into the index and are about
to be committed.
-<4> Next, commit the changes stored in the index. The -c option specifies to
+<4> Next, commit the changes stored in the index. The `-c` option specifies to
pre-populate the commit message from the original message that you started
- with in the first commit. This is helpful to avoid retyping it. The HEAD@{1}
- is a special notation for the commit that HEAD used to be at prior to the
- original reset commit (1 change ago). See linkgit:git-reflog[1] for more
- details. You may also use any other valid commit reference.
+ with in the first commit. This is helpful to avoid retyping it. The
+ `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at
+ prior to the original reset commit (1 change ago).
+ See linkgit:git-reflog[1] for more details. You may also use any other
+ valid commit reference.
<5> You can repeat steps 2-4 multiple times to break the original code into
any number of commits.
<6> Now you've split out many of the changes into their own commits, and might
- no longer use the patch mode of git add, in order to select all remaining
+ no longer use the patch mode of `git add`, in order to select all remaining
uncommitted changes.
<7> Once again, check to verify that you've included what you want to. You may
also wish to verify that git diff doesn't show any remaining changes to be
@@ -353,17 +354,17 @@ The tables below show what happens when running:
git reset --option target
----------
-to reset the HEAD to another commit (`target`) with the different
+to reset the `HEAD` to another commit (`target`) with the different
reset options depending on the state of the files.
-In these tables, A, B, C and D are some different states of a
+In these tables, `A`, `B`, `C` and `D` are some different states of a
file. For example, the first line of the first table means that if a
-file is in state A in the working tree, in state B in the index, in
-state C in HEAD and in state D in the target, then "git reset --soft
-target" will leave the file in the working tree in state A and in the
-index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of
-the current branch, if you are on one) to "target" (which has the file
-in state D).
+file is in state `A` in the working tree, in state `B` in the index, in
+state `C` in `HEAD` and in state `D` in the target, then `git reset --soft
+target` will leave the file in the working tree in state `A` and in the
+index in state `B`. It resets (i.e. moves) the `HEAD` (i.e. the tip of
+the current branch, if you are on one) to `target` (which has the file
+in state `D`).
....
working index HEAD target working index HEAD
@@ -425,21 +426,21 @@ working index HEAD target working index HEAD
--keep B C C
....
-"reset --merge" is meant to be used when resetting out of a conflicted
+`reset --merge` is meant to be used when resetting out of a conflicted
merge. Any mergy operation guarantees that the working tree file that is
involved in the merge does not have local change wrt the index before
it starts, and that it writes the result out to the working tree. So if
we see some difference between the index and the target and also
between the index and the working tree, then it means that we are not
resetting out from a state that a mergy operation left after failing
-with a conflict. That is why we disallow --merge option in this case.
+with a conflict. That is why we disallow `--merge` option in this case.
-"reset --keep" is meant to be used when removing some of the last
+`reset --keep` is meant to be used when removing some of the last
commits in the current branch while keeping changes in the working
tree. If there could be conflicts between the changes in the commit we
want to remove and the changes in the working tree we want to keep,
the reset is disallowed. That's why it is disallowed if there are both
-changes between the working tree and HEAD, and between HEAD and the
+changes between the working tree and `HEAD`, and between `HEAD` and the
target. To be safe, it is also disallowed when there are unmerged
entries.
@@ -466,7 +467,7 @@ working index HEAD target working index HEAD
--keep (disallowed)
....
-X means any state and U means an unmerged index.
+`X` means any state and `U` means an unmerged index.
GIT
---
--
2.20.0.rc1.8.g46351a2c6f
^ permalink raw reply related
* [PATCH 1/2] git-reset.txt: render tables correctly under Asciidoctor
From: Martin Ågren @ 2018-11-28 19:02 UTC (permalink / raw)
To: git; +Cc: Paweł Samoraj
In-Reply-To: <cover.1543429054.git.martin.agren@gmail.com>
Asciidoctor removes the indentation of each line in these tables, so the
last lines of each table have a completely broken alignment.
Similar to 379805051d ("Documentation: render revisions correctly under
Asciidoctor", 2018-05-06), use an explicit literal block to indicate
that we want to keep the leading whitespace in the tables.
Because this gives us some extra indentation, we can remove the one that
we have been carrying explicitly. That is, drop the first six spaces of
indentation on each line. With Asciidoc (8.6.10), this results in
identical rendering before and after this commit, both for git-reset.1
and git-reset.html.
Reported-by: Paweł Samoraj <samoraj.pawel@gmail.com>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Documentation/git-reset.txt | 140 ++++++++++++++++++++----------------
1 file changed, 78 insertions(+), 62 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2dac95c71a..7c925e3a29 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -365,53 +365,65 @@ index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of
the current branch, if you are on one) to "target" (which has the file
in state D).
- working index HEAD target working index HEAD
- ----------------------------------------------------
- A B C D --soft A B D
- --mixed A D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- A B C C --soft A B C
- --mixed A C C
- --hard C C C
- --merge (disallowed)
- --keep A C C
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B B C D --soft B B D
- --mixed B D D
- --hard D D D
- --merge D D D
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B B C C --soft B B C
- --mixed B C C
- --hard C C C
- --merge C C C
- --keep B C C
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B C C D --soft B C D
- --mixed B D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B C C C --soft B C C
- --mixed B C C
- --hard C C C
- --merge B C C
- --keep B C C
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+ --keep A C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+ --keep B C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+ --keep B C C
+....
"reset --merge" is meant to be used when resetting out of a conflicted
merge. Any mergy operation guarantees that the working tree file that is
@@ -434,21 +446,25 @@ entries.
The following tables show what happens when there are unmerged
entries:
- working index HEAD target working index HEAD
- ----------------------------------------------------
- X U A B --soft (disallowed)
- --mixed X B B
- --hard B B B
- --merge B B B
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- X U A A --soft (disallowed)
- --mixed X A A
- --hard A A A
- --merge A A A
- --keep (disallowed)
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge B B B
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge A A A
+ --keep (disallowed)
+....
X means any state and U means an unmerged index.
--
2.20.0.rc1.8.g46351a2c6f
^ permalink raw reply related
* [PATCH 0/2] Re: Broken alignment in git-reset docs
From: Martin Ågren @ 2018-11-28 19:02 UTC (permalink / raw)
To: git; +Cc: Paweł Samoraj
In-Reply-To: <CAN0heSph-a08AzsihqqxfC=nqmUQLsqx-rKGULXQ-gmT4+c10w@mail.gmail.com>
On Wed, 28 Nov 2018 at 13:02, Martin Ågren <martin.agren@gmail.com> wrote:
>
> On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj <samoraj.pawel@gmail.com> wrote:
> >
> > The git-reset documentation page section which is accessible via URL
> > https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
> [...] The correct fix could be something like 379805051d
> ("Documentation: render revisions correctly under Asciidoctor",
> 2018-05-06).
Turns out it probably is, so here's a proposed fix, followed by a patch
to typeset more of this document in monospace. That should also make
things prettier, but not in such a dramatic way as the first patch.
This is obviously not 2.20-material. About where to queue this, I had
expected this to depend on 743e63f3ed ("Documentation: use 8-space tabs
with Asciidoctor", 2018-05-06) just like 379805051d does for proper
rendering, but from my testing, somehow it doesn't.
Paweł, I'm hoping this fix should be in v2.21 in a few months and then
eventually trickle down to git-scm. Thanks again for reporting this.
Martin Ågren (2):
git-reset.txt: render tables correctly under Asciidoctor
git-reset.txt: render literal examples as monospace
Documentation/git-reset.txt | 277 +++++++++++++++++++-----------------
1 file changed, 147 insertions(+), 130 deletions(-)
--
2.20.0.rc1.8.g46351a2c6f
^ permalink raw reply
* Re: Simple git push --tags deleted all branches
From: Mateusz Loskot @ 2018-11-28 18:13 UTC (permalink / raw)
To: git
In-Reply-To: <CABUeae-e33Jc4s4MezjhpVsEJ_0sO8QZ1mpa1z_79ZGuQWM-Xw@mail.gmail.com>
On Wed, 28 Nov 2018 at 17:50, Mateusz Loskot <mateusz@loskot.net> wrote:
>
> (using git version 2.19.2.windows.1)
> [...]
> I restored the repo and tried out
>
> git push origin 1.0
> git push origin --tags
>
> and this time both succeeded, without wiping out any refs.
And, to my surprise, this pushed all branches and all tags:
git push --all origin
So, I did not have to run follow with tags push only using
git push --tags origin
Has anything changes in [1] that now
--all
Push all branches ...AND tags?
[1] https://git-scm.com/docs/git-push#git-push---all
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
^ permalink raw reply
* Re: [PATCH] rebase -i: introduce the 'test' command
From: Paul Morelle @ 2018-11-28 16:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Users
In-Reply-To: <nycvar.QRO.7.76.6.1811281600240.41@tvgsbejvaqbjf.bet>
Hi Johannes,
On 28/11/18 16:19, Johannes Schindelin wrote:
> Hi Paul,
>
> On Wed, 28 Nov 2018, Paul Morelle wrote:
>
>> The 'exec' command can be used to run tests on a set of commits,
>> interrupting on failing commits to let the user fix the tests.
>>
>> However, the 'exec' line has been consumed, so it won't be ran again by
>> 'git rebase --continue' is ran, even if the tests weren't fixed.
>>
>> This commit introduces a new command 'test' equivalent to 'exec', except
>> that it is automatically rescheduled in the todo list if it fails.
>>
>> Signed-off-by: Paul Morelle <paul.morelle@gmail.com>
> Would it not make more sense to add a command-line option (and a config
> setting) to re-schedule failed `exec` commands? Like so:
Your proposition would do in most cases, however it is not possible to
make a distinction between reschedulable and non-reschedulable commands.
Do you think that we can ignore the distinction between reschedulable
and non-reschedulable commands in the same script?
In this case, I would add some tests to your patch below, and propose
the result on this mailing list.
> -- snip --
> diff --git a/builtin/rebase--interactive.c b/builtin/rebase--interactive.c
> index a2ab68ed0632..a9ab009fdbca 100644
> --- a/builtin/rebase--interactive.c
> +++ b/builtin/rebase--interactive.c
> @@ -192,6 +192,8 @@ int cmd_rebase__interactive(int argc, const char **argv, const char *prefix)
> OPT_STRING(0, "onto-name", &onto_name, N_("onto-name"), N_("onto name")),
> OPT_STRING(0, "cmd", &cmd, N_("cmd"), N_("the command to run")),
> OPT_RERERE_AUTOUPDATE(&opts.allow_rerere_auto),
> + OPT_BOOL(0, "reschedule-failed-exec", &opts.reschedule_failed_exec,
> + N_("automatically re-schedule any `exec` that fails")),
> OPT_END()
> };
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5b3e5baec8a0..700cbc4e150e 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -104,6 +104,7 @@ struct rebase_options {
> int rebase_merges, rebase_cousins;
> char *strategy, *strategy_opts;
> struct strbuf git_format_patch_opt;
> + int reschedule_failed_exec;
> };
>
> static int is_interactive(struct rebase_options *opts)
> @@ -415,6 +416,8 @@ static int run_specific_rebase(struct rebase_options *opts)
> argv_array_push(&child.args, opts->gpg_sign_opt);
> if (opts->signoff)
> argv_array_push(&child.args, "--signoff");
> + if (opts->reschedule_failed_exec)
> + argv_array_push(&child.args, "--reschedule-failed-exec");
>
> status = run_command(&child);
> goto finished_rebase;
> @@ -903,6 +906,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> "strategy")),
> OPT_BOOL(0, "root", &options.root,
> N_("rebase all reachable commits up to the root(s)")),
> + OPT_BOOL(0, "reschedule-failed-exec",
> + &options.reschedule_failed_exec,
> + N_("automatically re-schedule any `exec` that fails")),
> OPT_END(),
> };
> int i;
> @@ -1195,6 +1201,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> break;
> }
>
> + if (options.reschedule_failed_exec && !is_interactive(&options))
> + die(_("--reschedule-failed-exec requires an interactive rebase"));
> +
> if (options.git_am_opts.argc) {
> /* all am options except -q are compatible only with --am */
> for (i = options.git_am_opts.argc - 1; i >= 0; i--)
> diff --git a/sequencer.c b/sequencer.c
> index e1a4dd15f1a8..69bee63e116f 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -158,6 +158,7 @@ static GIT_PATH_FUNC(rebase_path_strategy, "rebase-merge/strategy")
> static GIT_PATH_FUNC(rebase_path_strategy_opts, "rebase-merge/strategy_opts")
> static GIT_PATH_FUNC(rebase_path_allow_rerere_autoupdate, "rebase-merge/allow_rerere_autoupdate")
> static GIT_PATH_FUNC(rebase_path_quiet, "rebase-merge/quiet")
> +static GIT_PATH_FUNC(rebase_path_reschedule_failed_exec, "rebase-merge/reschedule-failed-exec")
>
> static int git_sequencer_config(const char *k, const char *v, void *cb)
> {
> @@ -2362,6 +2363,9 @@ static int read_populate_opts(struct replay_opts *opts)
> opts->signoff = 1;
> }
>
> + if (file_exists(rebase_path_reschedule_failed_exec()))
> + opts->reschedule_failed_exec = 1;
> +
> read_strategy_opts(opts, &buf);
> strbuf_release(&buf);
>
> @@ -2443,6 +2447,8 @@ int write_basic_state(struct replay_opts *opts, const char *head_name,
> write_file(rebase_path_gpg_sign_opt(), "-S%s\n", opts->gpg_sign);
> if (opts->signoff)
> write_file(rebase_path_signoff(), "--signoff\n");
> + if (opts->reschedule_failed_exec)
> + write_file(rebase_path_reschedule_failed_exec(), "%s", "");
>
> return 0;
> }
> @@ -3586,9 +3592,10 @@ static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
> *end_of_arg = saved;
>
> /* Reread the todo file if it has changed. */
> - if (res)
> - ; /* fall through */
> - else if (stat(get_todo_path(opts), &st))
> + if (res) {
> + if (opts->reschedule_failed_exec)
> + reschedule = 1;
> + } else if (stat(get_todo_path(opts), &st))
> res = error_errno(_("could not stat '%s'"),
> get_todo_path(opts));
> else if (match_stat_data(&todo_list->stat, &st)) {
> diff --git a/sequencer.h b/sequencer.h
> index 5071a73563f1..1f865dae2618 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -39,6 +39,7 @@ struct replay_opts {
> int allow_empty_message;
> int keep_redundant_commits;
> int verbose;
> + int reschedule_failed_exec;
>
> int mainline;
>
> -- snap --
>
> That would avoid your having to add a `--test` option accompanying the `--exec`
> option (which is missing from your patch).
You are right about the missing `--test` option, which I could also add
to a new version of this patch.
Cheers,
Paul
> Ciao,
> Johannes
>
>> ---
>> Documentation/git-rebase.txt | 9 ++++++---
>> rebase-interactive.c | 1 +
>> sequencer.c | 23 +++++++++++++++--------
>> t/lib-rebase.sh | 4 +++-
>> t/t3404-rebase-interactive.sh | 16 ++++++++++++++++
>> 5 files changed, 41 insertions(+), 12 deletions(-)
>>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
>> index 80793bad8..c8f565637 100644
>> --- a/Documentation/git-rebase.txt
>> +++ b/Documentation/git-rebase.txt
>> @@ -693,8 +693,8 @@ $ git rebase -i -p --onto Q O
>> Reordering and editing commits usually creates untested intermediate
>> steps. You may want to check that your history editing did not break
>> anything by running a test, or at least recompiling at intermediate
>> -points in history by using the "exec" command (shortcut "x"). You may
>> -do so by creating a todo list like this one:
>> +points in history by using the "exec" command (shortcut "x") or the
>> +"test" command. You may do so by creating a todo list like this one:
>> -------------------------------------------
>> pick deadbee Implement feature XXX
>> @@ -702,7 +702,7 @@ fixup f1a5c00 Fix to feature XXX
>> exec make
>> pick c0ffeee The oneline of the next commit
>> edit deadbab The oneline of the commit after
>> -exec cd subdir; make test
>> +test cd subdir; make test
>> ...
>> -------------------------------------------
>> @@ -715,6 +715,9 @@ in `$SHELL`, or the default shell if `$SHELL` is
>> not set), so you can
>> use shell features (like "cd", ">", ";" ...). The command is run from
>> the root of the working tree.
>> +The "test" command does the same, but will remain in the todo list as
>> +the next command, until it succeeds.
>> +
>> ----------------------------------
>> $ git rebase -i --exec "make test"
>> ----------------------------------
>> diff --git a/rebase-interactive.c b/rebase-interactive.c
>> index 78f3263fc..4a408661d 100644
>> --- a/rebase-interactive.c
>> +++ b/rebase-interactive.c
>> @@ -14,6 +14,7 @@ void append_todo_help(unsigned edit_todo, unsigned
>> keep_empty,
>> "s, squash <commit> = use commit, but meld into previous commit\n"
>> "f, fixup <commit> = like \"squash\", but discard this commit's log
>> message\n"
>> "x, exec <command> = run command (the rest of the line) using shell\n"
>> +" test <command> = same as exec command, but keep it in TODO if it
>> fails\n"
>> "b, break = stop here (continue rebase later with 'git rebase
>> --continue')\n"
>> "d, drop <commit> = remove commit\n"
>> "l, label <label> = label current HEAD with a name\n"
>> diff --git a/sequencer.c b/sequencer.c
>> index e1a4dd15f..c3dde6910 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -1508,6 +1508,7 @@ enum todo_command {
>> TODO_SQUASH,
>> /* commands that do something else than handling a single commit */
>> TODO_EXEC,
>> + TODO_TEST,
>> TODO_BREAK,
>> TODO_LABEL,
>> TODO_RESET,
>> @@ -1530,6 +1531,7 @@ static struct {
>> { 'f', "fixup" },
>> { 's', "squash" },
>> { 'x', "exec" },
>> + { 0, "test" },
>> { 'b', "break" },
>> { 'l', "label" },
>> { 't', "reset" },
>> @@ -2072,7 +2074,7 @@ static int parse_insn_line(struct todo_item *item,
>> const char *bol, char *eol)
>> command_to_string(item->command));
>> if (item->command == TODO_EXEC || item->command == TODO_LABEL ||
>> - item->command == TODO_RESET) {
>> + item->command == TODO_RESET || item->command == TODO_TEST) {
>> item->commit = NULL;
>> item->arg = bol;
>> item->arg_len = (int)(eol - bol);
>> @@ -3576,7 +3578,7 @@ static int pick_commits(struct todo_list
>> *todo_list, struct replay_opts *opts)
>> item->arg, item->arg_len, opts,
>> res, to_amend);
>> }
>> - } else if (item->command == TODO_EXEC) {
>> + } else if (item->command == TODO_EXEC || item->command == TODO_TEST) {
>> char *end_of_arg = (char *)(item->arg + item->arg_len);
>> int saved = *end_of_arg;
>> struct stat st;
>> @@ -3586,9 +3588,12 @@ static int pick_commits(struct todo_list
>> *todo_list, struct replay_opts *opts)
>> *end_of_arg = saved;
>> /* Reread the todo file if it has changed. */
>> - if (res)
>> + if (res) {
>> ; /* fall through */
>> - else if (stat(get_todo_path(opts), &st))
>> + if (item->command == TODO_TEST) {
>> + reschedule = 1;
>> + }
>> + } else if (stat(get_todo_path(opts), &st))
>> res = error_errno(_("could not stat '%s'"),
>> get_todo_path(opts));
>> else if (match_stat_data(&todo_list->stat, &st)) {
>> @@ -3622,10 +3627,12 @@ static int pick_commits(struct todo_list
>> *todo_list, struct replay_opts *opts)
>> return error(_("unknown command %d"), item->command);
>> if (reschedule) {
>> - advise(_(rescheduled_advice),
>> - get_item_line_length(todo_list,
>> - todo_list->current),
>> - get_item_line(todo_list, todo_list->current));
>> + if (item->command != TODO_TEST) {
>> + advise(_(rescheduled_advice),
>> + get_item_line_length(todo_list,
>> + todo_list->current),
>> + get_item_line(todo_list, todo_list->current));
>> + }
>> todo_list->current--;
>> if (save_todo(todo_list, opts))
>> return -1;
>> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
>> index 7ea30e500..7d36f00bd 100644
>> --- a/t/lib-rebase.sh
>> +++ b/t/lib-rebase.sh
>> @@ -19,6 +19,8 @@
>> #
>> # "exec_cmd_with_args" -- add an "exec cmd with args" line.
>> #
>> +# "test_cmd_with_args" -- add a "test cmd with args" line.
>> +#
>> # "#" -- Add a comment line.
>> #
>> # ">" -- Add a blank line.
>> @@ -49,7 +51,7 @@ set_fake_editor () {
>> case $line in
>> pick|p|squash|s|fixup|f|edit|e|reword|r|drop|d)
>> action="$line";;
>> - exec_*|x_*|break|b)
>> + exec_*|x_*|break|b|test_*)
>> echo "$line" | sed 's/_/ /g' >> "$1";;
>> "#")
>> echo '# comment' >> "$1";;
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index 7a440e08d..14c60b14d 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -1453,4 +1453,20 @@ test_expect_success 'valid author header when
>> author contains single quote' '
>> test_cmp expected actual
>> '
>> +test_expect_success 'rebase -i keeps test until it passes' '
>> + git checkout master &&
>> + (
>> + set_fake_editor &&
>> + FAKE_LINES="1 test_false 2 3 4 5" &&
>> + export FAKE_LINES &&
>> + test_must_fail git rebase -i A &&
>> + test_cmp_rev B HEAD &&
>> + test_must_fail git rebase --continue &&
>> + test_cmp_rev B HEAD &&
>> + FAKE_LINES="test_true 2 3 4" git rebase --edit-todo &&
>> + git rebase --continue
>> + ) &&
>> + test_cmp_rev master HEAD
>> +'
>> +
>> test_done
>> --
>> 2.19.1
>>
>>
^ permalink raw reply
* Simple git push --tags deleted all branches
From: Mateusz Loskot @ 2018-11-28 16:50 UTC (permalink / raw)
To: git
Hi,
(using git version 2.19.2.windows.1)
I've just encountered one of those WTH moments.
I have a bare repository
core.git (BARE:master) $ git branch
1.0
2.0
* master
core.git (BARE:master) $ git tag
1.0.1651
1.0.766
2.0.1103
2.0.1200
I published the repo using: git push --all --follow-tags
This succeeded, but there seem to be no tags pushed, just branches.
So, I followed with
core.git (BARE:master) $ git push --tags
To XXX
- [deleted] 1.0
- [deleted] 2.0
! [remote rejected] master (refusing to delete the current
branch: refs/heads/master)
error: failed to push some refs to 'XXX'
And, I've found out that all branches and tags have been
wiped in both, local repo and remote :)
I restored the repo and tried out
git push origin 1.0
git push origin --tags
and this time both succeeded, without wiping out any refs.
Could anyone help me to understand why remote-less
git push --tags
is/was so dangerous and unforgiving?!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
^ permalink raw reply
* Re: [PATCH v3 1/7] rebase: fix incompatible options error message
From: Elijah Newren @ 2018-11-28 16:31 UTC (permalink / raw)
To: Nguyễn Thái Ngọc
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Pratik Karki, Phillip Wood
In-Reply-To: <CACsJy8BpVgTaE0EM9qkj5dK68x85ZbMmDZ-S7Jvf_KDqYrAW=A@mail.gmail.com>
On Wed, Nov 28, 2018 at 8:12 AM Duy Nguyen <pclouds@gmail.com> wrote:
>
> On Thu, Nov 22, 2018 at 7:32 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > In commit f57696802c30 ("rebase: really just passthru the `git am`
> > options", 2018-11-14), the handling of `git am` options was simplified
> > dramatically (and an option parsing bug was fixed), but it introduced
> > a small regression in the error message shown when options only
> > understood by separate backends were used:
> >
> > $ git rebase --keep --ignore-whitespace
> > fatal: error: cannot combine interactive options (--interactive, --exec,
> > --rebase-merges, --preserve-merges, --keep-empty, --root + --onto) with
> > am options (.git/rebase-apply/applying)
> >
> > $ git rebase --merge --ignore-whitespace
> > fatal: error: cannot combine merge options (--merge, --strategy,
> > --strategy-option) with am options (.git/rebase-apply/applying)
> >
> > Note that in both cases, the list of "am options" is
> > ".git/rebase-apply/applying", which makes no sense. Since the lists of
> > backend-specific options is documented pretty thoroughly in the rebase
> > man page (in the "Incompatible Options" section, with multiple links
> > throughout the document), and since I expect this list to change over
> > time, just simplify the error message.
>
> Can we simplify it further and remove the "error: " prefix? "fatal:
> error: " looks redundant.
Sure, I can do that. Looks like there are a few other cases that need
fixing as well:
$ git grep error: builtin/rebase.c
builtin/rebase.c: die(_("error: cannot combine
interactive options "
builtin/rebase.c: die(_("error: cannot combine
merge options (--merge, "
builtin/rebase.c: die(_("error: cannot combine
'--preserve-merges' with "
builtin/rebase.c: die(_("error: cannot combine
'--rebase-merges' with "
builtin/rebase.c: die(_("error: cannot combine
'--rebase-merges' with "
Perhaps, for consistency, I should also change the error message in
the git-legacy-rebase.sh script to use 'fatal' instead of 'error'?:
$ git grep error: *rebase*.sh
git-legacy-rebase.sh: die "$(gettext "error: cannot
combine interactive options (--interactive, --exec, --rebase-merges,
--preserve-merges, --keep-empty, --root + --onto) with am options
($incompatible_opts)")"
git-legacy-rebase.sh: die "$(gettext "error: cannot
combine merge options (--merge, --strategy, --strategy-option) with am
options ($incompatible_opts)")"
git-legacy-rebase.sh: die "$(gettext "error: cannot combine
'--signoff' with '--preserve-merges'")"
git-legacy-rebase.sh: die "$(gettext "error: cannot combine
'--preserve-merges' with '--rebase-merges'")"
git-legacy-rebase.sh: die "$(gettext "error: cannot combine
'--rebase-merges' with '--strategy-option'")"
git-legacy-rebase.sh: die "$(gettext "error: cannot combine
'--rebase-merges' with '--strategy'")"
^ permalink raw reply
* Re: [PATCH v3 1/7] rebase: fix incompatible options error message
From: Duy Nguyen @ 2018-11-28 16:12 UTC (permalink / raw)
To: Elijah Newren
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Pratik Karki, phillip.wood
In-Reply-To: <20181122044841.20993-2-newren@gmail.com>
On Thu, Nov 22, 2018 at 7:32 PM Elijah Newren <newren@gmail.com> wrote:
>
> In commit f57696802c30 ("rebase: really just passthru the `git am`
> options", 2018-11-14), the handling of `git am` options was simplified
> dramatically (and an option parsing bug was fixed), but it introduced
> a small regression in the error message shown when options only
> understood by separate backends were used:
>
> $ git rebase --keep --ignore-whitespace
> fatal: error: cannot combine interactive options (--interactive, --exec,
> --rebase-merges, --preserve-merges, --keep-empty, --root + --onto) with
> am options (.git/rebase-apply/applying)
>
> $ git rebase --merge --ignore-whitespace
> fatal: error: cannot combine merge options (--merge, --strategy,
> --strategy-option) with am options (.git/rebase-apply/applying)
>
> Note that in both cases, the list of "am options" is
> ".git/rebase-apply/applying", which makes no sense. Since the lists of
> backend-specific options is documented pretty thoroughly in the rebase
> man page (in the "Incompatible Options" section, with multiple links
> throughout the document), and since I expect this list to change over
> time, just simplify the error message.
Can we simplify it further and remove the "error: " prefix? "fatal:
error: " looks redundant.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 1/7] rebase: fix incompatible options error message
From: Elijah Newren @ 2018-11-28 15:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Pratik Karki, Phillip Wood
In-Reply-To: <nycvar.QRO.7.76.6.1811280000020.41@tvgsbejvaqbjf.bet>
On Wed, Nov 28, 2018 at 12:28 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Elijah,
>
> On Wed, 21 Nov 2018, Elijah Newren wrote:
>
> > In commit f57696802c30 ("rebase: really just passthru the `git am`
> > options", 2018-11-14), the handling of `git am` options was simplified
> > dramatically (and an option parsing bug was fixed), but it introduced
> > a small regression in the error message shown when options only
> > understood by separate backends were used:
> >
> > $ git rebase --keep --ignore-whitespace
> > fatal: error: cannot combine interactive options (--interactive, --exec,
> > --rebase-merges, --preserve-merges, --keep-empty, --root + --onto) with
> > am options (.git/rebase-apply/applying)
> >
> > $ git rebase --merge --ignore-whitespace
> > fatal: error: cannot combine merge options (--merge, --strategy,
> > --strategy-option) with am options (.git/rebase-apply/applying)
> >
> > Note that in both cases, the list of "am options" is
> > ".git/rebase-apply/applying", which makes no sense. Since the lists of
> > backend-specific options is documented pretty thoroughly in the rebase
> > man page (in the "Incompatible Options" section, with multiple links
> > throughout the document), and since I expect this list to change over
> > time, just simplify the error message.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
>
> This patch is obviously good.
>
> Given that you embedded it in the patch series that makes the sequencer
> the work horse also for the `merge` backend of `git rebase` in addition to
> the `interactive` one, may I assume that you intend this patch for post
> v2.20.0?
>
> Ciao,
> Dscho
I think post v2.20.0 probably makes the most sense. I was unsure what
the policy was around changing strings late in the cycle, but figured
that the worst case with this regression is someone basically
understands what the message is trying to say but thinks it might be
saying more than they understand and reach out with questions. In
contrast, if we decide to change the string and some translators don't
have enough time to translate it before 2.20.0 goes out, then someone
who doesn't understand English gets an English error message, which
seems a little worse.
I at least wanted it to be discussed, though, which is why I
highlighted it in the cover letter.
^ permalink raw reply
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