Do I misunderstand cg-merge --squash option

I am trying to take my current development repository which has several hundred commits in it as I was developing my application and make a simplified branch for pushing to my public repository.

I basically created a new branch (public) from the tag at the point where I started the repository.

git-checkout -b public initial_commit

I then did a merge

cg-merge --squash v1.0

This seemed to work fine (although it had trouble prompting me with an open editor to edit the commit message)

But I don't know how to move forward and merge in changes after my v1.0 tag. Any attempt to merge anything else into this "public" branch seems to throw up what appears to be merge conflict, but I can't see why - when I look at the results one side has extra lines, but there is no other overlap.

Dear diary, on Thu, Nov 10, 2005 at 01:25:05AM CET, I got a letter where Alan Chandler <alan@chandlerfamily.org.uk> said that...

Why do you want to do a squash merge?

I told you in the documentation - "re-merging with that branch later will cause trouble". If you want to be able to re-merge the branch later, you shouldn't use squash merge. And you shouldn't use squash merge anyway, expect for few narrow use cases.

On Thursday 10 Nov 2005 10:12, Petr Baudis wrote:

I used git experimentally as I built a web application from scratch, learning both what I wanted the application to look like and how to do it with the packages I was using. There is several hundreds of commits that are totally irrelevant (both because they were all different directions I was trying and then backing out of and because I saved state just were I was when I gave up for the day).

So what I was experimenting with was whether I could somehow get rid of that history (at least in one branch) before making that history public.

I know - I saw the warning - and I was only experimenting. I just didn't understand what had happened.

I am now experimenting with another approach using grafts etc. But I will post on that seperately, so as not to confuse titles of the e-mail thread.

Dear diary, on Thu, Nov 10, 2005 at 08:15:53PM CET, I got a letter where Alan Chandler <alan@chandlerfamily.org.uk> said that...

Aha. That sounds reasonable.

If you would be doing something like this again, it's best to merge, and then rather than continuing to develop what you merged, just throw that branch again and re-clone the merged repository.

Right now, what about trying to manually select the merge base?

	public$ cg-merge -b v1.0 master

On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:

Actually, that does merge very nicely. However, I don't think its what I want. From gitk I get both routes back to my initial commit, both the fast track one and the slow train via all stations en-route.

I have had more success with grafting (which you kindly informed me about yesterday)

something like

echo `cg-object-id v1.0` `cg-object-id initial_commit` >.git/info/grafts

lf I make a branch out of the parent of v1.0 before doing this, I end up with there being a side branch of the old history and my master branch headed back through a quick route to the initial_commit.

Something strange (well actually not that unexpected, the more I think about it) has happened though.

I was trying to see if cg-clone would effectively me make a new repository without the grafts in it (ie with real commit object with a parent as specified via the graft) but it doesn't - it just looses the graft and rebrings all the old history back in

Is that a bug?

Dear diary, on Thu, Nov 10, 2005 at 09:36:06PM CET, I got a letter where Alan Chandler <alan@chandlerfamily.org.uk> said that...

Huh. But you still have the history cluttered and both routes to your initial commit, don't you? I'm now confused - I fear I don't know what you want anymore. But well, whatever is working out for you... ;-)

So far grafts were considered a private thing to enable some cool things like tying ancient history to your current history tree, etc. But if you want to do some persistent changes in the DAG, you are really best off just rebuilding the whole history.