Re: [PATCHv2 2/7] xread: poll on non blocking fds

On 18.12.15 04:13, Jeff King wrote: > On Thu, Dec 17, 2015 at 09:42:01PM +0100, Torsten Bögershausen wrote: > >>> Or do you mean to insert another continue in here? >> I was thinking that we run into similar loop as before: >> read() returns -1; errno = EAGAIN /* No data to read */ >> poll()

Re: [PATCH v2 10/10] dir: do not use untracked cache ident anymore

On Thu, Dec 17, 2015 at 7:33 PM, Junio C Hamano wrote: > Christian Couder writes: > >> In the "git worktree" documentation there is: >> >> "If you move a linked working tree to another file system, or within a >> file system that does not support

Re: [PATCH v2] mingw: emulate write(2) that fails with a EPIPE

Hi Junio, On Thu, 17 Dec 2015, Junio C Hamano wrote: > PLEASE DON'T DO THE BELOW TO THE SAME MESSAGE AS THE PATCH ITSELF. > "git apply" would not read and understand the next line as a natural > language sentence for obvious reasons. > > Johannes Schindelin writes:

Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

> On the other hand, I've marked a handful of topics below as "Will > discard". They were all dormant after waiting for updates for quite > a long time; interested people may want to help resurrect them. > * sg/pretty-more-date-mode-format (2015-10-07) 1 commit > - pretty: add format specifiers

Re: (unknown)

Patrick Steinhardt writes: > On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote: >> David Greene writes: >> >> > - If new option --keep-redundant is specified, invoke cherry-pick with >> > --keep-redundant-commits. >> >> This came up in the

Re: [PATCHv2 2/7] xread: poll on non blocking fds

On Fri, Dec 18, 2015 at 09:50:46AM +0100, Torsten Bögershausen wrote: > >> So the code would look like this: > >> > >>if (!poll(, 1, -1)) > >> return -1; > > > > That changes the semantics of the function. The poll() is just a > > convenience to avoid spinning. If it fails, with

Re: Odd rebase behavior

John Keeping writes: > It seems that the problem is introduces by --preserve-merges (and > -Xsubtree causes something interesting to happen as well). I see the > following behaviour: Thanks for narrowing this down! Is it possible this is actually a cherry-pick problem

Re: Help debugging git-svn

Ok I came up with another idea to avoid having to deal with the old svn history (I'm having no problems fetching/dcommitting with my current repo). I already have the branches I work with, the thing is that the revisions I fetched before I started using the svn authors file have nasty IDs

Re: Odd rebase behavior

On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > John Keeping writes: > > > It seems that the problem is introduces by --preserve-merges (and > > -Xsubtree causes something interesting to happen as well). I see the > > following behaviour: > > Thanks for

git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

Not sure for what batch operations that file is actually useful, but the story is that if we have a shared git repo (I know -- might not be as common of a situation but possible and allowed to happen), then if one from the shared group commits within that repository, it becomes impossible for

[PATCH 2/3] t5304: Add test for .bitmap garbage files

When checking for pack garbage, .bitmap files are now detected as garbage when not associated with another .pack/.idx file. Signed-off-by: Doug Kelly --- t/t5304-prune.sh | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git

[PATCH 3/3] gc: Clean garbage .bitmap files from pack dir

Similar to cleaning up excess .idx files, clean any garbage .bitmap files that are not otherwise associated with any .idx/.pack files. Signed-off-by: Doug Kelly --- builtin/gc.c | 12 ++-- t/t5304-prune.sh | 2 +- 2 files changed, 11 insertions(+), 3

[PATCH v3 0/3] prepare_packed_git(): find more garbage

Corrects the issues found in review by Peff, including simplifying the logic in report_helper(). bits_to_msg() would've been an alternate solution to that change, however it'll get called by real_report_garbage(), so there's no need to call it twice, especially when the check we need within

[PATCH 1/3] prepare_packed_git(): find more garbage

.bitmap and .keep files without .idx/.pack don't make much sense, so make sure these are reported as garbage as well. At the same time, refactoring report_garbage to handle extra bits. Signed-off-by: Doug Kelly --- builtin/count-objects.c | 16 ++-- cache.h

Re: [PATCH 3/3] gc: Clean garbage .bitmap files from pack dir

On Fri, Dec 18, 2015 at 06:06:40PM -0600, Doug Kelly wrote: > Similar to cleaning up excess .idx files, clean any garbage .bitmap > files that are not otherwise associated with any .idx/.pack files. > > Signed-off-by: Doug Kelly > --- > builtin/gc.c | 12 ++-- >

Re: [RFC] Malicously tampering git metadata?

On Tue, Dec 15, 2015 at 10:26:39PM -0500, Santiago Torres wrote: > 4) The developer pushes to upstream. All the traffic can be re-routed > back to the original repository. The target branch now contains a > vulnerable piece of code. I assume you are assuming here that the "push to upstream"

Re: [PATCH 7/8] config: add core.untrackedCache

On Thu, Dec 17, 2015 at 1:36 PM, Duy Nguyen wrote: > On Wed, Dec 16, 2015 at 4:53 AM, Ævar Arnfjörð Bjarmason > wrote: >> On Tue, Dec 15, 2015 at 8:40 PM, Junio C Hamano wrote: >>> Ævar Arnfjörð Bjarmason writes: >>> I

Forcing git to pack objects

Hi! Recently I was running manually a git gc --prune command (wanted to shrink my 2.8G .git directory by getting rid of loose objects) and I ended up running out of space on my HD. After freaking out a little bit (didn't know if the repo would end up in a 'stable' state), I ended up freeing up

[PATCH] do_compare_entry: use already-computed path

In traverse_trees, we generate the complete traverse path for a traverse_info. Later, in do_compare_entry, we used to go do a bunch of work to compare the traverse_info to a cache_entry's name without computing that path. But since we already have that path, we don't need to do all that work.

Re: [PATCH v3 0/3] prepare_packed_git(): find more garbage

On Fri, Dec 18, 2015 at 06:06:37PM -0600, Doug Kelly wrote: > Corrects the issues found in review by Peff, including simplifying > the logic in report_helper(). bits_to_msg() would've been an alternate > solution to that change, however it'll get called by > real_report_garbage(), so there's no

Re: [PATCH v3 0/3] prepare_packed_git(): find more garbage

On Fri, Dec 18, 2015 at 09:02:47PM -0500, Jeff King wrote: > I left a few comments on 3/3. I don't think it's _wrong_, but I think we > can be a bit more thorough (and IMHO, a little more maintainable, but > others might disagree). Oh, and I forgot to say thank you for working on this. :) -Peff

Fwd: [PATCH 7/8] config: add core.untrackedCache

(Sorry I sent this one privately to Duy by mistake too.) -- Forwarded message -- From: Christian Couder Date: Fri, Dec 18, 2015 at 11:35 PM Subject: Re: [PATCH 7/8] config: add core.untrackedCache To: Duy Nguyen On Thu, Dec 17,

Re: Odd rebase behavior

Am 18.12.2015 um 19:05 schrieb John Keeping: On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: John Keeping writes: It seems that the problem is introduces by --preserve-merges (and -Xsubtree causes something interesting to happen as well). I see the

Fwd: [PATCH 7/8] config: add core.untrackedCache

Sorry I sent this privately to Peff by mistake (once again). -- Forwarded message -- From: Christian Couder Date: Fri, Dec 18, 2015 at 11:09 PM Subject: Re: [PATCH 7/8] config: add core.untrackedCache To: Jeff King On Thu, Dec 17,

Re: [PATCH v2] mingw: emulate write(2) that fails with a EPIPE

Am 17.12.2015 um 18:08 schrieb Johannes Schindelin: On Windows, when writing to a pipe fails, errno is always EINVAL. However, Git expects it to be EPIPE. According to the documentation, there are two cases in which write() triggers EINVAL: the buffer is NULL, or the length is odd but the mode

Re: [PATCH 1/2] gitk: match ttk fonts to gitk fonts

On Tue, Dec 08, 2015 at 08:05:50AM +0100, Giuseppe Bilotta wrote: > The fonts set in setoptions aren't consistently picked up by ttk, who > uses its own predefined fonts. This is noticeable when switching > between using and not using ttk with custom fonts or in HiDPI settings > (where the default

Re: [PATCH v3] gitk: add -C commandline parameter to change path

On Mon, Nov 09, 2015 at 01:45:22PM +0200, Juha-Pekka Heikkila wrote: > This patch adds -C (change working directory) parameter to > gitk. With this parameter, instead of need to cd to directory > with .git folder, one can point the correct folder from > commandline. > > Signed-off-by: Juha-Pekka

Re: [PATCH] gitk: sv.po: Update Swedish translation (311t)

Thanks, applied. Paul. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/11] ref-filter: introduce struct used_atom

On Thu, Dec 17, 2015 at 2:27 AM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak wrote: >> Introduce the 'used_array' structure which would replace the existing >> implementation of 'used_array' (which a list of atoms). This

Re: [PATCH v2 05/11] ref-filter: skip deref specifier in match_atom_name()

On Thu, Dec 17, 2015 at 2:41 AM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak wrote: >> In upcoming patches we make calls to match_atom_name() with the '*' >> deref specifier still attached to the atom name. This causes >>

Re: [PATCH v2 06/11] ref-filter: introduce color_atom_parser()

On Thu, Dec 17, 2015 at 2:51 AM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak wrote: >> Introduce color_atom_parser() which will parse a "color" atom and >> store its color in the "use_atom" structure for further usage in

Re: [RFPR] updates for 2.7?

On Tue, Dec 15, 2015 at 03:09:44PM -0800, Junio C Hamano wrote: > Git 2.7-rc1 has just been tagged, and the remainder of the year will > be for the stabilization, fixes to brown-paper-bag bugs, reverts of > regressions, etc., but I haven't seen updates to the various > subsystems you guys maintain

Re: Help debugging git-svn

On Fri, Dec 18, 2015 at 11:28 AM, Edmundo Carmona Antoranz wrote: > Ok I came up with another idea to avoid having to deal with the > old svn history (I'm having no problems fetching/dcommitting with my > current repo). I already have the branches I work with, the thing