On 2/2/14, Reuben Hawkins wrote:
>>
> This is a separate issue which core.ignorecase is sweeping under the rug.
> When you get this error message, do an 'ls' and you'll see there isn't an
> untracked file called 'FileName.txt'. There is, however, a tracked file
> called 'Filename.txt'. Because
On Sun, Feb 2, 2014 at 9:19 AM, Duy Nguyen wrote:
>> + /* check whole path */
>> + if (strcmp(real_path(path0), work_tree) == 0) {
>> + *path0 = '\0';
>> + return 0;
>> + }
>
> I think this is already handled by the "check if work tree is already
> the
On Sun, Feb 2, 2014 at 8:59 AM, Martin Erik Werner
wrote:
> + /* check if work tree is already the prefix */
> + if (strncmp(path, work_tree, wtlen) == 0) {
> + if (path[wtlen] == '/')
> + memmove(path, path + wtlen + 1, len - wtlen);
> +
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which first checks if the
work tree is already the pref
The 'prefix_path_gently' function currently applies real_path to
everything if given an absolute path, dereferencing symlinks both
outside and inside the work tree. In order to manipulate symlinks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
Mo
The current behaviour of prefix_path is to return an empty string if
prefixing and absolute path that only contains exactly the work tree.
This behaviour is a potential regression point.
Signed-off-by: Martin Erik Werner
---
t/t0060-path-utils.sh | 6 ++
1 file changed, 6 insertions(+)
diff
Hmm, maybe fourth time's the ch...nevermind.
On Sat, Feb 01, 2014 at 02:31:21AM +0100, Martin Erik Werner wrote:
> On Fri, Jan 31, 2014 at 11:37:29PM +0100, Torsten Bögershausen wrote:
> > On 2014-01-31 21.22, Martin Erik Werner wrote:
(...)
> > > diff --git a/cache.h b/cache.h
> > > index ce377e1
When symlinks in the working tree are manipulated using the absolute
path, git dereferences them, and tries to manipulate the link target
instead.
This is a regression introduced by 18e051a:
setup: translate symlinks in filename when using absolute paths
(which did not take symlinks in the work
On Sat, Feb 1, 2014 at 1:14 PM, Reuben Hawkins wrote:
> Most case-insensitive filesystems are case-preserving. In these
> filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
> then rename the file to FileName.txt. That file will be accessible
> by both filenames, but the case is
On 2014-02-01 10.14, Reuben Hawkins wrote:
> Most case-insensitive filesystems are case-preserving. In these
> filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
> then rename the file to FileName.txt. That file will be accessible
> by both filenames, but the case is otherwise ho
I usually start splitting a commit with "reset @^" then "add -p" back.
The problem is "reset @^" does not keep track of new files added in
HEAD, so I often end up forgetting to add new files back (with "add
-p"). I'm thinking of making "reset" to do "add -N" automatically for
me so I won't miss cha
Most case-insensitive filesystems are case-preserving. In these
filesystems (such as HFS+ on OS X) you can name a file Filename.txt,
then rename the file to FileName.txt. That file will be accessible
by both filenames, but the case is otherwise honored. We don't want
to have git ignore case on th
create_default_files was getting a bit long and indented. This
particular bit of code got long enough to be its own function.
Signed-off-by: Reuben Hawkins
---
builtin/init-db.c | 97 +
1 file changed, 53 insertions(+), 44 deletions(-)
diff
13 matches
Mail list logo
