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
>
> Same comment as last time: s/use_atom/used_at
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
>> undesirable errors, hence, if present skip over
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 helps us
>> parse atom's before hand and store re
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 is
> that the revisions
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
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
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 H
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
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
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 n
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 ++--
> t/t5304-prune.sh |
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. In
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 som
.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 | 4 +++-
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 a/t/t5304-prune.sh b/t/t5304-prun
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 deletions(-)
diff --git a/built
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 report
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 still have a problem with the approach from "design cleanliness"
>>> point o
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" doesn'
(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, 2015 at 1:26 PM, Duy Nguyen wrote:
> On Thu, Dec
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, 2015 at 8:44 AM, Jeff King wrote:
> On Tue, De
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
following behaviour:
Tha
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
i
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 anoth
On Fri, Dec 18, 2015 at 09:50:46AM +0100, Torsten Bögershausen wrote:
> >> So the code would look like this:
> >>
> >>if (!poll(&pfd, 1, -1))
> >> return -1;
> >
> > That changes the semantics of the function. The poll() is just a
> > convenience to avoid spinning. If it fails, with Ste
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 narrowing this down!
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 since --preserve-merges f
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 past several weeks, I think; you would
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 inste
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:
>
> > Interdiff vs v1:
Whoo
> 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 f
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() retu
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 hard links, you need to run at least
>> one git co
33 matches
Mail list logo
