* Re: git performance
From: Jeff King @ 2008-10-24 18:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edward Ned Harvey, git
In-Reply-To: <alpine.LFD.2.00.0810241050310.3287@nehalem.linux-foundation.org>
On Fri, Oct 24, 2008 at 10:53:20AM -0700, Linus Torvalds wrote:
> > echo 1 >/proc/sys/vm/drop_caches
>
> Use "echo 3" instead of "1".
>
> It's actually a bitmask, with bit 0 being "data" (pagecache) and bit 1
> being "metadata" (inodes and directory caches).
>
> And since git (or any SCM) is very metadata-intensive, you really should
> make sure to drop metadata too, otherwise your caches won't be really very
> cold at all.
>
> (But it obviously depends on the operation you're testing - some are more
> about the inodes and directories, others are about file data access).
Ah, thanks. In this case, he was interested in walking the directory
tree, so the metadata caching was indeed very important.
-Peff
^ permalink raw reply
* Re: git performance
From: Linus Torvalds @ 2008-10-24 17:53 UTC (permalink / raw)
To: Jeff King; +Cc: Edward Ned Harvey, git
In-Reply-To: <20081024142947.GB11568@coredump.intra.peff.net>
On Fri, 24 Oct 2008, Jeff King wrote:
>
> Side note: on Linux, it is much easier to clear the cache via
>
> echo 1 >/proc/sys/vm/drop_caches
Use "echo 3" instead of "1".
It's actually a bitmask, with bit 0 being "data" (pagecache) and bit 1
being "metadata" (inodes and directory caches).
And since git (or any SCM) is very metadata-intensive, you really should
make sure to drop metadata too, otherwise your caches won't be really very
cold at all.
(But it obviously depends on the operation you're testing - some are more
about the inodes and directories, others are about file data access).
Linus
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 17:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0810241943470.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Fri, Oct 24, 2008 at 7:44 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 23 Oct 2008, Johannes Sixt wrote:
>
>> Giuseppe Bilotta schrieb:
>> > Zit will create a directory .zit.file to hold a git repository
>> > tracking the single file .zit.file/file, which is just a hard link to
>> > file.
>>
>> git breaks hard links, mind you! (Just in case you check out older
>> versions and you wonder why your "real" file is not updated).
>>
>> But there's a recent patch by Dscho floating around that takes care of
>> the hard link case.
>
> Yep, I still want to work on it; it breaks on one of Junio's machines.
Well, it's not needed by Zit anymore, but there was someone else
asking about on the ml recently, too 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git performance
From: George Shammas @ 2008-10-24 17:42 UTC (permalink / raw)
To: git
In-Reply-To: <20081024142947.GB11568@coredump.intra.peff.net>
If you are really trying to backup a filesystem, you may want to look
at a filesystem that can do snapshots, it would be a lot more
efficient then a version control system. Such as NILFS and ZFS.
http://en.wikipedia.org/wiki/NILFS
http://en.wikipedia.org/wiki/ZFS
Both these will allow you to look at changed files over time. NILFS is
slightlly diffrent in that it doesn't take snapshots, because it never
deletes, so you can rollback every change on a file. They both also
allow each user to rollback their own files if they wanted to, so if
this is your goal, source code version control is not for you, and a
good file system is for you.
-G
On Fri, Oct 24, 2008 at 10:29 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Oct 24, 2008 at 12:15:19AM -0400, Edward Ned Harvey wrote:
>
>> Feel free to forward to the list, if anyone's still talking about it.
>> I already un-subscribed.
>
> Posting is not limited to subscribers, so you can happily continue the
> conversation there by cc'ing the list (and I am cc'ing the list here).
>
>> I did my benchmarking at least two months ago, so I forgot the exact
>> results now, so I ran the benchmark once just now. I also downloaded
>> git, and did "git status" for comparison. I rebooted the system in
>> between each trial run, to clear the cache. Here's the results:
>
> Side note: on Linux, it is much easier to clear the cache via
>
> echo 1 >/proc/sys/vm/drop_caches
>
> than to reboot for each benchmark.
>
>> Local disk mirror "time git status" on the same tree. 17,468 versioned files, so the whole tree is 30,647 including .git files
>> 0m 25s cold cache
>> 0m 0.2s warm cache trial 1
>> 0m 0.2s warm cache trial 2
>
> Hmm. That's a lot of increase in files for .git. Did you try repacking
> and then running your test?
>
>> I questioned whether svn and git were causing unnecessary overhead.
>
> Sure, they are doing more than just walking. So there is overhead, but
> it's hard to say how much is unnecessary. However, if you were working
> with an unpacked git, then it may have had to open() a lot of files in
> the object db (keep in mind that status doesn't just show the difference
> between the working tree and the index; it shows the difference between
> the index and the last commit. So maybe "git diff" would be a more
> accurate comparison).
>
>> Conclusions:
>> * For "status" operations on cold cache, large file count, Neither the
>> performance of git or svn approaches the ideal. Both are an order of
>> magnitude slower than ideal, which is still assuming "ideal" requires
>> walking the tree. A better ideal avoids the need to walk the tree,
>> and has near-zero total cost.
>
> Try your git benchmark again with a packed repo, and I think you will
> find it approaches the time it takes to walk the tree.
>
> That being said, if walking the tree is unacceptable to you, then no,
> current git won't work. You would need to patch it to use inotify (once
> upon a time there was some discussion of this, but it never went
> anywhere -- I guess most people work on machines where they can keep the
> cache relatively warm).
>
> -Peff
> --
> 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
>
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Johannes Schindelin @ 2008-10-24 17:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Giuseppe Bilotta, git
In-Reply-To: <49007623.1060606@viscovery.net>
Hi,
On Thu, 23 Oct 2008, Johannes Sixt wrote:
> Giuseppe Bilotta schrieb:
> > Zit will create a directory .zit.file to hold a git repository
> > tracking the single file .zit.file/file, which is just a hard link to
> > file.
>
> git breaks hard links, mind you! (Just in case you check out older
> versions and you wonder why your "real" file is not updated).
>
> But there's a recent patch by Dscho floating around that takes care of
> the hard link case.
Yep, I still want to work on it; it breaks on one of Junio's machines.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Nicolas Pitre @ 2008-10-24 15:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <1224790716-20551-1-git-send-email-trast@student.ethz.ch>
On Thu, 23 Oct 2008, Thomas Rast wrote:
> Replaces the existing simple history search with a more sophisticated
> algorithm:
>
> 1) Walk history with exponentially increasing stride lengths; i.e.,
> send the 1st commit, then the 2nd after that, then the 4th after
> that, and so on.
>
> 2) Bisect the resulting intervals.
>
> Combined with tracking the "outstanding haves" so that we can detect
> which sha1s were never ACKed by upload-pack (and hence not common),
> this gives O(log(n)) required "have" lines.
>
> Unfortunately this cannot work if the server sends fake ACKs, so we
> introduce a capability 'exp-stride' which instructs upload-pack to
> disable ok_to_give_up(). (Which incidentally saves the server a lot
> of work.)
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
>
> ---
>
> This is a simple resend of v2, in the hope of attracting some
> discussion or at least encouraging words this time around.
OK, I gave this a quick try, and fetch operations appear to make their
mind about what to do quicker. Some fetch requests which used to take
up to 5 seconds are somewhat faster. I have no formal measurements
though.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-svn: change dashed git-config to git config
From: Deskin Miller @ 2008-10-24 15:27 UTC (permalink / raw)
To: gitster; +Cc: git, Eric Wong
In-Reply-To: <20081024091544.GB27362@untitled>
On Fri, Oct 24, 2008 at 02:15:44AM -0700, Eric Wong wrote:
> Deskin Miller <deskinm@umich.edu> wrote:
> > ---
> > When testing git-svn changes, I'll often use git-svn.perl directly on a
> > repository of mine, to see how things work. Recently I had this happen:
> >
> > $ git-svn.perl info
> > Use of uninitialized value in scalar chomp at ../git/git-svn.perl line 1202.
> > Use of uninitialized value in concatenation (.) or string at ../git/git-svn.perl line 1203.
> >
> > but the expected output showed up correctly, giving the SVN-like info.
> >
> > git svn info appeared to work just fine though, despite there being essentially
> > no difference between the two. However, if I do the following, this is what I
> > see:
> >
> > $ env /usr/libexec/git-core/git-svn info
> > Can't exec "git-config": No such file or directory at /usr/libexec/git-core/git-svn line 1202.
> > Use of uninitialized value in scalar chomp at /usr/libexec/git-core/git-svn line 1202.
> >
> > Again, the SVN info would still appear.
> >
> > Regardless, I think we want to change this call to use the non-dashed form.
>
> Thanks Deskin,
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
Sorry, patch should have had a
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Feel free to forge it.
> > Deskin Miller
> >
> > git-svn.perl | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 33e1b50..2e68c68 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1126,7 +1126,7 @@ sub read_repo_config {
> > my $v = $opts->{$o};
> > my ($key) = ($o =~ /^([a-zA-Z\-]+)/);
> > $key =~ s/-//g;
> > - my $arg = 'git-config';
> > + my $arg = 'git config';
> > $arg .= ' --int' if ($o =~ /[:=]i$/);
> > $arg .= ' --bool' if ($o !~ /[:=][sfi]$/);
> > if (ref $v eq 'ARRAY') {
> > --
> > 1.6.0.2.554.g3041b
^ permalink raw reply
* Re: git performance
From: Jeff King @ 2008-10-24 14:29 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000001c9358f$232bac70$69830550$@com>
On Fri, Oct 24, 2008 at 12:15:19AM -0400, Edward Ned Harvey wrote:
> Feel free to forward to the list, if anyone's still talking about it.
> I already un-subscribed.
Posting is not limited to subscribers, so you can happily continue the
conversation there by cc'ing the list (and I am cc'ing the list here).
> I did my benchmarking at least two months ago, so I forgot the exact
> results now, so I ran the benchmark once just now. I also downloaded
> git, and did "git status" for comparison. I rebooted the system in
> between each trial run, to clear the cache. Here's the results:
Side note: on Linux, it is much easier to clear the cache via
echo 1 >/proc/sys/vm/drop_caches
than to reboot for each benchmark.
> Local disk mirror "time git status" on the same tree. 17,468 versioned files, so the whole tree is 30,647 including .git files
> 0m 25s cold cache
> 0m 0.2s warm cache trial 1
> 0m 0.2s warm cache trial 2
Hmm. That's a lot of increase in files for .git. Did you try repacking
and then running your test?
> I questioned whether svn and git were causing unnecessary overhead.
Sure, they are doing more than just walking. So there is overhead, but
it's hard to say how much is unnecessary. However, if you were working
with an unpacked git, then it may have had to open() a lot of files in
the object db (keep in mind that status doesn't just show the difference
between the working tree and the index; it shows the difference between
the index and the last commit. So maybe "git diff" would be a more
accurate comparison).
> Conclusions:
> * For "status" operations on cold cache, large file count, Neither the
> performance of git or svn approaches the ideal. Both are an order of
> magnitude slower than ideal, which is still assuming "ideal" requires
> walking the tree. A better ideal avoids the need to walk the tree,
> and has near-zero total cost.
Try your git benchmark again with a packed repo, and I think you will
find it approaches the time it takes to walk the tree.
That being said, if walking the tree is unacceptable to you, then no,
current git won't work. You would need to patch it to use inotify (once
upon a time there was some discussion of this, but it never went
anywhere -- I guess most people work on machines where they can keep the
cache relatively warm).
-Peff
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 14:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <4901D557.90106@viscovery.net>
On Fri, Oct 24, 2008 at 04:01:59PM +0200, Johannes Sixt wrote:
> Your reasoning makes sense, of course. (I thought that forgoing textconv
> in these cases would have a simpler implementation; but it can't be a lot
> simpler than yours.)
Yeah, I think preventing it entirely for this case would be much more
complex, since you would have to realize much sooner that a textconv was
going to happen.
> > +test_expect_failure 'textconv does not act on symlinks' '
> Can we trust your solution if you still have 'test_expect_failure' here? ;-)
Heh. It helps if I commit before format-patch. ;) Fortunately, this was
the only change I missed out on sending.
-Peff
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Johannes Sixt @ 2008-10-24 14:01 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024135132.GA11568@coredump.intra.peff.net>
Jeff King schrieb:
> On Fri, Oct 24, 2008 at 09:15:54AM +0200, Johannes Sixt wrote:
> Actually, I don't think this is right. The typechange has been broken
> into two parts: the removal of the file contents and the addition of the
> symlink. So the first part _should_ use the textconv, since it is just
> comparing the file contents to /dev/null. But the second part should
> not, since it is by definition just the text of the symlink. Ditto for
> gitlinks, which have a special text representation. So how about this?
Your reasoning makes sense, of course. (I thought that forgoing textconv
in these cases would have a simpler implementation; but it can't be a lot
simpler than yours.)
> diff --git a/diff.c b/diff.c
> index 52feba7..ce1317d 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -289,6 +289,9 @@ static int diff_filespec_textconv(struct diff_filespec *one)
> if (!DIFF_FILE_VALID(one))
> return 0;
>
> + if (!S_ISREG(one->mode))
> + return 0;
> +
> diff_filespec_load_driver(one);
> if (!one->driver->textconv)
> return 0;
...
> +test_expect_failure 'textconv does not act on symlinks' '
Can we trust your solution if you still have 'test_expect_failure' here? ;-)
-- Hannes
^ permalink raw reply
* [PATCH/RFC] Introduce a built-in attribute "text"
From: Michael J Gruber @ 2008-10-24 13:55 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
"text is the opposite of "binary": It sets the attributes "crlf" and
"diff". It is needed because attribute macros can't be negated,
and some users may want to force git into treating certain files as
text which are not recognized by the internal logic.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This gives the user the chance to mess up completely (given an
"appropriate" setting of autocrlf), but I still think it's a good idea
to have that "-binary" built-in. attributes aren't used by noobs anyways.
In many cases, "diff" might be preferred over "text". Should I add a warning
to the doc?
Michael
Documentation/gitattributes.txt | 4 +++-
attr.c | 1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2694559..2a00f8c 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -510,7 +510,9 @@ the same time. The system knows a built-in attribute macro, `binary`:
which is equivalent to the above. Note that the attribute macros can only
be "Set" (see the above example that sets "binary" macro as if it were an
ordinary attribute --- setting it in turn unsets "crlf" and "diff").
-
+Therefore, there is also a built-in attribute macro `text` which allows
+you to mark certain files as text which git does not recognize automatically.
+It is equivalent to setting `crlf diff`.
DEFINING ATTRIBUTE MACROS
-------------------------
diff --git a/attr.c b/attr.c
index 17f6a4d..63e2837 100644
--- a/attr.c
+++ b/attr.c
@@ -283,6 +283,7 @@ static void free_attr_elem(struct attr_stack *e)
static const char *builtin_attr[] = {
"[attr]binary -diff -crlf",
+ "[attr]text diff crlf",
NULL,
};
--
1.6.0.3.514.g2f91b
^ permalink raw reply related
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 13:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <4901762A.3090003@viscovery.net>
On Fri, Oct 24, 2008 at 09:15:54AM +0200, Johannes Sixt wrote:
> +cat >expect.typechange <<'EOF'
> +Binary files a/file and /dev/null differ
> +diff --git a/file b/file
> +new file mode 120000
> +index ad8b3d2..67be421
> +--- /dev/null
> ++++ b/file
> +@@ -0,0 +1 @@
> ++frotz
> +\ No newline at end of file
> +EOF
Actually, I don't think this is right. The typechange has been broken
into two parts: the removal of the file contents and the addition of the
symlink. So the first part _should_ use the textconv, since it is just
comparing the file contents to /dev/null. But the second part should
not, since it is by definition just the text of the symlink. Ditto for
gitlinks, which have a special text representation. So how about this?
-- >8 --
only textconv regular files
We treat symlinks as text containing the results of the
symlink, so it doesn't make much sense to text-convert them.
Similarly gitlink components just end up as the text
"Subproject commit $sha1", which we should leave intact.
Note that a typechange may be broken into two parts: the
removal of the old part and the addition of the new. In that
case, we _do_ show the textconv for any part which is the
addition or removal of a file we would ordinarily textconv,
since it is purely acting on the file contents.
Signed-off-by: Jeff King <peff@peff.net>
---
diff.c | 3 +++
t/t4030-diff-textconv.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 52feba7..ce1317d 100644
--- a/diff.c
+++ b/diff.c
@@ -289,6 +289,9 @@ static int diff_filespec_textconv(struct diff_filespec *one)
if (!DIFF_FILE_VALID(one))
return 0;
+ if (!S_ISREG(one->mode))
+ return 0;
+
diff_filespec_load_driver(one);
if (!one->driver->textconv)
return 0;
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index e456746..a5cd99b 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -19,6 +19,22 @@ cat >expect.text <<'EOF'
+1
EOF
+cat >expect.typechange <<'EOF'
+--- a/file
++++ /dev/null
+@@ -1,2 +0,0 @@
+-0
+-1
+diff --git a/file b/file
+new file mode 120000
+index ad8b3d2..67be421
+--- /dev/null
++++ b/file
+@@ -0,0 +1 @@
++frotz
+\ No newline at end of file
+EOF
+
cat >hexdump <<'EOF'
#!/bin/sh
perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
@@ -75,4 +91,16 @@ test_expect_success 'format-patch produces binary' '
test_cmp expect.binary actual
'
+# make a symlink the hard way that works on symlink-challenged file systems
+test_expect_failure 'textconv does not act on symlinks' '
+ echo -n frotz > file &&
+ git add file &&
+ git ls-files -s | sed -e s/100644/120000/ |
+ git update-index --index-info &&
+ git commit -m typechange &&
+ git show >diff &&
+ find_diff <diff >actual &&
+ test_cmp expect.typechange actual
+'
+
test_done
--
1.6.0.3.523.ge05eb.dirty
^ permalink raw reply related
* Re: git adds some text file as binary file by mistake
From: Michael J Gruber @ 2008-10-24 13:51 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320810240630s5cbfa62esd10a9da45ce37bf8@mail.gmail.com>
Ping Yin venit, vidit, dixit 24.10.2008 15:30:
> On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
>>> So what should i do if i want it added as text file?
>> You should give us more detail on the file ;)
>> What's the extension, what's the typical content? It may be a simple
>> matter of specifying attributes.
>> Do ordinary diff and grep recognize your files as text?
>>
>> Michael
>>
>
> It's just an xml file. I guess maybe there are some hidden characters
> at the beginning. I will figure it out later because i have no access
> to that file right now.
Maybe it's in an encoding which is not available on the machine you're
using git on?
> I'm just ask this problem in general sense. So is there a general way
> to specify whether a file is text or binary?
Bruce suggested a good read. To save you some time: You want to say
*.xml diff
or
*.xml diff crlf
in one of the attributes files, depending on whether you want git to
possibly translate line endings (which depends on other settings also).
Note that the "content type" of the file plays a role only for diffs and
stats, not for the actual storage (except for, possibly, crlf conversion).
Cheers,
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Jakub Narebski @ 2008-10-24 13:45 UTC (permalink / raw)
To: git
In-Reply-To: <7v8wsf50ne.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
> - gitweb: generate parent..current URLs
> - gitweb: parse parent..current syntax from PATH_INFO
> - gitweb: use_pathinfo filenames start with /
> - gitweb: generate project/action/hash URLs
> - gitweb: parse project/action/hash_base:filename PATH_INFO
>
> Seventh iteration; hopefully the usual gitweb gangs will give quick
> comments and ack to push this out to 'next' soon.
If I remember correctly v7 is mainly cosmetic changes, and I have
acked all or almost all of the equivalent patches from v6.
> * gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
> + gitweb: refactor input parameters parse/validation
>
> A major cleanup on the way gitweb parses its input arguments.
> Future gitweb patches to add more arguments into the PATH_INFO
> depend upon this initial cleanup work.
Nice.
> * jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
> - gitweb: Better processing format string in custom links in navbar
>
> Waiting for some sort of response from Pasky.
>
> * jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
> + Fix reading of cloud tags
>
> Request-for-review-and-ack sent; waiting for response.
It would be nice to have those two...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Bruce Stephens @ 2008-10-24 13:34 UTC (permalink / raw)
To: Ping Yin; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <46dff0320810240630s5cbfa62esd10a9da45ce37bf8@mail.gmail.com>
"Ping Yin" <pkufranky@gmail.com> writes:
[...]
> I'm just ask this problem in general sense. So is there a general way
> to specify whether a file is text or binary?
Yes: gitattributes(5).
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Ping Yin @ 2008-10-24 13:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4901C58D.4010309@drmicha.warpmail.net>
On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
>> So what should i do if i want it added as text file?
>
> You should give us more detail on the file ;)
> What's the extension, what's the typical content? It may be a simple
> matter of specifying attributes.
> Do ordinary diff and grep recognize your files as text?
>
> Michael
>
It's just an xml file. I guess maybe there are some hidden characters
at the beginning. I will figure it out later because i have no access
to that file right now.
I'm just ask this problem in general sense. So is there a general way
to specify whether a file is text or binary?
--
Ping Yin
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Michael J Gruber @ 2008-10-24 12:54 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320810240537i4f0d86b9p56def9ef6a69c180@mail.gmail.com>
Ping Yin venit, vidit, dixit 24.10.2008 14:37:
> So what should i do if i want it added as text file?
You should give us more detail on the file ;)
What's the extension, what's the typical content? It may be a simple
matter of specifying attributes.
Do ordinary diff and grep recognize your files as text?
Michael
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 12:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <4901762A.3090003@viscovery.net>
On Fri, Oct 24, 2008 at 09:15:54AM +0200, Johannes Sixt wrote:
> What do we do when symlinks are involved? Pilot error? Or should we
> exclude them from textconv (and diff.*.command, for that matter)
> at all times? See a test case below.
Hrm, I hadn't really considered that. I would guess they should not be
excluded from diff.*.command; the external driver gets the mode, so it
is free to represent symlinks in whatever way it wants.
But clearly they are going to always be text, so there is no point in
textconv'ing them.
> +cat >expect.typechange <<'EOF'
> +Binary files a/file and /dev/null differ
> +diff --git a/file b/file
> +new file mode 120000
> +index ad8b3d2..67be421
> +--- /dev/null
> ++++ b/file
> +@@ -0,0 +1 @@
> ++frotz
> +\ No newline at end of file
> +EOF
> +
I find this output a bit confusing, since it actually breaks it into a
deletion and an addition. But I guess that is orthogonal to the textconv
issue, and intended. I don't think I've ever actually needed to diff a
symlink before.
-Peff
^ permalink raw reply
* git adds some text file as binary file by mistake
From: Ping Yin @ 2008-10-24 12:37 UTC (permalink / raw)
To: Git Mailing List
So what should i do if i want it added as text file?
--
Ping Yin
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <200810241332.32487.jnareb@gmail.com>
On Fri, Oct 24, 2008 at 1:32 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> By the way RCS which I use for version control of single files use
>>> both approaches: it can store 'file,v' alongside 'file' (just like
>>> your '.zit.file/' or '.file.git/'), but it can also store files on
>>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>>> '.zit/file.git/' solution)
>>
>> Indeed, there's not particular reason why both solutions shouldn't be
>> available. [...]
>
>> The only problem then is priority. When looking for a file's repo, do
>> we look at .file.git first, or .zit/file.git? How does RCS behave in
>> this case?
>
> rcsintro(1) states:
>
> If you don't want to clutter your working directory with RCS files, create
> a subdirectory called RCS in your working directory, and move all your RCS
> files there. RCS commands will look *first* into that directory to find
> needed files.
Cool. I pushed changes to this end to git.oblomov.eu/zit --now zit
will look for .zit/file.git first, then for .file.git; if neither is
found, and .zit/ exists, the repo is set to .zit/file.git, otherwise
it's set to .file.git
You can either manually mkdir .zit, or use zit init that does exactly
the same thing.
>>> By the way, it would be nice to have VC interface for Emacs for Zit...
>>
>> I'm afraid someone else will have to take care of that, since Emacs is
>> not really something I use.
>
> I'll try to hack it using contrib/emacs/vc-git.el as a base...
Cool, thanks.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 11:32 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810240352u28bab2b5p907065680985270a@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>>> If you decide against a shared repository, maybe you want to
>>>> consider to not use ".zit.file/", but ".zit/file/" as the
>>>> repository? This would reduce the clutter to a single directory,
>>>> just like with ".git". And moving files around wouldn't be that
>>>> much complicated.
>>>
>>> Right. I'll give that a shot.
>>
>> By the way RCS which I use for version control of single files use
>> both approaches: it can store 'file,v' alongside 'file' (just like
>> your '.zit.file/' or '.file.git/'), but it can also store files on
>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>> '.zit/file.git/' solution)
>
> Indeed, there's not particular reason why both solutions shouldn't be
> available. [...]
> The only problem then is priority. When looking for a file's repo, do
> we look at .file.git first, or .zit/file.git? How does RCS behave in
> this case?
rcsintro(1) states:
If you don't want to clutter your working directory with RCS files, create
a subdirectory called RCS in your working directory, and move all your RCS
files there. RCS commands will look *first* into that directory to find
needed files.
>> By the way, it would be nice to have VC interface for Emacs for Zit...
>
> I'm afraid someone else will have to take care of that, since Emacs is
> not really something I use.
I'll try to hack it using contrib/emacs/vc-git.el as a base...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 11:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m34p32i83f.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
> [...]
>
> Could you add it to Git Wiki page:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>
> I think that the project is interesting enough to be added there
> even if it is still in beta, or even alpha, stage.
Ah, good idea. Done, in Version Control Interface layers section
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 10:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <m38wsei8ne.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>
>> > If you decide against a shared repository, maybe you want to
>> > consider to not use ".zit.file/", but ".zit/file/" as the
>> > repository? This would reduce the clutter to a single directory,
>> > just like with ".git". And moving files around wouldn't be that
>> > much complicated.
>>
>> Right. I'll give that a shot.
>
> By the way RCS which I use for version control of single files use
> both approaches: it can store 'file,v' alongside 'file' (just like
> your '.zit.file/' or '.file.git/'), but it can also store files on
> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
> '.zit/file.git/' solution)
Indeed, there's not particular reason why both solutions shouldn't be
available. I'll think about implementing it this way:
$ zit init
will indicate that we want to track many files, and thus it will
create a .zit directory under which RCS files will be available.
$ zit track somefile
will start tracking somefile by setting up .zit/somefile.git if .zit
is available or .somefile.git otherwise.
The only problem then is priority. When looking for a file's repo, do
we look at .file.git first, or .zit/file.git? How does RCS behave in
this case?
> By the way, it would be nice to have VC interface for Emacs for Zit...
I'm afraid someone else will have to take care of that, since Emacs is
not really something I use.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdqbta$rhe$1@ger.gmane.org>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
> .file.git/ to track file's history. .file.git/info/excludes is
> initialized to the very strong '*' pattern to ensure that things such
> as git status etc only consider the actually tracked file.
[...]
Could you add it to Git Wiki page:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
I think that the project is interesting enough to be added there
even if it is still in beta, or even alpha, stage.
P.S. Currently I cannot access git.or.cz for some reason (it is
up for everyone else, and even for me on different remote machine).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810232355u6de0479cyc260c80227f44e59@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
> > If you decide against a shared repository, maybe you want to
> > consider to not use ".zit.file/", but ".zit/file/" as the
> > repository? This would reduce the clutter to a single directory,
> > just like with ".git". And moving files around wouldn't be that
> > much complicated.
>
> Right. I'll give that a shot.
By the way RCS which I use for version control of single files use
both approaches: it can store 'file,v' alongside 'file' (just like
your '.zit.file/' or '.file.git/'), but it can also store files on
per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
'.zit/file.git/' solution)
By the way, it would be nice to have VC interface for Emacs for Zit...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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