On 28 July 2016 at 18:37, Junio C Hamano [off-list ref] wrote:
Øyvind A. Holm [off-list ref] writes:
quoted
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.
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.
Øyvind
W dniu 2016-07-28 o 18:56, Øyvind A. Holm pisze:
On 28 July 2016 at 18:37, Junio C Hamano [off-list ref] wrote:
quoted
Øyvind A. Holm [off-list ref] writes:
quoted
quoted
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.
On 28 July 2016 at 21:31, Jakub Narębski [off-list ref] wrote:
W dniu 2016-07-28 o 18:56, Øyvind A. Holm pisze:
quoted
Øyvind A. Holm [off-list ref] writes:
quoted
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:
[...]
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.
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.
That's an interesting idea. Have to test it out. This is the result from
the current master in linux.git:
With clone:
$ time git testadd pwd
git-testadd: Using ".testadd.tmp" as destination directory
Cloning into '.testadd.tmp'...
done.
Checking out files: 100% (55256/55256), done.
git-testadd: Applying staged changes
git-testadd: Executing "pwd" in /home/sunny/src/test-wt/.testadd.tmp
/home/sunny/src/test-wt/.testadd.tmp
real 0m10.464s
user 0m5.983s
sys 0m2.790s
$
With worktree:
$ time git worktree add testaddtmp
Preparing testaddtmp (identifier testaddtmp)
Checking out files: 100% (55256/55256), done.
HEAD is now at 194dc87 Add braces to avoid "ambiguous ‘else’" compiler
warnings
real 0m10.343s
user 0m6.010s
sys 0m2.523s
$
Both tests were run with cold cache ("echo 3 >/proc/sys/vm/drop_caches"
as root). It seems as there's no difference, and that git clone is as
fast as it can get without breaking physical laws. And we probably
shouldn't do that. :)
Z poważaniem,
Øyvind