* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-16 18:38 UTC (permalink / raw)
To: Paul Umbers; +Cc: Junio C Hamano, Robin Rosenberg, git
In-Reply-To: <a5eb9c330801161010h41e55486y5e8a4335dd939b73@mail.gmail.com>
Paul Umbers, Wed, Jan 16, 2008 19:10:43 +0100:
> > After seeing the above error, running the test with -i (stop
> > immediately on failure):
> >
> > $ cd t
> > $ sh -x ./t0000-basic.sh -i -v
> >
> Tried Junio's latest suggestion. The resulting output and contents of
> the trash are attached as a tar.gz. Thanks for all your help guys, I'm
Well, either it didn't work or you omited something critical (like
stderr):
* expecting success: tree=$(git write-tree)
* FAIL 5: writing tree out with git write-tree
tree=$(git write-tree)
that is too short. All the traces missing. Could you please retry
with
sh -x ./t0000-basic.sh -d -v -i &> test_results.txt
? If that is what you actually did, I suspect you have a very broken
shell installed. Could you check if you have bash (bash --version)
and try it instead of "sh"?
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-16 18:31 UTC (permalink / raw)
To: Paul Umbers; +Cc: Robin Rosenberg, git
In-Reply-To: <a5eb9c330801160742j645ee50p72ee0a93adf8f94f@mail.gmail.com>
Paul Umbers, Wed, Jan 16, 2008 16:42:46 +0100:
> OK, I think this worked (I'm a Java man, not C/C++). I downloaded the
> latest 1.5.3 source from the git repository and ran "make" with
> GIT_TEST_OPTS="--verbose --debug". Here's the output:
>
...
> * expecting success: tree=$(git write-tree)
> error: invalid object e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
> fatal: git-write-tree: error building trees
> * FAIL 5: writing tree out with git write-tree
> tree=$(git write-tree)
Ok, since you managed to compile it, could you please try to strace
git-add? Cygwins strace is a bit unusual, but strace --help can
provide enough information to configure it to trace filesystem
operations.
In the top-level of Git source directory:
$ uname -a > somefile
$ strace -o log -f -m syscall ./git --exec-path=$(pwd) add somefile
$ git ls-files -s somefile
or
$ strace -o log -f -m syscall ./git --exec-path=$(pwd) hash-object somefile
Than check if the sha1file is missing and send in the log.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Linus Torvalds @ 2008-01-16 18:25 UTC (permalink / raw)
To: Mike; +Cc: Neil Macneale, git
In-Reply-To: <alpine.LFD.1.00.0801161000310.2806@woody.linux-foundation.org>
On Wed, 16 Jan 2008, Linus Torvalds wrote:
>
> Yes, it's certainly quite possible that you simply don't have any
> management scripts etc, and that you don't generate any files, and you
> simply want to just deploy the exact files that you also want to track.
> But that really is a fairly unusual thing to do.
Example management scripts: let's say that you have a logo that shows up
in multiple different sizes. You can just have it as <n> number of
different files that you check in and update separately, or you can have
it as *one* scalable master file, and then the deployment script will
create all the generated files and put them in the deployment area.
So the common issue with SCM's is that you want to share two totally
different things:
- the actual "source" (which obviously doesn't have to be source code per
se), which is the thing you want to have for yourself and people you
work with, and which you want the history of.
- the "output" for external entities, which may often contain a lot of
the "source" verbatim, but quite often doesn't contain it all (some of
the stuff you need to manage things may be rather private and purely
for *your* management info), and almost invariably contains some
post-processing.
Some people don't split this up, and they tend to make horrible horrible
mistakes, like checking in the *results* of the post-processing too (ie
binary result blobs that can be regenerated from the other files), because
they don't make a clear separation between the parts they do development
on, and the end result.
Linus
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Linus Torvalds @ 2008-01-16 18:15 UTC (permalink / raw)
To: Mike; +Cc: Neil Macneale, git
In-Reply-To: <478E3D8E.1090300@talkingspider.com>
On Wed, 16 Jan 2008, Mike wrote:
>
> Neil Macneale wrote:
> >
> > It seems to me that you are asking git to be your deployment software,
> > which is a bad fit.
>
> I'm asking git to get out of my deployment!
I think you mis-understood.
The normal way of handling this is to NOT DO DEVELOPMENT IN YOUR
DEPLOYMENT TREE!
It's almost always a bad idea to develop in the tree that is also where
you "export" things, and if you find git annoying in this respect, ask
yourself why pretty much *every*single*scm*out*there* makes their
infrastructure even more noticeable (eg CVS subdirectories in every single
directory etc)
So while you can do various tricks (symlinking ".git", using GIT_DIR, etc
etc) to get the .git contents out of your worktree, the thing is, the
correct thing to do is almost always to simply re-think the whole problem,
and come at it the other way: rather than getting .git out of your
development tree, you should consider getting your development tree out of
your deployment area!
Let me do a few examples of why this is a good idea:
- the whole point of development trees and SCM's (and that's *especially*
true with git) is how you can try things out, go backwards in time, and
generally just do *development*.
If you do that in what is your public deployment area, you're already
very limited. Not only may you not want to make that .git directory
accessible to others (while you *do* obviously want to make the
deployment itself), you also end up exposing things like your
management scripts and source code along with "generated files" etc
that are the things you actually want to deploy.
Yes, it's certainly quite possible that you simply don't have any
management scripts etc, and that you don't generate any files, and you
simply want to just deploy the exact files that you also want to track.
But that really is a fairly unusual thing to do.
- with git in particular, you lose a lot of the capabilities if you are
forcing yourself to have "deployment == development tree". Things like
switching branches for managing different versions suddenly are
painful, because you're artificially forcing a 1:1 relationship between
"development" and "deployment".
- Most sane people want to deploy and test separately. In particular, you
want to test *before* you deploy. People make mistakes, they don't want
to show them. Or there are consistency requirements, and/or you simply
want to deploy to multiple sites simultaneously. All of which really
re-inforces the "develop separately" mentality, where the actual
deployment is then a separate "now I'm ready, let's push out the
result".
Now, maybe none of these things are issues at all for you. Good for you.
But hopefully this explains why most people don't have your issues, and
why people try to tell you that "deployment software" is a separate thing
from "source control management", and you often want both, and _want_ to
keep them separate.
Linus
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Paul Umbers @ 2008-01-16 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Robin Rosenberg, git
In-Reply-To: <7v1w8hslhw.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]
Tried Junio's latest suggestion. The resulting output and contents of
the trash are attached as a tar.gz. Thanks for all your help guys, I'm
sorry I can't contribute more but as I mentioned, I'm nowhere near
proficient in c/c++ or the internals of Git.
Paul
On Jan 16, 2008 10:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Paul Umbers" <paul.umbers@gmail.com> writes:
>
> > OK, I think this worked (I'm a Java man, not C/C++). I downloaded the
> > latest 1.5.3 source from the git repository and ran "make" with
> > GIT_TEST_OPTS="--verbose --debug". Here's the output:
> >
> > paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t
> > $ make
> > *** t0000-basic.sh ***
> > * ok 1: .git/objects should be empty after git init in an empty repo.
> > * ok 2: .git/objects should have 3 subdirectories.
> > * ok 3: git update-index without --add should fail adding.
> > * ok 4: git update-index with --add should succeed.
> > * FAIL 5: writing tree out with git write-tree
> > tree=$(git write-tree)
>
> Often the first error is the most interesting, as your build is
> failing the most basic operation (like creating a tree), and
> later parts of the test uses the tree to validate other aspects
> of your build.
>
> After seeing the above error, running the test with -i (stop
> immediately on failure):
>
> $ cd t
> $ sh -x ./t0000-basic.sh -i -v
>
> and looking at the exact command that fails is the usual
> approach for debugging something like this. During that
> debugging session, the contents of the directory t/trash (which
> is where the test script runs) left by the failed test is what
> we often do.
>
>
--
Computer Science is no more about computers than astronomy is about telescopes.
--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP
paul.umbers@gmail.com
[-- Attachment #2: full_test_results.tar.gz --]
[-- Type: application/x-gzip, Size: 5352 bytes --]
^ permalink raw reply
* Re: git and binary files
From: Junio C Hamano @ 2008-01-16 18:09 UTC (permalink / raw)
To: Petko Manolov; +Cc: Wincent Colaiuta, Johannes Schindelin, David Symonds, git
In-Reply-To: <7vwsq9r6mf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petko Manolov <petkan@nucleusys.com> writes:
>
>> On Wed, 16 Jan 2008, Wincent Colaiuta wrote:
>>
>>> If the exact contents of these large binaries *really* don't matter,
>>> as you say they don't, than why don't you just commit one and never
>>> touch it again?
>>
>> Unfortunately those binaries does change, although the process is slow
>> and not very frequent. And this is why it pokes me in the eye - for
>> changing a few bytes i end up with much larger repository.
>
> For changing a few bytes you get with much larger repository?
> What happened to our packfiles?
>
> Is it possible for us to take a look at two versions of such a
> binary blob, one before the change and one after such a change
> that touches only a few bytes?
I replied before reading the rest of the thread. Please ignore
me on this one.
^ permalink raw reply
* Re: git and binary files
From: Junio C Hamano @ 2008-01-16 18:02 UTC (permalink / raw)
To: Petko Manolov; +Cc: Wincent Colaiuta, Johannes Schindelin, David Symonds, git
In-Reply-To: <alpine.DEB.1.00.0801161643480.5260@bender.nucleusys.com>
Petko Manolov <petkan@nucleusys.com> writes:
> On Wed, 16 Jan 2008, Wincent Colaiuta wrote:
>
>> If the exact contents of these large binaries *really* don't matter,
>> as you say they don't, than why don't you just commit one and never
>> touch it again?
>
> Unfortunately those binaries does change, although the process is slow
> and not very frequent. And this is why it pokes me in the eye - for
> changing a few bytes i end up with much larger repository.
For changing a few bytes you get with much larger repository?
What happened to our packfiles?
Is it possible for us to take a look at two versions of such a
binary blob, one before the change and one after such a change
that touches only a few bytes?
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Junio C Hamano @ 2008-01-16 17:55 UTC (permalink / raw)
To: Paul Umbers; +Cc: Alex Riesen, Robin Rosenberg, git
In-Reply-To: <a5eb9c330801160742j645ee50p72ee0a93adf8f94f@mail.gmail.com>
"Paul Umbers" <paul.umbers@gmail.com> writes:
> OK, I think this worked (I'm a Java man, not C/C++). I downloaded the
> latest 1.5.3 source from the git repository and ran "make" with
> GIT_TEST_OPTS="--verbose --debug". Here's the output:
>
> paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t
> $ make
> *** t0000-basic.sh ***
> * ok 1: .git/objects should be empty after git init in an empty repo.
> * ok 2: .git/objects should have 3 subdirectories.
> * ok 3: git update-index without --add should fail adding.
> * ok 4: git update-index with --add should succeed.
> * FAIL 5: writing tree out with git write-tree
> tree=$(git write-tree)
Often the first error is the most interesting, as your build is
failing the most basic operation (like creating a tree), and
later parts of the test uses the tree to validate other aspects
of your build.
After seeing the above error, running the test with -i (stop
immediately on failure):
$ cd t
$ sh -x ./t0000-basic.sh -i -v
and looking at the exact command that fails is the usual
approach for debugging something like this. During that
debugging session, the contents of the directory t/trash (which
is where the test script runs) left by the failed test is what
we often do.
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Johannes Schindelin @ 2008-01-16 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Bill Lear, Mike, git
In-Reply-To: <7vd4s1sm7y.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 16 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Yes, so you can use
> >>
> >> $ git --work-tree . --git-dir /some/other/place <some-command>
> >>
> >> But it's far from the user-friendlyness of a real lightweight
> >> checkout: you need to provide the --work-tree and --git-dir options
> >> each time you run git. And making an alias or using the environment
> >> variables are not really an option if you have more than one
> >> repository or working tree to deal with.
> >
> > Well, the OP said he did not want _any_ file in the worktree. So
> > there's no way around specifying by hand everytime where the git
> > directory should be.
>
> Export GIT_DIR and GIT_WORKTREE and you are free to go, right?
Yep.
Ciao,
Dscho
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Johannes Schindelin @ 2008-01-16 17:51 UTC (permalink / raw)
To: Mike; +Cc: Neil Macneale, git
In-Reply-To: <478E3D8E.1090300@talkingspider.com>
Hi,
On Wed, 16 Jan 2008, Mike wrote:
> Neil Macneale wrote:
> > Mike wrote:
> >> .... And as for permissions and ownership, rsync takes care of that.
> > Perhaps "rsync --exclude *.git"?
> >
> > It seems to me that you are asking git to be your deployment software,
> > which is a bad fit.
>
> I'm asking git to get out of my deployment!
But that's easy: rm -rf /usr/bin/git* .git/ ;-)
Hth,
Dscho
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Junio C Hamano @ 2008-01-16 17:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Bill Lear, Mike, git
In-Reply-To: <alpine.LSU.1.00.0801161244390.17650@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Yes, so you can use
>>
>> $ git --work-tree . --git-dir /some/other/place <some-command>
>>
>> But it's far from the user-friendlyness of a real lightweight checkout:
>> you need to provide the --work-tree and --git-dir options each time you
>> run git. And making an alias or using the environment variables are not
>> really an option if you have more than one repository or working tree to
>> deal with.
>
> Well, the OP said he did not want _any_ file in the worktree. So there's
> no way around specifying by hand everytime where the git directory should
> be.
Export GIT_DIR and GIT_WORKTREE and you are free to go, right?
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 17:31 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP143D18D25EC9A59ABD42D7AE400@CEZ.ICE>
Sean wrote:
> On Tue, 15 Jan 2008 23:07:22 -0500
> Mike <fromlists@talkingspider.com> wrote:
>
>
>>> git archive --help
>>>
>> I got:
>>
>> $ git archive --help
>> No manual entry for git-archive
>>
>> Did I install it wrong? I have CentOS 5, and I did:
>>
>> su
>> yum install git
>>
>
> Yes, on Centos you probably need "yum install git-core" which installs all
> the assorted pieces and dependencies of Git.
>
Thanks but didn't work-
# yum install git-core
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
rpmforge 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
updates 100% |=========================| 951 B 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Parsing package install arguments
Nothing to do
Also if this helps, here's what I have for git:
$ rpm -qa | grep -i git
git-1.5.2.1-1.el5.rf
xorg-x11-drv-digitaledge-1.1.0-1.1
perl-Git-1.5.2.1-1.el5.rf
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 17:23 UTC (permalink / raw)
To: Neil Macneale; +Cc: git
In-Reply-To: <478D95D8.5040806@theory.org>
Neil Macneale wrote:
> Mike wrote:
>> .... And as for permissions and ownership, rsync takes care of that.
> Perhaps "rsync --exclude *.git"?
>
> It seems to me that you are asking git to be your deployment software,
> which is a bad fit.
I'm asking git to get out of my deployment!
^ permalink raw reply
* Re: I don't want the .git directory next to my code.
From: Mike @ 2008-01-16 17:23 UTC (permalink / raw)
To: Luke Lu; +Cc: David Symonds, git, Johannes.Schindelin
In-Reply-To: <D017F6F6-D674-428B-936B-181BF20CF4B5@vicaya.com>
Luke Lu wrote:
>
> On Jan 15, 2008, at 8:18 PM, Mike wrote:
>
>>
>> David Symonds wrote:
>>> On Jan 16, 2008 2:27 PM, Mike <fromlists@talkingspider.com> wrote:
>>>> 2. If I tar/gz my code and deliver it to a client, I don't want the
>>>> .git
>>>> dir slipping into the tarball, allowing my client to be able to peruse
>>>> the history of what we did and when.
>>> Use git-archive.
>>
>> Thanks but this isn't sufficient. If we have one directory of our web
>> root in a git repository, say docroot/php, and we tar up docroot, it
>> will include php/.git. We don't want that. We would have to go out
>> of our way to avoid the .git directory. The point is, we don't want
>> anything in docroot that shouldn't be made live.
>
> git-archive generates an archive file *without* the .git directory. From
> git-archive(1):
>
> git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)
> Create a tar archive that contains the contents of the latest
> commit on the current branch, and extracts it in
> /var/tmp/junk
> directory.
>
> git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >
> git-1.4.0.tar.gz
> Create a compressed tarball for v1.4.0 release.
>
> git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip
> >git-1.4.0.tar.gz
> Create a compressed tarball for v1.4.0 release, but without a
> global extended pax header.
>
> git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ >
> git-1.4.0-docs.zip
> Put everything in the current head's Documentation/ directory
> into git-1.4.0-docs.zip, with the prefix git-docs/.
>
> IMHO, git export is probably a better name for the command. git-archive
> sounds like backup everything associated with git.
>
> __Luke
> -
OK I don't think you read my response closely. I wasn't going to
respond except I see Johannes missed the point too.
I completely understand that git archive will not inlcude the .git dir.
What you missed in my response is the case where someone tars up a
directory above the .git directory. Not all of the content under doc
root is in a git archive.
^ permalink raw reply
* Re: [PATCH v2] Do not show "diff --git" metainfo with --no-prefix
From: Junio C Hamano @ 2008-01-16 17:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Chris Ortman, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801151919440.2806@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So I do not think it's true that "--no-prefix" (or --src/dst-prefix)
> necessarily implies "no-git" at all. It *can* do so, but it's not a given
> thing, and almost certainly isn't in the long run with submodule support.
>
> So it would be kind of sad if we mixed it up with the prefix decision,
> when it really is something totally separate. Many other SCM's may want a
> simple "-p1" patch (BK did, for example), and that doesn't make them
> particularly "git-like". And conversely, git itself will want more than a
> simple "-p1" patch for subproject handling.
Ok. That's a sensible argument.
^ permalink raw reply
* Re: [RFC/PATCH] Remove repo-config
From: Junio C Hamano @ 2008-01-16 17:20 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <478D8AA8.3070008@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> On 01/15/2008 10:23 PM, Junio C Hamano wrote:
>> I do not think it is unreasonable to add repo-config to feature
>> removal schedule in 1.5.4 release notes. Perhaps something like...
>>
>> + * "git repo-config", which was an old name for "git config" command,
>> + has been supported without being advertised for a long time. The
>> + next feature release will remove it.
>> +
>
> Seems fine to me. Does it need to be put in command-list.txt for the time being too, or what all is that file used for? Sorry I am not familiar.
>
> Something like:
>
> git-repo-config ancillarymanipulators deprecated
Technically, you are right, but somehow it feels backwards.
We stopped advertising the existence of the command in v1.5.0,
and adding it to the list now would mean we need to add a new
git-repo-config manual page that says "This is deprecated, use
git-config instead".
^ permalink raw reply
* Re: git on MacOSX and files with decomposed utf-8 file names
From: Jakub Narebski @ 2008-01-16 16:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Ballard, Mark Junker, git
In-Reply-To: <alpine.LSU.1.00.0801161629580.17650@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 16 Jan 2008, Kevin Ballard wrote:
>
> > On Jan 16, 2008, at 10:34 AM, Johannes Schindelin wrote:
> >
> > > On Wed, 16 Jan 2008, Mark Junker wrote:
> > >
> > > > I have some files like "Lüftung.txt" in my repository. The strange
> > > > thing is that I can pull / add / commit / push those files without
> > > > problem but git-status always complains that thoes files are
> > > > untraced (but not missing).
> > >
> > > This is a known problem. Unfortunately, noone has implemented a fix,
> > > although if you're serious about it, I can point you to threads where
> > > it has been hinted how to solve the issue.
> > >
> > > FWIW the issue is that Mac OS X decides that it knows better how to
> > > encode your filename than you could yourself.
> >
> > More like, Mac OS X has standardized on Unicode and the rest of the
> > world hasn't caught up yet. Git is the only tool I've ever heard of that
> > has a problem with OS X using Unicode.
>
> No. That's not at all the problem. Mac OS X insists on storing _another_
> encoding of your filename. Both are UTF-8. Both encode the _same_
> string. Yet they are different, bytewise. For no good reason.
To be more exact encoding used to _create_ file differs from encoding
returned when _reading directory_...
> Stop spreading FUD. Git can handle Unicode just fine. In fact, Git does
> not _care_ how the filename is encoded, it _respects_ the user's choice,
> not only of the encoding _type_, but the _encoding_, too.
...which means that sequence of bytes differ. And Git by design is
(both for filenames and for blob contents) encoding agnostic.
HFS+ is just _stupid_. And unfortunately Git doesn't support stupid
filesystems (e.g. case insensitive filesystems) well.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and binary files
From: Florian Weimer @ 2008-01-16 16:41 UTC (permalink / raw)
To: Petko Manolov; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0801161640010.5260@bender.nucleusys.com>
* Petko Manolov:
>>> Unfortunately this is not the case. These binary blobs are already
>>> compressed and/or encrypted and adding even a few bytes ends up storing
>>> new version in full size.
>>
>> Can't you store them uncompressed?
>
> Not really, but i can convert them into ascii format and store only
> the delta. This will admittedly increase the initial size of the
> repository, but hopefully not by much.
If the encryption is halfway decent, a new IV/nonce will be chosen for
each new revision, and you can't tell that two ciphertexts share a
common prefix without fully decrypting them.
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: git and binary files
From: Jakub Narebski @ 2008-01-16 16:34 UTC (permalink / raw)
To: Petko Manolov; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0801161640010.5260@bender.nucleusys.com>
On Wed, 16 January 2008, Petko Manolov wrote:
> On Wed, 16 Jan 2008, Jakub Narebski wrote:
>> Petko Manolov wrote:
>>> On Wed, 16 Jan 2008, Jakub Narebski wrote:
>>>
>>>> You can always tag a blob (like junio-gpg-pub tag in git.git repository),
>>>> but it wouldn't be in a working directory. But it would get distributed
>>>> on clone.
>>>
>>> Hm, how does it work?
>>
>> You use git-hash-object to put file (-t blob) into the object database.
>> It would return sha1 of added object. Use git-tag to create tag to blob
>> (use returned sha1 for head). You can get file (to stdout) with
>> "git cat-file blob tagname^{blob}".
>
> Sounds like i'll have to play with the above. Thanks for the tip.
>
>> The file would be in object database, but not in working directory
>> by default.
>
> Not a big problem.
Please read carefully section about retagging / changing a tag
in git-tag(1) manpage; you should take care about propagating change
if you ever change the binary blob.
Nothe that I haven't used the technique described.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git on MacOSX and files with decomposed utf-8 file names
From: Johannes Schindelin @ 2008-01-16 16:32 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Mark Junker, git
In-Reply-To: <427BE4FD-6534-4CB2-91F8-F9014DC82B54@sb.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1367 bytes --]
Hi,
On Wed, 16 Jan 2008, Kevin Ballard wrote:
> On Jan 16, 2008, at 10:34 AM, Johannes Schindelin wrote:
>
> > On Wed, 16 Jan 2008, Mark Junker wrote:
> >
> > > I have some files like "Lüftung.txt" in my repository. The strange
> > > thing is that I can pull / add / commit / push those files without
> > > problem but git-status always complains that thoes files are
> > > untraced (but not missing).
> >
> > This is a known problem. Unfortunately, noone has implemented a fix,
> > although if you're serious about it, I can point you to threads where
> > it has been hinted how to solve the issue.
> >
> > FWIW the issue is that Mac OS X decides that it knows better how to
> > encode your filename than you could yourself.
>
> More like, Mac OS X has standardized on Unicode and the rest of the
> world hasn't caught up yet. Git is the only tool I've ever heard of that
> has a problem with OS X using Unicode.
No. That's not at all the problem. Mac OS X insists on storing _another_
encoding of your filename. Both are UTF-8. Both encode the _same_
string. Yet they are different, bytewise. For no good reason.
Stop spreading FUD. Git can handle Unicode just fine. In fact, Git does
not _care_ how the filename is encoded, it _respects_ the user's choice,
not only of the encoding _type_, but the _encoding_, too.
Okay?
Hth,
Dscho
^ permalink raw reply
* Re: Merging using only fast-forward
From: Randal L. Schwartz @ 2008-01-16 16:27 UTC (permalink / raw)
To: Sverre Hvammen Johansen; +Cc: git
In-Reply-To: <loom.20080116T151930-575@post.gmane.org>
>>>>> "Sverre" == Sverre Hvammen Johansen <hvammen@gmail.com> writes:
Sverre> If there are changes on both A and B that have not yet been integrated
Sverre> (by A doing a pull (fetch/rebase)) I want a pull (fetch/merge) on B to
Sverre> fail.
Junio implemented a 7-line patch on the IRC channel (calling parts of it
"for randal" or something, I believe :) to do precisely this.
Perhaps you can test it, and submit it as if it were your idea. I, for one,
would use it as well. I'm doing ugly things with parsing the output of
git-status right now to achieve the same thing.
--
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: git and binary files
From: Petko Manolov @ 2008-01-16 16:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801160958170.25841@xanadu.home>
On Wed, 16 Jan 2008, Nicolas Pitre wrote:
> On Wed, 16 Jan 2008, Petko Manolov wrote:
>
>> On Wed, 16 Jan 2008, Jakub Narebski wrote:
>>
>>> Petko Manolov wrote:
>>>>
>>>> Unfortunately this is not the case. These binary blobs are already
>>>> compressed and/or encrypted and adding even a few bytes ends up storing
>>>> new version in full size.
>>>
>>> Can't you store them uncompressed?
>>
>> Not really, but i can convert them into ascii format and store only the delta.
>
> If you don't have the original uncompressed unencrypted file, what will
> converting them to ascii actually give you?
Not much. I was blindly hoping that bzip2 may compress such files better,
though i haven't tested this hypothesis yet. Will let you know if the
result is different from the obvious one. :-)
Petko
^ permalink raw reply
* Re: git and binary files
From: Petko Manolov @ 2008-01-16 16:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801161056500.25841@xanadu.home>
On Wed, 16 Jan 2008, Nicolas Pitre wrote:
> On Wed, 16 Jan 2008, Petko Manolov wrote:
>
>> On Wed, 16 Jan 2008, Nicolas Pitre wrote:
>>
>>> On Wed, 16 Jan 2008, Petko Manolov wrote:
>>>
>>>> On Wed, 16 Jan 2008, Jakub Narebski wrote:
>>>>
>>>>> Petko Manolov wrote:
>>>>>>
>>>>>> Unfortunately this is not the case. These binary blobs are already
>>>>>> compressed and/or encrypted and adding even a few bytes ends up
>>>>>> storing
>>>>>> new version in full size.
>>>>>
>>>>> Can't you store them uncompressed?
>>>>
>>>> Not really, but i can convert them into ascii format and store only the
>>>> delta.
>>>
>>> If you don't have the original uncompressed unencrypted file, what will
>>> converting them to ascii actually give you?
>>
>> I hope that in the case of incremental changes (0 to 5MB file is the same,
>> last 64KB are actually new) the delta will be small and should be able to
>> compress well.
>>
>> This won't work for random changes along the length of the whole file.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> But my question remains.
>
> If you cannot create good deltas out of your binary files, converting
> those binaries into ascii will do nothing to compression performance.
I did agree with you above. Binary or ascii it doesn't matter.
The experiments so far shows that git is doing a good job finding deltas
in binary files. This may be a solution for certain part of my files...
Petko
^ permalink raw reply
* Merging using only fast-forward
From: Sverre Hvammen Johansen @ 2008-01-16 15:54 UTC (permalink / raw)
To: git
Hi,
I have a work flow where A is only allowed to rebase and B is only allowed to
fast-forward. They both fetch from each other and rebase/merge using pull. On
A I can use the configuration branch.<name>.rebase but it does not seem to be an
option to enforce a fast-forward on B.
If there are changes on both A and B that have not yet been integrated (by A
doing a pull (fetch/rebase)) I want a pull (fetch/merge) on B to fail.
It would be useful with a configuration ala branch.<name>.fast-forward or an
option --ff-only to git-merge so I could use the configuration
branch.<name>.mergeoptions.
Is there any other way to achieve this?
Thanks for a great tool. I am using git with accurev where B is the integrator
between git and accurev (commits flow in both directions). I imagine this could
be useful in other environments as well.
--
Sverre Hvammen Johansen
^ permalink raw reply
* Re: git and binary files
From: Nicolas Pitre @ 2008-01-16 15:58 UTC (permalink / raw)
To: Petko Manolov; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0801161715570.5260@bender.nucleusys.com>
On Wed, 16 Jan 2008, Petko Manolov wrote:
> On Wed, 16 Jan 2008, Nicolas Pitre wrote:
>
> > On Wed, 16 Jan 2008, Petko Manolov wrote:
> >
> > > On Wed, 16 Jan 2008, Jakub Narebski wrote:
> > >
> > > > Petko Manolov wrote:
> > > > >
> > > > > Unfortunately this is not the case. These binary blobs are already
> > > > > compressed and/or encrypted and adding even a few bytes ends up
> > > > > storing
> > > > > new version in full size.
> > > >
> > > > Can't you store them uncompressed?
> > >
> > > Not really, but i can convert them into ascii format and store only the
> > > delta.
> >
> > If you don't have the original uncompressed unencrypted file, what will
> > converting them to ascii actually give you?
>
> I hope that in the case of incremental changes (0 to 5MB file is the same,
> last 64KB are actually new) the delta will be small and should be able to
> compress well.
>
> This won't work for random changes along the length of the whole file.
But my question remains.
If you cannot create good deltas out of your binary files, converting
those binaries into ascii will do nothing to compression performance.
Nicolas
^ 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