This is another preparation patch for the transition to Python 3.x,
where the input first needs to be encoded before it is passed to
the git command to be executed.
Change-Id: I2d8aac02a17b5d5765ab5e2c357bc15ead4f2c64
TN: U530-006
This commit is preparation work for the transition to Python 3.x,
where the output obtained by running Git commands will become
bytes as opposed to a string. In the vast majority of cases,
we'll want to decode that output into a string. Ideally, we would
want to do this in a way that is both compatible with Python 2.x
and Python 3.x, but we have found that this requires a lot of
work with many changes spread all over the code. So, instead,
what this commit does is introduce the concept of decoding
the output, but with the decoding only occurring when running
under Python 3.x.
That way, we can make progress towards Python 3.x while preserving
the behavior under Python 2.x intact.
Change-Id: I189577798ee96cba1fa55c7356babf102575642f
TN: U530-006
A recent change in this function sometimes causes a crash when
pushing a commit. This happens in a situation such as the following:
The user has a repository that looks like this:
<root>/
subdir/
.gitattributes
sub_sub_dir/
.gitattributes
some_file
If the user creates a commit which modifies some_file, the git_attribute
function will be passed a list of files which includes:
subdir/sub_sub_dir/some_file
It will process that file by first looking at subdir/sub_sub_dir,
check if there is a .gitattributes in it (yes), so create that
directory, add it to the dirs_with_changes "list" so we know
we've already processed that directory. So far, so good.
Loop again, this time with os.path.dirname('subdir/sub_sub_dir'),
thus with 'subdir'. Is that directory in dirs_with_changes? No.
Does it have a .gitattribute in it? Yes. So, rince-repeat, which
means first creating the subdir. That leads to the crash, since
we already just created it as a side-effect of creating its subdir.
This patch fixes the issue by simply remembering when a directory
has been created for a given file in filename_list. Once that's
done, we know that the next iterations on the dir_path loop are
necessarily for parent directories, which have therefore been
created, even if they are not listed in the dirs_with_changes
"list" yet.
Another possible fix, which would be safer, would be to just
check the filesystem directly. But this code can be a hot-spot
in terms of performance, so we'll try really hard to avoid it.
Fixes P601-011.
Related to P531-036.
For a commit for which there are 4,500 files being modified and
for which all files have the no-precommit-check attribute set,
this reduces the amount of time it takes for the update hook
to process that commit from 20-25 seconds down to less than a second.
For P531-036.
The comment I added in function git_attributes to explain why we may
have to create the "info/" directory was not quite correct. This
patch improves it, now that we have a little more info about the
source of the condition (most likely differences in git versions).
Part of MC16-012.
This is another attempt at fixing the error raised when trying
to overwrite the info/attributes file when this file was left
by another user during the previous update.
For M116-004.
It turns out that making info/attributes group-writable is not
sufficient: A second user is allowed to overwrite the file, but
then the hooks fail when trying to change the file permissions
to make it group-writable.
We will use a different approach which should not need this anymore.
Part of M116-004.
A user needs to be able to overwrite this file, so we make it
group-writable.
Update the testsuite to verify this requirement for both
a repository's .gitattribute file, as well as the bare
repository's default_attribute file.
Experience shows that this is a very repetive operations, involving
multiple calls for each file being changed (the number of calls
per file being changed is equal to the depth of the file, in terms
of number of sub-directories). Caching it this way has been measured
to reduce the amount of time spent by about 10% for small commits
in the GDB repository (12 files changed). For commits involving
a larger number of files (3717), it improves performance by about 60%!
