Sponsored Content
Full Discussion: Safe place for download
Top Forums UNIX for Dummies Questions & Answers Safe place for download Post 302924795 by DGPickett on Wednesday 12th of November 2014 12:00:24 PM
Old 11-12-2014
I run Ubuntu 14.04 LTS, and it was upgraded for me by the Software Updater. I have K'ish XWindows. Am I missing anything like G'ish XWindows or ??? Smilie
 

2 More Discussions You Might Find Interesting

1. Solaris

Async-Signal-Safe versus MT-Safe

Hi, I am Solaris 9 developer and notice that the documentation does not provide a clear notion of the inherent concurrency in routines defined as "Async-Signal-Safe". Routines defined as "MT-Safe" obviously have the best level of concurrency, compared to normal "Safe" interfaces. I have... (1 Reply)
Discussion started by: tristan12
1 Replies

2. Solaris

What is the best way to copy data from place to another place?

Dear Gurus, I need you to advice or suggestion about the best solution to copy data around 200-300G from serverA(location A) to serverB(location B). Normally, I will share folder and then copy but it takes too long time(about 2 days). Do you have any suggestion or which way should be... (9 Replies)
Discussion started by: unitipon
9 Replies
GIT-LS-TREE(1)							    Git Manual							    GIT-LS-TREE(1)

NAME
git-ls-tree - List the contents of a tree object SYNOPSIS
git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [<path>...] DESCRIPTION
Lists the contents of a given tree object, like what "/bin/ls -a" does in the current working directory. Note that: o the behaviour is slightly different from that of "/bin/ls" in that the <path> denotes just a list of patterns to match, e.g. so specifying directory name (without -r) will behave differently, and order of the arguments does not matter. o the behaviour is similar to that of "/bin/ls" in that the <path> is taken as relative to the current working directory. E.g. when you are in a directory sub that has a directory dir, you can run git ls-tree -r HEAD dir to list the contents of the tree (that is sub/dir in HEAD). You don't want to give a tree that is not at the root level (e.g. git ls-tree -r HEAD:sub dir) in this case, as that would result in asking for sub/sub/dir in the HEAD commit. However, the current working directory can be ignored by passing --full-tree option. OPTIONS
<tree-ish> Id of a tree-ish. -d Show only the named tree entry itself, not its children. -r Recurse into sub-trees. -t Show tree entries even when going to recurse them. Has no effect if -r was not passed. -d implies -t. -l, --long Show object size of blob (file) entries. -z line termination on output. --name-only, --name-status List only filenames (instead of the "long" output), one per line. --abbrev[=<n>] Instead of showing the full 40-byte hexadecimal object lines, show only a partial prefix. Non default number of digits can be specified with --abbrev=<n>. --full-name Instead of showing the path names relative to the current working directory, show the full path names. --full-tree Do not limit the listing to the current working directory. Implies --full-name. [<path>...] When paths are given, show them (note that this isn't really raw pathnames, but rather a list of patterns to match). Otherwise implicitly uses the root level of the tree as the sole path argument. OUTPUT FORMAT
<mode> SP <type> SP <object> TAB <file> Unless the -z option is used, TAB, LF, and backslash characters in pathnames are represented as , , and \, respectively. This output format is compatible with what --index-info --stdin of git update-index expects. When the -l option is used, format changes to <mode> SP <type> SP <object> SP <object size> TAB <file> Object size identified by <object> is given in bytes, and right-justified with minimum width of 7 characters. Object size is given only for blobs (file) entries; for other entries - character is used in place of size. GIT
Part of the git(1) suite Git 1.8.3.1 06/10/2014 GIT-LS-TREE(1)
All times are GMT -4. The time now is 07:27 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy