git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Grafting mis-aligned trees.

From
Boyd Stephen Smith Jr. <bss03@volumehost.net>
Date
Dec 2, 2008, 18:28 UTC
Message-ID
<200812021228.07070.bss03@volumehost.net>
In-Reply-To
<493572A3.4070205@drmicha.warpmail.net>

On Tuesday 02 December 2008, Michael J Gruber <git@drmicha.warpmail.net> wrote about 'Re: Grafting mis-aligned trees.':

Show 7 quoted lines
>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.
Show 6 quoted lines
>> 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.

Show 10 quoted lines
>'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/                      \_/     
Previous: Michael J Gruber
Message 7 of 7 in “Grafting mis-aligned trees.”
  1. Boyd Stephen Smith Jr.Nov 17, 2008
  2. Michael J GruberNov 18, 2008
  3. Boyd Stephen Smith Jr.Nov 28, 2008
  4. Michael J GruberDec 2, 2008
  5. Boyd Stephen Smith Jr.Dec 2, 2008
  6. Michael J GruberDec 2, 2008
  7. Boyd Stephen Smith Jr.Dec 2, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.