On Wed, Oct 23, 2019 at 01:01:34PM +, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
> config behavior. His example initially happened during a clone with
> --recurse-submodules, we
On Wed, Oct 23, 2019 at 8:04 AM Denton Liu wrote:
> Currently, apply does not respect the merge.conflictStyle setting.
> Demonstrate this by making the 'apply with --3way' test case generic and
> extending it to show that the configuration of
> merge.conflictStyle = diff3 causes a breakage.
>
> Ch
UPDATE for V2: We now know the full repro, and a test is added. Thanks
Szeder and Peff for your insights!
While dogfooding, Johannes found a bug in the fetch.writeCommitGraph config
behavior. While his example initially happened during a clone with
--recurse-submodules, (UPDATE) and the submodule
From: Derrick Stolee
While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
config behavior. His example initially happened during a clone with
--recurse-submodules, we found that this happens with the first fetch
after cloning a repository that contains a submodule:
$ git
On Wednesday 23 October 2019 13:09:51 CEST Denton Liu wrote:
> On Wed, Oct 23, 2019 at 10:15:15AM +, Jerome Pouiller wrote:
> > On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> > > I am currently have a WIP patchset that will print the location of the
> > > failed patch file (.git
This fixes a bug where even if `merge.conflictStyle = diff3`, running
`git apply --3way` would not output the base.
Patches 1-3 are general cleanup for t4108, 4 demonstrates the bug and 5
actually fixes it.
Denton Liu (5):
t4108: replace create_file with test_write_lines
t4108: remove git
Currently, apply does not respect the merge.conflictStyle setting.
Demonstrate this by making the 'apply with --3way' test case generic and
extending it to show that the configuration of
merge.conflictStyle = diff3 causes a breakage.
Change print_sanitized_diff() to also sanitize `|||` conflic
On Wed, Oct 23, 2019 at 10:15:15AM +, Jerome Pouiller wrote:
> On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> > I am currently have a WIP patchset that will print the location of the
> > failed patch file (.git/rebase-apply/patch) in the case of a failure as
> > well as the line
On Wednesday 23 October 2019 10:55:03 CEST Denton Liu wrote:
> On Wed, Oct 23, 2019 at 08:49:41AM +, Jerome Pouiller wrote:
> > On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> > > Jerome Pouiller writes:
> > > > I try to use "git am" to apply a patch sent using "git send-ema
Hi Jerome,
On Wed, Oct 23, 2019 at 08:49:41AM +, Jerome Pouiller wrote:
> On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> > Jerome Pouiller writes:
> > > I try to use "git am" to apply a patch sent using "git send-email". This
> > > patch does not apply properly. I try to u
On Wednesday 23 October 2019 04:24:58 CEST Junio C Hamano wrote:
> Jerome Pouiller writes:
> > I try to use "git am" to apply a patch sent using "git send-email". This
> > patch does not apply properly. I try to use "git am --show-current-patch"
> > to understand the problem. However, since origin
Jerome Pouiller writes:
> Hello all,
>
> I try to use "git am" to apply a patch sent using "git send-email". This
> patch does not apply properly. I try to use "git am --show-current-patch"
> to understand the problem. However, since original mail is encoded in quoted-
> printable, data returned
While dogfooding, Johannes found a bug in the fetch.writeCommitGraph config
behavior. While his example initially happened during a clone with
--recurse-submodules, we found that it is actually a problem with the first
fetch after a new clone and no existing commit-graph file:
$ git clone test
Hello all,
I try to use "git am" to apply a patch sent using "git send-email". This
patch does not apply properly. I try to use "git am --show-current-patch"
to understand the problem. However, since original mail is encoded in quoted-
printable, data returned by --show-current-patch is not a vali
Hello,
[+cc: Ævar]
John Paul Adrian Glaubitz wrote:
> The testsuite is failing again on s390x and all other big-endian targets in
> Debian. For a full build log on s390x see [1].
>
> Adrian
>
>> [1]
>> https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.24.0%7Erc0-1&stamp=1
Hi!
On 7/31/19 9:17 AM, Todd Zullinger wrote:
>> Build logs are:
>>
>>> https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.23.0%7Erc0-1&stamp=1564449102&raw=0
>>> https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.23.0%7Erc0%2Bnext.20190729-1&stamp=1564449
Hi Thomas,
On Fri, Oct 18, 2019 at 02:02:29PM +0200, Thomas Braun wrote:
> This is a known bug unfortunately. See
> https://public-inbox.org/git/cagz79kyty6u0enwvu0pcdyt_qxgyygm5vkdvwltuqgqg6bb...@mail.gmail.com/
> for reference.
Good to know. Thanks for the reference.
Chris
/include/mbedtls/oid.h
> ext/mbedtls/include/mbedtls/pk.h
> ext/mbedtls/include/mbedtls/platform.h
> ext/mbedtls/include/mbedtls/platform_util.h
> ext/mbedtls/include/mbedtls/threading.h
> Please move or remove them before you switc
Hello all,
### Environment:
$ git --version
git version 2.21.0
### Reproduce:
git clone g...@github.com:JuulLabs-OSS/mcuboot.git
cd mcuboot
git submodule init
git submodule update
git checkout ae01f153b11637feaedbc9d9042172fba2e080c0
### Discussion:
In the above sequence, the last step (check
On Fri, Oct 11, 2019 at 03:10:33PM -0500, Brent Casavant wrote:
> I noticed what appears to be a bug in rev-parse with an admittedly
> somewhat unusual combination of arguments.
>
> Compare the output of the following:
>
> % git rev-parse HEAD --no
Hello,
I noticed what appears to be a bug in rev-parse with an admittedly somewhat
unusual combination of arguments.
Compare the output of the following:
% git rev-parse HEAD --not --remotes=origin
3de09080eb219149a8596dc21915d5a496cba171
^4fb157bf360413fe3fad38d03b02ce7232d12961
Hi,
I ran into an issue where git stash seems to be losing modified content
from submodules without warning, if submodule.recurse is true. See
below for an example:
1. enable submodule.recurse:
~ $ git config --global submodule.recurse true
2. create the repo to be used as a submodule:
~ $ git
Derrick Stolee writes:
> On 10/6/2019 7:30 PM, Eric Wong wrote:
>> v3 changes:
>> - use __typeof__ to avoid invalid clang warning on uninitialized var
>> - formatting fixes recommended by Stolee
>> - add Reviewed-by for Stolee
>> - add patch 20 to update docs to drop first member requirement
>>
On 10/6/2019 7:30 PM, Eric Wong wrote:
> v3 changes:
> - use __typeof__ to avoid invalid clang warning on uninitialized var
> - formatting fixes recommended by Stolee
> - add Reviewed-by for Stolee
> - add patch 20 to update docs to drop first member requirement
>
> Range-diff against v2:
I scann
On 10/8/2019 4:58 AM, Johannes Schindelin wrote:
> Hi Eric & Junio,
>
> On Sun, 6 Oct 2019, Eric Wong wrote:
>
>> v3 changes:
>> - use __typeof__ to avoid invalid clang warning on uninitialized var
>> - formatting fixes recommended by Stolee
>> - add Reviewed-by for Stolee
>> - add patch 20 to up
On Fri, Sep 27, 2019 at 02:02:01PM +0200, SZEDER Gábor wrote:
> On Fri, Sep 27, 2019 at 11:51:07AM +0200, Anders Janmyr wrote:
> > I'm not sure if this is a bug or not but `git describe` gives
> > different results when the repo has been cloned with `--depth` or not.
> >
Hi Eric & Junio,
On Sun, 6 Oct 2019, Eric Wong wrote:
> v3 changes:
> - use __typeof__ to avoid invalid clang warning on uninitialized var
> - formatting fixes recommended by Stolee
> - add Reviewed-by for Stolee
> - add patch 20 to update docs to drop first member requirement
This has quite a b
Eric Wong writes:
> v3 changes:
> - use __typeof__ to avoid invalid clang warning on uninitialized var
> - formatting fixes recommended by Stolee
> - add Reviewed-by for Stolee
> - add patch 20 to update docs to drop first member requirement
I just did
git checkout ew/hashmap
gi
v3 changes:
- use __typeof__ to avoid invalid clang warning on uninitialized var
- formatting fixes recommended by Stolee
- add Reviewed-by for Stolee
- add patch 20 to update docs to drop first member requirement
v2 here:
https://public-inbox.org/git/20190924010324.22619-...@80x24.org/
The fol
From: Johannes Schindelin
The return value of that function is 0 both for variables that are
unset, as well as for variables whose values are empty. To discern those
two cases, one has to call `GetLastError()`, whose return value is
`ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively.
Exc
Denton Liu writes:
> Range-diff against v1:
> 1: e77af8cde5 = 1: e77af8cde5 test-lib: let test_merge() perform octopus
> merges
micronit: I would say s/let/allow/ if I were writing this.
> 2: 4a93deb3f6 = 2: 4a93deb3f6 t4214: use test_merge
> 3: c09f761185 = 3: c09f761185 t4214: generate
Junio, the test cases from earlier didn't exactly cover the cases Peff
talked about so I added a few more test cases. These should cover those
situations and a few more so we can be extra sure when the bug is fixed.
This patchset cleans up t4214 and then, in the last patch, demonstrates
a b
Duy Nguyen writes:
> On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano wrote:
>> > In fact, running `git am --show-current-patch` shows the whole mail, not
>> > only the 'patch' file so users would have no reason to expect the line
>> > numbers to refer to the 'patch' file.
>>
>> Yeah, show-current-
rong (because they're
> the non-collapsing type).
Thanks for analysing further. I wonder if new tests added by
Denton's BUG/PATCH series cover both kinds? It would be good
to make sure that any "fix" corrects known-broken cases while
keeping the working cases still working.
Thanks.
On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano wrote:
> > In fact, running `git am --show-current-patch` shows the whole mail, not
> > only the 'patch' file so users would have no reason to expect the line
> > numbers to refer to the 'patch' file.
>
> Yeah, show-current-patch was a misguided attemp
gt; separate 'msg' file in the same directory and stores the rest in
>> that 'patch' file. And it is line 87 that has problems.
>
> In this case, I would still regard this as a bug since users would
> expect the line 87 to refer to their input file. I think most use
the rest in
> that 'patch' file. And it is line 87 that has problems.
In this case, I would still regard this as a bug since users would
expect the line 87 to refer to their input file. I think most users
don't even realise that a .git/rebase-apply/patch file exists. (I
certainly
e
> last hunk wants it to be, in which case we should be able to say
> 'premature end of input at line 87' or something like that.
Yep, I noticed this bug while I was writing a patch to do exactly that.
>
>
Denton Liu writes:
> which is in the middle of the log message. I expect the line to be
> reported as something in the range of 198-203,...
That comes from not knowing who is complaining and what it is
reading. In this case, "git apply" issues a warning because it is
fed .git/rebase-apply/patch
Denton Liu writes:
> Applying: dir: special case check for the possibility that pathspec is
> NULL
> error: corrupt patch at line 87
This refers to line 87 of the input file, not a line that begins
with "@@ -87,count...", doesn't it? If the sender hand edits a
patch without correct
Hello all,
I found a bug where the line numbers in git am are being reported
incorrectly in the case where a patch fails to apply cleanly.
The test case for this is pretty simple:
$ wget
https://public-inbox.org/git/20191001185524.18772-1-new...@gmail.com/raw
$ git am raw
And
Johannes Schindelin wrote:
> Hi Eric,
>
> On Tue, 24 Sep 2019, Eric Wong wrote:
>
> > Patches 1-11 are largely unchanged from the original series with the
> > exception of 2, which is new and posted at:
> >
> > https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
> >
> > 12-17
From: Johannes Schindelin
The return value of that function is 0 both for variables that are
unset, as well as for variables whose values are empty. To discern those
two cases, one has to call `GetLastError()`, whose return value is
`ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively.
Exc
Eric Wong writes:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap_entry being
> the first elem
On Fri, Sep 27, 2019 at 04:17:46AM +0200, SZEDER Gábor wrote:
> On Fri, Sep 27, 2019 at 03:09:30AM +0200, SZEDER Gábor wrote:
> > On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> > > Hi Elijah,
> > >
> > > I ran into a segfault on MacOS. I managed to bisect it down to
> > > 404ebceda0
On Fri, Sep 27, 2019 at 11:51:07AM +0200, Anders Janmyr wrote:
> Hi,
>
> I'm not sure if this is a bug or not but `git describe` gives
> different results when the repo has been cloned with `--depth` or not.
>
> In the example below from the git repository the number
Hi,
I'm not sure if this is a bug or not but `git describe` gives
different results when the repo has been cloned with `--depth` or not.
In the example below from the git repository the number of additional
commits since the
last tag differs 256 vs. 265.
```
$ git clone https://github.co
On Fri, Sep 27, 2019 at 03:09:30AM +0200, SZEDER Gábor wrote:
> On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> > Hi Elijah,
> >
> > I ran into a segfault on MacOS. I managed to bisect it down to
> > 404ebceda0 (dir: also check directories for matching pathspecs,
> > 2019-09-17), whi
On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The test
> case below works f
ctory() like this:
>
> i = read_directory(&d, o->src_index, pathbuf, namelen+1, NULL);
>
> where we explictly pass in a NULL and it is handed down the callstack. I
> guess this means that we should be expecting that pathspecs can be NULL
> in this path. So I've applied
pecs can be NULL
in this path. So I've applied the patch at the bottom and it fixes the
problem.
I was wondering if we should stick a
if (!ps)
BUG("ps is NULL");
into do_match_pathspec(), though, so we can avoid these situations in
the future.
Also, I'm st
On Wed, Sep 25, 2019 at 10:09:02AM -0700, Denton Liu wrote:
> On Wed, Sep 25, 2019 at 03:26:57AM -0700, Denton Liu wrote:
> > I tried my hand at fixing the bug but in the hour I spent going at it, I
> > couldn't fix the logic up. The buggy logic is in graph.c:
> > gra
Hi Eric
On 24/09/2019 02:03, Eric Wong wrote:
Patches 1-11 are largely unchanged from the original series with the
exception of 2, which is new and posted at:
https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
12-17 take further steps to get us away from hashmap_entry b
Hi Eric,
On Tue, 24 Sep 2019, Eric Wong wrote:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap
From: Johannes Schindelin
The return value of that function is 0 both for variables that are
unset, as well as for variables whose values are empty. To discern those
two cases, one has to call `GetLastError()`, whose return value is
`ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively.
Exc
On Wed, Sep 25, 2019 at 02:28:15PM -0700, Elijah Newren wrote:
[...]
> > Sorry for the information dump, I haven't had the time to properly look
> > into the issue but I just wanted to make sure that you're aware.
>
> Thanks for testing and sending the heads up. Unfortunately, I cannot
> reprod
Hi Denton,
On Wed, Sep 25, 2019 at 1:39 PM Denton Liu wrote:
>
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The test
> case below wor
Hi Elijah,
I ran into a segfault on MacOS. I managed to bisect it down to
404ebceda0 (dir: also check directories for matching pathspecs,
2019-09-17), which should be the patch in the parent thread. The test
case below works fine without this patch applied but segfaults once it
is applied.
On Wed, Sep 25, 2019 at 03:26:57AM -0700, Denton Liu wrote:
> I tried my hand at fixing the bug but in the hour I spent going at it, I
> couldn't fix the logic up. The buggy logic is in graph.c:
> graph_draw_octopus_merge() in case anyone is interested.
I guess for the record, this
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap_entry b
Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.
Move the generation of the ex
In the previous commit, we extended test_merge() so that it could
perform octopus merges. Now that the restriction is lifted, use
test_merge() to perform the octopus merge instead of manually
duplicating test_merge() functionality.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 3 +
This patchset cleans up t4214 and then, in the last patch, demonstrates
a bug in the way some octopus merges are colored.
While I was playing around with Pratyush's octopus merge in git-gui, I
noticed that there was a bug in `git log --graph`. The horizontal lines
in the octopus merge seem
In a future test case, we will be extending the commit graph. As a
result, explicitly list the tags that will generate the graph so that
when future additions are made, the current graph illustrations won't be
affected.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 8
1 f
The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).
If one runs
git log
Currently test_merge() only allows developers to merge in one branch.
However, this restriction is artificial and there is no reason why it
needs to be this way.
Extend test_merge() to allow the specification of multiple branches so
that octopus merges can be performed.
Signed-off-by: Denton Liu
Hello,
I think I have found a bug in the implementation of `git checkout
—recurse-submodules $branch` in the case of nested submodules. When I add a
submodule that has submodules in a feature branch of the main project, checkout
the master branch and then checkout my feature branch again, the
Patches 1-11 are largely unchanged from the original series with the
exception of 2, which is new and posted at:
https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
12-17 take further steps to get us away from hashmap_entry being
the first element, but they're also a bit ug
73558/git-with-client-certificates-failing-and-working-with-curl
I'm not sure if this is a bug with GIT or just something i'm not doing
correctly.
Thanks
[Cc-ing brian, because I can vaguely remember (or misremember?) that
he cares about GnuPG.]
On Mon, Sep 16, 2019 at 04:51:49PM -0700, Denton Liu wrote:
> I just wanted to report that t7030 is flaky. I first noticed this on
> Szeder's Travis job[1]. I was also able to reproduce this on my Macbook
>
Hello all,
I just wanted to report that t7030 is flaky. I first noticed this on
Szeder's Travis job[1]. I was also able to reproduce this on my Macbook
with gpg (GnuPG) 2.2.17 and git version 2.23.0.248.g3a9dd8fb08 (latest
master) by running `./t7030-verify-tag.sh --stress`.
I'll try to investiga
Hi,
I would like to report what I suspect is a bug in `git rebase -i`.
The problem in question is that when a `rebase -i` is run on a repo
which has had a subtree added with `git subtree add --prefix=xxx`
previously; the later command will be executed without the `--prefix`
argument, resulting
On Mon, Sep 09, 2019 at 03:01:32PM -0700, Junio C Hamano wrote:
> Sebastian Gniazdowski writes:
>
> > Hello,
> > if the password contains a hash, then it's impossible to clone a
> > repository, either with https or ssh protocols. I've had to use a
> > `gitg' GUI to clone such a repo.
>
> Hmph,
Sebastian Gniazdowski writes:
> Hello,
> if the password contains a hash, then it's impossible to clone a
> repository, either with https or ssh protocols. I've had to use a
> `gitg' GUI to clone such a repo.
Hmph, do you mean that
git clone https://user:passw...@hosting.site/repository
Hello,
if the password contains a hash, then it's impossible to clone a
repository, either with https or ssh protocols. I've had to use a
`gitg' GUI to clone such a repo.
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
B
On Thu, Aug 29, 2019 at 01:33:36PM -0400, randall.s.bec...@rogers.com wrote:
> I don't know whether this is new behaviour following changes to stash, but
> here goes.
>
> Suppose I have files a,b,c,d modified, but only file d is in the index.
> After stash push (or save) --include-untracked, sta
On Tue, 3 Sep 2019 07:51:54 +
Giuseppe Crinò wrote:
> On Mon, Sep 02, 2019 at 12:25:37PM -0700, Junio C Hamano wrote:
> > I'd rather leave the sleeping dog lie, if we need to encourage
> > people to live in 21st century and step outside US-ASCII to do so,
> > then do that instead.
>
> +1 t
On Mon, Sep 02, 2019 at 12:25:37PM -0700, Junio C Hamano wrote:
> I'd rather leave the sleeping dog lie, if we need to encourage
> people to live in 21st century and step outside US-ASCII to do so,
> then do that instead.
+1 to let the sleeping dog lie. When you say we should encourage people
to s
On Mon, 02 Sep 2019 12:25:37 -0700
Junio C Hamano wrote:
> Jeff King writes:
>
> > But it still risks losing a case where some code path relies on the crud
> > cleanup for odd cases (mismatched delimiters, or interleaved delimiters,
> > or non-delimiter crud mixed in with delimiters).
> > ...
>
Jeff King writes:
> But it still risks losing a case where some code path relies on the crud
> cleanup for odd cases (mismatched delimiters, or interleaved delimiters,
> or non-delimiter crud mixed in with delimiters).
> ...
> So I dunno. There is no patch to be discussed, and I am not volunteeri
> -Original Message-
> From: Philip Oakley
> Sent: September 2, 2019 11:56 AM
> To: 002901d55e8f$e4a4af70$adee0e50$@rogers.com;
> randall.s.bec...@rogers.com
> Cc: git@vger.kernel.org
> Subject: Re: [BUG} stash show does not show untracked files stashed
> (reposte
On 02/09/2019 14:01, Giuseppe Crinò wrote:
Suppose I have files a,b,c,d modified, but only file d is in the index.
After stash push (or save) --include-untracked, stash show only displays
file d. A subsequent pop will restore files a,b,c,d. So functionally push
and pop are fine, but stash show a
On Sat, Aug 31, 2019 at 01:17:48PM +, Giuseppe Crinò wrote:
> On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> > We'd still want to keep the low-level removal of "<>\n", since those are
> > syntactically significant to Git (i.e., if they sneak in you end up with
> > a broken commit
> Suppose I have files a,b,c,d modified, but only file d is in the index.
> After stash push (or save) --include-untracked, stash show only displays
> file d. A subsequent pop will restore files a,b,c,d. So functionally push
> and pop are fine, but stash show appears to ignores files in the stash.
On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> We'd still want to keep the low-level removal of "<>\n", since those are
> syntactically significant to Git (i.e., if they sneak in you end up with
> a broken commit object).
Would it work to change `strbuf_addstr_without_crud()` such th
I don't know whether this is new behaviour following changes to stash, but
here goes.
Suppose I have files a,b,c,d modified, but only file d is in the index.
After stash push (or save) --include-untracked, stash show only displays
file d. A subsequent pop will restore files a,b,c,d. So functional
On Wed, Aug 28, 2019 at 02:33:15PM +, Giuseppe Crino' wrote:
> On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> > But we'd still need something at least for
> > GECOS, where "Your Name" is common.
>
> As I understand this, those commas are *not* removed by
> strbuf_addstr_with
On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> But we'd still need something at least for
> GECOS, where "Your Name" is common.
As I understand this, those commas are *not* removed by
strbuf_addstr_without_crud(). Instead they're skipped from /etc/pass
-- see `ident.c/copy_gecos(
On Tue, 27 Aug 2019 13:51:49 +
"Giuseppe Crino'" wrote:
> On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> > So it might make sense to push these rules into "git mailinfo" instead
> > of applying them everywhere. But we'd still need something at least for
> > GECOS, where "Your Na
On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> So it might make sense to push these rules into "git mailinfo" instead
> of applying them everywhere. But we'd still need something at least for
> GECOS, where "Your Name" is common.
What's the GECOS you mean?
On Fri, Aug 23, 2019 at 10:29:00AM +0200, SZEDER Gábor wrote:
> On Fri, Aug 23, 2019 at 12:13:12AM +0530, Pratyush Yadav wrote:
> > > Does it make more sense to replace this strbuf_addstr_without_crud()
> > > setup with something more intelligent (i.e. checking for matching crud
> > > on either en
On Sat, Aug 24, 2019 at 05:49:52PM +, Giuseppe Crinò wrote:
> On Fri, Aug 23, 2019 at 10:29:00AM +0200, SZEDER Gábor wrote:
> > What I wonder is whether we really have to remove crud from the user
> > name if it comes from the configuration.
>
> Yes. If the primary use of removing crud is to r
On Fri, Aug 23, 2019 at 10:29:00AM +0200, SZEDER Gábor wrote:
> What I wonder is whether we really have to remove crud from the user
> name if it comes from the configuration.
Yes. If the primary use of removing crud is to remove quotes from a
quoted name (as in `From: 'Foo baz Bar'`) why not dire
Jeff King writes:
> ...
> --commit-filter '
> commit=$(git commit-tree "$@")
> git notes copy $GIT_COMMIT $commit
> echo $commit
> '
Thanks. I was writing the same "git notes copy $this $that" based
response, but TIL we had --stdin to fe
Jeff King writes:
> This started with 8a0fc8d19d (stash: convert apply to builtin,
> 2019-02-25), which is in v2.22.0. Interestingly, do_stash_apply() does
> in fact call refresh_cache(). But it looks like we don't ever write it
> out to disk. So when we later call merge_recursive(), it presumabl
SZEDER Gábor writes:
> ... However, once
> rebase stops for the 'edit' instruction the user can do just about
> anything, so I'm not sure how rebase could figure out when to copy the
> note and when not.
True.
> This doesn't happen when inserting a 'break' instruction between
> picking the "se
I noticed that somehow two commits on the same branch ended up with
the same note attached. I believe that this is the result of me using
interactive rebase's 'edit' instruction to insert new commits, and
then it copied the note from the edited commit to the commit from from
where I 'git rebase --
On Fri, Aug 23, 2019 at 11:35:48AM +0200, Giuseppe Crinò wrote:
> On Fri, Aug 23, 2019 at 10:29 AM SZEDER Gábor wrote:
> > If we go down this route, then someone might want to write ő as o" or
> > ű as u", which still supposed to be used in pairs, but what if someone
> > wants to write ä as a:, ö
On Fri, Aug 23, 2019 at 10:29 AM SZEDER Gábor wrote:
> If we go down this route, then someone might want to write ő as o" or
> ű as u", which still supposed to be used in pairs, but what if someone
> wants to write ä as a:, ö as o:, ü as u:, ç as "c,", ş as "s,", etc.
I don't know any language th
On Fri, Aug 23, 2019 at 12:13:12AM +0530, Pratyush Yadav wrote:
> > Does it make more sense to replace this strbuf_addstr_without_crud()
> > setup with something more intelligent (i.e. checking for matching crud
> > on either end, like ^[$crudchars].*\1$? We already check for matched <>.
>
> Sound
1 - 100 of 4624 matches
Mail list logo
