Do I misunderstand cg-merge --squash option

Do I misunderstand cg-merge --squash option

[Alan Chandler]

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.






-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

Re: Do I misunderstand cg-merge --squash option

[Petr Baudis]

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...
> 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

Why do you want to do a squash merge?

> 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.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Do I misunderstand cg-merge --squash option

[Alan Chandler]

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

>
> Why do you want to do a squash merge?
>

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 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.

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.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

Re: Do I misunderstand cg-merge --squash option

[Petr Baudis]

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...
> On Thursday 10 Nov 2005 10:12, Petr Baudis wrote:
> > Why do you want to do a squash merge?
> 
> 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.

Aha. That sounds reasonable.

> > 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.
> 
> I know - I saw the warning - and I was only experimenting.  I just didn't 
> understand what had happened.

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Do I misunderstand cg-merge --squash option

[Alan Chandler]

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

>
> Right now, what about trying to manually select the merge base?
>
> 	public$ cg-merge -b v1.0 master

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?

-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

Re: Do I misunderstand cg-merge --squash option

[Petr Baudis]

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...
> On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:
> 
> >
> > Right now, what about trying to manually select the merge base?
> >
> > 	public$ cg-merge -b v1.0 master
> 
> 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.

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... ;-)

> 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?

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.