git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Levedahl <mdl123@verizon.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, junkio@cox.net, Nicolas Pitre <nico@cam.org>,
	Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Subject: Re: [PATCH] git-bundle: assorted fixes
Date: Thu, 22 Feb 2007 20:36:07 -0500	[thread overview]
Message-ID: <45DE4507.7090206@verizon.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0702221913250.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

I built this under cygwin, it is running but I find two regressions 
compared to my git-bundle.sh:

1) git bundle create --all  <whatever> does not record any references, 
while it should record all references (heads and tags). From shell, this 
requires use of both git-rev-parse and git-show-ref:
    gitrevargs=$(git-rev-parse --symbolic --revs-only $args) || exit 1

    # find the refs to carry along and get sha1s for each.
    refs=
    fullrevargs=
    for arg in $gitrevargs ; do
        #ignore options and basis refs, get full ref name for things
        # we will transport rejecting anything ambiguous (e.g., user
        # gives master, have heads/master and remotes/origin/master, we
        # keep the former).
        case "$arg" in
            -* | ^*) fullrevargs="$fullrevargs $arg";;
            *)  ref=$(git-show-ref "$arg")
                test "$(echo $ref | wc -w)" = "2" || die "Ambigous 
reference: $arg
$ref"
                fullrevargs="$fullrevargs ${ref#* }"
                refs="$refs $ref";;
        esac
    done

2) git bundle verify  reports only a single sha1 if prerequisites are 
not met. git-bundle.sh would loop through finding each missing one, 
annotating with the one line commit message. The prerequisites were 
stored using:

    (for p in $prereqs ; do
        git-rev-list --pretty=one --max-count=1 $p
    done) > "$prerequisites"

and then verify does:
    test -z "$prereqs" && return 0
    bad=$(echo "$prereqs" | cut -b-40 | git-rev-list --stdin --not --all 
2>&1)
    if test -n "$bad" ; then
        test "$1" = "--silent" && return 1
        echo "error: $bfile requires the following commits you lack:"
        echo "$prereqs" |
        while read sha1 comment ; do
            missing=$(git-rev-list $sha1 --not --all 2>&1)
            test -n "$missing" && echo "$sha1 $comment"
        done
        exit 1
    fi
    return 0

The difference is

    fatal: bad object 59e4aa84d4b4f7c6393317c68649ef7db3c4440c
    error: At least one prerequisite is lacking.

vs.

    error: /home/mlevedahl/bundle2 requires the following commits you lack:
    59e4aa84d4b4f7c6393317c68649ef7db3c4440c Merge remote branch 
'rvaas05/gem.418' into lcb.418
    8eb8c8274c28be9435da8534f8bb598503f4f85a Merge remote branch 
'rvaas05/gem.418' into lcd.419

This was Junio's suggestion originally, and I think it a very good one. 
The latter error message is far more helpful to some poor soul trying to 
fix a problem.


Also,  I did track down the issue that forced me to use tar (or at least 
*some* archiver) in cygwin: it is a known bug without a planned fix that 
precludes saving mixed text and binary in one file from bash, and seems 
to be tied deeply into bash, fork, and pipes. Basically, doing
    echo "some text data" > file
    echo "some binary data" >>file
is totally confused as the underlying pipe / fork mechanism thinks file 
is text mode on the second operation. This happens regardless of mount 
mode or CYGWIN=binmode. The end result is under bash the binary data 
unconditionally suffers crlf->lf translation. You can look at at 
http://www.mail-archive.com/cygwin@cygwin.com/msg76319.html for more 
information.

Mark

  reply	other threads:[~2007-02-23  1:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.63.0702220157130.22628@wbgn013.biozentrum.uni-wuerz burg.de>
2007-02-22  0:59 ` [PATCH] Add git-bundle: move objects and references by archive Johannes Schindelin
2007-02-22  3:28   ` Nicolas Pitre
2007-02-22 15:55     ` Johannes Schindelin
2007-02-22 16:14       ` Simon 'corecode' Schubert
2007-02-22 16:28         ` Nicolas Pitre
2007-02-22 16:37         ` Johannes Schindelin
2007-02-22 16:46           ` Simon 'corecode' Schubert
2007-02-22 17:09             ` Johannes Schindelin
2007-02-22 16:24       ` Nicolas Pitre
2007-02-22 17:12         ` Johannes Schindelin
2007-02-22 17:21           ` Nicolas Pitre
2007-02-22  6:56   ` Junio C Hamano
2007-02-22  7:08     ` Junio C Hamano
2007-02-22 16:20       ` Johannes Schindelin
2007-02-22 19:10         ` Junio C Hamano
2007-02-22 19:16           ` Johannes Schindelin
2007-02-22 20:05             ` Junio C Hamano
2007-02-22 20:25               ` Johannes Schindelin
2007-02-22 16:17     ` Johannes Schindelin
2007-02-23  2:32     ` Mark Levedahl
2007-02-23  4:39       ` Junio C Hamano
2007-02-22  9:31   ` Johannes Sixt
2007-02-22 18:14   ` [PATCH] git-bundle: assorted fixes Johannes Schindelin
2007-02-23  1:36     ` Mark Levedahl [this message]
2007-02-23  1:56       ` Johannes Schindelin
2007-02-23  2:12         ` Mark Levedahl
2007-02-23  2:17           ` Johannes Schindelin
2007-02-23  3:37             ` Mark Levedahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DE4507.7090206@verizon.net \
    --to=mdl123@verizon.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=corecode@fs.ei.tum.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=nico@cam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).