{"thread":{"id":"10306","subject":"What's cooking in git/spearce.git (topics)","startedAt":"2007-10-16T06:04:56Z","lastAt":"2007-10-24T00:12:40Z","messageCount":21,"participants":["Shawn O. Pearce","Johannes Schindelin","Theodore Tso","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55952","messageId":"20071016060456.GC13801@spearce.org","threadId":"10306","inReplyTo":null,"subject":"What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-16T06:04:56Z","receivedAt":"2007-10-16T06:04:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\nI know there are a number of other topics that I don't have in my\ntree yet (bisect improvements, push refspec matching improvements,\noption parser).  I plan on loading those into 'pu' tomorrow.\nIn the meantime we have this in next.\n\n\n* db/fetch-pack (Thu Oct 11 01:47:55 2007 +0100) 58 commits\n + fetch: if not fetching from default remote, ignore default merge\n + Support 'push --dry-run' for http transport\n + Support 'push --dry-run' for rsync transport\n + Fix 'push --all branch...' error handling\n + Fix compilation when NO_CURL is defined\n + Added a test for fetching remote tags when there is not tags.\n + Fix a crash in ls-remote when refspec expands into nothing\n + Remove duplicate ref matches in fetch\n ... and many more ...\n\n The above commits are all new since Junio's last published next.\n About half of them fix known bugs in the builtin-fetch series.\n If you are running next, you want these fixes.\n\n I'm actually really happy with this series, but given the set of\n bugs that the above commits had to fix I think it needs to cook\n more in next before the topic can safely can graduate into master.\n\n* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits\n + git-am: fix typo in the previous one.\n + git-am: make the output quieter.\n\n I'm also really happy with this change.  If nobody objects I may\n move it over to master later this week.\n\n\n* lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit\n + optimize diffcore-delta by sorting hash entries.\n\n* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n + Export rerere() and launch_editor().\n + Introduce entry point add_interactive and add_files_to_cache\n + Enable wt-status to run against non-standard index file.\n + Enable wt-status output to a given FILE pointer.\n\n* js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nI inherited the above three topics from Junio.  I haven't had a\nchance to really look at these yet myself to understand what their\nstatus is and how ready they are for master (or not ready as the\ncase may be).\n"},{"id":"56016","messageId":"Pine.LNX.4.64.0710161209480.25221@racer.site","threadId":"10306","inReplyTo":"20071016060456.GC13801@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T11:16:28Z","receivedAt":"2007-10-16T11:16:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nfirst let me thank you for being the interim maintainer.  I know it is \nmuch work, and I frankly do not have the time, or nerve, to do it.  Out of \ncuriousity: did you use the scripts in \"todo\" to send these emails?\n\nOn Tue, 16 Oct 2007, Shawn O. Pearce wrote:\n\n> * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit\n>  + optimize diffcore-delta by sorting hash entries.\n\nAFAIR this was ready to go to master, with a 5-10% speedup or so, just \nneeding a bit of testing.  Which it should have gotten by now.\n\n> * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n>  + Export rerere() and launch_editor().\n>  + Introduce entry point add_interactive and add_files_to_cache\n>  + Enable wt-status to run against non-standard index file.\n>  + Enable wt-status output to a given FILE pointer.\n\nThis is the beginning of the builtin-commit.  The option parser has to go \nin before that (it was split out from the builtin-commit series), and the \n(minimal) adjustments to builtin-commit.c for the now-changed option \nparser have to be done.\n\nSo I think this topic should stay in master until builtin-commit is there, \ntoo.\n\n> * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n>  + rebase: allow starting from a dirty tree.\n>  + stash: implement \"stash create\"\n\nThis needs more work in rebase-i, and Junio indicated that he's not \ncompletely happy with it.\n\nIt would serve to be able to rebase in a dirty tree, by first stashing \naway the changes, and then applying them on top of the rebased branch.\n\nI think that this would avoid many \"Huh?\" effects, but it should try to \n\"git stash apply --index\" first, falling back to \"git stash apply\".\n\nSomething like that would be very nice for git-pull, too, I guess.\n\nHowever, I have not thought through all implications.\n\nCiao,\nDscho\n"},{"id":"56119","messageId":"20071016195744.GB32132@closure.lan","threadId":"10306","inReplyTo":"Pine.LNX.4.64.0710161209480.25221@racer.site","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-16T19:57:44Z","receivedAt":"2007-10-16T19:57:44Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:\n> \n> first let me thank you for being the interim maintainer.  I know it is \n> much work, and I frankly do not have the time, or nerve, to do it.  Out of \n> curiousity: did you use the scripts in \"todo\" to send these emails?\n\nI've recently started trying to use some of the scripts in \"todo\" to\nsend similar \"What's cooking\" messages, and started wondering if they\nwere what Junio actually used in production to send his notes.  For\nexample, the scripts don't work particularly well if the refs have\nbeen packed.  So I had to make changes such as these so they would\nwork for me.\n\nI was waiting for Junio to get back from vacation to ask if he was\ninterested in accepting such changes, and/or changes to make the\nscripts more general purpose, and possibly useful for other projects.\n\n\t\t     \t      \t     \t       - Ted\n\ndiff --git a/PU b/PU\nindex 4b4be2b..4643a42 100755\n--- a/PU\n+++ b/PU\n@@ -26,8 +26,8 @@ case \"$#\" in\n 0)\n \t# interactive ;-)\n \tshift\n-\tHH=`cd .git/refs/heads && find -type f |\n-\tsed -e 's/^\\.\\///' \\\n+\tHH=`git-show-ref --heads | awk '{print $2}' |\\\n+\tsed -e 's;refs/heads/;;' \\\n \t    -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`\n \twhile test \"$HH\"\n \tdo\ndiff --git a/RB b/RB\nindex 918a372..a890cfd 100755\n--- a/RB\n+++ b/RB\n@@ -3,9 +3,9 @@\n master_sha1=`git rev-parse --verify refs/heads/master`\n LF='\n '\n-(cd .git/refs/heads && find -type f) |\n+git-show-ref --heads | awk '{print $2}' |\n sed -n \\\n-    -e 's/^\\.\\///' \\\n+    -e 's;refs/heads/;;' \\\n     -e '/^[^\\/][^\\/]\\//p' |\n while read topic\n do\n"},{"id":"56149","messageId":"20071016234040.GF13801@spearce.org","threadId":"10306","inReplyTo":"Pine.LNX.4.64.0710161209480.25221@racer.site","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-16T23:40:40Z","receivedAt":"2007-10-16T23:40:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> first let me thank you for being the interim maintainer.  I know it is \n> much work, and I frankly do not have the time, or nerve, to do it.\n\nHeh.  In the past 24 hours I've really learned how much I appreciate\nthe work that Junio does, and how infrequently I make it known that\nI'm happy he's doing it for us.  Nothing like understanding what\nthe guy goes through then to walk a day in his shoes.  :-)\n\n> Out of \n> curiousity: did you use the scripts in \"todo\" to send these emails?\n\nYes.  Took me a few minutes to figure out which scripts did\nwhat magic.  Junio likes two character script names, because uh,\nthey are short to type.  Then I hand modified the output to say\ngit/spearce.git and appear from me, not Junio.  But otherwise they\nare the same scripts available from his Meta repository (aka the\ntodo branch).\n \n> On Tue, 16 Oct 2007, Shawn O. Pearce wrote:\n> \n> > * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit\n> \n> AFAIR this was ready to go to master, with a 5-10% speedup or so, just \n> needing a bit of testing.  Which it should have gotten by now.\n\nOK.  I'll look at it tomorrow and consider moving it.  I recall the\ncontext of this discussion now that you mention it, and I've been\nrunning this in production use since Junio committed it to next\nso I'm certainly not seeing any downsides to having this patch in\nthe tree.\n \n> > * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n> > * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n\nThanks for the summary on these two topics.  They are going to stay\nparked in next for a while then.  :-)\n\n-- \nShawn.\n"},{"id":"56192","messageId":"20071017032009.GS13801@spearce.org","threadId":"10306","inReplyTo":"20071016195744.GB32132@closure.lan","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-17T03:20:10Z","receivedAt":"2007-10-17T03:20:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> I've recently started trying to use some of the scripts in \"todo\" to\n> send similar \"What's cooking\" messages, and started wondering if they\n> were what Junio actually used in production to send his notes.  For\n> example, the scripts don't work particularly well if the refs have\n> been packed.  So I had to make changes such as these so they would\n> work for me.\n\nI think Junio just makes sure he doesn't pack his refs.  :-)\n \n> diff --git a/PU b/PU\n> index 4b4be2b..4643a42 100755\n> --- a/PU\n> +++ b/PU\n> @@ -26,8 +26,8 @@ case \"$#\" in\n>  0)\n>  \t# interactive ;-)\n>  \tshift\n> -\tHH=`cd .git/refs/heads && find -type f |\n> -\tsed -e 's/^\\.\\///' \\\n> +\tHH=`git-show-ref --heads | awk '{print $2}' |\\\n\nPerhaps `git for-each-ref --format='%(refname)' refs/heads` is the\nbetter change here as then you can avoid the pipe into awk.  We still\nneed the sed to strip the refs/heads/ off the results though.\n\n> +\tsed -e 's;refs/heads/;;' \\\n>  \t    -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`\n>  \twhile test \"$HH\"\n>  \tdo\n\nI'm actually applying it with the show-ref variant and will wind up\npushing it into my tree later tonight.  Because I do pack my refs.\n\n-- \nShawn.\n"},{"id":"56934","messageId":"7v3aw2aaxu.fsf@gitster.siamese.dyndns.org","threadId":"10306","inReplyTo":"20071016195744.GB32132@closure.lan","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-23T01:15:09Z","receivedAt":"2007-10-23T01:15:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:\n>> \n>> first let me thank you for being the interim maintainer.  I know it is \n>> much work, and I frankly do not have the time, or nerve, to do it.  Out of \n>> curiousity: did you use the scripts in \"todo\" to send these emails?\n>\n> I've recently started trying to use some of the scripts in \"todo\" to\n> send similar \"What's cooking\" messages, and started wondering if they\n> were what Junio actually used in production to send his notes.  For\n> example, the scripts don't work particularly well if the refs have\n> been packed.  So I had to make changes such as these so they would\n> work for me.\n\nSorry, WI is for \"what's in\", WC is for \"what's cooking\".  I\nshould remove PU and RB from there.\n"},{"id":"56935","messageId":"20071023012140.GC22997@thunk.org","threadId":"10306","inReplyTo":"7v3aw2aaxu.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T01:21:40Z","receivedAt":"2007-10-23T01:21:40Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:\n> >\n> > I've recently started trying to use some of the scripts in \"todo\" to\n> > send similar \"What's cooking\" messages, and started wondering if they\n> > were what Junio actually used in production to send his notes.  For\n> > example, the scripts don't work particularly well if the refs have\n> > been packed.  So I had to make changes such as these so they would\n> > work for me.\n> \n> Sorry, WI is for \"what's in\", WC is for \"what's cooking\".  I\n> should remove PU and RB from there.\n> \n\nI assume PU is what you used to build your proposed-update branch?\nI'm actually trying to use it, and it is useful, although it hasn't\nbeen working for me completely perfectly.  I've still been trying to\nfigure out if the reason why it hasn't been working quite right is due\nto my not understanding how to use it correctly, or whether you don't\nuse it these days.\n\nOne question which I have had about the WC script is that if I\nmanually add a commit to the next branch, it ends up showing up in all\nof the topic branches as a commit that was part of that topic branch\nwhich is in next.  So I can manually edit the output of WC to remove\nthe spurious commit, or I could make it be a rule that all new commits\neither must go against the master branch, or be put in a topic branch\nbased off of master, and then merged into next.  Or maybe I'm not\nunderstanding how to make the WC and git-topic.perl script work and\nsing for me perfectly?\n\n\t\t\t\t\t- Ted\n"},{"id":"56937","messageId":"7vtzoi8voo.fsf@gitster.siamese.dyndns.org","threadId":"10306","inReplyTo":"20071023012140.GC22997@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-23T01:29:59Z","receivedAt":"2007-10-23T01:29:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> I assume PU is what you used to build your proposed-update branch?\n> I'm actually trying to use it, and it is useful, although it hasn't\n> been working for me completely perfectly.  I've still been trying to\n> figure out if the reason why it hasn't been working quite right is due\n> to my not understanding how to use it correctly, or whether you don't\n> use it these days.\n\nAh, these days I almost always do:\n\n\tgit checkout pu\n\tgit reset --hard next\n\nand then merge the topics that haven't been merged anywhere by\nhand, using output from\n\n        Meta/git-topic.perl\n\nas the guide.\n\n> One question which I have had about the WC script is that if I\n> manually add a commit to the next branch, it ends up showing up in all\n> of the topic branches as a commit that was part of that topic branch\n> which is in next...\n\nWell, the policy is never to commit directly on top of next\n(iow, only merge other topics and nothing else).  Otherwise it\nbecomes hard to allow individual topics graduate to 'master'\nindependently.\n"},{"id":"56945","messageId":"20071023020044.GA27132@thunk.org","threadId":"10306","inReplyTo":"7vtzoi8voo.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T02:00:44Z","receivedAt":"2007-10-23T02:00:44Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:\n> Well, the policy is never to commit directly on top of next\n> (iow, only merge other topics and nothing else).  Otherwise it\n> becomes hard to allow individual topics graduate to 'master'\n> independently.\n\nI see.  So if it's non-trivial enough that you want it to \"cook\" in\nnext for a cycle, you'll create a topic branch for it (based off of\n'master'), and then force a merge into 'next'?\n\n\t\t\t\t\t- Ted\n"},{"id":"56948","messageId":"20071023040522.GX14735@spearce.org","threadId":"10306","inReplyTo":"20071023020044.GA27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T04:05:22Z","receivedAt":"2007-10-23T04:05:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:\n> > Well, the policy is never to commit directly on top of next\n> > (iow, only merge other topics and nothing else).  Otherwise it\n> > becomes hard to allow individual topics graduate to 'master'\n> > independently.\n> \n> I see.  So if it's non-trivial enough that you want it to \"cook\" in\n> next for a cycle, you'll create a topic branch for it (based off of\n> 'master'), and then force a merge into 'next'?\n\nYes.  Because 'next' always has commits in it that never appear in\n'master'.  So any topic forked from master must merge into next.\nIt can't be a fast-forward.  No forced merging required.\n\nOf course this isn't true for a new project.  That first topic\nthat forked from master to *create* next will be a fast-forward\nas it creates next.  But that's no big deal.  The second topic will\nmerge into next, and that first topic can still be merged back into\nmaster without merging next (or the second topic).\n\nI was also doing the same thing Junio already explained to manage\nnext and pu while he was away.  Except I shortcut his:\n\n\tgit checkout pu\n\tgit reset --hard next\n\nas:\n\n\tgit branch -f pu next\n\tgit checkout pu\n\nas I'm was usually already sitting on next.  This saved my poor\nlittle laptop from a second of IO chugging as it slewed around\nbetween the two versions.  There were no files to update as it\nswitched from next to pu, and pu was already setup for merging\nthe proposed topics.  :-)\n\n-- \nShawn.\n"},{"id":"56951","messageId":"20071023042752.GY14735@spearce.org","threadId":"10306","inReplyTo":"20071023012140.GC22997@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T04:27:52Z","receivedAt":"2007-10-23T04:27:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:\n> > \n> > Sorry, WI is for \"what's in\", WC is for \"what's cooking\".  I\n> > should remove PU and RB from there.\n> \n> I assume PU is what you used to build your proposed-update branch?\n\nActually I found PU of some use:\n\n\tgit branch -f pu next\n\tgit checkout pu\n\t./Meta/PU --continue\n\nits a little sluggish to list, but made it pretty easy to pick\ntopics for merging into pu.  git-rerere really makes it easy to\nrecover conflicts in pu during future rebuilds of pu.\n\n> based off of master, and then merged into next.  Or maybe I'm not\n> understanding how to make the WC and git-topic.perl script work and\n> sing for me perfectly?\n\nThe other tidbits I managed to learn by trial and error here was\nto make sure I did the following:\n\n\t- make sure master is fully merged into next\n\t- make sure next is fully merged into pu\n\t- Run \"Meta/git-topic.perl --base=master | less\"\n\nIt wasn't uncommon for me to merge master->next, next->pu, run\ngit-topic, then reset both next and pu *back* to what I had last\npublished (remote tracking branches updated during push make this\neasy) before moving on with my next and pu updating activities.\n\nOf course take my notes above with a grain of salt; I only worked\nthis way for a week and it took me a couple of days to come up with\nthe above.  Junio may very well have it streamlined even more.\n\n-- \nShawn.\n"},{"id":"56955","messageId":"20071023043321.GC27132@thunk.org","threadId":"10306","inReplyTo":"20071023040522.GX14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T04:33:21Z","receivedAt":"2007-10-23T04:33:21Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:\n>\n> Yes.  Because 'next' always has commits in it that never appear in\n> 'master'.  So any topic forked from master must merge into next.\n> It can't be a fast-forward.  No forced merging required.\n\nWhy is it the case that 'next' always commits that never appear in\n'master'.  So far in how I've been doing things that hasn't been the\ncase.  When I do a \"git checkout master; git merge next\", it's always\nbeen a fast-forward merge. \n\nOh, I see.  That's because if you put some trivial changes in\n'master', and then pull those changes into next, there will be merge\ncommits in 'next' that will never be in 'master.  Is that it?  \n\nI had been trying to avoid that case by always putting new commits,\neven trivial ones, into 'next', and then having them drop into\n'master' at the next cycle; so 'master' was always trailing 'next',\nbut they were always the same commit string (i.e., 'master' was always\na subset of 'next').  \n\nAside from the WC script not working right, are there other\ndisadvantages to my doing things that way as opposed to the way the\nJunio has been running the git repository?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"56958","messageId":"20071023044657.GC14735@spearce.org","threadId":"10306","inReplyTo":"20071023043321.GC27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T04:46:57Z","receivedAt":"2007-10-23T04:46:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:\n> >\n> > Yes.  Because 'next' always has commits in it that never appear in\n> > 'master'.  So any topic forked from master must merge into next.\n> > It can't be a fast-forward.  No forced merging required.\n> \n> Why is it the case that 'next' always commits that never appear in\n> 'master'.  So far in how I've been doing things that hasn't been the\n> case.  When I do a \"git checkout master; git merge next\", it's always\n> been a fast-forward merge. \n> \n> Oh, I see.  That's because if you put some trivial changes in\n> 'master', and then pull those changes into next, there will be merge\n> commits in 'next' that will never be in 'master.  Is that it?  \n\nExactly.  This of course means that next has been growing in distance\nfrom master for quite some time.  It has well over 1000 commits now\nin git.git that aren't in master.  Most of those will never merge\nthere either.\n \n> I had been trying to avoid that case by always putting new commits,\n> even trivial ones, into 'next', and then having them drop into\n> 'master' at the next cycle; so 'master' was always trailing 'next',\n> but they were always the same commit string (i.e., 'master' was always\n> a subset of 'next').  \n> \n> Aside from the WC script not working right, are there other\n> disadvantages to my doing things that way as opposed to the way the\n> Junio has been running the git repository?\n\nThe reason Junio does what he does is flexibility.\n\nBy merging only individual topics forked from master into next you\ncan merge those individual topics into master at different points\nin time.  For example db/fetch-pack has been in next for many weeks\nand hasn't yet merged into master, yet jc/am-quiet was forked after\ndb/fetch-pack started and has already merged into master.\n\nYour way would make jc/am-quiet wait until db/fetch-pack was ready.\nThat's a big risk in the sense that your tree is \"blocked\" and even\nsimple changes are held up by ones that suddenly became a lot more\ncomplex then you originally thought they were going to be.\n\n-- \nShawn.\n"},{"id":"56959","messageId":"20071023045632.GD27132@thunk.org","threadId":"10306","inReplyTo":"20071023044657.GC14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T04:56:32Z","receivedAt":"2007-10-23T04:56:32Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote:\n> By merging only individual topics forked from master into next you\n> can merge those individual topics into master at different points\n> in time.  For example db/fetch-pack has been in next for many weeks\n> and hasn't yet merged into master, yet jc/am-quiet was forked after\n> db/fetch-pack started and has already merged into master.\n> \n> Your way would make jc/am-quiet wait until db/fetch-pack was ready.\n> That's a big risk in the sense that your tree is \"blocked\" and even\n> simple changes are held up by ones that suddenly became a lot more\n> complex then you originally thought they were going to be.\n\nYes, true.  Alternatively, what I've been doing is that if I wasn't\nsure that a particular topic was ready to go to 'master' very shortly\nafter it went into 'next', I would never let it go into 'next', but\nrather keep it in 'pu' (which is OK, because pu is constantly getting\nrewound).  But I guess the downside of that is you might get fewer\ntesters for the code, because fewer people are probably tracking and\ntesting 'pu' as compared to 'next'.\n\nRight?\n\n\t\t\t\t\t- Ted\n"},{"id":"56960","messageId":"20071023050726.GD14735@spearce.org","threadId":"10306","inReplyTo":"20071023045632.GD27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T05:07:26Z","receivedAt":"2007-10-23T05:07:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote:\n> > By merging only individual topics forked from master into next you\n> > can merge those individual topics into master at different points\n> > in time.  For example db/fetch-pack has been in next for many weeks\n> > and hasn't yet merged into master, yet jc/am-quiet was forked after\n> > db/fetch-pack started and has already merged into master.\n> > \n> > Your way would make jc/am-quiet wait until db/fetch-pack was ready.\n> > That's a big risk in the sense that your tree is \"blocked\" and even\n> > simple changes are held up by ones that suddenly became a lot more\n> > complex then you originally thought they were going to be.\n> \n> Yes, true.  Alternatively, what I've been doing is that if I wasn't\n> sure that a particular topic was ready to go to 'master' very shortly\n> after it went into 'next', I would never let it go into 'next', but\n> rather keep it in 'pu' (which is OK, because pu is constantly getting\n> rewound).  But I guess the downside of that is you might get fewer\n> testers for the code, because fewer people are probably tracking and\n> testing 'pu' as compared to 'next'.\n> \n> Right?\n\nYes, that's a good point.\n\nI think in Git part of the reason less people track pu is because\nits very volatile.  Not because of the rewind policy, but becuase\nsometimes the code there doesn't work properly so using it for real\n\"production\" work is pretty risky.  On the other hand most of the\ncode that merges into next has been reasonbly well reviewed and\ntested, so following it for \"production\" work is not as risky.\n\nJunio has in the past proposed rewinding next, especially after a\nsignificant release (e.g. 1.5.3).  A bunch of folks (myself included\nif I recall correctly) didn't want to do this, as we create topic\nbranches locally from things in next and sometimes make commits\nover them to improve the topic further.  But I also make topic\nbranches for things in pu, so I might as well just shut up and\nnot complain.  :-)\n\nOf course another thought that just came to mind is it is very easy\nfor me to review next with a\n\n\tgit log -p --reverse origin/next..build-next\n\njust before merging it into my build branch and compiling it locally.\nIf next rewound frequently (as pu does) this would be more difficult.\n\n-- \nShawn.\n"},{"id":"56961","messageId":"20071023053003.GE27132@thunk.org","threadId":"10306","inReplyTo":"20071023050726.GD14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T05:30:03Z","receivedAt":"2007-10-23T05:30:03Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:\n> Junio has in the past proposed rewinding next, especially after a\n> significant release (e.g. 1.5.3).  \n\nHmm, yes.  I think I'd want to rewind next after a while; the thought\nof next drifting hundreds or thousands of commits away from master\njust gives me the heebee-jeebies.  I'm sure it mostly works, but it\njust feels wrong.  :-)\n\n> A bunch of folks (myself included if I recall correctly) didn't want\n> to do this, as we create topic branches locally from things in next\n> and sometimes make commits over them to improve the topic further.\n\nI guess I don't see why this would be a hardship; would a quick rebase\non the topic branches more or less take care of the problem?  \n\nI guess that brings up another question; I've been regularly rebasing\nthe topics branches as master and next advances... probably more out\nof superstition than anything else.  Is that a bad idea for any reason?\n\n\nHmm... I guess some of this would be really good to get into the Howto\nsection of the user guide when talking about git workflows!\n\n\t       \t    \t       \t       \t     \t - Ted\n"},{"id":"56964","messageId":"20071023054238.GE14735@spearce.org","threadId":"10306","inReplyTo":"20071023053003.GE27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T05:42:38Z","receivedAt":"2007-10-23T05:42:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Theodore Tso <tytso@mit.edu> wrote:\n> On Tue, Oct 23, 2007 at 01:07:26AM -0400, Shawn O. Pearce wrote:\n> > Junio has in the past proposed rewinding next, especially after a\n> > significant release (e.g. 1.5.3).  \n> \n> Hmm, yes.  I think I'd want to rewind next after a while; the thought\n> of next drifting hundreds or thousands of commits away from master\n> just gives me the heebee-jeebies.  I'm sure it mostly works, but it\n> just feels wrong.  :-)\n\nThere's been a couple of times in git history where Junio has basically\ndone this to whack next back into line:\n\n\tgit checkout next\n\tgit diff next master | git apply --index\n\tgit commit -m \"Whack next back in line\"\n\nBecause we've found a change or two lurking in there that shouldn't\nhave been there after a while.  I think it was related to a merge\nconflict that happened in next but didn't in master or something\nlike that.  But usually this difference exists as there's usually\nalways something cooking in next.\n \n> > A bunch of folks (myself included if I recall correctly) didn't want\n> > to do this, as we create topic branches locally from things in next\n> > and sometimes make commits over them to improve the topic further.\n> \n> I guess I don't see why this would be a hardship; would a quick rebase\n> on the topic branches more or less take care of the problem?  \n\nYes.  But you need the prior value of the branch so you can do\nsomething easy like:\n\n\tgit checkout yourtopic\n\tgit rebase --onto $newtopic $oldtopic\n\nwhich means you probably need to look through the logs for not just\npu but also pu@{1}.  A script to break out the topic branches from\npu post fetch and store them as proper tracking branches would make\nthis easier, but that much.  If you plan ahead you can save that\n$oldtopic point so you can do something like this:\n\n\tgit log pu ; # find $newtopic\n\tgit checkout yourtopic\n\tgit rebase --onto $newtopic base-yourtopic\n\tgit tag -f base-yourtopic $newtopic\n\n> I guess that brings up another question; I've been regularly rebasing\n> the topics branches as master and next advances... probably more out\n> of superstition than anything else.  Is that a bad idea for any reason?\n\nIt keeps the history shorter in gitk.  But otherwise it isn't bad.\nUnless you are running into a lot of conflicts every time you rebase\nand its wasting your time.  ;-)\n\nI prefer to rebase the topics until they've merged to an integration\nbranch that doesn't rewind (e.g. master or next in git.git).\nThat way they have the shortest line possible in gitk between the\nfinal merge and the start point.\n\nThere are good reasons why there's an \"author\" and a \"committer\"\nfield in commits.  Rebasing will change the committer field's\ntimestamp, but not the author field.  And author comes from the\nemail, to preserve the original date of development.\n \n> Hmm... I guess some of this would be really good to get into the Howto\n> section of the user guide when talking about git workflows!\n\nYea, I think so too.  We've adopted this model in git.git because\nit works for our community.  A lot of other communities aren't\ntoo far away, as we have a lot of crossover in members.  E.g. we\nlearned a lot from the kernel community.\n\n-- \nShawn.\n"},{"id":"56997","messageId":"20071023120338.GG27132@thunk.org","threadId":"10306","inReplyTo":"20071023054238.GE14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-23T12:03:38Z","receivedAt":"2007-10-23T12:03:38Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 23, 2007 at 01:42:38AM -0400, Shawn O. Pearce wrote:\n> Yes.  But you need the prior value of the branch so you can do\n> something easy like:\n> \n> \tgit checkout yourtopic\n> \tgit rebase --onto $newtopic $oldtopic\n> \n> which means you probably need to look through the logs for not just\n> pu but also pu@{1}.  A script to break out the topic branches from\n> pu post fetch and store them as proper tracking branches would make\n> this easier, but that much.  If you plan ahead you can save that\n> $oldtopic point so you can do something like this:\n> \n> \tgit log pu ; # find $newtopic\n> \tgit checkout yourtopic\n> \tgit rebase --onto $newtopic base-yourtopic\n> \tgit tag -f base-yourtopic $newtopic\n\nYeah, I had thought about writing a little script that would take my\nproject's topic branches, and then push them out into the public\nrepository under topics/ad/extents-testcases or\ntopics/tt/badblocks-cleanup.  That would make it easy to find the head\nof your topic, and once you find that, the base of your-topic isn't\nthat hard to find, since it would just be the result of \"git-rev-list\ntopic ^master | tail -1\".\n\nOne of the reasons I was thinking the above is because most of the\npatches are coming into my end as emailed patch series, and I end up\ntweaking them a lot as I carry them around in the topics branch.  So\nif other people want to see what I've done to a branch after I've done\na git rebase --interactive, it's easier if they can get access to the\nindividual topics branch, so they can extract out the patch series\nwhile it's being tweaked by me (and possibly others).\n\nThis is probably because my view of git has been colored by kernel\ncommunity practices, where patches are normally perfected and get\nrebased a lot (normally in a sub-maintainer or maintainer's tree)\nbefore they get pushed to Linus, and in my mental model a topic branch\nrepresents the maintainer's git tree in the central repository.\n\nThe extreme end of this would be the classical BitKeeper model, where\nLarry McVoy once argued to me that he didn't like history to *ever* be\nrewound/rewritten, since not only did this interfere with other people\ntrees once they had been pushed, but it causes development history to\nbe lost, which is always valuable.  (Of course, in the end he did\nwrite \"bk fold\", which squashes the last N commits into 1, mainly due\nto customer pressure.)  The kernel viewpoint is to rebase all the\ntime, because the history is so huge that we don't *want* to see the\ndevelopment history of the rough drafts of features before they get\nmerged into mainline.\n\n> It keeps the history shorter in gitk.  But otherwise it isn't bad.\n> Unless you are running into a lot of conflicts every time you rebase\n> and its wasting your time.  ;-)\n\nIt sounds like what you are saying here is that the git.git tree takes\na viewpoint which is slightly between the extremes of the kernel model\n(which does involve resolving rebasing a lot and resolving lots of\nconflicts, but heh, that's not Linus's problem, that's been pushed out\nto the leafs of the developer community, and besides, it strongly\nencourages topics to get merged into the mainline fast), and the\nclassical Bitkeeper model, which says that philosophical goodness\nmeans you should keep *all* development history once it enters the BK SCM.\n\nWith git.git, we are essentially throwing away development history\nwhile it is in 'pu', but once a commit graduates to 'next', we do keep\nthe development history forever.  The downside to this is that\ndevelopment 'crud' can build up in next; even if all substantive\ncommits in 'next' end up graduating to 'master', there will still be\nlots of merge commits that will only be in 'next'.   \n\nI have an emotional bias which tends to treat that excess history as\ntoxic waste to be avoided at all costs, but that's probably because\nwhen you have a git tree as huge as the kernel, life is easier if the\nhistory is kept as clean as possible.  \n\nWhich I suppose is easy enough to do in the git.git model; if you\nthrow away the 'next' branch and then rewind it so it is forked off of\n'master' all of that history essentially gets flushed.  The downside\nis that people maintaining topics branches which were forked against\nthe old 'next' will need to do some grotty work to rebase their\npatches, so any attempt to rewind next would probably require the\ncentral maintainer to give plenty of notice, and then on the flag day,\nsave 'next' as 'old-next' before rewinding to allow the other\ndevelopers to more easily rebase any private branches they might have.\n\nHmm, interesting.  A lot of this is quite subtle, or at least the\nimpacts of different choices in the git workflow really didn't become\nobvious to me until I started trying I stepped into the central\nmaintainer role for a project using git!\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"57008","messageId":"Pine.LNX.4.64.0710231131320.32497@iabervon.org","threadId":"10306","inReplyTo":"20071023120338.GG27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-23T17:44:36Z","receivedAt":"2007-10-23T17:44:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I keep thinking that there should be a better mechanism to use for \"pu\" \nthan a branch. Normally what you see in \"pu\" is a sequential merge of \n\"next\" and a number of topic branches, where the series of merges is \neither entirely uninteresting or only interesting in a schematic sense \n(that is, it is interesting what topics appear, and in what order, but the \nsnapshot of each topic's head when it got merged isn't interesting).\n\nThat is, the work which \"pu\" consists of, and therefore the history is a \nsequence of steps, each of which is one or more of: \"add this topic\", \n\"update this topic\", \"remove this topic\", \"update to a new next\". And we \ndon't keep a record of this history, but it's not what's discarded by \nrewinding anyway.\n\nI think that, if we actually care about this sort of thing, we'd want to \nmake \"pu\" a series of commits, each with the previous \"pu\" as the sole \nparent, with a series object given in a new header. The series object \nwould start with a \"next\" commit, and then list the topics merged by name \nand head-as-merged. Of course, the \"pu\" commits would contain the \nresulting tree as normal, so that people without a git that understands \nthis would see \"pu\" as consisting of a straight line of commits, each of \nwhich simply shows the net effect of the changes. Or something like that. \nI suppose \"pu\" could also be represented as a superproject where each \nsubproject is \"next\" or a topic branch, if we really want to avoid \nintroducing new objects, but that seems unweildy somehow.\n\nIs this worth doing? It might be; I bet it would make debugging -mm a \nwhole lot nicer. (First bisect through -mm to find the action Andrew took \nthat accepted the breakage, then bisect the history within that action.) I \nbet the status quo is a real pain when the feature that broke is only in \n-mm and later in Andrew's list than the tree whose change triggered the \nfailure (i.e., -mm4 works; -mm5 doesn't work, and everything in -mm5 is \neither broken or untestable).\n\nAnd, of course, \"origin/pu[db/builtin-fetch]\" would be an easy thing to \nbuild into git, and it could even generate extra magic, where it knows \nwhat the topic was last rebased on, so git could lead people through \n\"rebase everything in a pu collection on the new base for the collection\"\nand \"make my local topic branch agree with my topic branch as present in \norigin/pu\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"57015","messageId":"7vtzoh7j1l.fsf@gitster.siamese.dyndns.org","threadId":"10306","inReplyTo":"20071023120338.GG27132@thunk.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-23T19:00:38Z","receivedAt":"2007-10-23T19:00:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> With git.git, we are essentially throwing away development history\n> while it is in 'pu', but once a commit graduates to 'next', we do keep\n> the development history forever.  The downside to this is that\n> development 'crud' can build up in next; even if all substantive\n> commits in 'next' end up graduating to 'master', there will still be\n> lots of merge commits that will only be in 'next'.   \n>\n> I have an emotional bias which tends to treat that excess history as\n> toxic waste to be avoided at all costs, but that's probably because\n> when you have a git tree as huge as the kernel, life is easier if the\n> history is kept as clean as possible.  \n>\n> Which I suppose is easy enough to do in the git.git model; if you\n> throw away the 'next' branch and then rewind it so it is forked off of\n> 'master' all of that history essentially gets flushed.\n\nYou can view 'next' as if it is sort of -mm.  Following 'master'\nis like following Linus tree, whose development is without those\nnumerous 'merge improvements again' merges into 'next'.\n\n> The downside\n> is that people maintaining topics branches which were forked against\n> the old 'next' will need to do some grotty work to rebase their\n> patches, so any attempt to rewind next would probably require the\n> central maintainer to give plenty of notice, and then on the flag day,\n> save 'next' as 'old-next' before rewinding to allow the other\n> developers to more easily rebase any private branches they might have.\n\nAn alternative is to give an easier access to the tips of\nindividual topic branch head, at least to the ones that have\nbeen merged to 'next' as they will never be rewound once they\nare in 'next', and encourage people to fork off of them, instead\nof 'next' directly.  Then 'next' will be more like 'pu'.\n\n> Hmm, interesting.  A lot of this is quite subtle, or at least the\n> impacts of different choices in the git workflow really didn't become\n> obvious to me until I started trying I stepped into the central\n> maintainer role for a project using git!\n\nVery true.\n"},{"id":"57059","messageId":"20071024001240.GB6404@thunk.org","threadId":"10306","inReplyTo":"7vtzoh7j1l.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-24T00:12:40Z","receivedAt":"2007-10-24T00:12:40Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 23, 2007 at 12:00:38PM -0700, Junio C Hamano wrote:\n> \n> You can view 'next' as if it is sort of -mm.  Following 'master'\n> is like following Linus tree, whose development is without those\n> numerous 'merge improvements again' merges into 'next'.\n\nActually -mm is much closer to 'pu', since it can and is rewound all\nthe time.  Patches can disappear if they are causing problems, they\ncan be replaced and reworked, etc.\n\n\t\t\t\t\t\t- Ted\n"}]}