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
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: [PATCH] subtree/Makefile: Standardize (esp. for packagers)
Jeff King 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 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: 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 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 are"Signed-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 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: Recording the current branch on each commit?
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 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 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?
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 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 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 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 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 >> >> 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
[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 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 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 --- 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 --- 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 --- 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 --- 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 --- 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 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 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 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: 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 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
Re: [PATCH 1/9] Define a structure for object IDs.
On 5 May 2014 19:23:06 GMT+10:00, Andreas Schwab wrote: >David Kastrup 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 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 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 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 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: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass
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 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 Signed-off-by: James Denholm --- 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 Signed-off-by: James Denholm --- 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 Signed-off-by: James Denholm --- 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 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/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 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 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 Signed-off-by: James Denholm --- 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 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] Standardize python shebangs
On 7 May 2014 21:11:53 GMT+10:00, Felipe Contreras wrote: >Johan Herland wrote: >> On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras >> 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 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 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
>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 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 wrote: >Felipe Contreras writes: > >> Matthieu Moy wrote: >>> Felipe Contreras 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 wrote:
> 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 -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
>>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 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
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 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] contrib/subtree bugfix: Can't `add` annotated tag
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 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 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] contrib/subtree bugfix: Can't `add` annotated tag
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 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 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 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 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 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 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 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] remote-helpers: point at their upstream repositories
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 > 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. 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. -- 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] 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
