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

On Mon, Nov 26, 2018 at 11:23 PM Junio C Hamano wrote: > Sorry, but I do not see the connection to this question and the > above example. The reason why we strip C: is because the letter > that comes after that colon determines if we are talking about > absolute path (in other words, the current

Re: [PATCH] pack-protocol.txt: accept error packets in any context

Masaya Suzuki writes: > In the Git pack protocol definition, an error packet may appear only in > a certain context. However, servers can face a runtime error (e.g. I/O > error) at an arbitrary timing. This patch changes the protocol to allow > an error packet to be sent instead of any packet.

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

Steven Penny writes: > If you strip the drive, you can still navigate within the same drive: > > $ cd 'C:\Users' > $ pwd > /cygdrive/c/Users > > $ cd '\Windows' > $ pwd > /cygdrive/c/Windows > > but you can no longer traverse drives: > > $ cd '\Testing' > sh: cd:

[PATCH] pack-protocol.txt: accept error packets in any context

In the Git pack protocol definition, an error packet may appear only in a certain context. However, servers can face a runtime error (e.g. I/O error) at an arbitrary timing. This patch changes the protocol to allow an error packet to be sent instead of any packet. Following this protocol spec

Re: [RFC PATCH v2] Add 'human' date format

On Saturday, July 7, 2018 3:02:35 PM MST Linus Torvalds wrote: > From: Linus Torvalds > > This adds --date=human, which skips the timezone if it matches the > current time-zone, and doesn't print the whole date if that matches (ie > skip printing year for dates that are "this year", but also

From Mr.Frank Yacouba

With due respect, Please forgive me for stressing you with my business as I know that this letter may come to you as big surprise. Truly, I came across your contact email address through my personal search, then afterward I decided to email you directly believing that you will be honest to help

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

On Mon, Nov 26, 2018 at 7:16 PM Junio C Hamano wrote: > I wonder if it makes the rest of the code simpler if we stripped > things like /cygdrive/c here exactly the sam way as we strip C: > For that, has_dos_drive_prefix() needs to know /cygdrive/[a-z], > which may not be a bad thing, I guess.

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

tbo...@web.de writes: > Reported-By: Steven Penny > Signed-off-by: Torsten Bögershausen > --- > > This is the first vesion of a patch. > Is there a chance that you test it ? > > abspath.c | 2 +- > compat/cygwin.c | 18 ++ > compat/cygwin.h | 32

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

Stefan Beller writes: > 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

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

[PATCH] t/lib-git-daemon: fix signal checking

Test scripts checking 'git daemon' stop the daemon with a TERM signal, and the 'stop_git_daemon' helper checks the daemon's exit status to make sure that it indeed died because of that signal. This check is bogus since 03c39b3458 (t/lib-git-daemon: use test_match_signal, 2016-06-24), for two

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

[PATCH] transport-helper.c: do not translate a string twice

Signed-off-by: Nguyễn Thái Ngọc Duy --- My bad. transport-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transport-helper.c b/transport-helper.c index 7213fa0d32..bf225c698f 100644 --- a/transport-helper.c +++ b/transport-helper.c @@ -573,7 +573,7 @@ static int

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*

[PATCH v2 1/2] Introduce "precious" file concept

A new attribute "precious" is added to indicate that certain files have valuable content and should not be easily discarded even if they are ignored or untracked. So far there are two parts of Git that are made aware of precious files: "git clean" will leave precious files alone and

[PATCH v2 2/2] unpack-trees: support core.allIgnoredFilesArePreciousWhenMerging

Ignored files can be marked precious to prevent being overwritten during a merge (or even a branch switch). If you really want to make sure no ignored files are overwritten, this config variable is for you. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config/core.txt | 6 ++

[PATCH v2 0/2] Precios files round two

Let's see if I can make everybody almost happy with this. Patch 1 is not that much different from round one except now with tests. It is still about "precious" attributes that prevent content loss with "git clean", "git checkout " or "git merge". Patch 2 goes Ævar and Per are pursuing. It adds

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

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

From: Torsten Bögershausen A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as

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

git bash lunching error

cess: Resource temporarily unavailable (-1). DLL rebasing may be required; see 'rebaseall / rebase --help'.

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