* Re: Problem with git ls-files
From: Imran M Yousuf @ 2008-01-07 4:48 UTC (permalink / raw)
To: git
In-Reply-To: <7bfdc29a0801062038j269466fcgaffd2b90d59ebfb4@mail.gmail.com>
For output of git-ls-files is
100644 c462997b94c371248bf17895ee18e7fbea5bce9b 0 .gitmodules
160000 091158296a8f57322f70f3c17e5fcb66687a0970 0 a
160000 6397239aeb662ba96f61b59ccc0a0d0812f48435 0 b
160000 c9f0a7dedcb4a9daf5a68c37109577d7d177e10b 0 c
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 main.txt
Sorry for the mistake earlier.
The pastes are also available here.
http://git.pastebin.com/f632762aa
Please help.
Best regards & thank you,
Imran
On Jan 7, 2008 10:38 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:
> Hi all,
>
> I am facing a strange problem with git ls-files in git-submodule. When I do -
> echo in modules init with "$@" - `git-ls-files --stage` - `git
> ls-files --stage -- "$@" | grep -e '^160000 '` - `pwd`
> The output is =
>
> in modules init with d - 100644
> c462997b94c371248bf17895ee18e7fbea5bce9b 0 .gitmodules 160000
> 091158296a8f57322f70f3c17e5fcb66687a0970 0 a 160000
> 6397239aeb662ba96f61b59ccc0a0d0812f48435 0 b 160000
> c9f0a7dedcb4a9daf5a68c37109577d7d177e10b 0 c 100644
> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 main.txt - -
> /home/imyousuf/projects/git-projs/test/super-project/a
>
> If we format the above output of git list-files --stage we can see the following
>
> 100644 c462997b94c371248bf17895ee18e7fbea5bce9b 0 .gitmodules
> 160000 091158296a8f57322f70f3c17e5fcb66687a0970 0 a
> 160000 6397239aeb662ba96f61b59ccc0a0d0812f48435 0 b
> 160000 c9f0a7dedcb4a9daf5a68c37109577d7d177e10b 0 c
> 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 main.txt
>
> In the output please note the path
> /home/imyousuf/projects/git-projs/test/super-project/a
>
> Now I am providing the output of -
> ls -al /home/imyousuf/projects/git-projs/test/super-project/a
>
> drwxr-xr-x 4 imyousuf imyousuf 4096 2008-01-07 10:22 .
> drwxr-xr-x 6 imyousuf imyousuf 4096 2008-01-07 10:22 ..
> -rw-r--r-- 1 imyousuf imyousuf 130 2008-01-07 10:22 a.txt
> drwxr-xr-x 2 imyousuf imyousuf 4096 2008-01-07 10:22 d
> drwxr-xr-x 8 imyousuf imyousuf 4096 2008-01-07 10:22 .git
> -rw-r--r-- 1 imyousuf imyousuf 95 2008-01-07 10:22 .gitmodules
>
>
> Now this is getting really confusing for me, because I get the strange
> output when I call the git submodule from shell script but after the
> shell script is executed if I do the same command copy and paste in
> gnome-terminal it works fine.
>
> Can someone please tell me what I am doing wrong?
>
> Thank you,
>
> Imran
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
^ permalink raw reply
* Problem with git ls-files
From: Imran M Yousuf @ 2008-01-07 4:38 UTC (permalink / raw)
To: git
Hi all,
I am facing a strange problem with git ls-files in git-submodule. When I do -
echo in modules init with "$@" - `git-ls-files --stage` - `git
ls-files --stage -- "$@" | grep -e '^160000 '` - `pwd`
The output is =
in modules init with d - 100644
c462997b94c371248bf17895ee18e7fbea5bce9b 0 .gitmodules 160000
091158296a8f57322f70f3c17e5fcb66687a0970 0 a 160000
6397239aeb662ba96f61b59ccc0a0d0812f48435 0 b 160000
c9f0a7dedcb4a9daf5a68c37109577d7d177e10b 0 c 100644
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 main.txt - -
/home/imyousuf/projects/git-projs/test/super-project/a
If we format the above output of git list-files --stage we can see the following
100644 c462997b94c371248bf17895ee18e7fbea5bce9b 0 .gitmodules
160000 091158296a8f57322f70f3c17e5fcb66687a0970 0 a
160000 6397239aeb662ba96f61b59ccc0a0d0812f48435 0 b
160000 c9f0a7dedcb4a9daf5a68c37109577d7d177e10b 0 c
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 main.txt
In the output please note the path
/home/imyousuf/projects/git-projs/test/super-project/a
Now I am providing the output of -
ls -al /home/imyousuf/projects/git-projs/test/super-project/a
drwxr-xr-x 4 imyousuf imyousuf 4096 2008-01-07 10:22 .
drwxr-xr-x 6 imyousuf imyousuf 4096 2008-01-07 10:22 ..
-rw-r--r-- 1 imyousuf imyousuf 130 2008-01-07 10:22 a.txt
drwxr-xr-x 2 imyousuf imyousuf 4096 2008-01-07 10:22 d
drwxr-xr-x 8 imyousuf imyousuf 4096 2008-01-07 10:22 .git
-rw-r--r-- 1 imyousuf imyousuf 95 2008-01-07 10:22 .gitmodules
Now this is getting really confusing for me, because I get the strange
output when I call the git submodule from shell script but after the
shell script is executed if I do the same command copy and paste in
gnome-terminal it works fine.
Can someone please tell me what I am doing wrong?
Thank you,
Imran
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Jeff King @ 2008-01-07 3:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Jon Hancock, git
In-Reply-To: <7v63y62xwj.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 06, 2008 at 06:05:16PM -0800, Junio C Hamano wrote:
> Actually, I think I found a bug.
>
> $ git reset --hard
> $ echo >>Makefile
> $ git diff --numstat
> 1 0 Makefile
> $ git mv Makefile makefile
> $ git diff
> $ git diff --cached -M --numstat
> 1 0 Makefile => makefile
>
> "git mv" should not have staged the change. It should have
> moved the index entry from Makefile to makefile and moved the
> work tree files.
I thought there was some discussion about this a few months ago,
concerning what exactly it should do, and that was how we arrived at the
current behavior. However, I can't seem to find it now. Maybe I dreamed
it.
-Peff
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Jay Soffian @ 2008-01-07 3:05 UTC (permalink / raw)
To: Jon Hancock; +Cc: git
In-Reply-To: <379EDA94-A67B-483A-BC5F-E961DD52AD0C@gmail.com>
On 1/6/08, Jon Hancock <redstarling@gmail.com> wrote:
> Additionally, is there
> a simple procedure with git to say: "I want to version exactly what is
> in my working tree. If I removed something or added something, just
> handle it".
>From http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html#id2553633
is the helpful hint:
$ git-ls-files -d -m -o -z | xargs -0 git-update-index --add --remove
I've got the following aliases in my .gitconfig:
alias.addremove=!git-ls-files -d -m -o -z -X .git/info/exclude -X
$(git-config core.excludesfile) --exclude-per-directory=.gitignore |
xargs -0 git-update-index --add --remove
alias.ls=!git-ls-files -d -m -o -v -X .git/info/exclude -X
$(git-config core.excludesfile) --exclude-per-directory=.gitignore
(In 1.5.4, you can replace the two -X's and the
--exclude-per-directory with --exclude-standard.)
j.
^ permalink raw reply
* [RFC] Initializing and updating submodules during clone and recursion over submodules
From: Imran M Yousuf @ 2008-01-07 2:27 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
Hi All,
I have added "recurse" command to the git-submodule to recurse any git
command and also added fetching of submodules during cloning. Please
have a look at the changes and let me know your comments on them.
Thank you and best regards,
--
Imran M Yousuf
[-- Attachment #2: git-submodule --]
[-- Type: application/octet-stream, Size: 8786 bytes --]
#!/bin/sh
#
# git-submodules.sh: add, init, update or list git submodules
# or recurse any git command over the submodules recursively.
#
# Copyright (c) 2007 Lars Hjemli
USAGE='[[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]|[recurse [-v] command arguments ...]]'
. git-sh-setup
require_work_tree
add=
branch=
init=
update=
status=
quiet=
cached=
#
# print stuff on stdout unless -q was specified
#
say()
{
if test -z "$quiet"
then
echo "$@"
fi
}
# NEEDSWORK: identical function exists in get_repo_base in clone.sh
get_repo_base() {
(
cd "`/bin/pwd`" &&
cd "$1" || cd "$1.git" &&
{
cd .git
pwd
}
) 2>/dev/null
}
#
# Map submodule path to submodule name
#
# $1 = path
#
module_name()
{
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
re=$(printf '%s' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
test -z "$name" &&
die "No submodule mapping found in .gitmodules for path '$path'"
echo "$name"
}
#
# Clone a submodule
#
# Prior to calling, modules_update checks that a possibly existing
# path is not a git repository.
# Likewise, module_add checks that path does not exist at all,
# since it is the location of a new submodule.
#
module_clone()
{
path=$1
url=$2
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
# action) and try to remove it.
# Note: if $path is a symlink to a directory the test will
# succeed but the rmdir will fail. We might want to fix this.
if test -d "$path"
then
rmdir "$path" 2>/dev/null ||
die "Directory '$path' exist, but is neither empty nor a git repository"
fi
test -e "$path" &&
die "A file already exist at path '$path'"
git-clone -n "$url" "$path" ||
die "Clone of '$url' into submodule path '$path' failed"
}
#
# Add a new submodule to the working tree, .gitmodules and the index
#
# $@ = repo [path]
#
# optional branch is stored in global branch variable
#
module_add()
{
repo=$1
path=$2
if test -z "$repo"; then
usage
fi
# Turn the source into an absolute path if
# it is local
if base=$(get_repo_base "$repo"); then
repo="$base"
fi
# Guess path from repo if not specified or strip trailing slashes
if test -z "$path"; then
path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
else
path=$(echo "$path" | sed -e 's|/*$||')
fi
test -e "$path" &&
die "'$path' already exists"
git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
die "'$path' already exists in the index"
module_clone "$path" "$repo" || exit
(unset GIT_DIR && cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
git add "$path" ||
die "Failed to add submodule '$path'"
GIT_CONFIG=.gitmodules git config submodule."$path".path "$path" &&
GIT_CONFIG=.gitmodules git config submodule."$path".url "$repo" &&
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
#
# Register submodules in .git/config
#
# $@ = requested paths (default to all)
#
modules_init()
{
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
# Skip already registered paths
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
test -z "$url" || continue
url=$(GIT_CONFIG=.gitmodules git config submodule."$name".url)
test -z "$url" &&
die "No url found for submodule path '$path' in .gitmodules"
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
say "Submodule '$name' ($url) registered for path '$path'"
done
}
#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
#
modules_update()
{
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
if test -z "$url"
then
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
say "Submodule path '$path' not initialized"
continue
fi
if ! test -d "$path"/.git
then
module_clone "$path" "$url" || exit
subsha1=
else
subsha1=$(unset GIT_DIR && cd "$path" &&
git rev-parse --verify HEAD) ||
die "Unable to find current revision in submodule path '$path'"
fi
if test "$subsha1" != "$sha1"
then
(unset GIT_DIR && cd "$path" && git-fetch &&
git-checkout -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
say "Submodule path '$path': checked out '$sha1'"
fi
done
}
set_name_rev () {
revname=$( (
unset GIT_DIR &&
cd "$1" && {
git describe "$2" 2>/dev/null ||
git describe --tags "$2" 2>/dev/null ||
git describe --contains --tags "$2"
}
) )
test -z "$revname" || revname=" ($revname)"
}
#
# List all submodules, prefixed with:
# - submodule not initialized
# + different revision checked out
#
# If --cached was specified the revision in the index will be printed
# instead of the currently checked out revision.
#
# $@ = requested paths (default to all)
#
modules_list()
{
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
if test -z "url" || ! test -d "$path"/.git
then
say "-$sha1 $path"
continue;
fi
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
say " $sha1 $path$revname"
else
if test -z "$cached"
then
sha1=$(unset GIT_DIR && cd "$path" && git rev-parse --verify HEAD)
set_name_rev "$path" "$sha1"
fi
say "+$sha1 $path$revname"
fi
done
}
# Simply checks whether the submodule is initialized
# or not. If not initialized it does so.
initializeSubModule() {
if [ ! -d "$1"/.git ]; then
if [ $recurse_verbose -eq 1 ]; then
echo Initializing and updating "$1"
fi
git-submodule init "$1"; git-submodule update "$1"
fi
}
# This actually traverses the module; checks
# whether the module is initialized or not.
# if not initialized, then done so and then the
# intended command is evaluated. Then it
# recursively goes into it modules.
traverseModule() {
current_dir=`pwd`
dir_path="$current_dir:$dir_path"
initializeSubModule "$1"
cd "$1"
if [ $recurse_verbose -eq 1 ]; then
echo Working in mod $1 @ `pwd` with $2
fi
eval "$2"
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
traverseModule "$mod_path" "$2"
done
fi
old_dir=$(echo $dir_path | cut -d':' -f1-1)
length_old_dir=`expr "$old_dir" : '.*'`
cd $old_dir
index=$(echo "$length_old_dir+2" | bc)
dir_path=`echo $dir_path $index | awk '{print substr($1, $2)}'`
}
# Propagates or recurses over all the submodules at any
# depth with any git command, e.g. git-clone, git-status,
# git-commit etc., with the arguments supplied exactly as
# it would have been supplied to the command otherwise.
# This actually starts the recursive propagation
propagate() {
project_home=`pwd`
echo Project Home: $project_home
if [ -d $project_home/.git/ ]; then
git_command=$1
shift
command_arguments=""
for arg in "$@"; do
if [ `expr index "$arg" ' '` -gt 0 ]; then
arg="\"$arg\""
fi
command_arguments="$command_arguments $arg"
done
if [ $recurse_verbose -eq 1 ]; then
echo GIT Command git-$git_command with arguments\($#\) "$command_arguments"
fi
main_command="git-$git_command $command_arguments"
eval $main_command
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
traverseModule $mod_path "$main_command"
done
fi
else
echo $project_home not a git repo thus exiting
exit
fi
}
recurse_verbose=0
while test $# != 0
do
case "$1" in
add)
add=1
;;
init)
init=1
;;
update)
update=1
;;
status)
status=1
;;
-q|--quiet)
quiet=1
;;
-b|--branch)
case "$2" in
'')
usage
;;
esac
branch="$2"; shift
;;
--cached)
cached=1
;;
--)
break
;;
-*)
usage
;;
recurse)
recurse=1
case "$2" in
-v)
recurse_verbose=1
shift
;;
esac
shift
break
;;
*)
break
;;
esac
shift
done
case "$add,$branch" in
1,*)
;;
,)
;;
,*)
usage
;;
esac
case "$add,$init,$update,$recurse,$status,$cached" in
1,,,,,)
module_add "$@"
;;
,1,,,,)
modules_init "$@"
;;
,,1,,,)
modules_update "$@"
;;
,,,1,,)
propagate "$@"
;;
,,,,*,*)
modules_list "$@"
;;
*)
usage
;;
esac
[-- Attachment #3: git-clone --]
[-- Type: application/octet-stream, Size: 12633 bytes --]
#!/bin/sh
#
# Copyright (c) 2005, Linus Torvalds
# Copyright (c) 2005, Junio C Hamano
#
# Clone a repository into a different directory that does not yet exist.
# See git-sh-setup why.
unset CDPATH
die() {
echo >&2 "$@"
exit 1
}
usage() {
die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-w|--with-submodule] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
}
get_repo_base() {
(
cd "`/bin/pwd`" &&
cd "$1" || cd "$1.git" &&
{
cd .git
pwd
}
) 2>/dev/null
}
if [ -n "$GIT_SSL_NO_VERIFY" -o \
"`git config --bool http.sslVerify`" = false ]; then
curl_extra_args="-k"
fi
http_fetch () {
# $1 = Remote, $2 = Local
curl -nsfL $curl_extra_args "$1" >"$2" ||
case $? in
126|127) exit ;;
*) return $? ;;
esac
}
clone_dumb_http () {
# $1 - remote, $2 - local
cd "$2" &&
clone_tmp="$GIT_DIR/clone-tmp" &&
mkdir -p "$clone_tmp" || exit 1
if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
"`git config --bool http.noEPSV`" = true ]; then
curl_extra_args="${curl_extra_args} --disable-epsv"
fi
http_fetch "$1/info/refs" "$clone_tmp/refs" ||
die "Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?"
test "z$quiet" = z && v=-v || v=
while read sha1 refname
do
name=`expr "z$refname" : 'zrefs/\(.*\)'` &&
case "$name" in
*^*) continue;;
esac
case "$bare,$name" in
yes,* | ,heads/* | ,tags/*) ;;
*) continue ;;
esac
if test -n "$use_separate_remote" &&
branch_name=`expr "z$name" : 'zheads/\(.*\)'`
then
tname="remotes/$origin/$branch_name"
else
tname=$name
fi
git-http-fetch $v -a -w "$tname" "$sha1" "$1" || exit 1
done <"$clone_tmp/refs"
rm -fr "$clone_tmp"
http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" ||
rm -f "$GIT_DIR/REMOTE_HEAD"
if test -f "$GIT_DIR/REMOTE_HEAD"; then
head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
case "$head_sha1" in
'ref: refs/'*)
;;
*)
git-http-fetch $v -a "$head_sha1" "$1" ||
rm -f "$GIT_DIR/REMOTE_HEAD"
;;
esac
fi
}
initializeSubModule() {
if [ ! -d "$1"/.git ]; then
git-submodule init "$1"; git-submodule update "$1"
fi
}
initSubModules() {
current_dir=`pwd`
dir_path="$current_dir:$dir_path"
initializeSubModule "$1"
cd "$1"
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
initSubModules "$mod_path"
done
fi
old_dir=$(echo $dir_path | cut -d':' -f1-1)
length_old_dir=`expr "$old_dir" : '.*'`
cd $old_dir
index=$(echo "$length_old_dir+2" | bc)
dir_path=`echo $dir_path $index | awk '{print substr($1, $2)}'`
}
quiet=
local=no
use_local_hardlink=yes
local_shared=no
unset template
no_checkout=
upload_pack=
bare=
reference=
origin=
origin_override=
use_separate_remote=t
depth=
no_progress=
local_explicitly_asked_for=
test -t 1 || no_progress=--no-progress
with_submodule=0
while
case "$#,$1" in
0,*) break ;;
*,-n|*,--no|*,--no-|*,--no-c|*,--no-ch|*,--no-che|*,--no-chec|\
*,--no-check|*,--no-checko|*,--no-checkou|*,--no-checkout)
no_checkout=yes ;;
*,--na|*,--nak|*,--nake|*,--naked|\
*,-b|*,--b|*,--ba|*,--bar|*,--bare) bare=yes ;;
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local)
local_explicitly_asked_for=yes
use_local_hardlink=yes ;;
*,--no-h|*,--no-ha|*,--no-har|*,--no-hard|*,--no-hardl|\
*,--no-hardli|*,--no-hardlin|*,--no-hardlink|*,--no-hardlinks)
use_local_hardlink=no ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; ;;
1,--template) usage ;;
*,--template)
shift; template="--template=$1" ;;
*,--template=*)
template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote) ;;
*,--no-separate-remote)
die "clones are always made with separate-remote layout" ;;
1,--reference) usage ;;
*,--reference)
shift; reference="$1" ;;
*,--reference=*)
reference=`expr "z$1" : 'z--reference=\(.*\)'` ;;
*,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)
case "$2" in
'')
usage ;;
*/*)
die "'$2' is not suitable for an origin name"
esac
git check-ref-format "heads/$2" ||
die "'$2' is not suitable for a branch name"
test -z "$origin_override" ||
die "Do not give more than one --origin options."
origin_override=yes
origin="$2"; shift
;;
1,-u|1,--upload-pack) usage ;;
*,-u|*,--upload-pack)
shift
upload_pack="--upload-pack=$1" ;;
*,--upload-pack=*)
upload_pack=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
*,-w|*,--w|*,--wi|*,--wit|*,--with|*,--with-s|*,--with-su|*,--with-sub|*,--with-subm|*,--with-submo|*,--with-submod|*,--with-submodu|*,--with-submodul|*,--with-submodule) with_submodule=1 ;;
1,--depth) usage;;
*,--depth)
shift
depth="--depth=$1";;
*,-*) usage ;;
*) break ;;
esac
do
shift
done
repo="$1"
test -n "$repo" ||
die 'you must specify a repository to clone.'
# --bare implies --no-checkout and --no-separate-remote
if test yes = "$bare"
then
if test yes = "$origin_override"
then
die '--bare and --origin $origin options are incompatible.'
fi
no_checkout=yes
use_separate_remote=
fi
if test -z "$origin"
then
origin=origin
fi
# Turn the source into an absolute path if
# it is local
if base=$(get_repo_base "$repo"); then
repo="$base"
local=yes
fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && die "destination directory '$dir' already exists."
[ yes = "$bare" ] && unset GIT_WORK_TREE
[ -n "$GIT_WORK_TREE" ] && [ -e "$GIT_WORK_TREE" ] &&
die "working tree '$GIT_WORK_TREE' already exists."
D=
W=
cleanup() {
err=$?
test -z "$D" && rm -rf "$dir"
test -z "$W" && test -n "$GIT_WORK_TREE" && rm -rf "$GIT_WORK_TREE"
cd ..
test -n "$D" && rm -rf "$D"
test -n "$W" && rm -rf "$W"
exit $err
}
trap cleanup 0
mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
test -n "$GIT_WORK_TREE" && mkdir -p "$GIT_WORK_TREE" &&
W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
if test yes = "$bare" || test -n "$GIT_WORK_TREE"; then
GIT_DIR="$D"
else
GIT_DIR="$D/.git"
fi &&
export GIT_DIR &&
GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
if test -n "$bare"
then
GIT_CONFIG="$GIT_DIR/config" git config core.bare true
fi
if test -n "$reference"
then
ref_git=
if test -d "$reference"
then
if test -d "$reference/.git/objects"
then
ref_git="$reference/.git"
elif test -d "$reference/objects"
then
ref_git="$reference"
fi
fi
if test -n "$ref_git"
then
ref_git=$(cd "$ref_git" && pwd)
echo "$ref_git/objects" >"$GIT_DIR/objects/info/alternates"
(
GIT_DIR="$ref_git" git for-each-ref \
--format='%(objectname) %(*objectname)'
) |
while read a b
do
test -z "$a" ||
git update-ref "refs/reference-tmp/$a" "$a"
test -z "$b" ||
git update-ref "refs/reference-tmp/$b" "$b"
done
else
die "reference repository '$reference' is not a local directory."
fi
fi
rm -f "$GIT_DIR/CLONE_HEAD"
# We do local magic only when the user tells us to.
case "$local" in
yes)
( cd "$repo/objects" ) ||
die "cannot chdir to local '$repo/objects'."
if test "$local_shared" = yes
then
mkdir -p "$GIT_DIR/objects/info"
echo "$repo/objects" >>"$GIT_DIR/objects/info/alternates"
else
l= &&
if test "$use_local_hardlink" = yes
then
# See if we can hardlink and drop "l" if not.
sample_file=$(cd "$repo" && \
find objects -type f -print | sed -e 1q)
# objects directory should not be empty because
# we are cloning!
test -f "$repo/$sample_file" || exit
if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
then
rm -f "$GIT_DIR/objects/sample"
l=l
elif test -n "$local_explicitly_asked_for"
then
echo >&2 "Warning: -l asked but cannot hardlink to $repo"
fi
fi &&
cd "$repo" &&
find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
*)
case "$repo" in
rsync://*)
case "$depth" in
"") ;;
*) die "shallow over rsync not supported" ;;
esac
rsync $quiet -av --ignore-existing \
--exclude info "$repo/objects/" "$GIT_DIR/objects/" ||
exit
# Look at objects/info/alternates for rsync -- http will
# support it natively and git native ones will do it on the
# remote end. Not having that file is not a crime.
rsync -q "$repo/objects/info/alternates" \
"$GIT_DIR/TMP_ALT" 2>/dev/null ||
rm -f "$GIT_DIR/TMP_ALT"
if test -f "$GIT_DIR/TMP_ALT"
then
( cd "$D" &&
. git-parse-remote &&
resolve_alternates "$repo" <"$GIT_DIR/TMP_ALT" ) |
while read alt
do
case "$alt" in 'bad alternate: '*) die "$alt";; esac
case "$quiet" in
'') echo >&2 "Getting alternate: $alt" ;;
esac
rsync $quiet -av --ignore-existing \
--exclude info "$alt" "$GIT_DIR/objects" || exit
done
rm -f "$GIT_DIR/TMP_ALT"
fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
https://*|http://*|ftp://*)
case "$depth" in
"") ;;
*) die "shallow over http or ftp not supported" ;;
esac
if test -z ""
then
clone_dumb_http "$repo" "$D"
else
die "http transport not supported, rebuild Git with curl support"
fi
;;
*)
case "$upload_pack" in
'') git-fetch-pack --all -k $quiet $depth $no_progress "$repo";;
*) git-fetch-pack --all -k $quiet "$upload_pack" $depth $no_progress "$repo" ;;
esac >"$GIT_DIR/CLONE_HEAD" ||
die "fetch-pack from '$repo' failed."
;;
esac
;;
esac
test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp"
if test -f "$GIT_DIR/CLONE_HEAD"
then
# Read git-fetch-pack -k output and store the remote branches.
if [ -n "$use_separate_remote" ]
then
branch_top="remotes/$origin"
else
branch_top="heads"
fi
tag_top="tags"
while read sha1 name
do
case "$name" in
*'^{}')
continue ;;
HEAD)
destname="REMOTE_HEAD" ;;
refs/heads/*)
destname="refs/$branch_top/${name#refs/heads/}" ;;
refs/tags/*)
destname="refs/$tag_top/${name#refs/tags/}" ;;
*)
continue ;;
esac
git update-ref -m "clone: from $repo" "$destname" "$sha1" ""
done < "$GIT_DIR/CLONE_HEAD"
fi
if test -n "$W"; then
cd "$W" || exit
else
cd "$D" || exit
fi
if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
then
# a non-bare repository is always in separate-remote layout
remote_top="refs/remotes/$origin"
head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
case "$head_sha1" in
'ref: refs/'*)
# Uh-oh, the remote told us (http transport done against
# new style repository with a symref HEAD).
# Ideally we should skip the guesswork but for now
# opt for minimum change.
head_sha1=`expr "z$head_sha1" : 'zref: refs/heads/\(.*\)'`
head_sha1=`cat "$GIT_DIR/$remote_top/$head_sha1"`
;;
esac
# The name under $remote_top the remote HEAD seems to point at.
head_points_at=$(
(
test -f "$GIT_DIR/$remote_top/master" && echo "master"
cd "$GIT_DIR/$remote_top" &&
find . -type f -print | sed -e 's/^\.\///'
) | (
done=f
while read name
do
test t = $done && continue
branch_tip=`cat "$GIT_DIR/$remote_top/$name"`
if test "$head_sha1" = "$branch_tip"
then
echo "$name"
done=t
fi
done
)
)
# Upstream URL
git config remote."$origin".url "$repo" &&
# Set up the mappings to track the remote branches.
git config remote."$origin".fetch \
"+refs/heads/*:$remote_top/*" '^$' &&
# Write out remote.$origin config, and update our "$head_points_at".
case "$head_points_at" in
?*)
# Local default branch
git symbolic-ref HEAD "refs/heads/$head_points_at" &&
# Tracking branch for the primary branch at the remote.
git update-ref HEAD "$head_sha1" &&
rm -f "refs/remotes/$origin/HEAD"
git symbolic-ref "refs/remotes/$origin/HEAD" \
"refs/remotes/$origin/$head_points_at" &&
git config branch."$head_points_at".remote "$origin" &&
git config branch."$head_points_at".merge "refs/heads/$head_points_at"
;;
'')
# Source had detached HEAD pointing nowhere
git update-ref --no-deref HEAD "$head_sha1" &&
rm -f "refs/remotes/$origin/HEAD"
;;
esac
case "$no_checkout" in
'')
test "z$quiet" = z -a "z$no_progress" = z && v=-v || v=
git read-tree -m -u $v HEAD HEAD
esac
fi
rm -f "$GIT_DIR/CLONE_HEAD" "$GIT_DIR/REMOTE_HEAD"
if [ $with_submodule -eq 1 ]; then
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
initSubModules "$mod_path"
done
fi
fi
trap - 0
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Junio C Hamano @ 2008-01-07 2:05 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Jon Hancock, git
In-Reply-To: <20080107015518.GD17748@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I haven't looked to see if this optimization is in place, but "git mv"
> can also avoid having to recompute the sha1 of the file (which in most
> cases doesn't matter, but on a large file with a cold cache, can make
> the operation seem just as snappy as a regular "mv").
Actually, I think I found a bug.
$ git reset --hard
$ echo >>Makefile
$ git diff --numstat
1 0 Makefile
$ git mv Makefile makefile
$ git diff
$ git diff --cached -M --numstat
1 0 Makefile => makefile
"git mv" should not have staged the change. It should have
moved the index entry from Makefile to makefile and moved the
work tree files.
The fix for this would fall out from your "optimization" quite
naturally, but I think that might be a post 1.5.4 item.
^ permalink raw reply
* Re: [PATCH] Test "git log --diff-filter"
From: Junio C Hamano @ 2008-01-07 1:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Arjen Laarhoven
In-Reply-To: <200801070131.57722.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Am I mistaken in thinking that the rest of git always use terminators,
> and not separators for records output?
Actually, for normal "git log", separator semantics is the right
thing to use. You do not want to add an additional trailing
newline when you show only one. Compare these two to see what I
mean:
$ git log -1
$ git log -2
The problem is with --pretty=format.
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Jeff King @ 2008-01-07 1:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Hancock, git
In-Reply-To: <alpine.LFD.1.00.0801061108320.2811@woody.linux-foundation.org>
On Sun, Jan 06, 2008 at 11:22:50AM -0800, Linus Torvalds wrote:
> > So, do I need to use git's mv and rm commands?
>
> Nope.
>
> They are there only to
>
> (a) make people who are used to do "svn mv" not complain
>
> (b) simplify things a little teeny bit, by avoiding having to "git add"
> the new file.
I haven't looked to see if this optimization is in place, but "git mv"
can also avoid having to recompute the sha1 of the file (which in most
cases doesn't matter, but on a large file with a cold cache, can make
the operation seem just as snappy as a regular "mv").
-Peff
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Jeff King @ 2008-01-07 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk724pji.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 06, 2008 at 01:22:57PM -0800, Junio C Hamano wrote:
> Yes, to a certain extent with Perl (I think if you make the same
> typo twice you won't get much help, and that is quite easy to
> trigger with variable name autocompletion and cut-and-paste).
Yes, and a static checking language would be a little less error-prone.
But who can live without "eval <STDIN>"? :)
> I suspect "if (!$menu_use_color)" might need to be refined in
> sub "highlight_prefix". It should be tied with $prompt_color
> somehow (i.e. either it is undef or the "plain" color),
> shouldn't it?
I'm not sure. It avoids printing the brackets in "[p]atch". If you say
"use color, but make the color plain" does that mean you want brackets
or not (right now it will not show brackets)?
> But other than that the result looks quite nice. I shuffled the
> patches around and the resulting series consists of three patches:
Great. That is the order I would have chosen as well (and hopefully I
gave you enough material in the commit messages to cut and paste
something sensible).
-Peff
^ permalink raw reply
* Re: [PATCH] Test "git log --diff-filter"
From: Jakub Narebski @ 2008-01-07 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Arjen Laarhoven
In-Reply-To: <7vmyrj7kq5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > My test checks all --diff-filter filters relevant to git-diff-tree,
> > i.e. ADMRCBT, and not only AMD.
>
> Ah, I see. Thanks --- that could have been stated in the log
> message. Maybe we would want to add them to existing test
> script, instead of adding a whole new one?
The test as it stands now checks if --diff-filter select appropriate
revisions, even without patch output. I think it is enough, as I don't
see how we could screw up to filter AMD correctly, and not all others...
...perhaps with exception of pair breaking, and how they are filtered
using --diff-filter=M and --diff-filter=B; but this impression might
be caused by the fact that pair breaking is the only one which doesn't
use symbol ('B') in raw diff format output.
> > P.S. By the way, it is IMHO a bit strange that --pretty=oneline uses
> > newline as a terminator (it means that there is a newline at the end of
> > "git log --pretty=oneline), while --pretty="format:%s" uses newline as
> > a separator...
>
> Yeah, I tend to agree, although I learned to live with it long
> time ago.
IMHO that is design bug. Perhaps it should be changed? This way, at least
conceptually oneline, short, medium, full, fuller, email formats might be
considered simply pre-defined format:<sth> formats.
Am I mistaken in thinking that the rest of git always use terminators,
and not separators for records output?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Make commit, cherry-pick and revert more silent.
From: Junio C Hamano @ 2008-01-06 22:52 UTC (permalink / raw)
To: Gabriel; +Cc: git
In-Reply-To: <1199634201-26013-1-git-send-email-g2p.code@gmail.com>
Gabriel <g2p.code@gmail.com> writes:
> Commit now obeys --quiet more.
> Cherry-pick and revert call commit as --quiet.
> Prevents us from displaying working-tree status once or even twice.
Well, you also need to defend that it is a good thing not to
show the status information during cherry-pick or revert much
better, especially when we are this late into the -rc cycle.
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 73f1e35..96ace77 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -759,7 +759,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>
> if (!prepare_log_message(index_file, prefix) && !in_merge &&
> !allow_empty && !(amend && is_a_merge(head_sha1))) {
> - run_status(stdout, index_file, prefix, 0);
> + fprintf(stderr, "There are no changes, not committing.\n");
> + if (!quiet)
> + run_status(stdout, index_file, prefix, 0);
Especially if you are introducing a change to a command you do
not even mention in the topic line of the patch.
Having said that, I think it is a good change, if the UI change
to cherry-pick and revert only triggers when the operation did
not have any effect.
It is much harder to know for a user if a cherry-pick or revert
will result in such a situation before actually running these
commands, than when making his own commit. And the status
output from underlying git-commit only distracts him by
obscuring the punch-line "nothing added to commit", which is
currently the only clue. I'd agree that is a UI bug in the
current implementation of cherry-pick/revert.
So a more convincing presentation would be:
* A single patch to "git commit". The commit log message would
read:
When there is nothing to commit, "git commit --quiet" still
shows the status output before saying "nothing added to
commit...". This patch makes it less verbose.
* Another patch on top of it that runs "git commit" with
the "--quiet" option from cherry-pick and revert. The commit
log message would read:
When cherry-pick or revert results in no change at all
(e.g. the user cherry-picked an ancestor of the current
commit), the command correctly refuses to create a new
commit, but it responds by showing the status output and
"nothing added to commit" message.
This is a very roundabout way to tell the user that the
cherry-pick or revert was unnecessary. Especially because it
is much harder to know for a user if a cherry-pick or revert
will result in such a situation before actually running these
commands, than when making his own commit.
This patch makes cherry-pick and revert call "git commit"
with --quiet option to make the output much less confusing.
After I wrote all that, I realized that the patch is not
acceptable as is.
Why?
This makes a successful cherry-pick way too silent. With your
patch, we will see:
* "Auto-merged ..." messages that shows what paths are affected
by the cherry-pick/revert (which I do not think we would want
to squelch),
* "Finished one cherry-pick."
But we will lose the "Created commit ...: <msg>" and "<num>
files changed..." summary, neither of which we would want to
lose.
Also sign your patch (see Documentation/SubmittingPatches),
please, when you try the second round.
Thanks.
^ permalink raw reply
* Re: [PATCH] parse_commit_buffer: don't parse invalid commits
From: Junio C Hamano @ 2008-01-06 22:00 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <11996461913672-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
> ---
> commit.c | 28 +++++++++++++++++++++-------
> 1 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/commit.c b/commit.c
> index f074811..ffa0894 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -48,19 +48,33 @@ struct commit *lookup_commit(const unsigned char *sha1)
> return check_commit(obj, sha1, 0);
> }
>
> -static unsigned long parse_commit_date(const char *buf)
> +static unsigned long parse_commit_date(const char *buf, const char* tail)
Should be "const char *tail" in our codebase.
> {
> unsigned long date;
> + char datebuf[20];
> + unsigned long len;
>
> + if (buf + 6 >= tail)
> + return 0;
> if (memcmp(buf, "author", 6))
> return 0;
Even though buf, which is a result from read_sha1_file(), is
always terminated with an extra NUL (outside its object size),
if a bogus commit object ends with "author" (and without the
author information) this part will pass, and ...
> - while (*buf++ != '\n')
> + while (buf < tail && *buf++ != '\n')
> /* nada */;
> + if (buf + 9 >= tail)
> + return 0;
... you catch that here. That seems like a good change.
> if (memcmp(buf, "committer", 9))
> return 0;
> - while (*buf++ != '>')
> + while (buf < tail && *buf++ != '>')
> /* nada */;
> - date = strtoul(buf, NULL, 10);
> + if (buf >= tail)
> + return 0;
Likewise here.
> + len = tail - buf;
> + if (len > sizeof(datebuf) - 1)
> + len = sizeof(datebuf) - 1;
Broken indentation.
> + memcpy(datebuf, buf, len);
> + datebuf[len] = 0;
> + date = strtoul(datebuf, NULL, 10);
However, as long as buf at this point hasn't go beyond tail,
which you already checked, I think we can rely on strtoul()
stopping at the NUL at the end of buffer (that is one beyond
tail), without this extra memcpy(). Am I mistaken?
> @@ -236,9 +250,9 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
> return 0;
> item->object.parsed = 1;
> tail += size;
> - if (tail <= bufptr + 5 || memcmp(bufptr, "tree ", 5))
> + if (tail <= bufptr + 46 || memcmp(bufptr, "tree ", 5) || bufptr[45] != '\n')
> return error("bogus commit object %s", sha1_to_hex(item->object.sha1));
> - if (tail <= bufptr + 45 || get_sha1_hex(bufptr + 5, parent) < 0)
> + if (get_sha1_hex(bufptr + 5, parent) < 0)
> return error("bad tree pointer in commit %s",
> sha1_to_hex(item->object.sha1));
> item->tree = lookup_tree(parent);
This hunk is logically a no-op but I like your version better.
It also makes sure tree object name is terminated with a LF.
> @@ -275,7 +289,7 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
> n_refs++;
> }
> }
> - item->date = parse_commit_date(bufptr);
> + item->date = parse_commit_date(bufptr, tail);
>
> if (track_object_refs) {
> unsigned i = 0;
> --
> 1.4.4.4
When already somewhat deep in the rc cycle, looking at a patch
from somebody who uses 1.4.4.4 makes me look at the patch a bit
more carefully than usual ;-)
^ permalink raw reply
* Re: [PATCH] Make the git metapackage require the same version of the subpackages.
From: Junio C Hamano @ 2008-01-06 21:24 UTC (permalink / raw)
To: James Bowes; +Cc: git
In-Reply-To: <3f80363f0801061313o514fa01bje354503483db47ab@mail.gmail.com>
"James Bowes" <jbowes@dangerouslyinc.com> writes:
> I believe the obsolete is still needed, as you'd need a way to tell
> rpm to just get rid of git-p4 entirely.
Thanks.
I am also wondering what should happen to spec file if we were
to later re-introduce git-p4, but that is not an immediate
concern.
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-06 21:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080106205946.GA17482@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yes, I considered making a %palette, as well, but it just seemed a
> little gratuitous (and the nice thing about using variables is that they
> catch typos better).
Yes, to a certain extent with Perl (I think if you make the same
typo twice you won't get much help, and that is quite easy to
trigger with variable name autocompletion and cut-and-paste).
I suspect "if (!$menu_use_color)" might need to be refined in
sub "highlight_prefix". It should be tied with $prompt_color
somehow (i.e. either it is undef or the "plain" color),
shouldn't it?
But other than that the result looks quite nice. I shuffled the
patches around and the resulting series consists of three patches:
- "remove unused diff colors";
- "color.diff" colors diff, "color.interactive" colors
interaction (squashed the original with change to the "sub
colored" to use palette setting instead of $use_color as the
cue);
- documentation update to redefine the color.interactive
semantics;
^ permalink raw reply
* Re: [PATCH] Make the git metapackage require the same version of the subpackages.
From: James Bowes @ 2008-01-06 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprwe4s8e.fsf@gitster.siamese.dyndns.org>
On Jan 6, 2008 3:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> James Bowes <jbowes@dangerouslyinc.com> writes:
>
> > Without explicit version deps in the rpm spec file, 'yum update git'
> > effectively does nothing. Require explicit versions of the subpackages, so that
> > they get pulled in on an update.
> >
> > Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
>
> I am asking as an RPM illiterate, not questioning the validity
> of what your patch does.
>
> The approach your patch takes feels like the right way we should
> have taken from the beginning. Does this supersede the "fix" in
> 5587cac28be66acf5edc2a4b83b67c8cfffbc5e9 (GIT 1.5.3.1: obsolete
> git-p4 in RPM spec file)? IOW, if we had Requires for the same
> version from the beginning, we wouldn't have had the problem
> when we dropped git-p4 package?
I believe the obsolete is still needed, as you'd need a way to tell
rpm to just get rid of git-p4 entirely.
-James
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Jeff King @ 2008-01-06 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7b33zjk.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 06, 2008 at 04:32:15AM -0800, Junio C Hamano wrote:
> Yeah, I like that much better, especially the renaming of
> $use_color to more descriptive (but is it really about "menu", I
> wonder?).
I thought that, too, but I didn't know what better word to use
(something like "display" doesn't make it clear that it doesn't involve
the diff).
> I might consider rewriting this part
>
> > +my $menu_use_color = $repo->get_colorbool('color.interactive');
> > +my ($prompt_color, $header_color, $help_color) =
> > + $menu_use_color ? (
> > + $repo->get_color('color.interactive.prompt', 'bold blue'),
> > + $repo->get_color('color.interactive.header', 'bold'),
> > + $repo->get_color('color.interactive.help', 'red bold'),
> > + ) : ();
>
> like this:
>
> my ($prompt_color, $header_color, $help_color, $fraginfo_color);
> if ($colored_prompt) {
> $prompt_color = ...;
> $header_color = ...;
> }
> if ($colored_diff) {
> $fraginfo_color = ...;
> }
Actually, that's more or less how it's written before my patch (in fact,
you could eliminate that part of my patch and just move $normal_color
outside of the conditional). However I didn't like having the
declaration and the assignment so far apart (and duplicated). But I will
admit my version is a little nested. Please feel free to switch it when
you apply.
> or even like this:
>
> my (%palette);
> if ($colored_prompt) {
> my %default = (
> prompt => 'bold blue',
> header => 'bold',
> ...
> );
> while (my ($k,$v) = each %default) {
> $palette{$k} = $repo->get_color("color.interactive.$k",$v);
> }
> }
>
> But I realize that's going overboard. Certainly the last one is
> doing unnecessary generalization for generalization's sake.
Yes, I considered making a %palette, as well, but it just seemed a
little gratuitous (and the nice thing about using variables is that they
catch typos better).
-Peff
^ permalink raw reply
* Re: [PATCH] Make the git metapackage require the same version of the subpackages.
From: Junio C Hamano @ 2008-01-06 20:24 UTC (permalink / raw)
To: James Bowes; +Cc: git, gitster
In-Reply-To: <20080106173501.GB9349@spitfire>
James Bowes <jbowes@dangerouslyinc.com> writes:
> Without explicit version deps in the rpm spec file, 'yum update git'
> effectively does nothing. Require explicit versions of the subpackages, so that
> they get pulled in on an update.
>
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
I am asking as an RPM illiterate, not questioning the validity
of what your patch does.
The approach your patch takes feels like the right way we should
have taken from the beginning. Does this supersede the "fix" in
5587cac28be66acf5edc2a4b83b67c8cfffbc5e9 (GIT 1.5.3.1: obsolete
git-p4 in RPM spec file)? IOW, if we had Requires for the same
version from the beginning, we wouldn't have had the problem
when we dropped git-p4 package?
^ permalink raw reply
* Re: [PATCH] rebase interactive: Add hint how to continue after 'Unknown command' error
From: Junio C Hamano @ 2008-01-06 20:14 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Steffen Prohaska, git
In-Reply-To: <20080106195044.GA24169@old.davidb.org>
David Brown <git@davidb.org> writes:
> On Sun, Jan 06, 2008 at 06:33:32PM +0100, Wincent Colaiuta wrote:
>>El 6/1/2008, a las 16:46, Steffen Prohaska escribió:
>>
>>> @@ -310,7 +310,7 @@ do_next () {
>>> ;;
>>> *)
>>> warn "Unknown command: $command $sha1 $rest"
>>> - die_with_patch $sha1 "Please fix this in the file $TODO."
>>> + die_with_patch $sha1 "Please fix this in the file
>>> $TODO. And run 'git rebase --continue'."
>>
>>Grammar nit: sentences can't start with "And", so that should really be:
>
> Not true:
> <http://www.accu-assist.com/grammar-tips-archive/11-07-06_GrammarTip_and-but-conjunctions.htm>
>
> Although, in this case, I would agree that it should just be one sentence
> with a comma. It's more of a stylistic construct, more common in fiction
> than technical documentation.
I've always wondered why this part can't just re-launch the
editor with the $TODO file, have the instruction to "fix" in the
file for the user to see (together with the original "#
commented out" instructions), and do the --continue itself.
^ permalink raw reply
* Re: [PATCH] rebase interactive: Add hint how to continue after 'Unknown command' error
From: David Brown @ 2008-01-06 19:50 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Steffen Prohaska, git
In-Reply-To: <5F80ADF7-A68A-4DF3-8453-92B76BC927EF@wincent.com>
On Sun, Jan 06, 2008 at 06:33:32PM +0100, Wincent Colaiuta wrote:
>El 6/1/2008, a las 16:46, Steffen Prohaska escribió:
>
>> @@ -310,7 +310,7 @@ do_next () {
>> ;;
>> *)
>> warn "Unknown command: $command $sha1 $rest"
>> - die_with_patch $sha1 "Please fix this in the file $TODO."
>> + die_with_patch $sha1 "Please fix this in the file $TODO. And run
>> 'git rebase --continue'."
>
>Grammar nit: sentences can't start with "And", so that should really be:
Not true:
<http://www.accu-assist.com/grammar-tips-archive/11-07-06_GrammarTip_and-but-conjunctions.htm>
Although, in this case, I would agree that it should just be one sentence
with a comma. It's more of a stylistic construct, more common in fiction
than technical documentation.
Dave
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Linus Torvalds @ 2008-01-06 19:22 UTC (permalink / raw)
To: Jon Hancock; +Cc: git
In-Reply-To: <379EDA94-A67B-483A-BC5F-E961DD52AD0C@gmail.com>
On Sun, 6 Jan 2008, Jon Hancock wrote:
>
> So, do I need to use git's mv and rm commands?
Nope.
They are there only to
(a) make people who are used to do "svn mv" not complain
(b) simplify things a little teeny bit, by avoiding having to "git add"
the new file.
So if you do just a rename, you can do either
git mv old-file new-file
git commit
or you can do
mv old-file new-file
git add new-file
git commit -a
and the *result* will be the same (the "git commit -a" is there to
automatically pick up the fact that "old-file" went away: you could have
done it with "git rm old-file" too, or "git add -u" or any number of
other ways that update the index).
> Can't I just rename, add, and remove files using any means I like and
> then just ensure my "index" is staged properly when I do a commit?
Absolutely. And depending on your workflow, that may well be the right
thing to do.
In particular, this all means that it's perfectly fine to make changes to
a git repository using *any* non-git-aware tools, including things like
graphical file managers etc.
> Additionally, is there a simple procedure with git to say: "I want to
> version exactly what is in my working tree. If I removed something or
> added something, just handle it". This is sort of what "git add ."
> does, but "git add" doesn't handling things I removed or moved, correct?
You should be able to do that with either
git add .
git commit -a
or if you don't want to do a commit, you can do a
git add -u
git add .
where the "git add -u" will look at any files git already knows and update
them (which includes removing them if they are gone), and then "git add ."
will add any new files.
Linus
^ permalink raw reply
* [PATCH] parse_commit_buffer: don't parse invalid commits
From: Martin Koegler @ 2008-01-06 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
In-Reply-To: <11996461912682-git-send-email-mkoegler@auto.tuwien.ac.at>
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
commit.c | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/commit.c b/commit.c
index f074811..ffa0894 100644
--- a/commit.c
+++ b/commit.c
@@ -48,19 +48,33 @@ struct commit *lookup_commit(const unsigned char *sha1)
return check_commit(obj, sha1, 0);
}
-static unsigned long parse_commit_date(const char *buf)
+static unsigned long parse_commit_date(const char *buf, const char* tail)
{
unsigned long date;
+ char datebuf[20];
+ unsigned long len;
+ if (buf + 6 >= tail)
+ return 0;
if (memcmp(buf, "author", 6))
return 0;
- while (*buf++ != '\n')
+ while (buf < tail && *buf++ != '\n')
/* nada */;
+ if (buf + 9 >= tail)
+ return 0;
if (memcmp(buf, "committer", 9))
return 0;
- while (*buf++ != '>')
+ while (buf < tail && *buf++ != '>')
/* nada */;
- date = strtoul(buf, NULL, 10);
+ if (buf >= tail)
+ return 0;
+
+ len = tail - buf;
+ if (len > sizeof(datebuf) - 1)
+ len = sizeof(datebuf) - 1;
+ memcpy(datebuf, buf, len);
+ datebuf[len] = 0;
+ date = strtoul(datebuf, NULL, 10);
if (date == ULONG_MAX)
date = 0;
return date;
@@ -236,9 +250,9 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
return 0;
item->object.parsed = 1;
tail += size;
- if (tail <= bufptr + 5 || memcmp(bufptr, "tree ", 5))
+ if (tail <= bufptr + 46 || memcmp(bufptr, "tree ", 5) || bufptr[45] != '\n')
return error("bogus commit object %s", sha1_to_hex(item->object.sha1));
- if (tail <= bufptr + 45 || get_sha1_hex(bufptr + 5, parent) < 0)
+ if (get_sha1_hex(bufptr + 5, parent) < 0)
return error("bad tree pointer in commit %s",
sha1_to_hex(item->object.sha1));
item->tree = lookup_tree(parent);
@@ -275,7 +289,7 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
n_refs++;
}
}
- item->date = parse_commit_date(bufptr);
+ item->date = parse_commit_date(bufptr, tail);
if (track_object_refs) {
unsigned i = 0;
--
1.4.4.4
^ permalink raw reply related
* [PATCH] parse_tag_buffer: don't parse invalid tags
From: Martin Koegler @ 2008-01-06 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
The current tag parsing code can access memory outside the tag buffer,
if \n are missing. This patch prevent this behaviour.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
tag.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tag.c b/tag.c
index f62bcdd..fa22ae6 100644
--- a/tag.c
+++ b/tag.c
@@ -39,6 +39,7 @@ int parse_tag_buffer(struct tag *item, void *data, unsigned long size)
unsigned char sha1[20];
const char *type_line, *tag_line, *sig_line;
char type[20];
+ const char* start = data;
if (item->object.parsed)
return 0;
@@ -53,11 +54,11 @@ int parse_tag_buffer(struct tag *item, void *data, unsigned long size)
if (memcmp("\ntype ", type_line-1, 6))
return -1;
- tag_line = strchr(type_line, '\n');
+ tag_line = memchr(type_line, '\n', size - (type_line - start));
if (!tag_line || memcmp("tag ", ++tag_line, 4))
return -1;
- sig_line = strchr(tag_line, '\n');
+ sig_line = memchr(tag_line, '\n', size - (tag_line - start));
if (!sig_line)
return -1;
sig_line++;
--
1.4.4.4
^ permalink raw reply related
* [PATCH] Make the git metapackage require the same version of the subpackages.
From: James Bowes @ 2008-01-06 17:35 UTC (permalink / raw)
To: git, gitster
Without explicit version deps in the rpm spec file, 'yum update git'
effectively does nothing. Require explicit versions of the subpackages, so that
they get pulled in on an update.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
git.spec.in | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 3e5bebb..7f1bd5a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -10,7 +10,15 @@ URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, perl-Git
+
+Requires: git-core = %{version}-%{release}
+Requires: git-svn = %{version}-%{release}
+Requires: git-cvs = %{version}-%{release}
+Requires: git-arch = %{version}-%{release}
+Requires: git-email = %{version}-%{release}
+Requires: gitk = %{version}-%{release}
+Requires: git-gui = %{version}-%{release}
+Requires: perl-Git = %{version}-%{release}
%description
Git is a fast, scalable, distributed revision control system with an
@@ -172,6 +180,9 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %doc Documentation/technical}
%changelog
+* Sun Jan 06 2008 James Bowes <jbowes@dangerouslyinc.com>
+- Make the metapackage require the same version of the subpackages.
+
* Wed Dec 12 2007 Junio C Hamano <gitster@pobox.com>
- Adjust htmldir to point at /usr/share/doc/git-core-$version/
--
1.5.4.rc2.1141.g437b09
^ permalink raw reply related
* Re: [PATCH] rebase interactive: Add hint how to continue after 'Unknown command' error
From: Wincent Colaiuta @ 2008-01-06 17:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1199634385511-git-send-email-prohaska@zib.de>
El 6/1/2008, a las 16:46, Steffen Prohaska escribió:
> @@ -310,7 +310,7 @@ do_next () {
> ;;
> *)
> warn "Unknown command: $command $sha1 $rest"
> - die_with_patch $sha1 "Please fix this in the file $TODO."
> + die_with_patch $sha1 "Please fix this in the file $TODO. And run
> 'git rebase --continue'."
Grammar nit: sentences can't start with "And", so that should really be:
"Please fix this in the file $TODO and run 'git rebase --continue'."
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] tree-walk: don't parse incorrect entries
From: Martin Koegler @ 2008-01-06 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1w8w80a3.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 05, 2008 at 12:50:28PM -0800, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> > * The start of the path may not be after the last zero (21 bytes before the end).
>
> How can that be possible?
>
> - you know end points at NUL and buf < end;
>
> - get_mode() starts scanning from buf, stops at the first SP if
> returns a non NULL pointer; anything non octal digit before
> it sees that SP results in a NULL return;
>
> - the return value of get_mode() is the beginning of the path.
>
> The second point above means when get_mode() scans buf, it would
> never go beyond end which you already made sure is NUL (which is
> not SP and not an octal digit). If it hits end, you would get NULL
> pointer back, wouldn't you?
Yes, I agree with you.
> Rejecting an empty path may be sensible (i.e. checking "!*path"
> instead), though.
I sent a new patch with both changes.
mfg Martin Kögler
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox