Jeff King <peff@xxxxxxxx> writes: > On Thu, Dec 18, 2008 at 02:48:39PM +0100, Johannes Schindelin wrote: > >> Yes, it is a neat idea. But I always keep in mind what Junio had to say >> about my "add -e" thing (that I use pretty frequently myself): you will >> put something into the index that has _never_ been tested. >> >> Would we really want to bless such a workflow with "official" support? Back in stone ages of git, there wasn't usable tool support to make random unproven commits, later to be tested separately before releasing. The old aversion to committing something that has never existed as a whole in the work tree comes from those days. The world has changed quite a bit since then, and I do not think the argument holds anymore when better tool support for "commit first, validate and fix-up as needed later" workflow is available. > That is definitely something to be concerned about. Which is why my > workflow is something like: > > $ hack hack hack > $ while ! git diff; do > git add -p > git commit > done > $ for i in `git rev-list origin..`; do > git checkout $i && make test || barf > done > > That is, it is not inherently a problem to put something untested into > the index as long as you are doing it so that you can go back and test > later. Yeah, I do not think there is anything inherently wrong about it, either. -- 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
