Case-insensitive filename handling in Mercurial - windows

I'm using TortoiseHg 0.5 (which includes Mercurial 1.0.2) on Vista64. My understanding from the Mercurial Book is that Mercurial should handle filenames in a case-insensitive manner on a case-insensitive filesystem (such as NTFS, which is what I'm on). However I find that my installation of Mercurial is in fact sensitive to case:
>hg status -A foo
C foo
>hg status -A FOO
? FOO
Could this be a bug in Mercurial, a bug in the TortoiseHg build of Mercurial, or is it something else? How can I achieve case-insensitive filename handling from Mercurial on Windows?

This issue has been resolved in Mercurial 1.1! From the release notes: "Improved correctness in the face of casefolding filesystems".
On Windows, Mercurial now ignores case in its command line arguments:
>hg status -A foo
C foo
>hg status -A FOO
C foo
And it also is aware that filename changes that only involve case are not new files:
>ren foo FOO
>hg status -A fOO
C foo
Thus there's no longer any risk of overlooking changes due to mistypes on the command line.
However, be aware that the contents of the .hgignore file remain case sensitive. This is an issue only if you're using glob syntax; with regexp syntax you can put (?i) at the beginning of patterns to make them insensitive.

I think you misread the hgbook. The intro to section 7.7 is just describing the three different types of case sensitivity that exist in OSs, not saying that mercurial will mirror those semantics.
Later in section 7.7.2 'Detecting case conflicts' it says:
When operating in the working
directory, Mercurial honours the
naming policy of the filesystem where
the working directory is located. If
the filesystem is case preserving, but
insensitive, Mercurial will treat
names that differ only in case as the
same.
When you do hg status -A FOO the process that's happening within mercurial is:
Check if a file exists on the file system matching the file argument, 'FOO', -- and at this point it's being case insensitive so it finds 'foo' and says "yup, I've got a file"
Check if there's an entry in the file manifest matching the file argument, 'FOO', and there isn't, so status shows a '?' saying it's a file on disk that hg isn't tracking
To better see mercurial not caring about case on NTFS try these steps:
hg init
echo line > Foo
hg add Foo
hg commit -m 'committed Foo'
move Foo not-foo
move not-foo FOO
hg status
and you should see hg saying that nothing has changed because the only thing that has changed is the case which hg is ignoring for you.
When I do the same thing on linux I instead see:
! Foo
? FOO

Related

Implement git branch --contains with rugged library

I'm working with a ruby script that execute the following git command on a given git repository.
branches = `git branch -a --contains #{tag_name}`
This approach has some drawbacks with command output (that may change in different git versions) and is subject to git binary version on the hosting machine, so I was trying to see if it's possible to replace that command using rugged but I wasn't able to find anything similar to that.
Maybe in rugged there's no way to implement --contains flag, but I think it should be pretty easy to implement this behavior:
Given any git commit-ish (a tag, a commit sha, etc.) how to get (with rugged) the list of branches (both local and remote) that contains that commit-ish?
I need to implement something like github commit show page, i.e. tag xyz is contained in master, develop, branch_xx
Finally solved with this code:
def branches_for_tag(tag_name, repo_path = Dir.pwd)
#branches ||= begin
repo = Rugged::Repository.new(repo_path)
# Convert tag to sha1 if matching tag found
full_sha = repo.tags[tag_name] ? repo.tags[tag_name].target_id : tag_name
logger.debug "Inspecting repo at #{repo.path}, branches are #{repo.branches.map(&:name)}"
# descendant_of? does not return true for it self, i.e. repo.descendant_of?(x, x) will return false for every commit
# #see https://github.com/libgit2/libgit2/pull/4362
repo.branches.select { |branch| repo.descendant_of?(branch.target_id, full_sha) || full_sha == branch.target_id }
end
end

bash completion random characters

I am having trouble with bash_completion. When I expand variables, I am fine, but when I use a commands completion (such as git or vim-addon-manager), then the completion throws random characters in there. This didn't use to happen to me, I can't figure out what it is.
This is an example of what happens when I type gitTabTaby
[11:11] me#my_computer:~ $ git
Display all 131 possibilities? (y or n)
^[[01;31m^[[K c^[[m^[[Kheckout delete-tag f^[[m^[[Kmt-merge-msg i^[[m^[[Knit-db notes rm
a^[[m^[[Kdd c^[[m^[[Kheckout-index d^[[m^[[Kaemon f^[[m^[[Kor-each-ref i^[[m^[[Knstaweb obliterate setup
a^[[m^[[Klias c^[[m^[[Kheck-ref-format d^[[m^[[Kelete-branch f^[[m^[[Kormat-patch info p4 shortlog
a^[[m^[[Km c^[[m^[[Kherry d^[[m^[[Kelete-merged-branches f^[[m^[[Ksck line-summary pull show
a^[[m^[[Knnotate c^[[m^[[Kherry-pick d^[[m^[[Kelete-submodule f^[[m^[[Ksck-objects l^[[m^[[Kog pull-request show-branch
a^[[m^[[Kpply c^[[m^[[Klean d^[[m^[[Kescribe fresh-branch l^[[m^[[Ks-files push show-tree
a^[[m^[[Krchive c^[[m^[[Klone d^[[m^[[Kiff g^[[m^[[Kc l^[[m^[[Ks-remote rebase squash
a^[[m^[[Krchive-file c^[[m^[[Kolumn d^[[m^[[Kiff-files g^[[m^[[Ket-tar-commit-id l^[[m^[[Ks-tree refactor stage
b^[[m^[[Kack c^[[m^[[Kommit d^[[m^[[Kiff-index g^[[m^[[Krep local-commits reflog stash
b^[[m^[[Kisect c^[[m^[[Kommits-since d^[[m^[[Kifftool graft mergetool release status
b^[[m^[[Klame c^[[m^[[Kommit-tree d^[[m^[[Kiff-tree h^[[m^[[Kash-object m^[[m^[[Kailinfo relink submodule
b^[[m^[[Kranch c^[[m^[[Konfig effort h^[[m^[[Kelp m^[[m^[[Kailsplit remote subtree
b^[[m^[[Kug c^[[m^[[Kontrib extras h^[[m^[[Kttp-backend m^[[m^[[Kerge rename-tag summary
b^[[m^[[Kundle c^[[m^[[Kount feature h^[[m^[[Kttp-fetch m^[[m^[[Kerge-base repack tag
c^[[m^[[Kat-file c^[[m^[[Kount-objects f^[[m^[[Kast-export h^[[m^[[Kttp-push m^[[m^[[Kerge-file repl touch
c^[[m^[[Khangelog c^[[m^[[Kreate-branch f^[[m^[[Kast-import ignore m^[[m^[[Kerge-index replace undo
c^[[m^[[Kheck-attr c^[[m^[[Kredential f^[[m^[[Ketch i^[[m^[[Kmap-send m^[[m^[[Kerge-octopus request-pull whatchanged
c^[[m^[[Kheck-ignore c^[[m^[[Kredential-cache f^[[m^[[Ketch-pack i^[[m^[[Kndex-pack mv reset
c^[[m^[[Kheck-mailmap c^[[m^[[Kredential-store f^[[m^[[Kilter-branch i^[[m^[[Knit name-rev revert
Another example is vam tetris (vam tetTabTab):
^[[01;31m^[[Kaddon: tet^[[m^[[Kris
For vam install tetTabTab, it actually renders it an invalid argument (it's also quite difficult to read), so how can I fix this?
I was experiencing the same problem and saw your answer and changed:
export GREP_OPTIONS='--color=always' to export GREP_OPTIONS='--color=auto'This seems to have fixed the problem with bash-completion on my Mac.
Apparently, bash completions don't like when grep is colored. Anything like
alias grep='grep --color=always'
alias fgrep='fgrep --color=always'
alias egrep='egrep --color=always'
will give you problems.
Therefore, as Garrett Bellomy details below, it may be wise to use --color=auto, which can be achieved by setting GREP_OPTIONS (or by aliasing grep in your rc file). If you want to make this a global variable, add this to ~/.bash_profile (for bash) or ~/.zprofile (zsh) depending on your default shell: export GREP_OPTIONS='--color=auto'

Python: Check if a directory is an alias

Does python have a simple function for checking if a directory is an actual directory or if it's just an alias to another directory? I'm trying to list all files/folders in a directory but because of these alias folders, I'm getting a lost of stuff that looks like this:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle/Home/bundle
I know I can write a function that will compare paths and quit if it seems like I'm going in circles, but is there a simple function that does exactly that that I'm not aware of?
E.g.
os.isAlias( …pathname… )
Thanks!
Here's a version of os.path.realpath that works on Mac aliases as well as on symbolic links under Python 2:
from Carbon import File
def osx_realpath (path):
return File.FSResolveAliasFile(path, True)[0].as_pathname()
If you call osx_realpath on each directory before you recurse into it you should avoid duplication. Alternatively you could define something like
def is_osx_realpath (path):
return path == osx_realpath(path)
Here you have to worry a little about false negatives, however. If you filter for is_osx_realpath and the path you start with is an alias, your program will stop without looking at anything.
So far I don't know of a way to do this under Python 3. I have a question here where I'm hoping for an answer. Right now I can't do better than using subprocess.call to invoke something that does the check on the command line.
EDIT: I should add that not only is Carbon.File not available in Python 3, but it is deprecated and so is best avoided in Python 2 as well--however it's the most pragmatic solution I know of for Python 2 at present.
EDIT 2: here is a way to check if a file is an alias that I believe to be Python 3-friendly. However, I don't have code to resolve the alias. I believe you need PyObjC installed.
from AppKit import NSWorkspace
def is_alias (path):
uti, err = NSWorkspace.sharedWorkspace().typeOfFile_error_(
os.path.realpath(path), None)
if err:
raise Exception(unicode(err))
else:
return "com.apple.alias-file" == uti
(source)
The answer above is incorrect.
While it is true that Finder reports symlinks as alias, they are distinct things.
Symlinks are a basic feature of UNIX, but alias are a Apple only feature.
If you doubt this create a symlink to a directory and an alias. The symlink will be small typically 50-100 bytes, whereas the alias can be several MB.
os.path.islink( … ) will report symlinks, but not alias.
I am not sure how you would find them in Python, but the following link shows other methods.
https://stackoverflow.com/a/21151368/838253
You can check whether a file or directory is an alias with the GetFileInfo command in Mac OS X. GetFileInfo -aa foo prints a line with "1" if foo is an alias and "0" if not.
import subprocess
def is_alias(path):
return subprocess.check_output(["GetFileInfo", "-aa", path]) == "1\n"
Seems a little sad to spawn a process for every check, but I think this works with versions of Mac OS X since probably 10.4.4 (2006), 32-bit, 64-bit, Python 2 and Python 3. The version of GetFileInfo I have (from 2009) is a "universal" i386 + PPC binary.
GetFileInfo is part of Xcode, which is large, but you can download the command-line tools separately (see the "Separate Download" section here).
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/GetFileInfo.1.html
Old question, but I just ran into this myself.
I have no perfect method for checking if the file is an alias, however, if using mimetypes, python will return None for an alias or a symlink. Might be useful in some situations. I've only tested this in python 3.8 on macOS Big Sur.
import mimetypes
for idx, f in enumerate(filepaths):
type = mimetypes.guess_type(f)[0]
print(f"type is: {type}")
returns (without my added comments):
type is: None # <-- Folder Alias
type is: None # <-- File Alias
type is: text/x-python
type is: None # <-- Folder Alias
type is: video/mp4
type is: image/png
type is: None # <-- Folder Alias
type is: None # <-- Symlink
type is: image/png
type is: application/zip
type is: image/png
type is: image/jpeg
type is: None # <-- Symlink
I ran some files through exiftool just to see what types they returned, and aliases and symlinks both showed the following:
File Type : ALIAS
File Type Extension : alias
MIME Type : application/x-macos
You might be able to init the mimetypes for these, but haven't tested and not sure if it will give false positives if anything else shows up as application/x-macos

buildroot - how to change kernel version string

I work on SAM9G25 EK board with buildroot and Armstrong linux (Linux4sam).
My script is creating linux version "2.6.39+" and this "+" is confusing (/lib/modules folder etc.). I want to remove it. I found only two files .uImage.cmd, and kernel.release that contains this string, but both are generated.
Where is this string created ?
You have a .config? Look in there for the value assigned to CONFIG_LOCALVERSION.
To have no local version specifed in the kernel's release, either remove CONFIG_LOCALVERSION or comment it out by starting the line containing it by a #.
The default shall be:
#CONFIG_LOCALVERSION is not set
In this case the main reason was :
scripts/setlocalversion line >170:
# append a plus sign if the repository is not in a clean
# annotated or signed tagged state (as git describe only
# looks at signed or annotated tags - git tag -a/-s) and
# LOCALVERSION= is not specified
if test "${LOCALVERSION+set}" != "set"; then
scm=$(scm_version --short)
res="$res${scm:++}"
fi
I commented this part out.

get the latest commit where a file changed

My task at hand is to figure out, what is the commit id of the last commit, where a specific file changed. I'm using ruby / rugged. The only solution I came up with is to walk over all commits, search for the file in the tree associated with the commit for that file and compare that files oid with the oid of the file from the first (latest) commit:
def commit_oid commit, file
commit.tree.walk( :postorder ) { | root, obj |
return obj[ :oid ] if "#{root}#{obj[ :name ]}" == file
}
raise "\'#{file}\' not found in repository"
end
def find_last_commit file
johnny = Rugged::Walker.new( get_repository )
johnny.push get_repository.head.target
oid = commit_oid johnny.first, file
old_commit = johnny.first.oid
johnny.each do | commit |
new_oid = commit_oid commit, file
return old_commit if new_oid != oid
old_commit = commit.oid
end
old_commit
end
This works but seems to be quit complicated. There must be an easier ways to get the information, "what changed with a commit". Is there an easier, more straight forward way to accomplish the same?
Running $ git log <file> will give you a reverse chronological log of only commits that altered the given file. $ git whatchanged <file> will do the same, adding a line with details of the change (i.e. mode change, change type). It's great for visual purposes, but not so much for scripting.
If you want just the hash of the most recent commit, the following will work well: $ git rev-list --max-count 1 HEAD <file>

Resources