[ANNOUNCE] TopGit v0.3

[ANNOUNCE] TopGit v0.3

[Petr Baudis]

  Hi!

  After awfully long delay, here comes v0.3 of TopGit - we hopefully
begin to approach some kind of practical usability by now.

  TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
and others, of course in an attempt to Get It Right this time around.
TopGit is absolutely minimal porcelain layer that will manage your
patch queue for you using topic branches, one patch per branch,
never rewriting the history in order to enable fully distributed
workflow.  You can get TopGit at

	http://repo.or.cz/w/topgit.git

and read up on its design, usage and implementation at:

	http://repo.or.cz/w/topgit.git?a=blob;f=README


  Aside of few minor changes, the major point of this release is remotes
handling; you can elevate any remote to a TopGit-tracked status using
'tg remote', then git fetch / push will haul around the TopGit bases
as well, and 'tg update' can update your local branches based on
the remote ones. Each repository has one "default" TopGit remote and
the local branches are supposed to reflect this one; that is the remote
'tg update' and all the other commands consider by default. Normally,
this remote is the last one you called 'tg remote --populate' on, but
you can change it in .git/config or switch it for a particular tg call
using the 'tg -r REMOTE command' parameter.

  The other major improvement is new 'tg import' command by Aneesh Kumar
that lets you transform a series of commits to a topic branch sequence.
I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
this release yet, since it will probably take me a bit of time yet to
fully understand his approach; so far, I have an uneasy feel about it.

  Note that this release, as usual, received only very light testing -
please come back with any bugs you find. If someone would feel like
adding at least a simple testsuite, that would be really nice.


Aneesh Kumar K.V (1):
      topgit: Implement tg-import

Bert Wesarg (1):
      Makefile: Use $(wildcard) for commands_in

David Brown (1):
      Force adding the .topmsg and .topdep files.

Jan Nieuwenhuizen (1):
      TOPGIT: [PATCH] Use standard prefix and DESTDIR rather than explain

Jonathan Nieder (2):
      supply template argument to mktemp
      tg-info: fix sed typo

Petr Baudis (35):
      tg-export: Ensure we don't overwrite a branch by git update-ref
      tg create: Set up refs/top-bases/ after conflict resolution
      README: Sketch of my current ideas on remotes handling
      tg summary: Fix confusing variable name
      tg remote: New command
      tg-update.sh: Better explain base update
      Factor out rev-parse --verify calls to new ref_exists() function
      tg.sh: Set $base_remote to topgit.remote config value
      recurse_deps+branch_needs_update(): Deal with remote branches
      tg update: Support updating from remote branches
      has_remote(): Introduce to check if branch has remote counterpart
      tg info: Show information about remote branches
      tg info: Asterisk-prefix 'out-of-band' warnings
      tg summary: Show info about remote mates
      tg summary: 'L' denotes that push will update remote mate
      tg info: Note if local head is ahead of remote mate
      tg summary: Mark current branch with '>'
      tg -r REMOTE: Support for switching base remote
      tg summary: Fix spurious errors on tg-inconsistent remotes
      Fix recursive tg calls: Pass tg parameters through properly
      Account for direct-tg arguments in Usage strings
      tg import: Better description
      tg import: Standard script header
      tg import: Standard options parsing
      tg import: Remove tg_ prefixes from functions
      tg import: Change default prefix from tp/ to t/
      README: Add synopsis for working with remotes
      tg create -r BRANCH: Create branch based on a remote one
      tg import -p PREFIX: Custom prefix instead of t/
      tg import: Fix up process_commit() progress reporting
      branch_contains(): More explicit call to git rev-list
      tg import: Make the progress reporting stand out more
      Merge branch 'tg-import'
      README: Remove stale TODO
      TopGit-0.3

martin f. krafft (2):
      Add tg-export to gitignore
      Add various todos/wishlists


  Have fun,

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Bert Wesarg]

On Wed, Sep 10, 2008 at 01:10, Petr Baudis <pasky@suse.cz> wrote:
>  Hi!
Hi,

Thanks for the release.  I have some notes:

1. .gitignore is not up-to-date
2. tg tells me v0.2

What do I need to publish my TopGit controlled branches, is it enough
to push with:

	push = refs/heads/t/*:refs/heads/t/*
	push = refs/top-bases/t/*:refs/top-bases/t/*

Thanks.

> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
> this release yet, since it will probably take me a bit of time yet to
> fully understand his approach; so far, I have an uneasy feel about it.
You may have noticed my problem with this patch, and it seems that he
is working on a new approach/implementation

Regards
Bert

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

  Hi,

On Wed, Sep 10, 2008 at 10:18:08AM +0200, Bert Wesarg wrote:
> On Wed, Sep 10, 2008 at 01:10, Petr Baudis <pasky@suse.cz> wrote:
> >  Hi!
> Hi,
> 
> Thanks for the release.  I have some notes:
> 
> 1. .gitignore is not up-to-date

  thanks, fixed.

> 2. tg tells me v0.2

  This works for me.

> What do I need to publish my TopGit controlled branches, is it enough
> to push with:
> 
> 	push = refs/heads/t/*:refs/heads/t/*
> 	push = refs/top-bases/t/*:refs/top-bases/t/*

  Yes, if you keep all of your TopGit-controlled branches in t/*.
Or just call 'tg remote' on the publishing remote and it will set up
this stuff for you.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On wo, 2008-09-10 at 01:10 +0200, Petr Baudis wrote:

Hi,

> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
> this release yet, since it will probably take me a bit of time yet to
> fully understand his approach; so far, I have an uneasy feel about it.

Ah, good.  It is still an experiment, as far as I'm concerned.  Alas,
I haven't gotten round to look at it, really.

We were discussing this, Jonathan Nieder had two more suggestions/ideas

    http://kerneltrap.org/mailarchive/git/2008/8/15/2954214
    http://kerneltrap.org/mailarchive/git/2008/8/15/2952004

and Bert reported a bug

    http://kerneltrap.org/mailarchive/git/2008/9/1/3152864

The last implementation would just recreate a branch with all new
dependencies, which is quite inefficient when you're just removing
or adding one (and the list of dependencies is long, say ~100).

It would be nice if my previous cherry-pick & revert logic would be
combined with git read-tree to create the new dependencies-base.
That could be much faster and hopefully git read-tree could fix 
the multiple add/remove issue.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

On Thu, Sep 11, 2008 at 10:03:12AM +0200, Jan Nieuwenhuizen wrote:
> The last implementation would just recreate a branch with all new
> dependencies, which is quite inefficient when you're just removing
> or adding one (and the list of dependencies is long, say ~100).

But this is rewriting history, isn't it? This would make your work
completely different from others' and that violates one of main TopGit's
design goals. Or am I missing something obvious?

Currently, I'm thinking that something like .topundeps (or !-prefixing
dependencies in .topdeps) is the only way to implement this...

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:

> But this is rewriting history, isn't it?

No (that would be useless), see 

    http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea

I've just implemented the second idea

    http://kerneltrap.org/mailarchive/git/2008/8/15/2954214

but haven't got any time to test it yet.  Then there's also 

    http://kerneltrap.org/mailarchive/git/2008/8/15/2952004

to consider.

> Currently, I'm thinking that something like .topundeps (or !-prefixing
> dependencies in .topdeps) is the only way to implement this...

Yeah, i've been thinking that too.  It would be nice if we could
hack around that.  It seems that the two redepend ideas get around
it at the expense of creating the whole list of dependencies,
which is much too expensive for my taste.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

On Fri, Sep 12, 2008 at 02:27:13PM +0200, Jan Nieuwenhuizen wrote:
> On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:
> 
> > But this is rewriting history, isn't it?
> 
> No (that would be useless), see 
> 
>     http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea

Huh. I can't see how that could ever work.

> 	$ git checkout -b P' P
> 	$ git rebase --onto B' B
> 	$ git checkout P
> 	$ git merge --no-ff --no-commit B'   (*)
> 	$ git read-tree -u P'
> 	$ git commit
> 	$ git branch -D P'

The read-tree step is broken, you can't do that. The dependencies
content will be gone from your base, but not from the actual head -
what's the point of removing them at all?

Actually, tg patch will then show diff not only of your patch, but the
removed dependencies as well!

There's plenty of other problems with this approach as well. And I can't
see how readding a removed dependency would work at all either.

> I've just implemented the second idea
> 
>     http://kerneltrap.org/mailarchive/git/2008/8/15/2954214
> 
> but haven't got any time to test it yet.  Then there's also 
> 
>     http://kerneltrap.org/mailarchive/git/2008/8/15/2952004
> 
> to consider.

That's good point, indirect dependencies problem did not occur to me
before. That's troublesome...

I'm beginning to wonder if it is worth the trouble to support changing
dependencies in existing branches at all, except in the case the
dependency got merged to upstream (then we don't hit any of these
troubles). I'm stopping to see any way how to sanely support dependency
removal without history rewriting, since we rely on Git for our all
changes propagation.

> > Currently, I'm thinking that something like .topundeps (or !-prefixing
> > dependencies in .topdeps) is the only way to implement this...
> 
> Yeah, i've been thinking that too.  It would be nice if we could
> hack around that.  It seems that the two redepend ideas get around
> it at the expense of creating the whole list of dependencies,
> which is much too expensive for my taste.

Actually, you would have to do this here as well for what we could call
"the evil Jonathan scenario":

> 	Make a topic branch t/foo depending on master.
> 	Change the dependency of t/foo to the older version maint.
> 	Make a new topic branch t/bar depending on t/foo and master.

When creating t/bar, you _need_ to look in t/foo dependencies to figure
out that you really do need the master stuff merged.

Even worse, these dependency removals act dominantly through merges.
Consider t/xyzzy and t/qux both depending on master. If you remove
master dependency from t/xyzzy and then merge them together, you'll lose
master from the result, even though t/qux needs it, because of the
dependency removal commit!

More and more worms turn up in the can.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

also sprach Petr Baudis <pasky@suse.cz> [2008.09.12.1415 +0100]:
> I'm stopping to see any way how to sanely support dependency
> removal without history rewriting, since we rely on Git for our
> all changes propagation.

I've considered this question a lot before and could not come up
with anything; you cannot undo a merge.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On vr, 2008-09-12 at 19:14 +0100, martin f krafft wrote:

> I've considered this question a lot before and could not come up
> with anything; you cannot undo a merge.

Isn't that overly pessimistic?  Can't we have git create a merge
commit that can be reverted with git revert?

For our ooo-build use case, I'm hoping to use [top]git as "a better 
patch" and hope to have mostly orthogonal topic branches.  With patch,
to "undo a merge" usually means patch -R and remove the patch from
the dependency list.  I can hardly imagine something easily possible
with patch is still impossible with git.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

On Wed, Sep 17, 2008 at 12:48:40PM +0200, Jan Nieuwenhuizen wrote:
> On vr, 2008-09-12 at 19:14 +0100, martin f krafft wrote:
> 
> > I've considered this question a lot before and could not come up
> > with anything; you cannot undo a merge.
> 
> Isn't that overly pessimistic?  Can't we have git create a merge
> commit that can be reverted with git revert?
> 
> For our ooo-build use case, I'm hoping to use [top]git as "a better 
> patch" and hope to have mostly orthogonal topic branches.  With patch,
> to "undo a merge" usually means patch -R and remove the patch from
> the dependency list.  I can hardly imagine something easily possible
> with patch is still impossible with git.

The problem is that you can undo the merge content, but not the history
information. So this revert can e.g. propagate even into branches which
still *should* depend on the other branch, you get into trouble when you
want to make your branch depend on the other one anyway, etc.

				Petr "Pasky" Baudis

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:

> The problem is that you can undo the merge content, but not the history
> information. So this revert can e.g. propagate even into branches which
> still *should* depend on the other branch, you get into trouble when you
> want to make your branch depend on the other one anyway, etc.

Ah, yes.  I see.  Does this mean that functionality for easy adding and
removing dependencies/patches from a branch can only be provided through
some sort of [unpublishable] patch based mechanism like stgit?

Possibly we'd need a kind of setup where stgit-like patch branches
can be "finalized" into topgit branches.  Hmm.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

On Mon, Sep 22, 2008 at 11:13:45AM +0200, Jan Nieuwenhuizen wrote:
> On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:
> 
> > The problem is that you can undo the merge content, but not the history
> > information. So this revert can e.g. propagate even into branches which
> > still *should* depend on the other branch, you get into trouble when you
> > want to make your branch depend on the other one anyway, etc.
> 
> Ah, yes.  I see.  Does this mean that functionality for easy adding and
> removing dependencies/patches from a branch can only be provided through
> some sort of [unpublishable] patch based mechanism like stgit?
> 
> Possibly we'd need a kind of setup where stgit-like patch branches
> can be "finalized" into topgit branches.  Hmm.

Do you really expect you will need this kind of functionality often,
though? Adding dependencies is easy, and note that removing whole topic
branches or deleting dependencies that were merged upstream _is_ doable.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:

Hi,

[about adding and removing topic branch dependencies]

> Do you really expect you will need this kind of functionality often,
> though?

Yes.  This is what people are used to and do now with our patches based
system.  We cannot take away such basic functionality.  Also, currently
it is very easy to do, however, it is quite error prone.  That's also 
why using [top]git would be so great.

There are ~300 topic branches.  Usually, a combination of most of these
is used as the master branch.  There are a number of scenarios where
you would want to add/remove some of these topic branches from master.

The most pressing case for this is for packagers making a release.
Unless we also make their life easier, we can forget about moving to 
[top]git.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

  Hi,

On Tue, Sep 23, 2008 at 03:13:10PM +0200, Jan Nieuwenhuizen wrote:
> On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:
> [about adding and removing topic branch dependencies]
> 
> > Do you really expect you will need this kind of functionality often,
> > though?
> 
> Yes.  This is what people are used to and do now with our patches based
> system.  We cannot take away such basic functionality.  Also, currently
> it is very easy to do, however, it is quite error prone.  That's also 
> why using [top]git would be so great.
> 
> There are ~300 topic branches.  Usually, a combination of most of these
> is used as the master branch.  There are a number of scenarios where
> you would want to add/remove some of these topic branches from master.
> 
> The most pressing case for this is for packagers making a release.
> Unless we also make their life easier, we can forget about moving to 
> [top]git.

  I think that would be possible to do, too. ;-) It really depends on
how general your patch tree is - what we can't make to work is just the
most generic case, but e.g. if master is a *leaf* branch nothing else
depends on and it can't get the branch through multiple paths, you can
do the dependency removal rather easily (if it can get through multiple
paths, you can still do it but you might have to deal with big
conflicts).

  But if you scenario indeed is totally generic, I'm afraid I don't know
how to make TopGit remove dependencies, except perhaps for the price of
massive complexity and massive slowdown (pretty much redoing all the
history walking etc.). Maybe someone else comes by with a genial
solution...

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Jan Nieuwenhuizen]

On di, 2008-09-23 at 15:27 +0200, Petr Baudis wrote:

> what we can't make to work is just the
> most generic case, but e.g. if master is a *leaf* branch nothing else
> depends on and it can't get the branch through multiple paths, you can
> do the dependency removal rather easily (if it can get through multiple
> paths, you can still do it but you might have to deal with big
> conflicts).

This already would be very nice and would probably remove the last
technical hurdle to switch.  Is it also easy to detect if a branch is
a leaf node?

>   But if you scenario indeed is totally generic, I'm afraid I don't know
> how to make TopGit remove dependencies, except perhaps for the price of
> massive complexity and massive slowdown (pretty much redoing all the
> history walking etc.). Maybe someone else comes by with a genial
> solution...

Ah, so the problem is about branches depending on a branch from which
a dependency is removed.  What is it that we need to be looking for
by history walking?  Can't we possibly keep/cache that info in a
special topgit file?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [ANNOUNCE] TopGit v0.3

[Jan Holesovsky]

Hi Pasky,

On Tuesday 23 September 2008 15:27, Petr Baudis wrote:

>   But if you scenario indeed is totally generic, I'm afraid I don't know
> how to make TopGit remove dependencies, except perhaps for the price of
> massive complexity and massive slowdown (pretty much redoing all the
> history walking etc.). Maybe someone else comes by with a genial
> solution...

Still thinking about this, and I think we [ooo-builders ;-)] could live with 
the ugliest of the ugly way of doing this:  When you have a topgit branch 
t/b1, and would like to undepend it, just

- tg patch t/b1 > save.diff
- commit a reverse of save.diff to t/b1
- tg update everything
- remove t/b1 from all the .topdeps
- commit save.diff to t/b1 again ;-)

Yeah, it creates 2 more commits in t/b1, but that's bearable I think [we do 
disable patches, but not every day ;-)], you still have the history, and you 
are able to add the dependency later again.

What do you think, please?

Regards,
Jan

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

  Hi,

On Thu, Sep 11, 2008 at 07:40:30AM +0200, Mike Hommey wrote:
> I just saw Martin Krafft's talk at debconf 8, showing TopGit, and I
> wonder why TopGit needs to keep top-bases/* references ? Isn't
> git merge-base enough for this ?

  the top-bases/ references are to determine what to base the patch
against. Consider patch structure like:

	         .---- A ----.
	vanilla <             > C
	         `---- B ----'

  Then, top-bases/C will consist of branches A and B, merging updates in
these branches over time, and you can get the current image of C's patch
by diffing top-bases/C and heads/C. There is no way how to get this by
using git merge-base, since that gives you only kind of "multi-way
diff" - I'm not even sure what would you call merge-base on in this
example.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Michael Radziej]

Hi!

I'm just starting to toy around with TopGit. Please excuse if I am simply
too naive :-)                                                 
                                
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). 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.
                                                                                                                                       
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.


Cheers,

Michael Radziej

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

Re: [ANNOUNCE] TopGit v0.3

[Petr Baudis]

  Hi,

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

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

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

  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.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit v0.3

[Michael Radziej]

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