* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Junio C Hamano @ 2006-05-09 21:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060510000826.1a708c03.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Better to support only -x=y or -x y, not both.
Didn't I just say -x=y where x is a single letter _is_ odd?
It is either -xy or -x y, not -x=y.
^ permalink raw reply
* Re: [PATCH/RFC] gitopt - command-line parsing enhancements
From: Eric Wong @ 2006-05-09 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7332ba0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> If you can make it an iterator style, it would be a lot easier
> to see what is going on, I suspect. Then you would not even
> need the callback function pointers and small functions created
> by magic eat() macros.
That sounds like a great idea, I'll work on it tonight.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/6] gitopt: a new command-line option parser for git
From: Timo Hirvonen @ 2006-05-09 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4u3nv8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > Better to support only -x=y or -x y, not both.
>
> Didn't I just say -x=y where x is a single letter _is_ odd?
> It is either -xy or -x y, not -x=y.
Oh, I thought parameters would use same syntax for short and long
options. For optional args -C2 would make sense but -C 2 would be
ambiguous ("-C -- 2" or "-C2"?). Maybe I'm just too drunk to
understand.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [BUG] "cg-object-id -p" ignore grafts, breaks cg-admin-rewritehist
From: Yann Dirson @ 2006-05-09 22:25 UTC (permalink / raw)
To: GIT list; +Cc: Petr Baudis
Currently (cogito 0.17.2), using "cg-object-id -p" to lookup a
commit's parents fetches information directly from the commit object
through "git-cat-file commit". This causes all its callers to ignore
any grafts, and probably causes various problems. The one I stumbled
upon is an inconstency in the data seen by cg-admin-rewritehist, when
a graft is used to replace the single parent of a commit with another
single parent - tentative recovery of a tarball import done on a wrong
branch, in the hope that cg-admin-rewritehist would allow to fix the
history as defined by the graft.
In that case, after identifying the commits to rewrite through legal
means, rewritehist attempts to lookup the parents for each of those
original commits and map them to already-rewritten ones, but
cg-object-id returns the pre-graft parent, which was not to be
rewritten, and the tool fails (miserably with an invalid rewritten
branch, as the exception is not caught).
A patch follows (depending on an updated "set -e" patch for
rewritehist) to have rewritehist at least abort in error when it can
identify such an inconsistency.
What should cg-object-id use to lookup parent information in a sane
way that does not ignore grafts ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 22:09 UTC (permalink / raw)
To: torvalds; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <BAYC1-PASMTP02C02EAC2F64AC00BB5801AEA90@CEZ.ICE>
On Tue, 9 May 2006 15:44:59 -0400
sean <seanlkml@sympatico.ca> wrote:
> On Tue, 9 May 2006 12:24:02 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > NOTE! This patch could be applied right now, and to all the branches (to
> > make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing
> > actually uses it.
> >
> > It just makes the syntax be
> >
> > [section<space>+"<randomstring>"]
> >
> > where the only rule for "randomstring" is that it can't contain a newline,
> > and if you really want to insert a double-quote, you do it with \".
>
> Lightly tested here. Looks good.
>
Linus,
I really tried to like your patch ;o) But it breaks the repo-config command
line and causes mixing of some branches using old style [branch.xyz] and new
style [branch "XYZ"] which just doesn't seem to be the right thing to do.
The following patch produced for sake of discussion just allows section
headers to contain whatever characters are needed to get the job done.
git-repo-config works properly with no further need of change. Section
headers become case sensitive but key identifiers within sections do not.
AFAIK there should be no backward compatibility issues with regard to
case sensitivity. All tests pass after having been fixed up to remove
the assumption that section names are case insensitive.
The syntax is:
[<random string>]
Here's how your example would look in this style:
[email.torvalds@osdl.org]
name = Linus Torvalds
And there's no strange syntax needed with repo-config to set and get it:
$ git repo-config email.torvalds@osdl.org.name
Linus Torvalds
and just to show that key names are still case insensitive:
$ git repo-config email.torvalds@osdl.org.NAME
Linus Torvalds
Setting new sections is unambiguous from the command line and
doesn't have to decide whether to use the [branch "<string>"] or
[branch.section.name] format.
$ git repo-config branch.branch.x y
$ git repo-config branch.WonkKY.x y
$ git repo-config --get-regexp branch.\*
branch.branch.x y
branch.WonkKY.x y
[email.torvalds@osdl.org]
name = Linus Torvalds
[branch.branch]
x = y
[branch.WonkKY]
x = y
Sean
---
config.c | 11 +++++++----
repo-config.c | 8 ++++----
t/t1300-repo-config.sh | 38 ++++++++++++++++++++++----------------
3 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/config.c b/config.c
index 0f518c9..5d19ae9 100644
--- a/config.c
+++ b/config.c
@@ -144,11 +144,14 @@ static int get_base_var(char *name)
return -1;
if (c == ']')
return baselen;
- if (!isalnum(c) && c != '.')
- return -1;
+ if (c == '\\') {
+ c = get_next_char();
+ if (c == '\n')
+ return -1;
+ }
if (baselen > MAXNAME / 2)
return -1;
- name[baselen++] = tolower(c);
+ name[baselen++] = c;
}
}
@@ -455,7 +458,7 @@ int git_config_set_multivar(const char*
ret = 1;
goto out_free;
} else
- store.key[i] = tolower(key[i]);
+ store.key[i] = key[i];
store.key[i] = 0;
/*
diff --git a/repo-config.c b/repo-config.c
index 63eda1b..ba5fbd6 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -65,11 +65,11 @@ static int show_config(const char* key_,
static int get_value(const char* key_, const char* regex_)
{
int i;
+ char *tl;
- key = malloc(strlen(key_)+1);
- for (i = 0; key_[i]; i++)
- key[i] = tolower(key_[i]);
- key[i] = 0;
+ key = strdup(key_);
+ for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
+ *tl = tolower(*tl);
if (use_key_regexp) {
key_regexp = (regex_t*)malloc(sizeof(regex_t));
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7090ea9..f341206 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -23,6 +23,7 @@ git-repo-config Core.Movie BadPhysics
cat > expect << EOF
[core]
penguin = little blue
+[Core]
Movie = BadPhysics
EOF
@@ -33,6 +34,7 @@ git-repo-config Cores.WhatEver Second
cat > expect << EOF
[core]
penguin = little blue
+[Core]
Movie = BadPhysics
[Cores]
WhatEver = Second
@@ -45,10 +47,12 @@ git-repo-config CORE.UPPERCASE true
cat > expect << EOF
[core]
penguin = little blue
+[Core]
Movie = BadPhysics
- UPPERCASE = true
[Cores]
WhatEver = Second
+[CORE]
+ UPPERCASE = true
EOF
test_expect_success 'similar section' 'cmp .git/config expect'
@@ -62,11 +66,13 @@ test_expect_success 'replace with non-ma
cat > expect << EOF
[core]
penguin = very blue
- Movie = BadPhysics
- UPPERCASE = true
penguin = kingpin
+[Core]
+ Movie = BadPhysics
[Cores]
WhatEver = Second
+[CORE]
+ UPPERCASE = true
EOF
test_expect_success 'non-match result' 'cmp .git/config expect'
@@ -130,7 +136,7 @@ EOF
test_expect_success 'really mean test' 'cmp .git/config expect'
-git-repo-config nextsection.nonewline wow
+git-repo-config nextSection.nonewline wow
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -160,7 +166,7 @@ EOF
test_expect_success 'unset' 'cmp .git/config expect'
-git-repo-config nextsection.NoNewLine "wow2 for me" "for me$"
+git-repo-config nextSection.NoNewLine "wow2 for me" "for me$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -176,18 +182,18 @@ EOF
test_expect_success 'multivar' 'cmp .git/config expect'
test_expect_success 'non-match' \
- 'git-repo-config --get nextsection.nonewline !for'
+ 'git-repo-config --get nextSection.nonewline !for'
test_expect_success 'non-match value' \
- 'test wow = $(git-repo-config --get nextsection.nonewline !for)'
+ 'test wow = $(git-repo-config --get nextSection.nonewline !for)'
test_expect_failure 'ambiguous get' \
- 'git-repo-config --get nextsection.nonewline'
+ 'git-repo-config --get nextSection.nonewline'
test_expect_success 'get multivar' \
- 'git-repo-config --get-all nextsection.nonewline'
+ 'git-repo-config --get-all nextSection.nonewline'
-git-repo-config nextsection.nonewline "wow3" "wow$"
+git-repo-config nextSection.nonewline "wow3" "wow$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -202,15 +208,15 @@ EOF
test_expect_success 'multivar replace' 'cmp .git/config expect'
-test_expect_failure 'ambiguous value' 'git-repo-config nextsection.nonewline'
+test_expect_failure 'ambiguous value' 'git-repo-config nextSection.nonewline'
test_expect_failure 'ambiguous unset' \
- 'git-repo-config --unset nextsection.nonewline'
+ 'git-repo-config --unset nextSection.nonewline'
test_expect_failure 'invalid unset' \
- 'git-repo-config --unset somesection.nonewline'
+ 'git-repo-config --unset someSection.nonewline'
-git-repo-config --unset nextsection.nonewline "wow3$"
+git-repo-config --unset nextSection.nonewline "wow3$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -249,7 +255,7 @@ test_expect_success 'hierarchical sectio
cat > expect << EOF
beta.noindent=sillyValue
-nextsection.nonewline=wow2 for me
+nextSection.nonewline=wow2 for me
123456.a123=987
1.2.3.alpha=beta
EOF
@@ -259,7 +265,7 @@ test_expect_success 'working --list' \
cat > expect << EOF
beta.noindent sillyValue
-nextsection.nonewline wow2 for me
+nextSection.nonewline wow2 for me
EOF
test_expect_success '--get-regexp' \
^ permalink raw reply related
* [PATCH 0/2] Support for "set -e" in cogito script, and assertion in rewritehist
From: Yann Dirson @ 2006-05-09 22:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
The first patch is an updated version of the one posted on Apr 17th, which makes
cg-Xlib compatible with "set -e" for safer scripts, and converts cg-admin-rewritehist
to "set -e" mode. The second ones makes the latter robust on one backquoted command,
for which "set -e" is not sufficient. Let the devil bring shell programming into hell,
asap.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH 2/2] Catch history inconsistency in cg-admin-rewritehist.
From: Yann Dirson @ 2006-05-09 22:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060509222738.20814.57282.stgit@gandelf.nowhere.earth>
This assertion is triggered by a bug in "cg-object-id -p", which
ignores grafts, when we attempt to rewrite a grafted commit whose
original parent does not get rewritten.
Dying here prevents to leave the user with a corrupted rewriten history.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
cg-admin-rewritehist | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 958a8ab..8dd33f2 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -218,9 +218,13 @@ while read commit; do
parentstr=
for parent in $(cg-object-id -p $commit); do
- for reparent in $(cat ../map/$parent); do
- parentstr="$parentstr -p $reparent"
- done
+ if [ -r "../map/$parent" ]; then
+ for reparent in $(cat "../map/$parent"); do
+ parentstr="$parentstr -p $reparent"
+ done
+ else
+ die "assertion failed: parent $parent for commit $commit not found in rewritten ones"
+ fi
done
if [ "$filter_parent" ]; then
parentstr="$(echo "$parentstr" | eval "$filter_parent")"
^ permalink raw reply related
* [PATCH 1/2] Suppress use of unsafe idiomatic use of && in cg-Xlib
From: Yann Dirson @ 2006-05-09 22:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060509222738.20814.57282.stgit@gandelf.nowhere.earth>
This is a necessary step to make any cogito script "set -e"-safe.
Also fixes similar issues in cg-admin-rewritehist and turn "set -e" on
there.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
cg-Xlib | 82 ++++++++++++++++++++++++++------------------------
cg-admin-rewritehist | 8 +++--
2 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 31f93d2..ff2b895 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -26,7 +26,7 @@ warn()
fi
echo "Warning: $@" >&2
- [ "$beep" ] && echo -ne "\a" >&2
+ [ -z "$beep" ] || echo -ne "\a" >&2
}
die()
@@ -177,7 +177,7 @@ showdate()
{
local secs=$1 tzhours=${2:0:3} tzmins=${2:0:1}${2:3} format="$3"
# bash doesn't like leading zeros
- [ "${tzhours:1:1}" = 0 ] && tzhours=${2:0:1}${2:2:1}
+ [ "${tzhours:1:1}" != 0 ] || tzhours=${2:0:1}${2:2:1}
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
[ "$format" ] || format="+%a, %d %b %Y %H:%M:%S $2"
if [ "$has_gnudate" ]; then
@@ -221,7 +221,7 @@ colorify_diffcolors="$colorify_diffcolor
colorify_setup()
{
local C="$1"
- [ -n "$CG_COLORS" ] && C="$C:$CG_COLORS"
+ [ -z "$CG_COLORS" ] || C="$C:$CG_COLORS"
C=${C//=/=\'$'\e'[}
C=col${C//:/m\'; col}m\'
@@ -261,7 +261,7 @@ column_width()
done | sort -nr | head -n 1 |
(
read maxlen;
- [ ${maxlen:-0} -gt $maxwidth ] && maxlen=$maxwidth;
+ [ ${maxlen:-0} -le $maxwidth ] || maxlen=$maxwidth;
echo ${maxlen:-0}
)
}
@@ -283,7 +283,7 @@ columns_print()
else
fmt="$fmt%-${width}s"
fi
- [ "$tab" ] && fmt="$fmt\t";
+ [ -z "$tab" ] || fmt="$fmt\t";
done
printf "$fmt\n" "${cols[@]}"
}
@@ -321,7 +321,7 @@ pick_id()
'
LANG=C LC_ALL=C sed -ne "$pick_id_script"
# Ensure non-empty id name.
- echo "[ -z \"\$GIT_${uid}_NAME\" ] && export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
+ echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
}
pick_author()
@@ -355,16 +355,16 @@ while IFS= read -r inp; do
done
path[${#path[@]}]="$inp"
for (( i=0; $i < ${#path[@]}; i++ )); do
- [ "${path[$i]}" = "." ] && continue
+ [ "${path[$i]}" != "." ] || continue
if [ "${path[$i]}" = ".." ]; then
- [ "${#path2[@]}" -gt 0 ] && unset path2[$((${#path2[@]} - 1))]
+ [ "${#path2[@]}" -le 0 ] || unset path2[$((${#path2[@]} - 1))]
continue
fi
path2[${#path2[@]}]="${path[$i]}"
done
for (( i=0; $i < ${#path2[@]}; i++ )); do
echo -n "${path2[$i]}"
- [ $i -lt $((${#path2[@]} - 1)) ] && echo -n /
+ [ $i -ge $((${#path2[@]} - 1)) ] || echo -n /
done
echo
done
@@ -400,7 +400,7 @@ # only the dirname/ will be
# EXTRAEXCLUDE: extra exclude pattern
list_untracked_files()
{
- [ "$_git_no_wc" ] && die "INTERNAL ERROR: list_untracked_files() outside a working copy"
+ [ -z "$_git_no_wc" ] || die "INTERNAL ERROR: list_untracked_files() outside a working copy"
excludeflag="$1"; shift
squashflag="$1"; shift
EXCLUDE=()
@@ -443,7 +443,7 @@ list_untracked_files()
fi
fi
local listdirs=
- [ "$squashflag" = "squashdirs" ] && listdirs=--directory
+ [ "$squashflag" != "squashdirs" ] || listdirs=--directory
git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
}
@@ -512,8 +512,8 @@ editor()
actionkey="$1"; shift
${EDITOR:-vi} "$LOGMSG2"
- [ "$force" ] && return 0
- [ "$LOGMSG2" -nt "$LOGMSG" ] && return 0
+ [ -z "$force" ] || return 0
+ [ "$LOGMSG" -nt "$LOGMSG2" ] || return 0
echo "Log message unchanged or not specified" >&2
while true; do
@@ -538,7 +538,7 @@ # the working copy (if ROLLBACK_BOOL) an
# Returns false in case of local modifications (but only if ROLLBACK_ROLL).
tree_timewarp()
{
- [ "$_git_no_wc" ] && die "INTERNAL ERROR: tree_timewarp() outside a working copy"
+ [ -z "$_git_no_wc" ] || die "INTERNAL ERROR: tree_timewarp() outside a working copy"
local no_head_update=
if [ "$1" = "--no-head-update" ]; then
no_head_update=1
@@ -550,14 +550,14 @@ tree_timewarp()
local branch="$1"; shift
local localmods=0
- [ -s "$_git/merging" ] && die "merge in progress - cancel it by cg-reset first"
+ [ ! -s "$_git/merging" ] || die "merge in progress - cancel it by cg-reset first"
if [ -n "$rollback" ]; then
local patchfile="$(mktemp -t gituncommit.XXXXXX)"
cg-diff -r "$base" >"$patchfile"
- [ -s "$patchfile" ] &&
+ [ ! -s "$patchfile" ] ||
warn "uncommitted local changes, trying to bring them $dirstr"
- [ -s "$patchfile" ] && localmods=1
+ [ ! -s "$patchfile" ] || localmods=1
git-read-tree -m "$branch" || die "$branch: bad commit"
[ "$no_head_update" ] || git-update-ref HEAD "$branch" || :
@@ -589,9 +589,9 @@ conservative_merge_base()
_cg_base_conservative=
for (( safecounter=0; $safecounter < 1000; safecounter++ )) ; do
baselist=($(git-merge-base --all "${baselist[@]}")) || return 1
- [ "${#baselist[@]}" -le "1" ] && break
+ [ "${#baselist[@]}" -gt "1" ] || break
done
- [ $safecounter -gt 0 ] && _cg_base_conservative=$safecounter
+ [ $safecounter -le 0 ] || _cg_base_conservative=$safecounter
_cg_baselist=("${baselist[@]}")
}
@@ -603,7 +603,7 @@ # Never use it. If you do, accompany it
# it safe to use it.
update_index()
{
- [ "$_git_no_wc" ] && die "INTERNAL ERROR: update_index() outside a working copy"
+ [ -z "$_git_no_wc" ] || die "INTERNAL ERROR: update_index() outside a working copy"
git-update-index --refresh | sed 's/needs update$/locally modified/'
}
@@ -620,14 +620,14 @@ is_same_repo()
# second side...
if [ ! -w "$dir1" -o ! -w "$dir2" ]; then
# ...except in readonly setups.
- [ "$(readlink -f "$dir1")" = "$(readlink -f "$dir2")" ] && diff=0
+ [ "$(readlink -f "$dir1")" != "$(readlink -f "$dir2")" ] || diff=0
else
n=$$
while [ -e "$dir1/.,,lnstest-$n" -o -e "$dir2/.,,lnstest-$n" ]; do
n=$((n+1))
done
touch "$dir1/.,,lnstest-$n"
- [ -e "$dir2/.,,lnstest-$n" ] && diff=0
+ [ ! -e "$dir2/.,,lnstest-$n" ] || diff=0
rm "$dir1/.,,lnstest-$n"
fi
return $diff
@@ -679,7 +679,7 @@ deprecated_alias()
cmd="${0##*/}"
propername="$1"; shift
for a in "$@"; do
- [ "$cmd" = "$a" ] && \
+ [ "$cmd" != "$a" ] || \
warn "'$a' is a deprecated alias, please use '$propername' instead"
done
}
@@ -709,7 +709,7 @@ print_help()
echo
echo "Options:"
maxlen="$(sed -n 's/^# \(-.*\)::[^A-Za-z0-9].*/\1/p' < "$_cg_cmd" | column_width)"
- [ $maxlen -lt 11 ] && maxlen=11 # --long-help
+ [ $maxlen -ge 11 ] || maxlen=11 # --long-help
_cg_fmt=" %-20s %s\n"
sed -n 's/# \(-.*\)::[^A-Za-z0-9]\(.*\)/\1\n\2/p' < "$_cg_cmd" | while read line; do
case "$line" in
@@ -727,7 +727,7 @@ print_help()
}
for option in "$@"; do
- [ x"$option" = x-- ] && break
+ [ x"$option" != x-- ] || break
if [ x"$option" = x"-h" ] || [ x"$option" = x"--help" ]; then
print_help short "${_cg_cmd##cg-}"
elif [ x"$option" = x"--long-help" ]; then
@@ -777,8 +777,8 @@ optparse()
--) optshift; return 1 ;;
-*) return 0 ;;
*) while (( ++ARGPOS < ${#ARGS[@]} )); do
- [[ "${ARGS[$ARGPOS]}" == -- ]] && return 1
- [[ "${ARGS[$ARGPOS]}" == -* ]] && return 0
+ [[ "${ARGS[$ARGPOS]}" != -- ]] || return 1
+ [[ "${ARGS[$ARGPOS]}" != -* ]] || return 0
done;
return 1 ;;
esac
@@ -786,22 +786,26 @@ optparse()
CUROPT="${ARGS[$ARGPOS]}"
local match="${1%=}" minmatch="${2:-1}" opt="$CUROPT" o="$CUROPT" val
- [[ "$1" == *= ]] && val="$match"
+ [[ "$1" != *= ]] || val="$match"
case "$match" in
--*)
- [ "$val" ] && o="${o%%=*}"
+ [ -z "$val" ] || o="${o%%=*}"
[ ${#o} -ge $((2 + $minmatch)) -a \
"${match:0:${#o}}" = "$o" ] || return 1
- [[ -n "$val" && "$opt" == *=?* ]] \
- && ARGS[$ARGPOS]="${opt#*=}" \
- || optshift "$val" ;;
+ if [[ -n "$val" && "$opt" == *=?* ]]; then
+ ARGS[$ARGPOS]="${opt#*=}"
+ else
+ optshift "$val"
+ fi ;;
-?)
[[ "$o" == $match* ]] || return 1
[[ "$o" != -?-* || -n "$val" ]] || optfail
ARGS[$ARGPOS]=${o#$match}
- [ -n "${ARGS[$ARGPOS]}" ] \
- && { [ -n "$val" ] || ARGS[$ARGPOS]=-"${ARGS[$ARGPOS]}"; } \
- || optshift "$val" ;;
+ if [ -n "${ARGS[$ARGPOS]}" ]; then
+ [ -n "$val" ] || ARGS[$ARGPOS]=-"${ARGS[$ARGPOS]}";
+ else
+ optshift "$val"
+ fi ;;
*)
die "optparse cannot handle $1" ;;
esac
@@ -846,7 +850,7 @@ check_tool()
fi
done
IFS="$save_IFS"
- [ "$hasname" ] && break
+ [ -z "$hasname" ] || break
done 2>/dev/null
}
@@ -882,7 +886,7 @@ if [ ! "$_git_repo_unneeded" ]; then
_git=.
export GIT_DIR=.
fi
- [ "$GIT_DIR" = . ] && _git_no_wc=1
+ [ "$GIT_DIR" != . ] || _git_no_wc=1
if [ ! -d "$_git" ]; then
echo "There is no GIT repository here ($_git not found)" >&2
exit 1
@@ -894,8 +898,8 @@ if [ ! "$_git_repo_unneeded" ]; then
exit 1
fi
_git_head=master
- [ -s "$_git/HEAD" ] && { _git_head="$(git-symbolic-ref HEAD)"; _git_head="${_git_head#refs/heads/}"; }
- [ -s "$_git/head-name" ] && _git_head="$(cat "$_git/head-name")"
+ [ ! -s "$_git/HEAD" ] || { _git_head="$(git-symbolic-ref HEAD)"; _git_head="${_git_head#refs/heads/}"; }
+ [ ! -s "$_git/head-name" ] || _git_head="$(cat "$_git/head-name")"
fi
# Check if the script requires to be called from the workdir root.
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 9fa4c2a..958a8ab 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -133,6 +133,8 @@ # as their parents instead of the merge
# Testsuite: TODO
+set -e
+
USAGE="cg-admin-rewritehist [-d TEMPDIR] [-r STARTREV]... [FILTERS] DESTBRANCH"
_git_wc_unneeded=1
_git_requires_root=1
@@ -169,10 +171,10 @@ done
dstbranch="${ARGS[0]}"
[ -n "$dstbranch" ] || die "missing branch name"
-[ -s "$_git/refs/heads/$dstbranch" ] && die "branch $dstbranch already exists"
-[ -s "$_git/branches/$dstbranch" ] && die "branch $dstbranch is already a remote branch"
+[ ! -s "$_git/refs/heads/$dstbranch" ] || die "branch $dstbranch already exists"
+[ ! -s "$_git/branches/$dstbranch" ] || die "branch $dstbranch is already a remote branch"
-[ -e "$tempdir" ] && die "$tempdir already exists, please remove it"
+[ ! -e "$tempdir" ] || die "$tempdir already exists, please remove it"
mkdir -p "$tempdir/t"
cd "$tempdir/t"
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-09 22:42 UTC (permalink / raw)
To: sean; +Cc: torvalds, junkio, Johannes.Schindelin, git
In-Reply-To: <BAYC1-PASMTP04D623089E043F1C792A37AEA90@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> The syntax is:
>
> [<random string>]
Does this mean you can have anything other than LF and ']'?
> Here's how your example would look in this style:
>
> [email.torvalds@osdl.org]
> name = Linus Torvalds
How does a program (not a script, but git_config() users) get
that value and parse it?
^ permalink raw reply
* [PATCH] Fix cg-object-id to lookup parents in the Right Way
From: Yann Dirson @ 2006-05-09 22:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This causes grafts to not be ignored any more, allowing
cg-admin-rewritehist to work as expected on grafted commits.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
cg-object-id | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-object-id b/cg-object-id
index ee23082..71c72e5 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -147,7 +147,7 @@ fi
if [ "$show_parent" ]; then
- git-cat-file commit "$normid" | sed -ne 's/^parent //p;/^$/q'
+ git-rev-list --parents -n 1 "$normid"| tr ' ' '\n'|tail +2
exit 0
fi
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, junkio, Johannes.Schindelin, git
In-Reply-To: <7vu07y252m.fsf@assigned-by-dhcp.cox.net>
On Tue, 09 May 2006 15:42:25 -0700
Junio C Hamano <junkio@cox.net> wrote:
> sean <seanlkml@sympatico.ca> writes:
>
> > The syntax is:
> >
> > [<random string>]
>
> Does this mean you can have anything other than LF and ']'?
Anything but LF; how's this for ugly:
["hello Worl\]d \\backslash]
> > Here's how your example would look in this style:
> >
> > [email.torvalds@osdl.org]
> > name = Linus Torvalds
>
> How does a program (not a script, but git_config() users) get
> that value and parse it?
The same way they do now. For instance git-repo-config processes
the config file using the same get_config() + callback as usual. The
only issue is that they should no longer cast everything to lower first.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-09 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, Johannes.Schindelin, git
In-Reply-To: <20060509184519.5a707231.seanlkml@sympatico.ca>
On Tue, 9 May 2006 18:45:19 -0400
sean <seanlkml@sympatico.ca> wrote:
> > How does a program (not a script, but git_config() users) get
> > that value and parse it?
>
> The same way they do now. For instance git-repo-config processes
> the config file using the same get_config() + callback as usual. The
> only issue is that they should no longer cast everything to lower first.
Junio,
Sorry I see what you're driving at; how does a program break the section
name into it's constituent pieces. I glossed over this issue because
it's exactly the same between Linus' proposal and mine. The answer is,
they really can't, with either proposal.
All you can count on (by convention) is that there is an initial segment
that is terminated by a period; and a final segment that starts with a
period, and everything in between is an opaque unit.
section.<random string>.keyname value
Although the initial "section." isn't currently enforced (but easily
could be). Actually i didn't yank out the bit from config.c that
validates the keyname, so without an additional patch the only way
to enter the extended names is by manual editing of the .git/config.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-09 23:23 UTC (permalink / raw)
To: sean; +Cc: Junio C Hamano, torvalds, Johannes.Schindelin, git
In-Reply-To: <20060509184519.5a707231.seanlkml@sympatico.ca>
On Tue, 2006-05-09 at 18:45 -0400, sean wrote:
> On Tue, 09 May 2006 15:42:25 -0700
> Junio C Hamano <junkio@cox.net> wrote:
> > Does this mean you can have anything other than LF and ']'?
>
> Anything but LF; how's this for ugly:
>
> ["hello Worl\]d \\backslash]
Actually, LF is already handled just fine in the value part:
[proski@dv .git]$ git-repo-config s1.k1 $'v1\nv2'
[proski@dv .git]$ grep [sk]1 config
[s1]
k1 = v1\nv2
Note that quoting doesn't solve this problem (unless multi-line section
headers are allowed), but backslash escaping does.
But I guess everybody prefers quotes for their friendly look.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-10 0:17 UTC (permalink / raw)
To: sean; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <BAYC1-PASMTP04D623089E043F1C792A37AEA90@CEZ.ICE>
On Tue, 9 May 2006, sean wrote:
>
> I really tried to like your patch ;o) But it breaks the repo-config command
> line and causes mixing of some branches using old style [branch.xyz] and new
> style [branch "XYZ"] which just doesn't seem to be the right thing to do.
Well, obviously it's _simpler_ to have the machine-readable format as-is,
and say "don't try to make it human-readable". But the repo-config patch
to make it human-readable isn't that hard.
And it's _not_ that hard to make repo-config do the right thing.
Here's a pretty lightly tested patch (on top of my previous one) that does
exactly that.
(The first part just fixes an indentation bug)
Linus
---
diff --git a/config.c b/config.c
index f3b74e0..12c51b1 100644
--- a/config.c
+++ b/config.c
@@ -372,10 +372,12 @@ static int store_aux(const char* key, co
store.offset[store.seen] = ftell(config_file);
store.state = KEY_SEEN;
store.seen++;
- } else if (strrchr(key, '.') - key == store.baselen &&
+ } else {
+ if (strrchr(key, '.') - key == store.baselen &&
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
store.offset[store.seen] = ftell(config_file);
+ }
}
}
return 0;
@@ -383,8 +385,30 @@ static int store_aux(const char* key, co
static void store_write_section(int fd, const char* key)
{
+ const char *dot = strchr(key, '.');
+ int len1 = store.baselen, len2 = -1;
+
+ dot = strchr(key, '.');
+ if (dot) {
+ int dotlen = dot - key;
+ if (dotlen < len1) {
+ len2 = len1 - dotlen - 1;
+ len1 = dotlen;
+ }
+ }
+
write(fd, "[", 1);
- write(fd, key, store.baselen);
+ write(fd, key, len1);
+ if (len2 >= 0) {
+ write(fd, " \"", 2);
+ while (--len2 >= 0) {
+ unsigned char c = *++dot;
+ if (c == '"')
+ write(fd, "\\", 1);
+ write(fd, &c, 1);
+ }
+ write(fd, "\"", 1);
+ }
write(fd, "]\n", 2);
}
@@ -458,7 +482,7 @@ int git_config_set(const char* key, cons
int git_config_set_multivar(const char* key, const char* value,
const char* value_regex, int multi_replace)
{
- int i;
+ int i, dot;
int fd = -1, in_fd;
int ret;
char* config_filename = strdup(git_path("config"));
@@ -483,16 +507,23 @@ int git_config_set_multivar(const char*
* Validate the key and while at it, lower case it for matching.
*/
store.key = (char*)malloc(strlen(key)+1);
- for (i = 0; key[i]; i++)
- if (i != store.baselen &&
- ((!isalnum(key[i]) && key[i] != '.') ||
- (i == store.baselen+1 && !isalpha(key[i])))) {
- fprintf(stderr, "invalid key: %s\n", key);
- free(store.key);
- ret = 1;
- goto out_free;
- } else
- store.key[i] = tolower(key[i]);
+ dot = 0;
+ for (i = 0; key[i]; i++) {
+ unsigned char c = key[i];
+ if (c == '.')
+ dot = 1;
+ /* Leave the extended basename untouched.. */
+ if (!dot || i > store.baselen) {
+ if (!isalnum(c) || (i == store.baselen+1 && !isalpha(c))) {
+ fprintf(stderr, "invalid key: %s\n", key);
+ free(store.key);
+ ret = 1;
+ goto out_free;
+ }
+ c = tolower(c);
+ }
+ store.key[i] = c;
+ }
store.key[i] = 0;
/*
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-10 1:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605091543100.3718@g5.osdl.org>
On Tue, 9 May 2006 17:17:58 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> Here's a pretty lightly tested patch (on top of my previous one) that does
> exactly that.
This patch or something like it is needed for repo-config in order to query
the new case sensitive portion of section names. This is on top of your two
patches:
diff --git a/repo-config.c b/repo-config.c
index 63eda1b..9a9194f 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -65,11 +65,14 @@ static int show_config(const char* key_,
static int get_value(const char* key_, const char* regex_)
{
int i;
+ char *tl;
+
+ key = strdup(key_);
+ for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
+ *tl = tolower(*tl);
+ for (tl=key; *tl && *tl != '.'; ++tl)
+ *tl = tolower(*tl);
- key = malloc(strlen(key_)+1);
- for (i = 0; key_[i]; i++)
- key[i] = tolower(key_[i]);
- key[i] = 0;
if (use_key_regexp) {
key_regexp = (regex_t*)malloc(sizeof(regex_t));
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-10 1:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605091543100.3718@g5.osdl.org>
On Tue, 9 May 2006 17:17:58 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> And it's _not_ that hard to make repo-config do the right thing.
>
> Here's a pretty lightly tested patch (on top of my previous one) that does
> exactly that.
So every mutli-part section is going to be of the form:
[section "big long opaque string"]
It seems to handle everything, you have me convinced.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-10 2:08 UTC (permalink / raw)
To: sean; +Cc: junkio, Johannes.Schindelin, git
In-Reply-To: <BAYC1-PASMTP037EBB0237B35C5F92FB0BAEAE0@CEZ.ICE>
On Tue, 9 May 2006, sean wrote:
> On Tue, 9 May 2006 17:17:58 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > And it's _not_ that hard to make repo-config do the right thing.
> >
> > Here's a pretty lightly tested patch (on top of my previous one) that does
> > exactly that.
>
> So every mutli-part section is going to be of the form:
>
> [section "big long opaque string"]
That's what my stupid patch does now. It seems to work well for all cases,
but if we were to care, we could have some special heuristics for
different section names (ie "if subsection is all lower-case
alphanumerics, and the section name is one of the following, use the
old-fashioned format").
I don't see _why_ we'd ever do that, but we certainly _could_, if it were
to make more sense that way for some section name.
However, if you already use a syntax like
[section.subsection]
key = 1
and then do
git-repo-config --replace-all section.subsection.new 2
it will actually keep the old section header, so you'll end up with
[section.subsection]
key = 1
new = 2
but if you create a _new_ subsection (and since subsections are now case
sensitive, this example is a "new" subsection):
git-repo-config --replace-all section.SubSection.new 3
you will now have
[section.subsection]
key = 1
new = 2
[section "SubSection"]
new = 3
(ie notice how it did _not_ replace the old "section.subsection.new",
because of how this is a _different_ subsection due to the subsectin
rules, and notice how it will always create the new subsection with
quotes).
So you _can_ continue to use the old subsection format, and it will work
the way it always did, except for the fact that it would now be deprecated
(if there were any multi-level users, which I don't think there are), and
it is now case-sensitive (which makes sense in the new format with ""
around it, but is illogical in the old deprecated one).
> It seems to handle everything, you have me convinced.
Hey, it was fun, and the only ugly part was the write-out of the quoted
format.
And it should be perfectly easy to use. Modulo double-quotes in branch
names, you can do trivial things like
git repo-config "branch.$branchname.remote" "git://git.kernel.org/..."
and it will do the obvious thing.
My one complaint is that I think we should add an empty line for the case
where we add a new sub-section to the end of a file. That's not a new
problem, but that was really the only visually ugly part I noticed during
testing.
You _can_ be user-friendly and machine-parseable at the same time!
Linus
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-05-10 3:11 UTC (permalink / raw)
To: git
This week's "What's in" is a day early, since I do not expect to
be able to do much gitting for the rest of the week.
* The 'maint' branch has these fixes since the last announcement.
Dmitry V. Levin:
Separate object name errors from usage errors
Eric Wong:
apply: fix infinite loop with multiple patches with --index
Johannes Schindelin:
repo-config: trim white-space before comment
Junio C Hamano:
core.prefersymlinkrefs: use symlinks for .git/HEAD
repo-config: document what value_regexp does a bit more clearly.
Fix repo-config set-multivar error return path.
Documentation: {caret} fixes (git-rev-list.txt)
Linus Torvalds:
Fix "git diff --stat" with long filenames
revert/cherry-pick: use aggressive merge.
Martin Waitz:
clone: keep --reference even with -l -s
repack: honor -d even when no new pack was created
Matthias Lederhofer:
core-tutorial.txt: escape asterisk
Pavel Roskin:
Release config lock if the regex is invalid
Sean Estabrooks:
Fix for config file section parsing.
Yakov Lerner:
read-cache.c: use xcalloc() not calloc()
* The 'master' branch has these since the last announcement, in
addition to the above. I've flushed topics that have been
cooked in "next" long enough and hadn't given me problems.
Eric Wong:
git-svn: documentation updates
git-svn 1.0.0
Johannes Schindelin:
builtin-push: --all and --tags _are_ explicit refspecs
Fix users of prefix_path() to free() only when necessary
Fix users of prefix_path() to free() only when necessary
Junio C Hamano:
get_sha1(): :path and :[0-3]:path to extract from index.
Makefile: do not link rev-list any specially.
delta: stricter constness
pack-object: squelch eye-candy on non-tty
binary patch.
binary diff: further updates.
update-index --unresolve: work from a subdirectory.
checkout-index: plug memory leak from prefix_path()
update-index: plug memory leak from prefix_path()
update-index --again
update-index --again: take optional pathspecs
binary diff and apply: testsuite.
repo-config: document what value_regexp does a bit more clearly.
get_sha1() - fix infinite loop on nonexistent stage.
Teach git-clean optional <paths>... parameters.
checkout: use --aggressive when running a 3-way merge (-m).
Martin Waitz:
Transitively read alternatives
test case for transitive info/alternates
clone: don't clone the info/alternates file
Nicolas Pitre:
split the diff-delta interface
use delta index data when finding best delta matches
replace adler32 with Rabin's polynomial in diff-delta
tiny optimization to diff-delta
improve diff-delta with sparse and/or repetitive data
improve base85 generated assembly code
Peter Hagervall:
Sparse fix for builtin-diff
Sean Estabrooks:
Several trivial documentation touch ups.
Fix up docs where "--" isn't displayed correctly.
Update git-unpack-objects documentation.
Clarify git-cherry documentation.
Another config file parsing fix.
t1300-repo-config: two new config parsing tests.
* The 'next' branch, in addition, has these.
- cvsserver and cvsexportcommit updates (Martin Langhoff and Martyn Smith)
This is a new merge but not very new code. Martin may want
to comment on how ready they are.
- built-in fmt-patch (Johannes Schindelin)
I think this is ready, even though it does not have some
things we have in format-patch (i.e. --attach, --signoff,
--check). If anybody deeply cares please stop me soon or
better yet enhance with your patches; otherwise I would like
to push this out to "master" sometime next week to supersede
the git-format-patch script.
- built-in grep (me)
I think this is also ready, even though it robs users from
having funky "grep" on their $PATH and invoke it. Compared
to GNU grep, it lacks -P (pcre), -Z (NUL-terminated output),
-q (totally quiet), -z (NUL-terminated input), but all the
commonly used ones including -f (from file), -F (fixed), -w
(word regexp), -l/-L (files with/without match) and -n (line
number) are implemented. The same "stop me or else" comment
applies.
- use config "remote.$name.url" and friends for fetch/pull
(Johannes Schindelin)
I think this itself is ready; the only reason I do not plan
to do so this week is to wait until the new config format
discussion settles, at which time we would need to adjust
this to the new format.
- cache-tree (me)
This has been stalled; I would want to redo it without using
out-of-index data structure, but that would need the
following steps, and lately I have too many distractions to
concentrate on them.
- review existing index/working-tree/tree walkers.
- prepare a merge-tree style path walker that walks index,
working tree, and zero or more trees in parallel. This
would probably have an interator interface to return list
of either tree or blob <mode,sha1> to the caller. Because
index does not currently have tree entries, a "not
up-to-date" tree entry would be returned from the index
part of the walker if I base this change on "master". I
might base this on "next" and use information from
cache-tree.
- using the parallel path walker, revamp diff-cache (both
cached and non cached) to work out kinks to the walker API
and see how well it performs. If I base the work on
"next", the code should be able to skip unchanged
subtrees.
- revamp diff-files (walks index and working tree), although
this will not get any benefit from having tree entries in
the index.
- revamp read-tree (all forms).
- if I based the work on "next", rip out the cache-tree
dependency and make the walker return "not up-to-date"
tree entries for index.
- revamp update-index, apply, and write-tree to have tree
entries in the index. This probably involves revamping
read-cache interface to update the index file contents.
- review read-tree to make sure it correctly maintains the
tree entries in the cache.
* The 'pu' branch, in addition, has the proposed configuration
file syntax updates from Linus with a patch from Sean. I
haven't had time to really look at it, and it seems to fail a
test right now, but I left it as is. This is merged from a
throw-away topic branch for now, but when I resume to gitting
sometime next week I am hoping we have something ready to be
tested (iow, "next" material) based on the list concensus. At
that time we might probably do backport to cope with the
syntax updates for 1.3.X release and perhaps 1.2.X series just
for fun.
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-05-10 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viroezi8s.fsf@assigned-by-dhcp.cox.net>
On Tue, 9 May 2006, Junio C Hamano wrote:
>
> * The 'pu' branch, in addition, has the proposed configuration
> file syntax updates from Linus with a patch from Sean. I
> haven't had time to really look at it, and it seems to fail a
> test right now, but I left it as is.
The reason for the failure is the new syntax for multi-section variables.
This patch makes the test succed, by changing
[1.2.3]
into
[1 "2.3"]
which is how subsections now end up being shown (you can still _parse_
them the old way, but they get created the new way, which is why the test
fails)
That's a very strange test-case, and on the face of it the new syntax
looks "worse", but if you were to be realistic about this kind of section
name, it would more likely explain _what_ that number sequence means, so
you would more realistically name your sections something like
[version "1.2.3"]
which I think everybody agrees looks nicer than
[version.1.2.3]
or similar.
Of course, I don't think we currently actually have any _users_ of any
multi-level section names at all, so this is all entirely theoretical
until we start actually using them.
Linus
---
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7090ea9..54b3394 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -241,7 +241,7 @@ # empty line
NoNewLine = wow2 for me
[123456]
a123 = 987
-[1.2.3]
+[1 "2.3"]
alpha = beta
EOF
^ permalink raw reply related
* Re: What's in git.git
From: Linus Torvalds @ 2006-05-10 4:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viroezi8s.fsf@assigned-by-dhcp.cox.net>
On Tue, 9 May 2006, Junio C Hamano wrote:
>
> Junio C Hamano:
> binary patch.
> binary diff: further updates.
Btw, am I just smoking stuff, or is this going to be fundamentally
problematic for "git-apply -R" if we ever want to support that?
I think the new binary diff is non-reversible. That's ok right now, since
we don't actually support patching in reverse (if you want to get the
reverse patch, you need to _diff_ it in reverse and then patch it that
way).
But at least in theory we might well want to do "-R" eventually.
Hmm? Or did I just mis-understand the format?
Linus
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-05-10 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605092117240.3718@g5.osdl.org>
On Tue, 9 May 2006, Linus Torvalds wrote:
>
> I think the new binary diff is non-reversible. That's ok right now, since
> we don't actually support patching in reverse (if you want to get the
> reverse patch, you need to _diff_ it in reverse and then patch it that
> way).
Btw, I don't actually know why we don't support "-R". The way git-apply is
written, it should be totally trivial (just switch old/new around for data
and line numbers - since it doesn't actually apply the patch directly line
by line or anything like that) for a normal patch.
So if I read the binary patch right, the lack of "-R" went from "silly
oversight" to "uhhuh, I don't think the patch format supports it".
Maybe it's not a big deal.
Linus
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-05-10 4:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viroezi8s.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> This week's "What's in" is a day early, since I do not expect to
Junio> be able to do much gitting for the rest of the week.
I just got this with the latest, on the git archive, using git-repack -a:
Generating pack...
Done counting 19151 objects.
Deltifying 19151 objects.
Segmentation fault (core dumped)
This is on OpenBSD. Is there a secret sabotage afoot? This is repeatable.
Is there anything I can try differently?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-05-10 4:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605092117240.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 9 May 2006, Junio C Hamano wrote:
>>
>> Junio C Hamano:
>> binary patch.
>> binary diff: further updates.
>
> Btw, am I just smoking stuff, or is this going to be fundamentally
> problematic for "git-apply -R" if we ever want to support that?
It is problematic but not more than the current index + "Binary
files differ" output. If you have both pre and postimage then
you do not need the binary data.
The forward application is done assuming you have the preimage
(but not necessarily postimage), and when you do not have
postimage the binary data is used. When going reverse we should
assume you have the postimage (but not necessarily preimage),
but the pack-object format xdelta is not reversible so if you do
not have preimage that matches the index, with the current
output format you lose.
If we care enough, we could add a reverse delta from postimage
to preimage to the output, but I am not sure if it is worth it.
> But at least in theory we might well want to do "-R" eventually.
Yes, but even without binary, -R has a funny implication when
copy-edit patch is involved. What if a patch copy-edits to
create a new file B based on old A, and also modifies A
in-place, and somehow the postimages of A and B you already have
are not consistent with what that patch does? Application with
-R would produce two versions of A and you would get a conflict.
I guess showing a combined diff would be a helpful way to
resolve that ;-).
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-05-10 4:45 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, Nicolas Pitre, Git Mailing List
In-Reply-To: <864pzyh4x0.fsf@blue.stonehenge.com>
On Tue, 9 May 2006, Randal L. Schwartz wrote:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> This week's "What's in" is a day early, since I do not expect to
> Junio> be able to do much gitting for the rest of the week.
>
> I just got this with the latest, on the git archive, using git-repack -a:
>
> Generating pack...
> Done counting 19151 objects.
> Deltifying 19151 objects.
> Segmentation fault (core dumped)
>
> This is on OpenBSD. Is there a secret sabotage afoot? This is repeatable.
> Is there anything I can try differently?
Can you see what the traceback is with gdb?
I'd suspect the deltifier changes, the rabin hash in particular. The core
file traceback would probably point right at the culprit if so.
I don't see the problem myself, but if it's an access just past the end of
an array or something, it would depend on exactly what the delta pattern
is (which, without the "-f" flag, in turn depends on what your previous
packs looked like) and also on the allocation strategy (which migth
explain why it shows on OpenBSD but Linux people hadn't seen it).
Linus
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-05-10 4:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5emze3h.fsf@assigned-by-dhcp.cox.net>
On Tue, 9 May 2006, Junio C Hamano wrote:
>
> It is problematic but not more than the current index + "Binary
> files differ" output. If you have both pre and postimage then
> you do not need the binary data.
Fair enough.
> > But at least in theory we might well want to do "-R" eventually.
>
> Yes, but even without binary, -R has a funny implication when
> copy-edit patch is involved. What if a patch copy-edits to
> create a new file B based on old A, and also modifies A
> in-place, and somehow the postimages of A and B you already have
> are not consistent with what that patch does?
Yeah, that could get exciting ;)
Linus
^ 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