[PATCH 1/3] Add --gui option to mergetool

This fixes the discrepancy between difftool and mergetool where the former has the --gui flag and the latter does not by adding the functionality to mergetool. Signed-off-by: Denton Liu --- Documentation/git-mergetool.txt| 8 +++-

Re: [PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper

On Fri, Mar 03, 2017 at 12:16:31PM +0100, Johannes Schindelin wrote: > > What is "dir"? I'm guessing this patch got reordered and it should stay > > as cwd.buf? > > Oh drats. Usually I do a final `git rebase -x "make test" upstream/master` > run before submitting, but I was really, really tired

[PATCH/RFC 2/2] merge-recursive: Handle rename/rename/delete/delete conflicts.

On a rename 2to1 conflict, where both a and b are renamed to c, the other branch may have deleted a or b. This currently luckily works for files but fails for symlinks. Fix conflict_rename_rename_2to1 to not merge_file_special_markers() with diff_filespecs where mode == 0. The alternative would

[PATCH 1/2] t6042: Add failing test for rename/rename/delete/delete.

Each side of a rename 2to1 could also be deleted by the other side. The code does not expect this. While it luckily works for files, it fails for symlinks as follow: CONFLICT (rename/rename): Rename a->c in HEAD. Rename b->c in C^0 Renaming a to c~HEAD and b to c~C^0 instead error: cannot read

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 01:46:10PM -0800, Brandon Williams wrote: > There were a few of us discussing this sort of approach internally. We > also figured that, given some performance hit, you could maintain your > repo in sha256 and do some translation to sha1 if you need to push or > fetch to a

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 03, 2017 at 04:42:51PM +0700, Nguyễn Thái Ngọc Duy wrote: > If a directory is given as a config file by accident, we keep open it > as a file. The behavior of fopen() in this case seems to be > undefined. > > On Linux, we open a directory as a file ok, then get error (which we >

Re: [PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper

Hi Peff, On Thu, 2 Mar 2017, Jeff King wrote: > On Fri, Mar 03, 2017 at 03:04:07AM +0100, Johannes Schindelin wrote: > > > It is okay in practice to test for forward slashes in the output of > > getcwd(), because we go out of our way to convert backslashes to > > forward slashes in getcwd()'s

lening bieden

Goede dag,   Het is ons een genoegen om u te schrijven ten aanzien van het geven van leningen via e-mail advertentie. GLASGOW CREDIT UNION, We opereren onder een korte, duidelijke en begrijpelijke termen en voorwaarden Wij geven leningen tegen een lage rente van 3%. Beste lezers moeten er

[PATCH v2] Travis: also test on 32-bit Linux

From: Johannes Schindelin When Git v2.9.1 was released, it had a bug that showed only on Windows and on 32-bit systems: our assumption that `unsigned long` can hold 64-bit values turned out to be wrong. This could have been caught earlier if we had a Continuous

[PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

It does not make sense for these placeholder scripts to depend on Python just because the real scripts do. At the example of Git for Windows, we would not even be able to see those warnings as it does not ship with Python. So just use plain shell scripts instead. Signed-off-by: Sebastian

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 3, 2017 at 5:15 PM, Jeff King wrote: > But I do think option (a) is cleaner. The only trick is that for errno > to be valid, we need to make sure we check ferror() soon after seeing > the EOF return value. I suspect it would work OK in practice for the >

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 03, 2017 at 05:29:47PM +0700, Duy Nguyen wrote: > On Fri, Mar 3, 2017 at 5:15 PM, Jeff King wrote: > > But I do think option (a) is cleaner. The only trick is that for errno > > to be valid, we need to make sure we check ferror() soon after seeing > > the EOF return

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 03, 2017 at 05:15:03AM -0500, Jeff King wrote: > But I do think option (a) is cleaner. The only trick is that for errno > to be valid, we need to make sure we check ferror() soon after seeing > the EOF return value. I suspect it would work OK in practice for the >

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 03, 2017 at 05:06:57PM +0700, Duy Nguyen wrote: > > But if we do, I think we'd either want to: > > > >a. actually check ferror() after getting EOF and report the read > > error. That catches EISDIR, along with any other unexpected > > errors. > > > >

[PATCH 0/2] Improve error messages when opening a directory as file

The topic nd/conditional-config-include hit a problem on Windows [1]. The test basically does this (much simplified) echo '[include]path=foo' >~/.gitconfig cd ~ && git init foo At some point in 'git init' after 'foo' directory has been created, we request to include ~/foo as an extra

Re: [PATCH 1/2] config: check if config path is a file before parsing it

On Fri, Mar 3, 2017 at 4:53 PM, Jeff King wrote: > I'm mildly negative on this approach for two reasons: > > 1. It requires doing an _extra_ check anywhere we want to care about > this. So if we care about file/directory confusion, we're going to > sprinkle these

Re: [PATCH v7 0/3] Conditional config include

On Fri, Mar 03, 2017 at 01:33:29AM -0500, Jeff King wrote: > For those following on the mailing list, there is some discussion at: > > https://github.com/git/git/commit/484f78e46d00c6d35f20058671a8c76bb924fb33 > > I think that is mostly focused around another failing in the > error-handling of

[PATCH 1/2] config: check if config path is a file before parsing it

If a directory is given as a config file by accident, we keep open it as a file. The behavior of fopen() in this case seems to be undefined. On Linux, we open a directory as a file ok, then get error (which we consider eof) on the first read. So the config parser sees this "file" as empty (i.e.

[PATCH 2/2] attr.c: check if .gitattributes is a file before parsing it

Similar to the previous patch, this is about better error messages when .gitattributes happens to be a directory. FWIW .gitignore code is also checked. There open() is used instead and open("dir") does not fail on Linux. But the next read should fail with EISDIR, which is a pretty good clue

Re: [PATCH 4/4] p7000: add test for filter-branch with --prune-empty

On Thu, Feb 23, 2017 at 02:27:36AM -0600, Devin J. Pohly wrote: > +test_perf 'noop prune-empty' ' > + git checkout --detach tip && > + git filter-branch -f --prune-empty base..HEAD > +' I don't mind adding this, but of curiosity, does it show anything interesting? -Peff

Re: [PATCH v2 5/9] Make read_early_config() reusable

On Fri, Mar 03, 2017 at 03:04:20AM +0100, Johannes Schindelin wrote: > The pager configuration needs to be read early, possibly before > discovering any .git/ directory. > > Let's not hide this function in pager.c, but make it available to other > callers. > [...] > + * Note that this is a

[PATCH] t/perf: add fallback for pre-bin-wrappers versions of git

On Fri, Mar 03, 2017 at 02:14:03AM -0500, Jeff King wrote: > With this patch I was able to run p0001 against v1.7.0. I don't think we > can go further back than that because the perf library depends on the > presence of bin-wrappers. That's probably enough. Unlike the t/interop > library I

Re: [PATCH v2 4/9] Export the discover_git_directory() function

On Fri, Mar 03, 2017 at 03:04:15AM +0100, Johannes Schindelin wrote: > The function we introduced earlier needs to return both the path to the > .git/ directory as well as the "cd-up" path to allow > setup_git_directory() to retain its previous behavior as if it changed > the current working

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

On Thu, Mar 02, 2017 at 11:36:18AM -0800, Junio C Hamano wrote: > "Devin J. Pohly" writes: > > > I think your point is interesting too, though. If a commit is also > > TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems > > reasonable that someone might want to

Re: git push - 401 unauthorized

On Tue, Feb 07, 2017 at 09:47:45PM +0100, Alessio Rocchi wrote: > I try to push my commit on a private repository (which has been working > since about five years). It wasn't clear to me from your email, but did this work with a previous version of Git and is now broken? >

<    1   2