Ah! Good to learn about "git replace", thanks!

I want to get rid of the old history so it would be fine to force git fetch 
B to override and replace existing local tags with the fetched tags of the 
same name.

So what about the following plan, after setting A as a remote to B:

git fetch B

git fetch B '+refs/tags/*:refs/tags/*'
(This seems necessary in order to force tags from B to replace existing 
local tags)

git replace D1 D2
(As I understand now, this sets a kind of graftpoint to reroute history 
without changing later commits)

Now it would be fine to rewrite commits in order to remove the graftpoint 
and have a clean history. But I do want to keep the graph between E, F, G 
and H..J intact. 
If I would call

git filter-branch -- --all

would that rewrite all commits from E *but keep the graph beyond that point 
as it is?*
And what about any tags defined in E...J, will they be preserved and point 
to the new commit names after the rewrite?

Thanks for your help!


On Tuesday, May 12, 2015 at 1:56:10 PM UTC+2, Konstantin Khomoutov wrote:
>
> On Tue, 12 May 2015 04:39:32 -0700 (PDT) 
> J66st <vdplas...@gmail.com <javascript:>> wrote: 
>
> > I have two repositories A and B. A is my working repository. B is a 
> > bare repository containing a more detailed history than A. This is 
> > illustrated in the following simplified graphs. 
> [...] 
> > A1--------D1---------E--F--G [master] 
> > 
> >                       \  \ 
> > 
> >                        H--I--J [topic] 
> [...] 
> > A2---B2--C2--D2 
> [...] 
>
> > Notice that both histories use identical tag names for tagging 
> > versions! My first idea is to set repository B as a remote to 
> > repository A, then fetch from B, rebase E onto D2, then prune A1 thru 
> > D1. 
>
> That is correct. 
>
> > But wouldn't fetching from repository B cause the tag names to clash? 
>
> You're not forced to fetch tags. 
> Use something like 
>
>   git fetch B 'refs/heads/master:refs/heads/mb' 
>
> and you'll get a local branch named "mb" containing the history of 
> "master" available in "B". 
>
> What I'm more concerned with is that rebasing E onto D2 will surely 
> break H..J because your E, F, G will turn into E', F', G' with changed 
> SHA1 names. 
>
> So *may be* you will instead want to use `git replace` replacing 
> D1 with D2 so that E and the descendant commits are left intact. 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to