Re: [ANNOUNCE] TopGit v0.3

[Michael Radziej <mir@noris.de>]

Hi Petr!

Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Sep 15, 2008 at 10:01:31AM +0200, Michael Radziej wrote:
> > I wonder about the .topmsg and .topdeps files. Why is this information
> > within the topic branch? It tends to get into the way even though a special
> > merge driver is provided. For example, you cannot do octopus merges (which I
> > found very confusing as first-time user).
> 
>   what do octopus merge have to do with that? If these files prevent
> octopus merges somehow, I think that'd be a Git bug. (TopGit making
> octopus merges whenever possible is deep on my mental TODO list.)

Hmm. Is there a way to to the octopus merge? If I do it straight away

  git merge b1 b2 b3 b4

then git does not use the "ours" merge driver for the .topfiles, since the
attribute setting is only used for 3-way-merges. Then I get conflicts, and
git cannot handle conflicts during octopus merges.


> > And it might also confuse people
> > cloning a TopGit repository and want to use a topgit branch. They might not
> > be aware of these special TopGit things.
> 
>   They need to be properly educated by whoever gives them the clone URL.
> Using TopGit branches outside of TopGit is still dangerous - they have
> *unholy* history and they are not really suitable for non-TopGit merging
> etc. If TopGit users want non-TopGit users to use their work, they
> should tg export.

With *unholy* you mean the lots of merges? I usually avoid them by doing
"tg update" only when I get conflicts. Are there other problems?

> > I'd rather have a dedicated branched named e.g. 'TopGit' which includes the                                                           
> > information that is currently in .topmsg and .topdeps, but for all branches
> > in a repository.
> 
>   This was indeed a difficult design decision, perhaps the most major
> one I had to make. Both approaches have their pros and cons, and in the
> end I chose the .top* files mainly to keep the changes atomicity - if
> you revert your branch to older version, your .topmsg and .topdeps are
> rewound appropriately as well, and if you change something in your
> branch that affects your topmessage, these changes are connected
> appropriately. Also, you do not need to use special tools to edit your
> top message 

Yeah, you're right about git-reset on branches. I tend to see the patch
description independent from the patch, so I don't see this as a big
problem. But how often does one really change the .topfiles?

> and merges are much simpler than if you had to merge two
> people's work on a single branch (besides, the merge semantics of the
> TopGit branch would be really, really nasty, perhaps downright
> impossible to specify properly)

I don't use the merge result as a TopGit branch - it's like a regular git
branch for me.

I use merging in different ways. I merge all topic branches to get a testing
branch, which I throw away later. And I also temporarily merge the upstream
branch with all the topic branches just to check for conflicts. If I get a
conflict, I use tg update for the conflicting branches. I'll probably script
this sooner or later :-)

>   Hmm, well, oops. Merging of two people's work on a single branch is
> broken right now anyway, because we unconditionally use our 'ours' merge
> driver in these cases. I wonder how to fix this best... swapping two
> gitattributes files in .git/info/attributes during tg update seems like
> the only solution to me.

I don't have enough insight into TopGit to really think through this, at
least for now. Does it make sense at all build a TopGit branch on top of two
other TopGit branches from different repositories?

Michael