[PATCH] credential-cache: interpret an ECONNRESET as on EOF

Since commit 612c49e94d ("credential-cache: add tests for XDG functionality", 17-03-2017), the cygwin build has been failing all the new tests added by that commit. In particular, the 'git credential-cache exit' command, as part of the test cleanup code, has been die-ing with the message:

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

Heh, then I'll forward my response and we are even ;-) -- Forwarded message -- From: Junio C Hamano Date: Mon, Jul 10, 2017 at 10:48 AM Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS? To: Michael Haggerty

Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

On Wed, Jul 26, 2017 at 4:42 PM, brian m. carlson wrote: > On Wed, Jul 26, 2017 at 04:29:58PM -0700, Jonathan Tan wrote: >> This is an updated version of my previous patch [1], but without the >> list of promises. It is somewhat different now because fsck cannot just

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

Dang, I just noticed that I hit "reply" rather than "reply-to-all" on the below email (stupid GMail default). Junio, your response to this email accordingly went only to me. Michael -- Forwarded message -- From: Michael Haggerty Date: Mon, Jul 10, 2017 at

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

Hi, Michael Haggerty wrote: > One of the tricks that `contrib/workdir/git-new-workdir` plays is to > making `packed-refs` in the new workdir a symlink to the `packed-refs` > file in the original repository. Before > 42dfa7ecef ("commit_packed_refs(): use a staging file separate from > the

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

On Wed, Jul 26, 2017 at 4:39 PM, Michael Haggerty wrote: > One of the tricks that `contrib/workdir/git-new-workdir` plays is to > making `packed-refs` in the new workdir a symlink to the `packed-refs` > file in the original repository. Before > 42dfa7ecef

Re: [PATCHv2] builtin/blame: highlight interesting things

On Wed, Jul 26, 2017 at 4:29 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When using git-blame lots of lines contain redundant information, for >> example in hunks that consist of multiple lines, the metadata (commit name, >> author) are repeated.

Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile

I just submitted a patch [1] that fixes the `packed-refs`-is-a-symlink problem in combination with git-new-workdir. I haven't considered any possible problems related to `core.preferSymlinkRefs`. That behavior should be unaffected by the packed-ref-store patch series and I'm not very interested

Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

On Wed, Jul 26, 2017 at 04:29:58PM -0700, Jonathan Tan wrote: > This is an updated version of my previous patch [1], but without the > list of promises. It is somewhat different now because fsck cannot just > mark all promised objects as HAS_OBJ. > > This could be adapted and incorporated into

[PATCH] packed_ref_store: handle a packed-refs file that is a symlink

One of the tricks that `contrib/workdir/git-new-workdir` plays is to making `packed-refs` in the new workdir a symlink to the `packed-refs` file in the original repository. Before 42dfa7ecef ("commit_packed_refs(): use a staging file separate from the lockfile", 2017-06-23), a lockfile was used as

[RFC PATCH 0/4] Some patches for fsck for missing objects

This is an updated version of my previous patch [1], but without the list of promises. It is somewhat different now because fsck cannot just mark all promised objects as HAS_OBJ. This could be adapted and incorporated into patch sets that have objects missing from the local repo. I split this up

[RFC PATCH 3/4] fsck: support referenced lazy objects

Teach fsck to not treat missing objects indirectly pointed to by refs as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan --- builtin/fsck.c | 11 +++ t/t0410-lazy-object.sh | 27 +++ 2 files changed, 38

[RFC PATCH 2/4] fsck: support refs pointing to lazy objects

Teach fsck to not treat refs with missing targets as an error when extensions.lazyobject is set. For the purposes of warning about no default refs, such refs are still treated as legitimate refs. Signed-off-by: Jonathan Tan --- builtin/fsck.c | 8

[RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

Currently, Git does not support repos with very large numbers of objects or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the user operates mostly on part of the repo, because Git is designed on the assumption that every

[RFC PATCH 4/4] fsck: support lazy objects as CLI argument

Teach fsck to not treat missing objects provided on the CLI as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan --- builtin/fsck.c | 2 ++ t/t0410-lazy-object.sh | 16 2 files changed, 18 insertions(+) diff --git

Re: [ANNOUNCE] Git v2.14.0-rc1

On Mon, Jul 24, 2017 at 03:44:23PM -0700, Junio C Hamano wrote: > A release candidate Git v2.14.0-rc1 is now available for testing > at the usual places. It is comprised of 708 non-merge commits > since v2.13.0, contributed by 61 people, 14 of which are new faces. > > The tarballs are found at:

Re: [PATCHv2] builtin/blame: highlight interesting things

Stefan Beller writes: > When using git-blame lots of lines contain redundant information, for > example in hunks that consist of multiple lines, the metadata (commit name, > author) are repeated. A reader may not be interested in those, so darken > (commit, author)

[PATCHv2] builtin/blame: highlight interesting things

When using git-blame lots of lines contain redundant information, for example in hunks that consist of multiple lines, the metadata (commit name, author) are repeated. A reader may not be interested in those, so darken (commit, author) information that is the same as in the previous line. Choose

Re: Change in output as a result of patch

Kaartic Sivaraam writes: > b347d06bf09 (branch: deprecate --set-upstream and show help if we detect > possible mistaken use, > Thu Aug 30 19:23:13 2012) > > Is there any possibility for it to be removed some time in the near > future? > > I'm asking

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

Junio C Hamano writes: > Hmph, this is interesting. > > "git rebase" does take "--rerere-autoupdate" option from the command > line, and propagates it to a later invocation of "rebase --continue" > by storing the value to $state_dir/allow_rerere_autoupdate file and > reading

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

Junio C Hamano writes: > Phillip Wood writes: > >> From: Phillip Wood >> >> These patches add an '--autostage' option (and corresponding config >> variable) to 'rebase --continue' that will stage any unstaged changes >>

Re: [PATCH 09/15] submodule: remove submodule_config callback routine

Brandon Williams writes: > Remove the last remaining caller of 'submodule_config()' as well as the > function itself. > > With 'submodule_config()' being removed the submodule-config API can be > a little simpler as callers don't need to worry about whether or not > they need

Re: [PATCH 03/15] add, reset: ensure submodules can be added or reset

Stefan Beller writes: > On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: >> Commit aee9c7d65 (Submodules: Add the new "ignore" config option for >> diff and status) ... > > introduced in 2010, so quite widely spread. > >> ... introduced the ignore

Re: [PATCH] submodule: correct error message for missing commits.

Stefan Beller writes: > We _do_ show the submodule as demonstrated by the code sample above > if we possess the objects. > ... >> That sounds like a very sensible and user-centric behaviour to me, >> and "not initialized" sounds like the right message to give in such >> a

Re: [PATCH 02/15] submodule: don't use submodule_from_name

Stefan Beller writes: > Rereading the archives, there was quite some discussion on the design > of these patches, but these lines of code did not get any attention > > https://public-inbox.org/git/4cdb3063.5010...@web.de/ > > I cc'd Jens in the hope of him having a good

Re: [PATCH 01/15] t7411: check configuration parsing errors

Brandon Williams writes: > Check for configuration parsing errors in '.gitmodules' in t7411, which > is explicitly testing the submodule-config subsystem, instead of in > t7400. Also explicitly use the test helper instead of relying on the > gitmodules file from being read in

Re: [PATCH] submodule: correct error message for missing commits.

On Wed, Jul 26, 2017 at 1:30 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When a submodule diff should be displayed we currently just add the >> submodule objects to the main object store and then e.g. walk the >> revision graph and create a

Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions

Raman Gupta writes: > On 26/07/17 02:05 PM, Junio C Hamano wrote: >> I haven't tried this patch, but would this work well with options >> meant for the 'git rev-list --parents "$@"' that grabs the list of >> merge commits to learn from? e.g. >> >> $

Re: [PATCHv2] t8008: rely on rev-parse'd HEAD instead of sha1 value

Stefan Beller writes: > Remove hard coded sha1 values, obtain the values using > 'git rev-parse HEAD' which should be future proof regardless > of the hash function used. > > Additionally future-proof the test by hard coding the > abbreviation length of the hash. > >

Re: [PATCH] submodule: correct error message for missing commits.

Stefan Beller writes: > When a submodule diff should be displayed we currently just add the > submodule objects to the main object store and then e.g. walk the > revision graph and create a summary for that submodule. > > It is possible that we are missing the submodule

Re: [PATCH/RFC] setup: update error message to be more meaningful

Jonathan Nieder writes: > For an initial guess: in the example > > git grep test -n > > ... > 2. Focus on "argument" instead of "filename" so that the message > could still apply: something like > > fatal: option '-n' must come before non-option arguments I

[PATCH] submodule: correct error message for missing commits.

When a submodule diff should be displayed we currently just add the submodule objects to the main object store and then e.g. walk the revision graph and create a summary for that submodule. It is possible that we are missing the submodule either completely or partially, which we currently

Re: [PATCH for NEXT v3 0/2] sub-process: refactor handshake to common function

Jonathan Tan writes: > Thanks for all your comments. > > This is now built off "next" to include Lars's changes. > > About whether this is too restrictive (for example, as Junio mentions, > this will not allow future capabilities of the form "key=???"), I think > that

Re: [PATCH] recursive submodules: detach HEAD from new state

Stefan Beller writes: > So I took a step back and wrote about different proposals where > we want to go long term. See below. This will help us > figuring out how to approach this bug correctly. Thanks for writing this. > RFC: A new type of symbolic refs > > A symbolic ref

[PATCH v3] contrib/rerere-train: optionally overwrite existing resolutions

Provide the user an option to overwrite existing resolutions using an `--overwrite` flag. This might be used, for example, if the user knows that they already have an entry in their rerere cache for a conflict, but wish to drop it and retrain based on the merge commit(s) passed to the rerere-train

[PATCHv2] t8008: rely on rev-parse'd HEAD instead of sha1 value

Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD' which should be future proof regardless of the hash function used. Additionally future-proof the test by hard coding the abbreviation length of the hash. Signed-off-by: Stefan Beller --- > Don't

Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions

On 26/07/17 02:05 PM, Junio C Hamano wrote: > I haven't tried this patch, but would this work well with options > meant for the 'git rev-list --parents "$@"' that grabs the list of > merge commits to learn from? e.g. > > $ contrib/rerere-train.sh -n 4 --merges master > $

Re: What's cooking in git.git (Jul 2017, #07; Mon, 24)

Johannes Schindelin writes: >> * wd/rebase-conflict-guide (2017-07-17) 1 commit >> (merged to 'next' on 2017-07-20 at c78e758b23) >> + rebase: make resolve message clearer for inexperienced users >> >> Code clean-up. > > This is not a code clean-up. It is an

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

Phillip Wood writes: > From: Phillip Wood > > These patches add an '--autostage' option (and corresponding config > variable) to 'rebase --continue' that will stage any unstaged changes > before continuing. This saves the user having to

[PATCH for NEXT v3 0/2] sub-process: refactor handshake to common function

Thanks for all your comments. This is now built off "next" to include Lars's changes. About whether this is too restrictive (for example, as Junio mentions, this will not allow future capabilities of the form "key=???"), I think that this can be upgraded later if necessary. For now, both the

[PATCH for NEXT v3 2/2] sub-process: refactor handshake to common function

Refactor, into a common function, the version and capability negotiation done when invoking a long-running process as a clean or smudge filter. This will be useful for other Git code that needs to interact similarly with a long-running process. As you can see in the change to t0021, this commit

[PATCH for NEXT v3 1/2] Documentation: migrate sub-process docs to header

Move the documentation for the sub-process API from a separate txt file to its header file. Signed-off-by: Jonathan Tan --- Documentation/technical/api-sub-process.txt | 59 - sub-process.h | 25 +++- 2

Re: [PATCH] sub-process: refactor handshake to common function

Lars Schneider writes: > Please note that I've recently refactored the capabilities negotiation a bit: > https://github.com/git/git/commit/1514c8edd62d96006cd1de31e906ed5798dd4681 > > This change is still cooking in `next`. I am not sure how this should/could > be

Re: Reducing redundant build at Travis?

Lars Schneider writes: > ... I started > to work on a patch that moves all TravisCI logic into scripts located > in the `ci` folder. These scripts share a `lib-travisci.sh` for common > functions such as `skip_branch_tip_with_tag ()` executed at the > beginning of

Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions

Raman Gupta writes: > Provide the user an option to overwrite existing resolutions using an > `--overwrite` flag. This might be used, for example, if the user knows > that they already have an entry in their rerere cache for a conflict, > but wish to drop it and retrain

Re: [PATCH v1 0/4] Teach 'run' perf script to read config files

On Wed, Jul 26, 2017 at 05:58:09PM +0200, Christian Couder wrote: > Actually after taking another look at that, it looks like the following > happens: > > 1) the run script sources the original GIT-BUILD-OPTIONS file from > ../.. relative to its location > 2) a git version is built in

Re: [PATCH] sub-process: refactor handshake to common function

> On 24 Jul 2017, at 23:38, Jonathan Tan wrote: > > Refactor, into a common function, the version and capability negotiation > done when invoking a long-running process as a clean or smudge filter. > This will be useful for other Git code that needs to interact

Re: [PATCH] git-gui (MinGW): make use of MSys2's msgfmt

> On 25 Jul 2017, at 10:35, Johannes Schindelin > wrote: > > When Git for Windows was still based on MSys1, we had no gettext, ergo > no msgfmt, either. Therefore, we introduced a small and simple Tcl > script to perform the same task. > > However, with MSys2, we

Re: Reducing redundant build at Travis?

> On 21 Jul 2017, at 18:44, Junio C Hamano wrote: > > Lars Schneider writes: > >> To answer your question: I don't see an easy solution to the problem. > > That's OK. Thanks for digging. > > I am wondering if the attached would be acceptable as

Re: [PATCH v1 0/4] Teach 'run' perf script to read config files

On Fri, Jul 14, 2017 at 8:27 AM, Christian Couder wrote: > On Thu, Jul 13, 2017 at 10:55 PM, Jeff King wrote: >> On Thu, Jul 13, 2017 at 08:57:01PM +0200, Christian Couder wrote: >> >>> >> We want to make it possible to store the parameters to the 'run'

Re: git gc seems to break --symbolic-full-name

26.07.2017 16:23, Jeff King пишет: In git.git we do something like: -- >8 -- other: version cat $< >$@ .PHONY: FORCE version: FORCE @git rev-parse HEAD >$@+ @if cmp $@+ $@ >/dev/null 2>&1; then rm $@+; else mv $@+ $@; fi -- >8 -- Yes, thats a nice recipe that I would

Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users

On 24/07/17 21:53, Junio C Hamano wrote: Phillip Wood writes: git rebase --continue requiring one to git add first confuses/annoys me too. I started a patch to autostage unstaged changes if they don't contain conflict markers a couple of weeks ago, I'll clean it up

Re: git gc seems to break --symbolic-full-name

On Wed, Jul 26, 2017 at 11:40:46AM +0300, Stas Sergeev wrote: > 26.07.2017 03:36, Jacob Keller пишет: > > If your goal is to make it so users filling out bug reports have a > > version, then using git descrsibe and making that be part of your > > version (based off your tags, and commits) is how

[PATCH] remote: split and simplify messages

Splitting a single sentence across multiple lines could degrade readability. Further, long messages are likely to be ignored by users. Split the sentences and simplify it to improve their readability. Signed-off-by: Kaartic Sivaraam --- remote.c

Re: [PATCH] fsck: cleanup unused variable

On Tue, Jul 25, 2017 at 06:34:56PM -0700, Jonathan Tan wrote: > Remove the unused variable "heads" from cmd_fsck(). > > This variable was made unused in commit c3271a0 ("fsck: do not fallback > "git fsck " to "git fsck"", 2017-01-17). Thanks, I should have caught this then. The patch is

Re: [PATCH/RFC] setup: update error message to be more meaningful

Hello Jonathan Nieder, Thanks for the reply! Jonathan Nieder wrote: > > > The error message shown when a flag is found when expecting a > > filename wasn't clear as it didn't communicate what was wrong > > using the 'suitable' words in *all* cases. > > > > Correct case, > > > > $ git

[RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

From: Phillip Wood These patches add an '--autostage' option (and corresponding config variable) to 'rebase --continue' that will stage any unstaged changes before continuing. This saves the user having to type 'git add' before running 'git rebase --continue'.

[RFC PATCH 5/5] Add rebase.continue.autostage config setting

From: Phillip Wood This enables the user to always specify --autostage with --continue The tests check that setting rebase.continue.autostage=true results in 'git rebase --continue' autostaging unstaged changes and that '--no-autostage' overrides it. Signed-off-by:

[RFC PATCH 4/5] Add tests for rebase --continue --autostage

From: Phillip Wood Make sure that --autostage stages any changes and fails if there are merge markers in the file to be staged. Signed-off-by: Phillip Wood --- t/t3418-rebase-continue.sh | 35 ++- 1 file

[RFC PATCH 2/5] rebase -i: improve --continue --autostage

From: Phillip Wood If HEAD has changed since the rebase stopped or rebase stopped due to a failed exec then 'git rebase --continue --autostage' will autostage changes that cannot be commited. Fix this by reordering some of the checks so that 'git rebase --continue

[RFC PATCH 1/5] rebase --continue: add --autostage to stage unstaged changes

From: Phillip Wood After resolving conflicts during a rebase it is a pain to have to run 'git add' before 'git rebase --continue'. Passing --autostage to 'git rebase --continue' will stage them automatically so long as 'git diff --check' says they are ok. This is a

[RFC PATCH 3/5] Unify rebase amend message when HEAD has changed

From: Phillip Wood If rebase --interactive is unable to commit staged changes because HEAD has changed since rebase stopped the user gets different messages depending on whether they specified --autostage or not. Update the messages in the other code paths to match

Loan Offer@2%

I am a private Lender Daniel Jones located in USA, Are You In Need Of A Private Or Business Loans from $5,000.00 to $10.000.000.00 At 2% Rate For Various Purposes? If Yes; Contact us Via Email: 3231...@gmail.com Names... Amount($)... Country Tel... Duration...

Urgent reply needed,

Dear Partner, Please consider this mail serious despite the fact that you did not expect it. Hope you are doing well. I am Mr.Alimuji Gabratai, the Manager of head opérations department of our bank in Burkina Faso. I discovered a risk-free deal of US$9.9 million from my department which was left

Re: git gc seems to break --symbolic-full-name

26.07.2017 03:36, Jacob Keller пишет: If your goal is to make it so users filling out bug reports have a version, then using git descrsibe and making that be part of your version (based off your tags, and commits) is how pretty much every other project I've worked on does this. I really don't

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

Jeff King writes: > Hrm. That doesn't quite work, though. Because if your are the > merge, then merging a topic to next will get an "A" that is a merge > commit from next. But that commit will never end up in master. What's > causing the conflict is really some "A" that is

[PATCH v4] merge: add a --signoff flag.

Some projects require every commit, even merges, to be signed off [*1*]. Because "git merge" does not have a "--signoff" option like "git commit" does, the user needs to add one manually when the command presents an editor to describe the merge, or later use "git commit --amend --signoff". Help

Re: [PATCH v3] merge: add a --signoff flag.

lukaszgryglicki writes: >>> +--signoff:: >>> + Add Signed-off-by line by the committer at the end of the commit >>> + log message. The meaning of a signoff depends on the project, >>> + but it typically certifies that committer has >>> + the rights to submit this

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

Jeff King writes: > From the user's perspective, calling X "rerere" would probably be OK[1]. > But from an implementation perspective (and to keep the existing > plumbing available and unchanged), it probably makes sense to call it > something else, and have it run both rerere and