* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.L FD.0.999.0707221031050.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>>
>> 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.
>
> You don't seem to realize - although I've told you now abotu a million
> times - that what you are talking about is:
>
> - technically exactly the same as ".gitignore", which for some
> unfathomable reason you cannot seem to accept.
Linus? Do both of us a favor and forget about the "." proposal.
Since I already dropped it, we can save time if you rant about the
proposal I have replaced it with and call me an idiot for a different
reason.
> Quite frankly, Junio would be a total idiot to take any patches that do
> what you want to do. Happily, he is anything but.
And he does not come across as one.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-22 18:56 UTC (permalink / raw)
To: git, gitster
Inspired by contrib/workdir/git-new-workdir, the flag --new-workdir (or
its shortcut, -n) can be used to create a new working directory for the
newly created branch. All information, except which branch is checked
out (and therefore also the index), will be symlinked from the current
repository.
Example:
$ git branch -n ~/my-new-topic xy-problem
will create a branch called "xy-problem", which is initially identical
to the current branch, and check out the new branch in ~/my-new-topic/.
You will be able to cherry-pick from, log and diff with the branch
"xy-problem" in the current repository, since most of the metadata is
shared.
Conversely, you can access all the branches in the current repository
from ~/my-new-topic/, too.
A word of warning: switching to _same_ branch that is checked out in
the other repository is asking for trouble. You are really working not
only on the same object database, but also the same (i.e. not copied)
refs namespace.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
IMHO this is a better syntax than what is in contrib/, and "git
branch" is probably the right place for such a thing, from a
user's perspective.
Documentation/git-branch.txt | 7 +++-
builtin-branch.c | 79 +++++++++++++++++++++++++++++++++++++++--
t/t3200-branch.sh | 11 ++++++
3 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bc6aa88..a05c795 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,7 +10,8 @@ SYNOPSIS
[verse]
'git-branch' [--color | --no-color] [-r | -a]
[-v [--abbrev=<length> | --no-abbrev]]
-'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git-branch' [--track | --no-track] [-l] [-f] <branchname>
+ [-n <dir> | --new-workdir <dir>] [<start-point>]
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
@@ -91,6 +92,10 @@ OPTIONS
--no-abbrev::
Display the full sha1s in output listing rather than abbreviating them.
+-n\|--new-workdir <dir>::
+ Set up a new working directory which shares all information with the
+ current repository, except which branch is checked out.
+
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
diff --git a/builtin-branch.c b/builtin-branch.c
index 5f5c182..cba5fac 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -11,9 +11,10 @@
#include "commit.h"
#include "builtin.h"
#include "remote.h"
+#include "unpack-trees.h"
static const char builtin_branch_usage[] =
- "git-branch [-r] (-d | -D) <branchname> | [--track | --no-track] [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [--color | --no-color] [-r | -a] [-v [--abbrev=<length> | --no-abbrev]]";
+ "git-branch [-r] (-d | -D) <branchname> | [--track | --no-track] [-l] [-f] [-n <dir> | --new-workdir <dir>] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [--color | --no-color] [-r | -a] [-v [--abbrev=<length> | --no-abbrev]]";
#define REF_UNKNOWN_TYPE 0x00
#define REF_LOCAL_BRANCH 0x01
@@ -500,6 +501,67 @@ static void rename_branch(const char *oldname, const char *newname, int force)
die("Branch is renamed, but update of config-file failed");
}
+static struct lock_file lockfile;
+
+/* This function free()s path */
+static int create_new_workdir(char *path, const char *branch_name)
+{
+ static const char *links[] = {
+ "config", "refs", "logs/refs", "objects", "info", "hooks",
+ "packed-refs", "remotes", "rr-cache", NULL
+ };
+ const char *git_dir = get_git_dir(), *absolute;
+ struct stat st;
+ unsigned char sha1[20];
+ char *ref;
+ struct object *object;
+ struct unpack_trees_options opts;
+ struct object_list trees;
+ int i, fd;
+
+ if (!has_symlinks)
+ return error("New workdir not possible without symlinks");
+ /* make sure that GIT_DIR is an absolute path */
+ if ((absolute = make_absolute_path(git_dir)) != git_dir &&
+ setup_new_git_dir(absolute))
+ return 1;
+ if (!lstat(git_path("config"), &st) && S_ISLNK(st.st_mode))
+ return error("Will not create a workdir from a workdir");
+ if (safe_create_leading_directories(path) ||
+ mkdir(path, 0777) || chdir(path))
+ return error("Could not create '%s'", path);
+ if (mkdir(DEFAULT_GIT_DIR_ENVIRONMENT, 0777) ||
+ chdir(DEFAULT_GIT_DIR_ENVIRONMENT) ||
+ mkdir("logs", 0777))
+ return error("Could not set up '%s/%s'",
+ path, DEFAULT_GIT_DIR_ENVIRONMENT);
+ for (i = 0; links[i]; i++)
+ if (symlink(git_path(links[i]), links[i]))
+ return error("Could not link '%s'", links[i]);
+ if (chdir("..") || setup_new_git_dir(DEFAULT_GIT_DIR_ENVIRONMENT))
+ return error("Error setting up new workdir");
+ fd = hold_locked_index(&lockfile, 1);
+ if (fd < 0)
+ return error("Could not lock index");
+ if (dwim_ref(branch_name, strlen(branch_name), sha1, &ref) != 1 ||
+ create_symref("HEAD", ref, "new workdir") ||
+ !(object = parse_object(sha1)) ||
+ object->type != OBJ_COMMIT)
+ return error("Could not checkout HEAD");
+ free(ref);
+ trees.item = &((struct commit *)object)->tree->object;
+ trees.next = NULL;
+
+ memset(&opts, 0, sizeof(opts));
+ opts.update = 1;
+ opts.merge = 1;
+ opts.head_idx = 1;
+ opts.fn = oneway_merge;
+ return unpack_trees(&trees, &opts) ||
+ write_cache(fd, active_cache, active_nr) ||
+ close(fd) || commit_locked_index(&lockfile);
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
@@ -507,6 +569,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
int reflog = 0, track;
int kinds = REF_LOCAL_BRANCH;
+ char *new_workdir = NULL;
int i;
git_config(git_branch_config);
@@ -587,11 +650,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
branch_use_color = 0;
continue;
}
+ if (!strcmp(arg, "--new-workdir") || !strcmp(arg, "-n")) {
+ if (++i >= argc)
+ usage(builtin_branch_usage);
+ new_workdir = xstrdup(argv[i]);
+ continue;
+ }
usage(builtin_branch_usage);
}
if ((delete && rename) || (delete && force_create) ||
- (rename && force_create))
+ (rename && force_create) || (new_workdir && (delete || rename)))
usage(builtin_branch_usage);
head = resolve_ref("HEAD", head_sha1, 0, NULL);
@@ -615,10 +684,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(head, argv[i], force_rename);
else if (rename && (i == argc - 2))
rename_branch(argv[i], argv[i + 1], force_rename);
- else if (i == argc - 1 || i == argc - 2)
+ else if (i == argc - 1 || i == argc - 2) {
create_branch(argv[i], (i == argc - 2) ? argv[i+1] : head,
force_create, reflog, track);
- else
+ if (new_workdir)
+ return create_new_workdir(new_workdir, argv[i]);
+ } else
usage(builtin_branch_usage);
return 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index ef1eeb7..d9ec82a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -202,4 +202,15 @@ test_expect_success \
test -f .git/logs/refs/heads/g/h/i &&
diff expect .git/logs/refs/heads/g/h/i'
+test_expect_success 'create new workdir' '
+ git branch -n new-workdir forked &&
+ test -d new-workdir &&
+ (cd new-workdir &&
+ test $HEAD = $(git rev-parse HEAD) &&
+ test refs/heads/forked = $(git symbolic-ref HEAD) &&
+ git fsck &&
+ git diff-files --quiet &&
+ git diff-index --quiet --cached HEAD)
+'
+
test_done
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* [PATCH 2/3] Add setup_new_git_dir() function
From: Johannes Schindelin @ 2007-07-22 18:56 UTC (permalink / raw)
To: git, gitster
With the function setup_new_git_dir() you can reset the path that will
be used for git_path(), git_dir() and friends.
The responsibility to close files and throw away information from the
old git_dir lies with the caller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
cache.h | 1 +
environment.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 98af530..bd58853 100644
--- a/cache.h
+++ b/cache.h
@@ -214,6 +214,7 @@ extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
extern char *get_graft_file(void);
+extern int setup_new_git_dir(const char *path);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/environment.c b/environment.c
index f83fb9e..264392b 100644
--- a/environment.c
+++ b/environment.c
@@ -107,3 +107,11 @@ char *get_graft_file(void)
setup_git_env();
return git_graft_file;
}
+
+int setup_new_git_dir(const char *path)
+{
+ if (setenv(GIT_DIR_ENVIRONMENT, path, 1))
+ return error("Could not set GIT_DIR to '%s'", path);
+ setup_git_env();
+ return 0;
+}
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* [PATCH 1/3] Add is_absolute_path() and make_absolute_path() functions
From: Johannes Schindelin @ 2007-07-22 18:55 UTC (permalink / raw)
To: git, gitster
This patch adds convenience functions to work with absolute paths.
The function is_absolute_path() should help the efforts to integrate
the MinGW fork.
Note that make_absolute_path() returns a pointer to a static buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I am in the middle of so many things, otherwise I would have
tried to find all places that can use these functions. But
maybe a helpful soul out there wants to do that?
cache.h | 5 +++++
path.c | 18 ++++++++++++++++++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 53801b8..98af530 100644
--- a/cache.h
+++ b/cache.h
@@ -358,6 +358,11 @@ int git_config_perm(const char *var, const char *value);
int adjust_shared_perm(const char *path);
int safe_create_leading_directories(char *path);
char *enter_repo(char *path, int strict);
+static inline int is_absolute_path(const char *path)
+{
+ return path[0] == '/';
+}
+const char *make_absolute_path(const char *path);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/path.c b/path.c
index c4ce962..b5b1959 100644
--- a/path.c
+++ b/path.c
@@ -292,3 +292,21 @@ int adjust_shared_perm(const char *path)
return -2;
return 0;
}
+
+const char *make_absolute_path(const char *path)
+{
+ static char buf[PATH_MAX];
+ const int size = sizeof(buf);
+ int len;
+
+ if (is_absolute_path(path))
+ return path;
+
+ if (!getcwd(buf, size))
+ die ("Could not get current working directory");
+ len = strlen(buf);
+ if (snprintf(buf + len, size - len, "/%s", path) > size - 1)
+ die ("Could not make absolute path from '%s'", path);
+ return buf;
+}
+
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-22 18:48 UTC (permalink / raw)
To: Git Mailing List, lkml
It would really be useful if git diff had an option for suppressing
diffs caused by CVS keyword expansion. I run into this problem over
and over when trying to recover stuff out of old kernel sources that
people checked into CVS and then posted CVS diffs to fulfill their GPL
obligations. I sometimes wonder if vendors are doing this on purpose
to make it more difficult to recover the changes they made to the
code.
To prevent this in the future, I'd love to see a patch removing all
CVS keywords from the kernel sources. Quick grep of kernel shows 1,535
$Id, 197 $Log, 441 $Revision, 144 $Date. I guestimate that this would
remove about 5,000 lines form the kernel source and touch 1,700 files.
Would this be accept or do those expansions contain useful info?
Example diff caused by $Log expansion:
diff --git a/arch/cris/kernel/ptrace.c b/arch/cris/kernel/ptrace.c
index b3d10fb..32e47ca 100644
--- a/arch/cris/kernel/ptrace.c
+++ b/arch/cris/kernel/ptrace.c
@@ -8,6 +8,9 @@
* Authors: Bjorn Wesen
*
* $Log: ptrace.c,v $
+ * Revision 1.2 2003/06/26 21:08:16 vangool
+ * Commit kernel changes.
+ *
* Revision 1.8 2001/11/12 18:26:21 pkj
* Fixed compiler warnings.
*
Or in this case the person edited out all of the lines in the kernel
containing $Id
diff --git a/arch/i386/boot/tools/build.c b/arch/i386/boot/tools/build.c
index 2edd0a4..792aeb1 100644
--- a/arch/i386/boot/tools/build.c
+++ b/arch/i386/boot/tools/build.c
@@ -1,5 +1,4 @@
/*
- * $Id: build.c,v 1.5 1997/05/19 12:29:58 mj Exp $
*
* Copyright (C) 1991, 1992 Linus Torvalds
* Copyright (C) 1997 Martin Mares
A variation on this where the Id was updated..
- * $Id: build.c,v 1.5 1997/05/19 12:29:58 mj Exp $
+ * $Id: build.c,v 1.5 2002/09/29 12:29:58 mj Exp $
There are a more CVS keywords that can cause expansion, probably around twenty.
When removing these with a simple grep it can get fooled and mess up.
CVS keyword expansion adds about 60,000 lines of noise to a typical
diff.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: A simpler approach to tracking directories
From: David Kastrup @ 2007-07-22 18:45 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20070722175731.GA16658@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Jul 22, 2007 at 05:39:06PM +0200, David Kastrup wrote:
>> Now my proposal basically boils down to using the u+x bit on
>> directory/tree entries for tracking "keep around when empty".
>>
>> I think we are on the safe side to assume a directory with access
>> permissions zero (a-rwx) is something we never want to be able to
>> track with git.
>
> Ok, so I think you are still missing the fundamental issue about why
> Linus is upset with your proposals.
Or I am not careful in communicating what I consider obvious in
addressing it.
> One of the fundamental things which falls out of the "Git Tracks
> Contents" mantra is that information which you expect to be pushed
> forward future revisions (as opposed to metadata which is specific
> to a commit, such as the Author and Committer of a patch, the Commit
> log, etc.) *MUST* be information which is realized in the working
> tree.
For every _file_ in the working tree, there is _one_ bit of
information in the repository that is not in the working tree: namely
whether git is tracking this file at all.
> That way, if you diff between working trees, one of which has either
> your "." entry or your "u+x" bit, and of which doesn't, they need to
> be *different* when run "git diff" on the two working trees.
If I have two identical working trees, and in one working tree a file
A has been added into git, and in the other it hasn't, then git diff
will report a difference.
> Another way of putting is this single bit of information meaning
> "keep this directory around when empty" is something that ***must***
> be representable in three different places: in a git tree object, in
> the index, *AND* in the working tree. The problem with "." is that
> since all directories contain the "." entry, you can't represent the
> bit of information you want to record in the working tree in that
> way.
But if I have two identical working trees, where in one of them A has
been added into git and in the other it hasn't, there _is_ a bit of
difference in the repository.
I think the remaining problem boils down to the following: a file that
is not tracked by git has nothing in the repository which one would
associate with it. That is easy to understand. But trees in the
repository are right now a consequence of tracking files: a file needs
a tree, and git creates one. So we have an object in the repository
which we naturally correlate with the directory in the working tree
that is required for holding the files in the working tree. So the
relationship becomes somewhat less intuitive:
git tracks file -> file is in the repository
git does not track file -> file is not in the repository
That's easy.
git tracks directory -> tree permissions are not zero in the repository
git does not track directory -> no tree with non-zero permissions
So the problem in understanding is that in spite of git not tracking
the directory, there can be _still_ an _incidental_ tree whose
existence is solely to support the blobs in it. This problem is
acerbated by git having to actually manipulate working file
directories even if it has no information about them. So that git
_works_ with directories does not help to clarify that it does not
_track_ them. At least one pointer that it does not track them,
however, is that they are not even entered into the index. So since
no information flow into the repository happens, at the current point
of time, all directories can be considered untracked. git _is_
accessing and manipulating them, but without any help from the
repository that would be specific to the directory.
> There is a same problem with using the u+x permission, for the same
> reason. Unless you want to make directories you want to keep around
> with access permissions of zero in the working tree, you're *still*
> not able to record presence or absence of the "keep around when
> empty bit" in the working tree.
Like it is not encoded in the working tree whether or not git is
tracking a particular file.
> That's why the ".gitignore" entry is acceptable, where as your
> proposals are not.
But whether or not a file is tracked is not decided by a .gitignore
entry: gitignore comes into play only when one is adding entire
directories, and thus _implicitly_ adding files.
The explicit act or non-act of "git-add file" records a difference in
the repository that is nowhere reflected in the work directory.
> But the problem is that Linus very much wants the "do not erase" bit
> to be visible in the working directory, since to do otherwise would
> violate fundamental design assumptions all over the git source
> files.
Whether or not a file is tracked is _not_ encoded in the work
directory. While the gitignore entries provide useful defaults, as
long as every git-add and git-rm is only naming single files, tracking
and not tracking remains a possibility for every single file, a
possibility nowhere reflected in the work directory.
> So your new proposal suffers from the same fundamental flaw as your
> previous one.
It pretty much behaves the same, yes. After all, it has to represent
the difference between
mkdir a
touch a/b
git-add a/b
git-commit -m x
git-rm a/b
git-commit -m x
(where a should be removed) and
mkdir a
touch a/b
git-add a
git-commit -m x
git-rm a/b
git-commit -m x
(where a should be retained). Feel free to address this.
> Maybe you disagree with Linus's design constraint, but you've never
> addressed his specific concern on-point, which is that since Git
> Tracks Content, if you want something to be tracked across
> revisions, it must be visible in the working tree.
Oh, I address it pretty much in every posting: whether or not a _file_
is being tracked is _not_ visible in the working directory, and nobody
sees a problem with that. So this "design constraint" is very much
violated all the time, anyway.
> The problem with such a proposal is that it now requires that the
> filesystem used to store the working directory MUST support extended
> attributes, and some filesystems, such as FAT filesystems, do not.
> And Git already has been accused of not being Windows friendly
> enough, and this would make things worse.
Where is the relation to my proposal? Am I asking for anything that
any file system could not represent?
> It's also a lot of hair for two very marginal features, namely being
> able to support arbitrary SVN property values, and the "do not erase
> when empty" directory bit.
Maybe we should call the bit by its meaning, not its effect. Call it
the "git has been told to track this directory" bit.
Perhaps then it gets less offensive.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Idea for git-fast-import
From: Michael Haggerty @ 2007-07-22 18:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070720072824.GP32566@spearce.org>
Shawn O. Pearce wrote:
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Also, is there a big cost to using "not-quite-consecutive" integers as
>> marks? cvs2svn's CVSRevision IDs are intermingled with IDs for
>> CVSBranches and CVSTags, so the CVSRevisions alone probably only pack
>> the ID space 5%-50% full.
>
>> In fact, if there is a big cost to "not-quite-consecutive" integers,
>> then I withdraw my request for separate mark namespaces, since I would
>> have to reallocate mark numbers anyway :-)
>
> See above. 5% full is really bad, because you are probably going to
> allocate nearly every block in the directory, and only fill each leaf
> block at 5% full. 50% full is actually reasonable, as it means marks
> are only costing you about 2 pointers on average (8 or 16 bytes).
OK, then, never mind. As I mentioned, it is not a big deal to have
cvs2svn generate a separate integer series for marks. If comments are
implemented, then the debugging disadvantage is also quite minor.
>> Another thing that might help with debugging would be a "comment"
>> command, which git-fast-import should ignore. One could put text about
>> the source of a chunk of git-fast-import stream to relate it back to the
>> front-end concepts when debugging the stream contents by hand.
>
> This is an awesome idea, especially when combined with having a
> buffer of the last few commands that fast-import saw right before
> it crashed. I'll see what I can do.
Thanks!
Michael
^ permalink raw reply
* [PATCH] Copyright and author information were missing from it.po
From: Paolo Ciarrocchi @ 2007-07-22 18:30 UTC (permalink / raw)
To: git, Johannes.Schindelin
Copyright and author information were missing from the file
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
po/it.po | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/po/it.po b/po/it.po
index 6879d66..80365b4 100644
--- a/po/it.po
+++ b/po/it.po
@@ -1,8 +1,7 @@
-# SOME DESCRIPTIVE TITLE.
-# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
-# This file is distributed under the same license as the PACKAGE package.
-# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
-#
+# Translation of git-gui to Italian
+# Copyright (C) 2007 Shawn Pearce
+# This file is distributed under the same license as the git-gui package.
+# Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>, 2007
#, fuzzy
msgid ""
msgstr ""
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* [PATCH] some feedbacks from the Italian Free Translation Project.
From: Paolo Ciarrocchi @ 2007-07-22 18:19 UTC (permalink / raw)
To: Johannes.Schindelin, git
Many thanks to the Italian Free Translation Project
More patches in the following days.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
po/it.po | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/it.po b/po/it.po
index 162e187..6879d66 100644
--- a/po/it.po
+++ b/po/it.po
@@ -195,11 +195,11 @@ msgstr "Ramo corrente:"
#: git-gui.sh:2115
msgid "Staged Changes (Will Be Committed)"
-msgstr "Modifiche preparate (Saranno committate)"
+msgstr "Modifiche preparate (ne verrà effettuato il commit)"
#: git-gui.sh:2135
msgid "Unstaged Changes (Will Not Be Committed)"
-msgstr "Modifiche non preparate (Non saranno committate)"
+msgstr "Modifiche non preparate (non ne verrà effettuato il commit)"
#: git-gui.sh:2182
msgid "Add Existing"
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* Re: [KORG] Encoding problem with the git documentation
From: H. Peter Anvin @ 2007-07-22 18:07 UTC (permalink / raw)
To: Alexander Wuerstlein; +Cc: webmaster, git
In-Reply-To: <20070722174915.GI26471@cip.informatik.uni-erlangen.de>
Alexander Wuerstlein wrote:
>
> There are 2 resolutions for this problem, changing the charset the webserver
> delivers in the response headers or recoding the html to be utf-8. One
> possibility to fix the response headers would be to use the 'AddDefaultCharset'
> directive (http://httpd.apache.org/docs/2.2/de/mod/core.html#adddefaultcharset)
> like 'AddDefaultCharset Off' or 'AddDefaultCharset ISO-8859-1'.
> This could also be set in .htaccess, so the persons responsible for the subtree
> can control the charset by themselves without your interaction. Of course
> the right solution depends on your setup which you know best about :)
>
We're aware of this problem, and the first answer is the right one --
this is 2007 and UTF-8 is what we should use everywhere.
However, the second option (using .htaccess) is available.
-hpa
^ permalink raw reply
* Re: A simpler approach to tracking directories (was: The philosophy behind my directory proposal in a nutshell)
From: Jakub Narebski @ 2007-07-22 18:13 UTC (permalink / raw)
To: git
In-Reply-To: <20070722175731.GA16658@thunk.org>
Theodore Tso wrote:
> Another way of putting is this single bit of information meaning "keep
> this directory around when empty" is something that ***must*** be
> representable in three different places: in a git tree object, in the
> index, *AND* in the working tree. The problem with "." is that since
> all directories contain the "." entry, you can't represent the bit of
> information you want to record in the working tree in that way.
I don't think the "do not delete when empty" bit must be somehow represented
in the working directory. It is enough to have this bit in index to deal
with working directory, and in the repository to have it persistent.
Compare with submodules, and with unmerged entries (which sometimes do not
have worktree representation).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 17:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git
In-Reply-To: <alpine.LFD.0.999.0707221029160.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>>
>> Sigh. No, I don't want to track every directory. I want to have
>> every directory _trackable_.
>
> And they already are.
Their contents are.
> Your point is pointless. You don't understand the git data
> structures, and you are trying to do something that makes no sense.
That makes no sense to you and apparently quite a few other people,
after a lot of explaining. That does not mean that it wouldn't work,
but it does mean that it is going nowhere: it is irrelevant whether I
consider the concept easy to understand and explain when nobody else
does: that makes it unmaintainable.
Fortunately, a few other participants, notably Junio and Jakub, have
focused a bit more on technical details rather than my sanity in their
somewhat more nuanced feedback, and thus I have (in a separate thread)
made a new proposal that addresses a few technical shortcomings and
that does no longer require splitting tree-ness/directory-ness into
separate concepts and records, something which I considered elegant
and others gibberish.
It boils down to encoding the "don't-evaporate-when-empty" or "I told
you to keep track of it" property in the directory access permissions:
if those are zero, git does not track the corresponding directory and
will attempt a remove-on-empty. If they are non-zero (probably 755 as
long as git stores only a sanitized version of the actual state
there), this means that git has been told to track the directory and
will not attempt to delete it until it is told to stop tracking it
again.
The proposal of allowing "." "!." as a gitignore pattern to specify
the tracking/non-tracking indicator does still stand, but its
semantics are now so much decoupled from that of
"don't-evaporate-when-empty" that the code would not actually overlap
with that of the tracking, and so discussing it is orthogonal to the
actual proposal and can be postponed separately, and an implementation
proferred separately once the rest is in place.
So do both of us a favor and skip the rest of the mail queue with
"Empty directories..." in its title.
Actually, the code (and later comments for it) you produced matches
the areas of work and what I think needs to be done quite closer now
than with my original proposal.
So while the discussion with you has not really been much of a help
except to show without reasonable doubt that my original approach
would have been unmaintainable by other persons, the code _is_ very
helpful.
Thanks,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: A simpler approach to tracking directories (was: The philosophy behind my directory proposal in a nutshell)
From: Theodore Tso @ 2007-07-22 17:57 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85abtola79.fsf@lola.goethe.zz>
On Sun, Jul 22, 2007 at 05:39:06PM +0200, David Kastrup wrote:
> Now my proposal basically boils down to using the u+x bit on
> directory/tree entries for tracking "keep around when empty".
>
> I think we are on the safe side to assume a directory with access
> permissions zero (a-rwx) is something we never want to be able to
> track with git.
Ok, so I think you are still missing the fundamental issue about why
Linus is upset with your proposals. One of the fundamental things
which falls out of the "Git Tracks Contents" mantra is that
information which you expect to be pushed forward future revisions (as
opposed to metadata which is specific to a commit, such as the Author
and Committer of a patch, the Commit log, etc.) *MUST* be information
which is realized in the working tree.
That way, if you diff between working trees, one of which has either
your "." entry or your "u+x" bit, and of which doesn't, they need to
be *different* when run "git diff" on the two working trees.
Another way of putting is this single bit of information meaning "keep
this directory around when empty" is something that ***must*** be
representable in three different places: in a git tree object, in the
index, *AND* in the working tree. The problem with "." is that since
all directories contain the "." entry, you can't represent the bit of
information you want to record in the working tree in that way.
There is a same problem with using the u+x permission, for the same
reason. Unless you want to make directories you want to keep around
with access permissions of zero in the working tree, you're *still*
not able to record presence or absence of the "keep around when empty
bit" in the working tree.
That's why the ".gitignore" entry is acceptable, where as your
proposals are not. The absence or presence of the ".gitignore" entry
in the working tree is a natural way of representing the "keep around
when empty". So would a ".do_not_erase" file in the directory ---
sort of like the "Do Not Erase" that professors would write on
whiteboards in order to request janitors to not erase them. It seems
that you are objecting to having something tangible written on the
whiteboard --- or, in the directory, to indicate the "do not erase"
note.
But the problem is that Linus very much wants the "do not erase" bit
to be visible in the working directory, since to do otherwise would
violate fundamental design assumptions all over the git source files.
Metadata such as the executable bit is actually stored in the working
directory. But we can't store the "do not erase bit" by leaving the
executable permission off, since that will prevent the directory from
being useful.
So your new proposal suffers from the same fundamental flaw as your
previous one.
Maybe you disagree with Linus's design constraint, but you've never
addressed his specific concern on-point, which is that since Git
Tracks Content, if you want something to be tracked across revisions,
it must be visible in the working tree. That is, metadata in the
sense of data which is not visible in the working tree, is not allowed
to exist inside Git and carried across revisions. So fundamentally,
Git does not currently today support "svn propset" in terms of setting
metadata on a particular file which isn't visible in the working tree.
With SVN, today you can use svn propset to what you could think of as
extended attributes. So one proposal that you *could* try proposing
is using extended attributes to represent arbitrary properties,
including the one which you want, which is the "do not erase"
property. And one of the arguments might be that this way we could
better preserve arbitrary properties currently set inside SVN, so that
such repository could be faithfully translated into a Git repository.
The problem with such a proposal is that it now requires that the
filesystem used to store the working directory MUST support extended
attributes, and some filesystems, such as FAT filesystems, do not.
And Git already has been accused of not being Windows friendly enough,
and this would make things worse.
It's also a lot of hair for two very marginal features, namely being
able to support arbitrary SVN property values, and the "do not erase
when empty" directory bit. Personally, I don't htink it's worth it,
but at least using filesystem xattrs to store that one bit of
information would at least be faithful to the fundamental git design
principal.
Regards,
- Ted
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 17:33 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85abtpoydg.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
>
> 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.
You don't seem to realize - although I've told you now abotu a million
times - that what you are talking about is:
- technically exactly the same as ".gitignore", which for some
unfathomable reason you cannot seem to accept.
- except your use of "." is 100% INFERIOR exactly because the "." entry
has no meaning in the target filesystem, so it means that the bit of
information is no longer something that is trackable in the working
tree.
Quite frankly, Junio would be a total idiot to take any patches that do
what you want to do. Happily, he is anything but.
Linus
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 17:30 UTC (permalink / raw)
To: David Kastrup; +Cc: david, git
In-Reply-To: <851wf0pzyt.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
>
> Sigh. No, I don't want to track every directory. I want to have
> every directory _trackable_.
And they already are.
Your point is pointless. You don't understand the git data structures, and
you are trying to do something that makes no sense.
Linus
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-22 17:28 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85abtpoydg.fsf@lola.goethe.zz>
On Sun, 22 Jul 2007, David Kastrup wrote:
>
> > 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.
You're pointless.
We have no problems at all with non-empty trees. We know exactly what they
are. We keep track of them fine, and we do not need a totally pointless
"." entry for them.
> But we are talking about
> permitting _empty_ trees in the repository.
And WE ALREADY DO.
The empty tree looks like this: "". It has a SHA1 of
4b825dc642cb6eb9a060e54bf8d69288fbee4904. It works today, and in fact, git
uses it already.
Try this:
git ls-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
in the git repository. What do you think that is?
Your "." is *pointless*.
And it's _worse_ than pointless: it's not "content". It doesn't add any
information. It's not something you can match up against the working tree
meaningfully, exactly because *every* working tree has it. As such, it's
total non-information.
Linus
^ permalink raw reply
* [PATCH] git-gui-i18n: Fix translation of the context menu
From: Johannes Schindelin @ 2007-07-22 16:20 UTC (permalink / raw)
To: git
There is some funny code generation going on to make the context menu,
and the messages for this have to be doubly quoted.
Noticed by Harri Ilari Tapio Liusvaara
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-gui.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 075a2b9..52170ee 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2457,9 +2457,9 @@ bind_button3 $ui_diff "
set cursorX %x
set cursorY %y
if {\$ui_index eq \$current_diff_side} {
- $ctxm entryconf $ui_diff_applyhunk -label [mc {Unstage Hunk From Commit}]
+ $ctxm entryconf $ui_diff_applyhunk -label \"[mc "Unstage Hunk From Commit"]\"
} else {
- $ctxm entryconf $ui_diff_applyhunk -label [mc {Stage Hunk For Commit}]
+ $ctxm entryconf $ui_diff_applyhunk -label \"[mc "Stage Hunk For Commit"]\"
}
tk_popup $ctxm %X %Y
"
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* Question about unpack-trees.c and tree_entry_list
From: David Kastrup @ 2007-07-22 16:17 UTC (permalink / raw)
To: git
The definition of tree_entry_list ist the following
struct tree_entry_list {
struct tree_entry_list *next;
unsigned directory : 1;
unsigned executable : 1;
unsigned symlink : 1;
unsigned int mode;
const char *name;
const unsigned char *sha1;
};
but it appears to me that the only of the bit fields that is used at
all is "directory" : all other uses revert to "mode" which directory
presumably could do as well.
Is there something I am overlooking?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-07-22 15:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18083.19607.236048.797818@cargo.ozlabs.ibm.com>
On Sun, Jul 22, 2007 at 10:24:55PM +1000, Paul Mackerras wrote:
> Yann Dirson writes:
>
> > This new version causes the command to add its revs to the litteral
> > ones from command-line instead of overriding them, and allows to
> > edit the command in the view editor.
>
> Is it actually useful to use both the --argscmd flag and some literal
> revisions on the command line? Why would you use both?
I tend to mostly use --all each time I use gitk (or stg-gitk, for that
matter), so my personal way of using gitk does not need it. However,
it could be useful if someone launched, say, 'stg-gitk master', thus
using --argscmd, and later wants to edit the view, eg. to add "origin".
> Instead of the --argscmd flag, maybe we could have a convention that
> an argument starting with "|" is a command to run rather than a
> literal revision. Would that suit?
If we go that way, a final "|" could be more intuitive.
However, a final "|" would run into a limitation of the view editor,
which is already a bit annoying with long command lines: the limited
size of the text field would by default hide the important final char.
> It would seem to simplify the
> patch by eliminating the requirement for an extra entry field, as well
> as removing the need for the separate viewargscmd array.
Sure, but at the same time, it does not make the code that more
complicated, and it makes it obvious that there are 2 ways to specify
the revs.
> > Disclaimer: I'm no tcl/tk expert, feel free to flame my style :)
>
> There are a couple of things I think should be done differently, in
> fact. :)
Eh :)
Best regards,
--
Yann
^ permalink raw reply
* A simpler approach to tracking directories (was: The philosophy behind my directory proposal in a nutshell)
From: David Kastrup @ 2007-07-22 15:39 UTC (permalink / raw)
To: git
In-Reply-To: <85fy3hqtwl.fsf@lola.goethe.zz>
Ok, I've gotten enough flak for my first proposal that it is clear
that it is rather irrelevant whether it would work (of which I remain
convinced) or not. Now I also have been of the opinion that it was
perfectly easy to understand and embrace, and the amount, content and
tone of responses have made very obvious that I have been quite wrong
about _that_ at least.
The good thing is that among all the flamage there have been actually
some people who went to the pain of actually reviewing the proposed
changes and give feedback about their relative feasibility in the
current code base. This has helped more than the reflections on my
sanity, I am glad to say.
So here we go:
I think there has been some vague consensus with the notion that it
does not make sense to track whether or not a directory _is_ empty at
the time of checkin (when checking in files below it, it _can't_ be),
but rather whether it should be automatically added and removed by git
based on the files in it alone.
The current state of affairs with git is that directories are
exclusively a mechanism for accommodating hierarchical filenames.
Consequently, the index does not need to know about them.
Anyway, here is the basic idea: git is already capable of tracking
file permissions (though at the current point of time, this is
somewhat artificially limited to the u+x bit), so there are basic
mechanisms in place for passing the respective bits through.
Now my proposal basically boils down to using the u+x bit on
directory/tree entries for tracking "keep around when empty".
I think we are on the safe side to assume a directory with access
permissions zero (a-rwx) is something we never want to be able to
track with git. So this special value, which I think is the current
default, can express "delete when empty". Personally I believe that
git can be made without problems to track more permissions (possibly
by configuring an appropriate mask for the project) than it currently
does, but that's not relevant for now: it is sufficient to use
permissions a-rwx for an automatically managed (=evaporate when empty)
tree/directory, and 755 for a manually managed (=stay around)
tree/directory without actually calling lstat for now.
Apart from needing to accommodate directories in the index (since they
are now associated with 1 instead of 0 bits of information), this will
work with the current data structures and protocols. Patches and
diffs can encode the change between tracked and untracked directories
as a change in the permissions of the directory.
So this obliterates the need to distinguish trees from directories
using actually separate and separately listed repository entries,
hopefully removing the main stumbling block.
It also addresses the concern of a tree's SHA1 changing when its
evaporate-when-empty-ness changes. It also will not lead to dangerous
situations on systems attempting to replace or delete "." as a regular
file.
So it has several technical advantages over my previous proposal, and
I _think_ it may be easier to understand and lead to less
contraintuitive behavior.
Now for deciding about _when_ to track a directory or not, I think
that the following part of the previous proposal was workable:
A directory's permission should be tracked in the same situations that
a file's permissions get tracked: that is if either the directory has
_explicitly_ been added to a commit, or it is _implicitly_ part of a
complete tree added into a commit. For implicitly indicated _files_,
whether or not they become tracked depends on the gitignore mechanism.
I think asking the gitignore mechanism whether the pattern "." in a
given directory is worth tracking is a good way of deciding implicit
inclusion, falling back onto a "core.dirtrack" or similar variable
that has some vague analogy to the "core.filemode" variable.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Matt McCutchen @ 2007-07-22 15:05 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git, Petr Baudis, Luben Tuikov
In-Reply-To: <7vd4ylt3eh.fsf@assigned-by-dhcp.cox.net>
On 7/22/07, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks. Will apply.
Jakub, thanks for picking this up. I was running out of energy to
push what began as an offer of a possibly useful local customization
any further toward adoption.
That said: the backward compatibility code for gitweb _site_
configuration is broken because it is inside an if statement that only
runs for gitweb _repository_ configuration. I tested it with a
gitweb_config.perl with
$feature{'snapshot'}{'default'} = ['x-gzip', 'gz', 'gzip'];
$feature{'snapshot'}{'override'} = 0;
and gitweb generated "snapshot ( )" (no visible link). Inspection of
the source revealed links to "sf=x-gzip", "sf=gz", and "sf=gzip" with
empty strings for the link text. The expected behavior is
"_snapshot_", linking to "sf=tgz", with a tooltip indicating "tar.gz"
format.
Moving the code out of the `if' wouldn't solve the problem by itself
because feature_snapshot is only reached if override is enabled, but
the site configuration compatibility needs to work whether or not
override is enabled. That's why Junio was considering adding a
separate function gitweb_bc_feature_snapshot. I think a nicer
alternative would be to change gitweb_check_feature to call the sub
(if any) whether or not override is enabled and let the sub check
$feature{'foo'}{'override'} itself to decide whether to look for an
override. Then each feature_* sub is the central point for both
override processing and backward compatibility for that feature.
Matt
^ permalink raw reply
* Re: German translations
From: Edgar Toernig @ 2007-07-22 14:52 UTC (permalink / raw)
To: David Kastrup; +Cc: Christian Stimming, git
In-Reply-To: <85tzrxr0m9.fsf@lola.goethe.zz>
> >> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> >> > +msgid "Commit"
> >> > +msgstr "Übertragen"
> >>
> >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> >> passendes Substantiv zu finden. "Sendung"?
> [...]
> Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
> Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.
>
> [usw]
Das ist genau der Grund, warum ich normalerweise keine deutschen
Lokalisierungen benutze - total unverstaendlicher Kauderwelsch.
Denkt doch bitte mal an die Zielgruppe! Das sind Techniker, keine
Grossmuetter. Ihr duerft Fachvokabular benutzen! Und gerade hier
wird die Zielgruppe schon englische Dokumentation gelesen haben.
Solch zwanghaft eingedeutschten Begriffe verwirren da nur.
Also sagt doch bitte einfach "der Commit" und "comitten" wie es
jeder Techniker macht. Ihr duerft auch "das Repository", "der
Index" und mMn auch ruhig "der Branch" benutzen.
Verstaendlichkeit, Klarheit, Exaktheit - das ist das oberste Ziel!
Wir sind doch keine Franzosen ;-)
Ciao, ET.
PS: bzgl. "Sign Off": "Gutheißen" ist zu lasch - das entspricht
dem Ack'ed-by.
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-22 14:29 UTC (permalink / raw)
To: Christian Stimming
Cc: Junio C Hamano, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <200707221535.46422.stimming@tuhh.de>
Hi,
On Sun, 22 Jul 2007, Christian Stimming wrote:
> Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:
>
> > - The i18n coordinator (could be Shawn but anybody else can
> > volunteer; as things stand, I think Christian and Johannes
> > are doing this): responsible for running "make
> > po/git-gui.pot; make update-po" from time to time in order to
> > keep po/*.po in sync with the vocabulary.
>
> Actually, please DO NOT RUN update-po except right before a new tarball
> is being packaged and distributed! It sucks royally if I have updated my
> de.po translation, only to discover someone has run update-po on the
> server and I have to figure out how to get out of the de.po conflicts.
I plan to work on that. It seems to be pretty easy to define a sane merge
behaviour, and we have gitattributes: by setting "*.po diff=po merge=po"
we can provide a custom merge program, just for .po files.
> > - Translators (one for each language): responsible for updating
> > po/xx.po file;
> >
> > initially, start by copying po/git-gui.pot to create
> > po/xx.po;
> >
> > maintainance of "glossary" part of po/xx.po could also be
> > made this person's responsibility instead of i18n
> > coordinator's.
> >
> > This way, the translators do not have to be so familiar with the
> > gettext toolchain nor even have to have gettext installed.
>
> Translators who are unfamiliar with gettext are a mixed blessing. [...]
> I wouldn't spent too much effort to enable translation work without
> gettext tools; instead, I'd rather encourage to optimize the setup for
> those translators that have the full toolchain available.
You need not work on the "without gettext toolchain" part; I will. Let's
see how far I get ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 13:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707221406.25541.jnareb@gmail.com>
Jakub, this mail is too long already, and it does not make sense to
tack a changed proposal to its end since then the readers will be
exhausted at the time they come there. So I'll instead tack a
followup to the "big picture" mail instead where I outline a modified
approach which is presumably easier to understand and completely
backwards-compatible, incorporating your feedback.
There is probably little sense in wasting your time on a detailed
response: feel free to point out where you don't see myself making
sense. I have no problem with people coming to different conclusions
that I do, but I would prefer it if it is not because they consider
myself a raving lunatic, but because they have different opinions
regarding the details.
"I can follow you, but I disagree with your conclusion" is perfectly
fine for now since I am going to propose something else, anyway.
Thanks for the feedback. It gave me some good ideas.
Jakub Narebski <jnareb@gmail.com> writes:
> On Sun, 22 July 2007, David Kastrup wrote:
>> 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.
>
> Or you are wrong...
Well, there is little reason for you to take my word on it, but I
happen to have a history of designing and implementing systems where I
have been responsible for every single byte, bootloader, firmware,
applications, target compiler, assembler, whatever. I have been
exposed to Unix and working with it several years before Linux even
existed. I also have a track record of being not exactly stupid.
So I pretty much can rule out that I am wrong on the factual side.
But where I may be wrong is in estimating the how obvious the design
can appear to others, and how useful and maintainable for others it
may be in the long run. Linus says "code talks", but that's actually
not half the story. If my code says that it works and the evidence is
there, but nobody is able to understand _why_ it works, it has no
place in a project where I am not permanently around.
If smart people don't get what I am talking about, it does not matter
that the patch is surprisingly well-contained: it will be a
maintenance nightmare because people will never figure out why
something stopped working after some particular change.
>> 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.
>
> True. I forgot about that.
Thanks. It is almost a revelation that anybody can agree on any point
with me at the moment.
> IMHO it would be best to first provide plumbing infrastructure (as
> e.g. it was the case of submodule support), then add option to
> git-update-index to change the "stickiness"/"autoremoval" status of
> a directory (of a tree), and _last_ think about how to change the
> porcelain (git-add and git-rm).
Sure. It does no harm to think about reducing the amount of breaking
porcelain, though.
> [...]
>
>> 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.
>
> Here we disagree. I think putting "." in a tree as marker of having
> it not be automatically deleted when empty, as opposed to marking
> tree using filemode in the parent, is not a good idea.
Well, "not a good idea" is a far step forward from "stupid idiot
babbling nonsense", so we may make progress towards actually being
able to _weigh_ different options. I can actually associate with "not
a good idea", not least because nobody else seems to get the idea, and
that makes it infeasible for maintenance.
So I'll address some points and then propose a different way of
implementing what will in the end amount to rather similar semantics,
but with a different view of looking at those semantics, one that
corresponds well with the implementation.
> The only advantage to the "." idea is that it can use gitignore
> mechanism (both in-tree .gitignore, tracked or not, and info/exclude
> file). But I also think that the fact that gitignore mechanism is
> recursive is more of disadvantage than advantage.
>
> First, it is _not_ consistent. Working directory trees _always_ have
> '.' in them, while trees would have or would have not it, depending
> if they would be "sticky" or "autoremoved".
Let me point out again that this inconsistency is already present in
the difference of tracked and untracked _files_: they are always in
the working directory, while trees have or not have them, depending on
whether they are "registered" or "not".
There is no inconsistency involved here, but it seems to make people
_very_ uncomfortable to factor out the "stays around even if empty"
functionality and call it "dir/." from the "can hold content"
functionality which is in effect called "dir/", and basically
associate tracked physical existence just with the former.
The recursiveness of the gitignore mechanism has the advantage that
when maintaining a large repository with actual or logical
subprojects, one does not need to pick a single policy for all
subprojects. I think that is quite important. It could possibly be
achieved with some other method of having per-subproject
configuration, but I see little wrong in using what is there and
documented already.
> Second, the "easy implementation" is anything but easy. "git add ."
> as a way to mark directory as "sticky" is not backward compatibile:
> currently it mean to add _all contents_ of current directory.
> Implementation is tricky: as we have seen trying to unlink '.' or
> create '.' can unfortunately succeed on [some Sun OS, and UFS
> filesystem] (which follows POSIX stupidly to the letter) f**king up
> the filesystem.
I was not suggesting actually leaving any such calls in place: after
all, they would presumably lead to error messages. But I agree that
this could lead to nasty surprises when somebody with a legacy version
of git worked with a repository containing "." as explicit entries of
some file type.
> The alternative proposal of adding "magic mode" to mark directory as
> "not remove when empty" is largely tested; it is very similar to the
> subproject support.
Good. Because it is what I converged to last night.
> Third, is contrary to the git philosophy of tracking contents.
> "Stickiness" is an attribute; the fact that directory is explicitely
> tracked or not does not change contents of a directory. Compare to
> 'blob' which contains only contents of a file: not a filename, not a
> pathname, not [subset of] filemode.
>
> Fourth, is very artificial. What would you put for filemode for '.'?
> 040000 (i.e. directory)?
Taken already. By something very artificial, namely a tree... Yes,
this was a wart in my proposal.
> What would you put for sha1? Sha1 of an empty directory?
Some fixed value. Everywhere the same. Not really relevant.
>> 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.
>
> Whether directory is automatically managed by git (automatically
> removed or untracked). But we need directory entry in index for
> git-diff, for example to recognize if there is or there is not empty
> directory, or if a directory is automanaged or not.
One conclusion that I have come to (and I think I am in agreement with
Linus here) is that the information "empty or not" is actually useless
separately: when I add files below a directory to the repository, the
directory _can't_ be empty. And git has no way of knowing whether it
is non-empty because I wanted the directory to be there, or whether it
is non-empty because I could not have checked in the files into the
tree below it otherwise.
>> 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. [...]
>
> The above sentence is nonsensical. Index is helper for repository,
> and can be derived from repository. Not vice versa.
>
> Trees do contain information which is not inherently present by the
> blobs.
Could you give examples for such information? As long as we are not
talking about _history_, I am at a loss at what else you mean. File
names and permissions?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Christian Stimming @ 2007-07-22 13:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <7vabtpv43d.fsf@assigned-by-dhcp.cox.net>
Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:
> > Agreed. I propose to throw away the "add glossary" patch and I'll
> > resubmit, this time in a separate po/glossary/ directory, where each
> > language will get a po file for the glossary.
>
> Actually, I would even suggest that we should NOT have a
> separate glossary file at all, if gettext suite allows what I
> outline below.
>
> How about having it as a part of header comment in each of the
> xx.po file?
I don't think this would work well. In particular, you don't get all the nice
gettext *merging* features that you only get with a full-blown po file.
> The division of labor I think would make sense for message l10n
> process goes like this:
>
> - The software developer (primarily Shawn): responsible for
> marking messages subject to i18n;
Yes, except those developers who don't happen to be translators as well tend
to forget the markups. I don't blame anyone for doing so - just keep in mind
that translators have to give feedback about missing markups, and they
hopefully will do so.
> - The i18n coordinator (could be Shawn but anybody else can
> volunteer; as things stand, I think Christian and Johannes
> are doing this): responsible for running "make
> po/git-gui.pot; make update-po" from time to time in order to
> keep po/*.po in sync with the vocabulary.
Actually, please DO NOT RUN update-po except right before a new tarball is
being packaged and distributed! It sucks royally if I have updated my de.po
translation, only to discover someone has run update-po on the server and I
have to figure out how to get out of the de.po conflicts. There will be
conflicts after each and every update-po because the line numbers in the po
file will have changed inevitably -- but the actualy content in terms of
messages might be completely unchanged.
For that reason, please use the update-po rule AS SELDOM AS POSSIBLE. Thanks a
lot.
> initially, populate "glossary" part in po/git-gui.pot;
>
> as needed, add entries "glossary" part in po/git-gui.pot, and
> (if possible) add corresponding placeholders to po/*.po;
Again, this doesn't work well, and depending on the po file editor that is
used by a translator they might not see this comment block anyway. I would
instead propose a subdirectory po/glossary; a CSV file that contains the
terms itself; a csv-to-po converter script that will turn the terms into a
git-gui-glossary.pot; and a po file for each language.
> - Translators (one for each language): responsible for updating
> po/xx.po file;
>
> initially, start by copying po/git-gui.pot to create
> po/xx.po;
>
> maintainance of "glossary" part of po/xx.po could also be
> made this person's responsibility instead of i18n
> coordinator's.
>
> This way, the translators do not have to be so familiar with the
> gettext toolchain nor even have to have gettext installed.
Translators who are unfamiliar with gettext are a mixed blessing. Anyone is
able to contribute a bunch of initial string translations, especially if
there hasn't been a translation before. But if someone or a team wants to
achieve a really *high-quality*, 100%, consistent, and understandable
translation, the translators must be able to test the translation a lot,
which implies they must be able to generate the .msg files, which requires
the gettext toolchain anyway. For that reason I wouldn't spent too much
effort to enable translation work without gettext tools; instead, I'd rather
encourage to optimize the setup for those translators that have the full
toolchain available.
Christian
^ 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