Hi,
Sorry for incomplete post earlier. Here is the full post:
In the latest version of git a new attribute has been added,
working-tree-encoding. The release notes states:
'The new "working-tree-encoding" attribute can ask Git to convert the
contents to the specified encoding when
I could not find anything that would allow us to say 'if platform = z/OS then
encoding=EBCDIC else encoding=ASCII'. Is there a way this can be done?
Thanks
Steve Groeger
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517
On Wed, Jun 27, 2018 at 12:45 AM, Eric Sunshine wrote:
> On Wed, Jun 27, 2018 at 3:36 AM Elijah Newren wrote:
>> We are not passing the same args to merge strategies when we are doing an
>> --interactive rebase as we do with a --merge rebase. The merge strategy
>> should not need to be aware of
Signed-off-by: Elijah Newren
---
Changes since v1:
- Fixed up commit message (move below comment to below diffstat as
originally intended)
Long term I just want to make git-rebase--merge go away, so this patch
will eventually be obsoleted. But since I'm waiting for multiple
topics to
On Wed, Jun 27, 2018 at 3:36 AM Elijah Newren wrote:
> We are not passing the same args to merge strategies when we are doing an
> --interactive rebase as we do with a --merge rebase. The merge strategy
> should not need to be aware of which type of rebase is in effect. Add a
> testcase which
The interactive machinery for git rebase can accept special merge
strategies or strategy options, but has a bug in its handling of
strategy options. This short series patches that.
Changes since v1:
- Small change to the second commit message
- Addition of a cover letter. :-)
Elijah Newren
git-rebase.sh wrote strategy options to .git/rebase/merge/strategy_opts
in the following format:
'--ours' '--renormalize'
Note the double spaces.
git-rebase--interactive uses sequencer.c to parse that file, and
sequencer.c used split_cmdline() to get the individual strategy options.
After
We are not passing the same args to merge strategies when we are doing an
--interactive rebase as we do with a --merge rebase. The merge strategy
should not need to be aware of which type of rebase is in effect. Add a
testcase which checks for the appropriate args.
Signed-off-by: Elijah Newren
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
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
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.
Changes since v4 (short branch-diff at the end):
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 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 | 85
1 file changed, 77 insertions(+), 8
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
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.
Signed-off-by: Elijah Newren
---
git-rebase.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-rebase.sh
Add a simple directory rename testcase, in conjunction with each of the
types of rebases:
git-rebase--interactive
git-rebase--am
git-rebase--merge
and also use the same testcase for
git am --3way
This demonstrates a difference in behavior between the different rebase
backends in regards
Signed-off-by: Elijah Newren
---
.../technical/directory-rename-detection.txt | 92 +++
1 file changed, 92 insertions(+)
create mode 100644 Documentation/technical/directory-rename-detection.txt
diff --git a/Documentation/technical/directory-rename-detection.txt
rebase backends currently behave differently with empty commit messages,
largely as a side-effect of the different underlying commands on which
they are based. am-based rebases apply commits with an empty commit
message without stopping or requiring the user to specify an extra flag.
(It is
On Tue, Jun 26, 2018 at 11:17 AM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> +# Rebase has lots of useful options like --whitepsace=fix, which are
>> +# actually all built in terms of flags to git-am. Since neither
>> +# --merge nor --interactive (nor any options that imply those two)
On Wed, Jun 27, 2018 at 2:27 AM Johannes Sixt wrote:
> Am 27.06.2018 um 04:15 schrieb Elijah Newren:
> > On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
> >> On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> >>> Some of these dangers can be de-thoothed during the linting phase
Am 27.06.2018 um 04:15 schrieb Elijah Newren:
On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
Some of these dangers can be de-thoothed during the linting phase by
defining do-nothing shell functions:
cp () { :; }
mv
101 - 121 of 121 matches
Mail list logo
