Re: libgit2 status
The 27/08/12, Junio C Hamano wrote: d...@cray.com writes: 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? That something will not be the git core itself. Otherwise we will lose a stable reference implementation to catch its bugs. This is exactly what I'm most afraid about. I tend to think it's a chicken-and-egg problem, too. Do you expect one big merge of a very stable libgit2 at some point? Because, asking others to implement widely used tools on top of libgit2 in order to have it as stable/tested as curl is not going to happen, IMHO. 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. -- Nicolas Sebrecht -- 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
The 25/08/12, Vicent Marti wrote: The development of libgit2 happens 100% in the open. I don't know what commercial entity are you talking about, but there are several companies and independent contributors working on the Library at the moment. Right but as far as I'm aware of Junio had reserves about libgit2 integration into git due to issues making repositories broken. Though, having libgit2 as git core would make libgit2 the the-facto standard which would a *very* big plus. Also, I guess that integration into git would mean more developers contibuting for libgit2. Currently, issues seems to be a blocker for integration. So, libgit2 might appear to be a marginal/risky alternative for a long time which is sad. [ I'm somewhat in the same situation of OP. ] -- Nicolas Sebrecht -- 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] Re: git-am: indicate where a failed patch is to be found.
The 12/07/12, Junio C Hamano wrote: It does not matter at all that 0001-foo.patch only has a single patch. If you are going to fix up the patch after you saw git am failed, you will be fixing .git/rebase-apply/patch with your editor and re-run git am without arguments, at which point git am will not look at your 0001-foo.patch file at all. Hugh! Didn't know that. Is it actually expected from users to manually edit .git/rebase-apply/patch path? I can't find any reference about that in the documentation and it really sounds like interfering with the git internals. Shouldn't git-am/git-rebase expose this to the user (I'm thinking about something like git am --edit-offending-patch git am --fix-patch )? -- Nicolas Sebrecht -- 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
