On Fri, Jul 12, 2019 at 11:18 PM Edmundo Carmona Antoranz
wrote:
> @@ -1342,18 +1354,8 @@ int cmd_merge(int argc, const char **argv, const char
> *prefix)
> if (verbosity < 0)
> show_diffstat = 0;
>
> - if (squash) {
> - if (fast_forward == FF_NO)
> -
Using --squash made git stop regardless of conflicts so that the
user could finish the operation with a later call to git-commit.
Now --squash allows for the operation to finish with the new revision
if there are no conflicts (can still be controlled with --no-commit).
Option -m can be used to de
On 2019.06.20 14:06, Emily Shaffer wrote:
> On Wed, Jun 19, 2019 at 08:17:29AM -0700, Junio C Hamano wrote:
> > Emily Shaffer writes:
> >
> > > Maybe there's a case for storing them as a set of patch files that are
> > > revision-controlled somewhere within Documentation/? There was some
> > > di
In the previous patch, we added a deprecation warning for the current
log.mailmap setting. This warning only appears when git is attached to
a controlling terminal. Some tests however run under an emulated
terminal, so we need to disable the warning for those tests.
Signed-off-by: Ariadne Conill
Based on discussions around changing the log.mailmap default to being
enabled, it was decided that a transitional period is required.
Accordingly, we announce this transitional period with a warning
message.
Signed-off-by: Ariadne Conill
---
builtin/log.c | 25 -
1 file
The log.mailmap setting may be explicitly set to false, which disables
the mailmap feature implicity. In practice, doing so is equivalent to
always using the previously undocumented --no-use-mailmap option on the
command line.
Accordingly, we document both the existence of --no-use-mailmap as
well
Based on the discussion of the previous patches, we concluded that
changing the default will require a transitional period.
As such, I have introduced a deprecation warning that is printed when
the log builtin commands are used.
Thanks to Junio and everyone else for providing feedback on how to
p
On Fri, Jul 12, 2019 at 11:21:47AM -0700, Junio C Hamano wrote:
> > Christian Couder writes:
> >
> >> This is an RFC patch series that is not intended to be merged for now,
> >> as it looks like we don't need oidmaps that can handle several entries
> >> with the same key yet.
> >
> > What does it
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
> test_expect_failure (as well as other helper functions in the test
> harness library, such as test_expect_success, test_must_fail,
> test_might_fail, etc.) are explained in t/README. By its definition,
> it technically satisfies "list of known issues" as you asked for.
> However, most softwar
Ariadne Conill writes:
>> 4212.4 raises an interesting question. It wants to see the output
>> of this command:
>>
>> git log --format="%an+%ae+%ad" broken_email >actual.out 2>actual.err
>> &&
>>
>> The question is, when the user explicitly asked for the "true"
>> identity values (not t
Thanks Junio.
I was looking at 'smimesign' and working to understand how, when set
within 'gpg.program', it conformed with gpg's usage within git
sign,verify etc. I happened to look at the docs for the 'gpg.program'
config variable and noticed the discrepancy.
Thanks again,
Robert
On Fri, Jul 1
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 7 ++--
builtin/rebase.c| 23 ++---
seque
rebase am already has this flag to "lie" about the committer date, i.e., by
changing it to the author date. Let's add the same for interactive machinery.
This will get us a step closer to the ultimate aim of achieving consistency
between sequencer commands.
NB: To reduce merge conflicts on the rev
read_author_script reads name, email and author date from the author
script. However, it does not check if the arguments are NULL. Adding
NULL checks will allow us to selectively get the required value, for
example:
char *date;
if (read_author_script(_path_, NULL, NULL, &date, _int_))
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to treat lines
with only whitespace changes as unchanged. Wi
[cc'ing Phillip Wood, Martin Ågren and Dscho; they might be interested]
There are two backends available for rebasing, viz, the am and the interactive.
Naturally, there shall be some features that are implemented in one but not in
the other. One such flag is --ignore-whitespace which indicated mer
Sergey Organov writes:
>> If we have a project like this:
>>
>> A topic that is slightly stale
>>/
>> o---F---o---o---X mainline
>>
>> M, A', and N should end up with identical trees:
>>
>>
>> A---M topic that is slightly stale, merged into ma
Junio C Hamano writes:
> Christian Couder writes:
>
>> This is an RFC patch series that is not intended to be merged for now,
>> as it looks like we don't need oidmaps that can handle several entries
>> with the same key yet.
>
> What does it even mean for a map to allow multiple entries per key
Hello,
On Fri, Jul 12, 2019 at 12:50 PM Junio C Hamano wrote:
>
> Ariadne Conill writes:
>
> > Based on the discussion of the previous patches, we concluded that
> > changing the default will require a transitional period.
>
> OK.
>
> > As such, I have introduced a deprecation warning that is pr
Ariadne Conill writes:
> Based on the discussion of the previous patches, we concluded that
> changing the default will require a transitional period.
OK.
> As such, I have introduced a deprecation warning that is printed when
> the log builtin commands are used.
... used when the user did not
"Robert Morgan via GitGitGadget" writes:
> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt
> index f999f8ea49..cce2c89245 100644
> --- a/Documentation/config/gpg.txt
> +++ b/Documentation/config/gpg.txt
> @@ -2,7 +2,7 @@ gpg.program::
> Use this custom program inste
Johannes Sixt writes:
> Am 12.07.19 um 00:03 schrieb Ramsay Jones:
>> diff --git a/range-diff.c b/range-diff.c
>> index ba1e9a4265..0f24a4ad12 100644
>> --- a/range-diff.c
>> +++ b/range-diff.c
>> @@ -102,7 +102,7 @@ static int read_patches(const char *range, struct
>> string_list *list)
>>
Emily Shaffer writes:
> +test_expect_success 'push --atomic also prevents branch creation, reports
> collateral' '
> + # Setup upstream repo - empty for now
> + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-branches.git &&
> + git init --bare "$d" &&
> + test_config -C "$d" http.receivepack
On Fri, Jul 12, 2019 at 6:50 AM Sergey Organov wrote:
>
> That said, even if we rather all do agree rebase workflow is always
> inferior to merge one, is it satisfactory excuse to actively resist
> otherwise logical behavior of 'git merge' that is even documented? I
> don't think so.
>
> Thus, one
Hello,
On Fri, Jul 12, 2019 at 9:49 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I do not think we usually do this without having to say "at this
> > release" in such a warning.
>
> Sorry for horrible copy-editing that made the result say 100%
> opposite of what I meant. I am bad a
Based on discussions around changing the log.mailmap default to being
enabled, it was decided that a transitional period is required.
Accordingly, we announce this transitional period with a warning
message.
Signed-off-by: Ariadne Conill
---
builtin/log.c | 17 -
1 file changed,
Based on the discussion of the previous patches, we concluded that
changing the default will require a transitional period.
As such, I have introduced a deprecation warning that is printed when
the log builtin commands are used.
Thanks to Junio and everyone else for providing feedback on how to
p
The log.mailmap setting may be explicitly set to false, which disables
the mailmap feature implicity. In practice, doing so is equivalent to
always using the previously undocumented --no-use-mailmap option on the
command line.
Accordingly, we document both the existence of --no-use-mailmap as
well
From: Robert Morgan
The gpg --verify usage example within the 'gpg.program' variable
reference provides an incorrect example of the gpg --verify command
arguments.
The command argument order, when providing both a detached signature
and data, should be signature first and data second:
https://gn
The gpg --verify usage example within the 'gpg.program' variable reference
provides an incorrect example of the gpg --verify command arguments. The
command argument order, when providing both a detached signature and data,
should be signature first and data second:
https://gnupg.org/documentation/
It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git reset HEAD`, the file should be identical
in the index and HEAD. This patch provides the desired behavior even
when the file is empty in the index.
Signed-off-by: Varun Naik
---
My first patch!
Junio C Hamano writes:
> I do not think we usually do this without having to say "at this
> release" in such a warning.
Sorry for horrible copy-editing that made the result say 100%
opposite of what I meant. I am bad at negations.
But I hope the mistake and the message I wanted to convey were
Ariadne Conill writes:
>> What we need at this point is the "second release" phase, i.e.
>> additional warnings without yet changing the default behaviour.
>> After it is given to the end users and sufficient time passes, we
>> can flip the default.
>
> Do you have a proposed timetable for this?
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Junio C Hamano writes:
>>
>> [...]
>>
>>> The "the tip being merged into the mainline must always be
>>> fast-forwardable",
>>
>> It's rather "the tip being merged into the mainline must be fast-forwardable
>> the
>> first time it is merged"
Hi Thomas,
On Thu, 11 Jul 2019, Thomas Gummerer wrote:
> Thanks Junio for the comment on the previous round [1]. This round
> reanmes the struct we're using in apply.c to 'struct gitdiff_data',
> and updates the commit message of 7/14 to reflect the new name of the
> renamed function.
Yep, and
Hi brian,
On Thu, 11 Jul 2019, brian m. carlson wrote:
> On 2019-07-11 at 09:46:26, Johannes Schindelin wrote:
>
> > Since I have your attention and since I am interested in a related issue
> > (when I wanted to propose a GSoC mini project to let `git fetch
> > @` expand the `@` to the current (
On Thu, 2019-07-11 at 22:56 -0400, Andrey wrote:
> Strangely, I don't see any changes that could have broken it between 2.20.1
> and 2.22.0.
> Are you sure your git repository is not "bare", i.e. there's .git
> subdirectory?
> Looks like, it doesn't think that "MM6.test/.git" is a valid git repos
Hello,
On Thu, Jul 11, 2019 at 2:34 PM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > Even though I personally think it is an OK longer-term end goal, the
> > execution looks too hasty. The normal way we handle a big behaviour
> > change like this is to do the following in steps, in dif
39 matches
Mail list logo
