On Tue, Apr 22, 2014 at 05:58:10PM +1000, Bryan Turner wrote:
> It looks like the documentation for bitmaps is being included in the
> 1.9.2 release of Git for Windows but the functionality itself is not
> present. For example, doc\git\html\git-config.html includes settings
> like these:
>
> pack
>
> * jx/blame-align-relative-time (2014-04-22) 2 commits
> - blame: dynamic blame_date_width for different locales
> - blame:: fix broken time_buf paddings in relative timestamp
Should substitute the double colons (in blame::) with one.
>
> "git blame" miscounted number of columns needed to s
On Wed, Apr 23, 2014 at 1:56 AM, Karsten Blees wrote:
> Am 22.04.2014 12:35, schrieb Duy Nguyen:
>> On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen wrote:
IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so
hopefully you did a dummy 'cache_name_exists("anything")' before sta
On Apr 22, 2014, at 16:17, Jeff King wrote:
but I do not think that is necessarily any more readable, especially
because we probably need to cast it like:
self->rlw = (eword_t *)((uint8_t *)self->buffer + rlw_offset);
I suspect that will produce a warning about a cast increasing pointer
ali
Commit 26cd160 (rebase -i: use a better reflog message) tried to produce
a better reflog message, however, it seems a statement was introduced by
mistake.
'comment_for_reflog start' basically overides the GIT_REFLOG_ACTION we
just set.
Signed-off-by: Felipe Contreras
---
git-rebase--interactive
On Tue, Apr 22, 2014 at 03:53:02PM -0700, Kyle J. McKay wrote:
> So I was trying to use pack.writebitmaps=true and all I got was core dumps.
Eek.
> The fix with a real subject line ;) is below. I think perhaps this should be
> picked up for the 2.0.0 release. (Patch is against master.)
Yes, t
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch has passed v2.0.0-rc0, an early
preview release. There are a handful of topics still in 'next' (and
a few that a
"Kyle J. McKay" writes:
> So I was trying to use pack.writebitmaps=true and all I got was core dumps.
>
> The fix with a real subject line ;) is below. I think perhaps this should be
> picked up for the 2.0.0 release. (Patch is against master.)
Of course---a breakage in a new code may be less
So I was trying to use pack.writebitmaps=true and all I got was core dumps.
The fix with a real subject line ;) is below. I think perhaps this should be
picked up for the 2.0.0 release. (Patch is against master.)
--Kyle
>8
Subject: [PATCH] ewah_bitmap.c: do not assume size_t and ewor
"brian m. carlson" writes:
> On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote:
>> Another possibility would be to require Perl 5.8.9 or newer. It was
>> released in 2008.
>
> RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still
> security-supported until 2017, and be
On Tue, Apr 22, 2014 at 12:11 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> diff --git a/refs.c b/refs.c
>> index 138ab70..9daf89e 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -3414,12 +3414,12 @@ int ref_transaction_commit(struct ref_transaction
>> *transaction,
>>
I will look at this once i finish the next respin.
On Tue, Apr 22, 2014 at 12:34 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> This patch series changes most of the places where the ref functions for
>> locking and writing refs to instead use the new ref transaction API. There
>> are
On Tue, 22 Apr 2014, Theodore Ts'o wrote:
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probab
On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote:
> Another possibility would be to require Perl 5.8.9 or newer. It was
> released in 2008.
RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still
security-supported until 2017, and believe it or not people still
develop o
Felipe Contreras writes:
> Theodore Ts'o wrote:
>
>> This is especially true for commands which might not be used as often
>> -- e.g., "rebase", and for commands where the meaning of "git commit"
>> without any argument is qualitatively different from what "ci" (for
>> checkin) means in most othe
On 18. 4. 2014 14:28, Jens Lehmann wrote:
> Am 13.04.2014 01:41, schrieb Ronald Weiss:
>> Second, there are some differences between adding standard ignored
>> files, and ignored submodules:
>>
>> 1) Already tracked files are never ignored, regardless of .gitignore.
>> However, tracked submodules
Matthieu Moy writes:
> Felipe Contreras writes:
>
>> Why is not material for v2.0? Because you say so? Are you going to wait
>> another
>> ten years to introduce this to v3.0?
>
> There's no need to wait for a 3.0 to introduce this. If these would
> be low-priority compared to user-defined alia
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The documentation says
>>
>> --prefix=
>>
>> ...
>>
>> Before Git 2.0, the default prefix was "" (no prefix).
>> This meant that ...
>>
>> which suggests that I can use --prefix="" to mean no prefix. P
Theodore Ts'o wrote:
> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
> > > I am not fundamentally opposed. I just do not think it would add
> > > much value to new people at this point, and it will actively hurt
> > > if we shoved barely cooked one in 2.0.
> >
> > You are prob
Junio C Hamano writes:
> I am not fundamentally opposed. I just do not think it would add
> much value to new people at this point, and it will actively hurt
> if we shoved barely cooked one in 2.0.
>
> A few thinking points that are necessary to be worked out, even
> before we start imagining a
Robert Dailey writes:
> git log log --graph --abbrev-commit --decorate --date=relative
> --format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
> green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
> white)%an%C(reset) - %C(white)%s%C(reset)' --branches --remotes
> ...
> The goal is to weed out t
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
> > I am not fundamentally opposed. I just do not think it would add
> > much value to new people at this point, and it will actively hurt
> > if we shoved barely cooked one in 2.0.
>
> You are probably biased in that you've used G
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>>> this.
> [...]
>>> That way, normal usage of --prefix would still be consistent with
>>> other git commands that prefer the form with argument a
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but didn't allow to override it from command line.
This patch depends on Jens Lehmann's patch "commit -m: commit staged
submodules regardless
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
This commit is also a prerequisite for the next one in series, which
adds the --ignore-submodules switch to git commit. That's why a new
argument is added to public function add_files_to_cache(), and it's
call site
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > Why is not material for v2.0? Because you say so? Are you going to wait
> > another
> > ten years to introduce this to v3.0?
>
> There's no need to wait for a 3.0 to introduce this. If these would
> be low-priority compared to user-defined al
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>> this.
[...]
>> That way, normal usage of --prefix would still be consistent with
>> other git commands that prefer the form with argument attached
>> (--prefix=foo, not --pref
My log graphs are pretty insane sometimes because we converted our
repo from SVN and haven't had a chance to delete all of the remote
branches. We still have quite a few (maybe 20).
When I do `git log`, I am shown about 10-15 vertical lines and the
branch I currently have checked out isn't even at
Felipe Contreras writes:
> Why is not material for v2.0? Because you say so? Are you going to wait
> another
> ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to user-defined aliases, there's no backward
compatibi
Jonathan Nieder writes:
> Hm, perhaps we should introduce a 'no-prefix' option to work around
> this.
> ...
>> |diff --git a/git-svn.perl b/git-svn.perl
>> |index 7349ffea..284f458a 100755
>> |--- a/git-svn.perl
>> |+++ b/git-svn.perl
>> |@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_std
"Kyle J. McKay" writes:
> Alternatively this change can be made in git-svn.perl:
> |diff --git a/git-svn.perl b/git-svn.perl
> |index 7349ffea..284f458a 100755
> |--- a/git-svn.perl
> |+++ b/git-svn.perl
> |@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
> my %icv;
> my %in
Junio C Hamano writes:
> Do you have reaction to the other one "[PATCH 1/2] merge: enable
> defaulttoupstream by default"?
Sorry, that other one is not even about difftool/mergetool.
I just checked that patch myself, and found it sensible for the
longer term.
--
To unsubscribe from this list: s
Felipe Contreras writes:
> There's no point in this:
>
> % git merge
> fatal: No commit specified and merge.defaultToUpstream not set.
>
> We know the most likely scenario is that the user wants to merge the
> upstream, and if not, he can set merge.defaultToUpstream to false.
And a new possible
Richard Hansen writes:
>> and plan for transition to forbid them
>> everywhere in a next big version bump (it is too late for 2.0).
>
> Would it be acceptable to have a config option to forbid these in a
> non-major version bump?
Of course ;-) Because we try very hard to avoid a "flag day" cha
"Luis R. Rodriguez" writes:
> From: "Luis R. Rodriguez"
>
> This saves us a few branches when RUN_SETUP is set up.
>
> Signed-off-by: Luis R. Rodriguez
> ---
Makes sense, especially because there is no sane reason to set both
bits on.
> git.c | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
Ronnie Sahlberg writes:
> This patch series changes most of the places where the ref functions for
> locking and writing refs to instead use the new ref transaction API. There
> are still three more places where write_ref_sha1() is called from outside
> of refs.c but those all will require more c
Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
> > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:
> >
> >>> If we don't standardize this now people will come up with their own
> >>> definitions [1] [2] (and many others if you just search GitHub) which
> >>> are again likely to dif
Ronnie Sahlberg writes:
> @@ -3481,6 +3481,14 @@ cleanup:
> unlock_ref(updates[i]->lock);
> free(delnames);
> ref_transaction_free(transaction);
> + if (ret) {
> + const char *str = "Cannot commit transaction.";
> + switch (onerr) {
>
Am 22.04.2014 00:08, schrieb Ronald Weiss:
> On 18. 4. 2014 14:09, Jens Lehmann wrote:
>> Am 13.04.2014 00:49, schrieb Ronald Weiss:
>>> Allow ignoring submodules (or not) by command line switch, like diff
>>> and status do.
>>>
>>> Git commit honors the 'ignore' setting from .gitmodules or .git/co
Ronnie Sahlberg writes:
> diff --git a/refs.c b/refs.c
> index 138ab70..9daf89e 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3414,12 +3414,12 @@ int ref_transaction_commit(struct ref_transaction
> *transaction,
> const char *msg, enum action_on_err onerr)
> ...
> + if
Kyle J. McKay wrote:
> The problem with --prefix="" is this (from the Getopt::Long CHANGES file):
>
> Changes in version 2.37
> ---
>
> * Bugfix: With gnu_compat, --foo= will no longer trigger "Option
>requires an argument" but return the empty string.
>
> The system I ran
Am 22.04.2014 12:35, schrieb Duy Nguyen:
> On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen wrote:
>>> IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so
>>> hopefully you did a dummy 'cache_name_exists("anything")' before starting
>>> the measurement of the first run?
>>
>> No I didn
Jakob Stoklund Olesen wrote:
> Subversion can put mergeinfo on any sub-directory to track cherry-picks.
> Since cherry-picks are not represented explicitly in git, git-svn should
> just ignore it.
Hi, was git-svn trying to track cherry-picks as merge before?
This changes behavior a bit, so two i
Thanks! I still haven't gotten around to looking at svn:mergeinfo
things, but this passes tests so I'm inclined to merge this unless
somebody disagrees.
--
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 h
Change store_updated_refs to use a single ref transaction for all refs that
are updated during the fetch. This makes the fetch more atomic when update
failures occur.
Since ref update failures will now no longer occur in the code path for
updating a single ref in s_update_ref, we no longer have as
Change s_update_ref to use a ref transaction for the ref update.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
---
builtin/fetch.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a93c893..5c15584 100644
In s_update_ref there are two calls that when they fail we return an error
based on the errno value. In particular we want to return a specific error
if ENOTDIR happened. Both these functions do have failure modes where they
may return an error without updating errno, in which case a previous and
u
This change is based on the previous ref transaction patches.
This is sent as a separate patch series since it implements a lot more
non-trivial changes to the behaviour than the previous patches and thus can
use more detailed review.
Update fetch.c to use ref transactions when performing updates.
On 2014-04-22 13:38, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> While we're at it, I think it would be prudent to ban '-' at the
>> beginning of reference name segments. For example, reference names like
>>
>> refs/heads/--cmd=/sbin/halt
>> refs/tags/--exec=forkbomb(){forkbomb
Sebastian Schuberth writes:
> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:
>
>>> If we don't standardize this now people will come up with their own
>>> definitions [1] [2] (and many others if you just search GitHub) which
>>> are again likely to differ (slightly), hindering interopera
Jan Kara writes:
> On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
>> So perhaps the rule should be updated to do something like:
>>
>> - find candidate tags that can be used to "describe --contains"
>> the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
>>
>> - among the can
Andrew Ardill writes:
> As a data point, I have seen people add ".gitignore" to their
> .gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its "canonical" ignore list, but until that
time, it would "work" (
Michael Haggerty writes:
> While we're at it, I think it would be prudent to ban '-' at the
> beginning of reference name segments. For example, reference names like
>
> refs/heads/--cmd=/sbin/halt
> refs/tags/--exec=forkbomb(){forkbomb|forkbomb&};forkbomb
>
> are currently both legal, b
Ilya Bobyr wrote:
> On 4/22/2014 9:31 AM, Felipe Contreras wrote:
> > Stephen Leake wrote:
> >> Felipe Contreras writes:
> >>> Yes, there a reason for the existance of those hooks. Now tell me why
> >>> would
> >>> anybody use post-update-branch instead of pre-update-branch?
> >>
> >> I have a b
David Aguilar writes:
> [Cc:ing Charles in case he has an opinion, this behavior dates back to the
> original MT]
>
> On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
>> It's annoying to see the prompt:
>>
>> Hit return to start merge resolution tool (foo):
>>
>> Every time
David Aguilar writes:
> On Sun, Apr 20, 2014 at 07:24:20PM -0500, Felipe Contreras wrote:
>> It's similar to the default, except that the other windows are hidden.
>> This ensures that removed/added colors are still visible on the main
>> merge window, but the other windows not visible.
>>
>> Sp
David Aguilar writes:
> [Cc:ing Charles in case he has an opinion, this behavior dates back to the
> original MT]
>
> On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
>> It's annoying to see the prompt:
>>
>> Hit return to start merge resolution tool (foo):
>>
>> Every time
On 4/22/2014 9:31 AM, Felipe Contreras wrote:
> Stephen Leake wrote:
>> Felipe Contreras writes:
>>
>>> Ilya Bobyr wrote:
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> Ilya Bobyr wrote:
>
>> Also, most have names that start with either "pre-" or "post-".
>> It seems reasonab
Erik Faye-Lund writes:
>>> Shouldn't the latter also be anchored at the beginning of the string
>>> with a leading "^"?
>>>
+}
+
+require File::Spec::Functions;
+return File::Spec::Functions::file_name_is_absolute($path);
>>>
>>> We already "use File::Spec qw(somet
Dan Porter writes:
> I should have updated on this earlier, but I wished to refine my work
> on this feature before submitting. With 2.0 looming I'll submit
> what's there so far.
I am not Pete, but...
The pre-release time is to find and fix regressions that may have
been introduced since the
Stephen Leake wrote:
> Felipe Contreras writes:
>
> > Ilya Bobyr wrote:
> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
> >> > Ilya Bobyr wrote:
> >> >
> >> >> Also, most have names that start with either "pre-" or "post-".
> >> >> It seems reasonable for both "pre-update-branch" and
> >> >> "
Ilya Bobyr wrote:
> On 4/21/2014 1:49 PM, Felipe Contreras wrote:
> > Ilya Bobyr wrote:
> >> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> >>> This hook is invoked whenever a branch is updated, either when a branch
> >>> is created or updated with 'git branch', or when it's rebased with 'git
> >>
Ilya Bobyr wrote:
> On 4/20/2014 7:23 PM, Felipe Contreras wrote:
> > [...]
> >
> > diff --git a/branch.c b/branch.c
> > index 660097b..c2058d1 100644
> > --- a/branch.c
> > +++ b/branch.c
> > @@ -4,6 +4,7 @@
> > #include "refs.h"
> > #include "remote.h"
> > #include "commit.h"
> > +#include "ru
Marat Radchenko wrote:
> On Mon, Apr 21, 2014 at 07:06:24PM -0500, Felipe Contreras wrote:
> > I managed to fix all the errors, some apply to newer mingw, regardless of
> > 32 or
> > 64, others are specific to 64-bit. It's all hacky and I haven't checked if
> > it
> > runs, but at least it compil
Duy Nguyen wrote:
> On Sun, Apr 20, 2014 at 9:46 PM, Jeff King wrote:
> > On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
> >
> >> - --color-words within unified diff format, using background color to
> >> show what part of the line has changed. This is only enabled for
> >> 1-line cha
Hi Felipe,
On Tue, 22 Apr 2014, Felipe Contreras wrote:
> Johannes Schindelin wrote:
> > On Mon, 21 Apr 2014, Felipe Contreras wrote:
> > > Johannes Schindelin wrote:
> > > > Now, clearly you have all the motivation that is needed to get 64-bit
> > > > builds of Git for Windows going, and all the
Johannes Schindelin wrote:
> On Mon, 21 Apr 2014, Felipe Contreras wrote:
> > Johannes Schindelin wrote:
> > > Now, clearly you have all the motivation that is needed to get 64-bit
> > > builds of Git for Windows going, and all the motivation required to make
> > > sure that the MSVC support of the
On Tue, Apr 22, 2014 at 04:59:17PM +0700, Duy Nguyen wrote:
> On Sun, Apr 20, 2014 at 9:46 PM, Jeff King wrote:
> > On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
> >
> >> - --color-words within unified diff format, using background color to
> >> show what part of the line has change
Felipe Contreras writes:
> Ilya Bobyr wrote:
>> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
>> > Ilya Bobyr wrote:
>> >
>> >> Also, most have names that start with either "pre-" or "post-".
>> >> It seems reasonable for both "pre-update-branch" and
>> >> "post-update-branch" to exist.
>> > I do
When show date in relative date format for git-blame, the max display
width of datetime is set as the length of the string "Thu Oct 19
16:00:04 2006 -0700" (30 characters long). But actually the max width
for C locale is only 22 (the length of string "x years, xx months ago").
And for other locale
Command `git blame --date relative` aligns the date field with a
fixed-width (defined by blame_date_width), and if time_str is shorter
than that, it adds spaces for padding. But there are two bugs in the
following codes:
time_len = strlen(time_str);
...
memset(time_buf + t
Changes since V3:
* rollback patch 2/2 to v2, but with a nicer comment for translators.
Jiang Xin (2):
bugfix: fix broken time_buf paddings for git-blame
blame: dynamic blame_date_width for different locales
builtin/blame.c | 30 ++
1 file changed, 22 insertions
Johannes Schindelin writes:
> On Mon, 21 Apr 2014, Felipe Contreras wrote:
>
>> Johannes Schindelin wrote:
>> > Now, clearly you have all the motivation that is needed to get 64-bit
>> > builds of Git for Windows going, and all the motivation required to make
>> > sure that the MSVC support of th
Hi Marat,
On Tue, 22 Apr 2014, Marat Radchenko wrote:
> Johannes says building mingw64 Git is dirt-easy.
Marat, please let's stop misquoting me, okay?
What I said was more along the lines that there had been some start of a
work on getting things to compile for 64-bit Windows, but that the test
Hi,
On Mon, 21 Apr 2014, Felipe Contreras wrote:
> Johannes Schindelin wrote:
> > Now, clearly you have all the motivation that is needed to get 64-bit
> > builds of Git for Windows going, and all the motivation required to make
> > sure that the MSVC support of the msysGit project works.
>
> s/
2014-04-22 3:19 GMT+08:00 Junio C Hamano :
> Junio C Hamano writes:
>
>> What I am wondering is if we can do something
>> like this:
>> ...
>
> Nah, that is a lot more stupid than just doing
>
>> In code:
>>
>> blame_date_width = strtoul(_("4 years, 11 months ago"), NULL, 10) +
>> 1;
On Wed, Apr 16, 2014 at 7:19 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Erik Faye-Lund writes:
>>
>>> So let's manually check for these in that case, and fall back to
>>> the File::Spec-helper on other platforms (e.g Win32 with native
>>> Perl)
>>> ...
>>> +sub file_name_is_absolute
2014-04-22 18:01 GMT+08:00 David Kastrup :
> Junio C Hamano writes:
>
>> This is not wrong per-se, but I am not sure if translators would
>> understand that "years and months ago" may not be the longuest
>> variant for their language and they are asked to use "89 seconds
>> ago" if the translation
On 4/22/2014 12:26 AM, Felipe Contreras wrote:
> Marius Storm-Olsen wrote:
>> Turns out the osocas.2014.sgizmo.com survey subdomain gives an SSL
>> warning for the *.sgizmo.com certificate. *face palm*
>>
>> Feel free to use
>> http://bit.ly/OSOCAS2014
>> instead, which will redirect to the n
On Apr 18, 2014, at 12:37, Junio C Hamano wrote:
> An early preview release Git v2.0.0-rc0 is now available for
> testing at the usual places.
I have run into the following test failures with v2.0.0-rc0:
Test Summary Report
---
t9117-git-svn-init-clone.sh (Wstat: 256
Michael Haggerty writes:
> On 04/22/2014 09:07 AM, Matthieu Moy wrote:
>
> The whole point of the change is to *allow* strbuf to be used in
> performance-critical stuff.
OK. It should not make the current use of strbuf any harder anyway.
>> In your proposal, would STRBUF_OWNS_MEMORY be a consta
On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen wrote:
>> IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so hopefully
>> you did a dummy 'cache_name_exists("anything")' before starting the
>> measurement of the first run?
>
> No I didn't. Thanks for pointing it out. I'll see if I ca
On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
> So perhaps the rule should be updated to do something like:
>
> - find candidate tags that can be used to "describe --contains"
> the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
>
> - among the candidate tags, cull the ones
On Tue, Apr 22, 2014 at 4:56 PM, Karsten Blees wrote:
> Am 17.04.2014 07:51, schrieb Nguyễn Thái Ngọc Duy:
>> This patch serves as a heads up about a feature I'm working on. I hope
>> that by posting it early, people could double check if I have made
>> some fundamental mistakes that completely ru
Junio C Hamano writes:
> This is not wrong per-se, but I am not sure if translators would
> understand that "years and months ago" may not be the longuest
> variant for their language and they are asked to use "89 seconds
> ago" if the translation of that is longer than the translation for
> "4 y
On Sun, Apr 20, 2014 at 9:46 PM, Jeff King wrote:
> On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
>
>> - --color-words within unified diff format, using background color to
>> show what part of the line has changed. This is only enabled for
>> 1-line changes.
>
> See contrib/diff-hig
Am 17.04.2014 07:51, schrieb Nguyễn Thái Ngọc Duy:
> This patch serves as a heads up about a feature I'm working on. I hope
> that by posting it early, people could double check if I have made
> some fundamental mistakes that completely ruin the idea. It's about
> speeding up "git status" by cachin
Hi Pete,
I should have updated on this earlier, but I wished to refine my work
on this feature before submitting. With 2.0 looming I'll submit
what's there so far.
There is a patch viewable at this link:
https://github.com/Stealthii/git/commit/f7a2e611262fd977ac99e066872d3d0743b7df3c
For the us
As part of my work to help get git-p4 close to bug-free before Git
2.0, I'm posting all bugs and patches to this mailing list. Please
direct me elsewhere if this is incorrect.
When trying to clone a particular directory from a depot, that
contains one or more branches that contain no commits for t
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
> Michael Haggerty writes:
>
>> STRBUF_OWNS_MEMORY
>>
>> The memory pointed to by buf is owned by this strbuf. If this
>> bit is not set, then the memory should never be freed, and
>> (among other things) strbuf_detach() mus
On 04/21/2014 10:24 PM, Jeff King wrote:
> On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
>
>> Both bash and zsh subject the value of PS1 to parameter expansion,
>> command substitution, and arithmetic expansion. Rather than include
>> the raw, unescaped branch name in PS1 when r
Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
> wrote:
>
> >> The problem is that between "git rm" and "git mv", if we default "git
> >> cp" to mean "cherry-pick" there could easily be user confusion.
> >>
> >> I'm not sure that cherry-pick is used that often it
Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:
>
> >> If we don't standardize this now people will come up with their own
> >> definitions [1] [2] (and many others if you just search GitHub) which
> >> are again likely to differ (slightly), hindering interoper
We used to show "(missing )" next to tests skipped because they are
specified in GIT_SKIP_TESTS. Use "(GIT_SKIP_TESTS)" instead.
Plus tests that check basic GIT_SKIP_TESTS functions.
Signed-off-by: Ilya Bobyr
---
t/t-basic.sh | 63 ++
t
Most arguments that could be provided to a test have short forms.
Unless documented, the only way to learn them is to read the code.
Signed-off-by: Ilya Bobyr
---
t/README |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/README b/t/README
index caeeb9d..6b93aca 1
Allow better control of the set of tests that will be executed for a
single test suite. Mostly useful while debugging or developing as it
allows to focus on a specific test.
Signed-off-by: Ilya Bobyr
---
t/README | 73 +++-
t/t-basic.sh | 356 +
This patches add `--run` option to the test suites to allow one to run
individual tests out of the test suite. Like this:
./t-basic.sh --run='-4,7,9-12,15-'
Both spaces and commas are accepted as separators for the ranges (In
previous versions only spaces were accepted).
Two previous ve
It looks like the documentation for bitmaps is being included in the
1.9.2 release of Git for Windows but the functionality itself is not
present. For example, doc\git\html\git-config.html includes settings
like these:
pack.useBitmaps
When true, git will use pack bitmaps (if available) when packi
Charles Bailey wrote:
> On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote:
> > Charles Bailey wrote:
> > > On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
> > > >
> > > > This is what I get when a tool is not working:
> > > >
> > > > Documentation/config.txt see
On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote:
> Charles Bailey wrote:
> > On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
> > >
> > > This is what I get when a tool is not working:
> > >
> > > Documentation/config.txt seems unchanged.
> > > Was the merge
1 - 100 of 106 matches
Mail list logo
