{"thread":{"id":"15699","subject":"interactive rebase not rebasing","startedAt":"2008-09-29T04:50:13Z","lastAt":"2008-10-01T21:26:01Z","messageCount":9,"participants":["Stephen Haberman","Andreas Ericsson","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"91821","messageId":"20080928235013.5c749c6e.stephen@exigencecorp.com","threadId":"15699","inReplyTo":null,"subject":"interactive rebase not rebasing","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2008-09-29T04:50:13Z","receivedAt":"2008-09-29T04:50:13Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"Hello,\n\nPer the emails from me last week, I'm working in an environment with\nshared topic branches and am trying to find a bullet-proof way for devs\nto rebase their local commits after the topic branch has moved.\n\nThe easy approach would be to just let `git pull` create merge commits,\nand I would have been done with this long ago, but I'm striving to get\nrebasing to \"just work\" and avoid the ugliness of same-branch merge\ncommits. Cross-branch merge commits are cool, but not same-branch.\n\nSo, here's a crazy scenario we've ran into--a new release has hit\nstable, with two devs working on the same topic branch, and both of them\nmerge. One wins, and the other has to rebase. Previously, this was\nreplaying commits, but with great tips from the list last week, `rebase\n-i -p` is handling most scenarios.\n\nHowever, not this one:\n\n# A --C------            <-- origin/stable\n#  \\  |      \\\n#   B -- D -- E -- F     <-- origin/topic2\n#    \\|\n#     g -- h             <-- topic2\n\ntopic2 is a dev that has locally merged stable in g, moved on in h, is\nready to push, but another dev already merged stable in E, and also\ncommitted F.\n\nIf we do a `git pull --no-rebase`, the result is:\n\n# A --C------            <-- origin/stable\n#  \\  |      \\\n#   B -- D -- E -- F     <-- origin/topic2\n#    \\|             \\\n#     g -- h ------- i   <-- topic2\n\nBut i is a same-branch merge, and we'd rather rebase to something like:\n\n# A --C------            <-- origin/stable\n#  \\         \\\n#   B -- D -- E -- F     <-- origin/topic2\n#                   \\\n#                    h'  <-- topic2\n\n(...maybe g' in there if g resolved stable conflicts differently\nE did them. I'm not sure, I haven't gotten there yet.)\n\nHowever, currently, `git rebase -i -p origin/topic2` results in:\n\n# A --C------            <-- origin/stable\n#  \\  |      \\\n#   B -- D -- E -- F     <-- origin/topic2\n#    \\|\n#     g -- h             <-- topic2\n\nNothing has changed. g & h haven't moved...I can keep executing this\noperation and the commits never make it on top of origin/topic2's F. \n\nFrustratingly, if I run non-interactive rebase, it works perfectly. But\nI've got other cases (see earlier posts) that do need the interactive\nrebase. Personally, I could probably make do with trying each and\nseeing what happened, but I'm really trying to find a bullet proof\ncommand/alias/script for devs to run and have it \"just work\".\n\nI've attached a test that sets up the DAG as above and currently passes\nby asserting the not-desired/unchanged-DAG result. The assert for the\ndesired result is commented out at the end.\n\nAm I correct in asserting this is some sort of bug in the interactive\nrebase such that g & h are not ending up on top of F?\n\nThanks,\nStephen\n\n\n\n\n#!/bin/sh\n\ntest_description='rebase interactive does not rebase'\n\n. ./test-lib.sh\n\ntest_expect_success 'setup' '\n\techo \"setup\" >a &&\n\tgit add a &&\n\tgit commit -m \"setup\" &&\n\tgit clone ./. server &&\n\trm -fr server/.git/hooks &&\n\tgit remote add origin ./server &&\n\tgit config --add branch.master.remote origin &&\n\tgit config --add branch.master.merge refs/heads/master &&\n\tgit fetch &&\n\n\tgit checkout -b stable master &&\n\techo \"setup.stable\" >a &&\n\tgit commit -a -m \"stable\" &&\n\tgit push origin stable\n'\n#\n# A --C------            <-- origin/stable\n#  \\  |      \\\n#   B -- D -- E -- F     <-- origin/topic2\n#    \\|             \\\n#     g -- h ------- i   <-- topic2\n#\n# Trying to push F..i\n#\n# merge-base(F, h) has two options: B and C\n#\ntest_expect_success 'merging in stable with tricky double baserev does not fool the script' '\n\t# B: start our topic2 branch, and share it\n\tgit checkout -b topic2 origin/stable &&\n\tgit config --add branch.topic2.merge refs/heads/topic2 &&\n\techo \"commit B\" >a.topic2 &&\n\tgit add a.topic2 &&\n\tgit commit -m \"commit B created topic2\" &&\n\tgit push origin topic2 &&\n\n\t# C: now, separately, move ahead stable, and share it\n\tgit checkout stable\n\techo \"commit C\" >a &&\n\tgit commit -a -m \"commit C moved stable\" &&\n\tgit push origin stable &&\n\n\t# D: have another client commit (in this case, it is the server, but close enough) moves topic2\n\tcd server &&\n\tgit checkout topic2 &&\n\techo \"commit D continuing topic2\" >a.client2 &&\n\tgit add a.client2 &&\n\tgit commit -m \"commit D by client2\" &&\n\n\t# E: the same other client merges the moved stable\n\tgit merge stable &&\n\n\t# F: the same other client moves topic2 again\n\techo \"commit F\" >a.client2 &&\n\tgit commit -a -m \"commit F by client2\" &&\n\tF_hash=$(git rev-parse HEAD) &&\n\tcd .. &&\n\n\t# g: now locally merge in the moved stable (even though our topic2 is out of date)\n\tgit checkout topic2 &&\n\tgit merge stable &&\n\tg_hash=$(git rev-parse HEAD) &&\n\n\t# h: advance local topic2\n\techo \"commit H\" >a.topic2 &&\n\tgit commit -a -m \"commit H continues local fork\" &&\n\th_hash=$(git rev-parse HEAD) &&\n\n\t# i: make a new merge commit\n\tgit pull --no-rebase &&\n\ti_hash=$(git rev-parse HEAD) &&\n\n\t# Watch merge rejected as something that should get rebased\n\t# ! git push origin topic2\n\ttest \"$i_hash $h_hash $F_hash\" = \"$(git rev-list --parents --no-walk HEAD)\"\n\n\t# Now fix it the merge by rebasing it\n\tgit reset --hard ORIG_HEAD &&\n\tGIT_EDITOR=: git rebase -i -p origin/topic2 &&\n\th2_hash=$(git rev-parse HEAD) &&\n\n\t# Should be:\n\t# test \"$h2_hash $F_hash\" = \"$(git rev-list --parents --no-walk HEAD)\"\n\t# But is just:\n\ttest \"$h_hash $g_hash\" = \"$(git rev-list --parents --no-walk HEAD)\"\n\t# Where did $F_hash go?\n'\n\ntest_done\n\n"},{"id":"91827","messageId":"48E078BF.5030806@op5.se","threadId":"15699","inReplyTo":"20080928235013.5c749c6e.stephen@exigencecorp.com","subject":"Re: interactive rebase not rebasing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-09-29T06:42:07Z","receivedAt":"2008-09-29T06:42:07Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Stephen Haberman wrote:\n> Hello,\n> \n> Per the emails from me last week, I'm working in an environment with\n> shared topic branches and am trying to find a bullet-proof way for devs\n> to rebase their local commits after the topic branch has moved.\n> \n> The easy approach would be to just let `git pull` create merge commits,\n> and I would have been done with this long ago, but I'm striving to get\n> rebasing to \"just work\" and avoid the ugliness of same-branch merge\n> commits. Cross-branch merge commits are cool, but not same-branch.\n> \n> So, here's a crazy scenario we've ran into--a new release has hit\n> stable, with two devs working on the same topic branch, and both of them\n> merge. One wins, and the other has to rebase. Previously, this was\n> replaying commits, but with great tips from the list last week, `rebase\n> -i -p` is handling most scenarios.\n> \n> However, not this one:\n> \n> # A --C------            <-- origin/stable\n> #  \\  |      \\\n> #   B -- D -- E -- F     <-- origin/topic2\n> #    \\|\n> #     g -- h             <-- topic2\n> \n> topic2 is a dev that has locally merged stable in g, moved on in h, is\n> ready to push, but another dev already merged stable in E, and also\n> committed F.\n> \n> If we do a `git pull --no-rebase`, the result is:\n> \n> # A --C------            <-- origin/stable\n> #  \\  |      \\\n> #   B -- D -- E -- F     <-- origin/topic2\n> #    \\|             \\\n> #     g -- h ------- i   <-- topic2\n> \n> But i is a same-branch merge, and we'd rather rebase to something like:\n> \n> # A --C------            <-- origin/stable\n> #  \\         \\\n> #   B -- D -- E -- F     <-- origin/topic2\n> #                   \\\n> #                    h'  <-- topic2\n> \n> (...maybe g' in there if g resolved stable conflicts differently\n> E did them. I'm not sure, I haven't gotten there yet.)\n> \n> However, currently, `git rebase -i -p origin/topic2` results in:\n> \n> # A --C------            <-- origin/stable\n> #  \\  |      \\\n> #   B -- D -- E -- F     <-- origin/topic2\n> #    \\|\n> #     g -- h             <-- topic2\n> \n> Nothing has changed. g & h haven't moved...I can keep executing this\n> operation and the commits never make it on top of origin/topic2's F. \n> \n> Frustratingly, if I run non-interactive rebase, it works perfectly.\n\nI can imagine. Since you don't want to preserve the merges in this\ncase, you shouldn't be using the -p flag.\n\nIn fact, for this particular scenario (assuming \"h\" is really the only\ncommit on topic2), you probably want to just cherry-pick that commit\ninto origin/topic2:\n\n   git checkout topic2\n   git reset --hard origin/topic2\n   git cherry-pick ORIG_HEAD\n\nwould work nicely for that. If topic2 and topic1 resolved merge\nconflicts differently, cherry-picking topic2 will give conflicts again,\nso they'll have to be resolved. rebase (without -p) will have the same\neffect, ofcourse.\n\nI don't think you can have a single command that does all the things\nyou want, because the possible differences in input makes it very nearly\nimpossible to always do \"the right thing\". For this case, you don't\nwant to preserve merges, so \"git rebase\" without -p does the right\nthing. For that other case earlier this week, you wanted to preserve\nmerges, so \"git rebase -p\" does the right thing there. It's complex\nto try to dwim things like that, and complexity will cause very weird\nand surprising errors when it *does* fail.\n\nInstead, I think you should give your developers some training in the\nmore advanced parts of git's integration tools and also look over\nyour workflow. Frequently merging 'master' into a topic is very rarely\nthe right thing to do. It's usually better to rebase the topic onto\nmaster or cherry-pick relevant bugfixes from 'master' into the topic.\nIf two devs need to work on one topic, then that topic probably needs\nbreaking up into a sub-topic. However, sub-topics should never merge\n'master' into them themselves; only 'topic'. Otherwise you'll get\nmore merges than work done.\n\n\n> But\n> I've got other cases (see earlier posts) that do need the interactive\n> rebase. Personally, I could probably make do with trying each and\n> seeing what happened, but I'm really trying to find a bullet proof\n> command/alias/script for devs to run and have it \"just work\".\n> \n\nOr you could sit down and think about what you want to happen and then\nrun the appropriate command. ;-)\n\n> I've attached a test that sets up the DAG as above and currently passes\n> by asserting the not-desired/unchanged-DAG result. The assert for the\n> desired result is commented out at the end.\n> \n\nThanks for this. If all bug-reports had this, bugfixing would be a lot\neasier. However, for this particular case, I'm not so sure it's a bug.\n\n> Am I correct in asserting this is some sort of bug in the interactive\n> rebase such that g & h are not ending up on top of F?\n> \n\nAssuming you're passing a correct input file to rebase -i; yes. At the\nvery least, \"h\" should be moved to the tip of origin/topic2.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"92028","messageId":"20081001010306.01cc34eb.stephen@exigencecorp.com","threadId":"15699","inReplyTo":"48E078BF.5030806@op5.se","subject":"Re: interactive rebase not rebasing","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2008-10-01T06:03:06Z","receivedAt":"2008-10-01T06:03:06Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> > # A --C------            <-- origin/stable\n> > #  \\  |      \\\n> > #   B -- D -- E -- F     <-- origin/topic2\n> > #    \\|\n> > #     g -- h             <-- topic2\n> > \n> > Nothing has changed. g & h haven't moved...I can keep executing this\n> > operation and the commits never make it on top of origin/topic2's F. \n> > \n> > Frustratingly, if I run non-interactive rebase, it works perfectly.\n> \n> I can imagine. Since you don't want to preserve the merges in this\n> case, you shouldn't be using the -p flag.\n\nNo, I do want to preserve most merges. This \"most\" qualification is\nbecause the merge \"g\", if rebased, would have been a no-op, so `rebase\n-i -p` correctly kept it out of the TODO file.\n\nWhich is cool, except that later on, when rewriting the other TODO\ncommits, some of which were children of \"g\", it did not remember that\n\"g\" had gone away, so did nothing to take \"g\" out of the rewritten\nchildren's parent list.\n\n> In fact, for this particular scenario (assuming \"h\" is really the only\n> commit on topic2), you probably want to just cherry-pick that commit\n> into origin/topic2:\n> \n>    git checkout topic2\n>    git reset --hard origin/topic2\n>    git cherry-pick ORIG_HEAD\n\nAgreed. This makes a lot of sense for me, who has been hacking around in\ngit-rebase--interactive fixing things, but I'd really like the other\npeople on my team to just have to run `git rebase -i -p`.\n\n> I don't think you can have a single command that does all the things\n> you want, because the possible differences in input makes it very\n> nearly impossible to always do \"the right thing\".\n\nAh, you are too pessimistic. :-)\n\n> Assuming you're passing a correct input file to rebase -i; yes. At the\n> very least, \"h\" should be moved to the tip of origin/topic2.\n\nCool, agreed. I've got a patch that gets `rebase -i -p` to do this. I'll\nsend it to the list soon.\n\n- Stephen\n"},{"id":"92036","messageId":"48E32BD4.1050107@op5.se","threadId":"15699","inReplyTo":"20081001010306.01cc34eb.stephen@exigencecorp.com","subject":"Re: interactive rebase not rebasing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-01T07:50:44Z","receivedAt":"2008-10-01T07:50:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Stephen Haberman wrote:\n>>> # A --C------            <-- origin/stable\n>>> #  \\  |      \\\n>>> #   B -- D -- E -- F     <-- origin/topic2\n>>> #    \\|\n>>> #     g -- h             <-- topic2\n>>>\n>>> Nothing has changed. g & h haven't moved...I can keep executing this\n>>> operation and the commits never make it on top of origin/topic2's F. \n>>>\n>>> Frustratingly, if I run non-interactive rebase, it works perfectly.\n>> I can imagine. Since you don't want to preserve the merges in this\n>> case, you shouldn't be using the -p flag.\n> \n> No, I do want to preserve most merges. This \"most\" qualification is\n> because the merge \"g\", if rebased, would have been a no-op, so `rebase\n> -i -p` correctly kept it out of the TODO file.\n> \n> Which is cool, except that later on, when rewriting the other TODO\n> commits, some of which were children of \"g\", it did not remember that\n> \"g\" had gone away, so did nothing to take \"g\" out of the rewritten\n> children's parent list.\n> \n>> In fact, for this particular scenario (assuming \"h\" is really the only\n>> commit on topic2), you probably want to just cherry-pick that commit\n>> into origin/topic2:\n>>\n>>    git checkout topic2\n>>    git reset --hard origin/topic2\n>>    git cherry-pick ORIG_HEAD\n> \n> Agreed. This makes a lot of sense for me, who has been hacking around in\n> git-rebase--interactive fixing things, but I'd really like the other\n> people on my team to just have to run `git rebase -i -p`.\n> \n>> I don't think you can have a single command that does all the things\n>> you want, because the possible differences in input makes it very\n>> nearly impossible to always do \"the right thing\".\n> \n> Ah, you are too pessimistic. :-)\n> \n\nPerhaps, although I think you're being overly optimistic if you think\nrebase can do all of this intelligently while still retaining clear\nsemantics. I'd start with writing a separate tool for it, probably\nbased on git sequencer. When that works out ok, get it to do what\nrebase does today and then incorporate the new tool as an option to\nrebase and get ready to answer complex questions for the cases where\nit doesn't do what the user wanted it to do.\n\nGit is stupid very, very much by design. Linus constantly says that\nhe prefers tools that he can figure out why they did something stupid\nover tools that try really hard to get it right, and I agree with him\n100%, as do most of the core contributors (insofar as I've understood\nit). What you're suggesting is that a git command should try hard to\ndwim a lot of complexity about choosing tools away, and that goes\nright against the KISS principle which serves git so well. I'm not\nsaying you shouldn't do it. Merely that you should think hard about\nit and then make sure it doesn't break anything people are already\ndoing today with the current toolset.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"92054","messageId":"20081001095225.d28de16a.stephen@exigencecorp.com","threadId":"15699","inReplyTo":"48E32BD4.1050107@op5.se","subject":"Re: interactive rebase not rebasing","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2008-10-01T14:52:25Z","receivedAt":"2008-10-01T14:52:25Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> >> I don't think you can have a single command that does all the\n> >> things you want, because the possible differences in input makes it\n> >> very nearly impossible to always do \"the right thing\".\n> > \n> > Ah, you are too pessimistic. :-)\n> > \n> \n> Perhaps, although I think you're being overly optimistic if you think\n> rebase can do all of this intelligently while still retaining clear\n> semantics. I'd start with writing a separate tool for it, probably\n> based on git sequencer.\n\nI would agree with this, except that --preserve-merges is already in\nthe codebase and does what we want. I'm not fundamentally changing how\nit works (e.g. how it decides what commits to keep/rewrite/etc.), I just\nfound and patched a bug in it.\n\n> When that works out ok, get it to do what rebase does today and then\n> incorporate the new tool as an option to rebase and get ready to\n> answer complex questions for the cases where it doesn't do what the\n> user wanted it to do.\n\nYeah, I'm sorry, I did not mean my \"pessimistic\" comment that\nseriously. I understand `git rebase` can never do what everyone wants\nin all scenarios.\n\nBut given /this/ scenario (hehe), with the implementation's existing\nexplicit usage of \"--left-right --cherry-pick\" to drop no-op commits,\nbut then it's forgetting of this information later, leading to `git\nrebase` not performing a rebase at all, I think it is an obvious bug,\nand one that can be fixed without changing any of `git rebase`s\nexisting semantics.\n\n> Merely that you should think hard about it and then make sure it\n> doesn't break anything people are already doing today with the current\n> toolset.\n\nI've attempted to do that. Now that I sent in the patch, if you could\nreview it, I would appreciate your feedback. I do need to rework the\ntest case because I realized including the origin/pull aspects (which\nis what caused us to find it) is just noise and the bug can be\nreproduced with just local branches.\n\nThanks,\nStephen\n"},{"id":"92064","messageId":"48E396AF.2000100@op5.se","threadId":"15699","inReplyTo":"20081001095225.d28de16a.stephen@exigencecorp.com","subject":"Re: interactive rebase not rebasing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-01T15:26:39Z","receivedAt":"2008-10-01T15:26:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Stephen Haberman wrote:\n> \n> But given /this/ scenario (hehe), with the implementation's existing\n> explicit usage of \"--left-right --cherry-pick\" to drop no-op commits,\n> but then it's forgetting of this information later, leading to `git\n> rebase` not performing a rebase at all, I think it is an obvious bug,\n> and one that can be fixed without changing any of `git rebase`s\n> existing semantics.\n> \n\nAgreed.\n\n>> Merely that you should think hard about it and then make sure it\n>> doesn't break anything people are already doing today with the current\n>> toolset.\n> \n> I've attempted to do that. Now that I sent in the patch, if you could\n> review it, I would appreciate your feedback.\n\nI'm heading home from work now. I'll look it over tonight or tomorrow\nmorning. Thanks for the confidence :-)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"92076","messageId":"20081001121321.5761fc7e.stephen@exigencecorp.com","threadId":"15699","inReplyTo":"48E396AF.2000100@op5.se","subject":"Re: interactive rebase not rebasing","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2008-10-01T17:13:21Z","receivedAt":"2008-10-01T17:13:21Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> > I've attempted to do that. Now that I sent in the patch, if you could\n> > review it, I would appreciate your feedback.\n> \n> I'm heading home from work now. I'll look it over tonight or tomorrow\n> morning.\n\nCool, thanks.\n\nQuestion: how taboo is it to just add another test file?\n\nI'm attempting to integrate my test into t3404, which is the existing\ninteractive rebase test. The two test_expect_success's I added worked\nwhen I ran them at the start of the test and then reset --hard the\nbranches back for the other tests, but if I paste my tests where they\nshould probably be, in the middle after the other -p tests, they break\nbecause the 10 or tests before this have screwed with the DAG already.\n\nI can suffer through getting it to work, but a t3409 would be much\neasier, and probably easier to read as well as a I could setup my own\nDAG instead of hacking onto 3404s.\n\n> Thanks for the confidence :-)\n\nNo problem. :-)\n\n- Stephen\n"},{"id":"92079","messageId":"20081001183135.GL21310@spearce.org","threadId":"15699","inReplyTo":"20081001121321.5761fc7e.stephen@exigencecorp.com","subject":"Re: interactive rebase not rebasing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-01T18:31:35Z","receivedAt":"2008-10-01T18:31:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Stephen Haberman <stephen@exigencecorp.com> wrote:\n> \n> > > I've attempted to do that. Now that I sent in the patch, if you could\n> > > review it, I would appreciate your feedback.\n> > \n> > I'm heading home from work now. I'll look it over tonight or tomorrow\n> > morning.\n> \n> Cool, thanks.\n> \n> Question: how taboo is it to just add another test file?\n> \n> I can suffer through getting it to work, but a t3409 would be much\n> easier, and probably easier to read as well as a I could setup my own\n> DAG instead of hacking onto 3404s.\n\nUsually folks prefer to add stuff to an existing test file, but\nif the DAG is already a mess and you need a different DAG I find\nit easier to just add new test file.  Thus far Junio hasn't pushed\nback when I've done that.  Maybe I'm just lucky.  :-)\n\n-- \nShawn.\n"},{"id":"92098","messageId":"48E3EAE9.5070207@op5.se","threadId":"15699","inReplyTo":"20081001121321.5761fc7e.stephen@exigencecorp.com","subject":"Re: interactive rebase not rebasing","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-01T21:26:01Z","receivedAt":"2008-10-01T21:26:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Stephen Haberman wrote:\n>>> I've attempted to do that. Now that I sent in the patch, if you could\n>>> review it, I would appreciate your feedback.\n>> I'm heading home from work now. I'll look it over tonight or tomorrow\n>> morning.\n> \n> Cool, thanks.\n> \n> Question: how taboo is it to just add another test file?\n> \n\nNot so taboo. Especially not if there are compelling technical reasons\nnot to add stuff to an existing one.\n\n> I'm attempting to integrate my test into t3404, which is the existing\n> interactive rebase test. The two test_expect_success's I added worked\n> when I ran them at the start of the test and then reset --hard the\n> branches back for the other tests, but if I paste my tests where they\n> should probably be, in the middle after the other -p tests, they break\n> because the 10 or tests before this have screwed with the DAG already.\n> \n\nWhere you add the tests doesn't matter much. Many tests are grouped by\nfeature simply because they were added along with the feature they're\ntesting. There's no other value of grouping tests together.\n\n> I can suffer through getting it to work, but a t3409 would be much\n> easier, and probably easier to read as well as a I could setup my own\n> DAG instead of hacking onto 3404s.\n> \n\nt3409 is already in spearce.git's next branch. You should be able to\nadd stuff to that, or add t3410 if that doesn't work so good.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}