Felipe Contreras wrote:
> James Denholm wrote:
> > On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> > > (...) I would venture to say you have never made a package in your
> > > life.
> >
> > And you have, Felipe? Let us see the years o
On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
> (...) I would venture to say you have never made a package in your
> life.
And you have, Felipe? Let us see the years of experience you surely have
in the field.
> The fact that you think packagers of git would simply package
> g
Of course, this is something I haven't yet thought enough about and the
idea is likely full of holes, but hey, I'm nothing if not impractically
idealist.
---
Regards,
James Denholm.
--
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 http://vger.kernel.org/majordomo-info.html
On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote:
> James Denholm writes:
>
> > I'm not sure that can actually happen - peel_committish is essentially
> > implemented as `rev-parse $arg^0` (though with a bit of bling, of
> > course), and to my underst
On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote:
> James Denholm writes:
> > I felt that defining revp would be a little more self-documenting than
> > using $rev^0.
>
> That is a good decision, but as long as we are attempting to peel,
> don't we wa
peel_committish(), from git:git-sh-setup.sh, pre-existing
dependency of git-subtree.
Reported-by: Kevin Cagle
Helped-by: Junio C Hamano
Signed-off-by: James Denholm
---
I felt that defining revp would be a little more self-documenting than
using $rev^0.
contrib/subtree/git-subtree.sh | 3 ++-
1
On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote:
> Junio C Hamano wrote:
> > Would it be sufficient to do
> >
> > git commit-tree $tree $headp -p "$rev^0"
> >
> > in that "not squashing" codepath instead?
>
> On lin
ow ever will anyone argue with you if you don't let
them descend to your level?
Regards,
James Denholm.
--
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 http://vger.kernel.org/majordomo-info.html
Junio C Hamano wrote:
> The "rev" (not "revs") seems to be used by more things than the
> final commit-tree state. Are we losing some useful information by
> peeling it too early like this patch does? (...)
You're not wrong, actually, peeling at the last minute (or at least
later) would be a bet
Felipe, I would ask, suggest, beg, implore you to calm down. It's
generally not a good plan to alienate the maintainer of a project,
regardless of the correctness or incorrectness of one's arguments, but I
fear that's only what you will achieve at the moment.
--
Regards,
James
After a closer look, it seems the initial patch wasn't correctly sent
to the list. Please disregard, I'm re-sending the patch entirely.
Regards,
James Denholm.
On 8 May 2014 07:53, James Denholm wrote:
> On 4 May 2014 16:33:32 GMT+10:00, James Denholm wrote:
>>cmd_add
peel_committish(), from git:git-sh-setup.sh
Reported-by: Kevin Cagle
Diagnosed-by: Junio C Hamano
Signed-off-by: James Denholm
---
NB: This bug doesn't surface when using --squash, as $rev is reassigned
to the squash commit via new_squash_commit before git commit-tree sees
it (though for simplicit
n that some scripts depend on python2
already, and hence we know that the user has python2, and these scripts
run perfectly well on python2, why not mandate that the agnostic subset
be run on python2?
Regards,
James Denholm.
--
To unsubscribe from this list: send the line "unsubscribe
On 4 May 2014 16:33:32 GMT+10:00, James Denholm wrote:
>cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
>then rev-parsed into an object ID. However, if the user is fetching a
>tag rather than a branch HEAD, such as by executing:
>
>$ git subtree add
Yeah, but they shouldn't have to. The build process is
already non-"sane", let's please not make it more so?
Moving all instances of "env python" to be "env python2",
though, that I think is a reasonable solution (if this is even
felt to be a problem)
uot; on v2, noticing you
>posted something new, and not finding v3.
Ah, right. I thought that resending a post-discussion patch was the done
thing, given Documentation/SubmittingPatches, but that a comment line
might not have been worth a version bump.
>Will queue. Thanks.
Awesome, thanks.
MANPAGE_NORMAL_XSL with MANPAGE_XSL.
Reviewed-by: Jeff King
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 579bb51..f3834b5 100644
--- a/contrib
ate their
build-scripts.
Reviewed-by: Jeff King
Signed-off-by: James Denholm
Based-on-patch-by: Dan McGee
James Denholm (5):
contrib/subtree/Makefile: scrap unused $(gitdir)
contrib/subtree/Makefile: Use GIT-VERSION-FILE
contrib/subtree/Makefile: s/libexecdir/gitexecdir
contrib/subtree/Ma
In 7ff8463dba0d74fc07a766bed457ae7afcc902b5, the references to gitdir
were removed but the assignment itself wasn't. Hence, drop the gitdir
assignment.
Reviewed-by: Jeff King
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/co
GVF is already being used in most/all other makefiles in the project,
and has been for _quite_ a while. Hence, drop file-unique gitver and
replace with GIT_VERSION.
Reviewed-by: Jeff King
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 11 ---
1 file changed, 8 insertions
$(libexecdir) isn't used anywhere else in the project, while
$(gitexecdir) is the standard in the other appropriate makefiles. Hence,
replace the former with the latter.
Reviewed-by: Jeff King
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 6 +++---
1 file changed, 3 inser
subtree by "make test". Hence, remove
the rm call for those folders.
Other makefiles don't remove "*~" files, remove the rm call to prevent
unexpected behaviour in the future. Similarly, clean doesn't remove the
installable file, so rectify this.
Reviewed-by:
On 6 May 2014 08:01, Jeff King wrote:
> [fixed David's address in cc list]
Ah, right. Wasn't sure what was going on there.
> On Tue, May 06, 2014 at 07:54:30AM +1000, James Denholm wrote:
>
>> Given that subtree subtree doesn't really generate a lot of discussio
On 6 May 2014 07:49:30 GMT+10:00, Jeff King wrote:
>On Tue, May 06, 2014 at 07:41:29AM +1000, James Denholm wrote:
>
>> >I do not think BSD-ism matters for "rm", as it works pretty much the
>> >same everywhere. "install", on the other hand, is a bit wei
On 5 May 2014 15:08:04 GMT+10:00, Jeff King wrote:
>On Sat, May 03, 2014 at 10:49:30PM +1000, James Denholm wrote:
>
>> The main issues are that calls are made to git itself in the build
>> process, and that a subtree-exclusive variable is used for specifying
>> the exec p
On 5 May 2014 15:09:39 GMT+10:00, Jeff King wrote:
>On Sat, May 03, 2014 at 10:49:35PM +1000, James Denholm wrote:
>
>> diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
>> index f3834b5..4f96a24 100644
>> --- a/contrib/subtree/Makefile
>> +++ b/contri
its internal, sure, but an object of
that internal type can't necessarily pretend to be a
wrapper.
That said, obviously I'm not David, so I could be wrong.
That's what I got from his statement, though.
Regards,
James Denholm.
--
To unsubscribe from this list: send the l
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> Felipe Contreras wrote:
>> >David Lang wrote:
>> >> the vast majority of people here do not take that attitude.
>> >
>> >It's actually the exact opposite. I d
totally
didn't run `git log | grep James Denholm` at one point to demonstrate that I
had not yet made any
contributions,instead of actually engaging in discussion. Oh,
wait.
>If their argument is good, their argument is good.
The problem, though, is that time and time again you've
s
al snowflake. 'sall good, the v2 addresses most
of my immediate concerns with it.
Regards,
James Denholm.
--
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 http://vger.kernel.org/majordomo-info.html
Matthew Ogilvie wrote:
> On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
>> Jeff King wrote:
> Agreed. It also doesn't help that when subtree patches are proposed
> (especially new features instead of obvious bugs), there often seems
> to be little or
GVF is already being used in most/all other makefiles in the project,
and has been for _quite_ a while. Hence, drop file-unique gitver and
replace with GIT_VERSION.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff
MANPAGE_NORMAL_XSL with MANPAGE_XSL.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 579bb51..f3834b5 100644
--- a/contrib/subtree/Makefile
+++ b
$(libexecdir) isn't used anywhere else in the project, while
$(gitexecdir) is the standard in the other appropriate makefiles. Hence,
replace the former with the latter.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
subtree by "make test". Hence, remove
the rm call for those folders.
Other makefiles don't remove "*~" files, remove the rm call to prevent
unexpected behaviour in the future. Similarly, clean doesn't remove the
installable file, so rectify this.
Signed-off-by: James Den
All references were removed in 7ff8463dba0d74fc07a766bed457ae7afcc902b5,
but the assignment itself wasn't. Hence, drop gitdir assignment.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/subtree/Makefile b/contrib/su
ate their
build-scripts.
Signed-off-by: James Denholm
Based-on-patch-by: Dan McGee
James Denholm (5):
contrib/subtree/Makefile: scrap unused $(gitdir)
contrib/subtree/Makefile: Use GIT-VERSION-FILE
contrib/subtree/Makefile: s/libexecdir/gitexecdir
contrib/subtree/Makefile: Doc-gen rules cl
ion, as upon it's succession of git
you would have the argument needed to back your proposals?
Regards,
James Denholm.
--
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 http://vger.kernel.org/majordomo-info.html
Felipe Contreras wrote:
> James Denholm wrote:
>> > Either way your analogy is completely wrong as I already explained
>> > multiple times. I'm not trying to convince vegetarians to go
>> > hunting, I'm saying they should eat something, bread, meat,
>&g
On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
> wrote:
>> >James Denholm wrote:
>> >> So that we can all have egg on our faces when it takes off and is
>> >&g
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> So that we can all have egg on our faces when it takes off and is
>> proven superior... Right?
>
>I don't know what you mean by "we", but it certainly doesn't in
On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> I've no right to say this, given that I've no contributions I'm not
>> saying that you shouldn't work on the git codebase, you could very
>> easily fork it and make th
I've no right to say this, given that I've no contributions
thus far to the project, little history in open source at all,
and have only been following the list for less than a week,
but I'll say it anyway, mayhaps.
And I don't mean this to cause offence, or inspire outrage,
or any similar sort of
On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras
wrote:
>James Denholm wrote:
>> No, true, but my point was more related to that it's ones own "task",
>> perhaps being the better term than job, to debate the merits of one's
>>own work when the meri
Felipe Contreras wrote:
> James Denholm wrote:
>> It's not anybody else's job to take your patches and drizzle them in the
>> honey of respectable discourse.
>
> It's nobody's job to do anything. This a collaborative effort and in a
> collaborative effo
Felipe Contreras wrote:
>David Kastrup wrote:
>> It becomes easier to actually change things when communicating in a
>less
>> abrasive and destructive manner.
>
>That would make sense if I was the only one with the itch. But I wasn't
>the
>only one, so anybody could take the patches and send them
Jeremy Morton wrote:
>On 27/04/2014 22:40, James Denholm wrote:
>>> Also, you don't always have something you can link a commit to in an
>>> issue tracker. You may just be implementing a feature that has been
>>> agreed upon, independently of any such tracker.
cooler conversation with Bob on July 28th" or whatever the
patches relate to.
(Arguably, though, the better solution is to use a ticketing
system, or anything that allows discussion to be easily
referenced.)
Regards,
James Denholm.
--
To unsubscribe from this list: send the line "unsubscribe g
Jeff King wrote:
>On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
>
>> >Do we even make [subproject and mainline] anymore? It looks like
>they are part
>> >of the tests, but the whole test script runs inside its own trash
>> >directory.
>>
ly made in contrib/subtree,
but I'll look at perhaps "fixing" that when I split the proposal
into a series as you suggest.
Thanks for the advice!
Regards,
James Denholm.
--
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 http://vger.kernel.org/majordomo-info.html
jective consideration, not to just be ushered through on the basis
of tradition.
--
James Denholm
--
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 http://vger.kernel.org/majordomo-info.html
has a
single, good,
obvious and memorable commit command.
The problem is that those specific power-users don't know to use aliases.
--
James Denholm
--
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 http://vger.kernel.org/majordomo-info.html
52 matches
Mail list logo
