W dniu 2016-07-28 o 18:56, Øyvind A. Holm pisze: > On 28 July 2016 at 18:37, Junio C Hamano <gits...@pobox.com> wrote: >> Øyvind A. Holm <su...@sunbase.org> writes:
>>> This is a script I created some weeks ago, and I've found it to be >>> immensely useful. Here is a snippet from git-testadd --help: >>> >>> If you have lots of unrelated uncommitted changes in the current >>> repository and want to split up the commit, how can you easily >>> check if the changes passes the test suite? With all the other >>> unrelated changes it can be hard to make sure that only relevant >>> changes becomes part of the commit, and that they don't result in >>> regressions. This script clones the repository to the directory >>> ".testadd.tmp" in the current directory and applies the staged >>> chenges there (unless -u/--unmodified or -p/--pristine is >>> specified), chdirs to the same relative directory in the clone and >>> executes the command specified on the command line there. >> >> So in short, this solves the same problem as "git stash --keep" but in >> a more scalable way, in the sense that "git stash --keep" allows you >> to instantiate what you have in the index so that your working tree >> can be used for such a test, but you cannot do anything else while you >> are waiting for the test to finish, and "testadd" allows you to keep >> hacking in the working tree while a test runs in its own temporary >> checkout (and presumably you can have more than one running, which >> would allow you to scale more)? > > That's correct, the test clone is entirely separated from the working > copy, and you can keep working while the tests are running in the clone. > Combined with git-gui and/or "git add -p/git reset -p", it's easy to > tweak the staged changes until things are ok. I wonder if using `git worktree` instead of `git clone` (well, local clone uses hardlinks, so it is not that costly as it looks like) would be a better solution. > Also, there is a -l/--label option that creates a clone directory with > the name ".testadd-[LABEL].tmp", so you can have several test clones at > the same time, all with different staged changes. There is also a > -r/--ref option that tries to apply the staged changes onto another > commit, and the command will only run if the apply succeeds. Also, this > won't create dangling heads like "git stash --keep" does. Nice. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
