From: "Boyd Stephen Smith Jr." <bss03@volumehost•net>
To: Michael J Gruber <git@drmicha•warpmail.net>
Cc: git@vger•kernel.org
Subject: Re: Grafting mis-aligned trees.
Date: Tue, 2 Dec 2008 12:28:06 -0600 [thread overview]
Message-ID: <200812021228.07070.bss03@volumehost.net> (raw)
In-Reply-To: <493572A3.4070205@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
On Tuesday 02 December 2008, Michael J Gruber <git@drmicha•warpmail.net>
wrote about 'Re: Grafting mis-aligned trees.':
>Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19:
>> I can't help thinking that rebase -ip might have helped. I wasn't
>> aware of -p when I was initially working on this problem. (It doesn't
>> help that I generally use Debian stable, and git 1.4 did not have -p.)
>
>rebase rebases one branch at a time, but you need to rebase/rewrite
>several, and the merge info between depends on rewritten sha1s.
Yes. I guess that's why I employed filter-branch to begin with.
>> I probably don't need the -f. If there are files that should be
>> ignored (and thus shouldn't be in the repo), I'll filter-branch to cut
>> them out of the history at some point.
>
>'-f' is about not having to clean out refs/original from a previous
>filter-branch run.
Okay, I misread your command line. For some reason I thought "-f" was an
option to add.
>> What *exactly* is the subtree merge. The documentation I've read
>> sounds like this case, sort of, but it's rather unclear to me.
>
>I think 'subtree' does what you want, but 'merge' doesn't!
*giggle* I'm not quite sure what makes this funny to me, but it made me
laugh.
>'subtree'
>saves you the rewriting (putting TI into project/web), but you want a
>one-time conversion anyway. 'subtree' allows you to repeatedly merge
>branches with a different root. What it does is it looks for subdir,
>'rewrites' the incoming tree automatically and merges the result.
>
>But you don't want a merge, do you? Or else your whole TI history would
>be tacked onto FT's head "to the left": a new (subtree) merge commit
>would have FT's and TI's head as parents. This is one way of storing TI
>history in the full repo, but not the one you said you wanted.
You are right; that's not what I want. But, it is a good second-place
result that I'll keep in mind. Sometimes keeping the history at all is
more important that keeping the history orderly.
Again, thanks for the help.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost•net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
prev parent reply other threads:[~2008-12-02 18:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 22:45 Grafting mis-aligned trees Boyd Stephen Smith Jr.
2008-11-18 9:24 ` Michael J Gruber
2008-11-28 23:01 ` Boyd Stephen Smith Jr.
2008-12-02 16:20 ` Michael J Gruber
2008-12-02 17:19 ` Boyd Stephen Smith Jr.
2008-12-02 17:38 ` Michael J Gruber
2008-12-02 18:28 ` Boyd Stephen Smith Jr. [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812021228.07070.bss03@volumehost.net \
--to=bss03@volumehost$(echo .)net \
--cc=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox