* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-02 23:05 UTC (permalink / raw)
To: David Kastrup; +Cc: Robert Schiele, git
In-Reply-To: <85vebxy47e.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Robert Schiele <rschiele@gmail.com> writes:
> ...
>> Thus we have to decide whether we want some textbook example code
>> and thus break this platform completely or whether we want to fix
>> the issues you have listed and thus have a more portable
>> application.
>
> The "issues" are with Solaris, apparently. There is always a price
> for portability. If Solaris users can fix their problems with a
> global search and replace of the first line in *.sh, the question is
> whether it is worth the hassle of having unreadable but "portable"
> code. After all, it has to be read also by humans.
I am in the camp of avoiding "it is even in POSIX so it's your
fault if your shell does not support it". We do not take POSIX
too seriously in that way, although we do say "let's not use it,
it is not even in POSIX". In other words, I've been trying to
be, and as a result of that we are, fairly conservative.
However, there is a line we need to draw when bending bacwards
for compatibility, and I think a system that does not have a
working command substitution $( ... ) is on the other side of
that line.
^ permalink raw reply
* Re: [PATCH] Fix documentation for core.gitproxy to reflect code
From: Junio C Hamano @ 2007-08-02 23:07 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20708021545s54bc226ds4c1c4589c6617c00@mail.gmail.com>
Thanks. Much better and to the point.
I really appreciate your extra effort.
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Martin Langhoff @ 2007-08-02 23:08 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Guilhem Bonnefille, git, users
In-Reply-To: <46B1F96B.7050107@alum.mit.edu>
On 8/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> cvsps is not a conversion tool at all, though it is used by other
> conversion tools to generate the changesets. It appears (I hope I am
> not misinterpreting things) to emphasize speed and incremental
> operation, for example attempting to make changesets consistent from one
> run to the next, even if the CVS repository has been changed prudently
> between runs. cvsps does not appear to attempt to create atomic branch
> and tag creation commits or handle CVS's special vendorbranch behavior.
> cvsps operates via the CVS protocol; you don't need filesystem access
> to the CVS repository.
100% in agreement. And though I can't claim to be happy with cvsps, in
many scenarios it is mighty useful, in spite of its significant warts.
The "does incrementals" is hugely important these days, as lots of
people use git to run "vendor branches" of upstream projects that use
CVS.
To me, that's *the* killer-app feature of git. Of course, others see
different aspects of git as their deal-maker. But I'm sure I'm not
alone on this. Surely enough, others have written git-svn which
accomplishes this and more for those tracking SVN upstreams.
Is there any way we can run tweak cvs2svn to run incrementals, even if
not as fast as cvsps/git-cvsimport? The "do it remotely" part can be
worked around in most cases.
cheers,
martin
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7vwswdsfjp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> However, there is a line we need to draw when bending bacwards for
> compatibility, and I think a system that does not have a working
> command substitution $( ... ) is on the other side of that line.
Not an issue. But apparently, ${parameter#word} is for Solaris. I'd
still like to get confirmation that it is indeed /bin/sh, but if it
is, the current code is not good for Solaris.
So the line of compatibility is much more interesting for this one.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 23:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Steffen Prohaska, git, users
In-Reply-To: <alpine.LFD.0.999.0708021340450.8184@woody.linux-foundation.org>
Linus Torvalds wrote:
> On Thu, 2 Aug 2007, Steffen Prohaska wrote:
>> Right now, I'd prefer the import by parsecvs because of the
>> simpler history. However, I don't know if I loose history
>> information by doing so. I'd start by a run of cvs2svn to validate
>> the overall structure of the CVS repository.
>
> Well, once imported, you could just go through the branches and tags, and
> just delete the ones you consider uninteresting, and then do a "git gc".
>
> You'd want to re-pack after a fast-import anyway (regardless of the source
> of the fast-import input), so maybe cvs2svn ends up giving you a bit
> unnecessary info, but it should be easy enough to get rid of
> after-the-fact.
The real goal is to get cvs2svn to include the useful information and
exclude the rest. :-)
I definitely want to address the problem of the helper branches used to
create tags. This problem has has two aspects:
1. The helper branches should be deleted after the tag has been defined.
I simply couldn't figure out how to do this using git-fast-import, and
git-fast-import complained when I tried to use a branch called
"TAG_FIXUP" without the "refs/head/" prefix.
2. The helper branch is not needed at all if an existing revision has
exactly the same contents as needed on the tag. This requires cvs2svn
to keep a record of which files exist in the complete file tree on every
branch at every revision (which it can already do, though it is
expensive), and also to give it the smarts to choose the optimal tag
point (which it already does, except that it currently doesn't penalize
sources that require files to be deleted before making the tag).
If the problem is lots of seemingly-unnecessary merges involving a
vendor branch, then it is time for me or some other volunteer to add the
optimization of allowing branches to be grafted from the vendor branch
to trunk. I know of the problem and have a good idea how to implement
it; it is just a matter of finding the time to get it done.
If the problem is unlabeled branches that can't be excluded (because
other branches or tags depend on them), then the real problem is that it
is not known which unlabeled branches in individual files correspond to
the same project-wide conceptual branch. I have considered two
possibilities to improve this situation:
1. Allow unlabeled -- indeed any -- branches to be discarded even if
other branches or tags depend on them. This could be done by
incorporating the content of the source revision (i.e., the revision on
the unlabeled branch that is going to be discarded) into the zeroth
revision of the daughter branch, then grafting the daughter onto the
branch from which the unlabeled branch sprouted.
2. Rename the unlabeled branches by figuring out which unlabeled branch
in fileA corresponds to which unlabeled branch in fileB, fileC, etc.
This would involve a tricky bit of matching file-wise dependency trees
onto one another to unify unlabeled branch labels, keeping in mind that:
- The trees have other differences as well.
- The unlabeled branch does not necessarily occur in every file.
- There may be multiple unlabeled branches per file.
Michael
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7vwswdsfjp.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On Thu, Aug 02, 2007 at 04:05:46PM -0700, Junio C Hamano wrote:
> However, there is a line we need to draw when bending bacwards
> for compatibility, and I think a system that does not have a
> working command substitution $( ... ) is on the other side of
> that line.
Well, I have now a patch ready for submission that would replace all
occurences of ${PARAMETER#WORD}, ${PARAMETER%WORD}, and $(( EXPRESSION )).
But if you say that you won't accept replacement of $( ... ) then this is not
worth the effort since this one isn't accepted as well.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 23:27 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85vebxy47e.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
On Fri, Aug 03, 2007 at 12:14:13AM +0200, David Kastrup wrote:
> A non-working rebase would seem rather tough.
It depends on how you work. I for example always just push any change to a
linux machine where I do the actual integration work. Thus I don't need much
commands on the Solaris machine.
> The "issues" are with Solaris, apparently. There is always a price
> for portability. If Solaris users can fix their problems with a
> global search and replace of the first line in *.sh, the question is
> whether it is worth the hassle of having unreadable but "portable"
> code. After all, it has to be read also by humans.
Ok, but then we needed an infrastructure to replace the shell with a
configuration parameter.
> You are missing the line
> $ echo $0
> which is probably the most interesting one... we don't need to be
> compatible with everything having a "$ " prompt, just with everything
> called "/bin/sh".
Your way of telling people that you are considering everybody besides you to
be a moron is somehow insulting. You might wish to change that.
Sure I tested in on /bin/sh!
> See the rationale in my recently posted patch for implementing
> EDITOR/VISUAL support. One needs to shell-quote stuff properly, and
> the shell is better at shell-quote magic than C is.
Ok, will look up that later.
> If you prepare a patch replacing all existing ${parameter#word} uses
> and get it accepted, I will not push for inclusion of my cleanup.
>
> But you _really_ should go for it _now_.
I have it ready now. Just waiting for the answer of Junio to my last mail.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 23:32 UTC (permalink / raw)
To: Robert Schiele; +Cc: Junio C Hamano, git
In-Reply-To: <20070802232126.GU29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> On Thu, Aug 02, 2007 at 04:05:46PM -0700, Junio C Hamano wrote:
>> However, there is a line we need to draw when bending bacwards
>> for compatibility, and I think a system that does not have a
>> working command substitution $( ... ) is on the other side of
>> that line.
>
> Well, I have now a patch ready for submission that would replace all
> occurences of ${PARAMETER#WORD}, ${PARAMETER%WORD}, and $((
> EXPRESSION )). But if you say that you won't accept replacement of
> $( ... ) then this is not worth the effort since this one isn't
> accepted as well.
I absolutely can't understand your claim that most things work for
you, then. Are you _really_, _really_ sure you are talking about
/bin/sh here?
Look:
-*- mode: grep; default-directory: "/home/tmp/git/" -*-
Grep started at Fri Aug 3 01:29:41
fgrep -nH -e '$(' *.sh
check-builtins.sh:6: $(foreach b,$(BUILT_INS),echo XXX $b YYY;)
git-am.sh:24: cmdline=$(basename $0)
git-am.sh:83: his_tree=$(GIT_INDEX_FILE="$dotest/patch-merge-index" git write-tree) &&
git-am.sh:84: orig_tree=$(cat "$dotest/patch-merge-base") &&
git-am.sh:160: last=$(cat "$dotest/last") &&
git-am.sh:161: next=$(cat "$dotest/next") &&
git-am.sh:216: files=$(git diff-index --cached --name-only HEAD) || exit
git-am.sh:223:if test "$(cat "$dotest/binary")" = t
git-am.sh:227:if test "$(cat "$dotest/utf8")" = t
git-am.sh:233:if test "$(cat "$dotest/keep")" = t
git-am.sh:238:if test "$(cat "$dotest/sign")" = t
git-am.sh:301: GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$dotest/info")"
git-am.sh:302: GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
git-am.sh:303: GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
git-am.sh:313: SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
git-am.sh:415: unmerged=$(git ls-files -u)
git-am.sh:453: tree=$(git write-tree) &&
git-am.sh:455: parent=$(git rev-parse --verify HEAD) &&
git-am.sh:456: commit=$(git commit-tree $tree -p $parent <"$dotest/final-commit") &&
git-bisect.sh:59: head=$(GIT_DIR="$GIT_DIR" git symbolic-ref HEAD) ||
git-bisect.sh:92: orig_args=$(sq "$@")
git-bisect.sh:102: rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
git-bisect.sh:127: rev=$(git rev-parse --verify HEAD) ;;
git-bisect.sh:129: rev=$(git rev-parse --verify "$1^{commit}") ;;
git-bisect.sh:141: echo "# bad: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
git-bisect.sh:147: 0) revs=$(git rev-parse --verify HEAD) || exit ;;
git-bisect.sh:148: *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
git-bisect.sh:153: rev=$(git rev-parse --verify "$rev^{commit}") || exit
git-bisect.sh:164: echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
git-bisect.sh:170: test -n "$(git for-each-ref "refs/bisect/good-*")" || missing_good=t
git-bisect.sh:187: case "$(read yesno)" in [Nn]*) exit 1 ;; esac
git-bisect.sh:214: bad=$(git rev-parse --verify refs/bisect/bad) &&
git-bisect.sh:215: good=$(git for-each-ref --format='^%(objectname)' \
git-bisect.sh:218: eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
git-bisect.sh:219: eval=$(eval "$eval") &&
git-bisect.sh:243: eval gitk bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
git-bisect.sh:291: echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
git-bisect.sh:296: echo "# bad: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
git-checkout.sh:9:old=$(git rev-parse --verify $old_name 2>/dev/null)
git-checkout.sh:10:oldbranch=$(git symbolic-ref $old_name 2>/dev/null)
git-checkout.sh:60: if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
git-checkout.sh:69: rev=$(git rev-parse --verify "refs/heads/$arg^0")
git-checkout.sh:73: elif rev=$(git rev-parse --verify "$arg^{tree}" 2>/dev/null)
git-checkout.sh:206: merge_error=$(git read-tree -m -u --exclude-per-directory=.gitignore $old $new 2>&1) || (
git-clone.sh:147: upload_pack=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
git-clone.sh:181:if base=$(get_repo_base "$repo"); then
git-clone.sh:188:[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
git-clone.sh:205:mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
git-clone.sh:207:W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
git-clone.sh:231: ref_git=$(cd "$ref_git" && pwd)
git-clone.sh:260: sample_file=$(cd "$repo" && \
git-clone.sh:391: head_points_at=$(
git-commit.sh:463: encoding=$(git config i18n.commitencoding || echo UTF-8)
git-commit.sh:479: sign=$(git-var GIT_COMMITTER_IDENT | sed -e '
git-commit.sh:506: eval "$(get_author_ident_from_commit "$use_commit")"
git-commit.sh:528: PARENTS=$(git cat-file commit HEAD |
git-commit.sh:531: current="$(git rev-parse --verify HEAD)"
git-commit.sh:533: if [ -z "$(git ls-files)" ]; then
git-commit.sh:625: tree=$(GIT_INDEX_FILE="$USE_INDEX" git write-tree)
git-commit.sh:627: tree=$(GIT_INDEX_FILE="$TMP_INDEX" git write-tree) &&
git-commit.sh:630: commit=$(git commit-tree $tree $PARENTS <"$GIT_DIR/COMMIT_MSG") &&
git-commit.sh:631: rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
git-fetch.sh:43: exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)')
git-fetch.sh:88: origin=$(get_default_remote)
git-fetch.sh:89: test -n "$(get_remote_url ${origin})" ||
git-fetch.sh:97: exec="--upload-pack=$(get_uploadpack $1)"
git-fetch.sh:101:remote=$(get_remote_url "$@")
git-fetch.sh:112:ls_remote_result=$(git ls-remote $exec "$remote") ||
git-fetch.sh:125:if test -z "$update_head_ok" && test $(is_bare_repository) = false
git-fetch.sh:127: orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-fetch.sh:133: case "$(git config --get "remote.$1.tagopt")" in
git-fetch.sh:144:reflist=$(get_remote_refs_for_fetch "$@")
git-fetch.sh:166: eval=$(echo "$1" | git fetch--tool parse-reflist "-")
git-fetch.sh:192: theirs=$(echo "$ls_remote_result" | \
git-fetch.sh:242: ref=$(expr "z$ref" : 'z\.\(.*\)')
git-fetch.sh:249: ref=$(expr "z$ref" : 'z+\(.*\)')
git-fetch.sh:253: remote_name=$(expr "z$ref" : 'z\([^:]*\):')
git-fetch.sh:254: local_name=$(expr "z$ref" : 'z[^:]*:\(.*\)')
git-fetch.sh:273: head=$(echo "$ls_remote_result" | \
git-fetch.sh:286: head=$(git rev-parse --verify TMP_HEAD)
git-fetch.sh:343: taglist=$(IFS=' ' &&
git-fetch.sh:368: curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-filter-branch.sh:43: lid="$(echo "$1" | tr "A-Z" "a-z")"
git-filter-branch.sh:44: uid="$(echo "$1" | tr "a-z" "A-Z")"
git-filter-branch.sh:154:tempdir="$(cd "$tempdir"; pwd)" &&
git-filter-branch.sh:156:workdir="$(pwd)" ||
git-filter-branch.sh:177: GIT_DIR="$(pwd)/../../$GIT_DIR"
git-filter-branch.sh:190: ref="$(git symbolic-ref "$ref")"
git-filter-branch.sh:195: ref="$(git for-each-ref --format='%(refname)' |
git-filter-branch.sh:205:export GIT_INDEX_FILE="$(pwd)/../index"
git-filter-branch.sh:222:commits=$(wc -l <../revs | tr -d " ")
git-filter-branch.sh:230: i=$(($i+1))
git-filter-branch.sh:245: eval "$(set_ident AUTHOR <../commit)" ||
git-filter-branch.sh:247: eval "$(set_ident COMMITTER <../commit)" ||
git-filter-branch.sh:272: for reparent in $(map "$parent"); do
git-filter-branch.sh:277: parentstr="$(echo "$parentstr" | eval "$filter_parent")" ||
git-filter-branch.sh:285: $(git write-tree) $parentstr < ../message > ../map/$commit
git-filter-branch.sh:296: sha1=$(git rev-parse "$ref"^0)
git-filter-branch.sh:301: for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
git-filter-branch.sh:320: sha1=$(git rev-parse "$ref"^0)
git-filter-branch.sh:321: rewritten=$(map $sha1)
git-filter-branch.sh:344: rewritten=$(echo "$rewritten" | head -n 1)
git-filter-branch.sh:351: count=$(($count+1))
git-filter-branch.sh:370: sha1="$(git rev-parse "$sha1"^{commit} 2>/dev/null)" || continue
git-filter-branch.sh:374: new_sha1="$(cat "../map/$sha1")"
git-filter-branch.sh:376: new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
git-ls-remote.sh:30: exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)')
git-ls-remote.sh:48:peek_repo="$(get_remote_url "$@")"
git-ls-remote.sh:75: head=$(cat "$tmpdir/HEAD") &&
git-ls-remote.sh:78: head=$(expr "z$head" : 'zref: \(.*\)') &&
git-ls-remote.sh:79: head=$(cat "$tmpdir/$head") || exit
git-merge-octopus.sh:48:MRT=$(git write-tree)
git-merge-octopus.sh:64: common=$(git merge-base --all $MRC $SHA1) ||
git-merge-octopus.sh:86: MRC=$SHA1 MRT=$(git write-tree)
git-merge-octopus.sh:94: next=$(git write-tree 2>/dev/null)
git-merge-octopus.sh:100: next=$(git write-tree 2>/dev/null)
git-merge-one-file.sh:36: rmdir -p "$(expr "z$4" : 'z\(.*\)/')" 2>/dev/null || :
git-merge-resolve.sh:43:if result_tree=$(git write-tree 2>/dev/null)
git-merge.sh:13:test -z "$(git ls-files -u)" ||
git-merge.sh:102: rh=$(git rev-parse --verify "$remote^0" 2>/dev/null) || return
git-merge.sh:103: bh=$(git show-ref -s --verify "refs/heads/$remote" 2>/dev/null)
git-merge.sh:107: elif truname=$(expr "$remote" : '\(.*\)~[1-9][0-9]*$') &&
git-merge.sh:173: test "$(git config --bool merge.diffstat)" = false && show_diffstat=false
git-merge.sh:184: second_token=$(git rev-parse --verify "$2^0" 2>/dev/null) &&
git-merge.sh:185: head_commit=$(git rev-parse --verify "HEAD" 2>/dev/null) &&
git-merge.sh:203: rh=$(git rev-parse --verify "$1^0") ||
git-merge.sh:219: merge_name=$(for remote
git-merge.sh:226:head=$(git rev-parse --verify "$head_arg"^0) || usage
git-merge.sh:235: remotehead=$(git rev-parse --verify "$remote"^0 2>/dev/null) ||
git-merge.sh:281: common=$(git merge-base --all $head "$@")
git-merge.sh:284: common=$(git show-branch --merge-base $head "$@")
git-merge.sh:304: echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $1)"
git-merge.sh:311: new_head=$(git rev-parse --verify "$1^0") &&
git-merge.sh:334: result_tree=$(git write-tree)
git-merge.sh:337: result_commit=$(
git-merge.sh:353: common_one=$(git merge-base --all $head $remote)
git-merge.sh:435: result_tree=$(git write-tree) && break
git-merge.sh:442: parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
git-merge.sh:443: result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
git-merge-stupid.sh:69:if result_tree=$(git write-tree 2>/dev/null)
git-mergetool.sh:51: echo "a symbolic link -> '$(cat "$file")'"
git-mergetool.sh:266: eval "${eval_candidate}" --eval '"$(emacs-string "(ediff-merge-files-with-ancestor" @ "$LOCAL" @ "$REMOTE" @ "$BASE" "(lambda()(setq ediff-keep-variants nil))" @ "$path" ")")"'
git-mergetool.sh:268: eval "${eval_candidate}" --eval '"$(emacs-string "(ediff-merge-files" @ "$LOCAL" @ "$REMOTE" "(lambda()(setq ediff-keep-variants nil))" @ "$path" ")")"'
git-mergetool.sh:314: for i in "$GIT_EDITOR" "$(git config core.editor)" "$VISUAL" "$EDITOR"
git-parse-remote.sh:5:GIT_DIR=$(git rev-parse --git-dir 2>/dev/null) || :;
git-parse-remote.sh:16: if test "$(git config --get "remote.$1.url")"
git-parse-remote.sh:32: data_source=$(get_data_source "$1")
git-parse-remote.sh:58: curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
git-parse-remote.sh:59: origin=$(git config --get "branch.$curr_branch.remote")
git-parse-remote.sh:64: data_source=$(get_data_source "$1")
git-parse-remote.sh:105: set $(expand_refs_wildcard "$remote" "$@")
git-parse-remote.sh:108: if test "$remote" = "$(get_default_remote)"
git-parse-remote.sh:110: curr_branch=$(git symbolic-ref -q HEAD | \
git-parse-remote.sh:112: merge_branches=$(git config \
git-parse-remote.sh:125: ref=$(expr "z$ref" : 'z+\(.*\)')
git-parse-remote.sh:130: remote=$(expr "z$ref" : 'z\([^:]*\):')
git-parse-remote.sh:131: local=$(expr "z$ref" : 'z[^:]*:\(.*\)')
git-parse-remote.sh:157: if local_ref_name=$(expr "z$local" : 'zrefs/\(.*\)')
git-parse-remote.sh:168: data_source=$(get_data_source "$1")
git-parse-remote.sh:174: $(git for-each-ref --format='%(refname):')
git-parse-remote.sh:178: $(git config --get-all "remote.$1.fetch") ;;
git-parse-remote.sh:180: remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
git-parse-remote.sh:185: canon_refs_list_for_fetch -d "$1" $(sed -ne '/^Pull: */{
git-parse-remote.sh:254: data_source=$(get_data_source "$1")
git-parse-remote.sh:257: uplp=$(git config --get "remote.$1.uploadpack")
git-pull.sh:15:test -z "$(git ls-files -u)" ||
git-pull.sh:57:orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-pull.sh:60:curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-pull.sh:83:merge_head=$(sed -e '/ not-for-merge /d' \
git-pull.sh:89: curr_branch=$(git symbolic-ref -q HEAD)
git-pull.sh:121:merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
git-quiltimport.sh:12: quilt_author=$(expr "z$1" : 'z-[^=]*\(.*\)')
git-quiltimport.sh:29: QUILT_PATCHES=$(expr "z$1" : 'z-[^=]*\(.*\)')
git-quiltimport.sh:48: quilt_author_name=$(expr "z$quilt_author" : 'z\(.*[^ ]\) *<.*') &&
git-quiltimport.sh:49: quilt_author_email=$(expr "z$quilt_author" : '.*<\([^>]*\)') &&
git-quiltimport.sh:70:commit=$(git rev-parse HEAD)
git-quiltimport.sh:73:for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
git-quiltimport.sh:83: export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
git-quiltimport.sh:84: export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
git-quiltimport.sh:102: patch_author_name=$(expr "z$patch_author" : 'z\(.*[^ ]\) *<.*') &&
git-quiltimport.sh:103: patch_author_email=$(expr "z$patch_author" : '.*<\([^>]*\)') &&
git-quiltimport.sh:110: export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
git-quiltimport.sh:111: export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
git-quiltimport.sh:113: SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
git-quiltimport.sh:118: tree=$(git write-tree) &&
git-quiltimport.sh:119: commit=$( (echo "$SUBJECT"; echo; cat "$tmp_msg") | git commit-tree $tree -p $commit) &&
git-rebase--interactive.sh:29:test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
git-rebase--interactive.sh:73: count=$(($(wc -l < "$DONE")))
git-rebase--interactive.sh:74: total=$(($count+$(wc -l < "$TODO")))
git-rebase--interactive.sh:80: parent_sha1=$(git rev-parse --verify "$1"^ 2> /dev/null)
git-rebase--interactive.sh:103: parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
git-rebase--interactive.sh:104: current_sha1=$(git rev-parse --verify HEAD)
git-rebase--interactive.sh:108: sha1=$(git rev-parse --short $sha1)
git-rebase--interactive.sh:117: sha1=$(git rev-parse $sha1)
git-rebase--interactive.sh:121: current_commit=$(cat "$DOTEST"/current-commit) &&
git-rebase--interactive.sh:131: for p in $(git rev-list --parents -1 $sha1 | cut -d\ -f2-)
git-rebase--interactive.sh:136: new_p=$(cat "$REWRITTEN"/$p)
git-rebase--interactive.sh:154: first_parent=$(expr "$new_parents" : " \([^ ]*\)")
git-rebase--interactive.sh:163: author_script=$(get_author_ident_from_commit $sha1)
git-rebase--interactive.sh:165: msg="$(git cat-file commit $sha1 | \
git-rebase--interactive.sh:192: COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
git-rebase--interactive.sh:204: echo "# This is the $(nth_string $COUNT) commit message:"
git-rebase--interactive.sh:245: test -z "$(grep -ve '^$' -e '^#' < $DONE)" &&
git-rebase--interactive.sh:250: case "$(peek_next_command)" in
git-rebase--interactive.sh:265: author_script=$(get_author_ident_from_commit $sha1)
git-rebase--interactive.sh:288: HEADNAME=$(cat "$DOTEST"/head-name) &&
git-rebase--interactive.sh:289: OLDHEAD=$(cat "$DOTEST"/head) &&
git-rebase--interactive.sh:290: SHORTONTO=$(git rev-parse --short $(cat "$DOTEST"/onto)) &&
git-rebase--interactive.sh:294: current_commit=$(cat "$DOTEST"/current-commit) &&
git-rebase--interactive.sh:296: NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
git-rebase--interactive.sh:298: NEWHEAD=$(git rev-parse HEAD)
git-rebase--interactive.sh:304: git diff --stat $(cat "$DOTEST"/head)..HEAD
git-rebase--interactive.sh:344: HEADNAME=$(cat "$DOTEST"/head-name)
git-rebase--interactive.sh:345: HEAD=$(cat "$DOTEST"/head)
git-rebase--interactive.sh:400: ONTO=$(git rev-parse --verify "$2") ||
git-rebase--interactive.sh:417: HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
git-rebase--interactive.sh:418: UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
git-rebase--interactive.sh:441: for c in $(git merge-base --all $HEAD $UPSTREAM)
git-rebase--interactive.sh:451: SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
git-rebase--interactive.sh:452: SHORTHEAD=$(git rev-parse --short $HEAD)
git-rebase--interactive.sh:453: SHORTONTO=$(git rev-parse --short $ONTO)
git-rebase--interactive.sh:470: test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
git-rebase--interactive.sh:477: test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
git-rebase.sh:54: unmerged=$(git ls-files -u)
git-rebase.sh:82: msgnum=$(($msgnum + 1))
git-rebase.sh:87: cmt="$(cat $dotest/cmt.$1)"
git-rebase.sh:89: hd=$(git rev-parse --verify HEAD)
git-rebase.sh:90: cmt_name=$(git symbolic-ref HEAD)
git-rebase.sh:91: msgnum=$(cat $dotest/msgnum)
git-rebase.sh:92: end=$(cat $dotest/end)
git-rebase.sh:93: eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
git-rebase.sh:94: eval GITHEAD_$hd='"$(cat $dotest/onto_name)"'
git-rebase.sh:167: msgnum=$(($msgnum + 1))
git-rebase.sh:257:diff=$(git diff-index --cached --name-status -r HEAD)
git-rebase.sh:272:onto=$(git rev-parse --verify "${onto_name}^0") || exit
git-rebase.sh:298:branch=$(git rev-parse --verify "${branch_name}^0") || exit
git-rebase.sh:304:mb=$(git merge-base "$onto" "$branch")
git-rebase.sh:351: msgnum=$(($msgnum + 1))
git-repack.sh:67:names=$(git pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
git-reset.sh:27: rev=$(git rev-parse --verify "$1") || exit
git-reset.sh:36:rev=$(git rev-parse --verify $rev^0) || exit
git-reset.sh:69: test "" != "$(git ls-files --unmerged)"
git-reset.sh:78:if orig=$(git rev-parse --verify HEAD 2>/dev/null)
git-sh-setup.sh:32: : "${GIT_EDITOR:=$(git config core.editor)}"
git-sh-setup.sh:52: cdup=$(git rev-parse --show-cdup)
git-sh-setup.sh:63: test $(git rev-parse --is-inside-work-tree) = true ||
git-sh-setup.sh:89: encoding=$(git config i18n.commitencoding || echo UTF-8)
git-sh-setup.sh:113: GIT_DIR=$(GIT_DIR="$GIT_DIR" git rev-parse --git-dir) || {
git-sh-setup.sh:119: GIT_DIR=$(git rev-parse --git-dir) || exit
git-stash.sh:22: if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
git-stash.sh:43: if b_commit=$(git rev-parse --verify HEAD)
git-stash.sh:45: head=$(git log --abbrev-commit --pretty=oneline -n 1 HEAD)
git-stash.sh:50: if branch=$(git symbolic-ref -q HEAD)
git-stash.sh:56: msg=$(printf '%s: %s' "$branch" "$head")
git-stash.sh:59: i_tree=$(git write-tree) &&
git-stash.sh:60: i_commit=$(printf 'index on %s' "$msg" |
git-stash.sh:65: w_tree=$( (
git-stash.sh:80: stash_msg=$(printf 'WIP on %s' "$msg")
git-stash.sh:82: stash_msg=$(printf 'On %s: %s' "$branch" "$stash_msg")
git-stash.sh:84: w_commit=$(printf '%s\n' "$stash_msg" |
git-stash.sh:104: flags=$(git rev-parse --no-revs --flags "$@")
git-stash.sh:109: s=$(git rev-parse --revs-only --no-flags --default $ref_stash "$@")
git-stash.sh:111: w_commit=$(git rev-parse --verify "$s") &&
git-stash.sh:112: b_commit=$(git rev-parse --verify "$s^") &&
git-stash.sh:128: c_tree=$(git write-tree) ||
git-stash.sh:133: s=$(git rev-parse --revs-only --no-flags --default $ref_stash "$@") &&
git-stash.sh:134: w_tree=$(git rev-parse --verify "$s:") &&
git-stash.sh:135: b_tree=$(git rev-parse --verify "$s^1:") &&
git-stash.sh:136: i_tree=$(git rev-parse --verify "$s^2:") ||
git-stash.sh:145: unstashed_index_tree=$(git-write-tree) ||
git-submodule.sh:50: re=$(printf '%s' "$1" | sed -e 's/\([^a-zA-Z0-9_]\)/\\\1/g')
git-submodule.sh:51: name=$( GIT_CONFIG=.gitmodules \
git-submodule.sh:108: if base=$(get_repo_base "$repo"); then
git-submodule.sh:114: path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
git-submodule.sh:116: path=$(echo "$path" | sed -e 's|/*$||')
git-submodule.sh:148: name=$(module_name "$path") || exit
git-submodule.sh:149: url=$(git config submodule."$name".url)
git-submodule.sh:152: url=$(GIT_CONFIG=.gitmodules git config submodule."$name".url)
git-submodule.sh:173: name=$(module_name "$path") || exit
git-submodule.sh:174: url=$(git config submodule."$name".url)
git-submodule.sh:189: subsha1=$(unset GIT_DIR && cd "$path" &&
git-submodule.sh:206: revname=$( (
git-submodule.sh:232: name=$(module_name "$path") || exit
git-submodule.sh:233: url=$(git config submodule."$name".url)
git-submodule.sh:246: sha1=$(unset GIT_DIR && cd "$path" && git rev-parse --verify HEAD)
git-tag.sh:39: LINES=$(expr "$1" : '\([0-9]*\)')
git-tag.sh:64: OBJTYPE=$(git cat-file -t "$TAG")
git-tag.sh:67: ANNOTATION=$(git cat-file tag "$TAG" |
git-tag.sh:100: message="$(cat "$1")"
git-tag.sh:121: cur=$(git show-ref --verify --hash -- "refs/tags/$tag") || {
git-tag.sh:137: tag=$(git show-ref --verify --hash -- "refs/tags/$tag_name") ||
git-tag.sh:165:object=$(git rev-parse --verify --default HEAD "$@") || exit 1
git-tag.sh:166:type=$(git cat-file -t $object) || exit 1
git-tag.sh:167:tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
git-tag.sh:170: username=$(git repo-config user.signingkey) ||
git-tag.sh:171: username=$(expr "z$tagger" : 'z\(.*>\)')
git-tag.sh:202: object=$(git-mktag < "$GIT_DIR"/TAG_TMP)
git-verify-tag.sh:24:type="$(git cat-file -t "$1" 2>/dev/null)" ||
Grep finished (matches found) at Fri Aug 3 01:29:41
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 23:37 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Simon 'corecode' Schubert, git, users
In-Reply-To: <EDE86758-FFD0-4CED-A2C9-033FA13DD3B6@zib.de>
Steffen Prohaska wrote:
> On Aug 2, 2007, at 7:35 PM, Simon 'corecode' Schubert wrote:
>> Steffen Prohaska wrote:
>>> fromcvs's togit surrendered during the import.
>>> fromcvs's tohg accepted more of the history, but finally
>>> surrendered as well.
>>
>> Which repo is it you are converting? Is this available somewhere?
>
> Unfortunately not, the content is a proprietary software package.
>
>> I'd appreciate any reports concerning "surrenders" of fromcvs.
>> [...]
>
> Some time passed since I did the tests. I had no time to do a
> detailed investigation then. I'll have more time now and will
> prepare a bug report, which is not easy because I can't sent you
> the cvs repo, sorry.
I wrote a couple of scripts for dealing with just this situation for
cvs2svn bug reports, but they should also work for you, and I highly
recommend them. Both scripts are included in the cvs2svn source tree:
1. contrib/destroy_repository.py [1] -- strips almost all of the
information out of a CVS repository, including author names, log
messages, and file contents (but not file names, commit dates, or
branch/tag names). Most bugs are not affected by the omission of such
data. Use of this script has the effect of deleting most information
that might be considered proprietary and also shrinking the size of the
test case considerably. Use of this script is described in the script
comments itself and also in [2].
2. contrib/shrink_test_case.py [2] -- you provide the script with a
command that should "exit 0" if the bug you are looking for still
exists. It does a kind of "binary search" through CVS repository space,
iteratively attempting to delete a chunk of the CVS repository, running
the test command, then (depending on whether the test succeeded) either
reverting or making permanent the deletion. It can boil most test cases
down to just 1-3 files (though presumably not if the "problem" is a
23-way merge). The things that it will try to delete are:
- Entire directories and groups of directories
- Entire files and groups of files
- Branches within individual files
- Tags within individual files
It does this in a somewhat optimal way, trying to minimize the number of
times that the test has to be run. This script is documented in its own
comments and also in [4].
Michael
[1]
http://cvs2svn.tigris.org/svn/cvs2svn/trunk/contrib/destroy_repository.py
[2] http://cvs2svn.tigris.org/faq.html#reportingbugs
[3] http://cvs2svn.tigris.org/svn/cvs2svn/trunk/contrib/shrink_test_case.py
[4] http://cvs2svn.tigris.org/faq.html#testcase
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jon Smirl @ 2007-08-02 23:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, users
In-Reply-To: <f8r09t$qdg$1@sea.gmane.org>
On 8/1/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Michael Haggerty wrote:
>
> > I am the maintainer of cvs2svn[1], which is a program for one-time
> > conversions from CVS to Subversion. cvs2svn is very robust against the
> > many peculiarities of CVS and can convert just about every CVS
> > repository we have ever seen.
> >
> > I've been working on a cvs2svn output pass that writes the converted CVS
> > repository directly into git rather than Subversion. The code runs now
> > with at least one repository from our test suite of nasty CVS repositories.
>
> Have you contacted Jon Smirl about his unpublished work on cvs2git,
> cvs2svn based CVS to Git converter?
My converter was derived from Michael's cvs2svn code. The bulk of my
work was converting cvs2svn to output in a format that git-fastimport
could consume. This was all rather straight forward and there was
nothing really interesting in the code.
What it exposed were fundamental issues about the technical
complexities of trying to reconstruct a change set history from CVS
which didn't record all of the needed info. I was never able to
construct a satisfactory git representation of the Mozilla CVS
repository. Michael has had a long time to work on the change set
detection code and he's probably added some new strategies.
My code did include a CVS file parser for extracting all the revisions
from the file in a single pass. Doing that is a major performance
benefit. I believe I posted the code to the cvs2svn mailing list. It
was about 200 lines of code. Forking off cvs a million times to
extract the revisions takes days to run.
Same goes for forking git a million times.git-fastimport uses a pipe
to cvs2svn to avoid forking. git-fastimport also uses a technique from
the database world for bulk import, it imports everything without
indexing it. Indexing is done after the import finishes.
Between parsing the CVS files internally and Shawn's git-fastimport,
it was possible to import Mozilla CVS (2.4G) in about 2 hours and
generate a 450MB pack file. You need 3GB of RAM to do this - if swap
happens the process will take weeks to finish.
> Quote from InterfacesFrontendsAndTools page on GIT wiki[1]:
>
> cvs2git is the unofficial name of Jon Smirl's modifications to cvs2svn.
> These modifications allow cvs2svn to generate a data stream which is
> consumed by Shawn Pearce's git-fast-import (now included in git.git).
> git-fast-import converts its input stream directly into a Git .pack file,
> minimizing the amount of IO required on large imports.
>
> Jon Smirl stopped working on cvs2git[2] because first, Mozilla (which was
> main target of his work) decided that to not to move to git, and second
> because of troubles with cvs2svn architecture[*] (which it is based on).
> Jon Smirl has posted his impressions on working on CVS importer in
> "Some tips for doing a CVS importer" thread[3].
>
> References:
> -----------
> [1] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-23858c2cde0cef60443d8e73e6829a95f8e191ef
> [2] http://msgid.gmane.org/9e4733910611190940y147992b8mbdfac5a51f42e0fe@mail.gmail.com
> [3] http://marc.theaimsgroup.com/?t=116405956000001&r=1&w=2
>
> Footnotes:
> ----------
> [*] If I remember correctly authors of cvs2svn were talking about separating
> the code dealing with disentangling CVS repository structure from the part
> translating it into Subversion repository (with its quirks), and the part
> generating Subversion repository.
>
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 23:45 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85k5sdy0lk.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
On Fri, Aug 03, 2007 at 01:32:07AM +0200, David Kastrup wrote:
> Robert Schiele <rschiele@gmail.com> writes:
> > Well, I have now a patch ready for submission that would replace all
> > occurences of ${PARAMETER#WORD}, ${PARAMETER%WORD}, and $((
> > EXPRESSION )). But if you say that you won't accept replacement of
> > $( ... ) then this is not worth the effort since this one isn't
> > accepted as well.
>
> I absolutely can't understand your claim that most things work for
> you, then. Are you _really_, _really_ sure you are talking about
> /bin/sh here?
I started wondering myself and it turned out that we just didn't look in the
right place. Actually we _have_ an infrastructure in place to replace the
shell. (SHELL_PATH in the Makefile) In that case I would not consider this
an issue and you might go on with the cleanup from my point of view.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 23:50 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <46B25FC3.6000205@fs.ei.tum.de>
Simon 'corecode' Schubert wrote:
> Steffen Prohaska wrote:
>> BTW, togit creates much more complex branching patterns than cvs2svn
>> does. The attached file branching.png displays a small view of a
>> branching pattern that extends downwards over a couple of screens.
>> I checked the cvs2svn history again. It doesn't contain anything
>> of similar complexity.
>
> haha yea, there is still some issue with duplicate branch names and the
> branchpoint. if it doesn't get the branch right, it will always "pull"
> files from the parent branch.
This sounds very much like the problem reported by Daniel Jacobowitz
[1]. The problem is that if you create a branch A on a file, then
create branch B from branch A before making a commit on branch A, then
CVS doesn't record that branch A was the source of branch B. (It treats
B as if it sprouted directly from the revision that was the *source* of
branch A.) The same problem exists if "B" is a tag.
The only way to determine the correct branch hierarchy is to consider
the branch hierarchy of multiple files at the same time.
cvs2svn 2.0 includes code to choose a "preferred parent" of each branch
and try to use that parent for every file that is on the branch. It
helps simplify branch creation quite a bit. The main limitation is that
it still doesn't consider the revision copied back to trunk from a
vendor branch as the possible parent of a branch whose nominal source
was on the vendor branch (a limitation that has come up elsewhere in
this thread).
Michael
[1] http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1441
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 23:52 UTC (permalink / raw)
To: Robert Schiele; +Cc: Junio C Hamano, git
In-Reply-To: <20070802234515.GW29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> On Fri, Aug 03, 2007 at 01:32:07AM +0200, David Kastrup wrote:
>> Robert Schiele <rschiele@gmail.com> writes:
>> > Well, I have now a patch ready for submission that would replace all
>> > occurences of ${PARAMETER#WORD}, ${PARAMETER%WORD}, and $((
>> > EXPRESSION )). But if you say that you won't accept replacement of
>> > $( ... ) then this is not worth the effort since this one isn't
>> > accepted as well.
>>
>> I absolutely can't understand your claim that most things work for
>> you, then. Are you _really_, _really_ sure you are talking about
>> /bin/sh here?
>
> I started wondering myself and it turned out that we just didn't
> look in the right place. Actually we _have_ an infrastructure in
> place to replace the shell. (SHELL_PATH in the Makefile) In that
> case I would not consider this an issue and you might go on with the
> cleanup from my point of view.
I was starting to doubt my sanity here. Sorry that this thread
resulted in wasted work for you.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jon Smirl @ 2007-08-02 23:55 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Michael Haggerty, git, users
In-Reply-To: <65F1862F-4DF2-4A52-9FD5-20802AEACDAB@zib.de>
On 8/2/07, Steffen Prohaska <prohaska@zib.de> wrote:
> Right now, I'd prefer the import by parsecvs because of the
> simpler history. However, I don't know if I loose history
> information by doing so. I'd start by a run of cvs2svn to validate
> the overall structure of the CVS repository. Dealing with corruption
> in the CVS repository seems to be superior in cvs2svn. It reports
> errors when parsecvs just crashes.
Parsecvs silently throws away things that confuse it. cvs2svn is much
more careful about not losing track of anything. For example parsecvs
is unable to process Mozilla CVS and cvs2svn can. The branching in
Mozilla CVS is too complex for parsecvs to handle.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jon Smirl @ 2007-08-02 23:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Steffen Prohaska, git, users
In-Reply-To: <46B2132D.7090304@alum.mit.edu>
On 8/2/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Branches with names like "unlabeled-1.1.1" come from CVS branches for
> which the revisions are still contained in the RCS files but for which
> the branch name has been deleted. These wreak havoc on cvs2svn's
> attempt to find simple branch sources and cause a proliferation of
> basically useless branches. The main problem is that cvs2svn does not
> attempt to figure out that "unlabeled-1.2.4" in one file might be the
> same as "unlabeled-1.2.6" in another etc.
I seem to recall discussing an algorithm to fix this on the cvs2svn
mailing list. There was a somewhat simple way to correlate the
"unlabeled-1.2.4" in one file might be the same as "unlabeled-1.2.6"
problem.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-03 0:01 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85d4y5xznj.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
On Fri, Aug 03, 2007 at 01:52:32AM +0200, David Kastrup wrote:
> I was starting to doubt my sanity here. Sorry that this thread
> resulted in wasted work for you.
That's ok. I mean I didn't spot the SHELL_PATH thing in the first place
although I already had seen that one before (what I remember now).
At least in that case I don't have to worry any longer since I always can put
some compliant shell at some random place and use that one.
But at least you have learned now that not everything in the real world looks
like as it is written in some standard books. ;-)
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Junio C Hamano @ 2007-08-03 0:05 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Steffen Prohaska, git
In-Reply-To: <20070802181853.GB31885@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> I wonder whether we could get away with just the brief list of features
> ("lets you view changes in the index and the working file, lets you
> individually select diff hunks for inclusion in the index"), and leave
> the how-to stuff to online guit-gui help, if it's necessary?
Let's do that.
> Also, I like the verb "stage" as a way to explain the part of the index
> file in creating commits, but I've been consistently using the word
> "index" throughout the user manual, and I think that's consistent with
> the rest of the documentation--so don't avoid it here.
I tend to agree. The verb "to stage" is really just a way to
say "the act of adding contents to the index" and explain what
it implies (i.e. "prepare it to be included in the next commit").
Saying "you can _think_ of the index as a staging area" is fine,
but the official name of that thing is "the index", and I do not
think avoiding that term adds clarity to the documentation.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 0:11 UTC (permalink / raw)
To: Robert Schiele; +Cc: Junio C Hamano, git
In-Reply-To: <20070803000113.GX29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> On Fri, Aug 03, 2007 at 01:52:32AM +0200, David Kastrup wrote:
>> I was starting to doubt my sanity here. Sorry that this thread
>> resulted in wasted work for you.
>
> That's ok. I mean I didn't spot the SHELL_PATH thing in the first
> place although I already had seen that one before (what I remember
> now).
>
> At least in that case I don't have to worry any longer since I
> always can put some compliant shell at some random place and use
> that one.
>
> But at least you have learned now that not everything in the real
> world looks like as it is written in some standard books. ;-)
You are aware that I am the maintainer of AUCTeX? Which has an
autoconf-based setup that works under AIX, Solaris, MinGW, Cygwin,
HP/UX and a few other oddities, all with the respective native tools?
I know more about stupid shells than I really want to. But that does
not change that I could not imagine a shell such as yours to work
"mostly" with the current git code base.
For autoconf, it is fine to call sed (and you would probably not
believe how small the portable language subset for sed is) all the
time. Performance is not an issue. For normal user commands, this is
different.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-03 0:12 UTC (permalink / raw)
To: David Kastrup; +Cc: Robert Schiele, git
In-Reply-To: <85ps25y1ac.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> However, there is a line we need to draw when bending bacwards for
>> compatibility, and I think a system that does not have a working
>> command substitution $( ... ) is on the other side of that line.
>
> Not an issue. But apparently, ${parameter#word} is for Solaris. I'd
> still like to get confirmation that it is indeed /bin/sh, but if it
> is, the current code is not good for Solaris.
I happen to feel ${parameter#word} is more esoteric than $(cmd).
If a system does not even do the latter, then avoiding the
former to help such a system is a futile effort.
And /bin/sh my Solaris box does not understand $(cmd) and wants
you to say `cmd`. Of course % and # parameter substition do not
work there.
People could probably say SHELL_PATH=/usr/xpg4/bin/sh there to
get a saner shell, even if they do not like bash, though.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7vk5sdscfr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> However, there is a line we need to draw when bending bacwards for
>>> compatibility, and I think a system that does not have a working
>>> command substitution $( ... ) is on the other side of that line.
>>
>> Not an issue. But apparently, ${parameter#word} is for Solaris. I'd
>> still like to get confirmation that it is indeed /bin/sh, but if it
>> is, the current code is not good for Solaris.
>
> I happen to feel ${parameter#word} is more esoteric than $(cmd).
> If a system does not even do the latter, then avoiding the
> former to help such a system is a futile effort.
The situation is that we currently don't avoid the former. Robert
said that he had prepared a patch that would do so.
It would make sense to either encourage him to present his patch
(though we probably don't know for sure that there are indeed shells
for which the former works worse than the latter), or permit further
use of ${parameter#word} where it makes things more readable.
But "only a little bit of ${parameter#word}, please" seems pointless.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-03 0:48 UTC (permalink / raw)
To: David Kastrup; +Cc: Robert Schiele, git
In-Reply-To: <85wswdwjll.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
>> I happen to feel ${parameter#word} is more esoteric than $(cmd).
>> If a system does not even do the latter, then avoiding the
>> former to help such a system is a futile effort.
>
> The situation is that we currently don't avoid the former. Robert
> said that he had prepared a patch that would do so.
> ...
> But "only a little bit of ${parameter#word}, please" seems pointless.
Absolutely. And we started to adopt #/% substititions some time
ago. Undoing them just feels going backwards, and we need to
judge what the merits of going backwards are.
For that discussion, /bin/sh on Solaris does not count. There
are huge downside of rewriting scripts to work with stock
Solaris /bin/sh:
(1) that shell does not even grok $(cmd) substitution.
I won't accept a half-baked patch that replaces "$(" with a
backtick and matching ")" with another backtick. You need
to at least make sure your interpolated variables within
the backtick pair work sensibly, and you haven't broken
existing nesting of command interpolations, if any. I do
not even want to inspect, comment on and reject that kind
of changes. Quite frankly, it's not worth my time.
(2) Rewriting $(cmd) to `cmd`, and ${parameter#word} with sed
or expr would reduce readability, at least to other people.
Remember, I was the one who originally avoided modern
${parameter#word} substitutions, and older scripts had many
more invocations of expr than we currently have. Reading
such a backward rewrite would not be too much of a problem
for *me*, but other people also need to read and understand
scripts, if only to be able to rewrite them in C.
There may still be many old parts of the scripts that could
be made more readable and efficient using ${parameter#word}
substitutions. If we were to rewrite scripts, more use of
them could be a good thing, not the other way around.
Besides, on that platform there are more reasonable shells
available via SHELL_PATH, and it is not limited to going to
bash.
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Junio C Hamano @ 2007-08-03 0:51 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86tzrikz5x.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * With -l, as long as the source repository is healthy, it is
>> very likely that the recipient would be, too. Also it is
>> very cheap. You do not get any back-up benefit.
>
> Oh, but one does: an overzealous prune or rm -oopswrongoption in one
> repo does not hurt the other.
That's not "back-up" benefit I was thinking about. It is more
about protecting your data from hardware failure. You
physically have bits in two places, preferrably on separate disk
drives.
And that is what you do not get from hardlinked clone.
^ permalink raw reply
* gitweb via instaweb not showing log. Bug?
From: Brian Hetro @ 2007-08-03 1:26 UTC (permalink / raw)
To: git
Hi,
Using git version 1.5.3.rc3.120.g68d422, I am seeing a problem with
git-instaweb not being able to show the commit logs. For example, if
I git-clone the git repository, run git-instaweb and browse to:
http://127.0.0.1:1234/?p=.git;a=log;h=v1.5.1.5
I see:
Last change .
and no log of changes.
However, this does work using git version 1.5.2.4. In that case, I do
see the log.
I came up with a test script and let bisect have a go. It came up
with this commit:
e90fdc39b6903502192b2dd11e5503cea721a1ad is first bad commit
commit e90fdc39b6903502192b2dd11e5503cea721a1ad
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Wed Aug 1 01:30:14 2007 +0100
Clean up work-tree handling
[..snip..]
Known issue?
--
Brian
^ permalink raw reply
* Re: Why does git-svn dcommit rewrite the log messages?
From: Patrick Doyle @ 2007-08-03 1:44 UTC (permalink / raw)
To: Sam Vilain, git
In-Reply-To: <46B23415.8030008@vilain.net>
> Primarily it's so that the person who pushed via dcommit and people who
> sync via git-svn fetch get the same commit ID (assuming they are both
> using the same authors map).
>
> It might be possible to store the extra information needed to recreate
> exactly the original git commit in SVN revision properties, but this
> would need to be implemented once and basically not changed after that.
>
> You can disable this behaviour, but you'll end up with duplicate commits.
>
> Sam.
Thanks Sam,
Now I see the noMetadata option. I'll give that try and see how much
trouble I get myself in.
As I was thinking about this some more, I started wondering if perhaps
the information could be stored in a .git-svnid file, that was
versioned on the subversion server as well as in the local git
repository.
I'll have to think through the implications of your explanation in the
mean time.
--wpd
^ permalink raw reply
* [PATCH] gitweb: Provide RSS feeds for file history
From: Steven Walter @ 2007-08-03 2:05 UTC (permalink / raw)
To: git; +Cc: jnareb
If git_feed is provided a file name, it ought to show only the history
affecting that file. The title was already being set correctly, but all
commits from history were being shown anyway.
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 498b936..26932a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -611,6 +611,7 @@ sub href(%) {
my %mapping = @mapping;
$params{'project'} = $project unless exists $params{'project'};
+ $params{'file_name'} = $file_name unless exists $params{'file_name'};
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
@@ -5365,7 +5366,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch, history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150);
+ my @commitlist = parse_commits($head, 150, 0, "--full-history", $file_name);
my %latest_commit;
my %latest_date;
--
1.5.2.3
--
-Steven Walter <swalter@lexmark.com>
^ permalink raw reply related
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