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 wrote:
> > Jeff King writes:
> >
> >> On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote:
> >>
> >>> $ git show_ref
> >>> error: invalid key: pager.show_ref
> >>> er
On Fri, Feb 06, 2015 at 02:27:31PM -0800, Junio C Hamano wrote:
> Jeff King 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
On Fri, Feb 6, 2015 at 8:44 PM, Junio C Hamano wrote:
> Jeff King 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 'g
On Fri, Feb 6, 2015 at 3:06 PM, Junio C Hamano wrote:
> Junio C Hamano 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 be in the future?
I'd drop th
Junio C Hamano 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,
this would be
Junio C Hamano 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 to file B
Jeff King 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 names are
Jeff King 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 to
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, whi
On Fri, Feb 6, 2015 at 3:43 PM, Kyle J. McKay wrote:
> On Feb 6, 2015, at 12:05, Junio C Hamano wrote:
>> "Kyle J. McKay" 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 the fact that your te
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 simpl
On Feb 6, 2015, at 12:05, Junio C Hamano wrote:
"Kyle J. McKay" 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 u
On Fri, Feb 06, 2015 at 11:44:38AM -0800, Junio C Hamano wrote:
> Jeff King 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 gi
On Fri, Feb 06, 2015 at 12:14:35PM -0800, Junio C Hamano wrote:
> Jeff King 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
> t
Jeff King 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" subco
"Kyle J. McKay" 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 uses it.
Do
On Feb 6, 2015, at 02:00, Eric Sunshine wrote:
On Fri, Feb 6, 2015 at 4:35 AM, Kyle J. McKay
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
+#undef DEPRECATED_ATTRIBUTE
+#defi
Jeff King 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 fr
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 G
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
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 comman
On Thu, Feb 5, 2015 at 11:53 PM, Junio C Hamano 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 maint)
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, judging
On Fri, Feb 6, 2015 at 4:35 AM, Kyle J. McKay 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 MAC_OS_X_VERSION_10
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 AvailabilityMa
25 matches
Mail list logo
