David Michael Barr 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
Herman van Rink 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
Herman van Rink 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 qual
s 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
Herman van Rink writes:
> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>> Herman van Rink 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 t
Junio C Hamano writes:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
+1
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Andreas Schwab 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
--
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
Jeff King writes:
> if you really want it. As of 9bad723 (allow command-specific pagers in
> pager., 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 b
Junio C Hamano 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
w
Nicolas Sebrecht 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 g
Junio C Hamano 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 questio
Junio C Hamano 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
Junio C Hamano 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
Matthieu Moy 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 int
Herman van Rink 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 lon
16 matches
Mail list logo
