Commit 82dce99 (attr: more matching optimizations from .gitignore -
2012-10-15) changed match_attr structure but it did not update
DEBUG_ATTR-specific code. This fixes it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: fix handling of file perms when pushing
Previously, when changing and committing an executable file, the file
would loose its executable bit on the hg side. Likewise, symlinks ended
up as "normal" files". This was not immediately apparent on the git side
unless one did a fresh clone.
Signed-off-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
Suggested-by: Max Horn <max@quendi.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests assume that this is set to something valid. Make sure
that the 'clone --use-client-spec' does not leak its changes
out into the rest of the tests.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git p4: fail gracefully on sync with no master branch
If --branch was used to build a repository with no
refs/remotes/p4/master, future syncs will not know
which branch to sync. Notice this situation and
print a helpful error message.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up. It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.
Putting it in heads seems like a bad default; these should
go in remotes/p4/ in most situations. Make that the new default,
and be more liberal in the form of the branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that the example on how to use git-p4.branchList
works if typed directly. In particular, it does not make sense
to set a config variable until the git repository has been
initialized.
Reported-by: Olivier Delalleau <shish@keba.be> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master. Both cases should
create a master branch and checkout files.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is code to create a symbolic reference from p4/HEAD to
p4/master. This allows saying "git show p4" as a shortcut
to "git show p4/master", for example.
But this reference was only created on the second "git p4 sync"
(or first sync after a clone). Make it work on the initial
clone or sync.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add failing tests to document behavior when there are multiple p4
branches, as created using the --branch option. In particular:
Using clone --branch populates the specified branch correctly, but
dies with an error when trying to checkout master.
Calling sync without a master branch dies with an error looking for
master. When there are two or more branches, a sync does
nothing due to branch detection code, but that is expected.
Using sync --branch to try to update just a particular branch
updates no branch, but appears to succeed.
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset [--mixed]: use diff-based reset whether or not pathspec was given
Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
2009-05-20), resetting with paths is much faster than resetting
without paths. Some timings for the linux-2.6 repo to illustrate this
(best of five, warm cache):
reset reset .
real 0m0.219s 0m0.080s
user 0m0.140s 0m0.040s
sys 0m0.070s 0m0.030s
These two commands should do the same thing, so instead of having the
user type the trailing " ." to get the faster do_diff_cache()-based
implementation, always use it when doing a mixed reset, with or
without paths (so "git reset $rev" would also be faster).
Timing "git reset" shows that it indeed becomes as fast as
"git reset ." after this patch.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users seem to think, knowingly or not, that being on an unborn
branch is like having a commit with an empty tree checked out, but
when run on an unborn branch, "git reset" currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Instead of making users figure out that they should run
git rm --cached -r .
, let's teach "git reset" without a revision argument, when on an
unborn branch, to behave as if the user asked to reset to an empty
tree. Don't take the analogy with an empty commit too far, though, but
still disallow explictly referring to HEAD in "git reset HEAD".
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset $sha1 $pathspec: require $sha1 only to be treeish
Resetting with paths does not update HEAD and there is nothing else
that a commit should be needed for. Relax the argument parsing so only
a tree is required.
The sha1 is only passed to read_from_tree(), which already only
requires a tree.
The "rev" variable we pass to run_add_interactive() will resolve to a
tree. This is fine since interactive_reset only needs the parameter to
be a treeish and doesn't use it for display purposes.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset.c: finish entire cmd_reset() whether or not pathspec is given
By not returning from inside the "if (pathspec)" block, we can let the
pathspec-aware and pathspec-less code share a bit more, making it
easier to make future changes that should affect both cases. This also
highlights the similarity between read_from_tree() and reset_index().
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When doing a mixed reset without paths, the index is locked, read,
reset, and written back as part of the actual reset operation (in
reset_index()). Then, when showing the list of worktree modifications,
we lock the index again, refresh it, and write it.
Change this so we only write the index once, making "git reset" a
little faster. It does mean that the index lock will be held a little
longer, but the difference is small compared to the time spent
refreshing the index.
There is one minor functional difference: We used to say "Could not
write new index file." if the first write failed, and "Could not
refresh index" if the second write failed. Now, we will only use the
first message.
This speeds up "git reset" a little on the linux-2.6 repo (best of
five, warm cache):
Before After
real 0m0.239s 0m0.214s
user 0m0.160s 0m0.130s
sys 0m0.070s 0m0.080s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset.c: move lock, write and commit out of update_index_refresh()
In preparation for the/a following patch, move the locking, writing
and committing of the index file out of update_index_refresh(). The
code duplication caused will soon be taken care of. What remains of
update_index_refresh() is just one line, but it is still called from
two places, so let's leave it for now.
In the process, we expose and fix the minor UI bug that makes us print
"Could not refresh index" when we fail to write the index file when
invoked with a pathspec. Copy the error message from the pathspec-less
codepath ("Could not write new index file.").
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
where read_from_tree() internally also calls
update_index_refresh(). Move the call to update_index_refresh() out of
read_from_tree for symmetry with the 'else' block, making
read_from_tree() and reset_index() closer in functionality.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The switch statement towards the end of reset.c is missing case arms
for KEEP and MERGE for no obvious reason, and soon the only non-empty
case arm will be the one for HARD. So let's proactively replace it by
if-else, which will let us move one if statement out without leaving
funny-looking left-overs.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If writing or committing the new index file fails, we print "Could not
write new index file." followed by "Could not reset index file to
revision $rev.". The first message seems to imply the second, so print
only the first message.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reset --keep" calls reset_index_file() twice, first doing a
two-way merge to the target revision, updating the index and worktree,
and then resetting the index. After each call, we write the index
file.
In the unlikely event that the second call to reset_index_file()
fails, the index will have been merged to the target revision, but
HEAD will not be updated, leaving the user with a dirty index.
By moving the locking, writing and committing out of
reset_index_file() and into the caller, we can avoid writing the index
twice, thereby making the sure we don't end up in the half-way reset
state. As a bonus, we speed up "git reset --keep" a little on the
linux-2.6 repo (best of five, warm cache):
Before After
real 0m0.315s 0m0.296s
user 0m0.290s 0m0.280s
sys 0m0.020s 0m0.010s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use a single condition to guard the call to die_if_unmerged_cache for
both --soft and --keep. This avoids the small distraction of the
precondition check from the logic following it.
Also change an instance of
if (e)
err = err || f();
to the almost as short, but clearer
if (e && !err)
err = f();
(which is equivalent since we only care whether exit code is 0)
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset.c: extract function for updating {ORIG_,}HEAD
By extracting the code for updating the HEAD and ORIG_HEAD symbolic
references to a separate function, we declutter cmd_reset() a bit and
we make it clear that e.g. the four variables {,sha1_}{,old_}orig are
only used by this code.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Throughout most of parse_args(), the variable 'i' remains at 0. Many
references are still made to the variable even when it could only have
the value 0. This made at least me, who has relatively little
experience with C programming styles, think that parts of the function
was meant to be part of a loop. To avoid such confusion, remove the
variable and also the 'argc' parameter and check for NULL trailing
argv instead.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset: don't allow "git reset -- $pathspec" in bare repo
Running e.g. "git reset ." in a bare repo results in an index file
being created from the HEAD commit. The differences compared to the
index are then printed as usual, but since there is no worktree, it
will appear as if all files are deleted. For example, in a bare clone
of git.git:
Unstaged changes after reset:
D .gitattributes
D .gitignore
D .mailmap
...
This happens because the check for is_bare_repository() happens after
we branch off into read_from_tree() to reset with paths. Fix by moving
the branching point after the check.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reset.c: pass pathspec around instead of (prefix, argv) pair
We use the path arguments in two places in reset.c: in
interactive_reset() and read_from_tree(). Both of these call
get_pathspec(), so we pass the (prefix, argv) pair to both
functions. Move the call to get_pathspec() out of these methods, for
two reasons: 1) One argument is simpler than two. 2) It lets us use
the (arguably clearer) "if (pathspec)" in place of "if (i < argc)".
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reset $pathspec" currently exits with a non-zero exit code if the
worktree is dirty after resetting, which is inconsistent with reset
without pathspec, and it makes it harder to know whether the command
really failed. Change it to exit with code 0 regardless of whether the
worktree is dirty so that non-zero indicates an error.
This makes the 4 "disambiguation" test cases in t7102 clearer since
they all used to "fail", 3 of which "failed" due to changes in the
work tree. Now only the ambiguous one fails.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 34110cd (Make 'unpack_trees()' have a separate source and
destination index, 2008-03-06), the index no longer gets clobbered by
do_diff_cache() and we can remove the code for discarding and
re-reading it.
There are two paths to update_index_refresh() from cmd_reset(), but on
both paths, either read_cache() or read_cache_unmerged() will have
been called, so the call to read_cache() in this method is redundant
(although practically free).
This speeds up "git reset -- ." a little on the linux-2.6 repo (best
of five, warm cache):
Before After
real 0m0.093s 0m0.080s
user 0m0.040s 0m0.020s
sys 0m0.050s 0m0.050s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
94bc671 (Add directory pattern matching to attributes - 2012-12-08)
uses find_basename() to calculate the length of directory part in
prepare_attr_stack. This function expects the directory without the
trailing slash (as "origin" field in match_attr struct is without the
trailing slash). find_basename() includes the trailing slash and
confuses push/pop algorithm.
Consider path = "abc/def" and the push down code:
while (1) {
len = strlen(attr_stack->origin);
if (dirlen <= len)
break;
cp = memchr(path + len + 1, '/', dirlen - len - 1);
if (!cp)
cp = path + dirlen;
dirlen is 4, not 3, without this patch. So when attr_stack->origin is
"abc", it'll miss the exit condition because 4 <= 3 is wrong. It'll
then try to push "abc/" down the attr stack (because "cp" would be
NULL). So we have both "abc" and "abc/" in the stack.
Next time when "abc/ghi" is checked, "abc/" is popped out because of
the off-by-one dirlen, only to be pushed back in again by the above
code. This repeats for all files in the same directory. Which means
at least one failed open syscall per file, or more if .gitattributes
exists.
Reported-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: use prefixcmp instead of memcmp on NUL-terminated strings
This conversion avoids the need for magic string length numbers in the
code. And unlike memcmp(), prefixcmp() is careful to not run over the
end of a string.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create find_hook() function to determine if a given hook exists and is
executable. If it is, the path to the script will be returned,
otherwise NULL is returned.
This encapsulates the tests that are used to check for the existence of
a hook in one place, making it easier to modify those checks if that is
found to be necessary. This also makes it simple for places that can
use a hook to check if a hook exists before doing, possibly lengthy,
setup work which would be pointless if no such hook is present.
The returned value is left as a static value from get_pathname() rather
than a duplicate because it is anticipated that the return value will
either be used as a boolean, immediately added to an argv_array list
which would result in it being duplicated at that point, or used to
actually run the command without much intervening work. Callers which
need to hold onto the returned value for a longer time are expected to
duplicate the return value themselves.
Signed-off-by: Aaron Schrab <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase --preserve-merges: keep all merge commits including empty ones
Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
'git rebase --preserve-merges' fails to preserve empty merge commits
unless --keep-empty is also specified. Merge commits should be
preserved in order to preserve the structure of the rebased graph,
even if the merge commit does not introduce changes to the parent.
Teach rebase not to drop merge commits only because they are empty.
A special case which is not handled by this change is for a merge commit
whose parents are now the same commit because all the previous different
parents have been dropped as a result of this rebase or some previous
operation.
Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
(1) Only print out the names of the files and directories that got
actually deleted. Also do not mention that we are not removing
directories when the user did not ask us to do so with '-d'.
(2) Show ignore message for skipped untracked git repositories.
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
to run in both dry_run and delete modes with the delete logic as
follows:
(a) Check if the current directory to be deleted is an untracked
git repository. If it is and --force --force option is not set
do not touch this directory, print ignore message, set dir_gone
flag to false for the caller and return.
(b) Otherwise for each item in current directory:
(i) If current directory cannot be accessed, print warning,
set dir_gone flag to false and return.
(ii) If the item is a subdirectory recurse into it,
check for the returned value of the dir_gone flag.
If the subdirectory is gone, add the name of the deleted
directory to a list of successfully removed items 'dels'.
Else set the dir_gone flag as the current directory
cannot be removed because we have at least one subdirectory
hanging around.
(iii) If it is a file try to remove it. If success add the
file name to the 'dels' list, else print error and set
dir_gone flag to false.
(c) After we finished deleting all items in the current directory and
the dir_gone flag is still true, remove the directory itself.
If failed set the dir_gone flag to false.
(d) If the current directory cannot be deleted because the dir_gone flag
has been set to false, print out all the successfully deleted items
for this directory from the 'dels' list.
(e) We're done with the current directory, return.
(2) Modify the cmd_clean() function to:
(a) call the recursive delete function 'remove_dirs()' for each
topmost directory it wants to remove
(b) check for the returned value of dir_gone flag. If it's true
print the name of the directory as being removed.
In the longer term, tightening rules is a good thing to do, and
because nobody who has worked in the remote helper area seems to be
interested in reviewing this, I would assume they do not think
such a retroactive tightening will affect their remote helpers. So
let's advance this topic to see what happens.
* fc/remote-testgit-feature-done:
remote-testgit: properly check for errors
When user spells "cc:" in lowercase in the fake "header" in the
trailer part, send-email failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* nz/send-email-headers-are-case-insensitive:
git-send-email: treat field names as case-insensitively
Merge branch 'jl/interrupt-clone-remove-separate-git-dir' into maint
When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created. This
was most visible when interrupting a submodule update.
* jl/interrupt-clone-remove-separate-git-dir:
clone: support atomic operation with --separate-git-dir
Merge branch 'jc/maint-fmt-merge-msg-no-edit-lose-credit' into maint
"git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* jc/maint-fmt-merge-msg-no-edit-lose-credit:
merge --no-edit: do not credit people involved in the side branch
The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
* pf/editor-ignore-sigint:
fix compilation with NO_PTHREADS
launch_editor: propagate signals from editor to git
run-command: do not warn about child death from terminal
launch_editor: ignore terminal signals while editor has control
launch_editor: refactor to use start/finish_command
run-command: drop silent_exec_failure arg from wait_or_whine
Improve compatibility of our zip output to fill uncompressed size
in the header, which we can do without seeking back (even though it
should not be necessary).
* rs/zip-with-uncompressed-size-in-the-header:
archive-zip: write uncompressed size into header even with streaming
Update zip tests to skip some that cannot be handled on platform
unzip.
* rs/zip-tests:
t5003: check if unzip supports symlinks
t5000, t5003: move ZIP tests into their own script
t0024, t5000: use test_lazy_prereq for UNZIP
t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
Update the disused merge-tree proof-of-concept code.
* jc/merge-blobs:
merge-tree: fix d/f conflicts
merge-tree: add comments to clarify what these functions are doing
merge-tree: lose unused "resolve_directories"
merge-tree: lose unused "flags" from merge_list
Which merge_file() function do you mean?
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
* jc/format-patch-reroll:
format-patch: give --reroll-count a short synonym -v
format-patch: document and test --reroll-count
format-patch: add --reroll-count=$N option
get_patch_filename(): split into two functions
get_patch_filename(): drop "just-numbers" hack
get_patch_filename(): simplify function signature
builtin/log.c: stop using global patch_suffix
builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
* jc/submittingpatches:
SubmittingPatches: give list and maintainer addresses
SubmittingPatches: remove overlong checklist
SubmittingPatches: mention subsystems with dedicated repositories
SubmittingPatches: who am I and who cares?
Merge branch 'os/gitweb-highlight-uncaptured' into maint
"gitweb", when sorting by age to show repositories with new
activities first, used to sort repositories with absolutely nothing
in it early, which was not very useful.
* os/gitweb-highlight-uncaptured:
gitweb: fix error in sanitize when highlight is enabled
Merge branch 'jn/warn-on-inaccessible-loosen' into maint
When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* jn/warn-on-inaccessible-loosen:
config: exit on error accessing any config file
doc: advertise GIT_CONFIG_NOSYSTEM
config: treat user and xdg config permission problems as errors
config, gitignore: failure to access with ENOTDIR is ok
"git fetch --mirror" and fetch that uses other forms of refspec with
wildcard used to attempt to update a symbolic ref that match the
wildcard on the receiving end, which made little sense (the real ref
that is pointed at by the symbolic ref would be updated anyway).
Symbolic refs no longer are affected by such a fetch.
* jc/fetch-ignore-symref:
fetch: ignore wildcarded refspecs that update local symbolic refs
The way "git svn" asked for password using SSH_ASKPASS and
GIT_ASKPASS was not in line with the rest of the system.
* ss/svn-prompt:
git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not set
git-svn, perl/Git.pm: add central method for prompting passwords
The --separate-git-dir option was introduced to make it simple to put
the git directory somewhere outside the worktree, for example when
cloning a repository for use as a submodule.
It was not intended for use when creating a bare repository. In that
case there is no worktree and it is more natural to directly clone the
repository and create a .git file as separate steps:
contrib/vim: simplify instructions for old vim support
Rely on the upstream filetype.vim instead of duplicating its rules in
git's instructions for syntax highlighting support on pre-7.2 vim
versions.
The result is a shorter contrib/vim/README. More importantly, it lets
us punt on maintenance of the autocmd rules.
So now when we fix the upstream gitsendemail rule in light of commit eed6ca7, new git users stuck on old vim reading contrib/vim/README can
automagically get the fix without any further changes needed to git.
Once the world has moved on to vim 7.2+ completely, we can get rid of
these instructions, but for now if they are this simple it's
effortless to keep them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brace expansion is a shell feature that's not required by POSIX and not
supported by dash nor NetBSD's sh. Explicitly list all combinations
instead. Also avoid calling touch by creating the test files with a
redirection instead, as suggested by Junio.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
However, next time make is run with a different value in PYTHON_PATH,
we failed to regenerate these scripts.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>