lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Building wx from trunk


From: Greg Chicares
Subject: Re: [lmi] Building wx from trunk
Date: Fri, 24 Oct 2014 16:19:35 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 2014-10-20 20:01Z, Vadim Zeitlin wrote:
> On Mon, 20 Oct 2014 15:48:06 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> (1) Clone the wx repository--only need to do this once.
> GC> 
> GC> cd /opt/lmi
> GC> git clone https://github.com/wxWidgets/wxWidgets.git
> 
>  Just a note: you've previously mentioned that access to some domains may
> be restricted from some developers machines, I hope you can add github.com
> to the white list of allowed domains.

"Sein Ermatten ist das des Gladiators nach dem Kampf,
seine Arbeit war das Weißtünchen eines Winkels in einer Beamtenstube."

Like us, the author also worked at an insurance company.

> GC> Here's my question: It would be best for me and my US coworkers to
> GC> use the same revision, but wx trunk changes often, and we aren't
> GC> all likely to 'git pull' at the same time. Is there an easy way to
> GC> specify an as-of date with 'pull' or (more likely) 'archive'?
[...]
> GC> I did try to find the answer myself. 'man git-archive' mentions a
> GC> <tree-ish> option: "The tree or commit to produce an archive for".
> GC> Do I need to go looking for the SHA1 of a particular revision?
> GC> I can't make the time to master 'git' now, so I'm kind of lost.
> 
>  Now for the promised answer: the canonical way to identify a commit it git
> is indeed by using its SHA1. To find the SHA1 you want to use, you can
> use "git log" (to see just the latest commit, "git log -1")

Great. That's easy enough. I can do 'git pull' myself and make a note
of the SHA1. If that version looks okay to me, then I can ask my
coworkers to do 'git pull' (updating their clones to latest HEAD),
then 'git archive [specified-SHA1]', and then we all have the same
tarball. Just to be sure, I did that here (pull, then archive with
an older SHA1), and 'cmp' verifies that the new tarball matches the
old one that I've been using for several days.

I'm surprised that a truncated SHA1 is apparently accepted. I see
it on the console when I 'pull', e.g.:
  Updating e897361..9650c5b
The part on the right, "9650c5b", seems to be the first seven hex
digits of the new SHA1:
  /opt/lmi/wxWidgets[0]$git log -1 | head -n1
  commit 9650c5b55bb2cf2a6a57a120b56cb9c8206b2aff
Experimentally, I used "e897361" (the truncated SHA1 for the old
archive that I had carefully preserved) as 'tree-ish':
  git archive --prefix=wxWidgets-3.1.0/ e897361 | bzip2 > /path/to/whatever
and I was surprised that it seemed to work. With only seven hex
digits, the chance of a collision is 16^-7, and I anticipated
that a tool like git would take a more cautious approach. But I'm
not complaining.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]