Junio C Hamano <[EMAIL PROTECTED]> writes:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
>> I'd still like to revive my idea of having projects overlaid on each
>> other, where the commits in the project that absorbed the other project
>> say, essentially, "also include this other commit, but an
Darrin Thompson wrote:
What I'm going to do is actually an inversion of that. Publishing a
repository with the _intent_ of being merged into existing history, and
observing obvious naming conventions as the "prior arrangement".
I thought once I got the initial baseless merges done and committed
On Sat, 27 Aug 2005, Martin Langhoff wrote:
> On 8/27/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > The problem with both of these (and doing it in the build system) is that,
> > when a project includes another project, you generally don't want whatever
> > revision of the included project ha
On 8/27/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> The problem with both of these (and doing it in the build system) is that,
> when a project includes another project, you generally don't want whatever
> revision of the included project happens to be the latest; you want the
> revision of th
On Fri, 26 Aug 2005, Martin Langhoff wrote:
> On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > their core GIT tools come from. But how would _I_ pull from
> > that "My Project", if I did not want to pull unrelated stuff in?
>
> and then...
>
> > What I think _might_ deserve a bit more su
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> their core GIT tools come from. But how would _I_ pull from
> that "My Project", if I did not want to pull unrelated stuff in?
and then...
> What I think _might_ deserve a bit more support would be a merge
> of a foreign project as a subdi
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I'd still like to revive my idea of having projects overlaid on each
> other, where the commits in the project that absorbed the other project
> say, essentially, "also include this other commit, but any changes to
> those files belong to that branch,
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> One thing that makes me reluctant to recommend this "merging
> unrelated projects" business is that I suspect that it makes
> things _much_ harder for the upstream project that is being
> merged, and should not be done without prior arrangement; Linus
>
On Thu, 2005-08-25 at 15:26 -0700, Junio C Hamano wrote:
> empty=`GIT_INDEX_FILE=.no-such-file git-write-tree`
> git-read-tree -m -u $empty $head $foreign ||
o. Tricky.
Thanks for the script. That's a bad, bad hack. :-)
> One thing that makes me reluctant to recommend this "m
Darrin Thompson <[EMAIL PROTECTED]> writes:
> I have a weird situation I want to support. I want to be able to merge a
> foreign-tree repeatedly.
>
> What makes the foreign tree foreign is that it may not yet share any
> history with this branch.
I believe that's exactly what Linus did when he me
That didn't come out clearly. Restating:
On Thu, 2005-08-25 at 16:10 -0500, Darrin Thompson wrote:
> Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1
> as an implicit empty tree?
>
Could git-read-tree -m treat an argument of "0" as an implicit empty
tree? It mainly seems
11 matches
Mail list logo
