Re: tracking a tree that doesn't progress linearly

From: Petr Baudis <pasky@suse.cz>
Date: Nov 11, 2005, 11:06 UTC
Message-ID: <20051111110625.GO30496@pasky.or.cz>
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>

Dear diary, on Fri, Nov 11, 2005 at 04:18:31AM CET, I got a letter where Paul Mackerras <paulus@samba.org> said that...

Show 17 quoted lines

> I want to be able to publish a git tree for others to follow but I
> also want to be retain the freedom to remove commits and/or rebase
> commits in the tree.  For example, if someone sends me a patch and I
> put it in the tree, then they send me a revised version, I want to be
> able to roll back to just before I applied the older patch and start
> again from there.
> 
> What this means, AFAICS, is that the head of the published tree won't
> always be a descendent of all previous values of the head.  If
> somebody is following the state of the tree by doing a git pull every
> so often, and I have rolled back the tree and applied some new
> patches, then the git pull will try to merge the old and new state,
> which is not what we want.  What we want is something that just gets
> the local tree to the same state as the remote tree.
> 
> Is there a git command which does the equivalent of a git fetch,
> followed by setting the head and checking it out?

I plan to change the fast-forward condition in Cogito from

	is_ancestor(current, new_head)

to

	current == old_head || is_ancestor(current, new_head)

which should enable you to do this - just rebase, and it will Just Work for those cg-update'ing from you; the only problem si that cg-fetch + cg-merge will NOT work, but I have no simple workaround for that.

I already proposed this several times and it was always passed in silence, so I assume there are no problems with this approach.

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