Re: [PATCH 2/5] ieot: default to not writing IEOT section

Stefan Beller writes: >> > +static int record_ieot(void) >> > +{ >> > + int val; >> > + >> >> Initialize stack val to zero to ensure proper default. > > I don't think that is needed here, as we only use `val` when > we first write to it via git_config_get_bool. Yup.

Re: [ANNOUNCE] Git v2.20.0-rc1

Elijah Newren writes: > If we don't set rebase.useBuiltin to false, then there is also a minor > regression in the error message printed by the built-in rebase we may > want to try to address. I have a patch for it at > <20181122044841.20993-2-new...@gmail.com>, but I don't know if that > patch

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

Stefan Beller writes: > Maybe we need to step back and consider what the command does. > And from that I would name it "rewire-HEAD-and-update-index" > and then simplify from there. For the beginner user, the concept of > HEAD might be overwhelming, such that we don't want to have that > in

Re: [PATCH v1/RFC 1/1] 'git clone C:\cygwin\home\USER\repo' is working (again)

On Mon, Nov 26, 2018 at 11:32 AM wrote: > This is the first vesion of a patch. > Is there a chance that you test it ? I can confirm that this fixes the issue. Thank you!

Re: Confusing behavior with ignored submodules and `git commit -a`

On Thu, Nov 15, 2018 at 4:31 PM Michael Forney wrote: > > On 2018-11-15, Stefan Beller wrote: > > On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote: > >> Well, currently the submodule config can be disabled in diff_flags by > >> setting override_submodule_config=1. However, I'm thinking it

Re: [ANNOUNCE] Git v2.20.0-rc1

Hi Ævar, On Mon, 26 Nov 2018, Johannes Schindelin wrote: > On Sat, 24 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > On Wed, Nov 21 2018, Junio C Hamano wrote: > > > > > * "git rebase" and "git rebase -i" have been reimplemented in C. > > > > Here's another regression in the C version (and

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

Stefan Beller writes: >> * sb/submodule-recursive-fetch-gets-the-tip (2018-10-31) 11 commits >> [...] >> >> "git fetch --recurse-submodules" may not fetch the necessary commit >> that is bound to the superproject, which is getting corrected. >> >> Is the discussion on this topic over? What

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Johannes Sixt writes: > Am 26.11.18 um 04:04 schrieb Junio C Hamano: >> >> That does not sound right. I would understand it if both lines >> showed ^M at the end, and only the one on the postimage line had it >> highlighted as a trailing-whitespace. > > I agree that this is a (small?) weakness.

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 26, 2018 at 8:01 AM Ævar Arnfjörð Bjarmason wrote: > > > On Tue, Nov 20 2018, Duy Nguyen wrote: > > > On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote: > >> I promise to come back with something better (at least it still > >> sounds better in my mind). If that idea does not

Re: [ANNOUNCE] Git v2.20.0-rc1

Hi Ævar, On Sat, 24 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > On Wed, Nov 21 2018, Junio C Hamano wrote: > > > * "git rebase" and "git rebase -i" have been reimplemented in C. > > Here's another regression in the C version (and rc1), note: the > sha1collisiondetection is just a stand in for

Re: [PATCH 2/5] ieot: default to not writing IEOT section

On Mon, Nov 26, 2018 at 1:48 PM Ben Peart wrote: > > > > On 11/26/2018 2:59 PM, Stefan Beller wrote: > >>> +static int record_ieot(void) > >>> +{ > >>> + int val; > >>> + > >> > >> Initialize stack val to zero to ensure proper default. > > > > I don't think that is needed here, as we only use

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

> > * sb/submodule-recursive-fetch-gets-the-tip (2018-10-31) 11 commits > [...] > > "git fetch --recurse-submodules" may not fetch the necessary commit > that is bound to the superproject, which is getting corrected. > > Is the discussion on this topic over? What was the outcome? Please don't

Re: [PATCH 2/5] ieot: default to not writing IEOT section

On 11/26/2018 2:59 PM, Stefan Beller wrote: +static int record_ieot(void) +{ + int val; + Initialize stack val to zero to ensure proper default. I don't think that is needed here, as we only use `val` when we first write to it via git_config_get_bool. Did you spot this via code

Re: [PATCH v2 0/9] diff --color-moved-ws fixes and enhancment

On Fri, Nov 23, 2018 at 3:17 AM Phillip Wood wrote: > > From: Phillip Wood > > Thanks to Stefan for his feedback on v1. I've updated patches 2 & 8 in > response to those comments - see the range-diff below for details (the > patch numbers are off by one in the range diff, I think because the >

Re: [PATCH v1 1/2] log -G: Ignore binary files

On Wed, Nov 21, 2018 at 1:08 PM Thomas Braun wrote: > > The -G option of log looks for the differences whose patch text > contains added/removed lines that match regex. > > The concept of differences only makes sense for text files, therefore > we need to ignore binary files when searching with

Re: [PATCH 2/5] ieot: default to not writing IEOT section

> > +static int record_ieot(void) > > +{ > > + int val; > > + > > Initialize stack val to zero to ensure proper default. I don't think that is needed here, as we only use `val` when we first write to it via git_config_get_bool. Did you spot this via code review and thought of defensive

Re: [PATCH] grep: use grep_opt->repo instead of explict repo argument

On Sun, Nov 18, 2018 at 8:38 AM Nguyễn Thái Ngọc Duy wrote: > > This command is probably the first one that operates on a repository > other than the_repository, in f9ee2fcdfa (grep: recurse in-process > using 'struct repository' - 2017-08-02). An explicit 'struct > repository *' was added in

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 26.11.18 um 04:04 schrieb Junio C Hamano: It appears to me that what Frank sees is not "^M highlighted for whitespace breakage appears only on postimage lines, while ^M is shown but not highlighted on preimage lines". My reading of the above is "Not just without highlight, ^M is just *NOT*

Re: Did You Receive My Last Mail?

Hello, My name is ms. Reem Al-Hashimi. The UAE minister of state for international cooparation. I got your contact from an email database from your country. I have a financial transaction i would like to discuss with you. Please reply to reem2...@daum.net, for more details if you are

Re: [PATCH v16 Part II 2/8] bisect--helper: `bisect_write` shell function in C

Hi Martin, On Fri, 23 Nov 2018, Martin Ågren wrote: > On Fri, 23 Nov 2018 at 11:13, Johannes Schindelin > wrote: > > On Mon, 30 Oct 2017, Pranit Bauva wrote: > > > > > On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren > > > wrote: > > > > On 27 October 2017 at 17:06, Pranit Bauva > > > >

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

On Sun, Nov 25, 2018 at 11:02:05AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I do also think in the long run we should be fixing the "unreachable > > always become loose" issues. > > I think I've seen an idea of collecting them into a garbage pack > floated for at least a few

Re: [PATCH v2 0/4] Port git-add--interactive.perl:status_cmd to C

Hi Daniel, On 16-May-17 6:00 AM, Daniel Ferreira wrote: This is the second version of a patch series to start porting git-add--interactive from Perl to C. Series: v1: https://public-inbox.org/git/1494009820-2090-1-git-send-email-bnm...@gmail.com/ Travis CI build:

Re: t5570 shaky for anyone ?

On Sun, Nov 25, 2018 at 11:22:47PM +0100, SZEDER Gábor wrote: > > The following fixes it, but I am not sure if this is the ideal > > solution. > > Currently this is the only test that looks at 'daemon.log', but if we > ever going to add another one, then that will be prone to the same > issue. >

Re: t5570 shaky for anyone ?

On Sun, Nov 25, 2018 at 10:01:38PM +, Thomas Gummerer wrote: > On 11/25, Torsten Bögershausen wrote: > > After running the "Git 2.20-rc1" testsuite here on a raspi, > > the only TC that failed was t5570. > > When the "grep" was run on daemon.log, the file was empty (?). > > When inspecting

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 26, 2018 at 5:01 PM Ævar Arnfjörð Bjarmason wrote: > > So, what do you think? > > That "git checkout" does too many things is something that keeps coming > up in online discussions about Git's UI. Two things: > > a) It would really help to have some comparison of cases where these >

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 12, 2018 at 11:22:09PM +, brian m. carlson wrote: > This is going to totally hose automation. My last job had files which > might move from tracked to untracked (a file that had become generated), > and long-running CI and build systems would need to be able to check out > one

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Tue, Nov 20 2018, Duy Nguyen wrote: > On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote: >> I promise to come back with something better (at least it still >> sounds better in my mind). If that idea does not work out, we can >> come back and see if we can improve this. > > So this

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason wrote: > >> >> How about something like this: > >> >> > >> >> 1. Introduce a concept with "garbage" files, which git is "permitted to > >> >> delete" without prompting. > >> >> > >> >> 2. Retain the current default, i.e. "ignored files are

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26 2018, Duy Nguyen wrote: > On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason > wrote: >> >> >> On Mon, Nov 26 2018, Duy Nguyen wrote: >> >> > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg >> > wrote: >> >> >> >> On 11/13/18 1:22 AM, brian m. carlson wrote: >> >> > This is

Re: [RFC PATCH 0/7] test: NetBSD support

On Sun, Nov 25 2018, Carlo Marcelo Arenas Belón wrote: > Likely still missing changes as it only completes a run with a minimal > number of dependencies but open for feedback > > Requires pkgsrc packages for gmake, perl, bash and curl and completes a run > > $ gmake

Re: [ANNOUNCE] Git v2.20.0-rc1

On Sun, Nov 25, 2018 at 11:37 PM Junio C Hamano wrote: > > Unless I hear otherwise in the next 24 hours, I am planning to > merge the following topics to 'master' before cutting -rc2. Please > stop me on any of these topics. > > - jc/postpone-rebase-in-c > >This may be the most

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason wrote: > > > On Mon, Nov 26 2018, Duy Nguyen wrote: > > > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote: > >> > >> On 11/13/18 1:22 AM, brian m. carlson wrote: > >> > This is going to totally hose automation. My last job had files

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 26, 2018 at 4:03 AM Junio C Hamano wrote: > > Thomas Gummerer writes: > > > I like the idea of splitting those commands up, in fact it is > > something I've been considering working on myself. I do think we > > should consider if we want to change the behaviour of those new > >

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26 2018, Duy Nguyen wrote: > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote: >> >> On 11/13/18 1:22 AM, brian m. carlson wrote: >> > This is going to totally hose automation. My last job had files which >> > might move from tracked to untracked (a file that had become

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote: > > On 11/13/18 1:22 AM, brian m. carlson wrote: > > This is going to totally hose automation. My last job had files which > > might move from tracked to untracked (a file that had become generated), > > and long-running CI and build systems

Re: git bash lunching error

On Mon, Nov 26, 2018 at 08:32:27PM +0530, Chandra Shekhar wrote: > cess: Resource temporarily unavailable (-1). > DLL rebasing may be required; see 'rebaseall / rebase --help'. This ? Please do not post screenshots, post text. Also please

Re: [RFC PATCH] Introduce "precious" file concept

Per Lundberg writes: > How about something like this: > ... > Would this be a reasonable compromise for everybody? I do not think you'd need to introduce such a deliberately breaking change at all. Just introduce a new "precious" class, perhaps mark them with the atttribute mechanism, and that

Re: [RFC PATCH] Introduce "precious" file concept

On Mon, Nov 26 2018, Per Lundberg wrote: > On 11/13/18 1:22 AM, brian m. carlson wrote: >> This is going to totally hose automation. My last job had files which >> might move from tracked to untracked (a file that had become generated), >> and long-running CI and build systems would need to be

Re: [RFC PATCH] Introduce "precious" file concept

On 11/13/18 1:22 AM, brian m. carlson wrote: > This is going to totally hose automation. My last job had files which > might move from tracked to untracked (a file that had become generated), > and long-running CI and build systems would need to be able to check out > one status and switch to the

Re: [PATCH v3 2/5] pretty: allow showing specific trailers

Anders Waldenborg writes: > Would it feel less inconsistent if it did not set the 'only_trailers' > option? If %(trailers:key=...) did not automatically imply 'only', it would be very consistent. But as I already said, I think it would be less convenient, as I do suspect that those who want

Re: [PATCH v11 00/22] Convert "git stash" to C builtin

Junio C Hamano writes: > Thomas Gummerer writes: > >> Thanks for your work on this! I have read through the range-diff and >> the new patch of this last round, and this addresses all the comments >> I had on v10 (and some more :)). I consider it >> Reviewed-by: Thomas Gummerer > > Thanks. >

Re: [ANNOUNCE] Git v2.20.0-rc1

Unless I hear otherwise in the next 24 hours, I am planning to merge the following topics to 'master' before cutting -rc2. Please stop me on any of these topics. - jc/postpone-rebase-in-c This may be the most controversial. It demotes the C reimplementation of "git rebase" to an

Re: [PATCH] doc: update diff-format.txt for removed ellipses in --raw

Greg Hurrell writes: > Since 7cb6ac1e4b ("diff: diff_aligned_abbrev: remove ellipsis after > abbreviated SHA-1 value", 2017-12-03), the "--raw" format of diff > does not add ellipses in an attempt to align the output, but the > documentation was not updated to reflect this. > > Signed-off-by:

Re: [PATCH v3 2/5] pretty: allow showing specific trailers

Junio C Hamano writes: > I was confused by the "only" stuff. > > When you give a key (or two), they cannot possibly name non-trailer > lines, so while it may be possible to ask "oh, by the way, I also > want non-trailer lines in addition to signed-off-by and cc lines", > the value of being able

Re: [RFC PATCH 7/7] config.mak.uname: use pkgsrc perl for NetBSD

Carlo Marcelo Arenas Belón writes: > otherwise will default to /usr/bin/perl which wouldn't normally exist > > Signed-off-by: Carlo Marcelo Arenas Belón > --- > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) I do not have experience with NetBSD so I take your words on face value.

Re: [RFC PATCH 6/7] t5004: use GNU tar to avoid known issues with BSD tar

Carlo Marcelo Arenas Belón writes: > 56ee96572a ("t5004: resurrect original empty tar archive test", 2013-05-09) > added a test to try to detect and workaround issues with the standard tar > from BSD, but at least in NetBSD would be better to instead require GNU tar > which is available from

Re: [RFC PATCH 5/7] test-lib: use pkgsrc provided unzip for NetBSD

Carlo Marcelo Arenas Belón writes: > d98b2c5fce ("test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/", > 2016-07-21) added an exception to the test suite for FreeBSD because the > tests assume functionality not provided by its base unzip tool. > > NetBSD shares that limitation and

Re: [RFC PATCH 4/7] config.mak.uname: NetBSD uses old iconv interface

Carlo Marcelo Arenas Belón writes: > prevents the following warning : s/^/Doing so / or something to make it a complete sentence. > ... > it is set by optional configure at least since NetBSD 6.0 s/it/It/; Again, makes sense, and thanks for tying this loose end. > Signed-off-by: Carlo

Re: [RFC PATCH 3/7] config.mak.uname: NetBSD uses BSD semantics with fread for directories

Carlo Marcelo Arenas Belón writes: > this "fixes" test 23 (proper error on directory "files") from t1308 > > other BSD (OpenBSD, MirBSD) likely also affected but they will be > fixed in a different series > > the optional 'configure' sets this automatically and is probably what > most users

Re: [RFC PATCH 2/7] t0301: remove trailing / for dir creation

Carlo Marcelo Arenas Belón writes: > the semantics of how mkdir -p should work, specially when using -m are > not standard and in this case NetBSD will assume that the permision > should not be changed, breaking the test This does not explain, except for the fuzzy "in this case", why we want

Re: [RFC PATCH 1/7] Documentation: update INSTALL for NetBSD

Carlo Marcelo Arenas Belón writes: > NetBSD added a BSD licensed reimplementation of GNU libintl to > its base at least since release 4.0 (mid 2012) and git can be > configured to build with it. > > Signed-off-by: Carlo Marcelo Arenas Belón > --- > INSTALL | 6 +++--- > 1 file changed, 3

[PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)

ions > serve as a canary for a larger list which we'd discover if we held off > for another major release (and would re-enable rebase.useBuiltin=true in > master right after 2.20 is out the door). > > I am fine with the proposed flip, but I'll have to see the extent of

Re: [PATCH v11 00/22] Convert "git stash" to C builtin

Thomas Gummerer writes: > Thanks for your work on this! I have read through the range-diff and > the new patch of this last round, and this addresses all the comments > I had on v10 (and some more :)). I consider it > Reviewed-by: Thomas Gummerer Thanks. One thing that bothers me is that

Re: [PATCH v11 20/22] stash: convert `stash--helper.c` into `stash.c`

Paul-Sebastian Ungureanu writes: > The old shell script `git-stash.sh` was removed and replaced > entirely by `builtin/stash.c`. In order to do that, `create` and > `push` were adapted to work without `stash.sh`. For example, before > this commit, `git stash create` called `git stash--helper

Re: [PATCH] files-backend.c: fix build error on Solaris

Carlo Arenas writes: > Signed-off-by: Carlo Marcelo Arenas Belón Do you mean Tested-by: (meaning, you actually saw the breakage with SunCC without the patch and also saw the patch fixed the breakage)? > clang with -Wpedantic also catch this (at least with Apple LLVM > version 10.0.0); recent

Re: [PATCH] setup.c: remove needless argument passed to open in sanitize_stdfds

pedrodel...@gmail.com writes: > According to POSIX manual pages, the open() system call's mode > argument specifies the file mode bits to be applied when a new > file is created. If neither O_CREAT nor O_TMPFILE is specified, > then mode is ignored. Correct. While I would say two argument

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Johannes Sixt writes: > But incorrect whitespace is never highlighted in removed lines, why > should CR be an exception? > ... > Same here for other cases, for example > > -something > +something > > will not have on obvious indicator that whitespace was corrected. All correct, but misses one

Re: [PATCH v3 2/5] pretty: allow showing specific trailers

Anders Waldenborg writes: > Junio C Hamano writes: >> Also, use of 'key=' automatically turns on 'only' as described, and >> I tend to agree that it would a convenient default mode (i.e. when >> picking certain trailers only with this mechanism, it is likely that >> the user is willing to use

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

Thomas Gummerer writes: > I like the idea of splitting those commands up, in fact it is > something I've been considering working on myself. I do think we > should consider if we want to change the behaviour of those new > commands in any way compared to 'git checkout', since we're starting >

Re: [PATCH] http-backend: enable cleaning up forked upload/receive-pack on exit

Max Kirillov writes: > If http-backend dies because of errors, started upload-pack or > receive-pack are not killed and waited, but rather stay running for somtime "sometime" (will fix locally, no reason for a resend). > until they exits because of closed stdin. It may be undesirable in

Re: [PATCH] t5562: do not reuse output files

Max Kirillov writes: > On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: >> I do agree that forcing the parent to wait, like you described in >> the comment, would be far more preferrable, > > It looks like it can be done as simple as: > > --- a/http-backend.c > +++

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

On Sun, Nov 25, 2018 at 03:03:11PM +0100, Frank Schäfer wrote: > Am 24.11.18 um 23:07 schrieb Johannes Sixt: > > I don't think that there is anything to fix. If you have a file with > > CRLF in it, but you did not declare to Git that CRLF is the expected > > end-of-line indicator, then the CR *is*

Re: [PATCH v3 2/5] pretty: allow showing specific trailers

Junio C Hamano writes: > Also, use of 'key=' automatically turns on 'only' as described, and > I tend to agree that it would a convenient default mode (i.e. when > picking certain trailers only with this mechanism, it is likely that > the user is willing to use %(subject) etc. to fill in what

Re: t5570 shaky for anyone ?

On Sun, Nov 25, 2018 at 09:52:23PM +0100, Torsten Bögershausen wrote: > After running the "Git 2.20-rc1" testsuite here on a raspi, > the only TC that failed was t5570. > When the "grep" was run on daemon.log, the file was empty (?). > When inspecting it later, it was filled, and grep would have

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On 11/20, Duy Nguyen wrote: > On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote: > > I promise to come back with something better (at least it still > > sounds better in my mind). If that idea does not work out, we can > > come back and see if we can improve this. > > So this is it. The

Re: t5570 shaky for anyone ?

On 11/25, Torsten Bögershausen wrote: > After running the "Git 2.20-rc1" testsuite here on a raspi, > the only TC that failed was t5570. > When the "grep" was run on daemon.log, the file was empty (?). > When inspecting it later, it was filled, and grep would have found > the "extended.attribute"

Re: [PATCH v11 00/22] Convert "git stash" to C builtin

On 11/23, Paul-Sebastian Ungureanu wrote: > Hello, > > This is the 11th iteration of C git stash. Here are some of the changes, > based on Thomas's and dscho's suggestions (from mailing list / pull request > #495): Thanks for your work on this! I have read through the range-diff and the new

Re: [PATCH v11 03/22] strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`

On 11/23, Paul-Sebastian Ungureanu wrote: > Implement `strbuf_insertf()` and `strbuf_vinsertf()` to > insert data using a printf format string. > > Original-idea-by: Johannes Schindelin > Signed-off-by: Paul-Sebastian Ungureanu > --- > strbuf.c | 36 >

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 25.11.18 um 15:03 schrieb Frank Schäfer: Am 24.11.18 um 23:07 schrieb Johannes Sixt: I don't think that there is anything to fix. If you have a file with CRLF in it, but you did not declare to Git that CRLF is the expected end-of-line indicator, then the CR *is* trailing whitespace (because

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

be initialized like this: */ >> char c = *path; >> >> if (has_dos_drive_prefix(path)) >> return 0; >> >> goto inside; >> /* Q2: and why do we need the "goto" here ? */ >> for (;;) { >> if (!c) >>

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 24.11.18 um 23:07 schrieb Johannes Sixt: > I don't think that there is anything to fix. If you have a file with > CRLF in it, but you did not declare to Git that CRLF is the expected > end-of-line indicator, then the CR *is* trailing whitespace (because > the line ends at LF), and 'git diff'

Re: [PATCH] files-backend.c: fix build error on Solaris

On Sun, Nov 25, 2018 at 11:19 AM Carlo Arenas wrote: > > Signed-off-by: Carlo Marcelo Arenas Belón > > clang with -Wpedantic also catch this (at least with Apple LLVM > version 10.0.0); recent versions of gcc also include that flag and at > least 8.2.0 shows a warning for it, so it might be

Re: [PATCH] files-backend.c: fix build error on Solaris

Signed-off-by: Carlo Marcelo Arenas Belón clang with -Wpedantic also catch this (at least with Apple LLVM version 10.0.0); recent versions of gcc also include that flag and at least 8.2.0 shows a warning for it, so it might be worth adding it to developer mode (maybe under the pedantic DEVOPTS),

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

inside; > /* Q2: and why do we need the "goto" here ? */ > for (;;) { > if (!c) > return 1; > if (is_dir_sep(c)) { > inside: After some re-reading, I think that the "goto inside" was just hard to

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

On Sat, Nov 24, 2018 at 08:33:37PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote: > > > On Wed, Sep 05 2018, Eric Sunshine wrote: [] > > SunCC used to be ahead of GCC & Clang when it came to certain classes of > > warnings, but e.g. now everything

Re: git overwriting local ignored files?

On 11/24/18 10:41 AM, Konstantin Khomoutov wrote: On Sat, Nov 24, 2018 at 05:57:24PM +0300, Konstantin Khomoutov wrote: On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote: It seems that git is overwriting my local files on merge if they're in .gitignore. [...] The .gitignore

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

Jeff King writes: > I do also think in the long run we should be fixing the "unreachable > always become loose" issues. I think I've seen an idea of collecting them into a garbage pack floated for at least a few times here. What are the downsides? We no longer will know when these unreachable

Re: [PATCH v3 3/8] refs: new ref types to make per-worktree refs visible to all worktrees

Ævar Arnfjörð Bjarmason writes: > On Sun, Oct 21 2018, Nguyễn Thái Ngọc Duy wrote: > > This change has a regression in 2.20: > >> [...] >> static void files_reflog_path(struct files_ref_store *refs, >>struct strbuf *sb, >>const char

Re: How to efficiently backup a bare repository?

Ævar Arnfjörð Bjarmason writes: > There's no easy out of the box way to do exactly what you've > described. A few things come to mind: > ... Wouldn't it suffice to have a cron job that runs something like D=$(date +"%Y-%m-%d") git fetch $serving "refs/*:refs/backup-$D/*" on

Re: [ANNOUNCE] Git v2.20.0-rc1

version should we be considering reverting 5541bd5b8f ("rebase: default to using the builtin rebase", 2018-08-08)? I love the feature, but fear that the current list of known regressions serve as a canary for a larger list which we'd discover if we held off for another maj

Re: How to efficiently backup a bare repository?

On Fri, Nov 23 2018, Guilhem Bonnefille wrote: > I'm managing many bare repositories for development teams. > > One service we want to offer is to let developers retrieve old state > of the repository up to 30 days. For example, one developer > (accidently) removed (push -f) a branch/tag and

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 24.11.18 um 15:51 schrieb Frank Schäfer: Am 23.11.18 um 22:47 schrieb Johannes Sixt: Am 23.11.18 um 19:19 schrieb Frank Schäfer: The CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF. It shows up as expected in '-' lines when the ending of the

Re: [ANNOUNCE] Git v2.20.0-rc1

On Wed, Nov 21 2018, Junio C Hamano wrote: > * "git rebase" and "git rebase -i" have been reimplemented in C. Here's another regression in the C version (and rc1), note: the sha1collisiondetection is just a stand in for "some repo": ( rm -rf /tmp/repo && git init

Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

uts /opt/csw/gnu in its $PATH, so this whole thing is probably > a non-issue. I.e. if the near-as-you-can-get "official" package just > compiles git against GNU tooling, perhaps we should stop caring about > Solaris-native tooling. > > That does also mean that something like

Re: [PATCH v3 3/8] refs: new ref types to make per-worktree refs visible to all worktrees

On Sun, Oct 21 2018, Nguyễn Thái Ngọc Duy wrote: This change has a regression in 2.20: > [...] > static void files_reflog_path(struct files_ref_store *refs, > struct strbuf *sb, > const char *refname) > @@ -158,6 +178,9 @@ static void

Re: git overwriting local ignored files?

On Sat, Nov 24, 2018 at 05:57:24PM +0300, Konstantin Khomoutov wrote: > On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote: > > > > > It seems that git is overwriting my local files on merge if they're in > > > > .gitignore. > [...] > > > The .gitignore file is to list "ignored and

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

On Sat, Nov 24, 2018 at 03:51:26PM +0100, Frank Schäfer wrote: [] > > Hmm... is CR-only line termination supported at all ? > E.g. 'eol' can be set to 'lf' or 'crlf' but not 'cr'... > No, CR-only is not supported, because: Nobody was implementing it, and that is probably because the only

Re: git overwriting local ignored files?

On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote: > > > It seems that git is overwriting my local files on merge if they're in > > > .gitignore. [...] > > The .gitignore file is to list "ignored and expendable" class of > > files; there is no "ignored but precious class" in Git. >

Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

Am 23.11.18 um 22:47 schrieb Johannes Sixt: > Am 23.11.18 um 19:19 schrieb Frank Schäfer: >> The CR marker ^M doesn't show up in '-' lines of diffs when the ending >> of the removed line is CR+LF. >> It shows up as expected in '-' lines when the ending of the removed line >> is CR only. >> It also

Re: git overwriting local ignored files?

On 11/23/18 11:22 PM, Junio C Hamano wrote: David Mandelberg writes: It seems that git is overwriting my local files on merge if they're in .gitignore. See command transcript below. I searched `git help config` and Google, but I couldn't find any way to prevent it. Am I missing something?

Re: [PATCH] t5562: do not reuse output files

On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: > I do agree that forcing the parent to wait, like you described in > the comment, would be far more preferrable, It looks like it can be done as simple as: --- a/http-backend.c +++ b/http-backend.c @@ -486,6 +486,8 @@ static void

Re: [PATCH] t5562: do not reuse output files

On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: > I do agree that forcing the parent to wait, like you described in > the comment, would be far more preferrable, [...] Stray processes can sometimes have funny effects on an outer test harness, too. E.g., I think I've seen hangs

Re: [PATCH] t5562: fix perl path

On Fri, Nov 23, 2018 at 01:38:21AM +0200, Max Kirillov wrote: > From: Jeff King > > Some systems do not have perl installed to /usr/bin. Use the variable > from the build settiings, and call perl directly than via shebang. > > Signed-off-by: Max Kirillov > --- > Submitting. Could you

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

complete list. And has been loading it for some time. So if you run > > "git-fetch", for example, you've already been running this code for > > months (and using the cache in more places is now a free speedup). > > This is reminding me that I need to get around to re-submitting

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

On Sat, Nov 24, 2018 at 11:11:36AM +0900, Junio C Hamano wrote: > > However, note that the cache-load for finding abbreviations _must_ have > > the complete list. And has been loading it for some time. So if you run > > "git-fetch", for example, you've already been running this code for > >

Re: [PATCH 1/2] format-patch: add a more exhaustive --range-diff test

On Sat, Nov 24 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Change the narrow test added in 31e2617a5f ("format-patch: add >> --range-diff option to embed diff in cover letter", 2018-07-22) to >> test the full output. This test would have spotted a regression in the >>

Re: [PATCH] t5562: do not reuse output files

On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > a better workaround might be to write into unique output filenames > (act1.out, act2.out, etc.); that way, you do not have to worry about > the output file for the next request getting clobbered by a stale

Re: [PATCH] t5562: do not reuse output files

Junio C Hamano writes: > Max Kirillov writes: > >> diff --git a/t/t5562-http-backend-content-length.sh >> b/t/t5562-http-backend-content-length.sh >> index 90d890d02f..bb53f82c0c 100755 >> --- a/t/t5562-http-backend-content-length.sh >> +++ b/t/t5562-http-backend-content-length.sh >> @@ -25,6

Re: [PATCH] t5562: do not reuse output files

Max Kirillov writes: > diff --git a/t/t5562-http-backend-content-length.sh > b/t/t5562-http-backend-content-length.sh > index 90d890d02f..bb53f82c0c 100755 > --- a/t/t5562-http-backend-content-length.sh > +++ b/t/t5562-http-backend-content-length.sh > @@ -25,6 +25,8 @@ test_http_env() { >

Re: git overwriting local ignored files?

David Mandelberg writes: > It seems that git is overwriting my local files on merge if they're in > .gitignore. See command transcript below. I searched `git help config` > and Google, but I couldn't find any way to prevent it. Am I missing > something? (The reason I care about ignored files is

<    1   2   3   4   5   6   7   8   9   10   >