* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Ævar Arnfjörð Bjarmason @ 2018-12-11 20:51 UTC (permalink / raw)
To: Carlo Arenas; +Cc: sandals, git, pcre-dev
In-Reply-To: <CAPUEspjHs7+G+FHXjxb4rCcNLqaybbhZESik=14_9Q5h2HMzMA@mail.gmail.com>
On Tue, Dec 11 2018, Carlo Arenas wrote:
> On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Mon, Dec 10 2018, brian m. carlson wrote:
>> > Considering that some Linux users use PaX kernels with standard
>> > distributions and that most BSD kernels can be custom-compiled with a
>> > variety of options enabled or disabled, I think this is something we
>> > should detect dynamically.
>>
>> Right. I'm asking whether we're mixing up cases where it can always be
>> detected at compile-time on some systems v.s. cases where it'll
>> potentially change at runtime.
>
> the closer we come to a system specific issues is with macOS where the
> compiler (in some newer versions) is allocating the memory using the
> MAP_JIT flag, which seems was originally meant to be only used in iOS
> and has the strange characteristic of failing the mmap for versions
> older than 10.14 if it was called more than once.
>
> IMHO as brian pointed out, this is better done at runtime.
Sure. Just something I was wondering since it wasn't clear from the
patch. Makes sense, if it's always runtime (or not worth the effort to
divide the two) let's do that.
>> >> I'm inclined to suggest that we should have another ifdef here for "if
>> >> JIT fails I'd like it to die", so that e.g. packages I build (for
>> >> internal use) don't silently slow down in the future, only for me to
>> >> find some months later that someone enabled an overzealous SELinux
>> >> policy and we swept this under the rug.
>> >
>> > My view is that JIT is a nice performance optimization, but it's
>> > optional. I honestly don't think it should even be exposed through the
>> > API: if it works, then things are faster, and if it doesn't, then
>> > they're not. I don't see the value in an option for causing things to be
>> > broken if someone improves the security of the system.
>>
>> For many users that's definitely the case, but for others that's like
>> saying a RDBMS is still going to be functional if the "ORDER BY"
>> function degrades to bubblesort. The JIT improves performance my
>> multi-hundred percents sometimes, so some users (e.g. me) rely on that
>> not being silently degraded.
>
> the opposite is also true, specially considering that some old
> versions of pcre result in a segfault instead of an error message and
> therefore since there is no way to disable JIT, the only option left
> is not to use `git grep -P` (or the equivalent git log call)
Right, of course it segfaulting is a bug...
>> So I'm wondering if we can have something like:
>>
>> if (!jit)
>> if (must_have_jit)
>> BUG(...); // Like currently
>> else
>> fallback(); // new behavior
>
> I am wondering if something like a `git doctor` command might be an
> interesting alternative to this.
>
> This way we could (for ex: in NetBSD) give the user a hint of what to
> do to make their git grep -P faster when we detect we are running the
> fallback, and might be useful as well to provide hints for
> optimizations that could be used in other cases (probably even
> depending on the size of the git repository)
Such a command has been discussed before on-list. I think it's a good
idea for the more fuzzy things like optimization suggests, but for the
case of expecting something at compile-time where not having that at
runtime is a boolean state it's nicer to just die with a BUG(...).
> For your use case, you just need to add a crontab that will trigger an
> alarm if this command ever mentions PCRE
...The reason I'd like it to die is because it neatly and naturally
integrates with all existing test infrastructure I have. I.e. build
package, run stress tests on all sorts of machines, see that it passes,
and SELinux isn't ruining it or whatever.
I know this works now (I always get PCRE v2 JIT) because it doesn't die
or segfault. I'd like not to have it regress to having worse
performance.
Having a cronjob to test for "does PCRE v2 JIT still work?" is not as
easy & isn't a drop-in solution.
^ permalink raw reply
* Re: [PATCH 2/2] mingw: allow absolute paths without drive prefix
From: Johannes Sixt @ 2018-12-11 20:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Schindelin via GitGitGadget, git, Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1812111134250.43@tvgsbejvaqbjf.bet>
Am 11.12.18 um 12:25 schrieb Johannes Schindelin:
> On Mon, 10 Dec 2018, Johannes Sixt wrote:
>>> diff --git a/compat/mingw.c b/compat/mingw.c
>>> index 34b3880b29..4d009901d8 100644
>>> --- a/compat/mingw.c
>>> +++ b/compat/mingw.c
>>> @@ -928,11 +928,19 @@ unsigned int sleep (unsigned int seconds)
>>> char *mingw_mktemp(char *template)
>>> {
>>> wchar_t wtemplate[MAX_PATH];
>>> + int offset = 0;
>>> +
>>> if (xutftowcs_path(wtemplate, template) < 0)
>>> return NULL;
>>> +
>>> + if (is_dir_sep(template[0]) && !is_dir_sep(template[1]) &&
>>> + iswalpha(wtemplate[0]) && wtemplate[1] == L':') {
>>> + /* We have an absolute path missing the drive prefix */
>>
>> This comment is true for the source part, template, but I can't find
>> where the destination, wtemplate, suddenly gets the drive prefix. As far
>> as I can see, xutftowcs_path() just does a plain textual conversion
>> without any interpretation of the text as path. Can you explain it?
>
> It is legal on Windows for such a path to lack the drive prefix, also in
> the wide-character version. So the explanation is: even `wtemplate` won't
> get the drive prefix. It does not need to.
I'm sorry, my question was extremely fuzzy. I actually wanted to know
how the condition that you introduce in this patch can ever be true.
And after looking at the Git for Windows code, I could answer it myself:
it cannot. Not with this patch alone. In GfW, there is additional code
in xutftowcs_path() that massages wtemplate to receive a drive prefix;
but vanilla Git does not have that code, so that is_dir_sep(template[0])
and iswalpha(wtemplate[0]) can never be true at the same time at this point.
-- Hannes
^ permalink raw reply
* [PATCH 1/1] .gitattributes: ensure t/oid-info/* has eol=lf
From: Derrick Stolee via GitGitGadget @ 2018-12-11 20:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Derrick Stolee
In-Reply-To: <pull.98.git.gitgitgadget@gmail.com>
From: Derrick Stolee <dstolee@microsoft.com>
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is sensitive to CRLF
line endings, causing a problem when the test suite is run on a
Windows machine that converts LF to CRLF.
Exclude the files in this folder from this conversion.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
.gitattributes | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitattributes b/.gitattributes
index acf853e029..3738cea7eb 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -13,3 +13,4 @@
/Documentation/gitk.txt conflict-marker-size=32
/Documentation/user-manual.txt conflict-marker-size=32
/t/t????-*.sh conflict-marker-size=32
+/t/oid-info/* eol=lf
--
gitgitgadget
^ permalink raw reply related
* [PATCH 0/1] .gitattributes: ensure t/oid-info/* has eol=lf
From: Derrick Stolee via GitGitGadget @ 2018-12-11 20:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I noticed that our CI builds (see [1] for an example) were returning success
much faster than they did before Git v2.20.0. Turns out that there was a
test script failure involving the new test hash logic.
error: bug in the test script: bad hash algorithm
make[1]: *** [Makefile:56: t0000-basic.sh] Error 1
make[1]: *** Waiting for unfinished jobs....
The reason this passed was because we were running this command in our
build:
make GIT_TEST_OPTS=--quiet -j 10 -C t ||
make GIT_TEST_OPTS=\"-i -v -x\" -k -C t failed
The first make failed, but the test script did not record any failed tests
and hence the second command succeeded.
The test bug relates to this function added by 2c02b110d "t: add test
functions to translate hash-related values":
+# Load key-value pairs from stdin suitable for use with test_oid. Blank lines
+# and lines starting with "#" are ignored. Keys must be shell identifier
+# characters.
+#
+# Examples:
+# rawsz sha1:20
+# rawsz sha256:32
+test_oid_cache () {
+ local tag rest k v &&
+
+ { test -n "$test_hash_algo" || test_detect_hash; } &&
+ while read tag rest
+ do
+ case $tag in
+ \#*)
+ continue;;
+ ?*)
+ # non-empty
+ ;;
+ *)
+ # blank line
+ continue;;
+ esac &&
+
+ k="${rest%:*}" &&
+ v="${rest#*:}" &&
+
+ if ! expr "$k" : '[a-z0-9][a-z0-9]*$' >/dev/null
+ then
+ error 'bug in the test script: bad hash algorithm'
+ fi &&
+ eval "test_oid_${k}_$tag=\"\$v\""
+ done
+}
The verbose output included these values. Note how '\r' appears in the
variable values.
++ test_oid_init
++ test -n ''
++ test_detect_hash
++ test_hash_algo=sha1
++ test_oid_cache
++ local tag rest k v
++ test -n sha1
++ read tag rest
++ case $tag in
++ k=sha1
++ v=$'20\r'
++ expr sha1 : '[a-z0-9][a-z0-9]*$'
++ eval 'test_oid_sha1_rawsz="$v"'
+++ test_oid_sha1_rawsz=$'20\r'
++ read tag rest
++ case $tag in
++ k=sha256
++ v=$'32\r'
++ expr sha256 : '[a-z0-9][a-z0-9]*$'
++ eval 'test_oid_sha256_rawsz="$v"'
+++ test_oid_sha256_rawsz=$'32\r'
++ read tag rest
++ case $tag in
++ k=
++ v=
++ expr '' : '[a-z0-9][a-z0-9]*$'
[1] https://gvfs.visualstudio.com/ci/_build/results?buildId=4815
Derrick Stolee (1):
.gitattributes: ensure t/oid-info/* has eol=lf
.gitattributes | 1 +
1 file changed, 1 insertion(+)
base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-98%2Fderrickstolee%2Ftest-oid-fix-windows-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-98/derrickstolee/test-oid-fix-windows-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/98
--
gitgitgadget
^ permalink raw reply
* Re: [PATCH] commit: abort before commit-msg if empty message
From: Jonathan Tan @ 2018-12-11 20:14 UTC (permalink / raw)
To: gitster; +Cc: jonathantanmy, git, jrnieder
In-Reply-To: <xmqqin048te8.fsf@gitster-ct.c.googlers.com>
> Jonathan Tan <jonathantanmy@google.com> writes:
>
> > When a user runs "git commit" without specifying a message, an editor
> > appears with advice:
> >
> > Please enter the commit message for your changes. Lines starting
> > with '#' will be ignored, and an empty message aborts the commit.
> >
> > However, if the user supplies an empty message and has a commit-msg hook
> > which updates the message to be non-empty, the commit proceeds to occur,
> > despite what the advice states.
>
> When "--no-edit" is given, and when commit-msg fills that blank, the
> command should go ahead and record the commit, I think.
>
> An automation where commit-msg is used to produce whatever
> appropriate message for the automation is entirely a reasonable
> thing to arrange. Of course, you can move the logic to produce an
> appropriate message for the automation from commit-msg to the script
> that drives the "git commit" and use the output of that logic as the
> value for the "-m" option to achieve the same, so in that sense,
> there is an escape hatch even if you suddenly start to forbid such a
> working set-up, but it nevertheless is unnecessary busywork for those
> with such a set-up to adjust to this change.
Thanks for bringing up this workflow. Note that this patch only changes
behavior when the editor is brought up and, thus, the advice is shown -
see the check for use_editor in prepare_to_commit(). So there should be
no change if --no-edit is given, but I acknowledge that there will be a
negative change if the user brings up the editor and just immediately
quits it (which can happen in a workflow where commit-msg always
produces an appropriate message, but the user can provide additional
information if desired).
> I actually think in this partcular case, the commit-msg hook that
> adds Change-ID to an empty message is BUGGY. If the hook looked at
> the message contents and refrains from making an otherwise empty
> message to non-empty, there is no need for any change here.
>
> In any case, you'll have plenty of time to make your case after the
> rc freeze. I am not so sympathetic to a patch that makes us bend
> backwards to support such a buggy hook to e honest.
That's reasonable. In any case, we'll also look at fixing the Gerrit
hook - at the very least, so that it can work with versions of Git that
do not have this patch of mine (or something similar).
^ permalink raw reply
* Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
From: Carlo Arenas @ 2018-12-11 20:11 UTC (permalink / raw)
To: avarab; +Cc: sandals, git, pcre-dev
In-Reply-To: <87pnu9yekk.fsf@evledraar.gmail.com>
On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Mon, Dec 10 2018, brian m. carlson wrote:
> > Considering that some Linux users use PaX kernels with standard
> > distributions and that most BSD kernels can be custom-compiled with a
> > variety of options enabled or disabled, I think this is something we
> > should detect dynamically.
>
> Right. I'm asking whether we're mixing up cases where it can always be
> detected at compile-time on some systems v.s. cases where it'll
> potentially change at runtime.
the closer we come to a system specific issues is with macOS where the
compiler (in some newer versions) is allocating the memory using the
MAP_JIT flag, which seems was originally meant to be only used in iOS
and has the strange characteristic of failing the mmap for versions
older than 10.14 if it was called more than once.
IMHO as brian pointed out, this is better done at runtime.
> >> I'm inclined to suggest that we should have another ifdef here for "if
> >> JIT fails I'd like it to die", so that e.g. packages I build (for
> >> internal use) don't silently slow down in the future, only for me to
> >> find some months later that someone enabled an overzealous SELinux
> >> policy and we swept this under the rug.
> >
> > My view is that JIT is a nice performance optimization, but it's
> > optional. I honestly don't think it should even be exposed through the
> > API: if it works, then things are faster, and if it doesn't, then
> > they're not. I don't see the value in an option for causing things to be
> > broken if someone improves the security of the system.
>
> For many users that's definitely the case, but for others that's like
> saying a RDBMS is still going to be functional if the "ORDER BY"
> function degrades to bubblesort. The JIT improves performance my
> multi-hundred percents sometimes, so some users (e.g. me) rely on that
> not being silently degraded.
the opposite is also true, specially considering that some old
versions of pcre result in a segfault instead of an error message and
therefore since there is no way to disable JIT, the only option left
is not to use `git grep -P` (or the equivalent git log call)
> So I'm wondering if we can have something like:
>
> if (!jit)
> if (must_have_jit)
> BUG(...); // Like currently
> else
> fallback(); // new behavior
I am wondering if something like a `git doctor` command might be an
interesting alternative to this.
This way we could (for ex: in NetBSD) give the user a hint of what to
do to make their git grep -P faster when we detect we are running the
fallback, and might be useful as well to provide hints for
optimizations that could be used in other cases (probably even
depending on the size of the git repository)
For your use case, you just need to add a crontab that will trigger an
alarm if this command ever mentions PCRE
Carlo
^ permalink raw reply
* Re: [PATCH 6/8] checkout: add --cached option
From: Duy Nguyen @ 2018-12-11 19:23 UTC (permalink / raw)
To: Elijah Newren; +Cc: Junio C Hamano, Thomas Gummerer, Git Mailing List
In-Reply-To: <CABPp-BGQwtok1T3WmY3ndBG6RjbESSOgmbZxkWiN-avqfUjDVg@mail.gmail.com>
On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Duy Nguyen <pclouds@gmail.com> writes:
> >
> > > Elijah wanted another mode (and I agree) that modifies worktree but
> > > leaves the index alone. This is most useful (or least confusing) when
> > > used with <tree-ish> and would be default in restore-files. I'm not
> > > saying you have to implement it, but how do the new command line
> > > options are designed to make sense?
> >
> > I'd model it after "git apply", i.e.
> >
> > git restore-files [--tree=<treeish>] <pathspec>
> >
> > would work only on the working tree files,
> >
> > git restore-files --tree=<treeish> --cached <pathspec>
> >
> > would match the entries in the index that match pathspec to the
> > given treeish without touching the working tree, and
> >
> > git restore-files --tree=<treeish> --index <pathspec>
> >
> > would be both.
> >
> > I have never been happy with the phraso, the (arbitrary) distinction
> > between --cached/--index we use, so in the very longer term (like,
> > introducing synonym at 3.0 boundary and deprecating older ones at
> > 4.0 boundary), it may not be a bad idea to rename "--index" to
> > "--index-and-working-tree" and "--cached" to "--index-only".
> >
> > But until that happens, it would be better to use these two
> > consistently.
>
> I agree that consistency is important, but trying to distinguish
> between "--cached" and "--index" is _extremely_ painful. I still
> can't keep the distinction straight and have to look it up every time
> I want to use either. I don't know how to possibly teach users the
> meaning. Could we introduce synonyms earlier at least, and make the
> synonyms more prominent than the "--cached" and "--index" terms in the
> documentation?
For git-checkout I think --index and --cached fit. For restore-files,
if you come up with better names, I'll gladly use that. Otherwise I'll
just use these.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 1/1] git clone <url> C:\cygwin\home\USER\repo' is working (again)
From: Torsten Bögershausen @ 2018-12-11 18:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, svnpenn
In-Reply-To: <nycvar.QRO.7.76.6.1812111420570.43@tvgsbejvaqbjf.bet>
>
> Can you please replace the rather unnecessary, very, very long
> `win_path_utils_` function name prefix by the much better prefix `win32_`,
> to keep in line with the current, already existing, surrounding files'
> convention? Thanks a bunch.
>
That makes sense - thanks for the suggestion & testing.
^ permalink raw reply
* Re: Difficulty with parsing colorized diff output
From: George King @ 2018-12-11 18:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jeff King, Stefan Beller, git
In-Reply-To: <EB1AF739-F97B-4905-9736-2A003722AD9A@gmail.com>
I just noticed that while `wsErrorHighlight = none` fixes the problem of extra green codes for regular diff, it fails to have any effect during interactive `git add -p`.
> On 2018-12-11, at 11:41 AM, George King <george.w.king@gmail.com> wrote:
>
> I first started playing around with terminal colors about 5 years ago, and I recall learning the hard way that Apple Terminal at least behaves very strangely when you have background colors cross line boundaries: background colors disappeared when I scrolled lines back into view. I filed a bug thinking it couldn't be right and Apple closed it as behaving according to compatibility expectations. I never figured out whether they had misunderstood my report or if old terminals were just that crazy. Instead I decided that the safe thing to do was reset after every line. Perhaps some git author reached the same conclusion.
>
> From the perspective of parsing this output, it is really much easier if each line can be understood without considering state of previous lines. If anything, I think it is a safe approach to ensuring that it renders correctly on various terminals as well.
>
>> On 2018-12-11, at 11:28 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>>
>>
>> On Tue, Dec 11 2018, Jeff King wrote:
>>
>>> On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
>>>
>>>>> Context lines do have both. It's just that the default color for context
>>>>> lines is empty. ;)
>>>>
>>>> The content itself can contain color codes.
>>>>
>>>> Instead of unconditionally resetting each line, we could parse each
>>>> content line to determine if we actually have to reset the colors.
>>>
>>> Good point. I don't recall that being the motivation back when this
>>> behavior started, but it's a nice side effect (and the more recent line
>>> you mentioned in emit_line_0 certainly is doing it intentionally).
>>>
>>> That doesn't cover _other_ terminal codes, which could also make for
>>> confusing output, but I do think color codes are somewhat special. We
>>> generally send patches through "less -R", which will pass through the
>>> colors but show escaped versions of other codes.
>>
>> I wonder if optimizing this one way or the other matters for some
>> terminals. I.e. if we print out some huge diff of thousands of
>> consecutive "green" added lines is it faster/slower on some of them to
>> do one "begin green" and "reset" at the end, or is one line at a time
>> better, or doesn't it matter at all?
>
^ permalink raw reply
* Outreachy - Blog
From: TANUSHREE TUMANE @ 2018-12-11 18:21 UTC (permalink / raw)
To: git
Hi everyone,
I am an Outreachy GIT Intern. I will be working on the project
"Improve git-bisect", with Christian Couder and Johannes Schindelin
as mentors.
You can read my blog here: http://tanu1596.blogspot.com/
I will be posting every one or two weeks about the ongoing work.
- Tanushree Tumane
^ permalink raw reply
* Re: [BUG] Git 2.20: `git help -a' hangs if specific git alias occurs
From: SZEDER Gábor @ 2018-12-11 17:46 UTC (permalink / raw)
To: Sebastian Gniazdowski; +Cc: git
In-Reply-To: <CAKc7PVAzSOknfmy7p09zF4LOi4t66CBmd27ZuQ39_wKYWSiiUA@mail.gmail.com>
On Tue, Dec 11, 2018 at 06:30:26PM +0100, Sebastian Gniazdowski wrote:
> Hello,
> I've attached a screenshot for running `git help -a' that ends in a
> hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
> attached):
>
> https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.gitconfig
>
> So it's hangs on the alias `remote-origin-https-to-ssh'. One user in
> following thread discovered, that it's about lenght of the alias:
> "abcdefghijklmnopqr = ... is ok, but with abcdefghijklmnopqrs = ..."
> it will crash, "the problem occurs if the name of a git alias consists
> of more than 18 characters" (see the thread:
> https://github.com/zdharma/fast-syntax-highlighting/issues/95).
>
> Is there a workaround? Of course a fix is needed, but I'm interested
> specifically in a workaround so my Zsh plugin
> `fast-syntax-highlighting' can work without hang also with Git 2.20,
> without exceptions in code.
Have a look at these patches:
https://public-inbox.org/git/pull.97.git.gitgitgadget@gmail.com/T/
It sounds like you hit the same issue.
^ permalink raw reply
* Re: [BUG] Git 2.20: `git help -a' hangs if specific git alias occurs
From: Duy Nguyen @ 2018-12-11 17:46 UTC (permalink / raw)
To: sgniazdowski; +Cc: Git Mailing List
In-Reply-To: <CAKc7PVAzSOknfmy7p09zF4LOi4t66CBmd27ZuQ39_wKYWSiiUA@mail.gmail.com>
On Tue, Dec 11, 2018 at 6:42 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> Hello,
> I've attached a screenshot for running `git help -a' that ends in a
> hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
> attached):
>
> https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.gitconfig
>
> So it's hangs on the alias `remote-origin-https-to-ssh'. One user in
> following thread discovered, that it's about lenght of the alias:
> "abcdefghijklmnopqr = ... is ok, but with abcdefghijklmnopqrs = ..."
> it will crash, "the problem occurs if the name of a git alias consists
> of more than 18 characters" (see the thread:
> https://github.com/zdharma/fast-syntax-highlighting/issues/95).
>
> Is there a workaround? Of course a fix is needed, but I'm interested
> specifically in a workaround so my Zsh plugin
> `fast-syntax-highlighting' can work without hang also with Git 2.20,
> without exceptions in code.
I don't think there's a workaround (except shortening the aliases).
The fix for this was sent out just a couple hours ago, maybe it'll hit
2.20.1
https://public-inbox.org/git/pull.97.git.gitgitgadget@gmail.com/T/#t
> --
> Sebastian Gniazdowski
> News: https://twitter.com/ZdharmaI
> IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
> Blog: http://zdharma.org
--
Duy
^ permalink raw reply
* Re: [PATCH 0/3] rebase: offer to reschedule failed exec commands automatically
From: Stefan Beller @ 2018-12-11 17:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitgitgadget, git, Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1812111119560.43@tvgsbejvaqbjf.bet>
> It is amazing to me how much my perspective changed when I actually had to
> teach Git to new users. Things that I live with easily all of a sudden
> become these unnecessarily confusing road blocks that make it *so hard* to
> actually use Git.
I see. Without the -y patch, this series looks good to me.
> My workflow with `git rebase -r --exec "make test"` is pretty similar to
> yours. With the difference that I would want those commands to be
> rescheduled *even if* the command is flakey. Actually, *in particular*
> when it is flakey.
>
> I really see myself calling
>
> git config --global rebase.rescheduleFailedExec true
Me, too.
Thanks,
Stefan
^ permalink raw reply
* [BUG] Git 2.20: `git help -a' hangs if specific git alias occurs
From: Sebastian Gniazdowski @ 2018-12-11 17:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
Hello,
I've attached a screenshot for running `git help -a' that ends in a
hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
attached):
https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.gitconfig
So it's hangs on the alias `remote-origin-https-to-ssh'. One user in
following thread discovered, that it's about lenght of the alias:
"abcdefghijklmnopqr = ... is ok, but with abcdefghijklmnopqrs = ..."
it will crash, "the problem occurs if the name of a git alias consists
of more than 18 characters" (see the thread:
https://github.com/zdharma/fast-syntax-highlighting/issues/95).
Is there a workaround? Of course a fix is needed, but I'm interested
specifically in a workaround so my Zsh plugin
`fast-syntax-highlighting' can work without hang also with Git 2.20,
without exceptions in code.
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
[-- Attachment #2: gitconfig-crash-95.txt --]
[-- Type: text/plain, Size: 6869 bytes --]
[include]
path = ~/.gitconfig.user
#[user]
#useconfigOnly = true # enforces to configure Git user on a per-repository basis
[credential]
helper = cache --timeout=3600
[core]
trustctime = false
preComposeUnicode = false
autocrlf = input
eol = lf
untrackedCache = true # speed up commands involving untracked files
#attributesFile = ~/.gitattributes
#excludesfile = ~/.gitignore
#filemode = false
#editor = vim
[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "status"]
added = green
changed = yellow
deleted = red
untracked = cyan
header = normal italic
localBranch = cyan bold
remoteBranch = magenta bold
[color "diff"]
meta = yellow bold
frag = cyan
new = green # additions
old = red # deletions
newMoved = green dim
oldMoved = red dim
whitespace = red reverse
commit = yellow bold
[color "diff-highlight"]
oldNormal = red bold
oldHighlight = black red
newNormal = green bold
newHighlight = black green
[color "grep"]
linenumber = yellow bold
match = red bold
filename = magenta
[advice]
statusHints = false
[status]
showStash = true
[grep]
extendRegexp = true
lineNumber = true
[commit]
template = ~/.gitmessage
[stash]
showPatch = true
[apply]
whitespace = fix # Detect whitespace errors when applying a patch
[push]
default = simple
[pull]
ff = only
[rebase]
autoStash = true
[diff]
renames = copies
colorMoved = zebra
tool = meld
#tool = idea # slow
#whitespace = reverse
#context = 0
[difftool]
prompt = false
[difftool "meld"]
cmd = meld \"$LOCAL\" \"$REMOTE\" -L \"LOCAL | REMOTE\" 2>/dev/null
trustExitCode = true
[difftool "idea"]
cmd = idea diff \"$LOCAL\" \"$REMOTE\"
[diff-so-fancy]
useUnicodeRuler = false
[merge]
conflictstyle = diff3
tool = meld
#tool = idea
[mergetool]
prompt = false
#keepBackup = false # do not keep the .orig backup files
[mergetool "meld"]
cmd = meld \"$LOCAL\" \"$MERGED\" \"$REMOTE\" -o \"$MERGED\" -L \"LOCAL | MERGED | REMOTE\" 2>/dev/null
#cmd = meld \"$LOCAL\" \"$BASE\" \"$REMOTE\" -o \"$MERGED\" -L \"LOCAL | BASE | REMOTE\" 2>/dev/null
trustExitCode = true
[mergetool "idea"]
cmd = idea merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
trustExitCode = true
[interactive]
singleKey = true # in interactive mode, accept one-letter inputs (no need to hit enter)
[submodule]
fetchJobs = 0 # 0: auto, 1: default
[tag]
sort = version:refname # sort tags by version number (1.2.0 before 1.10.2)
[alias]
aliases = config --get-regexp "^alias\\."
alias = "!git config --get-regexp \"^alias\\.$1$\" #"
addu = add -u
addp = add -p
addi = add -i
addn = add -n
addN = add -N
st = status -sb
co = checkout
cob = checkout -b
cof = checkout -f
stashk = stash save --keep-index
stashl = stash list
stashps = stash push
ps = push
psf = push --force-with-lease
psuom = push -u origin master
pullf = pull --allow-unrelated-histories
br = branch
brd = branch -d
brD = branch -D
brm = branch -m
branches = branch -vv
remotes = remote -v
tags = tag -l
untracked = ls-files --exclude-standard --others --directory --no-empty-directory
ignored = ls-files --exclude-standard --others --ignored --directory
modified = ls-files --exclude-standard --modified
deleted = ls-files --exclude-standard --deleted
ci = commit -v
cia = commit -v -a
cim = commit -m
ciam = commit -v -a -m
cinit = commit -m 'Initial commit' --allow-empty
amend = commit --amend --no-edit
amenda = commit --amend --no-edit -a
amende = commit --amend
# View abbreviated SHA, description, and history graph of the latest 20 commits
lg = log --graph --pretty=format:'%C(red)%h%C(reset) %C(bold)%s%C(reset) %C(green)(%cr)%C(reset) %C(blue)%an%C(reset)%C(yellow)%d%C(reset)'
lga = !git lg --all
lgp = log -p --ignore-all-space --date=relative
lgpf = !git lgp --follow
standup = "!git log --stat --no-merges --since=$(($(date +%u)==1?3:1)).days.ago.midnight --date=format:'%Y-%m-%d %H:%M:%S' --pretty=format:'%C(red)%h%C(reset) %C(bold)%s%C(reset) %C(green)%cd%C(reset)'"
# Show what I did today
today = "!git log --reverse --no-merges --branches=* --date=local --after=\"yesterday 23:59\" --author=\"`git config --get user.name`\""
showw = show --color-words
showc = show --color-words=.
showst = show --stat
# word diff
diffw = diff --color-words #-U0 -b -w --ignore-space-at-eol --ignore-blank-lines
# character diff
diffc = diff --color-words=.
diffs = diff --staged
diffsw = diff --staged --color-words
diffsc = diff --staged --color-words=.
diffst = diff --stat
dt = difftool
mt = mergetool
rao = remote add origin
unstage = reset
rh = reset --hard
rs = reset --soft
rs1 = reset --soft @^
rb = rebase
rbi = rebase -i
rba = rebase --abort
rbc = rebase --continue
ls = ls-files
ag = "grep --break --heading --line-number"
# Search files registered in the index, rather than the working tree
ag-index = "grep --break --heading --line-number --cached -e"
# Local Git Server
# Appending "#" to an alias allow positional parameters without leaving the trailing ones
# Origin: git serve REPO
# Destination: git pull git://IP_OR_HOSTNAME_OF_ORIGIN/
server = "!git daemon --verbose --reuseaddr --export-all --enable=receive-pack --base-path=\"$1\" #"
remote-origin-https-to-ssh = "!git remote set-url origin $(git remote get-url origin | sed 's|.*://|git@|; s|/|:|')"
assume-unchanged = update-index --assume-unchanged
assume-changed = update-index --no-assume-unchanged
[url "git@github.com:"]
#insteadOf = "https://github.com/" # force SSH instead of HTTP
insteadOf = "github:" # shortcut
pushInsteadOf = "git://github.com/"
pushInsteadOf = "https://github.com/"
[url "git@gitlab.com:"]
#insteadOf = "https://gitlab.com/" # force SSH instead of HTTP
insteadOf = "gitlab:" # shortcut
pushInsteadOf = "git://gitlab.com/"
pushInsteadOf = "https://gitlab.com/"
[url "git@bitbucket.org:"]
#insteadOf = "https://bitbucket.org/" # force SSH instead of HTTP
insteadOf = "bitbucket:" # shortcut
pushInsteadOf = "git://bitbucket.org/"
pushInsteadOf = "https://bitbucket.org/"
[url "git@heroku.com:"]
insteadOf = "heroku:" # shortcut
# Prettier inline JSON diff
[diff "json"]
textconv = "perl -MJSON::PP -e '$j = JSON::PP->new->pretty->canonical; print $j->encode($j->decode(do {$/ = undef; <>}))'"
cachetextconv = true
[filter "transmission-conf"]
clean = "grep -Ev '\"(alt-speed-enabled|blocklist-date|main-window-[-a-z]+|open-dialog-dir|rpc-password)\":'"
smudge = cat
#[diff "bin"]
# textconv = hexdump -v -C
# Merge drivers
# .gitattributes example: file merge=ours
[merge "theirs"]
driver = cp -f %B %A
[merge "ours"]
driver = true
[-- Attachment #3: git-help--a-crash-95.png --]
[-- Type: image/png, Size: 20853 bytes --]
^ permalink raw reply
* Re: Announcing Pro Git Second Edition Reedited
From: Jon Forrest @ 2018-12-11 17:24 UTC (permalink / raw)
To: Konstantin Khomoutov
Cc: Ævar Arnfjörð Bjarmason, Jeff King,
Git Mailing List
In-Reply-To: <20181211171553.4mnd66ngqvcxb6me@tigra>
On 12/11/2018 9:15 AM, Konstantin Khomoutov wrote:
> I think an uspoken issue here is that while you're indeed free to "fork"
> this book and maintain your fork, having two books with almost identical
> contents may not be the best option as it simply may be outright
> confusing for those at whom your fork is actually targeted.
The coverage is almost identical, but the content is different.
> That's just my opinion, or — better — feeling I gathered from the
> discussion, but to me these friendly nudges to maybe consider
> reevaluating your work for inclusion into the original's book proper
> look exactly as hints at that having such a fork may not be the best
> of all options.
You might be right, but the reception I got when working on the
first edition led me to make the fork. In retrospect, I probably
should have tried again with the new crew who did the second
edition. As I said, I will try again if there's a third edition.
> Another problem with the fork is its visibility.
> The go-to Git website links to the original work, and I assure you
> novice users do not casually read this list — let alone search through
> its archives for the mentions of an alternative book's version.
I agree, and I don't know what to do about that.
Jon
^ permalink raw reply
* Re: Announcing Pro Git Second Edition Reedited
From: Konstantin Khomoutov @ 2018-12-11 17:15 UTC (permalink / raw)
To: Jon Forrest
Cc: Ævar Arnfjörð Bjarmason, Jeff King,
Git Mailing List
In-Reply-To: <55838db9-4f08-b77e-bc95-5c7dce4024d2@gmail.com>
On Tue, Dec 11, 2018 at 09:00:31AM -0800, Jon Forrest wrote:
> > As someone who's read neither your edit or the original edition, but I
> > did read your version of the intro, it would be very helpful to me /
> > others if there was some diff between the two so we could make up our
> > own mind about which one to read, and to get an idea of what sorts of
> > wording changes etc. these are.
>
> That would indeed be nice. The best I can do is to suggest that if
> you're satisfied with the regular Pro Git then my version won't
> help you. On the other hand, if you find regular Pro Git puzzling,
> especially in the early chapters, I suggest giving my version a try.
>
> Since I'm giving away my version, you have nothing to loose except
> perhaps a little time. If I'm right, and my version is clearer, then
> you could benefit from it.
>
> (You're a git expert so I doubt you need my version).
I think an uspoken issue here is that while you're indeed free to "fork"
this book and maintain your fork, having two books with almost identical
contents may not be the best option as it simply may be outright
confusing for those at whom your fork is actually targeted.
That's just my opinion, or — better — feeling I gathered from the
discussion, but to me these friendly nudges to maybe consider
reevaluating your work for inclusion into the original's book proper
look exactly as hints at that having such a fork may not be the best
of all options.
Another problem with the fork is its visibility.
The go-to Git website links to the original work, and I assure you
novice users do not casually read this list — let alone search through
its archives for the mentions of an alternative book's version.
^ permalink raw reply
* Re: Announcing Pro Git Second Edition Reedited
From: Jon Forrest @ 2018-12-11 17:00 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jeff King, Git Mailing List
In-Reply-To: <CACBZZX6g7TaxNHN=3ApV4wV91ZuVV8eoemMurS=WMt4mG8Q67g@mail.gmail.com>
On 12/11/2018 7:13 AM, Ævar Arnfjörð Bjarmason wrote:
> As someone who's read neither your edit or the original edition, but I
> did read your version of the intro, it would be very helpful to me /
> others if there was some diff between the two so we could make up our
> own mind about which one to read, and to get an idea of what sorts of
> wording changes etc. these are.
That would indeed be nice. The best I can do is to suggest that if
you're satisfied with the regular Pro Git then my version won't
help you. On the other hand, if you find regular Pro Git puzzling,
especially in the early chapters, I suggest giving my version a try.
Since I'm giving away my version, you have nothing to loose except
perhaps a little time. If I'm right, and my version is clearer, then
you could benefit from it.
(You're a git expert so I doubt you need my version).
Cordially,
Jon Forrest
^ permalink raw reply
* [RFC] A global mailmap service
From: Lukas Fleischer @ 2018-12-11 16:37 UTC (permalink / raw)
To: git
I came up with the idea of creating a global mailmap service earlier
this year and, given a recent discussion on maintaining .mailmap, I
decided to bring it up here. While only marginally related to Git
development, I hope that it is relevant enough to not be considered
spam.
The basic idea of the service I imagine is simple:
1. You register a primary email address and specify a password. You
receive a verification email to confirm that the address is yours.
2. At any time, you can add additional email addresses and link them to
your primary email address, using your previously specified password.
You can also update your primary email address. Any new addresses
obtain verification emails such that you cannot steal somebody else's
identity.
3. Anybody can use a public lookup interface to obtain the current
primary email address corresponding to any registered email address
they enter.
According to the principle of data economy, the full list of email
addresses is kept private. An email address is only returned if the user
performing a lookup already owns a (possibly outdated) email address of
the same user.
A batch query to the service can be used to automatically generate a
.mailmap file without having to maintain it on a per-project basis and
without having to be careful and confirm every entry manually.
I created a PoC here [1]. You can run
git log --pretty='%ae' | sort -u | curl -Ftopic=git -Femails='<-' https://mailmap.org/
from the Git source tree to auto-generate a .mailmap file. Of course,
this idea only works if people agree that it is useful and the majority
of developers register their email addresses to the service.
I am aware that some users use different email addresses for different
projects. The current approach is allowing the user to add primary
"topic email addresses". A request can optionally specify a topic (such
as "git" in the request above) and the lookup may potentially return an
email address different from the generic primary address. Of course,
these topics need to be standardized in some way. There might be better,
more sophisticated ways to tackle this and I'd be happy to discuss them
if there is interest in the general approach.
I am also aware that this may not cover all potential uses of .mailmap
files but, according to my understanding and experience, it should cover
a fairly large amount. The remaining adjustments can still be made on
top on a per-project basis.
Best regards,
Lukas
[1] https://mailmap.org/
^ permalink raw reply
* Re: Difficulty with parsing colorized diff output
From: George King @ 2018-12-11 16:41 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jeff King, Stefan Beller, git
In-Reply-To: <871s6oni3a.fsf@evledraar.gmail.com>
I first started playing around with terminal colors about 5 years ago, and I recall learning the hard way that Apple Terminal at least behaves very strangely when you have background colors cross line boundaries: background colors disappeared when I scrolled lines back into view. I filed a bug thinking it couldn't be right and Apple closed it as behaving according to compatibility expectations. I never figured out whether they had misunderstood my report or if old terminals were just that crazy. Instead I decided that the safe thing to do was reset after every line. Perhaps some git author reached the same conclusion.
From the perspective of parsing this output, it is really much easier if each line can be understood without considering state of previous lines. If anything, I think it is a safe approach to ensuring that it renders correctly on various terminals as well.
> On 2018-12-11, at 11:28 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Tue, Dec 11 2018, Jeff King wrote:
>
>> On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
>>
>>>> Context lines do have both. It's just that the default color for context
>>>> lines is empty. ;)
>>>
>>> The content itself can contain color codes.
>>>
>>> Instead of unconditionally resetting each line, we could parse each
>>> content line to determine if we actually have to reset the colors.
>>
>> Good point. I don't recall that being the motivation back when this
>> behavior started, but it's a nice side effect (and the more recent line
>> you mentioned in emit_line_0 certainly is doing it intentionally).
>>
>> That doesn't cover _other_ terminal codes, which could also make for
>> confusing output, but I do think color codes are somewhat special. We
>> generally send patches through "less -R", which will pass through the
>> colors but show escaped versions of other codes.
>
> I wonder if optimizing this one way or the other matters for some
> terminals. I.e. if we print out some huge diff of thousands of
> consecutive "green" added lines is it faster/slower on some of them to
> do one "begin green" and "reset" at the end, or is one line at a time
> better, or doesn't it matter at all?
^ permalink raw reply
* Re: Difficulty with parsing colorized diff output
From: Ævar Arnfjörð Bjarmason @ 2018-12-11 16:28 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Beller, george.w.king, git
In-Reply-To: <20181211101742.GE31588@sigill.intra.peff.net>
On Tue, Dec 11 2018, Jeff King wrote:
> On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
>
>> > Context lines do have both. It's just that the default color for context
>> > lines is empty. ;)
>>
>> The content itself can contain color codes.
>>
>> Instead of unconditionally resetting each line, we could parse each
>> content line to determine if we actually have to reset the colors.
>
> Good point. I don't recall that being the motivation back when this
> behavior started, but it's a nice side effect (and the more recent line
> you mentioned in emit_line_0 certainly is doing it intentionally).
>
> That doesn't cover _other_ terminal codes, which could also make for
> confusing output, but I do think color codes are somewhat special. We
> generally send patches through "less -R", which will pass through the
> colors but show escaped versions of other codes.
I wonder if optimizing this one way or the other matters for some
terminals. I.e. if we print out some huge diff of thousands of
consecutive "green" added lines is it faster/slower on some of them to
do one "begin green" and "reset" at the end, or is one line at a time
better, or doesn't it matter at all?
^ permalink raw reply
* Re: [PATCH 1/3] rebase: introduce --reschedule-failed-exec
From: Elijah Newren @ 2018-12-11 16:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Schindelin via GitGitGadget, Git Mailing List,
Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1812111104561.43@tvgsbejvaqbjf.bet>
Hi Dscho,
On Tue, Dec 11, 2018 at 2:14 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Elijah,
>
> On Mon, 10 Dec 2018, Elijah Newren wrote:
>
> > On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> > >
> > > @@ -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"));
> > > +
> >
> > I was surprised at first that you checked is_interactive() rather than
> > checking for --exec being specified. But I guess this is because users
> > can manually specify 'exec' lines.
>
> Indeed, that is exactly the reason.
>
> > What if the user specifies an implicitly interactive rebase (i.e. no
> > editing of the todo list, such as with --rebase-merges or
> > --keep-empty, or soon --strategy or --strategy-option) and also
> > doesn't specify --exec?
>
> Then the todo list won't have any `exec` lines, and the flag is irrelevant
> (but does not do any harm).
>
> ... except in the case that the rebase fails at some stage, the user edits
> the todo list with `git rebase --edit-todo` and inserts an `exec` line.
Ah, good point; hadn't thought of that case. Thanks for explaining.
^ permalink raw reply
* [PATCH v4 3/8] t5407: add a test demonstrating how interactive handles --skip differently
From: Elijah Newren @ 2018-12-11 16:11 UTC (permalink / raw)
To: git
Cc: gitster, Johannes.Schindelin, predatoramigo, phillip.wood,
Elijah Newren
In-Reply-To: <20181211161139.31686-1-newren@gmail.com>
The post-rewrite hook is documented as being invoked by commands that
rewrite commits such as commit --amend and rebase, and that it will
be called for each rewritten commit.
Apparently, the three backends handled --skip'ed commits differently:
am: treat the skipped commit as though it weren't rewritten
merge: same as 'am' backend
interactive: treat skipped commits as having been rewritten to empty
(view them as an empty fixup to their parent)
For now, just add a testcase documenting the different behavior (use
--keep to force usage of the interactive machinery even though we have
no empty commits). A subsequent commit will remove the inconsistency in
--skip handling.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t5407-post-rewrite-hook.sh | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh
index 9b2a274c71..6426ec8991 100755
--- a/t/t5407-post-rewrite-hook.sh
+++ b/t/t5407-post-rewrite-hook.sh
@@ -125,6 +125,37 @@ test_expect_success 'git rebase -m --skip' '
verify_hook_input
'
+test_expect_success 'git rebase with implicit use of interactive backend' '
+ git reset --hard D &&
+ clear_hook_input &&
+ test_must_fail git rebase --keep --onto A B &&
+ echo C > foo &&
+ git add foo &&
+ git rebase --continue &&
+ echo rebase >expected.args &&
+ cat >expected.data <<-EOF &&
+ $(git rev-parse C) $(git rev-parse HEAD^)
+ $(git rev-parse D) $(git rev-parse HEAD)
+ EOF
+ verify_hook_input
+'
+
+test_expect_success 'git rebase --skip with implicit use of interactive backend' '
+ git reset --hard D &&
+ clear_hook_input &&
+ test_must_fail git rebase --keep --onto A B &&
+ test_must_fail git rebase --skip &&
+ echo D > foo &&
+ git add foo &&
+ git rebase --continue &&
+ echo rebase >expected.args &&
+ cat >expected.data <<-EOF &&
+ $(git rev-parse C) $(git rev-parse HEAD^)
+ $(git rev-parse D) $(git rev-parse HEAD)
+ EOF
+ verify_hook_input
+'
+
. "$TEST_DIRECTORY"/lib-rebase.sh
set_fake_editor
--
2.20.0.8.g5de428d695
^ permalink raw reply related
* [PATCH v4 7/8] rebase: define linearization ordering and enforce it
From: Elijah Newren @ 2018-12-11 16:11 UTC (permalink / raw)
To: git
Cc: gitster, Johannes.Schindelin, predatoramigo, phillip.wood,
Elijah Newren
In-Reply-To: <20181211161139.31686-1-newren@gmail.com>
Ever since commit 3f213981e44a ("add tests for rebasing merged history",
2013-06-06), t3425 has had tests which included the rebasing of merged
history and whose order of applied commits was checked. Unfortunately,
the tests expected different behavior depending on which backend was in
use. Implementing these checks was the following four lines (including
the TODO message) which were repeated verbatim three times in t3425:
#TODO: make order consistent across all flavors of rebase
test_run_rebase success 'e n o' ''
test_run_rebase success 'e n o' -m
test_run_rebase success 'n o e' -i
As part of the effort to reduce differences between the rebase backends
so that users get more uniform behavior, let's define the correct
behavior and modify the different backends so they all get the right
answer. It turns out that the difference in behavior here is entirely
due to topological sorting; since some backends require topological
sorting (particularly when --rebase-merges is specified), require it for
all modes. Modify the am and merge backends to implement this.
Performance Considerations:
I was unable to measure any appreciable performance difference with this
change. Trying to control the run-to-run variation was difficult; I
eventually found a headless beefy box that I could ssh into, which
seemed to help. Using git.git, I ran the following testcase:
$ git reset --hard v2.20.0-rc1~2
$ time git rebase --quiet v2.20.0-rc0~16
I first ran once to warm any disk caches, then ran five subsequent runs
and recorded the times of those five. I observed the following results
for the average time:
Before this change:
"real" timing: 1.340s (standard deviation: 0.040s)
"user" timing: 1.050s (standard deviation: 0.041s)
"sys" timing: 0.270s (standard deviation: 0.011s)
After this change:
"real" timing: 1.327s (standard deviation: 0.065s)
"user" timing: 1.031s (standard deviation: 0.061s)
"sys" timing: 0.280s (standard deviation: 0.014s)
Measurements aside, I would expect the timing for walking revisions to
be dwarfed by the work involved in creating and applying patches, so
this isn't too surprising. Further, while somewhat counter-intuitive,
it is possible that turning on topological sorting is actually a
performance improvement: by way of comparison, turning on --topo-order
made fast-export faster (see
https://public-inbox.org/git/20090211135640.GA19600@coredump.intra.peff.net/).
Signed-off-by: Elijah Newren <newren@gmail.com>
---
git-rebase--am.sh | 2 +-
git-rebase--merge.sh | 2 +-
t/t3425-rebase-topology-merges.sh | 15 ++++++---------
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 99b8c17787..6416716ee6 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -36,7 +36,7 @@ rm -f "$GIT_DIR/rebased-patches"
git format-patch -k --stdout --full-index --cherry-pick --right-only \
--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \
- --pretty=mboxrd \
+ --pretty=mboxrd --topo-order \
$git_format_patch_opt \
"$revisions" ${restrict_revision+^$restrict_revision} \
>"$GIT_DIR/rebased-patches"
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index 91250cbaed..ced38bb3a6 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -143,7 +143,7 @@ write_basic_state
rm -f "$(git rev-parse --git-path REBASE_HEAD)"
msgnum=0
-for cmt in $(git rev-list --reverse --no-merges "$revisions")
+for cmt in $(git rev-list --topo-order --reverse --no-merges "$revisions")
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$state_dir/cmt.$msgnum"
diff --git a/t/t3425-rebase-topology-merges.sh b/t/t3425-rebase-topology-merges.sh
index 5f892e33d7..fd8efe84fe 100755
--- a/t/t3425-rebase-topology-merges.sh
+++ b/t/t3425-rebase-topology-merges.sh
@@ -70,9 +70,8 @@ test_run_rebase () {
test_linear_range "\'"$expected"\'" d..
"
}
-#TODO: make order consistent across all flavors of rebase
-test_run_rebase success 'e n o' ''
-test_run_rebase success 'e n o' -m
+test_run_rebase success 'n o e' ''
+test_run_rebase success 'n o e' -m
test_run_rebase success 'n o e' -i
test_run_rebase () {
@@ -87,9 +86,8 @@ test_run_rebase () {
test_linear_range "\'"$expected"\'" c..
"
}
-#TODO: make order consistent across all flavors of rebase
-test_run_rebase success 'd e n o' ''
-test_run_rebase success 'd e n o' -m
+test_run_rebase success 'd n o e' ''
+test_run_rebase success 'd n o e' -m
test_run_rebase success 'd n o e' -i
test_run_rebase () {
@@ -104,9 +102,8 @@ test_run_rebase () {
test_linear_range "\'"$expected"\'" c..
"
}
-#TODO: make order consistent across all flavors of rebase
-test_run_rebase success 'd e n o' ''
-test_run_rebase success 'd e n o' -m
+test_run_rebase success 'd n o e' ''
+test_run_rebase success 'd n o e' -m
test_run_rebase success 'd n o e' -i
if ! test_have_prereq REBASE_P; then
--
2.20.0.8.g5de428d695
^ permalink raw reply related
* [PATCH v4 5/8] git-rebase, sequencer: extend --quiet option for the interactive machinery
From: Elijah Newren @ 2018-12-11 16:11 UTC (permalink / raw)
To: git
Cc: gitster, Johannes.Schindelin, predatoramigo, phillip.wood,
Elijah Newren
In-Reply-To: <20181211161139.31686-1-newren@gmail.com>
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just traditionally been quieter. As such, we only drop a few
informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
Also, for simplicity, remove the differences in how quiet and verbose
options were recorded. Having one be signalled by the presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
builtin/rebase.c | 5 +----
git-legacy-rebase.sh | 2 +-
git-rebase--common.sh | 2 +-
sequencer.c | 23 +++++++++++++----------
sequencer.h | 1 +
5 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 78e982298f..ec2e5fbf23 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -185,10 +185,7 @@ static int read_basic_state(struct rebase_options *opts)
if (get_oid(buf.buf, &opts->orig_head))
return error(_("invalid orig-head: '%s'"), buf.buf);
- strbuf_reset(&buf);
- if (read_one(state_dir_path("quiet", opts), &buf))
- return -1;
- if (buf.len)
+ if (file_exists(state_dir_path("quiet", opts)))
opts->flags &= ~REBASE_NO_QUIET;
else
opts->flags |= REBASE_NO_QUIET;
diff --git a/git-legacy-rebase.sh b/git-legacy-rebase.sh
index fccb33b959..f4088b7bda 100755
--- a/git-legacy-rebase.sh
+++ b/git-legacy-rebase.sh
@@ -113,7 +113,7 @@ read_basic_state () {
else
orig_head=$(cat "$state_dir"/head)
fi &&
- GIT_QUIET=$(cat "$state_dir"/quiet) &&
+ test -f "$state_dir"/quiet && GIT_QUIET=t
test -f "$state_dir"/verbose && verbose=t
test -f "$state_dir"/strategy && strategy="$(cat "$state_dir"/strategy)"
test -f "$state_dir"/strategy_opts &&
diff --git a/git-rebase--common.sh b/git-rebase--common.sh
index 7e39d22871..dc18c682fa 100644
--- a/git-rebase--common.sh
+++ b/git-rebase--common.sh
@@ -10,7 +10,7 @@ write_basic_state () {
echo "$head_name" > "$state_dir"/head-name &&
echo "$onto" > "$state_dir"/onto &&
echo "$orig_head" > "$state_dir"/orig-head &&
- echo "$GIT_QUIET" > "$state_dir"/quiet &&
+ test t = "$GIT_QUIET" && : > "$state_dir"/quiet
test t = "$verbose" && : > "$state_dir"/verbose
test -n "$strategy" && echo "$strategy" > "$state_dir"/strategy
test -n "$strategy_opts" && echo "$strategy_opts" > \
diff --git a/sequencer.c b/sequencer.c
index e1a4dd15f1..bc25615050 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -150,6 +150,7 @@ static GIT_PATH_FUNC(rebase_path_refs_to_delete, "rebase-merge/refs-to-delete")
static GIT_PATH_FUNC(rebase_path_gpg_sign_opt, "rebase-merge/gpg_sign_opt")
static GIT_PATH_FUNC(rebase_path_orig_head, "rebase-merge/orig-head")
static GIT_PATH_FUNC(rebase_path_verbose, "rebase-merge/verbose")
+static GIT_PATH_FUNC(rebase_path_quiet, "rebase-merge/quiet")
static GIT_PATH_FUNC(rebase_path_signoff, "rebase-merge/signoff")
static GIT_PATH_FUNC(rebase_path_head_name, "rebase-merge/head-name")
static GIT_PATH_FUNC(rebase_path_onto, "rebase-merge/onto")
@@ -157,7 +158,6 @@ static GIT_PATH_FUNC(rebase_path_autostash, "rebase-merge/autostash")
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 int git_sequencer_config(const char *k, const char *v, void *cb)
{
@@ -2357,6 +2357,9 @@ static int read_populate_opts(struct replay_opts *opts)
if (file_exists(rebase_path_verbose()))
opts->verbose = 1;
+ if (file_exists(rebase_path_quiet()))
+ opts->quiet = 1;
+
if (file_exists(rebase_path_signoff())) {
opts->allow_ff = 0;
opts->signoff = 1;
@@ -2424,9 +2427,6 @@ int write_basic_state(struct replay_opts *opts, const char *head_name,
if (quiet)
write_file(rebase_path_quiet(), "%s\n", quiet);
- else
- write_file(rebase_path_quiet(), "\n");
-
if (opts->verbose)
write_file(rebase_path_verbose(), "%s", "");
if (opts->strategy)
@@ -3503,10 +3503,11 @@ static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
fprintf(f, "%d\n", todo_list->done_nr);
fclose(f);
}
- fprintf(stderr, "Rebasing (%d/%d)%s",
- todo_list->done_nr,
- todo_list->total_nr,
- opts->verbose ? "\n" : "\r");
+ if (!opts->quiet)
+ fprintf(stderr, "Rebasing (%d/%d)%s",
+ todo_list->done_nr,
+ todo_list->total_nr,
+ opts->verbose ? "\n" : "\r");
}
unlink(rebase_path_message());
unlink(rebase_path_author_script());
@@ -3738,8 +3739,10 @@ static int pick_commits(struct todo_list *todo_list, struct replay_opts *opts)
}
apply_autostash(opts);
- fprintf(stderr, "Successfully rebased and updated %s.\n",
- head_ref.buf);
+ if (!opts->quiet)
+ fprintf(stderr,
+ "Successfully rebased and updated %s.\n",
+ head_ref.buf);
strbuf_release(&buf);
strbuf_release(&head_ref);
diff --git a/sequencer.h b/sequencer.h
index 5071a73563..729222b583 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 quiet;
int mainline;
--
2.20.0.8.g5de428d695
^ permalink raw reply related
* [PATCH v4 8/8] rebase: Implement --merge via the interactive machinery
From: Elijah Newren @ 2018-12-11 16:11 UTC (permalink / raw)
To: git
Cc: gitster, Johannes.Schindelin, predatoramigo, phillip.wood,
Elijah Newren
In-Reply-To: <20181211161139.31686-1-newren@gmail.com>
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
.gitignore | 1 -
Documentation/git-rebase.txt | 17 +--
Makefile | 1 -
builtin/rebase.c | 15 ++-
git-legacy-rebase.sh | 43 ++++----
git-rebase--merge.sh | 166 ------------------------------
t/t3406-rebase-message.sh | 7 +-
t/t3420-rebase-autostash.sh | 78 ++------------
t/t3421-rebase-topology-linear.sh | 10 +-
t/t9903-bash-prompt.sh | 2 +-
10 files changed, 43 insertions(+), 297 deletions(-)
delete mode 100644 git-rebase--merge.sh
diff --git a/.gitignore b/.gitignore
index 0d77ea5894..910b1d2d2f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -124,7 +124,6 @@
/git-rebase--am
/git-rebase--common
/git-rebase--interactive
-/git-rebase--merge
/git-rebase--preserve-merges
/git-receive-pack
/git-reflog
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index dff17b3178..8bfa36a185 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -504,15 +504,7 @@ See also INCOMPATIBLE OPTIONS below.
INCOMPATIBLE OPTIONS
--------------------
-git-rebase has many flags that are incompatible with each other,
-predominantly due to the fact that it has three different underlying
-implementations:
-
- * one based on linkgit:git-am[1] (the default)
- * one based on git-merge-recursive (merge backend)
- * one based on linkgit:git-cherry-pick[1] (interactive backend)
-
-Flags only understood by the am backend:
+The following options:
* --committer-date-is-author-date
* --ignore-date
@@ -520,15 +512,12 @@ Flags only understood by the am backend:
* --ignore-whitespace
* -C
-Flags understood by both merge and interactive backends:
+are incompatible with the following options:
* --merge
* --strategy
* --strategy-option
* --allow-empty-message
-
-Flags only understood by the interactive backend:
-
* --[no-]autosquash
* --rebase-merges
* --preserve-merges
@@ -539,7 +528,7 @@ Flags only understood by the interactive backend:
* --edit-todo
* --root when used in combination with --onto
-Other incompatible flag pairs:
+In addition, the following pairs of options are incompatible:
* --preserve-merges and --interactive
* --preserve-merges and --signoff
diff --git a/Makefile b/Makefile
index 1a44c811aa..82e1eb1a4a 100644
--- a/Makefile
+++ b/Makefile
@@ -628,7 +628,6 @@ SCRIPT_LIB += git-parse-remote
SCRIPT_LIB += git-rebase--am
SCRIPT_LIB += git-rebase--common
SCRIPT_LIB += git-rebase--preserve-merges
-SCRIPT_LIB += git-rebase--merge
SCRIPT_LIB += git-sh-setup
SCRIPT_LIB += git-sh-i18n
diff --git a/builtin/rebase.c b/builtin/rebase.c
index ec2e5fbf23..d95843a8d4 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -122,7 +122,7 @@ static void imply_interactive(struct rebase_options *opts, const char *option)
case REBASE_PRESERVE_MERGES:
break;
case REBASE_MERGE:
- /* we silently *upgrade* --merge to --interactive if needed */
+ /* we now implement --merge via --interactive */
default:
opts->type = REBASE_INTERACTIVE; /* implied */
break;
@@ -481,10 +481,6 @@ static int run_specific_rebase(struct rebase_options *opts)
backend = "git-rebase--am";
backend_func = "git_rebase__am";
break;
- case REBASE_MERGE:
- backend = "git-rebase--merge";
- backend_func = "git_rebase__merge";
- break;
case REBASE_PRESERVE_MERGES:
backend = "git-rebase--preserve-merges";
backend_func = "git_rebase__preserve_merges";
@@ -1191,6 +1187,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
}
}
+ if (options.type == REBASE_MERGE)
+ imply_interactive(&options, "--merge");
+
if (options.root && !options.onto_name)
imply_interactive(&options, "--root without --onto");
@@ -1220,10 +1219,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
break;
if (is_interactive(&options) && i >= 0)
- die(_("cannot combine am options "
- "with interactive options"));
- if (options.type == REBASE_MERGE && i >= 0)
- die(_("cannot combine am options with merge options "));
+ die(_("cannot combine am options with either "
+ "interactive or merge options"));
}
if (options.signoff) {
diff --git a/git-legacy-rebase.sh b/git-legacy-rebase.sh
index 6baf10192d..0c9c19bc60 100755
--- a/git-legacy-rebase.sh
+++ b/git-legacy-rebase.sh
@@ -218,6 +218,7 @@ then
state_dir="$apply_dir"
elif test -d "$merge_dir"
then
+ type=interactive
if test -d "$merge_dir"/rewritten
then
type=preserve-merges
@@ -225,10 +226,7 @@ then
preserve_merges=t
elif test -f "$merge_dir"/interactive
then
- type=interactive
interactive_rebase=explicit
- else
- type=merge
fi
state_dir="$merge_dir"
fi
@@ -477,6 +475,7 @@ then
test -z "$interactive_rebase" && interactive_rebase=implied
fi
+actually_interactive=
if test -n "$interactive_rebase"
then
if test -z "$preserve_merges"
@@ -485,11 +484,12 @@ then
else
type=preserve-merges
fi
-
+ actually_interactive=t
state_dir="$merge_dir"
elif test -n "$do_merge"
then
- type=merge
+ interactive_rebase=implied
+ type=interactive
state_dir="$merge_dir"
else
type=am
@@ -505,13 +505,9 @@ incompatible_opts=$(echo " $git_am_opt " | \
sed -e 's/ -q / /g' -e 's/^ \(.*\) $/\1/')
if test -n "$incompatible_opts"
then
- if test -n "$interactive_rebase"
- then
- die "$(gettext "fatal: cannot combine am options with interactive options")"
- fi
- if test -n "$do_merge"
+ if test -n "$actually_interactive" || test "$do_merge"
then
- die "$(gettext "fatal: cannot combine am options with merge options")"
+ die "$(gettext "fatal: cannot combine am options with either interactive or merge options")"
fi
fi
@@ -676,7 +672,7 @@ require_clean_work_tree "rebase" "$(gettext "Please commit or stash them.")"
# but this should be done only when upstream and onto are the same
# and if this is not an interactive rebase.
mb=$(git merge-base "$onto" "$orig_head")
-if test -z "$interactive_rebase" && test "$upstream" = "$onto" &&
+if test -z "$actually_interactive" && test "$upstream" = "$onto" &&
test "$mb" = "$onto" && test -z "$restrict_revision" &&
# linear history?
! (git rev-list --parents "$onto".."$orig_head" | sane_grep " .* ") > /dev/null
@@ -726,6 +722,19 @@ then
GIT_PAGER='' git diff --stat --summary "$mb_tree" "$onto"
fi
+if test -z "$actually_interactive" && test "$mb" = "$orig_head"
+then
+ say "$(eval_gettext "Fast-forwarded \$branch_name to \$onto_name.")"
+ GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $onto_name" \
+ git checkout -q "$onto^0" || die "could not detach HEAD"
+ # If the $onto is a proper descendant of the tip of the branch, then
+ # we just fast-forwarded.
+ git update-ref ORIG_HEAD $orig_head
+ move_to_original_branch
+ finish_rebase
+ exit 0
+fi
+
test -n "$interactive_rebase" && run_specific_rebase
# Detach HEAD and reset the tree
@@ -735,16 +744,6 @@ GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $onto_name" \
git checkout -q "$onto^0" || die "could not detach HEAD"
git update-ref ORIG_HEAD $orig_head
-# If the $onto is a proper descendant of the tip of the branch, then
-# we just fast-forwarded.
-if test "$mb" = "$orig_head"
-then
- say "$(eval_gettext "Fast-forwarded \$branch_name to \$onto_name.")"
- move_to_original_branch
- finish_rebase
- exit 0
-fi
-
if test -n "$rebase_root"
then
revisions="$onto..$orig_head"
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
deleted file mode 100644
index ced38bb3a6..0000000000
--- a/git-rebase--merge.sh
+++ /dev/null
@@ -1,166 +0,0 @@
-# This shell script fragment is sourced by git-rebase to implement
-# its merge-based non-interactive mode that copes well with renamed
-# files.
-#
-# Copyright (c) 2010 Junio C Hamano.
-#
-
-prec=4
-
-read_state () {
- onto_name=$(cat "$state_dir"/onto_name) &&
- end=$(cat "$state_dir"/end) &&
- msgnum=$(cat "$state_dir"/msgnum)
-}
-
-continue_merge () {
- test -d "$state_dir" || die "$state_dir directory does not exist"
-
- unmerged=$(git ls-files -u)
- if test -n "$unmerged"
- then
- echo "You still have unmerged paths in your index"
- echo "did you forget to use git add?"
- die "$resolvemsg"
- fi
-
- cmt=$(cat "$state_dir/current")
- if ! git diff-index --quiet --ignore-submodules HEAD --
- then
- if ! git commit ${gpg_sign_opt:+"$gpg_sign_opt"} $signoff $allow_empty_message \
- --no-verify -C "$cmt"
- then
- echo "Commit failed, please do not call \"git commit\""
- echo "directly, but instead do one of the following: "
- die "$resolvemsg"
- fi
- if test -z "$GIT_QUIET"
- then
- printf "Committed: %0${prec}d " $msgnum
- fi
- echo "$cmt $(git rev-parse HEAD^0)" >> "$state_dir/rewritten"
- else
- if test -z "$GIT_QUIET"
- then
- printf "Already applied: %0${prec}d " $msgnum
- fi
- fi
- test -z "$GIT_QUIET" &&
- GIT_PAGER='' git log --format=%s -1 "$cmt"
-
- # onto the next patch:
- msgnum=$(($msgnum + 1))
- echo "$msgnum" >"$state_dir/msgnum"
-}
-
-call_merge () {
- msgnum="$1"
- echo "$msgnum" >"$state_dir/msgnum"
- cmt="$(cat "$state_dir/cmt.$msgnum")"
- echo "$cmt" > "$state_dir/current"
- git update-ref REBASE_HEAD "$cmt"
- hd=$(git rev-parse --verify HEAD)
- cmt_name=$(git symbolic-ref HEAD 2> /dev/null || echo HEAD)
- eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
- eval GITHEAD_$hd='$onto_name'
- export GITHEAD_$cmt GITHEAD_$hd
- if test -n "$GIT_QUIET"
- then
- GIT_MERGE_VERBOSITY=1 && export GIT_MERGE_VERBOSITY
- fi
- test -z "$strategy" && strategy=recursive
- # If cmt doesn't have a parent, don't include it as a base
- base=$(git rev-parse --verify --quiet $cmt^)
- eval 'git merge-$strategy' $strategy_opts $base ' -- "$hd" "$cmt"'
- rv=$?
- case "$rv" in
- 0)
- unset GITHEAD_$cmt GITHEAD_$hd
- return
- ;;
- 1)
- git rerere $allow_rerere_autoupdate
- die "$resolvemsg"
- ;;
- 2)
- echo "Strategy: $strategy failed, try another" 1>&2
- die "$resolvemsg"
- ;;
- *)
- die "Unknown exit code ($rv) from command:" \
- "git merge-$strategy $cmt^ -- HEAD $cmt"
- ;;
- esac
-}
-
-finish_rb_merge () {
- move_to_original_branch
- if test -s "$state_dir"/rewritten
- then
- git notes copy --for-rewrite=rebase <"$state_dir"/rewritten
- hook="$(git rev-parse --git-path hooks/post-rewrite)"
- test -x "$hook" && "$hook" rebase <"$state_dir"/rewritten
- fi
- say All done.
-}
-
-git_rebase__merge () {
-
-case "$action" in
-continue)
- read_state
- continue_merge
- while test "$msgnum" -le "$end"
- do
- call_merge "$msgnum"
- continue_merge
- done
- finish_rb_merge
- return
- ;;
-skip)
- read_state
- git rerere clear
- cmt="$(cat "$state_dir/cmt.$msgnum")"
- echo "$cmt $(git rev-parse HEAD^0)" >> "$state_dir/rewritten"
- msgnum=$(($msgnum + 1))
- while test "$msgnum" -le "$end"
- do
- call_merge "$msgnum"
- continue_merge
- done
- finish_rb_merge
- return
- ;;
-show-current-patch)
- exec git show REBASE_HEAD --
- ;;
-esac
-
-mkdir -p "$state_dir"
-echo "$onto_name" > "$state_dir/onto_name"
-write_basic_state
-rm -f "$(git rev-parse --git-path REBASE_HEAD)"
-
-msgnum=0
-for cmt in $(git rev-list --topo-order --reverse --no-merges "$revisions")
-do
- msgnum=$(($msgnum + 1))
- echo "$cmt" > "$state_dir/cmt.$msgnum"
-done
-
-echo 1 >"$state_dir/msgnum"
-echo $msgnum >"$state_dir/end"
-
-end=$msgnum
-msgnum=1
-
-while test "$msgnum" -le "$end"
-do
- call_merge "$msgnum"
- continue_merge
-done
-
-finish_rb_merge
-
-}
diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh
index f64b130cb8..b393e1e9fe 100755
--- a/t/t3406-rebase-message.sh
+++ b/t/t3406-rebase-message.sh
@@ -17,14 +17,9 @@ test_expect_success 'setup' '
git tag start
'
-cat >expect <<\EOF
-Already applied: 0001 A
-Already applied: 0002 B
-Committed: 0003 Z
-EOF
-
test_expect_success 'rebase -m' '
git rebase -m master >report &&
+ >expect &&
sed -n -e "/^Already applied: /p" \
-e "/^Committed: /p" report >actual &&
test_cmp expect actual
diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
index 4c7494cc8f..2d1094e483 100755
--- a/t/t3420-rebase-autostash.sh
+++ b/t/t3420-rebase-autostash.sh
@@ -53,41 +53,6 @@ create_expected_success_interactive () {
EOF
}
-create_expected_success_merge () {
- cat >expected <<-EOF
- $(grep "^Created autostash: [0-9a-f][0-9a-f]*\$" actual)
- HEAD is now at $(git rev-parse --short feature-branch) third commit
- First, rewinding head to replay your work on top of it...
- Merging unrelated-onto-branch with HEAD~1
- Merging:
- $(git rev-parse --short unrelated-onto-branch) unrelated commit
- $(git rev-parse --short feature-branch^) second commit
- found 1 common ancestor:
- $(git rev-parse --short feature-branch~2) initial commit
- [detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit
- Author: A U Thor <author@example.com>
- Date: Thu Apr 7 15:14:13 2005 -0700
- 2 files changed, 2 insertions(+)
- create mode 100644 file1
- create mode 100644 file2
- Committed: 0001 second commit
- Merging unrelated-onto-branch with HEAD~0
- Merging:
- $(git rev-parse --short rebased-feature-branch~1) second commit
- $(git rev-parse --short feature-branch) third commit
- found 1 common ancestor:
- $(git rev-parse --short feature-branch~1) second commit
- [detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit
- Author: A U Thor <author@example.com>
- Date: Thu Apr 7 15:15:13 2005 -0700
- 1 file changed, 1 insertion(+)
- create mode 100644 file3
- Committed: 0002 third commit
- All done.
- Applied autostash.
- EOF
-}
-
create_expected_failure_am () {
cat >expected <<-EOF
$(grep "^Created autostash: [0-9a-f][0-9a-f]*\$" actual)
@@ -112,43 +77,6 @@ create_expected_failure_interactive () {
EOF
}
-create_expected_failure_merge () {
- cat >expected <<-EOF
- $(grep "^Created autostash: [0-9a-f][0-9a-f]*\$" actual)
- HEAD is now at $(git rev-parse --short feature-branch) third commit
- First, rewinding head to replay your work on top of it...
- Merging unrelated-onto-branch with HEAD~1
- Merging:
- $(git rev-parse --short unrelated-onto-branch) unrelated commit
- $(git rev-parse --short feature-branch^) second commit
- found 1 common ancestor:
- $(git rev-parse --short feature-branch~2) initial commit
- [detached HEAD $(git rev-parse --short rebased-feature-branch~1)] second commit
- Author: A U Thor <author@example.com>
- Date: Thu Apr 7 15:14:13 2005 -0700
- 2 files changed, 2 insertions(+)
- create mode 100644 file1
- create mode 100644 file2
- Committed: 0001 second commit
- Merging unrelated-onto-branch with HEAD~0
- Merging:
- $(git rev-parse --short rebased-feature-branch~1) second commit
- $(git rev-parse --short feature-branch) third commit
- found 1 common ancestor:
- $(git rev-parse --short feature-branch~1) second commit
- [detached HEAD $(git rev-parse --short rebased-feature-branch)] third commit
- Author: A U Thor <author@example.com>
- Date: Thu Apr 7 15:15:13 2005 -0700
- 1 file changed, 1 insertion(+)
- create mode 100644 file3
- Committed: 0002 third commit
- All done.
- Applying autostash resulted in conflicts.
- Your changes are safe in the stash.
- You can run "git stash pop" or "git stash drop" at any time.
- EOF
-}
-
testrebase () {
type=$1
dotest=$2
@@ -177,6 +105,9 @@ testrebase () {
test_expect_success "rebase$type --autostash: check output" '
test_when_finished git branch -D rebased-feature-branch &&
suffix=${type#\ --} && suffix=${suffix:-am} &&
+ if test ${suffix} = "merge"; then
+ suffix=interactive
+ fi &&
create_expected_success_$suffix &&
test_i18ncmp expected actual
'
@@ -274,6 +205,9 @@ testrebase () {
test_expect_success "rebase$type: check output with conflicting stash" '
test_when_finished git branch -D rebased-feature-branch &&
suffix=${type#\ --} && suffix=${suffix:-am} &&
+ if test ${suffix} = "merge"; then
+ suffix=interactive
+ fi &&
create_expected_failure_$suffix &&
test_i18ncmp expected actual
'
diff --git a/t/t3421-rebase-topology-linear.sh b/t/t3421-rebase-topology-linear.sh
index 23ad4cff35..7274dca40b 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -111,7 +111,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
@@ -126,7 +126,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
@@ -141,7 +141,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
@@ -284,7 +284,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase success -p
@@ -315,7 +315,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_have_prereq !REBASE_P || test_run_rebase failure -p
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 81a5179e28..5cadedb2a9 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -180,7 +180,7 @@ test_expect_success 'prompt - interactive rebase' '
'
test_expect_success 'prompt - rebase merge' '
- printf " (b2|REBASE-m 1/3)" >expected &&
+ printf " (b2|REBASE-i 1/3)" >expected &&
git checkout b2 &&
test_when_finished "git checkout master" &&
test_must_fail git rebase --merge b1 b2 &&
--
2.20.0.8.g5de428d695
^ 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