Paul Tan <pyokagan@xxxxxxxxx> writes: > Hi, > > On Fri, May 8, 2015 at 1:24 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Paul Tan <pyokagan@xxxxxxxxx> writes: >> If 'git pull' gets broken, it will break this test _anyway_. > > You have a point, perhaps this should be changed to git-fetch + git-merge? > > Well my reasoning is that it's because git-pull --rebase requires more > code to be implemented than git-pull. So I'm thinking that git-pull > --rebase is more likely to break than git-pull. > >> Unless >> the operating assumption is "it is OK to break 'git pull --rebase', >> as long as we do not break 'git pull', while rewriting it", I am not >> sure the value of the change in this patch. We'd need to keep both >> form working, no? > > Yes, ultimately the git-pull rewrite must re-implement everything, but > if this test suite is affected by any git-pull (--rebase) breakage, > then there will be lots of patch noise as this test suite's tests get > disabled/re-enabled in the git-pull rewrite patches. > > But if the patch noise is okay, then I'm fine with dropping this patch > and 07/12. I am not sure what you mean by "patch noise". I do not think touching this test which does not have anything to do with "git pull" in your series is sensible at all, and you shouldn't flip test_expect_success temporarily to _expect_failure, if that is what you have in mind. Just don't run unrelated tests while your series is in flux. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html