* Re: [PATCH] Documentation/gitignore.txt: Fix the seriously misleading priority explanation
From: Junio C Hamano @ 2007-07-22 6:04 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85wswtp8va.fsf@lola.goethe.zz>
Your rewrite makes "patterns found in deeper file overrides the
ones in shallower ones" rule much much easier to read. Thanks.
^ permalink raw reply
* Re: [PATCH] Added 'git-rev-list --igrep' option for case insensitive grep
From: Junio C Hamano @ 2007-07-22 5:53 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950707212233h6047ecfas645b71b9b4c6317e@mail.gmail.com>
Are there notable side effects you would need to warn users
about?
For example, what is the difference between "--igrep=foo
--author=bar" and "--grep=foo --author=bar"?
^ permalink raw reply
* [PATCH] Added 'git-rev-list --igrep' option for case insensitive grep
From: Dmitry Kakurin @ 2007-07-22 5:33 UTC (permalink / raw)
To: git
>From 4b16e1823875f0051e3f0590803ab67dd3ca341d Mon Sep 17 00:00:00 2001
From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Date: Sat, 21 Jul 2007 22:22:49 -0700
Subject: [PATCH] Added 'git-rev-list --igrep' option for case insensitive grep
---
Documentation/git-rev-list.txt | 6 +++++-
revision.c | 5 +++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 08e7573..f427862 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -26,7 +26,7 @@ SYNOPSIS
[ \--left-right ]
[ \--cherry-pick ]
[ \--encoding[=<encoding>] ]
- [ \--(author|committer|grep)=<pattern> ]
+ [ \--(author|committer|grep|igrep)=<pattern> ]
[ \--regexp-ignore-case ] [ \--extended-regexp ]
[ \--date={local|relative|default|iso|rfc|short} ]
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
@@ -227,6 +227,10 @@ limiting may be applied.
Limit the commits output to ones with log message that
matches the specified pattern (regular expression).
+--igrep='pattern'::
+
+ Equivalent to --grep='pattern' --regexp-ignore-case.
+
--regexp-ignore-case::
Match the regexp limiting patterns without regard to letters case.
diff --git a/revision.c b/revision.c
index 28b5f2e..d5e1e69 100644
--- a/revision.c
+++ b/revision.c
@@ -1165,6 +1165,11 @@ int setup_revisions(int argc, const char
**argv, struct rev_info *revs, const ch
add_message_grep(revs, arg+7);
continue;
}
+ if (!prefixcmp(arg, "--igrep=")) {
+ add_message_grep(revs, arg+8);
+ regflags |= REG_ICASE;
+ continue;
+ }
if (!prefixcmp(arg, "--extended-regexp")) {
regflags |= REG_EXTENDED;
continue;
--
1.5.2.3
^ permalink raw reply related
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Junio C Hamano @ 2007-07-22 5:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matt McCutchen, git, Petr Baudis, Luben Tuikov
In-Reply-To: <200707220130.28516.jnareb@gmail.com>
Thanks. Will apply.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 4:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707212040340.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>>
>> "." _is_ visible and detectable in every tree.
>
> I'm going to add you to my "clueless" filter, because it's not worth
> my time to answr you any more.
Too bad I can't do the same.
> I told you. Several times. That "." is pointless exactly because
> it's in _every_ tree, and as such is no longer "content".
"." is in every _non-empty_ directory tree. But we are talking about
permitting _empty_ trees in the repository. And for an empty tree in
the repository, "." may or may not be in the corresponding work
directory tree, depending on whether the directory exists or not. So
when we are talking about a repository tree _becoming_ empty, we need
the information whether or whether not we should remove it upon
becoming empty. _That_ is the information content of "." being or not
being considered part of the trackable material. And the information
is no longer available at the time the repository tree becomes empty
_unless_ we already store it there when the tree is still populated.
> It's not something that the user can care about, because it has no
> meaning. There's no point in tracking it, because even if we do
> *not* track it, it's there, and we cannot do anything about it.
Ok, here we go _again_. Test case 1:
mkdir a
touch a/b
git-add a/b
git-commit -m x
git-rm a/b
git-commit -m x
Now we want to have the directory a _removed_.
Test case 2:
mkdir a
touch a/b
git-add a
git-commit -m x
git-rm a/b
git-commit -m x
Now we want to have the directory a _retained_.
After the first commit in _both_ test cases, the only file in the
trees / and /a is a/b. The working directory state is _identical_ at
this point, and we do identical commands afterwards.
The end result is not identical, so there must be some information
different in the repository after the first commit. This information
_can't_ be encoded in a remaining empty tree, because both the trees /
and /a are _non_-empty yet.
So we _must_ encode the evaporate-or-not-when-empty information
_otherwise_ into the repository. And we do that by _not_ having
/a/. in the set of tracked files in test case 1, and by _having_ it in
the set of tracked files in test case 2.
> That was the whole difference between "." and ".gitignore", and I
> explicitly pointed out that that was the difference (and the _only_
> one), and why it mattered.
You are underestimating the power of ".gitignore": while it is true
that its _physical_ presence will reliably keep git from removing the
directory, its physical presence is not _actually_ required.
It is sufficient that git _believes_ in its continuing physical
existence. And if we tell it "it is still there" whenever it takes a
look, then git will keep the record of .gitignore in its tree, and
consequently won't remove the tree and not try deleting the directory.
However, once we explicitly tell it "remove the record of .gitignore
from the repository", it will do so, and in the course of doing so
remove the directory in the work directory together with the tree in
the repository.
>From a user interface and logical standpoint, adding or not adding "."
to the tracked content is a perfectly consistent and convenient way of
having the directory kept around or not.
>From the viewpoint of the internal data structures, I'll likely go
with tampering with (pseudo-)permissions.
> And you didn't listen. And now you claim that I don't read your
> emails. I do. They just don't make any sense.
>
> Consider this discussion ended. I simply don't care any more.
It is painfully clear that I could invest a few weeks of time in
coding better than in explaining stuff. And I guess that's what I'll
have to do. And afterwards it will be your job to wrack your head
about why something does all the right things for the wrong reasons
and come up with a different explanation how and why the code works.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-22 4:00 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, git
In-Reply-To: <85tzrxslms.fsf@lola.goethe.zz>
On Jul 21, 2007, at 1:38 PM, David Kastrup wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So git filenames are very much a "stream of bytes", not anything
>> else. And they need to sort 100% reliably, always the same way, and
>> never with any localized meaning.
>
> There is some utf-8/Unicode trouble to be expected in connection with
> that eventually: some, but not all operating and/or file systems
> canonicalize file names, replacing accented letters by a combining
> accent and the letter. But that's beside the point.
This issue exists today. OS X does a number of things to filenames,
one of which is normalizing all UTF. The resulting error is wholly
non-intuitive, but easy to solve. Git thinks both that the file
exists under the name it expects and that the file is being ignored
as the name OS X uses. The solution is to put the OS X normalized
form into .git/info/exclude. Any other solution involves platform-
dependent hackery and inclusion of Unicode libraries. I perused this
for a short while some months ago, but was convinced to leave it be.
~~ Brian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 3:43 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85fy3hp3f2.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
>
> "." _is_ visible and detectable in every tree.
I'm going to add you to my "clueless" filter, because it's not worth my
time to answr you any more.
I told you. Several times. That "." is pointless exactly because it's in
_every_ tree, and as such is no longer "content". It's not something that
the user can care about, because it has no meaning. There's no point in
tracking it, because even if we do *not* track it, it's there, and we
cannot do anything about it.
That was the whole difference between "." and ".gitignore", and I
explicitly pointed out that that was the difference (and the _only_ one),
and why it mattered.
And you didn't listen. And now you claim that I don't read your emails. I
do. They just don't make any sense.
Consider this discussion ended. I simply don't care any more.
Linus
^ permalink raw reply
* Re: segfault in diff-delta.c on mac os x (commit 8433669)
From: Brian Gernhardt @ 2007-07-22 3:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <C10CCDA5-6D65-445E-92F3-2D3E4DCA4F8B@zib.de>
On Jul 21, 2007, at 11:15 AM, Steffen Prohaska wrote:
> 843366961cf14aad6490fbeb30f7b98f37f8833a may cause segfaults on
> Mac OS X. See backtrace below. I only observed the segfault with
> -O2 builds.
I have been using git on my OS X box for quite a while, and that
commit appears to be nearly two months old. I have yet to see any
packing errors in any of my repositories. (This is with -O2, which
appears to be the default.)
My gcc reports itself as build 5367 instead of 5250. Perhaps there
is a compiler error in an older copy of the DevTools?
Also, did this segfault occur with any publicly available repo or is
it your own work?
~~ Brian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 2:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707211840000.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>> Make it have an empty reference, and it is unique.
>
> I *really* don't see the point.
>
> And you seem to have igored totally my treatise on "content" and how
> the stuff git tracks must be stuff that is visible and detectable in
> the trees.
Oh please. Just because you refuse to read a point-to-point reply
does not mean it has not been made.
"." _is_ visible and detectable in every tree. But that does not mean
it is automatically tracked by git unless it gets added explicitly, or
implicitly (as long as the gitignore mechanism does not kick in) by
adding a higher level directory.
If a file does not get added explicitly or implicitly, it does not end
up in the repository and git behaves like it knows nothing about it.
And that's just the way it is going to be with directories. Nothing
more, nothing less, nothing new.
> And if I understand you correctly, you also wouldn't be backwards
> compatible.
Define backwards compatible. Anyway, you are the repository wizard:
here are the semantics I need supported for backwards compatibility:
I need an entry type in the index and in the repository with the
following features:
a) if part of a tree, the tree is not considered empty. Should be
easy.
b) it has the name ".". This is not absolutely necessary, but it
means that the gitignore mechanism can be used for dealing with it,
and that's intuitive and has exactly the expressive power required
for the job. Now the gitignore mechanism is isolated very locally
in dir.c: whether one makes the actual representation in the
repository based on an attribute like "filemode" rather than on a
separate entry does not actually complicate the code all too much.
There is, however, some level of complication since the consulted
.gitignore file for ignoring "." must, of course, be the .gitignore
file situated _in_ the directory. So making "." sit _in_ the tree
rather than _on_ the tree simplifies the code considerably. It is
a small amount of code, nevertheless, so it is not a major
strategic decision.
One conceivable implementation would be indeed similar to what the
"filemode" thing does: let us keep open the option to track, at one
time, permissions. The current format has, as far as I understand,
all zeros in the permissions field of trees (I have not checked,
though). Now if we stipulate that this is the kind of directory
permissions we will in all eternity _not_ support outside of git,
we are all set with regard to backwards compatibility: a tree with
permissions all zero will behave as previously: it will get removed
when it becomes empty (taking the corresponding work tree directory
with it, if possible). And that's it. But a tree with nonzero
permissions (whether they correspond to outward permissions or are
just a placeholder) will _not_ evaporate when becoming empty. It
will be possible to explicitly or implicitly delete it: that will
just set its permissions all to zero so that it has the chance to
evaporate next time it becomes empty.
> IOW, there's a lot of "why's" at all levels.
>
> I don't see the *point*. What's the problem you're trying to solve?
rm -rf ./*
git-commit -m "all empty" -a
unzip /tmp/something-with-empty-dirs.zip
git-add .
git-commit -m "something-with-empty-dirs"
git-checkout HEAD~1
# Now I don't want empty directories and their parents lying around.
git-checkout master
# Now the state after unzip should be restored faithfully
rm -rf ./*
unzip /tmp/something-else-with-empty-dirs
git-commit -a -m "something-else"
# Now I want to have the state of something-else registered faithfully
# even if it contains top-level files and directories not present in
# something-with-empty-dirs, because supposedly . is being tracked,
# not just every file element in it.
Actually, oops. This last criterion is not met when .'s relation to
the tree is such that it is only considered _part_ of tree.
Looks like it might be prudent to focus on the permissions-coupled
representation.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 1:41 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85r6n1p7sb.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
> Make it have an empty reference, and it is unique.
I *really* don't see the point.
And you seem to have igored totally my treatise on "content" and how the
stuff git tracks must be stuff that is visible and detectable in the
trees. And if I understand you correctly, you also wouldn't be backwards
compatible.
IOW, there's a lot of "why's" at all levels.
I don't see the *point*. What's the problem you're trying to solve?
Linus
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 1:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f7uap7$eo1$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup wrote:
>
>> I must be really bad at explaining things, or I am losing a fight
>> against preconceptions fixed beyond my imagination.
>
> I don't understand you, or you don't understand git. "Tree" object
> in object database (in repository) represents a directory in the
> working area. There was never any problem with having empty trees in
> object database, or having links to empty directory in the superdir.
> We don't have to change anything about object database.
I disagree here. The object database _can_ represent an _empty_
directory that has been added explicitly, because up to now no
operations existed that actually left an empty tree. But it can't
distinguish a _non_-empty directory that has been added explicitly
from non-empty directory that has not been added explicitly.
To wit: after the sequence
mkdir a
touch a/b
git-add a
git-commit -m x
git-rm a/b
git-commit -m x
I expect git to retain an empty directory a. But the _tree_ now can't
be different from the tree in the situation
mkdir a
touch a/b
git-add a/b
git-commit -m x
git-rm a/b
git-commit -m x
because after step 1, the trees have identical contents, and so there
is nothing at the _identical_ step 2 that could cause different
behavior.
But in the second case, git must _not_ retain a. So we need to record
the information that in the first case, a was added explicitly. And
this can't be done with the current repository layout. It doesn't buy
us anything that we _have_ a representation available for an _empty_
tree added explicitly. We need this "added explicitly" information
for _every_ tree, not just empty ones.
And a perfectly consistent way is to make those trees with an
explicitly added directory _non-empty_, by virtue of putting a file
"." in them. This file, of course, exists in every physical
directory, but we may or may not decide to let it be tracked by git,
using the gitignore mechanism on the pattern ".". Perfectly
expedient.
> The problems with git problems with empty directories stems from the
> fact that index didn't have directories.
That basically implies that no information about directories could be
tracked in the repository. And yes, we need appropriate information
in the index. Again, the information whether a directory was added
explicitly.
> Index is flattened version of root tree, and before subproject
> support it contained _only_ info about blobs (file contents).
And the repository is a versioned and hierarchically hashed version of
the index, but its trees contain _no_ information that is not already
inherently represented by the files alone. Permitting empty trees
would change that fundamental property, and it would not buy us the
ability to actually track directories: see above. So it is not worth
the trouble to assign any meaningful concept to persisting empty trees
rather than make them a case for git-fsck.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-22 1:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paolo Ciarrocchi,
しらいしななこ,
Shawn O. Pearce, Christian Stimming, git
In-Reply-To: <7vvecdtlf1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 21 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> paolo@paolo-desktop:~/git-gui-i18n$ ls po/
> >> de.msg de.po glossary.csv ja.msg ja.po
> >>
> >> There is "po/git-gui.pot" file in my repository.
> >
> > My fault. I was rebasing Junio's patch on top of Christian's new series.
> > Alas, the PO_TEMPLATE was no longer created by default.
> >
> > Should be fixed now.
>
> Note that if everybody agrees that the division of labor between
> the developer, the i18n coordinator and translators I suggested
> in the earlier message is the way to go, po/git-gui.pot should
> be managed by the i18n coordinator and revision tracked in-tree.
> Simple "make" should not try to update it for ordinary people,
> but we can have a "i18n coordinator only" maintenance target to
> update it.
>
> That way, translators do not have to touch anything other than
> their own po/xx.po files.
Done.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Jakub Narebski @ 2007-07-22 1:16 UTC (permalink / raw)
To: git
In-Reply-To: <85644dqoig.fsf@lola.goethe.zz>
David Kastrup wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Sat, 21 Jul 2007, David Kastrup wrote:
>>> Linus, a directory is simply non-existent inside of git.
>>
>> You need to learn git first.
>>
>> A directory doesn't exist IN THE INDEX (until my patches). But you
>> need to learn about the object database and the SHA1's. That's the
>> real meat of git, and it sure as hell knows about directories.
>
> I have written up a complete explanation about the underlying concept
> in a separate thread, maybe it would make sense reading that before
> investing too much time meddling over details that don't fit the large
> picture. The point is that the object database and the SHA1 values
> track _trees_, not _directories_. And a _tree_ is just a hashing
> mechanism in the repository for files. Its existence is solely
> dependent on the existence of its contents. The only synchronization
> with directories is that when a tree becomes empty, git attempts to do
> an rmdir on the corresponding directory. And of course, if git needs
> to check out a file, it creates the necessary parent directories.
>
> Now since the physical _contents_ of a directory are already tracked
> in _trees_ by git, the only missing part is the _existence_ of the
> directory itself: a directory must exist as long as there is a tree
> (and thus content) connected with it, but the reverse does not hold:
> without a tree, the directory can still exist. Which we can represent
> by a repository entry named "." without content (the content is
> already catered for by the _tree_). This must _not_ be represented by
> a _tree_ node since there is no content, and a tree without content by
> _definition_ does not exist.
>
> I must be really bad at explaining things, or I am losing a fight
> against preconceptions fixed beyond my imagination.
I don't understand you, or you don't understand git. "Tree" object
in object database (in repository) represents a directory in the
working area. There was never any problem with having empty trees
in object database, or having links to empty directory in the superdir.
We don't have to change anything about object database.
The problems with git problems with empty directories stems from the
fact that index didn't have directories. Index is flattened version
of root tree, and before subproject support it contained _only_ info
about blobs (file contents). At least till Linus patch...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707211737090.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>>
>> I must be really bad at explaining things, or I am losing a fight
>> against preconceptions fixed beyond my imagination.
>
> I really dont' see the point. But hey, code talks.
Yes, I am working on that. It would have been nice if IS_DIR was not
already taken by trees, but one can't have everything. So I need to
decide how to represent the node, and it would appear that I need to
angle for "file" after all. Since it is really quite closer to a file
or symlink than to a tree or project. Hm, perhaps a symlink might be
more expedient. Make it have an empty reference, and it is unique.
And there will be fewer places in the code manipulating symlinks than
files.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Initial Chinese translation
From: Xudong Guan @ 2007-07-22 0:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707220132290.14781@racer.site>
On 01:34 Sun 22 Jul , Johannes Schindelin wrote:
> Unfortunately, I am not able to verify ;-)
I pulled and saw your commit. The encoding is good.
Xudong
^ permalink raw reply
* [PATCH] Documentation/gitignore.txt: Fix the seriously misleading priority explanation
From: David Kastrup @ 2007-07-21 23:53 UTC (permalink / raw)
To: git
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/gitignore.txt | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index ea79d74..9c83095 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -18,21 +18,26 @@ pattern.
When deciding whether to ignore a path, git normally checks
`gitignore` patterns from multiple sources, with the following
-order of precedence:
+order of precedence, from highest to lowest (within one level of
+precedence, the last matching pattern decides the outcome):
- * Patterns read from the file specified by the configuration
- variable 'core.excludesfile'.
-
- * Patterns read from `$GIT_DIR/info/exclude`.
+ * Patterns read from the command line for those commands that support
+ them.
* Patterns read from a `.gitignore` file in the same directory
- as the path, or in any parent directory, ordered from the
- deepest such file to a file in the root of the repository.
+ as the path, or in any parent directory, with patterns in the
+ higher level files (up to the root) being overriden by those in
+ lower level files down to the directory containing the file.
These patterns match relative to the location of the
`.gitignore` file. A project normally includes such
`.gitignore` files in its repository, containing patterns for
files generated as part of the project build.
+ * Patterns read from `$GIT_DIR/info/exclude`.
+
+ * Patterns read from the file specified by the configuration
+ variable 'core.excludesfile'.
+
The underlying git plumbing tools, such as
gitlink:git-ls-files[1] and gitlink:git-read-tree[1], read
`gitignore` patterns specified by command-line options, or from
@@ -49,7 +54,8 @@ Patterns have the following format:
- An optional prefix '!' which negates the pattern; any
matching file excluded by a previous pattern will become
- included again.
+ included again. If a negated pattern matches, this will
+ override lower precedence patterns sources.
- If the pattern does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
--
1.5.2.3
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply related
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 0:37 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85644dqoig.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
>
> I must be really bad at explaining things, or I am losing a fight
> against preconceptions fixed beyond my imagination.
I really dont' see the point. But hey, code talks.
Linus
^ permalink raw reply
* Re: [PATCH] Initial Chinese translation
From: Junio C Hamano @ 2007-07-22 0:35 UTC (permalink / raw)
To: Xudong Guan
Cc: git, Johannes Schindelin, Paolo Ciarrocchi,
しらいしななこ,
Shawn O. Pearce, Christian Stimming
In-Reply-To: <11850629362012-git-send-email-xudong.guan@gmail.com>
Xudong Guan <xudong.guan@gmail.com> writes:
> Simplified Chinese, in UTF-8 encoding.
>
> Signed-off-by: Xudong Guan <xudong.guan@gmail.com>
> ---
> po/zh.po | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 250 insertions(+), 0 deletions(-)
This raises another point in the current i18n scheme. How would
we allow zh_CN and zh_TW to coexist?
^ permalink raw reply
* Re: [PATCH] Initial Chinese translation
From: Johannes Schindelin @ 2007-07-22 0:34 UTC (permalink / raw)
To: Xudong Guan; +Cc: git
In-Reply-To: <11850629362012-git-send-email-xudong.guan@gmail.com>
Hi,
On Sun, 22 Jul 2007, Xudong Guan wrote:
> Simplified Chinese, in UTF-8 encoding.
Unfortunately, I am not able to verify ;-)
I applied it an pushed it out. AFAICT the UTF-8 was imported correctly
this time ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 0:34 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0707211650190.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 21 Jul 2007, David Kastrup wrote:
>
>> Linus, a directory is simply non-existent inside of git.
>
> You need to learn git first.
>
> A directory doesn't exist IN THE INDEX (until my patches). But you
> need to learn about the object database and the SHA1's. That's the
> real meat of git, and it sure as hell knows about directories.
To put it in another way: what would happen if trees were removed from
git's repository completely? Instead we would just stipulate that git
should only track files, not trees, and that it would remove an
outside directory when removing the last file from the repository that
can't be accomodated without such a directory.
Now the effect would be that git would become quite inefficient. But
it would not change its behavior in any other way. Because it knows
_zilch_ about directories. It knows about the hierarchy of the
_contents_, but the directories, the physical entities in the work
tree? It deduces a convenient point of time to try deleting them
(when a tree collapses), and it deduces that they are there as long as
it is tracking their content, but no information about a _directory_
other than its _contents_ ever enter the repository or index. About
its _existence_, git only keeps circumstantial evidence.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Initial Chinese translation
From: Junio C Hamano @ 2007-07-22 0:32 UTC (permalink / raw)
To: Xudong Guan; +Cc: git
In-Reply-To: <11850629362012-git-send-email-xudong.guan@gmail.com>
Xudong Guan <xudong.guan@gmail.com> writes:
> Simplified Chinese, in UTF-8 encoding.
From: Xudong Guan <xudong.guan@gmail.com>
Subject: [PATCH] Initial Chinese translation
To: git@vger.kernel.org
Cc: Xudong Guan <xudong.guan@gmail.com>
Date: Sun, 22 Jul 2007 01:08:56 +0100
Message-ID: <11850629362012-git-send-email-xudong.guan@gmail.com>
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Your MUA disagrees with you, at least in the copy I see on gmane.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 0:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707211650190.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 21 Jul 2007, David Kastrup wrote:
>>
>> tree1:
>> 0?0000 . -> dir1
>> 100644 a.c -> blob1
>> 040000 a -> tree2
>> 100644 abc -> blob3
>
> No. Totally broken. That "." entry not only doesn't buy you
> anything, it is *impossible*. You cannot make an object point to
> itself. Not possible.
It does not point to itself. The name "." points to an entry of type
"dir", no content is involved. trees in the repository have content,
and _only_ content. directories in the repository imply existence,
and _only_ existence.
> Tell me how to calculate the SHA1 for the result.
Since "." has no content (as long as we don't decide to track any file
permissions at one point of time), _all_ entries "." will have the
same SHA1.
> Also, tell me what the *point* is. There is none.
The point is to have a reflection of the physical existence of a
directory. Not just as a manner of accommodating slashes in a flat
filespace, allowing certain slash-related operations to be carried out
efficiently.
>> Linus, a directory is simply non-existent inside of git.
>
> You need to learn git first.
>
> A directory doesn't exist IN THE INDEX (until my patches). But you
> need to learn about the object database and the SHA1's. That's the
> real meat of git, and it sure as hell knows about directories.
I have written up a complete explanation about the underlying concept
in a separate thread, maybe it would make sense reading that before
investing too much time meddling over details that don't fit the large
picture. The point is that the object database and the SHA1 values
track _trees_, not _directories_. And a _tree_ is just a hashing
mechanism in the repository for files. Its existence is solely
dependent on the existence of its contents. The only synchronization
with directories is that when a tree becomes empty, git attempts to do
an rmdir on the corresponding directory. And of course, if git needs
to check out a file, it creates the necessary parent directories.
Now since the physical _contents_ of a directory are already tracked
in _trees_ by git, the only missing part is the _existence_ of the
directory itself: a directory must exist as long as there is a tree
(and thus content) connected with it, but the reverse does not hold:
without a tree, the directory can still exist. Which we can represent
by a repository entry named "." without content (the content is
already catered for by the _tree_). This must _not_ be represented by
a _tree_ node since there is no content, and a tree without content by
_definition_ does not exist.
I must be really bad at explaining things, or I am losing a fight
against preconceptions fixed beyond my imagination.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Initial Chinese translation
From: Xudong Guan @ 2007-07-22 0:08 UTC (permalink / raw)
To: git; +Cc: Xudong Guan
Simplified Chinese, in UTF-8 encoding.
Signed-off-by: Xudong Guan <xudong.guan@gmail.com>
---
po/zh.po | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 250 insertions(+), 0 deletions(-)
create mode 100644 po/zh.po
diff --git a/po/zh.po b/po/zh.po
new file mode 100644
index 0000000..bea5e54
--- /dev/null
+++ b/po/zh.po
@@ -0,0 +1,250 @@
+# Translation of git-gui to Chinese
+# Copyright (C) 2007 Shawn Pearce
+# This file is distributed under the same license as the git-gui package.
+# Xudong Guan <xudong.guan@gmail.com>, 2007.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: git-gui\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-21 23:46+0100\n"
+"PO-Revision-Date: 2007-07-21 01:23-0700\n"
+"Last-Translator: Xudong Guan <xudong.guan@gmail.com>\n"
+"Language-Team: Chinese\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: git-gui.sh:1656
+msgid "Repository"
+msgstr "ç‰ˆæœ¬æ ‘"
+
+#: git-gui.sh:1657
+msgid "Edit"
+msgstr "编辑"
+
+#: git-gui.sh:1659
+msgid "Branch"
+msgstr "分支"
+
+#: git-gui.sh:1662 git-gui.sh:1840
+msgid "Commit"
+msgstr "æ交"
+
+#: git-gui.sh:1665
+msgid "Merge"
+msgstr "åˆå¹¶"
+
+#: git-gui.sh:1666
+msgid "Fetch"
+msgstr "导入"
+
+#: git-gui.sh:1667
+msgid "Push"
+msgstr "ä¸Šä¼ "
+
+#: git-gui.sh:1676
+msgid "Browse Current Branch's Files"
+msgstr "æµè§ˆå½“å‰åˆ†æ”¯æ–‡ä»¶"
+
+#: git-gui.sh:1685
+msgid "Visualize Current Branch's History"
+msgstr "调用gitk显示当å‰åˆ†æ”¯"
+
+#: git-gui.sh:1689
+msgid "Visualize All Branch History"
+msgstr "调用gitk显示所有分支"
+
+#: git-gui.sh:1694
+msgid "Database Statistics"
+msgstr "æ•°æ®åº“统计数æ®"
+
+#: git-gui.sh:1697
+msgid "Compress Database"
+msgstr "压缩数æ®åº“"
+
+#: git-gui.sh:1700
+msgid "Verify Database"
+msgstr "验è¯æ•°æ®åº“"
+
+#: git-gui.sh:1707 git-gui.sh:1711 git-gui.sh:1715
+msgid "Create Desktop Icon"
+msgstr "创建桌é¢å›¾æ ‡"
+
+#: git-gui.sh:1720
+msgid "Quit"
+msgstr "退出"
+
+#: git-gui.sh:1727
+msgid "Undo"
+msgstr "撤销"
+
+#: git-gui.sh:1730
+msgid "Redo"
+msgstr "é‡åš"
+
+#: git-gui.sh:1734 git-gui.sh:2249
+msgid "Cut"
+msgstr "剪切"
+
+#: git-gui.sh:1737 git-gui.sh:2252 git-gui.sh:2323 git-gui.sh:2395
+msgid "Copy"
+msgstr "å¤åˆ¶"
+
+#: git-gui.sh:1740 git-gui.sh:2255
+msgid "Paste"
+msgstr "粘贴"
+
+#: git-gui.sh:1743 git-gui.sh:2258
+msgid "Delete"
+msgstr "åˆ é™¤"
+
+#: git-gui.sh:1747 git-gui.sh:2262 git-gui.sh:2399
+msgid "Select All"
+msgstr "全选"
+
+#: git-gui.sh:1756
+msgid "Create..."
+msgstr "新建..."
+
+#: git-gui.sh:1762
+msgid "Checkout..."
+msgstr "切æ¢..."
+
+#: git-gui.sh:1768
+msgid "Rename..."
+msgstr "改å..."
+
+#: git-gui.sh:1773 git-gui.sh:1871
+msgid "Delete..."
+msgstr "åˆ é™¤..."
+
+#: git-gui.sh:1778
+msgid "Reset..."
+msgstr "é‡ç½®æ‰€æœ‰ä¿®åŠ¨..."
+
+#: git-gui.sh:1790
+msgid "New Commit"
+msgstr "æ–°æ交"
+
+#: git-gui.sh:1798
+msgid "Amend Last Commit"
+msgstr "修订上次æ交"
+
+#: git-gui.sh:1807
+msgid "Rescan"
+msgstr "é‡æ–°æ‰«æ"
+
+#: git-gui.sh:1813
+msgid "Add To Commit"
+msgstr "æ·»åŠ åˆ°æœ¬æ¬¡æ交"
+
+#: git-gui.sh:1818
+msgid "Add Existing To Commit"
+msgstr "æ·»åŠ é»˜è®¤ä¿®æ”¹æ–‡ä»¶"
+
+#: git-gui.sh:1824
+msgid "Unstage From Commit"
+msgstr "从本次æ交移除"
+
+#: git-gui.sh:1829
+msgid "Revert Changes"
+msgstr "æ¢å¤ä¿®æ”¹"
+
+#: git-gui.sh:1836 git-gui.sh:2273
+msgid "Sign Off"
+msgstr "ç¾å"
+
+#: git-gui.sh:1851
+msgid "Local Merge..."
+msgstr "本地åˆå¹¶..."
+
+#: git-gui.sh:1856
+msgid "Abort Merge..."
+msgstr "å–消åˆå¹¶..."
+
+#: git-gui.sh:1868
+msgid "Push..."
+msgstr "ä¸Šä¼ ..."
+
+#: git-gui.sh:1878
+msgid "Apple"
+msgstr "苹果"
+
+#: git-gui.sh:1881 git-gui.sh:1928
+#, tcl-format
+msgid "About %s"
+msgstr "关于%s"
+
+#: git-gui.sh:1883 git-gui.sh:1889 git-gui.sh:2441
+msgid "Options..."
+msgstr "选项..."
+
+#: git-gui.sh:1913
+msgid "Tools"
+msgstr "工具"
+
+#: git-gui.sh:1915
+msgid "Migrate"
+msgstr "移æ¤"
+
+#: git-gui.sh:1924
+msgid "Help"
+msgstr "帮助"
+
+#: git-gui.sh:1965
+msgid "Online Documentation"
+msgstr "在线文档"
+
+#: git-gui.sh:2215
+msgid "Initial Commit Message:"
+msgstr "åˆå§‹æ交æè¿°:"
+
+#: git-gui.sh:2216
+msgid "Amended Commit Message:"
+msgstr "修订æ交æè¿°:"
+
+#: git-gui.sh:2217
+msgid "Amended Initial Commit Message:"
+msgstr "修订åˆå§‹æ交æè¿°:"
+
+#: git-gui.sh:2218
+msgid "Amended Merge Commit Message:"
+msgstr "修订åˆå¹¶æ交æè¿°:"
+
+#: git-gui.sh:2219
+msgid "Merge Commit Message:"
+msgstr "åˆå¹¶æ交æè¿°:"
+
+#: git-gui.sh:2220
+msgid "Commit Message:"
+msgstr "æ交æè¿°:"
+
+#: git-gui.sh:2265 git-gui.sh:2403
+msgid "Copy All"
+msgstr "全部å¤åˆ¶"
+
+#: git-gui.sh:2391
+msgid "Refresh"
+msgstr "刷新"
+
+#: git-gui.sh:2412
+msgid "Apply/Reverse Hunk"
+msgstr ""
+
+#: git-gui.sh:2418
+msgid "Decrease Font Size"
+msgstr "缩å°å—体"
+
+#: git-gui.sh:2422
+msgid "Increase Font Size"
+msgstr "放大å—体"
+
+#: git-gui.sh:2427
+msgid "Show Less Context"
+msgstr "显示更多diff上下文"
+
+#: git-gui.sh:2434
+msgid "Show More Context"
+msgstr "显示更少diff上下文"
--
1.5.0.rc3.81.g8188e
^ permalink raw reply related
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-21 23:50 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85tzrxslms.fsf@lola.goethe.zz>
On Sat, 21 Jul 2007, David Kastrup wrote:
>
> tree1:
> 0?0000 . -> dir1
> 100644 a.c -> blob1
> 040000 a -> tree2
> 100644 abc -> blob3
No. Totally broken. That "." entry not only doesn't buy you anything, it
is *impossible*. You cannot make an object point to itself. Not possible.
Tell me how to calculate the SHA1 for the result. Also, tell me what the
*point* is. There is none.
> Linus, a directory is simply non-existent inside of git.
You need to learn git first.
A directory doesn't exist IN THE INDEX (until my patches). But you need to
learn about the object database and the SHA1's. That's the real meat of
git, and it sure as hell knows about directories.
Linus
^ permalink raw reply
* git-rm semantics (was: The philosophy behind my directory proposal in a nutshell)
From: David Kastrup @ 2007-07-21 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <85fy3hqtwl.fsf@lola.goethe.zz>
Following up on the git-rm note:
> [As a note aside: working directories get removed when their
> corresponding tree collapses and disappears from the
> repository. I should think it only consistent if the same
> happened with git-rm: let the file by default disappear at
> the moment when it gets removed from the repository,
> implying --cached. Namely, let
>
> git-rm some-file
> git-add some-file
>
> be a noop, regardless whether the file was registered
> previously. This also implies that git-rm will always leave
> unregistered files alone.]
Ok, this is somewhat incorrect: if we call git-rm and the file still
exists, this is strictly speaking the same situation as calling
git-add when a file does not exist.
And that gives:
fatal: pathspec 'geo' did not match any files
whether or not the repository has an idea about the file.
So in analogy, git-rm on an existing file could possibly made to barf.
Anyway, the following appears inconsistent to me:
touch geo
git-add geo
git-commit -m xxx -a
git-rm geo
[Now geo is gone]
git-add geo
[geo is complained about as unknown]
git-checkout geo
[geo is complained about as unknown!]
Now the last complaint clearly is quite a nuisance, because
git-checkout .
_will_ resurrect geo.
So for consistency's sake, it would appear that git-rm should really
only schedule a removal, and pull through only at the moment where the
file is actually removed from the repository. There is a slight
discordance with git-add in that git-add requires the existence of the
file at the time of the add. That is inevitable since git records the
_contents_ of the file at the time of the add. git-rm does not need
any such information.
Now what if a file disappears before we commit, namely
touch woozle
git add woozle
rm woozle
?
Woozle will in that case get committed if and only if the commit is
done without the -a option.
Makes sense. So in a nutshell: git-rm should not look at the working
directory. That's the business of the commit. When the repository
copy gets removed, this is the right time to remove the corresponding
file, and this is perfectly equivalent with the case for trees.
What _is_ strange is that a git-rmed file can't be restored by naming
it for a checkout.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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