On Jan 30, 2015, at 15:05, brian m. carlson wrote:
> On Fri, Jan 30, 2015 at 07:24:45AM +0100, Tom G. Christensen wrote:
>> The '--no-xmailer' option is a Getopt::Long boolean option. The
>> '--no-' prefix (as in --no-xmailer) for boolean options is not
>> supported in Getopt::Long version 2.32 whi
On Fri, Jan 30, 2015 at 07:24:45AM +0100, Tom G. Christensen wrote:
The '--no-xmailer' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-xmailer) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports
"Tom G. Christensen" writes:
> diff --git a/Makefile b/Makefile
> index c44eb3a..69a2ce3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1035,13 +1035,13 @@ else
> REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
> PROGRAM_OBJS += http-fetch.o
> PROGRAMS += $(REM
Jeff King writes:
> But could we instead pull this check to just before the write-out time?
> That is, to let any horrible thing happen in-core, as long as what we
> write out to the index and the filesystem is sane?
The check in-core is somewhat tricky, because we would need to (1)
catch a patc
Hi,
This bug report concerns git-gui. Apologies if this is not the right
mailing-list.
By submodule I mean a repository for which .git is not a regular Git
directory, but rather a "gitdir: ..." file.
While running "git gui" from such a directory will work fine, trying
to open it from the choose_r
Jeff King writes:
> Ah, OK. Yeah, doing it progressively can only be accurate if our
> name-checks follow the same order as applying, because we are checking
> against a particular state.
>
> But could we instead pull this check to just before the write-out time?
> That is, to let any horrible th
On Fri, Jan 30, 2015 at 12:20:02PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I had the impression that we did not apply in any arbitrary order that
> > could work, but rather that we did deletions first followed by
> > additions. But I am fairly ignorant of the apply code.
>
> No,
Jeff King writes:
> Hrm. That only works in the current code because we apply the deletion
> in the directory (and then clean up the now-empty directory) first. So I
> think you would need to check the paths progressively as you apply them,
> since those other parts of the diff "haven't happened
Jeff King writes:
> I had the impression that we did not apply in any arbitrary order that
> could work, but rather that we did deletions first followed by
> additions. But I am fairly ignorant of the apply code.
No, you are thinking about the write-out of the finished result,
which may have to
On Fri, Jan 30, 2015 at 12:11:30PM -0800, Junio C Hamano wrote:
> I am not sure how to fix this, without completely ripping out the
> misguided "We should be able to concatenate outputs from multiple
> invocations of 'git diff' into a single file and apply the result
> with a single invocation of
Junio C Hamano writes:
> Jeff King writes:
>
>>> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
>>> + return error(_("affected file '%s' is beyond a symbolic link"),
>>> +patch->new_name);
>>
>> Why does this not kick in when deleting a fi
On Fri, Jan 30, 2015 at 11:48:14AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
> >> + return error(_("affected file '%s' is beyond a symbolic link"),
> >> + patch->new_name);
> >
> > W
Jeff King writes:
>> +if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
>> +return error(_("affected file '%s' is beyond a symbolic link"),
>> + patch->new_name);
>
> Why does this not kick in when deleting a file? If it is not OK to
> add a
On Fri, Jan 30, 2015 at 11:42:49AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:
> >
> >> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
> >> + return error(_("affected file '%s' is beyond a s
Jeff King writes:
> On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:
>
>> +if (!patch->is_delete && path_is_beyond_symlink(patch->new_name))
>> +return error(_("affected file '%s' is beyond a symbolic link"),
>> + patch->new_name);
>
> Why do
On Fri, Jan 30, 2015 at 11:07:34AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > It looks like your new --allow-uplevel goes to verify_path(). So this
> > isn't just about "..", but it will also protect against applying a patch
> > inside ".git". Which seems like a good thing to me, but
Jeff King writes:
> It looks like your new --allow-uplevel goes to verify_path(). So this
> isn't just about "..", but it will also protect against applying a patch
> inside ".git". Which seems like a good thing to me, but I wonder if the
> option name is a little misleading.
True; not just misl
On Thu, Jan 29, 2015 at 03:48:14PM -0800, Junio C Hamano wrote:
> By default, a patch that affects outside the working area is
> rejected as a mistake; Git itself never creates such a patch
> unless the user bends backwards and specifies nonstandard
> prefix to "git diff" and friends.
>
> When `g
On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:
> +static int path_is_beyond_symlink(const char *name_)
> +{
> + struct strbuf name = STRBUF_INIT;
> +
> + strbuf_addstr(&name, name_);
> + do {
> + struct patch *previous;
> +
> + while (--name.len
I'm very glad to hear that. Thanks to all reviewers!
On Thu, Jan 29, 2015 at 3:19 PM, Junio C Hamano wrote:
> Thanks; queued. Let's run with this and try to make it graduate
> early next cycle.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
On Fri, Jan 30, 2015 at 08:55:20AM -0700, Lance Fredrickson wrote:
> I've been keeping up-to-date versions of git built for an embedded mipsel
> architecture device running on uclibc.
> 2.2.1 and previous versions build fine, but 2.2.2 stops with an error.
>
> The toolchain is an OpenWRT variant
Sorry, file this one away under user error. I had an issue with my build
environment.
cheers!
On 1/30/2015 8:55 AM, Lance Fredrickson wrote:
I've been keeping up-to-date versions of git built for an embedded
mipsel architecture device running on uclibc.
2.2.1 and previous versions build fine,
I've been keeping up-to-date versions of git built for an embedded
mipsel architecture device running on uclibc.
2.2.1 and previous versions build fine, but 2.2.2 stops with an error.
The toolchain is an OpenWRT variant (entware) using gcc 4.6.4 and uclibc
0.9.32, available at the following.
h
On Jan 30, 2015, at 06:50, Andreas Schwab wrote:
"Tom G. Christensen" writes:
diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJ
On 30/01/15 15:50, Andreas Schwab wrote:
"Tom G. Christensen" writes:
diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJS += http
When we add a new submodule the path of the submodule is being normalized. We
fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule'
will become 'path/to/./submodule' where it should be 'path/to/submodule'
instead.
Signed-off-by: Patrick Steinhardt
---
git-submodule.sh
On Fri, Jan 30, 2015 at 11:05:36AM +0100, Michael J Gruber wrote:
> It's a shame one can't simply replace the [footer-text] template which
> asciidoc insists on.
>
> It turns out asciidoc 8.6.9-3 and later will habe a knob to turn:
>
> https://github.com/asciidoc/asciidoc/pull/9
>
> I'll try an
"Tom G. Christensen" writes:
> diff --git a/Makefile b/Makefile
> index c44eb3a..69a2ce3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1035,13 +1035,13 @@ else
> REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
> PROGRAM_OBJS += http-fetch.o
> PROGRAMS += $(REM
Junio C Hamano schrieb am 29.01.2015 um 07:18:
> Olaf Hering writes:
>
>> On Tue, Jan 27, Junio C Hamano wrote:
>>
What file timestamp should be used for them? Likely "../version"?
>>>
>>> I tend to think the "Last updated" timestamp taken from the
>>> filesystem timestamp is a bad practice
On 29/01/15 16:52, Jeff King wrote:
Both this and the curl-version issue you reported seem to have simple
solutions that you've already worked out and tested. Would you like to
express them in the form of patches so they can be applied? :)
Patches have been posted as requested.
-tgc
--
To uns
curl 7.11.0 through 7.12.2 when built from their official release
archives will present a 5 digit version number instead of the documented
6 digits which breaks the version check in the Makefile.
Correct these broken version numbers on the fly when extracting them to
ensure the comparison works cor
On Thu, Jan 29, 2015 at 9:45 PM, Junio C Hamano wrote:
>
> Instead, for any patch in the input that leaves a path (i.e. a non
> deletion) in the result, we check all leading paths against interim
> result and then either the index or the working tree. The interim
> results of applying patches are
32 matches
Mail list logo
