Re: [PATCH] remote-helpers: point at their upstream repositories
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 of experience you surely have in the field. As a matter of fact, yes I've written many packages, for Debian, Fedora, ArchLinux, and others. Even Windows installers. I'd hardly say that a few PKGBUILDs count. I've written some myself, not hard to do. That said, if I had realised you were going to discuss such a trivial thing - _making_ packages rather than _maintaining_ them in a repo - I'd have dismissed your statement as mere idiotic vitriol. Do you honestly think that Junio has _never made a package?_ Never, on any of the systems he's ever touched, run makepkg or debuild or whathaveyou? I could be wrong here, but I'm fairly sure that Junio is a *nix software developer of some kind or another. You know, given that he's the maintainer of git, kinda might be the case. And I really doubt that any *nix dev, _anywhere_, could have _any_ sort of success without looking sideways once or twice at a package builder, given that pre-release homebrewing of expected packages is only an absolutely critical part of testing. Come on, man. Don't be silly. But that's a red herring. Even if was the worst packager in history, that doesn't make Junio's decision any more correct. No, but it would render your bizarre, tantrum-like accusations as generally baseless. I mean, I don't think anyone actually puts weight on them anyway, but hey, never hurts to shine a spotlight on nonsense. The fact that you think packagers of git would simply package git-remote-hg/bzr as well is pretty appalling. It's not an outlandish thought, in fact, I'd suggest it as probable - provided that they find the projects to be stable and of high quality. Do you want to bet? Not a betting man. However, ignoring that for a moment, I doubt we'd be able to agree on checks and balances for the case where git-remote-hg/bzr were rejected due to the code being of poor quality or unstable. So no, I won't bet, because you hold your own work and opinions as sacrosanct and infallible. You, or someone else, might have to tap them on the shoulder and play nice to _ensure_ they know about them (after all, we all know that packagers _never_ read READMEs, do they), but you're capable of that, I'm sure. In my experience packagers scratch their own itches, and if git-remote-hg/bzr are not their itch, I don't see why any amount of nice poking would make them package them. Some other packager would have to do it, not the Git packagers. If there's a demand, Felipe, and the build process is sane, I can't see why they wouldn't. Package maintainers are aware they provide a service to their distributions. If you really want, poke them _with_ the majority of the necessary work done, hand them the PKGBUILDs/whathaveyou yourself. Pre-scratch the itch if you really feel they won't care. -- 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
Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote: James Denholm nod.h...@gmail.com 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 understanding FETCH_HEAD will always parse to a committish - I could have missed something, of course. $ git fetch git://repo.or.cz/alt-git junio-gpg-pub $ git rev-parse FETCH_HEAD^0 That would be a problem... Sadly I doubt I'll have time to develop a solution into subtree's overall design before the end of June. As that eventual change would probably involve altering the inclusions of this fix, and that users have a workaround in adding either squashed commits or referencing lightweight tags, would you rather drop the patch and wait for that? --- 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
Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
Junio C Hamano wrote: To me, it looks like all that is necessary is to accept your patch but with a three-byte tightening to detect such a pathological case and signal an error, which is what , which I added to your new line that sets revp=$(peel_committish ...), is about. This patch, with or without these extra three bytes, will not be part of the upcoming 2.0 release anyway, so we have enough time to iron it out. Ah, right, sorry, somehow I missed the in the amended patch. I don't know how I overlooked that. That indeed would be plenty. Sorry, I am lost. What would be a problem exactly? A FETCH_HEAD can be pointing at an object that is not committish, and users involved, both at the originating end who controls the repository you fetched from and at the receiving end who wanted to fetch the object, are *not* expeting to be able to make a merge of such an object anyway. My suggestion was not to ask you to come up with a sane behaviour when the user told us to add a single blob with subtree add; it was merely to detect such unintended use as an error. Yeah, what I meant by problem was the possibility of finding a way to pre-empt the case of a tag pointing to a blob and handle it as gracefully as possible, and try to leave the user with their working tree in the state from before the subtree call. The reason I'd suggest it might be worth handling at some point is that (in the far flung future) it may not be out of the scope of subtree to pull not only other repos to a local subtree, but also specific trees (or perhaps blobs) to a local subtree. Conceptually, I'd argue that a sensible future functionality in order to allow subtree users to deal with upstreams that don't split their projects up sanely (cough splutter Facebook's internal). Hence, working out a way to determine tag types, possibly before doing the fetch somehow, would be a boon to that methinks. 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
Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote: James Denholm nod.h...@gmail.com 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 want to stop the damage when it does not peel to a commit? 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 understanding FETCH_HEAD will always parse to a committish - I could have missed something, of course. subtree Will need error-catching at some point, of course, triggering resets or at least suggesting instructions to the user, but I think that's a touch out of the scope of a bugfix at this point (and, to be honest, I personally can't allocate the time to that for about a month due to the dark shadow of academic exams). Indeed, what to do in those cases is probably worth (re-)discussing the overall design and aims of subtree for, and so I'm not confident that I currently know the best way to do that. I'll tentatively queue this. Thanks. Awesome, thanks again for this and the feedback. --- 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
Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag
On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote: Junio C Hamano gits...@pobox.com wrote: Would it be sufficient to do git commit-tree $tree $headp -p $rev^0 in that not squashing codepath instead? On line 561, sure. Do you want me to do a re-roll? Sorry to bump, but do you want a reroll on this? --- 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
[PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag
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 -P oldGit https://github.com/git/git.git tags/v1.8.0 The object ID is a tag and is never peeled, and the git commit-tree call (line 561) slaps us in the face because it doesn't handle tag IDs. Because peeling a committish ID doesn't do anything if it's already a commit, fix by peeling[1] the object ID before assigning it to $rev, as per the patch. [*1*]: Via peel_committish(), from git:git-sh-setup.sh, pre-existing dependency of git-subtree. Reported-by: Kevin Cagle kca...@micron.com Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: James Denholm nod.h...@gmail.com --- I felt that defining revp would be a little more self-documenting than using $rev^0. contrib/subtree/git-subtree.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index dc59a91..eefd720 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -557,8 +557,9 @@ cmd_add_commit() commit=$(add_squashed_msg $rev $dir | git commit-tree $tree $headp -p $rev) || exit $? else + revp=$(peel_committish $rev) commit=$(add_msg $dir $headrev $rev | -git commit-tree $tree $headp -p $rev) || exit $? +git commit-tree $tree $headp -p $revp) || exit $? fi git reset $commit || exit $? -- 1.9.2 -- 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
Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag
Junio C Hamano gits...@pobox.com 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 better choice. I'd suggest that we aren't losing currently-useful information (as it'd be rare-if-ever that a user would look at a hash in their commit logs and think Oh, that's that tag!), but certainly with future development in mind it's more ideal. I see that add_msg does not use anything useful from latest_new, so with the current state of the code, it does not make that much difference (except that it says from commit '$latest_new', and by peeling, the fact that the user wanted to use a tag is lost from the result). Yeah, that might be a worthy thing to porcelain-up in the future with logging the tag name rather than, or in addition to, the hash, as well as a similar change in add_squashed_msg. Would it be sufficient to do git commit-tree $tree $headp -p $rev^0 in that not squashing codepath instead? On line 561, sure. Do you want me to do a re-roll? -- 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
Re: [PATCH v1 23/25] contrib: remove 'hooks/multimail'
Felipe Contreras felipe.contre...@gmail.com wrote: Michael Haggerty wrote: What's more, it has a maintainer who doesn't routinely insult other people on the mailing list, Aaand skiping the rest. Good bye. Aww, Felipe, it's no fair when you ignore other people's slag. How 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
Re: [PATCH] Standardize python shebangs
On 7 May 2014 21:11:53 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: Johan Herland wrote: On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras felipe.contre...@gmail.com wrote: It's better if all our scripts use the same '/usr/bin/env python'. Only if they are source compatible with both Python2 and Python3. See PEP394 URL: http://legacy.python.org/dev/peps/pep-0394/ . Otherwise (for python2-only scripts) '/usr/bin/env python2' is the way to go. It doesn't matter. People and aistributions have to change them anyway. 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). 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
Re: [PATCH] contrib/subtree bugfix: Crash if FETCH_HEAD is tag
On 4 May 2014 16:33:32 GMT+10:00, James Denholm nod.h...@gmail.com 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 -P oldGit https://github.com/git/git.git tags/v1.8.0
The object ID is a tag and is never peeled, and the git commit-tree
call
(line 561) slaps us in the face because it doesn't handle tag IDs.
Because peeling a committish ID doesn't do anything if it's already a
commit, fix by peeling[1] the object ID before assigning it to $rev, as
per the patch.
[*1*]: Via peel_committish(), from git:git-sh-setup.sh
Reported-by: Kevin Cagle kca...@micron.com
Diagnosed-by: Junio C Hamano gits...@pobox.com
Signed-off-by: James Denholm nod.h...@gmail.com
---
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 simplicity, new_squash_commit now also sees the peeled
ID).
Also doesn't surface when using git subtree merge, as git merge can
handle tag objects.
On a side note, if merging a tag without --squash, git merge recognises
that it's a tag and adds a note to the merge commit body. It may be
worth mimicking this when using subtree merge --squash or
subtree add.
contrib/subtree/git-subtree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh
b/contrib/subtree/git-subtree.sh
index dc59a91..9453dae 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -538,7 +538,7 @@ cmd_add_commit()
{
revs=$(git rev-parse $default --revs-only $@) || exit $?
set -- $revs
- rev=$1
+ rev=$(peel_committish $1)
debug Adding $dir as '$rev'...
git read-tree --prefix=$dir $rev || exit $?
I know that subtree isn't exactly the most popular or exciting part of
the project at the moment, but given that this is adding a subtree based
on an annotated tag is a reasonably sensible operation and (to me) the
fix seems reasonably trivial, could I get some eyes on this?
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
Re: [PATCH] Standardize python shebangs
On 8 May 2014 06:57:13 GMT+10:00, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: If you want to use python2, then use '/usr/bin/env python2'. Err, yes, this is what the code does before your patch. Not for all the instances. Well, I guess not all scripts require python2, hence not all scripts declare that they depend on python2. Does it make sense for git to have a strict subset of python scripts as version agnostic, though? Given 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 git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] contrib/subtree bugfix: Crash if FETCH_HEAD is tag
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 nod.h...@gmail.com wrote:
On 4 May 2014 16:33:32 GMT+10:00, James Denholm nod.h...@gmail.com 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 -P oldGit https://github.com/git/git.git tags/v1.8.0
The object ID is a tag and is never peeled, and the git commit-tree
call
(line 561) slaps us in the face because it doesn't handle tag IDs.
Because peeling a committish ID doesn't do anything if it's already a
commit, fix by peeling[1] the object ID before assigning it to $rev, as
per the patch.
[*1*]: Via peel_committish(), from git:git-sh-setup.sh
Reported-by: Kevin Cagle kca...@micron.com
Diagnosed-by: Junio C Hamano gits...@pobox.com
Signed-off-by: James Denholm nod.h...@gmail.com
---
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 simplicity, new_squash_commit now also sees the peeled
ID).
Also doesn't surface when using git subtree merge, as git merge can
handle tag objects.
On a side note, if merging a tag without --squash, git merge recognises
that it's a tag and adds a note to the merge commit body. It may be
worth mimicking this when using subtree merge --squash or
subtree add.
contrib/subtree/git-subtree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh
b/contrib/subtree/git-subtree.sh
index dc59a91..9453dae 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -538,7 +538,7 @@ cmd_add_commit()
{
revs=$(git rev-parse $default --revs-only $@) || exit $?
set -- $revs
- rev=$1
+ rev=$(peel_committish $1)
debug Adding $dir as '$rev'...
git read-tree --prefix=$dir $rev || exit $?
I know that subtree isn't exactly the most popular or exciting part of
the project at the moment, but given that this is adding a subtree based
on an annotated tag is a reasonably sensible operation and (to me) the
fix seems reasonably trivial, could I get some eyes on this?
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
[PATCH] contrib/subtree bugfix: Can't `add` annotated tag
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 -P oldGit https://github.com/git/git.git tags/v1.8.0
The object ID is a tag and is never peeled, and the git commit-tree call
(line 561) slaps us in the face because it doesn't handle tag IDs.
Because peeling a committish ID doesn't do anything if it's already a
commit, fix by peeling[1] the object ID before assigning it to $rev, as
per the patch.
[*1*]: Via peel_committish(), from git:git-sh-setup.sh
Reported-by: Kevin Cagle kca...@micron.com
Diagnosed-by: Junio C Hamano gits...@pobox.com
Signed-off-by: James Denholm nod.h...@gmail.com
---
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 simplicity, new_squash_commit now also sees the peeled
ID).
Also doesn't surface when using git subtree merge, as git merge can
handle tag objects.
On a side note, if merging a tag without --squash, git merge recognises
that it's a tag and adds a note to the merge commit body. It may be
worth mimicking this when using subtree merge --squash or
subtree add.
contrib/subtree/git-subtree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index dc59a91..9453dae 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -538,7 +538,7 @@ cmd_add_commit()
{
revs=$(git rev-parse $default --revs-only $@) || exit $?
set -- $revs
- rev=$1
+ rev=$(peel_committish $1)
debug Adding $dir as '$rev'...
git read-tree --prefix=$dir $rev || exit $?
--
1.9.2
--
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
Re: [PATCH 0/4] remote-hg: more improvements
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 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
Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
On 6 May 2014 08:01, Jeff King p...@peff.net 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 discussion, would it be advisable to wrap this up (barring further discussion) and send it off to Junio rather than waiting for further community consensus? I do not know if lack of discussion is a good reason to consider something in good shape; oftentimes it is a sign that nobody is interested in the area. We usually rely on area maintainers to give an OK to the patches if they are not something that the maintainer himself has an interest in. Yeah, I certainly only meant that in the context of this particular patch, post-review. However, in this case, you did get review, and I think it is pretty easy to see the patches are good even if one does not care about the particular area. So I think they are fine to pass on and apply. Sounds good, I'll send it on up now. Thanks again for the help. Note also that patches like this are a great place to get started, as they help build trust in a contributor, who can later help out with area maintenance. Yeah, to be honest, beyond the immediate goal of getting subtree in more distros, that is kinda the plan. A bit of a practical experience in contributing to the project, learning the specific ropes and such before proposing more substantial discussion and fixes/changes. --- 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
[PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup
git:Documentation/Makefile and others establish RM ?= rm -f as a convention for rm calls in clean rules, hence follow this convention instead of simply forcing clean to use rm. subproj and mainline no longer need to be removed in clean, as they are no longer created in git:contrib/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: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index f3834b5..d888d45 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -12,7 +12,8 @@ man1dir ?= $(mandir)/man1 -include ../../GIT-VERSION-FILE # this should be set to a 'standard' bsd-type install program -INSTALL ?= install +INSTALL ?= install +RM ?= rm -f ASCIIDOC = asciidoc XMLTO= xmlto @@ -60,7 +61,7 @@ test: $(MAKE) -C t/ test clean: - rm -f *~ *.xml *.html *.1 - rm -rf subproj mainline + $(RM) $(GIT_SUBTREE) + $(RM) *.xml *.html *.1 .PHONY: FORCE -- 1.9.2 -- 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
[PATCH v2 2/5] contrib/subtree/Makefile: Use GIT-VERSION-FILE
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 p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 87797ed..f63334b 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -6,7 +6,10 @@ mandir ?= $(prefix)/share/man libexecdir ?= $(prefix)/libexec/git-core man1dir ?= $(mandir)/man1 -gitver ?= $(word 3,$(shell git --version)) +../../GIT-VERSION-FILE: FORCE + $(MAKE) -C ../../ GIT-VERSION-FILE + +-include ../../GIT-VERSION-FILE # this should be set to a 'standard' bsd-type install program INSTALL ?= install @@ -44,11 +47,11 @@ $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(gitver) $^ + -agit_version=$(GIT_VERSION) $^ $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(gitver) $^ + -agit_version=$(GIT_VERSION) $^ test: $(MAKE) -C t/ test @@ -56,3 +59,5 @@ test: clean: rm -f *~ *.xml *.html *.1 rm -rf subproj mainline + +.PHONY: FORCE -- 1.9.2 -- 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
[PATCH v2 3/5] contrib/subtree/Makefile: s/libexecdir/gitexecdir
$(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 p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index f63334b..579bb51 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -3,7 +3,7 @@ prefix ?= /usr/local mandir ?= $(prefix)/share/man -libexecdir ?= $(prefix)/libexec/git-core +gitexecdir ?= $(prefix)/libexec/git-core man1dir ?= $(mandir)/man1 ../../GIT-VERSION-FILE: FORCE @@ -33,8 +33,8 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH) doc: $(GIT_SUBTREE_DOC) $(GIT_SUBTREE_HTML) install: $(GIT_SUBTREE) - $(INSTALL) -d -m 755 $(DESTDIR)$(libexecdir) - $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir) + $(INSTALL) -d -m 755 $(DESTDIR)$(gitexecdir) + $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(gitexecdir) install-doc: install-man -- 1.9.2 -- 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
[PATCH v2 4/5] contrib/subtree/Makefile: Doc-gen rules cleanup
git:Documentation/Makefile establishes asciidoc/xmlto calls as being handled through their appropriate variables, Hence, change to bring into congruency with. Similarly, MANPAGE_XSL exists in git:Documentation/Makefile, while MANPAGE_NORMAL_XSL does not outside contrib/subtree. Hence, replace MANPAGE_NORMAL_XSL with MANPAGE_XSL. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- 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/contrib/subtree/Makefile @@ -14,8 +14,11 @@ man1dir ?= $(mandir)/man1 # this should be set to a 'standard' bsd-type install program INSTALL ?= install -ASCIIDOC_CONF = ../../Documentation/asciidoc.conf -MANPAGE_NORMAL_XSL = ../../Documentation/manpage-normal.xsl +ASCIIDOC = asciidoc +XMLTO= xmlto + +ASCIIDOC_CONF = ../../Documentation/asciidoc.conf +MANPAGE_XSL = ../../Documentation/manpage-normal.xsl GIT_SUBTREE_SH := git-subtree.sh GIT_SUBTREE:= git-subtree @@ -43,14 +46,14 @@ install-man: $(GIT_SUBTREE_DOC) $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) - xmlto -m $(MANPAGE_NORMAL_XSL) man $^ + $(XMLTO) -m $(MANPAGE_XSL) man $^ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) - asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ + $(ASCIIDOC) -b docbook -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(GIT_VERSION) $^ $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) - asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ + $(ASCIIDOC) -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(GIT_VERSION) $^ test: -- 1.9.2 -- 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
[PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
contrib/subtree/Makefile is a shambles in regards to it's consistency with other makefiles, which makes subtree overly painful to include in build scripts. 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 path. Patches 1/5 through 3/5 resolve these. The cleanup fixes (4/5 and 5/5) are based on precedents set by other makefiles across the project. One problem is foreseen: 3/5 will necessitate that package maintainers who already have git-subtree included in their packages update their build-scripts. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com Based-on-patch-by: Dan McGee dpmc...@gmail.com 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 cleanup contrib/subtree/Makefile: clean rule cleanup contrib/subtree/Makefile | 38 +++--- 1 file changed, 23 insertions(+), 15 deletions(-) -- 1.9.2 -- 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
[PATCH v2 1/5] contrib/subtree/Makefile: scrap unused $(gitdir)
In 7ff8463dba0d74fc07a766bed457ae7afcc902b5, the references to gitdir were removed but the assignment itself wasn't. Hence, drop the gitdir assignment. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 4030a16..87797ed 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -4,7 +4,6 @@ prefix ?= /usr/local mandir ?= $(prefix)/share/man libexecdir ?= $(prefix)/libexec/git-core -gitdir ?= $(shell git --exec-path) man1dir ?= $(mandir)/man1 gitver ?= $(word 3,$(shell git --version)) -- 1.9.2 -- 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
Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
Junio C Hamano gits...@pobox.com wrote: It is funny to see sign-off on 0/5 ;-) Yeah, I wasn't quite sure of exact protocol, and sort-of defaulted to sign-all-the-things mode. By the way, this is v3, not v2, no? It was somewhat confusing to see Peff saying filfre to add my reviewed-by 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. 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
Re: [PATCH 1/9] Define a structure for object IDs.
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab sch...@linux-m68k.org wrote: David Kastrup d...@gnu.org writes: It does not as far as I can see guarantee that a pointer to something of the same type of its first member can be converted to a pointer to a struct even if the struct only contains a member of such type. This sentence doesn't make any sense. If you have an object of struct type then any pointer to the first member of the object can only be a pointer to the one and same object. I think what David means is that a pointer to a wrapper can be derefed into 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 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
Re: [PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup
On 5 May 2014 15:09:39 GMT+10:00, Jeff King p...@peff.net 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/contrib/subtree/Makefile @@ -11,8 +11,9 @@ man1dir ?= $(mandir)/man1 -include ../../GIT-VERSION-FILE -# this should be set to a 'standard' bsd-type install program -INSTALL ?= install +# These should be set to 'standard' bsd-type programs +INSTALL ?= install +RM ?= rm -f 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 weirder between systems. So you might want to leave that comment as-is. True. I might just buff that out when sending the patch to Junio, unless protocol dictates otherwise - a reroll for a single comment line seems a bit excessive to me at the moment. 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
Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
On 5 May 2014 15:08:04 GMT+10:00, Jeff King p...@peff.net 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 path. Patches 1/5 through 3/5 resolve these. The cleanup fixes (4/5 and 5/5) are based on precedents set by other makefiles across the project. Thanks, these all look sane to me (I do not use subtree, but since it's just about Makefiles, it was pretty easy to review). Thanks for the review! Given that subtree subtree doesn't really generate a lot of discussion, would it be advisable to wrap this up (barring further discussion) and send it off to Junio rather than waiting for further community consensus? 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
Re: [PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup
On 6 May 2014 07:49:30 GMT+10:00, Jeff King p...@peff.net 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 weirder between systems. So you might want to leave that comment as-is. True. I might just buff that out when sending the patch to Junio, unless protocol dictates otherwise - a reroll for a single comment line seems a bit excessive to me at the moment. I don't think it is that big a deal either way. It's fine to tweak when you send re-roll the final for Junio. Sometimes for trivial fixups like this, Junio can just tweak it as he applies, but I do not know if he is even paying attention to this thread, so you may want to re-post anyway to get his attention. Sure, sounds good and will do. Either way, feel free to add my: Reviewed-by: Jeff King p...@peff.net Awesome, thanks again. 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
Re: Pull is Mostly Evil
Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you 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 shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold 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
Re: Pull is Mostly Evil
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com 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 don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you 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. You mean this thread[1] in which I sent 14 mails directly to you? Yeah, I din't engage in that discussion at all! Yeah, you didn't. Instead you danced, but I guess it's really all said and done now so eh, have your point. If their argument is good, their argument is good. The problem, though, is that time and time again you've shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold it. I can show you evidence of how that's a blatant lie. Just two days ago I changed my mind because somebody provided a good argument. And I can show you evidence of you being indiscourseable on the topic of your pet proposals, but I won't, because you're indiscourseable on the meta similarly. But I'm not going to bother any more with you, you are just spreading lies and tainting the discussion. Well, maybe we'll see what other folks think. 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
[PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
contrib/subtree/Makefile is a shambles in regards to it's consistency with other makefiles, which makes subtree overly painful to include in build scripts. 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 path. Patches 1/5 through 3/5 resolve these. The cleanup fixes (4/5 and 5/5) are based on precedents set by other makefiles across the project. One problem is foreseen: 3/5 will necessitate that package maintainers who already have git-subtree included in their packages update their build-scripts. Signed-off-by: James Denholm nod.h...@gmail.com Based-on-patch-by: Dan McGee dpmc...@gmail.com 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 cleanup contrib/subtree/Makefile: clean rule cleanup contrib/subtree/Makefile | 40 1 file changed, 24 insertions(+), 16 deletions(-) -- 1.9.2 -- 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
[PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup
git:Documentation/Makefile and others establish RM ?= rm -f as a convention for rm calls in clean rules, hence follow this convention instead of simply forcing clean to use rm. subproj and mainline no longer need to be removed in clean, as they are no longer created in git:contrib/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 Denholm nod.h...@gmail.com --- Admittedly, git:Makefile does not itself follow the RM ?= rm -f setup, instead using RM = rm -f, but I felt that there were probably $ARCANE_REASONS for this. Also, Peff, you were right about the dirs. contrib/subtree/Makefile | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index f3834b5..4f96a24 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -11,8 +11,9 @@ man1dir ?= $(mandir)/man1 -include ../../GIT-VERSION-FILE -# this should be set to a 'standard' bsd-type install program -INSTALL ?= install +# These should be set to 'standard' bsd-type programs +INSTALL ?= install +RM ?= rm -f ASCIIDOC = asciidoc XMLTO= xmlto @@ -60,7 +61,7 @@ test: $(MAKE) -C t/ test clean: - rm -f *~ *.xml *.html *.1 - rm -rf subproj mainline + $(RM) $(GIT_SUBTREE) + $(RM) *.xml *.html *.1 .PHONY: FORCE -- 1.9.2 -- 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
[PATCH v2 1/5] contrib/subtree/Makefile: scrap unused $(gitdir)
All references were removed in 7ff8463dba0d74fc07a766bed457ae7afcc902b5, but the assignment itself wasn't. Hence, drop gitdir assignment. Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 4030a16..87797ed 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -4,7 +4,6 @@ prefix ?= /usr/local mandir ?= $(prefix)/share/man libexecdir ?= $(prefix)/libexec/git-core -gitdir ?= $(shell git --exec-path) man1dir ?= $(mandir)/man1 gitver ?= $(word 3,$(shell git --version)) -- 1.9.2 -- 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
[PATCH v2 2/5] contrib/subtree/Makefile: Use GIT-VERSION-FILE
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 nod.h...@gmail.com --- contrib/subtree/Makefile | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 87797ed..f63334b 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -6,7 +6,10 @@ mandir ?= $(prefix)/share/man libexecdir ?= $(prefix)/libexec/git-core man1dir ?= $(mandir)/man1 -gitver ?= $(word 3,$(shell git --version)) +../../GIT-VERSION-FILE: FORCE + $(MAKE) -C ../../ GIT-VERSION-FILE + +-include ../../GIT-VERSION-FILE # this should be set to a 'standard' bsd-type install program INSTALL ?= install @@ -44,11 +47,11 @@ $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(gitver) $^ + -agit_version=$(GIT_VERSION) $^ $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ - -agit_version=$(gitver) $^ + -agit_version=$(GIT_VERSION) $^ test: $(MAKE) -C t/ test @@ -56,3 +59,5 @@ test: clean: rm -f *~ *.xml *.html *.1 rm -rf subproj mainline + +.PHONY: FORCE -- 1.9.2 -- 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
[PATCH v2 4/5] contrib/subtree/Makefile: Doc-gen rules cleanup
git:Documentation/Makefile establishes asciidoc/xmlto calls as being handled through their appropriate variables, Hence, change to bring into congruency with. Similarly, MANPAGE_XSL exists in git:Documentation/Makefile, while MANPAGE_NORMAL_XSL does not outside contrib/subtree. Hence, replace MANPAGE_NORMAL_XSL with MANPAGE_XSL. Signed-off-by: James Denholm nod.h...@gmail.com --- 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/contrib/subtree/Makefile @@ -14,8 +14,11 @@ man1dir ?= $(mandir)/man1 # this should be set to a 'standard' bsd-type install program INSTALL ?= install -ASCIIDOC_CONF = ../../Documentation/asciidoc.conf -MANPAGE_NORMAL_XSL = ../../Documentation/manpage-normal.xsl +ASCIIDOC = asciidoc +XMLTO= xmlto + +ASCIIDOC_CONF = ../../Documentation/asciidoc.conf +MANPAGE_XSL = ../../Documentation/manpage-normal.xsl GIT_SUBTREE_SH := git-subtree.sh GIT_SUBTREE:= git-subtree @@ -43,14 +46,14 @@ install-man: $(GIT_SUBTREE_DOC) $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) - xmlto -m $(MANPAGE_NORMAL_XSL) man $^ + $(XMLTO) -m $(MANPAGE_XSL) man $^ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) - asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ + $(ASCIIDOC) -b docbook -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(GIT_VERSION) $^ $(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) - asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ + $(ASCIIDOC) -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(GIT_VERSION) $^ test: -- 1.9.2 -- 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
[PATCH v2 3/5] contrib/subtree/Makefile: s/libexecdir/gitexecdir
$(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 nod.h...@gmail.com --- contrib/subtree/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index f63334b..579bb51 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -3,7 +3,7 @@ prefix ?= /usr/local mandir ?= $(prefix)/share/man -libexecdir ?= $(prefix)/libexec/git-core +gitexecdir ?= $(prefix)/libexec/git-core man1dir ?= $(mandir)/man1 ../../GIT-VERSION-FILE: FORCE @@ -33,8 +33,8 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH) doc: $(GIT_SUBTREE_DOC) $(GIT_SUBTREE_HTML) install: $(GIT_SUBTREE) - $(INSTALL) -d -m 755 $(DESTDIR)$(libexecdir) - $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir) + $(INSTALL) -d -m 755 $(DESTDIR)$(gitexecdir) + $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(gitexecdir) install-doc: install-man -- 1.9.2 -- 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
Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)
Matthew Ogilvie mmogilvi_...@miniinfo.net wrote: On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote: Jeff King p...@peff.net 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 no feedback from anyone. Depending on how much time you have: This may be outside the scope of work you were planning on, While current, immediate focus is really just getting the makefile fixed up and hopefully then have more people package subtree by default, overall I'll very likely extend that to general work on subtree and such. but it might be worth grepping through old mailing list archives for subtree patches that haven't been merged, and see if there is anything worth revisiting/resubmitting. I believe most of the following (at least) kind of languished and died, often with little or no real review and feedback: (...) (I don't know if these are the latest or best versions of these, nor have I really looked at them closely to decide if they are worth including at all. Be sure to exameine not just the discussion around the specific patches, but also the other patches in each series...) Yeah, certainly, I'll be sure to have a sticky-beak. Thanks for pointing those out! 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
Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)
On 4 May 2014 05:22:48 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: I think you should take a look at the Makefile of contrib/remote-helpers. I bet something simple like that would work just fine for subtree. The current makefile is simple enough, just quirky and likes to be a special 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
Re: Recording the current branch on each commit?
On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com 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 merits are currently unknown to the rest of a community. It's still the same thing. Nobody gets assigned any tasks; people choose their own tasks, and they might choose tasks that other people were doing. Right. Instead of bashing about in the haberdashery of misinterpretation, allow me to explicitly restate my original point. You cannot expect that anybody but yourself is willing to propose, debate the merits of and otherwise defend patches that you have authored (herein your patches, implying authorship, not ownership). Some people *may*, but if they do not or do not successfully, that does not imply the stagnation of the project. Ultimately, the only person who can ensure that a patch is championed, and the only person who need feel a responsibility to, is the author, and that responsibility is only ever to themselves. TL,DR: Champion your own patches, don't ask others to. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; oneperson doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. No. John might have sent a patch series X, and maybe he didn't explain correctly how it would benefit the project. Later on Mark finds out how those patches would be useful for himself and takes upon himself to get them merged, so he cleans them up and send an updated version with a clear explanation of how they would be useful. It's still the same proposal X, but a different person and a different strategy to get them merged. In other words, the fact that the community has not yet accepted the merits of an approach doesn't mean that another person cannot champion it. As addressed above. The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting. It doesn't matter if you want to go hunting and I want to buy bread, either one of those is better than starving to death. In the Git project though, we choose to starve to death. Neither were my patches picked, nor did anybody else step up with a different proposal, we just did nothing, which is what we always do. Not at all. Hunting may necessitate a negative side effect, such as betraying vegetarianism, having to go out into the jungle for five days, risk life and limb, and (worse yet) sleep in a tent. This is an especially poor decision if we honestly would prefer a loaf of bread, and we just need to find a way across the street. And again, I'm referring to the general case here, but of your views of what the solution should be clash with what the community view is, you're not going to be able to convince the community to go hunting. To tie in with the above, you sure aren't going to be able to if you don't engage in logical, calm, reasonable discourse. Regards, James. -- 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
Re: Recording the current branch on each commit?
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 thing. I mean this only with good intentions. But Felipe, if you honestly feel that git has stagnated, and that your contributions aren't wanted because we'd rather starve, then perhaps git isn't the right project for you. I'm not saying that you shouldn't work on the git codebase, you could very easily fork it and make the innovative SCMS none of us can see, and kill git. Can be done, if hunting really is the best choice as you say. -- 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
Re: Recording the current branch on each commit?
On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com 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 the innovative SCMS none of us can see, and kill git. Can be done, if hunting really is the best choice as you say. I already made a fork: http://felipec.wordpress.com/2013/10/28/git-fc/ Sweet. So now you're going to get open source journalism interested in git-fc and gain a groundswell of support, right? So that we can all have egg on our faces when it takes off and is proven superior... Right? -- 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
Re: Recording the current branch on each commit?
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com 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 include you. % git log --author=nod.h...@gmail.com master empty Sure it does. I didn't (and don't) have any impact on the debate and resulting community views, but I recall recently that I prescribed to the arguments that default aliases are a bad idea. I'm not arrogant enough to suggest that my views matter at this point, but if git-fc is proven superior by community adoption, I would be as wrong as anyone else who held that view. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? 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
Re: Recording the current branch on each commit?
On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com 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 include you. % git log --author=nod.h...@gmail.com master empty Sure it does. No it doesn't. Unless you have some credentials in the Git community, which come after several contributions, your opinion carries no weight at all. This might not be ideal, but that's the way it is. You have no credentials, your opinion doesn't count. You are not part of the we you referred before. I find your lack of reading comprehension... disturbing. To reassert the my full statement, as you so hastily truncated: James Denholm wrote: Sure it does. I didn't (and don't) have any impact on the debate and resulting community views, but I recall recently that I prescribed to the arguments that default aliases are a bad idea. I'm not arrogant enough to suggest that my views matter at this point, but if git-fc is proven superior by community adoption, I would be as wrong as anyone else who held that view. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? If by convince you mean apply my patches, my patches are still getting applied [1]. (...) [1] https://www.ohloh.net/p/git/contributors?sort=latest_commit But that isn't the case. If it was, you wouldn't have a blog post up about how git-fc has default aliases (and such), while git does not. You wouldn't have another post exclaiming frustration at the pace of development, and how certain contributions of yours have been ignored. Sure, a subset of your patches are being accepted, but if the ones you cared about weren't, this discussion wouldn't have even occurred. 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, vegetables, anything. Instead they choose to starve to death. Not at all. You propose solutions, rather than *just* calling for any solution to be accepted. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. And I'm done discussing with you. Your comments are content-free. Only code-free. And that's because this is a people problem, Felipe, not a code problem. 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
Re: Recording the current branch on each commit?
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, vegetables, anything. Instead they choose to starve to death. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. Wrong. The problems are ackowledged, no other proposals are put forward, nothing gets done. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? -- 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
Re: Recording the current branch on each commit?
Felipe Contreras wrote: You are obviously not very good with analogies, or reading for that matter. The answer is quoted right in the begginning of the mail. Congratulations, you've achieved a mail quote loop. I'll rephrase the question and it's context. Please attempt to answer it. You've expressed frustration at the pace of git's development. You've expressed frustration at how your proposals, at least a subset thereof, are not being chosen as solutions. You've expressed belief that this is to the fatal detriment of git. And you've expressed that you believe this situation won't change. Given that you feel you have the necessary solutions and you have git-fc with which to drive them into the world, why are you sticking around expressing exasperation and inevitable fatality? Why not promote git-fc as the superior option, 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
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com 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 in a less abrasive maner. It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. They're your patches, nobody else is going to champion them for you. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. You neglect the possibility that your personal view of what git should be differs from other people's. One's views and values aren't correct just on the virtue of that person having them, and you are no different, Felipe. -- 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
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com 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 effort everbody chimes in to do different things. 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 merits are currently unknown to the rest of a community. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; oneperson doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. Different situation. Note that I here specify a proposal's merits are known and accepted, rather than the issue at hand. I'd be very, very surprised if there was even a few cases in human history where a community was able to collaboratively work, efficiently and successfully, on a proposal where the merits were still hotly discussed (barring, of course, exploratory works). If a patch series is event considered to be merged upstream, that means it doesn't just benefit the person sending it (e.g. me), it benefits all Git users. So my patches where by the project and for the project. And yes, of course, but you misinterpret my use of one's patches to describe ownership or who benefits from those patches. I merely discuss authorship and seek not to imply anything more. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. You neglect the possibility that your personal view of what git should be differs from other people's. Except that in this case virtually everyone agreed the default was wrong. I already said that. Clarly you didn't read the relevant discussions where everyone, including Linus Torvalds, agreed. Did you? I'm talking about the general case, not a _specific_ patch or set thereof authored by you or any one person. Again, though, recall that even if a community has agreed that the current state is non-ideal, that doesn't mean that they agree that a _specific proposal_ is the right one. If A and B agree that they are starving to death, and B proposes they engage in hunting to resolve this, A might disagree because he'd rather just go across the street and buy a loaf of bread. Although as I write this it seems Junio has described this exact thing in a following mail, and on the following debate: A patch relates to more than a personal view of what a project shouldn't be. Even if it's solving an acknowledged problem, it by it's nature relates to a view of what the solution should be. Ergo, in the specific case, your view of what the solution should have been did not match the community's view of the same, even if the overall problem was acknowledged by the entire community. The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting. Sincerely and analogically yours, 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
Re: Recording the current branch on each commit?
I'm skipping a lot of the discussion here, sorry about that, but on one particular note: Jeremy Morton ad...@game-point.net wrote: (...) and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Not really. While different groups will have different values, the greater git community seems to prefer short _first lines_, of fifty chars or less, while the _body_ should be as verbose as it needs to be (but not more than). Ergo, while the first line shouldn't contain a swath of metadata, the body can easily. A particularly good example of this is almost every commit to the git project itself - there areSigned-of-by lines and such everywhere in the logs. 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. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water 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 git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton ad...@game-point.net 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. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water 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.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a branch checked into trailer. In that case, write something onto your post-commit hook and the functionality would be achieved. A relates-to line doesn't need a change to the structure of git commits. -- 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
Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)
Jeff King p...@peff.net wrote: I think the problem is that contrib/subtree does not really have an active dedicated area maintainer. Yeah, I can see how that might become a bit of a problem. I was actually thinking of doing a bit of work on subtree beyond this specific patch, so hopefully that won't be a show-stopper. We'll see what happens, I guess. Your changes look fine to me from a cursory examination. It would probably be more readable as four patches (the 3 fix points from your list, plus the minor fixes mentioned at the end). Then each patch stands on its own, can say what problem it's fixing, and how. (...) 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. subproject and mainline are actually 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
Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)
Jeff King p...@peff.net 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. subproject and mainline are actually made in contrib/subtree, but I'll look at perhaps fixing that when I split the proposal into a series as you suggest. Are they? I couldn't find any reference to them as directories except in the test script, and doing a make from contrib/subtree didn't create them. Yeah, I could be wrong as I don't have the code on-hand at the moment, but from memory they're made and populated by the test script as well. Either way I'll move all that into a subdir of t/ and rejigger the thing, if investigation reveals that as the Done Thing. I'll leave it to you to investigate further whether the clean rules are cruft or not, but certainly if they are, cleaning up cruft is a good thing. -- 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
Re: What is missing from Git v2.0
Felipe Contreras wrote: This is a false dichotomy; there aren't just two kinds of Git users. There is such a category of Git users who are not fresh-out-of-the-boat, yet not power users either. Oh, I didn't mean to suggest a dichotomy of any kind. However these are the two groups (I suggest) are the most immediately relevant - one calls for change, and the other would be negatively impacted. Unless the aliases are already there by default. Others, with knowledge far beyond mine, have pointed out the problems with this. I'd suggest the argument most relevant to my own statements is how it impacts the learning proccess, and makes it more likely that users will learn aliases _as_ commands, which of course is incorrect and potentially harmful. And if default aliases were such a bad idea, why do most (all?) version control systems out there have them? I'm so tempted just to sass and say that it's because they aren't git... But on a more serious note, a feature (any feature) being in one vcs doesn't mean, by default, that it's right for git. The status quo may be a mistake on the part of it's followers. (And, historically, has been many times - for an transculturally-acceptable example, consider the rejection of Galileo's astronomical research by the Vatican of the time.) Just because Mercurial et. all does something doesn't mean git needs to, or even should. It needs objective 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
Re: What is missing from Git v2.0
Felipe Contreras wrote: David Lang wrote: agreed, of all the things that people complain about regarding learning git, the fact that the commands are words instead of cryptic 2 letter abberviations is not one of them. It is when they start to use Git seriously and type them a lot. Felipe, I think you refute your own point here, because people _learning_ git aren't power-users. They might be one day, but not that day. If power-users are complaining that commit is too long, but aren't setting their own aliases, it's quite possible they just don't know about aliases. Because if they _did_ know about aliases, they'd set one. Even a shell alias, not nessecarily a git alias. I submit to you (with the backing of all my prior experience contributing to git... Which is too say none) that the problem is not that git 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
