{"thread":{"id":"15466","subject":"[ANNOUNCE] TopGit v0.3","startedAt":"2008-09-09T23:10:09Z","lastAt":"2008-10-03T10:00:28Z","messageCount":20,"participants":["Petr Baudis","Bert Wesarg","Jan Nieuwenhuizen","martin f krafft","Michael Radziej","Jan Holesovsky"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90289","messageId":"20080909231009.GD10544@machine.or.cz","threadId":"15466","inReplyTo":null,"subject":"[ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-09T23:10:09Z","receivedAt":"2008-09-09T23:10:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi!\n\n After awfully long delay, here comes v0.3 of TopGit - we hopefully\nbegin to approach some kind of practical usability by now.\n\n TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git\nand others, of course in an attempt to Get It Right this time around.\nTopGit is absolutely minimal porcelain layer that will manage your\npatch queue for you using topic branches, one patch per branch,\nnever rewriting the history in order to enable fully distributed\nworkflow. You can get TopGit at\n\n\thttp://repo.or.cz/w/topgit.git\n\nand read up on its design, usage and implementation at:\n\n\thttp://repo.or.cz/w/topgit.git?a=blob;f=README\n\n\n Aside of few minor changes, the major point of this release is remotes\nhandling; you can elevate any remote to a TopGit-tracked status using\n'tg remote', then git fetch / push will haul around the TopGit bases\nas well, and 'tg update' can update your local branches based on\nthe remote ones. Each repository has one \"default\" TopGit remote and\nthe local branches are supposed to reflect this one; that is the remote\n'tg update' and all the other commands consider by default. Normally,\nthis remote is the last one you called 'tg remote --populate' on, but\nyou can change it in .git/config or switch it for a particular tg call\nusing the 'tg -r REMOTE command' parameter.\n\n The other major improvement is new 'tg import' command by Aneesh Kumar\nthat lets you transform a series of commits to a topic branch sequence.\nI decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for\nthis release yet, since it will probably take me a bit of time yet to\nfully understand his approach; so far, I have an uneasy feel about it.\n\n Note that this release, as usual, received only very light testing -\nplease come back with any bugs you find. If someone would feel like\nadding at least a simple testsuite, that would be really nice.\n\n\nAneesh Kumar K.V (1):\n topgit: Implement tg-import\n\nBert Wesarg (1):\n Makefile: Use $(wildcard) for commands_in\n\nDavid Brown (1):\n Force adding the .topmsg and .topdep files.\n\nJan Nieuwenhuizen (1):\n TOPGIT: [PATCH] Use standard prefix and DESTDIR rather than explain\n\nJonathan Nieder (2):\n supply template argument to mktemp\n tg-info: fix sed typo\n\nPetr Baudis (35):\n tg-export: Ensure we don't overwrite a branch by git update-ref\n tg create: Set up refs/top-bases/ after conflict resolution\n README: Sketch of my current ideas on remotes handling\n tg summary: Fix confusing variable name\n tg remote: New command\n tg-update.sh: Better explain base update\n Factor out rev-parse --verify calls to new ref_exists() function\n tg.sh: Set $base_remote to topgit.remote config value\n recurse_deps+branch_needs_update(): Deal with remote branches\n tg update: Support updating from remote branches\n has_remote(): Introduce to check if branch has remote counterpart\n tg info: Show information about remote branches\n tg info: Asterisk-prefix 'out-of-band' warnings\n tg summary: Show info about remote mates\n tg summary: 'L' denotes that push will update remote mate\n tg info: Note if local head is ahead of remote mate\n tg summary: Mark current branch with '>'\n tg -r REMOTE: Support for switching base remote\n tg summary: Fix spurious errors on tg-inconsistent remotes\n Fix recursive tg calls: Pass tg parameters through properly\n Account for direct-tg arguments in Usage strings\n tg import: Better description\n tg import: Standard script header\n tg import: Standard options parsing\n tg import: Remove tg_ prefixes from functions\n tg import: Change default prefix from tp/ to t/\n README: Add synopsis for working with remotes\n tg create -r BRANCH: Create branch based on a remote one\n tg import -p PREFIX: Custom prefix instead of t/\n tg import: Fix up process_commit() progress reporting\n branch_contains(): More explicit call to git rev-list\n tg import: Make the progress reporting stand out more\n Merge branch 'tg-import'\n README: Remove stale TODO\n TopGit-0.3\n\nmartin f. krafft (2):\n Add tg-export to gitignore\n Add various todos/wishlists\n\n\n Have fun,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90327","messageId":"36ca99e90809100118m4c2c0904q5f3effb301b0d779@mail.gmail.com","threadId":"15466","inReplyTo":"20080909231009.GD10544@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2008-09-10T08:18:08Z","receivedAt":"2008-09-10T08:18:08Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Wed, Sep 10, 2008 at 01:10, Petr Baudis wrote:\n> Hi!\nHi,\n\nThanks for the release. I have some notes:\n\n1. .gitignore is not up-to-date\n2. tg tells me v0.2\n\nWhat do I need to publish my TopGit controlled branches, is it enough\nto push with:\n\n\tpush = refs/heads/t/*:refs/heads/t/*\n\tpush = refs/top-bases/t/*:refs/top-bases/t/*\n\nThanks.\n\n> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for\n> this release yet, since it will probably take me a bit of time yet to\n> fully understand his approach; so far, I have an uneasy feel about it.\nYou may have noticed my problem with this patch, and it seems that he\nis working on a new approach/implementation\n\nRegards\nBert\n"},{"id":"90431","messageId":"1221120192.8962.7.camel@heerbeest","threadId":"15466","inReplyTo":"20080909231009.GD10544@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-11T08:03:12Z","receivedAt":"2008-09-11T08:03:12Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On wo, 2008-09-10 at 01:10 +0200, Petr Baudis wrote:\n\nHi,\n\n> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for\n> this release yet, since it will probably take me a bit of time yet to\n> fully understand his approach; so far, I have an uneasy feel about it.\n\nAh, good. It is still an experiment, as far as I'm concerned. Alas,\nI haven't gotten round to look at it, really.\n\nWe were discussing this, Jonathan Nieder had two more suggestions/ideas\n\n http://kerneltrap.org/mailarchive/git/2008/8/15/2954214\n http://kerneltrap.org/mailarchive/git/2008/8/15/2952004\n\nand Bert reported a bug\n\n http://kerneltrap.org/mailarchive/git/2008/9/1/3152864\n\nThe last implementation would just recreate a branch with all new\ndependencies, which is quite inefficient when you're just removing\nor adding one (and the list of dependencies is long, say ~100).\n\nIt would be nice if my previous cherry-pick & revert logic would be\ncombined with git read-tree to create the new dependencies-base.\nThat could be much faster and hopefully git read-tree could fix \nthe multiple add/remove issue.\n\nGreetings,\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"90540","messageId":"20080912105839.GV10360@machine.or.cz","threadId":"15466","inReplyTo":"20080911054030.GA6602@glandium.org","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2008-09-12T10:58:39Z","receivedAt":"2008-09-12T10:58:39Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Thu, Sep 11, 2008 at 07:40:30AM +0200, Mike Hommey wrote:\n> I just saw Martin Krafft's talk at debconf 8, showing TopGit, and I\n> wonder why TopGit needs to keep top-bases/* references ? Isn't\n> git merge-base enough for this ?\n\n the top-bases/ references are to determine what to base the patch\nagainst. Consider patch structure like:\n\n\t .---- A ----.\n\tvanilla < > C\n\t `---- B ----'\n\n Then, top-bases/C will consist of branches A and B, merging updates in\nthese branches over time, and you can get the current image of C's patch\nby diffing top-bases/C and heads/C. There is no way how to get this by\nusing git merge-base, since that gives you only kind of \"multi-way\ndiff\" - I'm not even sure what would you call merge-base on in this\nexample.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90541","messageId":"20080912110017.GW10360@machine.or.cz","threadId":"15466","inReplyTo":"1221120192.8962.7.camel@heerbeest","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-12T11:00:17Z","receivedAt":"2008-09-12T11:00:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Sep 11, 2008 at 10:03:12AM +0200, Jan Nieuwenhuizen wrote:\n> The last implementation would just recreate a branch with all new\n> dependencies, which is quite inefficient when you're just removing\n> or adding one (and the list of dependencies is long, say ~100).\n\nBut this is rewriting history, isn't it? This would make your work\ncompletely different from others' and that violates one of main TopGit's\ndesign goals. Or am I missing something obvious?\n\nCurrently, I'm thinking that something like .topundeps (or !-prefixing\ndependencies in .topdeps) is the only way to implement this...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90542","messageId":"20080912110129.GX10360@machine.or.cz","threadId":"15466","inReplyTo":"36ca99e90809100118m4c2c0904q5f3effb301b0d779@mail.gmail.com","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-12T11:01:29Z","receivedAt":"2008-09-12T11:01:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Wed, Sep 10, 2008 at 10:18:08AM +0200, Bert Wesarg wrote:\n> On Wed, Sep 10, 2008 at 01:10, Petr Baudis wrote:\n> > Hi!\n> Hi,\n> \n> Thanks for the release. I have some notes:\n> \n> 1. .gitignore is not up-to-date\n\n thanks, fixed.\n\n> 2. tg tells me v0.2\n\n This works for me.\n\n> What do I need to publish my TopGit controlled branches, is it enough\n> to push with:\n> \n> \tpush = refs/heads/t/*:refs/heads/t/*\n> \tpush = refs/top-bases/t/*:refs/top-bases/t/*\n\n Yes, if you keep all of your TopGit-controlled branches in t/*.\nOr just call 'tg remote' on the publishing remote and it will set up\nthis stuff for you.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90546","messageId":"1221222433.29747.8.camel@heerbeest","threadId":"15466","inReplyTo":"20080912110017.GW10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-12T12:27:13Z","receivedAt":"2008-09-12T12:27:13Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:\n\n> But this is rewriting history, isn't it?\n\nNo (that would be useless), see \n\n http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea\n\nI've just implemented the second idea\n\n http://kerneltrap.org/mailarchive/git/2008/8/15/2954214\n\nbut haven't got any time to test it yet. Then there's also \n\n http://kerneltrap.org/mailarchive/git/2008/8/15/2952004\n\nto consider.\n\n> Currently, I'm thinking that something like .topundeps (or !-prefixing\n> dependencies in .topdeps) is the only way to implement this...\n\nYeah, i've been thinking that too. It would be nice if we could\nhack around that. It seems that the two redepend ideas get around\nit at the expense of creating the whole list of dependencies,\nwhich is much too expensive for my taste.\n\nGreetings,\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"90555","messageId":"20080912131530.GZ10360@machine.or.cz","threadId":"15466","inReplyTo":"1221222433.29747.8.camel@heerbeest","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-12T13:15:30Z","receivedAt":"2008-09-12T13:15:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Sep 12, 2008 at 02:27:13PM +0200, Jan Nieuwenhuizen wrote:\n> On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:\n> \n> > But this is rewriting history, isn't it?\n> \n> No (that would be useless), see \n> \n> http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea\n\nHuh. I can't see how that could ever work.\n\n> \t$ git checkout -b P' P\n> \t$ git rebase --onto B' B\n> \t$ git checkout P\n> \t$ git merge --no-ff --no-commit B' (*)\n> \t$ git read-tree -u P'\n> \t$ git commit\n> \t$ git branch -D P'\n\nThe read-tree step is broken, you can't do that. The dependencies\ncontent will be gone from your base, but not from the actual head -\nwhat's the point of removing them at all?\n\nActually, tg patch will then show diff not only of your patch, but the\nremoved dependencies as well!\n\nThere's plenty of other problems with this approach as well. And I can't\nsee how readding a removed dependency would work at all either.\n\n> I've just implemented the second idea\n> \n> http://kerneltrap.org/mailarchive/git/2008/8/15/2954214\n> \n> but haven't got any time to test it yet. Then there's also \n> \n> http://kerneltrap.org/mailarchive/git/2008/8/15/2952004\n> \n> to consider.\n\nThat's good point, indirect dependencies problem did not occur to me\nbefore. That's troublesome...\n\nI'm beginning to wonder if it is worth the trouble to support changing\ndependencies in existing branches at all, except in the case the\ndependency got merged to upstream (then we don't hit any of these\ntroubles). I'm stopping to see any way how to sanely support dependency\nremoval without history rewriting, since we rely on Git for our all\nchanges propagation.\n\n> > Currently, I'm thinking that something like .topundeps (or !-prefixing\n> > dependencies in .topdeps) is the only way to implement this...\n> \n> Yeah, i've been thinking that too. It would be nice if we could\n> hack around that. It seems that the two redepend ideas get around\n> it at the expense of creating the whole list of dependencies,\n> which is much too expensive for my taste.\n\nActually, you would have to do this here as well for what we could call\n\"the evil Jonathan scenario\":\n\n> \tMake a topic branch t/foo depending on master.\n> \tChange the dependency of t/foo to the older version maint.\n> \tMake a new topic branch t/bar depending on t/foo and master.\n\nWhen creating t/bar, you _need_ to look in t/foo dependencies to figure\nout that you really do need the master stuff merged.\n\nEven worse, these dependency removals act dominantly through merges.\nConsider t/xyzzy and t/qux both depending on master. If you remove\nmaster dependency from t/xyzzy and then merge them together, you'll lose\nmaster from the result, even though t/qux needs it, because of the\ndependency removal commit!\n\nMore and more worms turn up in the can.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90588","messageId":"20080912181442.GA5407@lapse.rw.madduck.net","threadId":"15466","inReplyTo":"20080912131530.GZ10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-12T18:14:42Z","receivedAt":"2008-09-12T18:14:42Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.09.12.1415 +0100]:\n> I'm stopping to see any way how to sanely support dependency\n> removal without history rewriting, since we rely on Git for our\n> all changes propagation.\n\nI've considered this question a lot before and could not come up\nwith anything; you cannot undo a merge.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nit may look like i'm just sitting here doing nothing.\nbut i'm really actively waiting\nfor all my problems to go away.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"90722","messageId":"20080915080131.GA30396@noris.de","threadId":"15466","inReplyTo":"20080909231009.GD10544@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Michael Radziej","fromEmail":"mir@noris.de","sentAt":"2008-09-15T08:01:31Z","receivedAt":"2008-09-15T08:01:31Z","isPatch":false,"sender":{"key":"mir@noris.de","avatar":null},"body":"Hi!\n\nI'm just starting to toy around with TopGit. Please excuse if I am simply\ntoo naive :-) \n \nI wonder about the .topmsg and .topdeps files. Why is this information\nwithin the topic branch? It tends to get into the way even though a special\nmerge driver is provided. For example, you cannot do octopus merges (which I\nfound very confusing as first-time user). And it might also confuse people\ncloning a TopGit repository and want to use a topgit branch. They might not\nbe aware of these special TopGit things.\n \nI'd rather have a dedicated branched named e.g. 'TopGit' which includes the \ninformation that is currently in .topmsg and .topdeps, but for all branches\nin a repository.\n\n\nCheers,\n\nMichael Radziej\n\n-- \nnoris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -\nTel +49-911-9352-0 - Fax +49-911-9352-100\nhttp://www.noris.de - The IT-Outsourcing Company\n \nVorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - \nVorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689\n"},{"id":"90912","messageId":"20080917101111.GR10360@machine.or.cz","threadId":"15466","inReplyTo":"20080915080131.GA30396@noris.de","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-17T10:11:11Z","receivedAt":"2008-09-17T10:11:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Mon, Sep 15, 2008 at 10:01:31AM +0200, Michael Radziej wrote:\n> I wonder about the .topmsg and .topdeps files. Why is this information\n> within the topic branch? It tends to get into the way even though a special\n> merge driver is provided. For example, you cannot do octopus merges (which I\n> found very confusing as first-time user).\n\n what do octopus merge have to do with that? If these files prevent\noctopus merges somehow, I think that'd be a Git bug. (TopGit making\noctopus merges whenever possible is deep on my mental TODO list.)\n\n> And it might also confuse people\n> cloning a TopGit repository and want to use a topgit branch. They might not\n> be aware of these special TopGit things.\n\n They need to be properly educated by whoever gives them the clone URL.\nUsing TopGit branches outside of TopGit is still dangerous - they have\n*unholy* history and they are not really suitable for non-TopGit merging\netc. If TopGit users want non-TopGit users to use their work, they\nshould tg export.\n\n> I'd rather have a dedicated branched named e.g. 'TopGit' which includes the \n> information that is currently in .topmsg and .topdeps, but for all branches\n> in a repository.\n\n This was indeed a difficult design decision, perhaps the most major\none I had to make. Both approaches have their pros and cons, and in the\nend I chose the .top* files mainly to keep the changes atomicity - if\nyou revert your branch to older version, your .topmsg and .topdeps are\nrewound appropriately as well, and if you change something in your\nbranch that affects your topmessage, these changes are connected\nappropriately. Also, you do not need to use special tools to edit your\ntop message and merges are much simpler than if you had to merge two\npeople's work on a single branch (besides, the merge semantics of the\nTopGit branch would be really, really nasty, perhaps downright\nimpossible to specify properly).\n\n Hmm, well, oops. Merging of two people's work on a single branch is\nbroken right now anyway, because we unconditionally use our 'ours' merge\ndriver in these cases. I wonder how to fix this best... swapping two\ngitattributes files in .git/info/attributes during tg update seems like\nthe only solution to me.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"90916","messageId":"1221648520.30402.12.camel@heerbeest","threadId":"15466","inReplyTo":"20080912181442.GA5407@lapse.rw.madduck.net","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-17T10:48:40Z","receivedAt":"2008-09-17T10:48:40Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On vr, 2008-09-12 at 19:14 +0100, martin f krafft wrote:\n\n> I've considered this question a lot before and could not come up\n> with anything; you cannot undo a merge.\n\nIsn't that overly pessimistic? Can't we have git create a merge\ncommit that can be reverted with git revert?\n\nFor our ooo-build use case, I'm hoping to use [top]git as \"a better \npatch\" and hope to have mostly orthogonal topic branches. With patch,\nto \"undo a merge\" usually means patch -R and remove the patch from\nthe dependency list. I can hardly imagine something easily possible\nwith patch is still impossible with git.\n\nGreetings,\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"90923","messageId":"20080917111729.GD16687@noris.de","threadId":"15466","inReplyTo":"20080917101111.GR10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Michael Radziej","fromEmail":"mir@noris.de","sentAt":"2008-09-17T11:17:29Z","receivedAt":"2008-09-17T11:17:29Z","isPatch":false,"sender":{"key":"mir@noris.de","avatar":null},"body":"Hi Petr!\n\nPetr Baudis wrote:\n> On Mon, Sep 15, 2008 at 10:01:31AM +0200, Michael Radziej wrote:\n> > I wonder about the .topmsg and .topdeps files. Why is this information\n> > within the topic branch? It tends to get into the way even though a special\n> > merge driver is provided. For example, you cannot do octopus merges (which I\n> > found very confusing as first-time user).\n> \n> what do octopus merge have to do with that? If these files prevent\n> octopus merges somehow, I think that'd be a Git bug. (TopGit making\n> octopus merges whenever possible is deep on my mental TODO list.)\n\nHmm. Is there a way to to the octopus merge? If I do it straight away\n\n git merge b1 b2 b3 b4\n\nthen git does not use the \"ours\" merge driver for the .topfiles, since the\nattribute setting is only used for 3-way-merges. Then I get conflicts, and\ngit cannot handle conflicts during octopus merges.\n\n\n> > And it might also confuse people\n> > cloning a TopGit repository and want to use a topgit branch. They might not\n> > be aware of these special TopGit things.\n> \n> They need to be properly educated by whoever gives them the clone URL.\n> Using TopGit branches outside of TopGit is still dangerous - they have\n> *unholy* history and they are not really suitable for non-TopGit merging\n> etc. If TopGit users want non-TopGit users to use their work, they\n> should tg export.\n\nWith *unholy* you mean the lots of merges? I usually avoid them by doing\n\"tg update\" only when I get conflicts. Are there other problems?\n\n> > I'd rather have a dedicated branched named e.g. 'TopGit' which includes the \n> > information that is currently in .topmsg and .topdeps, but for all branches\n> > in a repository.\n> \n> This was indeed a difficult design decision, perhaps the most major\n> one I had to make. Both approaches have their pros and cons, and in the\n> end I chose the .top* files mainly to keep the changes atomicity - if\n> you revert your branch to older version, your .topmsg and .topdeps are\n> rewound appropriately as well, and if you change something in your\n> branch that affects your topmessage, these changes are connected\n> appropriately. Also, you do not need to use special tools to edit your\n> top message \n\nYeah, you're right about git-reset on branches. I tend to see the patch\ndescription independent from the patch, so I don't see this as a big\nproblem. But how often does one really change the .topfiles?\n\n> and merges are much simpler than if you had to merge two\n> people's work on a single branch (besides, the merge semantics of the\n> TopGit branch would be really, really nasty, perhaps downright\n> impossible to specify properly)\n\nI don't use the merge result as a TopGit branch - it's like a regular git\nbranch for me.\n\nI use merging in different ways. I merge all topic branches to get a testing\nbranch, which I throw away later. And I also temporarily merge the upstream\nbranch with all the topic branches just to check for conflicts. If I get a\nconflict, I use tg update for the conflicting branches. I'll probably script\nthis sooner or later :-)\n\n> Hmm, well, oops. Merging of two people's work on a single branch is\n> broken right now anyway, because we unconditionally use our 'ours' merge\n> driver in these cases. I wonder how to fix this best... swapping two\n> gitattributes files in .git/info/attributes during tg update seems like\n> the only solution to me.\n\nI don't have enough insight into TopGit to really think through this, at\nleast for now. Does it make sense at all build a TopGit branch on top of two\nother TopGit branches from different repositories?\n\nMichael\n"},{"id":"91228","messageId":"20080921142445.GJ10360@machine.or.cz","threadId":"15466","inReplyTo":"1221648520.30402.12.camel@heerbeest","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-21T14:24:45Z","receivedAt":"2008-09-21T14:24:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Sep 17, 2008 at 12:48:40PM +0200, Jan Nieuwenhuizen wrote:\n> On vr, 2008-09-12 at 19:14 +0100, martin f krafft wrote:\n> \n> > I've considered this question a lot before and could not come up\n> > with anything; you cannot undo a merge.\n> \n> Isn't that overly pessimistic? Can't we have git create a merge\n> commit that can be reverted with git revert?\n> \n> For our ooo-build use case, I'm hoping to use [top]git as \"a better \n> patch\" and hope to have mostly orthogonal topic branches. With patch,\n> to \"undo a merge\" usually means patch -R and remove the patch from\n> the dependency list. I can hardly imagine something easily possible\n> with patch is still impossible with git.\n\nThe problem is that you can undo the merge content, but not the history\ninformation. So this revert can e.g. propagate even into branches which\nstill *should* depend on the other branch, you get into trouble when you\nwant to make your branch depend on the other one anyway, etc.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"91298","messageId":"1222074825.6698.13.camel@heerbeest","threadId":"15466","inReplyTo":"20080921142445.GJ10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-22T09:13:45Z","receivedAt":"2008-09-22T09:13:45Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:\n\n> The problem is that you can undo the merge content, but not the history\n> information. So this revert can e.g. propagate even into branches which\n> still *should* depend on the other branch, you get into trouble when you\n> want to make your branch depend on the other one anyway, etc.\n\nAh, yes. I see. Does this mean that functionality for easy adding and\nremoving dependencies/patches from a branch can only be provided through\nsome sort of [unpublishable] patch based mechanism like stgit?\n\nPossibly we'd need a kind of setup where stgit-like patch branches\ncan be \"finalized\" into topgit branches. Hmm.\n\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"91311","messageId":"20080922152712.GN10360@machine.or.cz","threadId":"15466","inReplyTo":"1222074825.6698.13.camel@heerbeest","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-22T15:27:12Z","receivedAt":"2008-09-22T15:27:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Sep 22, 2008 at 11:13:45AM +0200, Jan Nieuwenhuizen wrote:\n> On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:\n> \n> > The problem is that you can undo the merge content, but not the history\n> > information. So this revert can e.g. propagate even into branches which\n> > still *should* depend on the other branch, you get into trouble when you\n> > want to make your branch depend on the other one anyway, etc.\n> \n> Ah, yes. I see. Does this mean that functionality for easy adding and\n> removing dependencies/patches from a branch can only be provided through\n> some sort of [unpublishable] patch based mechanism like stgit?\n> \n> Possibly we'd need a kind of setup where stgit-like patch branches\n> can be \"finalized\" into topgit branches. Hmm.\n\nDo you really expect you will need this kind of functionality often,\nthough? Adding dependencies is easy, and note that removing whole topic\nbranches or deleting dependencies that were merged upstream _is_ doable.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"91388","messageId":"1222175590.10363.14.camel@heerbeest","threadId":"15466","inReplyTo":"20080922152712.GN10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-23T13:13:10Z","receivedAt":"2008-09-23T13:13:10Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:\n\nHi,\n\n[about adding and removing topic branch dependencies]\n\n> Do you really expect you will need this kind of functionality often,\n> though?\n\nYes. This is what people are used to and do now with our patches based\nsystem. We cannot take away such basic functionality. Also, currently\nit is very easy to do, however, it is quite error prone. That's also \nwhy using [top]git would be so great.\n\nThere are ~300 topic branches. Usually, a combination of most of these\nis used as the master branch. There are a number of scenarios where\nyou would want to add/remove some of these topic branches from master.\n\nThe most pressing case for this is for packagers making a release.\nUnless we also make their life easier, we can forget about moving to \n[top]git.\n\nGreetings,\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"91390","messageId":"20080923132728.GV10360@machine.or.cz","threadId":"15466","inReplyTo":"1222175590.10363.14.camel@heerbeest","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-23T13:27:28Z","receivedAt":"2008-09-23T13:27:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Tue, Sep 23, 2008 at 03:13:10PM +0200, Jan Nieuwenhuizen wrote:\n> On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:\n> [about adding and removing topic branch dependencies]\n> \n> > Do you really expect you will need this kind of functionality often,\n> > though?\n> \n> Yes. This is what people are used to and do now with our patches based\n> system. We cannot take away such basic functionality. Also, currently\n> it is very easy to do, however, it is quite error prone. That's also \n> why using [top]git would be so great.\n> \n> There are ~300 topic branches. Usually, a combination of most of these\n> is used as the master branch. There are a number of scenarios where\n> you would want to add/remove some of these topic branches from master.\n> \n> The most pressing case for this is for packagers making a release.\n> Unless we also make their life easier, we can forget about moving to \n> [top]git.\n\n I think that would be possible to do, too. ;-) It really depends on\nhow general your patch tree is - what we can't make to work is just the\nmost generic case, but e.g. if master is a *leaf* branch nothing else\ndepends on and it can't get the branch through multiple paths, you can\ndo the dependency removal rather easily (if it can get through multiple\npaths, you can still do it but you might have to deal with big\nconflicts).\n\n But if you scenario indeed is totally generic, I'm afraid I don't know\nhow to make TopGit remove dependencies, except perhaps for the price of\nmassive complexity and massive slowdown (pretty much redoing all the\nhistory walking etc.). Maybe someone else comes by with a genial\nsolution...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"91848","messageId":"1222685623.9905.171.camel@heerbeest","threadId":"15466","inReplyTo":"20080923132728.GV10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Nieuwenhuizen","fromEmail":"janneke-list@xs4all.nl","sentAt":"2008-09-29T10:53:43Z","receivedAt":"2008-09-29T10:53:43Z","isPatch":false,"sender":{"key":"janneke-list@xs4all.nl","avatar":null},"body":"On di, 2008-09-23 at 15:27 +0200, Petr Baudis wrote:\n\n> what we can't make to work is just the\n> most generic case, but e.g. if master is a *leaf* branch nothing else\n> depends on and it can't get the branch through multiple paths, you can\n> do the dependency removal rather easily (if it can get through multiple\n> paths, you can still do it but you might have to deal with big\n> conflicts).\n\nThis already would be very nice and would probably remove the last\ntechnical hurdle to switch. Is it also easy to detect if a branch is\na leaf node?\n\n> But if you scenario indeed is totally generic, I'm afraid I don't know\n> how to make TopGit remove dependencies, except perhaps for the price of\n> massive complexity and massive slowdown (pretty much redoing all the\n> history walking etc.). Maybe someone else comes by with a genial\n> solution...\n\nAh, so the problem is about branches depending on a branch from which\na dependency is removed. What is it that we need to be looking for\nby history walking? Can't we possibly keep/cache that info in a\nspecial topgit file?\n\nJan.\n\n-- \nJan Nieuwenhuizen | GNU LilyPond - The music typesetter\nhttp://www.xs4all.nl/~jantien | http://www.lilypond.org\n"},{"id":"92231","messageId":"200810031200.28697.kendy@suse.cz","threadId":"15466","inReplyTo":"20080923132728.GV10360@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit v0.3","fromName":"Jan Holesovsky","fromEmail":"kendy@suse.cz","sentAt":"2008-10-03T10:00:28Z","receivedAt":"2008-10-03T10:00:28Z","isPatch":false,"sender":{"key":"kendy@suse.cz","avatar":null},"body":"Hi Pasky,\n\nOn Tuesday 23 September 2008 15:27, Petr Baudis wrote:\n\n> But if you scenario indeed is totally generic, I'm afraid I don't know\n> how to make TopGit remove dependencies, except perhaps for the price of\n> massive complexity and massive slowdown (pretty much redoing all the\n> history walking etc.). Maybe someone else comes by with a genial\n> solution...\n\nStill thinking about this, and I think we [ooo-builders ;-)] could live with \nthe ugliest of the ugly way of doing this: When you have a topgit branch \nt/b1, and would like to undepend it, just\n\n- tg patch t/b1 > save.diff\n- commit a reverse of save.diff to t/b1\n- tg update everything\n- remove t/b1 from all the .topdeps\n- commit save.diff to t/b1 again ;-)\n\nYeah, it creates 2 more commits in t/b1, but that's bearable I think [we do \ndisable patches, but not every day ;-)], you still have the history, and you \nare able to add the dependency later again.\n\nWhat do you think, please?\n\nRegards,\nJan\n"}]}