Jeff King p...@peff.net writes:
This is highlighting the problem with pager.* that Junio mentioned
recently, which is that the keyname has arbitrary data,...
Yes, even if it is not arbitrary (imagine we limit ourselves to
the official set of commands we know about), the naming rule for the
git
I'm interested in a collaboration and change management solution for
data stored in pre-existing RDF data stores set behind SPARQL
endpoints. I would like some input on my idea before I invest too much
time in reading about Git internals. My main question is whether
people more experienced in how
Jeff King p...@peff.net writes:
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
$ git show_ref
error: invalid key: pager.show_ref
error: invalid key: alias.show_ref
git: 'show_ref' is not a git command. See 'git --help'.
Apparently we need to squelch this message
On Fri, Feb 06, 2015 at 11:44:38AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
$ git show_ref
error: invalid key: pager.show_ref
error: invalid key: alias.show_ref
git: 'show_ref' is not a git
On Thu, Feb 05, 2015 at 12:17:15PM -0800, Junio C Hamano wrote:
Would length() 1 be enough[1]? Or are people really typing yes and
not just y?
I cannot imagine a charset name that is smaller than two characters. It
may be that there are none smaller than 4, and we could cut it off
Kyle J. McKay mack...@gmail.com writes:
Actually I just tested it. If we #undef it we could end up producing
these:
error: syntax error before DEPRECATED_ATTRIBUTE
So I think it needs to stay #define'd to nothing to be safe in case
anything later on ends up including stuff that
On Feb 6, 2015, at 02:00, Eric Sunshine wrote:
On Fri, Feb 6, 2015 at 4:35 AM, Kyle J. McKay mack...@gmail.com
wrote:
#ifndef NO_OPENSSL
+#ifdef __APPLE__
#define __AVAILABILITY_MACROS_USES_AVAILABILITY 0
-#define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_6
+#include
On Fri, Feb 6, 2015 at 3:06 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
+ die(_(sorry, cannot apply a 'copying' patch in
reverse (yet)));
Is it wise to give the reader of the output hope that this is not
implemented (yet)
but may
Hello,
I recently ran into an annoying problem: 'git rebase' apparently
silently drops changes in non-conflicting paths of merge commits
(git version 1.9.3).
Is it a bug or feature? Is there a way to flatten history using rebase,
yet preserve manual changes found in merge commits?
Here is
Junio C Hamano gits...@pobox.com writes:
Action item: warn users against using apply -R on a
patchset with such a patch while this is fixed.
This needs to be replaced with the logic to properly reverse a patch
that creates a new file by copying from somewhere else, but for now,
On Fri, Feb 6, 2015 at 3:43 PM, Kyle J. McKay mack...@gmail.com wrote:
On Feb 6, 2015, at 12:05, Junio C Hamano wrote:
Kyle J. McKay mack...@gmail.com writes:
So I think it needs to stay #define'd to nothing to be safe in case
anything later on ends up including stuff that uses it.
Doesn't
Junio C Hamano gits...@pobox.com writes:
5. Third twist: rewriting by copying
...
One possible way to fix this is to include another patch in the same
patchset that shows the deletion of major-11.txt. The rule 2. would
be further revised to something like:
rule 2. a patch renaming file A
I've been thinking about diff -B -M for quite a while, and I am
finding a few interesting problems we have in our codebase. Here is
a snapshot, with a few action items.
In this write-up of my current thinking, I'll use these terms:
patchset::
Output from a single git diff invocation, which
Jeff King p...@peff.net writes:
That is one of the reasons why I had the unbounded set, including
the ones under our control such as subcommand names in the draft
update for the guideline. I dropped that part after the discussion
to keep other obviously agreed parts moving, but we may have
Jeff King p...@peff.net writes:
A list of enum-like values where we are OK confining the names to the
alnums is OK to use as an unbounded set of key values. Just like we have
color.branch.*, we just pick a name within that syntax for any new
values we add (and that is not even a burden; alnum
On Sat, Feb 07, 2015 at 01:03:15AM +0100, Mikael Magnusson wrote:
On Fri, Feb 6, 2015 at 8:44 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
$ git show_ref
error: invalid key:
On Fri, Feb 06, 2015 at 02:27:31PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
A list of enum-like values where we are OK confining the names to the
alnums is OK to use as an unbounded set of key values. Just like we have
color.branch.*, we just pick a name within that
On Fri, Feb 6, 2015 at 8:44 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
$ git show_ref
error: invalid key: pager.show_ref
error: invalid key: alias.show_ref
git: 'show_ref' is not a git
On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
there seems to be a regression in the behaviour of 'git show_ref'
(note the underscore). In v2.0.3-711-g586f414 it starts to say:
$ ./git show_ref
error: invalid key: pager.show_ref
git: 'show_ref' is not a git command.
On Fri, Feb 06, 2015 at 12:14:35PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
This is highlighting the problem with pager.* that Junio mentioned
recently, which is that the keyname has arbitrary data,...
Yes, even if it is not arbitrary (imagine we limit ourselves to
On Feb 6, 2015, at 12:05, Junio C Hamano wrote:
Kyle J. McKay mack...@gmail.com writes:
Actually I just tested it. If we #undef it we could end up producing
these:
error: syntax error before DEPRECATED_ATTRIBUTE
So I think it needs to stay #define'd to nothing to be safe in case
anything
MAC_OS_X_VERSION_MIN_REQUIRED may be defined by the builder to a
specific version in order to produce compatible binaries for a
particular system. Blindly defining it to MAC_OS_X_VERSION_10_6
is bad.
Additionally MAC_OS_X_VERSION_10_6 will not be defined on older
systems and should
On Fri, Feb 6, 2015 at 4:35 AM, Kyle J. McKay mack...@gmail.com wrote:
MAC_OS_X_VERSION_MIN_REQUIRED may be defined by the builder to a
specific version in order to produce compatible binaries for a
particular system. Blindly defining it to MAC_OS_X_VERSION_10_6
is bad.
Additionally
Hi all,
there seems to be a regression in the behaviour of 'git show_ref'
(note the underscore). In v2.0.3-711-g586f414 it starts to say:
$ ./git show_ref
error: invalid key: pager.show_ref
git: 'show_ref' is not a git command. See 'git --help'.
and somewhere (probably two commits,
On Thu, Feb 5, 2015 at 11:53 PM, Junio C Hamano gits...@pobox.com wrote:
The latest feature release Git v2.3.0 is now available at the
usual places.
[...]
* Git 2.0 was supposed to make the simple mode for the default of
git push, but it didn't.
(merge 00a6fa0 jk/push-simple later to
25 matches
Mail list logo
