Re: libgit2 status
Junio C Hamano gits...@pobox.com writes: And the last one should really be a longer term item. It is more important for its codebase to get mature and robust, and that can only happen by various projects and products (e.g. GitHub for Mac) using it to improve it. I do not think subtree (or anything in contrib/ for that matter) is part of the core stuff of git, and do not see a problem; such a move may help both subtree and libgit2. Over a much longer timeperiod, I wouldn't be surprised if some core stuff gets reimplemented on top of libgit2 and distributed as part of the git-core. I am hoping to move git-subtree into core once it performs a little better and I've fixed a couple of bugs. Will basing it on libgit2 delay that process significantly? Six months delay is no problem. 2 years would be problematic. I would be happy to be a guinea pig for libgit2 in order to improve it, but I don't want to significantly impact git-subtree's move to core. I'll have to figure out the right balance there given feedback. -Dave -- 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: libgit2 status
Junio C Hamano gits...@pobox.com writes: I would be happy to be a guinea pig for libgit2 in order to improve it, but I don't want to significantly impact git-subtree's move to core. I'll have to figure out the right balance there given feedback. I expect it will take some time for libgit2 to allow our Makefile to start saying LDFLAGS += -libgit2; it will need to become as stable and widespread as other libraries we depend on, e.g. -lz and -lcurl. Well that's a chicken-and-egg problem, isn't it. How will a library become widespread unless something uses it? Would it be enough to have libgit2 as an installable package in the major distributions? -Dave -- 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: libgit2 status
Junio C Hamano gits...@pobox.com writes: Well that's a chicken-and-egg problem, isn't it. How will a library become widespread unless something uses it? That something will not be the git core itself. Otherwise we will lose a stable reference implementation to catch its bugs. Well, the whole question here is whether git-subtree can become part of core if it is based on libgit2. It boils down to what you mean by widespread, I guess. Does widespread mean available as a package in major distributions, installed by default in major distributions or something else? -Dave -- 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: libgit2 status
Nicolas Sebrecht nicolas.s@gmx.fr writes: Do you expect one big merge of a very stable libgit2 at some point? I don't think there's any need to merge libgit2 into the git project source. As a library, it should be perfectly usable as a project of its own, just like libcurl and libz. Otherwise, what about going with this optionnal LDFLAGS += -libgit2 ASAP with good disclaimer that it's only intended for development and testing purpose? Then, git-core could slowly rely on functions of libgit2, one after the other. This makes a lot of sense to me. -David -- 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: (minor concern) git using the pager should not be a default
Junio C Hamano gits...@pobox.com writes: In other words, Porcelain (roughly speaking, those that page by default when their standard output is terminal), are not command line applications; they have a layer on top with a built-in UI. Is status considered a plumbing layer command? Because I have often wondered why it does not use the pager by default. I pipe it through less all the time and it's kind of annoying that it works differently than everything else. -Dave -- 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: (minor concern) git using the pager should not be a default
Jeff King p...@peff.net writes: if you really want it. As of 9bad723 (allow command-specific pagers in pager.cmd, 2010-11-17), you can even set it to an arbitrary pager for each git command. Cool! With all those options, it's amazing that we can still have threads about what should page. :) Well to be fair, it's hard to know when to read the documentation again. :) -Dave -- 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
Grafting Alternate History
I have an unfortunate situation where I have two subversion repositories for the same project, one a public version and one a private version. Because they are mirrors of svn repositories, they have very different histories as far as git is concerned. This is not all that uncommon but of course I would like to manage things in git. git-svn is great for interacting with one svn repository. The public svn repository has a fully-supported git mirror. The private repository also has a fully-supported git mirror. But I need to check in changes to the private repository via git-svn. I eventually need to check in changes to the public repository as well but that is orders of magnitude less frequent. A manual diff+patch+git-svn is acceptable for now. I am wondering if it's possible to graft the history of one of the git mirrors onto an empty branch of the other and share changes between them. I need to take updates from the public repository and apply them to the private repository. This is a frequent operation. I have been essentially using manual diff+patch but that is highly error-prone and annoying. For example, let's say we take a local copy of the private repository. I would like to somehow create an empty branch in that local copy and then populate it with the history of the public repository. I would like to be able to specify a git diff-like command on the public graft branch to get some changes over a range of commits and apply those changes to one of the private branches (say master). If I could use a git-merge-like or git-rebase-like command, so much the better. I would like to do the same in reverse but as I said that is a much less common operation. Has anyone done anything like this before? Is it even theoretically possible to manage disjoint histories like this? Thanks for your help! -Dave -- 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: Grafting Alternate History
Andreas Schwab sch...@linux-m68k.org writes: You can set up (the git mirror of) the public repository as a remote in the private repository and git cherry-pick the commits you want to copy over. Now why didn't I think of that!? :) Thanks for helping an old bumbler along. :) -Dave -- 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: Subtree in Git
Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@initfour.nl writes: Junio, Could you please consider merging the single commit from my subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates In general, in areas like contrib/ where there is a volunteer area maintainer, unless the change something ultra-urgent (e.g. serious security fix) and the area maintainer is unavailable, I'm really reluctant to bypass and take a single patch that adds many things that are independent from each other. Who do you see as volunteer area maintainer for contrib/subtree? My best guess would be Dave. And he already indicated earlier in the thread to be ok with the combined patch as long as you are ok with it. Let's be clear. Junio owns the project so what he says goes, no question. I provided some review feedback which I thought would help the patches get in more easily. We really shouldn't be adding multiple features in one patch. This is easily separated into multiple patches. Then there is the issue of testcases. We should NOT have git-subtree go back to the pre-merge _ad_hoc_ test environment. We should use what the usptream project uses. That will make mainlining this much easier in the future. If Junio is ok with overriding my decisions here, that's fine. But I really don't understand why you are so hesitant to rework the patches when it should be realtively easy. Certainly easier than convincing me they are in good shape currently. :) -David -- 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: Subtree in Git
Junio C Hamano gits...@pobox.com writes: I haven't formed an opinion on the particular change as to how bad its collapsing unrelated changes into a single change is. Maybe they are not as unrelated and form a coherent whole. Maybe not. It is difficult for me to tell which is one of the red flags that caused me to request breaking it up. It's much to hard to review this patch as it is. It conflates multiple features and bug fixes. It includes comments to the effect of, I don't like this but I don't know of a better way. Part of the reson we do reviews is to have people help out and find a better way. I don't think people can do that with the way the patch is currently structured. Note that I was not following the thread very closely, so I may have misread the discussion. I read his Unless Junio accepts... to mean I (dag) still object, but if Junio accepts that patch I object to directly, there is nothing I can do about it. That is very different from I am on the fence and cannot decide it is a good patch or not. I'll let Junio decide; I am OK as long as he is. Yopur first reading is the correct one. -David -- 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: Subtree in Git
Herman van Rink r...@initfour.nl writes: The problem is that I don't have the time to split all these out. Dag has indicated that he does not have the time either. I would have the time to review and integrate separate patches. I do not have time to unwrap the ball of wax and ensure the quality of each feature and bug fix. That is the responsibility of the submitter. You can't expect reviewers to do your work for you. I'm not being harsh, it is simply the reality of how things work in every project I've been involved with. This single ball of wax was already an alternative to the 'messy' merge history it had accumulated. The result of merging from dozens of github forks with numerous levels of parallel/contra-productive whitspace fixes. Yes, we don't really want that history. You have a single patch now. A series of git rebase -i + git add -i should make it easy to separate it into patches for each feature and bug fix, as I suggested previously. It really, really shouldn't be that hard unless the code is atrocious. -David -- 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: Subtree in Git
Herman van Rink r...@initfour.nl writes: What would a random user have to do to get a patch in? I've found a number of subtree related mails on the git-user list go completely unanswerd. Amongst them a patch from James Nylen wich seems very reasonable. I have those patches queued for merging. I've been out of town and otherwise occupied with critical work issues. I'm hoping to process those this weekend. I don't consider myself a gatekeeper and I won't complain if git-subtree patches are accepted without my review, especially if I am caught up in other things as I am now. Anyone is welcome to prepare, review and recommend patches for acceptance. Junio is the real boss anyway. :) The whole point of Free Software is that anyone can contribute. It won't work any other way. But when patches clearly take us backward, yeah, I'm going to have an issue with that. :) -David -- 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: Subtree in Git
David Michael Barr b...@rr-dav.id.au writes: As I have an interest in git-subtree for maintaining the out-of-tree version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted to make some sense of the organic growth that happened on GitHub. It doesn't appear that anyone else is willing to do this, so I doubt there will be any duplication of effort. Go for it! Thanks! -David -- 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: Subtree in Git
Herman van Rink r...@initfour.nl writes: It's hard to tell what's what with one big diff. Each command should get its own commit plus more if infrastructure work has to be done. I realize it's a bit of a pain to reformulate this but git rebase -i makes it easy and the history will be much better long-term. Each command should be described briefly in the commit log. That would indeed be nice, but as some parts interdependent it would be rather complicated. Do the interdependent parts first, then. These should be pure infrastructure. And what is the use if their not fully independently testable. The command should be testable as soon as they are fully implemented, no? I'm thinking about a sequence like this: - Infrastructure for command A (and possibly B, C, etc. if they are interdependent). - Command A + tests - Infrastructure for command B - Command B + tests - etc. If you want to fake a nice history tree then go ahead, I just don't have the energy to go through these commits again just for that. Well, I can't do this either, both because it would take time to get up to speed on the patches and because I have a million other things going on at the moment. So unfortunately, this is going to sit until someone can take it up. Unless Junio accepts your patches, of course. :) Some questions/comments: - Is .gittrees the right solution? I like the feature it provides but an external file feels a bit hacky. I wonder if there is a better way to track this metadata. Notes maybe? Other git experts will have to chime in with suggestions. It's similar to what git submodule does. And when you add this file to the index you can use it on other checkouts as well. Well, I guess I'm not strongly opposed, I was just asking the question. - This code seems to be repeated a lot. Maybe it should be a utility function. Yes that's there three times... So you agree it should be factored? - I removed all this stuff in favor of the test library. Please don't reintroduce it. These new tests will have to be rewritten in terms of the existing test infrastructure. It's not too hard. I've left it in to be able to verify your new tests. Once all the new tests are passing we can get rid of the old one, not before. And as all the old tests are contained in test.sh it should not interfere... No, I'm very strongly against putting this back in. The new tests will have to be updated to the upstream test infrastructure. -Dave -- 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: [ANNOUNCE] Sharness - Test library derived from Git
Matthieu Moy matthieu@grenoble-inp.fr writes: OTOH, having it leave in a subdirectory (e.g. $git/t/Sharness/), and synchronize with stg like subtree merge would be nice for the user. We already have something similar for gitk and git-gui, except that the synchronization is normally one way (subprojects merged into Git, but merging back changes that were made in git.git in these subprojects is more painful). Not really. contrib/git-subtree can really help with this. -Dave -- 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
