Vicent Martí:
I'm aware of that, but Git needs to build with glibc 2.7+ (or was it
2.6?), hence the need for this compat layer.
Right. But perhaps the compatibility layer could provide the
functionality with the names available in the later glibc versions
(and on *BSD)? That would make it ea
On 06/27/2013 12:35 AM, Jeff King wrote:
> On Wed, Jun 26, 2013 at 10:45:48PM +0100, Ramsay Jones wrote:
>
>>> This patch adds some *extra* cache invalidation that was heretofore
>>> missing. If stat() is broken it could
>>>
>>> (a) cause a false positive, resulting in some unnecessary cache
>>>
i have configured like this
git remote add myremote1 ...
git config --global push.default upstream
git branch --set-upstream-to=myremote1/master remote1-master
and git pull, git push in remote1-master work i expected
but "git remote status myremote1" display..
Local ref configured for 'git
Hi --
I have a disk image of a small embedded device whose root file system I'd like
to check-in to git as a means of distributing its GPL'd software. In that disk
image are device files, which GIT studiously ignores. If symlinks are handled
(contents being the path that the symlink points at
2013/6/27 Junio C Hamano :
>> + } else {
>> + i++;
>> + j++;
>> + }
>> + }
>> +
>> + if (
>> + /* "prefix" seems like prefix of "in" */
>> + i >= prefix_len &&
>
> So shouldn't this be "i == prefix_len"?
>
>> +
On Thu, Jun 27, 2013 at 04:36:54AM +0200, Vicent Martí wrote:
> That was a very rude reply. :(
>
> Please refrain from interacting with me in the ML in the future. I'l
> do accordingly.
I agree that the pointer arithmetic thing may have been a little much,
but I think there are some points we ne
That was a very rude reply. :(
Please refrain from interacting with me in the ML in the future. I'l
do accordingly.
Thanks!
vmg
On Thu, Jun 27, 2013 at 3:11 AM, Shawn Pearce wrote:
> On Tue, Jun 25, 2013 at 4:08 PM, Vicent Martí wrote:
>> On Tue, Jun 25, 2013 at 11:17 PM, Junio C Hamano wrote
On 06/26/2013 10:19 AM, Torsten Bögershausen wrote:
On 2013-06-25 23.18, Junio C Hamano wrote:
Johannes Sixt writes:
Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?
Sure. Thanks.
First of al
2013/6/27 Junio C Hamano :
>> diff --git a/quote.c b/quote.c
>> index 64ff3..ebb8 100644
>
> You seem to be using unusually short abbrev length.
>
> Please don't, at least in format-patch output.
>
> "ebb8" may be unique within your repository, but may not be unique
> in repositories of other peopl
On Wed, Jun 26, 2013 at 6:53 PM, Colby Ranger wrote:
>> + Generating this reverse index at runtime is **not** free (around 900ms
>> + generation time for a repository like `torvalds/linux`), and once again,
>> + this generation time needs to happen every time `pack-objects` is
>> + spawned.
9
On Tue, Jun 25, 2013 at 11:11 PM, Jeff King wrote:
> On Tue, Jun 25, 2013 at 09:33:11PM +0200, Vicent Martí wrote:
>
>> > One way we side-stepped the size inflation problem in JGit was to only
>> > use the bitmap index information when sending data on the wire to a
>> > client. Here delta reuse pl
On Tue, Jun 25, 2013 at 4:08 PM, Vicent Martí wrote:
> On Tue, Jun 25, 2013 at 11:17 PM, Junio C Hamano wrote:
>> What case are you talking about?
>>
>> The n-th object must be one of these four types and can never be of
>> more than one type at the same time, so a natural expectation from
>> the
2013/6/27 Junio C Hamano
>
> Jiang Xin writes:
>
> > Add subcommand "relative_path" in test-path-utils, and add test cases
> > in t0060.
> >
> > Johannes tested this commit on Windows, and found that some relative_path
>
> "this commit", or "an earlier version of this patch"? I am guessing
> it
git am was previously modified to provide --continue for consistency
with rebase, merge etc, and the documentation changed to showing
--continue as the primary form.
Complete the work by replacing remaining uses of --resolved by
--continue, most notably in suggested command reminders.
Signed-off-
> + Generating this reverse index at runtime is **not** free (around 900ms
> + generation time for a repository like `torvalds/linux`), and once again,
> + this generation time needs to happen every time `pack-objects` is
> + spawned.
If generating the reverse index is expensive, it is probabl
Excerpts from Junio C Hamano's message of Wed Jun 26 16:48:57 -0700 2013:
> Andrew Pimlott writes:
> > In order to test this, I wrote a helper function to dump the rebase -i
> > todo list. Would you like this introduced in its own patch, or
> > combined? See below.
>
> Depends on how involved t
Andrew Pimlott writes:
> In order to test this, I wrote a helper function to dump the rebase -i
> todo list. Would you like this introduced in its own patch, or
> combined? See below.
Depends on how involved the addition of the tests that actually use
the helper, but in general it would be a g
Dennis Kaarsemaker writes:
> Apart from the exactly matching refspecs, does git in any other way
> treat this as a special case?
Sorry, I do not quite understand, especially the "exactly matching"
part, which as far as I know is not special (in other words, I am
not sure what kind of "special ca
Thomas Rast writes:
[...]
> The next word after `L_M` (if any) must again be a RLW, for the next
> chunk. For efficient appending to the bitstream, the EWAH stores a
> format to the last RLW in the stream.
^^
I have no idea what Freud did there, but "pointer" or some such is
probably a sa
Vicent Martí writes:
> On Tue, Jun 25, 2013 at 5:58 PM, Thomas Rast wrote:
>>
>> Please document the RLW format here.
>
> Har har. I was going to comment on your review of the Ewah patchset,
> but might as well do it here: the only thing I know about Ewah bitmaps
> is that they work. And I know
Vicent Martí writes:
> I'm afraid I cannot reproduce the segfault locally (assuming you're
> performing the rev-list on the git/git repository). Could you please
> send me more information, and a core dump if possible?
Sure, but isn't the core dump useless if you don't have the same
executable?
On Wed, Jun 26, 2013 at 06:35:52PM -0400, Jeff King wrote:
> I am curious how often Cygwin gives us the false positive. If it is
> every time, then the check is not doing much good at all. Is it possible
> for you to instrument stat_validity_check to report how often it does or
> does not do anyth
On Wed, Jun 26, 2013 at 10:45:48PM +0100, Ramsay Jones wrote:
> > This patch adds some *extra* cache invalidation that was heretofore
> > missing. If stat() is broken it could
> >
> > (a) cause a false positive, resulting in some unnecessary cache
> > invalidation and re-reading of packed-refs,
>> Pinning the bitmap index on the reverse index adds complexity (lookups
>> are two-step: first find the entry in the reverse index, and then find
>> the SHA1 in the index) and is measurably slower, in both loading and
>> lookup times. Since Git doesn't have a memory problem, it's very hard
>> to
Michael Haggerty wrote:
> On 06/25/2013 07:07 AM, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> Michael Haggerty and Jeff King have been re-vamping the reference
>>> handling code. The failures noted above were provoked by patches
>>> in the 'mh/ref-races' branch. At the time I wrote this p
Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Michael Haggerty and Jeff King have been re-vamping the reference
>> handling code. The failures noted above were provoked by patches
>> in the 'mh/ref-races' branch. At the time I wrote this patch, that
>> branch was only included in 'pu', but I
Torsten Bögershausen wrote:
> On 2013-06-25 23.18, Junio C Hamano wrote:
>> Johannes Sixt writes:
>>
>>> Some context: This is about a patch by Ramsay that removes the
>>> "schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
>>> patch in pu?
>>
>> Sure. Thanks.
>
> First of al
Excerpts from Andrew Pimlott's message of Tue Jun 25 16:03:52 -0700 2013:
> Thomas's patch didn't do this: fixup! or squash! after the first is
> simply discarded, so you see:
>
> pick d78c915 original
> fixup 0c6388e fixup! original
> fixup d15b556 fixup! original
> fixup 1e39bcd
On zo, 2013-06-23 at 15:33 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote:
> >> Dennis Kaarsemaker writes:
> >>
> >> > Equality for
> >> > wildcards is allowed and tested for, so do we really want to 'outlaw'
> >> > equalit
Fredrik Gustafsson writes:
> On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
>> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
>> > Used only when a clone is initialized. This is useful when the submodule(s)
>> > are huge and you're not really interested in anyth
benoit.per...@ensimag.fr writes:
> +do you want ? Use the -r option to specify the remote.
Not that it really matters, but there should be no space before ? in
English (although there is in French).
(Shouldn't prevent merging)
Other than that, the series looks good to me. Good work splitting
pa
From: Benoit Person
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be created. To achieve this goal, the project needs a way to
share code b
From: Benoit Person
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any
From: Benoit Person
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed
From: Benoit Person
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implem
From: Benoit Person
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v4:
- Rebase on latest master
- Typos in commits messages and code
- Comments in Makefile
- Factoring the conversio
From: Benoit Person
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypas
> Pinning the bitmap index on the reverse index adds complexity (lookups
> are two-step: first find the entry in the reverse index, and then find
> the SHA1 in the index) and is measurably slower, in both loading and
> lookup times. Since Git doesn't have a memory problem, it's very hard
> to make
People may have comments and improvements on the actual
"interactive" UI part, but I think the earlier parts up to "into two
phases" is ready for 'next'. Let's queue them and have them
advance.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to m
Jiang Xin writes:
> After substitute path_relative() in quote.c with relative_path() from
> path.c, parameters (such as len and prefix_len) are obsolete in function
> quote_path_relative(). Remove unused parameters and change the order of
> parameters for quote_path_relative() function.
>
> Signe
Jiang Xin writes:
> Add subcommand "relative_path" in test-path-utils, and add test cases
> in t0060.
>
> Johannes tested this commit on Windows, and found that some relative_path
"this commit", or "an earlier version of this patch"? I am guessing
it is the latter (if so, I can easily amend loc
Jiang Xin writes:
> Original design of relative_path() is simple, just strip the prefix
> (*base) from the absolute path (*abs). In most cases, we need a real
> relative path, such as: ../foo, ../../bar. That's why there is another
> reimplementation (path_relative()) in quote.c.
>
> Borrowed som
Jiang Xin writes:
> Substitute the function path_relative in quote.c with the function
> relative_path. Function relative_path can be treated as an enhanced
> and robust version of path_relative.
> ...
> And if prefix has no trailing slash, path_relative can not work properly
> either. But since
Alexey Shumkin writes:
> v7 of this patch series includes the following changes against v6:
> 1. [PATCH v7 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected
> outputs
> untouched
> 2. [PATCH v7 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs
> untouched
> 3.
Heiko Voigt writes:
> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
>> Used only when a clone is initialized. This is useful when the submodule(s)
>> are huge and you're not really interested in anything but the latest commit.
>>
>> Signed-off-by: Fredrik Gustafsson
>
> I
On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
> > Used only when a clone is initialized. This is useful when the submodule(s)
> > are huge and you're not really interested in anything but the latest commit.
> >
>
Torsten Bögershausen writes:
>> +++ b/diff.c
>> @@ -2647,6 +2647,10 @@ static int diff_populate_gitlink(struct diff_filespec
>> *s, int size_only)
>> int diff_populate_filespec(struct diff_filespec *s, int size_only)
>> {
>> int err = 0;
>> +enum safe_crlf crlf_warn = (safe_crlf != SA
Hi,
sorry for long delay, I was busy on some important project so far. However,
we’ve found out really bad thing recently.
On Feb 21, 2013, at 7:04 PM, "Kraai, Matt" wrote:
> Junio C Hamano writes:
>> "David Ondřich" writes:
>>> I've read [1] recently, there's been some QNX port being
>>> init
Alexey Shumkin writes:
> On Tue, Jun 25, 2013 at 12:28:02PM -0700, Junio C Hamano wrote:
> ...
> If someone can do the same with latin1, I'd be happy.
> ...
> But today I've taken a look to Cygwin's locales more closely and found
> out that I've used incorrect encoding name (`iso88595` instead of
On 2013-06-25 23.18, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Some context: This is about a patch by Ramsay that removes the
>> "schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
>> patch in pu?
>
> Sure. Thanks.
First of all,
thanks for the work.
Here some "ben
One can set an alias
$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log messages writ
One can set an alias
$ git config [--global] alias.lg "log --graph
--pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log m
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t4205-log-pretty-formats.sh | 48 +++
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/t/t4205-log-pretty-forma
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t6006-rev-list-format.sh | 140 +
1 file changed, 77 insertions(+), 63 deletions(-)
diff --git a/t/t6006-rev-list-format.
v7 of this patch series includes the following changes against v6:
1. [PATCH v7 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected
outputs
untouched
2. [PATCH v7 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs
untouched
3. [PATCH v7 3/5] t4205 (log-pretty-f
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t7102-reset.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index df82ec9..05dfb27 100755
--- a/t/t
On Tue, Jun 25, 2013 at 12:28:02PM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > 4. [PATCH v6 4/5] pretty: Add failing tests: --format output should honor
> > logOutputEncoding
> > iso8859-5 encoding reverted back to cp1251 encoding (as it was in v4
> > series)
>
> Thanks for
On Mon, Jun 24, 2013 at 03:53:56PM -0400, Greg Freemyer wrote:
> I'm trying to create a tarball from a git tag and I can't get the
> syntax right. The documentation is not very clear.
> [...]
> > git archive --format=tar --remote=github.com:dkovar/analyzeMFT.git v2.0.4
Your remote should be g...
58 matches
Mail list logo