The `git log` command shows the author and committer name recorded in
the git repository itself, while other commands respect `.mailmap`
by default. I believe this is a bad design: it causes log entries to
reflect inaccurate information: anyone who changes their name or
e-mail address will not hav
From: Johannes Schindelin
When running an external diff from, say, a diff tool, it is safe to
assume that we want to write the files in question. On Windows, that
means that there cannot be any other process holding an open handle to
said files, or even just a mapped region.
So let's make sure t
On Windows, it is not possible to overwrite a file as long as any process
holds a read handle to it. Even keeping regions memory-mapped prevents that.
When git difftool calls git diff, it might be the user's intention to write
the file(s) via the diff tool, so let's make sure that they are not
mem
Hi brian,
On Wed, 10 Jul 2019, brian m. carlson wrote:
> On 2019-07-10 at 05:06:08, Mark Florian wrote:
> >
> > I learned today that `@` is a shortcut for `HEAD`. From `git help
> > reivisions`:
> >
> > @ alone is a shortcut for HEAD.
> >
> > However, when I tried to use it in a command I fr
On 08/07/2019 23:02, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> * pw/rebase-progress-test-cleanup (2019-07-01) 1 commit
>>> - t3420: remove progress lines before comparing output
>>> (this branch uses sg/rebase-progress.)
>>>
>>> Test cleanup.
>>>
>>> Will merge to 'next'.
>>
>> I've
Hi Matheus,
On Wed, 10 Jul 2019, Matheus Tavares wrote:
> - a replacement of explicit recursive dir iteration at
> copy_or_link_directory for the dir-iterator API;
As far as I can see, it was not replaced, but just dropped. Which is
good, as it will most likely address the CI failures.
Thanks
Are you interested in a Loan? We offer Loan at 2% interest rate. if you are
interested please send us the amount and your personal details for processing.
On Wed, Jul 10, 2019 at 11:40:50AM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > behavior. How about '--all-include-head'. Then e.g.
> >
> > git rev-parse --all-include-head --all --not origin/master
> >
> > would include the head ref like you proposed below?
> >
> > What do you th
Hi!
I don't know if this is a software or documentation bug.
man git-stash says about --keep-index:
If the --keep-index option is used, all changes already added to
the index are left intact.
If a file is deleted and this deletion is in the index a following
$ git stash push --keep-
Josh Steadmon writes:
> trace_schema_validator can be used to verify that trace2 event output
> conforms to the expectations set by the API documentation and codified
> in event_schema.json (or strict_schema.json). This allows us to build a
> regression test to verify that trace2 output does not
On 2019-07-11 at 09:46:26, Johannes Schindelin wrote:
> After reading that thread, I come to the conclusion that it was not so
> much a decision not to pick it up, but more like a falling between the
> cracks.
>
> I would be in favor of this patch.
I think there was some later follow-up in a diff
On 2019-07-11 at 08:19:58, Ariadne Conill wrote:
> The `git log` command shows the author and committer name recorded in
> the git repository itself, while other commands respect `.mailmap`
> by default. I believe this is a bad design: it causes log entries to
> reflect inaccurate information: any
On Thu, Jul 11, 2019 at 8:56 AM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Wed, 10 Jul 2019, Matheus Tavares wrote:
>
> > - a replacement of explicit recursive dir iteration at
> > copy_or_link_directory for the dir-iterator API;
>
> As far as I can see, it was not replaced, but just drop
Hello,
I am doing a software tool assessment for functional safety and I am reviewing
the use of Git as the SCM. One thing that I need to do is review the list of
"known issues" with the Git release being used. I have gone through the release
notes and found that it only contains the fixes and
On 2019-07-09 at 20:51:39, Bryan Turner wrote:
> I think this is something I've seen come up on the list before[1]
> (Roland can correct me if I'm wrong). What I've seen asked for before
> is the ability to pass the combination "--ff-only --no-ff" and have
> that:
> * Ensure the branch to be merged
On Thu, Jul 11, 2019 at 8:50 AM Mark T. Ortell wrote:
>
> Hello,
>
> I am doing a software tool assessment for functional safety and I am
> reviewing the use of Git as the SCM. One thing that I need to do is review
> the list of "known issues" with the Git release being used. I have gone
> thro
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
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.
[1]: https://public-inbox.org/git/20190708163315.29912-1-t.gumme...@gmail.
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
Currently the 'find_name_*()' functions take 'struct apply_state' as
parameter, even though they only need the 'root' member from that
struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we o
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Make 'parse_git_header()' (renamed to 'parse_git_diff_header()') a
"public" function in apply.h, so we can re-use it in range-diff in a
subsequent commit. We're renaming the function to make it clearer in
other parts of the codebase that we're talking about a diff header and
not just any header.
Currently the 'gitdiff_*()' functions take 'struct apply_state' as
parameter, even though they only needs the root, linenr and p_value
from that struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that h
Fix the indentation of the function parameters for a couple of
functions, to match the style in the rest of the file.
Signed-off-by: Thomas Gummerer
---
range-diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/range-diff.c b/range-diff.c
index 48b0e1b4ce..9242b8975f 1
Currently range-diff uses the 'strbuf_getline()' function for doing
its line by line processing. In a future patch we want to do parts of
that parsing using the 'parse_git_diff_header()' function. That
function does its own line by line reading of the input, and doesn't
use strbufs. This doesn't
Add the section headers/hunk headers we introduced in the previous
commits to the outer diff's hunk headers. This makes it easier to
understand which change we are actually looking at. For example an
outer hunk header might now look like:
@@ Documentation/config/interactive.txt
while previ
Currently range-diff keeps the diff header of the inner diff
intact (apart from stripping lines starting with index). This diff
header is somewhat useful, especially when files get different
names in different ranges.
However there is no real need to keep the whole diff header for that.
The main
When postprocessing the inner diff in range-diff, we currently replace
the whole hunk header line with just "@@". This matches how 'git
tbdiff' used to handle hunk headers as well.
Most likely this is being done because line numbers in the hunk header
are not relevant without other changes. They
In a range-diff it's not always clear which file a certain funcname of
the inner diff belongs to, because the diff header (or section header
as added in a previous commit) is not always visible in the
range-diff.
Add the filename to the inner diffs header, so it's always visible to
users.
This al
The line count in the outer diff's hunk headers of a range diff is not
all that interesting. It merely shows how far along the inner diff
are on both sides. That number is of no use for human readers, and
range-diffs are not meant to be machine readable.
In a subsequent commit we're going to add
On 2019-07-11 at 15:28:27, Mark T. Ortell wrote:
> Hello,
>
> I am doing a software tool assessment for functional safety and I am
> reviewing the use of Git as the SCM. One thing that I need to do is review
> the list of "known issues" with the Git release being used. I have gone
> through the
Hello,
On Thu, Jul 11, 2019 at 10:19 AM brian m. carlson
wrote:
>
> On 2019-07-11 at 08:19:58, Ariadne Conill wrote:
> > The `git log` command shows the author and committer name recorded in
> > the git repository itself, while other commands respect `.mailmap`
> > by default. I believe this is
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".
>
>> however, is not consistent with
Signed-off-by: Ramsay Jones
---
Hi Junio,
It seems Ævar didn't have a need to re-roll his patches [1], before
the 'ab/test-env' branch was merged to next. This version of the
patch is based on current 'next'.
Thanks!
ATB,
Ramsay Jones
[1]
https://public-inbox.org/git/f576dfa8-4beb-6430-67b
Hi Ariadne,
Welcome to the list!
On Thu, 11 Jul 2019 at 18:39, Ariadne Conill wrote:
>
> Hello,
>
> On Thu, Jul 11, 2019 at 10:19 AM brian m. carlson
> wrote:
> >
> > On 2019-07-11 at 08:19:58, Ariadne Conill wrote:
> > > The `git log` command shows the author and committer name recorded in
> >
Am 10.07.19 um 20:40 schrieb Junio C Hamano:
> Heiko Voigt writes:
>
>> behavior. How about '--all-include-head'. Then e.g.
>>
>> git rev-parse --all-include-head --all --not origin/master
>>
>> would include the head ref like you proposed below?
>>
>> What do you think? Or would you rather g
It is not uncommon for people to change their name or e-mail address.
To facilitate this, Git provides support for the `.mailmap` file,
which contains a list of identities and previously used e-mail
addresses that are associated with that identity.
Unfortunately, while Git's support for the `.mail
When mailmap is enabled by default or by configuration, it may be
useful to override the default behaviour. Previously, it was
possible to enable the mailmap feature when it was disabled by
default or in the configuration, but it was not possible to disable
the mailmap feature when it was enabled
In order to prove that the --no-use-mailmap option works as expected,
we add a test for it which runs with -Dlog.mailmap=true to ensure that
the option successfully negates the configured default.
Signed-off-by: Ariadne Conill
---
t/t4203-mailmap.sh | 8
1 file changed, 8 insertions(+)
The `git log` command shows the author and committer name recorded in
the git repository itself, while other commands respect `.mailmap`
by default. I believe this is a bad design: it causes log entries to
reflect inaccurate information: anyone who changes their name or
e-mail address will not hav
Matheus Tavares Bernardino writes:
> Sorry for the delay. I just sent v8[1] with Dscho's suggestions, which
> should fix all those test failures on Windows.
Thanks.
"Randall S. Becker" writes:
> On July 9, 2019 5:51 PM, Peff wrote:
[...]
>> No, textconv only applies when generating a diff to output, and will never
>> impact what's stored in Git.
>>
>> It sounds like you might want a clean filter instead, to sanitize the file
>> contents as they come into Git
On 11.07.19 19:26, Ariadne Conill wrote:
> In order to prove that the --no-use-mailmap option works as expected,
> we add a test for it which runs with -Dlog.mailmap=true to ensure that
s/-D/-c /
This ain't Java :-)
> the option successfully negates the configured default.
>
> Signed-off-by: Ar
Hello,
On Thu, Jul 11, 2019 at 12:32 PM Beat Bolli wrote:
>
> On 11.07.19 19:26, Ariadne Conill wrote:
> > In order to prove that the --no-use-mailmap option works as expected,
> > we add a test for it which runs with -Dlog.mailmap=true to ensure that
>
> s/-D/-c /
>
> This ain't Java :-)
Indeed
Hello,
On Thu, Jul 11, 2019 at 12:09 PM Martin Ågren wrote:
>
> Hi Ariadne,
>
> Welcome to the list!
Thanks!
> On Thu, 11 Jul 2019 at 18:39, Ariadne Conill wrote:
> >
> > Hello,
> >
> > On Thu, Jul 11, 2019 at 10:19 AM brian m. carlson
> > wrote:
> > >
> > > On 2019-07-11 at 08:19:58, Ariadne
On 07/11, Martin Nicolay wrote:
> Hi!
>
> I don't know if this is a software or documentation bug.
>
> man git-stash says about --keep-index:
> If the --keep-index option is used, all changes already added to
> the index are left intact.
>
> If a file is deleted and this deletion is in t
When mailmap is enabled by default or by configuration, it may be
useful to override the default behaviour. Previously, it was
possible to enable the mailmap feature when it was disabled by
default or in the configuration, but it was not possible to disable
the mailmap feature when it was enabled
In order to prove that the --no-use-mailmap option works as expected,
we add a test for it which runs with -c log.mailmap=true to ensure that
the option successfully negates the configured default.
Additionally, since --use-mailmap is now the default behaviour, we
remove mentions of --use-mailmap
It is not uncommon for people to change their name or e-mail address.
To facilitate this, Git provides support for the `.mailmap` file,
which contains a list of identities and previously used e-mail
addresses that are associated with that identity.
Unfortunately, while Git's support for the `.mail
The `git log` command shows the author and committer name recorded in
the git repository itself, while other commands respect `.mailmap`
by default. I believe this is a bad design: it causes log entries to
reflect inaccurate information: anyone who changes their name or
e-mail address will not hav
On 11.07.19 19:26, Ariadne Conill wrote:
> When mailmap is enabled by default or by configuration, it may be
> useful to override the default behaviour. Previously, it was
> possible to enable the mailmap feature when it was disabled by
> default or in the configuration, but it was not possible to
Hello,
On Thu, Jul 11, 2019 at 1:24 PM Beat Bolli wrote:
>
> On 11.07.19 19:26, Ariadne Conill wrote:
> > When mailmap is enabled by default or by configuration, it may be
> > useful to override the default behaviour. Previously, it was
> > possible to enable the mailmap feature when it was disa
On 11.07.19 20:25, Ariadne Conill wrote:
> Hello,
>
> On Thu, Jul 11, 2019 at 1:24 PM Beat Bolli wrote:
>>
>> On 11.07.19 19:26, Ariadne Conill wrote:
>>> When mailmap is enabled by default or by configuration, it may be
>>> useful to override the default behaviour. Previously, it was
>>> possib
When mailmap is enabled by default or by configuration, it may be
useful to override the default behaviour. Previously, it was
possible to enable the mailmap feature when it was disabled by
default or in the configuration, but it was not possible to disable
the mailmap feature when it was enabled
It is not uncommon for people to change their name or e-mail address.
To facilitate this, Git provides support for the `.mailmap` file,
which contains a list of identities and previously used e-mail
addresses that are associated with that identity.
Unfortunately, while Git's support for the `.mail
The `git log` command shows the author and committer name recorded in
the git repository itself, while other commands respect `.mailmap`
by default. I believe this is a bad design: it causes log entries to
reflect inaccurate information: anyone who changes their name or
e-mail address will not hav
In order to prove that the --no-use-mailmap option works as expected,
we add a test for it which runs with -c log.mailmap=true to ensure that
the option successfully negates the configured default.
Additionally, since --use-mailmap is now the default behaviour, we
remove mentions of --use-mailmap
Heiko Voigt writes:
> if {$revs eq {}} {
> set revs HEAD
> -} elseif {[lsearch -exact $revs --all] >= 0} {
> - lappend revs HEAD
> +} else {
> + linsert revs 0 --all-include-head
> }
OK. So the new option means "from here on, the meaning of the
'--all' opti
Elijah,
Thanks for the response. I am not clear whether the test_expect_failure means
that the test is trying to do something that should fail and so it is a valid
test case or if it is a test case that is failing, but should succeed and has
only been temporarily disabled until it is fixed. I'm
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When running an external diff from, say, a diff tool, it is safe to
> assume that we want to write the files in question. On Windows, that
> means that there cannot be any other process holding an open handle to
> sai
Ariadne Conill writes:
> It is not uncommon for people to change their name or e-mail address.
> To facilitate this, Git provides support for the `.mailmap` file,
> which contains a list of identities and previously used e-mail
> addresses that are associated with that identity.
>
> Unfortunately
On Thu, 11 Jul 2019 at 20:39, Ariadne Conill wrote:
>
> In order to prove that the --no-use-mailmap option works as expected,
> we add a test for it which runs with -c log.mailmap=true to ensure that
> the option successfully negates the configured default.
I believe that testing with `-c log.mai
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 different
> releases:
>
> - In the first release, introduce an early adoptor
Hi Mark,
On Thu, Jul 11, 2019 at 12:02 PM Mark T. Ortell
wrote:
>
> Elijah,
>
> Thanks for the response. I am not clear whether the test_expect_failure means
> that the test is trying to do something that should fail and so it is a valid
> test case or if it is a test case that is failing, but
subscribe git
On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git
You need to send this to majord...@vger.kernel.org. Sending it to the
git mailing list will not do a lot.
Kevin
Apologies list! Thanks Kevin. That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.
Robert
On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
>
On Wed, Jul 10, 2019 at 10:44:22AM -0700, Junio C Hamano wrote:
> 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 &&
> >
On 11/07/2019 03:13, Derrick Stolee wrote:
I apologize for the incorrect report sent earlier. I changed something about my
workflow, and it changed where build outputs were downloaded and I included an
old report.
-Stolee
---
pu c984b65d414a0da7af629eb476f12b27e13ede0b
jch 2bb3fc833
Emily Shaffer writes:
> Hmm. I'd like to argue that part of the requirement is to show the user
> what happened; for example, in an earlier iteration I was not
> successfully reporting the "collateral damage" refs to the user, even
> though they were not being pushed. To that end, I'd rather chec
On Wed, Jul 10, 2019 at 10:53:30AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> + # the new branch should not have been created upstream
> >> + test_must_fail git -C "$d" rev-parse refs/heads/atomic &&
> >
> > The new branch should not have been created; if this rev-parse
> > su
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side. We notice that a ref would be
rejected, and choose not to send it, but don't notice that if the client
has asked for --atomic we are violating atomicity if all the other
pushes we are send
Thomas Gummerer writes:
> Fix that behaviour by using 'git restore' which can faithfully restore
> the index and working tree. This also simplifies the code.
Hmph. I would have preferred to see we stayed away from 'restore'
(and used 'checkout' instead, if you must use a Porcelain command),
so
Hi all,
I noticed that git pull reports "Already up to date." but git push
reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
the Ubuntu repos.) Just for a consistent user experience, would it be
worth standardizing on:
Hyphenation (up-to-date vs up to date)?
Periods at the e
Derrick Stolee writes:
> On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote:
>>
>> Here is a second run at this RFC, which aims to create a "meta" config
>> setting that automatically turns on other settings according to a user's
>> willingness to trade new Git behavior or new feature ris
On 2019-07-11 at 21:36:50, Michael Kielstra wrote:
> Hi all,
>
> I noticed that git pull reports "Already up to date." but git push
> reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
> the Ubuntu repos.) Just for a consistent user experience, would it be
> worth standardizin
Signed-off-by: Ramsay Jones
---
Hi Thomas,
If you need to re-roll your 'tg/range-diff-output-update' branch, could
you please squash (parts) of this into the relevant patches.
The first hunk fixes a couple of 'hdr-check' warnings:
$ diff nhcout phcout | head
4a5,13
> apply.h:146:22: er
On 11/07/2019 17:08, 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.
>
> [1]: https://pu
25.06.2019, 13:44, "Junio C Hamano" :
> Andrey writes:
>
>>> Thanks. When I ask "Is this ready", I am asking for opinion(s) from
>>> third-party, not self nomination ;-)
>>
>> Ah, ok, sorry. :)
>> I just haven't seen any related comments to any of your previous "What's
>> cooking" emails,
>>
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)
> }
>
> i
On Fri, 12 Jul 2019 at 03:20, Andrey wrote:
>
> 25.06.2019, 13:44, "Junio C Hamano" :
> > Andrey writes:
> >
> >>> Thanks. When I ask "Is this ready", I am asking for opinion(s) from
> >>> third-party, not self nomination ;-)
> >>
> >> Ah, ok, sorry. :)
> >> I just haven't seen any related co
On Fri, 12 Jul 2019 at 00:16, brian m. carlson
wrote:
>
> On 2019-07-11 at 21:36:50, Michael Kielstra wrote:
> > Hi all,
> >
> > I noticed that git pull reports "Already up to date." but git push
> > reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
> > the Ubuntu repos.) Jus
83 matches
Mail list logo
