On Sat, Nov 10, 2012 at 1:33 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote: > >> > * fc/fast-export-fixes (2012-11-08) 14 commits >> > - fast-export: don't handle uninteresting refs >> > - fast-export: make sure updated refs get updated >> > - fast-export: fix comparison in tests >> > - fast-export: trivial cleanup >> > - remote-testgit: make clear the 'done' feature >> > - remote-testgit: report success after an import >> > - remote-testgit: exercise more features >> > - remote-testgit: cleanup tests >> > - remote-testgit: remove irrelevant test >> > - remote-testgit: get rid of non-local functionality >> > - Add new simplified git-remote-testgit >> > - Rename git-remote-testgit to git-remote-testpy >> > - remote-testgit: fix direction of marks >> > - fast-export: avoid importing blob marks >> > >> > Improvements to fix fast-export bugs, including how refs pointing to >> > already-seen commits are handled. An earlier 4-commit version of this >> > series looked good to me, but this much-expanded version has not seen >> > any comments. >> > >> > Needs review. >> >> I can send the previous 4-commit version if needed, the only thing >> that changed is the commit messages. > > In the actual code, perhaps, but aren't there significant changes to the > git-remote-testgit infrastructure that were not originally present? That > could use some review. > > I also seem to recall that the tests in this version rely on the presence of bash; > don't we still need to mark the tests with a prerequisite? I meant in the 4-commits. >> > * fc/completion-test-simplification (2012-10-29) 2 commits >> > - completion: simplify __gitcomp test helper >> > - completion: refactor __gitcomp related tests >> > >> > Clean up completion tests. >> > >> > There were some comments on the list. >> > >> > Expecting a re-roll. >> >> The second patch I can re-roll, but the first patch needs some >> external input. My preference is that tests should also be simple and >> maintainable, SZEDER's preference is that tests are better being >> explicit and verbose (even if harder to maintain) to minimize possible >> issues in the tests. > > I think it is better to keep the tests simple and maintainable. If there > are multiple ways to do things and they all need testing, then that > should be clear from the tests, not done haphazardly because some tests > happen to use a different way of doing things. Good, that's what my first patch does; no functional changes, just refactor code into a single function. > I seem to recall there was a one-liner fix that needed to be rolled in, > which is why I held it out of next. Yes, that I can reroll. Cheers. -- Felipe Contreras -- 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