Re: [PATCH v3 2/2] difftool: implement the functionality in the builtin

W dniu 24.11.2016 o 21:55, Johannes Schindelin pisze: > The current version of the builtin difftool does not, however, make full > use of the internals but instead chooses to spawn a couple of Git > processes, still, to make for an easier conversion. There remains a lot > of room for improvement,

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

W dniu 25.11.2016 o 04:14, Jeff King pisze: > On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > > Cc: # 4.4+ Looks like git send-email is not able to parse this address correctly though this is suggested format by

Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)

W dniu 24.11.2016 o 00:21, Junio C Hamano pisze: > * nd/rebase-forget (2016-10-28) 1 commit > - rebase: add --forget to cleanup rebase, leave HEAD untouched > > "git rebase" learned "--forget" option, which allows a user to > remove the metadata left by an earlier "git rebase" that was >

[feature request] Make "commit --only" work with new files

Hello, currently "git commit --only " only works if is already checked into the repo, but not with newly created and still untracked files (builtin/commit.c:list_path() throws the error "error: pathspec '' did not match any file(s) known to git.") I don't think this limitation is intented. I've

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Fri, Nov 25, 2016 at 06:41:23PM +0100, Johannes Schindelin wrote: > > Ah, I didn't realize that was a requirement. If this is going to be part > > of a release and real end-users are going to see it, that does make me > > think the config option is the better path (than the presence of some >

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

Hi Peff, On Fri, 25 Nov 2016, Jeff King wrote: > On Fri, Nov 25, 2016 at 12:05:00PM +0100, Johannes Schindelin wrote: > > > > I would have expected it to just be a build-time flag, like: > > > > > > make BUILTIN_DIFFTOOL=Yes test > > > > That works for Git developers. > > > > I want to let

[PATCH v2] date-formats.txt: Typo fix

Last time I checked, I was living in the UTC+01:00 time zone. UTC+02:00 would be Central European _Summer_ Time. --- Documentation/date-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index

[PATCH] date-formats.txt: Typo fix

Last time I checked, I was living in the UTC+01:00 time zone. UTC+02:00 would be Central European _Summer_ Time. --- Documentation/date-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index

Re: [PATCH v2] merge-recursive.c: use string_list_sort instead of qsort

On Fri, Nov 25, 2016 at 07:15:15PM +0700, Duy Nguyen wrote: > > I guess I haven't used string_list_sort() in a while, but I was > > surprised to find that it just feeds the strings to the comparator. That > > makes sense for using a raw strcmp() as the comparator, but I wonder if > > any callers

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Fri, Nov 25, 2016 at 12:05:00PM +0100, Johannes Schindelin wrote: > > I would have expected it to just be a build-time flag, like: > > > > make BUILTIN_DIFFTOOL=Yes test > > That works for Git developers. > > I want to let as many users as possible test the builtin difftool. > Hopefully a

Re: [PATCH 0/2] Fix segmentation fault with cherry-pick

Hi, On Fri, 25 Nov 2016, Johannes Schindelin wrote: > The culprit is actually not cherry-pick, but a special code path that > expects refresh_cache_entry() not to return NULL. And the fix is to > teach it to handle NULL there. > > This bug was brought to my attention by Markus Klein via >

[PATCH 2/2] Avoid a segmentation fault with renaming merges

Under very particular circumstances, merge-recursive's `add_cacheinfo()` function gets a `NULL` returned from `refresh_cache_entry()` without expecting it, and subsequently passes it to `add_cache_entry()` which consequently crashes. Let's not crash. This fixes

[PATCH 1/2] cherry-pick: demonstrate a segmentation fault

In https://github.com/git-for-windows/git/issues/952, a complicated scenario was described that leads to a segmentation fault in cherry-pick. It boils down to a certain code path involving a renamed file that is dirty, for which `refresh_cache_entry()` returns `NULL`, and that `NULL` not being

[PATCH 0/2] Fix segmentation fault with cherry-pick

The culprit is actually not cherry-pick, but a special code path that expects refresh_cache_entry() not to return NULL. And the fix is to teach it to handle NULL there. This bug was brought to my attention by Markus Klein via https://github.com/git-for-windows/git/issues/952. Johannes

Re: [PATCH v8 07/10] convert: unify the "auto" handling of CRLF

RFH, the normalization as descrived in Documentation/gitattributes.txt does not work anymore: >From a clean working directory: - $ echo "* text=auto" >.gitattributes $ rm .git/index # Remove the index to force Git to $ git reset #

Re: [PATCH 0/3] Minor fixes on 'git worktree'

On Fri, Nov 25, 2016 at 7:24 PM, Duy Nguyen wrote: > Adding the test for the failed parse_ref() is possible, I think. But > since that function is destined to die, as I promised to use > refs-provided api instead of rolling out a custom ref parser, and I'm > going to have

Re: [PATCH 0/3] Minor fixes on 'git worktree'

On Wed, Nov 23, 2016 at 11:52 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> This fixes two things: >> >> - make sure the first item is always the main worktree even if we >>fail to retrieve some info >> >> - keep 'worktree list' order

Re: [PATCH 3/3] worktree list: keep the list sorted

On Thu, Nov 24, 2016 at 12:16 AM, Junio C Hamano wrote: > More importantly, perhaps get_worktrees() should learn to take an > optional pointer to int that returns how many items are in the list? My first thought was "yeah I remember there are many counting loop like this" then

Re: [PATCH v2] merge-recursive.c: use string_list_sort instead of qsort

On Fri, Nov 25, 2016 at 3:52 AM, Jeff King wrote: > On Thu, Nov 24, 2016 at 06:45:36PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> This started out to as a hunt for remaining qsort() calls after rs/qsort >> series because qsort() API is a bit easy to get wrong (*). However, >> since we

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

Hi Peff, On Thu, 24 Nov 2016, Jeff King wrote: > On Thu, Nov 24, 2016 at 10:56:23PM +0100, Johannes Schindelin wrote: > > > > I think it would probably be OK to ship with that caveat (people would > > > probably use --global config, or "git -c" for a quick override), but if > > > you really