There are a variety of aspects that are common to all rebases regardless
of which backend is in use; however, the behavior for these different
aspects varies in ways that could surprise users. (In fact, it's not
clear -- to me at least -- that these differences were even desirable or
rebase was taught the --force-rebase option in commit b2f82e05de ("Teach
rebase to rebase even if upstream is up to date", 2009-02-13). This flag
worked for the am and merge backends, but wasn't a valid option for the
interactive backend.
rebase was taught the --no-ff option for interactive
am-based rebases already apply commits with an empty commit message
without requiring the user to specify an extra flag. Make merge-based and
interactive-based rebases behave the same.
Signed-off-by: Elijah Newren
---
Documentation/git-rebase.txt | 10 --
git-rebase.sh
git rebase has three different types: am, merge, and interactive, all of
which are implemented in terms of separate scripts. am builds on git-am,
merge builds on git-merge-recursive, and interactive builds on
git-cherry-pick. We make use of features in those lower-level commands in
the different
signoff is not specific to the am-backend. Also, re-order a few options
to make like things (e.g. strategy and strategy-option) be near each
other.
---
git-rebase.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index
git rebase has many options that only work with one of its three backends.
It also has a few other pairs of incompatible options. Document these.
Signed-off-by: Elijah Newren
---
Documentation/git-rebase.txt | 84
1 file changed, 76 insertions(+), 8
git rebase is split into three types: am, merge, and interactive. Various
options imply different types, and which mode we are using determine which
sub-script (git-rebase--$type) is executed to finish the work. Not all
options work with all types, so add tests for combinations where we expect
git-rebase has lots of options that are mutually incompatible. Even among
aspects of its behavior that is common to all rebase types, it has a number
of inconsistencies. This series tries to document, fix, and/or warn users
about many of these.
I have a much higher than average expectation that
Ever since commit 18633e1a22 ("rebase -i: use the rebase--helper builtin",
2017-02-09), when a commit marked as 'reword' in an interactive rebase
has conflicts and fails to apply, when the rebase is resumed that commit
will be squashed into its parent with its commit message taken.
The issue can
Signed-off-by: Karthikeyan Singaravelan
---
Documentation/RelNotes/1.7.11.7.txt | 2 +-
Documentation/RelNotes/2.17.0.txt | 2 +-
Documentation/RelNotes/2.18.0.txt | 2 +-
Documentation/diff-options.txt | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git
On Sat, Jun 16, 2018 at 11:36 PM Karthikeyan wrote:
> On Sun, Jun 17, 2018, 8:55 AM Eric Sunshine wrote:
>> Please sign-off[1] your patch so it can be included in the project.
>
> Thanks. I am a beginner using Gmail and I have used SubmitToGit for
> this. Is it possible to do this using
On Sat, Jun 16, 2018 at 10:57 PM Christian Couder
wrote:
> On Fri, Jun 15, 2018 at 12:47 AM, Mahmoud Al-Qudsi
> wrote:
> > ~> make NO_ICONV=1
> > # ommitted
> > LINK git-credential-store
> > /usr/bin/ld: cannot find -liconv
> I think 597c9cc540 (Flatten tools/ directory to make build
On Sat, Jun 16, 2018 at 12:08 PM Elijah Newren wrote:
> Subject: [PATCH] sequencer: do not squash 'reword' commits when we hit
> conflicts
> [...]
> Signed-off-by: Elijah Newren
> ---
> diff --git a/t/t3423-rebase-reword.sh b/t/t3423-rebase-reword.sh
> @@ -0,0 +1,44 @@
> +test_expect_success
On Sat, Jun 16, 2018 at 2:08 PM Xtreak wrote:
> doc: fix typos in documentation and release notes
Thanks for the patch. All the fixes look "obviously correct".
Please sign-off[1] your patch so it can be included in the project.
[1]:
Hi,
On Fri, Jun 15, 2018 at 12:47 AM, Mahmoud Al-Qudsi wrote:
> Hello list,
>
> With regards to the Makefile define/variable `NO_ICONV` - the Makefile
> comments imply that it should be used if "your libc doesn't properly support
> iconv," which could mean anything from "a patch will be applied"
Three tests in 't7406-submodule-update' contain broken &&-chains, but
since they are all in subshells, chain-lint couldn't notice them.
Signed-off-by: SZEDER Gábor
---
t/t7406-submodule-update.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
> +static int connect_gitdir_workingtree(int argc, const char **argv, const
> char *prefix)
> +{
> + struct strbuf sb = STRBUF_INIT;
> + const char *name, *path;
> + char *sm_gitdir;
> +
> + if (argc != 3)
> + BUG("submodule--helper connect-gitdir-workingtree
> ");
Hi Johannes,
Johannes Schindelin via GitGitGadget wrote:
> From: GitGitGadget
>
> Todd Zullinger reported this bug in
> https://public-inbox.org/git/20180615043111.gs3...@zaya.teonanacatl.net/:
> when calling git rebase --root and trying to reword the
> root commit's message, a BUG is reported.
From: Johannes Schindelin
The code path that triggered that "BUG" really does not want to run
without an explicit commit message. In the case where we want to amend a
commit message, we have an *implicit* commit message, though: the one of
the commit to amend. Therefore, this code path should
From: Todd Zullinger
When splitting a repository, running `git rebase -i --root` to reword
the initial commit, Git dies with
BUG: sequencer.c:795: root commit without message.
Signed-off-by: Todd Zullinger
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 9
From: GitGitGadget
Todd Zullinger reported this bug in
https://public-inbox.org/git/20180615043111.gs3...@zaya.teonanacatl.net/: when
calling git rebase --root and trying to reword the root commit's message, a BUG
is reported.
This fixes that.
IMO the bug fix is trivial enough to qualify
On Sat, Jun 16, 2018 at 04:35:13PM +0200, SZEDER Gábor wrote:
> > + head -c 512 <$bitmap >$bitmap.tmp &&
> > + mv $bitmap.tmp $bitmap &&
>
> This line turns out to be problematic on OSX and ultimately causes the
> test to fail.
>
> When OSX's 'mv's destination is read-only, it asks whether
---
Documentation/RelNotes/1.7.11.7.txt | 2 +-
Documentation/RelNotes/2.17.0.txt | 2 +-
Documentation/RelNotes/2.18.0.txt | 2 +-
Documentation/diff-options.txt | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/RelNotes/1.7.11.7.txt
On Mon, Jun 11, 2018 at 06:06:11PM +0200, ch wrote:
> During a recent rebase operation on one of my repositories a number of commits
> unexpectedly ended up getting squashed into other commits. After some
> experiments it turned out that the 'reword' instruction seems to squash the
> referenced
Hi,
Git v2.18.0-rc2 introduced a new l10n update, and it's easy to be
fixed, even though there are only two days left for the release of Git
2.18.0.
There are too many l10n updates for Git 2.18.0, and some l10n teams
may not have enough time to update. Not worry about that, we can send
one more
> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
> index 423c0a475f..237ee6e5fc 100755
> --- a/t/t5310-pack-bitmaps.sh
> +++ b/t/t5310-pack-bitmaps.sh
> @@ -331,4 +331,17 @@ test_expect_success 'pack reuse respects --incremental' '
> git show-index actual &&
> test_cmp
> I do not know offhand if "reset --merge" should force succeeding in
such a case, but I agree that it is criminal to stop "reset --hard"
with "not uptodate", as the whole point of "hard reset" is to get
rid of the 'not up-to-date' modification.
I originally had a fix just for "reset --hard". It
27 matches
Mail list logo
