* [PATCH 5/5] document the diff driver textconv feature
From: Jeff King @ 2008-10-24 2:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt, Matthieu Moy
In-Reply-To: <20081024024631.GA20365@coredump.intra.peff.net>
This patch also changes the term "custom diff driver" to
"external diff driver"; now that there are more facets of a
"custom driver" than just external diffing, it makes sense
to refer to the configuration of "diff.foo.*" as the "foo
diff driver", with "diff.foo.command" as the "external
driver for foo".
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/gitattributes.txt | 66 +++++++++++++++++++++++++++++++--------
1 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2694559..314e2d3 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -213,10 +213,12 @@ with `crlf`, and then `ident` and fed to `filter`.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
-The attribute `diff` affects if 'git-diff' generates textual
-patch for the path or just says `Binary files differ`. It also
-can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
-line.
+The attribute `diff` affects how 'git' generates diffs for particular
+files. It can tell git whether to generate a textual patch for the path
+or to treat the path as a binary file. It can also affect what line is
+shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an
+external command to generate the diff, or ask git to convert binary
+files to a text format before generating the diff.
Set::
@@ -227,7 +229,8 @@ Set::
Unset::
A path to which the `diff` attribute is unset will
- generate `Binary files differ`.
+ generate `Binary files differ` (or a binary patch, if
+ binary patches are enabled).
Unspecified::
@@ -238,21 +241,21 @@ Unspecified::
String::
- Diff is shown using the specified custom diff driver.
- The driver program is given its input using the same
- calling convention as used for GIT_EXTERNAL_DIFF
- program. This name is also used for custom hunk header
- selection.
+ Diff is shown using the specified diff driver. Each driver may
+ specify one or more options, as described in the following
+ section. The options for the diff driver "foo" are defined
+ by the configuration variables in the "diff.foo" section of the
+ git config file.
-Defining a custom diff driver
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Defining an external diff driver
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The definition of a diff driver is done in `gitconfig`, not
`gitattributes` file, so strictly speaking this manual page is a
wrong place to talk about it. However...
-To define a custom diff driver `jcdiff`, add a section to your
+To define an external diff driver `jcdiff`, add a section to your
`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
----------------------------------------------------------------
@@ -328,6 +331,43 @@ patterns are available:
- `tex` suitable for source code for LaTeX documents.
+Performing text diffs of binary files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sometimes it is desirable to see the diff of a text-converted
+version of some binary files. For example, a word processor
+document can be converted to an ASCII text representation, and
+the diff of the text shown. Even though this conversion loses
+some information, the resulting diff is useful for human
+viewing (but cannot be applied directly).
+
+The `textconv` config option is used to define a program for
+performing such a conversion. The program should take a single
+argument, the name of a file to convert, and produce the
+resulting text on stdout.
+
+For example, to show the diff of the exif information of a
+file instead of the binary information (assuming you have the
+exif tool installed):
+
+------------------------
+[diff "jpg"]
+ textconv = exif
+------------------------
+
+NOTE: The text conversion is generally a one-way conversion;
+in this example, we lose the actual image contents and focus
+just on the text data. This means that diffs generated by
+textconv are _not_ suitable for applying. For this reason,
+only `git diff` and the `git log` family of commands (i.e.,
+log, whatchanged, show) will perform text conversion. `git
+format-patch` will never generate this output. If you want to
+send somebody a text-converted diff of a binary file (e.g.,
+because it quickly conveys the changes you have made), you
+should generate it separately and send it as a comment _in
+addition to_ the usual binary diff that you might send.
+
+
Performing a three-way merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.6.0.3.518.gdb328.dirty
^ permalink raw reply related
* Re: git performance
From: Daniel Barkalow @ 2008-10-24 3:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Edward Ned Harvey, git
In-Reply-To: <20081024072412.6117@nanako3.lavabit.com>
On Fri, 24 Oct 2008, Nanako Shiraishi wrote:
> Quoting Daniel Barkalow <barkalow@iabervon.org>:
>
> > On Wed, 22 Oct 2008, Edward Ned Harvey wrote:
> >
> >> Out of curiosity, what are they talking about, when they say "git is
> >> fast?" Just the fact that it's all local disk, or is there more to it
> >> than that? I could see - git would probably outperform perforce for
> >> versioning of large files (let's say iso files) to benefit from
> >> sustained local disk IO, while perforce would probably outperform
> >> anything I can think of, operating on thousands of tiny files, because
> >> it will never walk the tree.
> >
> > It shouldn't be too hard to make git work like perforce with respect to
> > walking the tree. git keeps an index of the stat() info it saw when it
> > last looked at files, and only looks at the contents of files whose stat()
> > info has changed. In order to have it work like perforce, it would just
> > need to have a flag in the stat() info index for "don't even bother",
>
> Are you describing the "assume unchanged bit"?
Yes, but with the user write mode bit in the filesystem set to
no-assume-unchanged, which is how Perforce users cope with it. I hadn't
realized it had been implemented to get set on a per-file basis, rather
than just as a global setting that caused it to not stat() anything except
right when it was told to update.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git archive
From: Nguyen Thai Ngoc Duy @ 2008-10-24 3:58 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git
In-Reply-To: <20081023182103.GA8320@euler>
On 10/24/08, Deskin Miller <deskinm@umich.edu> wrote:
> On Thu, Oct 23, 2008 at 10:33:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> > On 10/22/08, Deskin Miller <deskinm@umich.edu> wrote:
> > > On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> > > > I was going to make a tar of the latest stable linux kernel.
> > > > Done it before but now I got a strange problem.
> > > >
> > > > >git archive --format=tar v2.6.27.2
> > > > fatal: Not a valid object name
> > >
> > >
> > > I had the same thing happen to me, while trying to make an archive of Git.
> > > Were you perchance working in a bare repository, as I was? I spent some time
> > > looking at it and I think git archive sets up the environment in the wrong
> > > order, though of course I never finished a patch so I'm going from memory:
> > >
> > > After looking at the code again, I think the issue is that git_config is called
> > > in builtin-archive.c:cmd_archive before setup_git_directory is called in
> > > archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
> > > if you're in a bare repository. My coding skills weren't up to fixing it
> > > easily; moving setup_git_directory before git_config in builtin-archive caused
> > > last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
> > > should still display the archive formats.
> >
> > The problem affects some other commands as well. I tried the following
> > patch, ran "make test" and discovered "git mailinfo", "git
> > verify-pack", "git hash-object" and "git unpack-file". A bandage patch
> > is at the end of this mail. Solution is as Jeff suggested: call
> > setup_git_directory_gently() early.
>
>
> Nice work. The patches look like they're on the right track (to me at least).
> I'm not sure though what you want to ultimately submit as a patch; I'd suggest
> both, squashed into one, since the check seems like something we'd reasonably
> want no matter what.
No, the patches are not in good shape and have not been tested well. I
just wanted to point out the problem in other commands. Ideally the
check in setup_git_env() should go along with discover_git_directory()
as part of git setup rework.
>
> Few comments spread around below; also, can we see some testcases for
> regression? Or, does the first patch preclude the need for testcases?
>
> Deskin Miller
>
>
> > ---<---
> > diff --git a/environment.c b/environment.c
> > index 0693cd9..00ed640 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -49,14 +49,18 @@ static char *work_tree;
> >
> > static const char *git_dir;
> > static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
> > +int git_dir_discovered;
>
>
> Should this be 'int git_dir_discovered = 0;' ?
It is initialized by default IIRC.
> > Bandage patch:
> >
> > ---<---
> > diff --git a/builtin-archive.c b/builtin-archive.c
> > index 432ce2a..5ea0a12 100644
> > --- a/builtin-archive.c
> > +++ b/builtin-archive.c
> > @@ -110,7 +110,9 @@ static const char *extract_remote_arg(int *ac,
> > const char **av)
> > int cmd_archive(int argc, const char **argv, const char *prefix)
> > {
> > const char *remote = NULL;
> > + int nongit;
> >
> > + prefix = setup_git_directory_gently(&nongit);
>
>
> Here and elsewhere, the 'nongit' variable isn't used.
> setup_git_directory_gently can be passed a NULL pointer, why not do that?
Passing NULL to setup_git_directory_gently() tells it to die() if no
git repo can be found. If you pass a variable to it, it will set the
variable to 1 if no repo is found, 0 otherwise.
> > git_config(git_default_config, NULL);
> > while (1 < argc) {
> > if (!no_more_options && argv[1][0] == '-') {
> > diff --git a/hash-object.c b/hash-object.c
> > index 20937ff..a52b6be 100644
> > --- a/hash-object.c
> > +++ b/hash-object.c
> > @@ -78,19 +78,20 @@ int main(int argc, const char **argv)
> > const char *prefix = NULL;
> > int prefix_length = -1;
> > const char *errstr = NULL;
> > + int nongit;
> >
> > type = blob_type;
> >
> > - git_config(git_default_config, NULL);
> > -
> > argc = parse_options(argc, argv, hash_object_options, hash_object_usage, 0);
> >
> > - if (write_object) {
> > - prefix = setup_git_directory();
> > - prefix_length = prefix ? strlen(prefix) : 0;
> > - if (vpath && prefix)
> > - vpath = prefix_filename(prefix, prefix_length, vpath);
> > - }
> > + prefix = setup_git_directory_gently(&nongit);
> > + git_config(git_default_config, NULL);
> > + prefix_length = prefix ? strlen(prefix) : 0;
> > + if (vpath && prefix)
> > + vpath = prefix_filename(prefix, prefix_length, vpath);
> > +
> > + if (write_object && nongit)
> > + die("Git repository required");
>
>
> I'd move this check up to just after setup_git_directory_gently.
Yeah, sounds reasonable.
--
Duy
^ permalink raw reply
* git-daemon and hook output
From: Joey Hess @ 2008-10-24 5:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
According to githooks, standard output/error for the post-receive and
pre-receive hooks will be seen by the user. This is true if using ssh.
But if git-daemon has been configured to allow pushes, the user will
not see anything these hooks output, and only a not very helpful
! [remote rejected] master -> master (pre-receive hook declined)
I suppose that to fix this, git-daemon would have to select on stdout
and stderr and pipe them over the wire to the client. Apologies for not
even trying to write a patch to do that.
(I ran into this in a real-world application -- I'm implementing
anonymous pushes into ikiwiki, which are checked pre-receive to limit
them to changes that could be done via the web interface. So all my nice
error messages about why a commit is refused are not available, which is
a pity.)
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-daemon: set REMOTE_ADDR to client address
From: Joey Hess @ 2008-10-24 5:48 UTC (permalink / raw)
To: git
This allows hooks like pre-receive to look at the client's IP
address.
Of course the IP address can't be used to get strong security;
git-daemon isn't the right thing to use if you need that. However,
basic IP address checking can be good enough in some situations.
REMOTE_ADDR is the same environment variable used to communicate the
client's address to CGI scripts.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
Real world example: ikiwiki can use pre-receive to check that the pushed
changes are ones that anyone could make to the wiki's source via the web
interface, and thus safe to accept. It's useful to be able to ban IP
addresses from editing a wiki on the web, as a first line of defence to
guard against spammers etc. With this patch the same IP guards can be
applied to changes pushed in via git-daemon.
Documentation/git-daemon.txt | 9 +++++++++
daemon.c | 4 ++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index b08a08c..f1a570a 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -270,6 +270,15 @@ selectively enable/disable services per repository::
----------------------------------------------------------------
+ENVIRONMENT
+-----------
+'git-daemon' will set REMOTE_ADDR to the IP address of the client
+that connected to it, if the IP address is available. REMOTE_ADDR will
+be available in the environment of hooks called when
+services are performed.
+
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
diff --git a/daemon.c b/daemon.c
index 3e5582d..b9ba44c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -537,6 +537,10 @@ static int execute(struct sockaddr *addr)
#endif
}
loginfo("Connection from %s:%d", addrbuf, port);
+ setenv("REMOTE_ADDR", addrbuf, 1);
+ }
+ else {
+ unsetenv("REMOTE_ADDR");
}
alarm(init_timeout ? init_timeout : timeout);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Junio C Hamano @ 2008-10-24 5:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <81b0412b0810230607sfea05ddm62bd03f837fc922e@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Otherwise the other global settings which were already read and set up will
> be overwritten ...
This is the answer to the question I asked in:
http://thread.gmane.org/gmane.comp.version-control.git/97986/focus=98066
Perhaps we should use a separate variable as the original patch did, in:
http://article.gmane.org/gmane.comp.version-control.git/97987
How about doing it like this instead?
diff --git i/compat/cygwin.c w/compat/cygwin.c
index f196753..ebac148 100644
--- i/compat/cygwin.c
+++ w/compat/cygwin.c
@@ -91,26 +91,32 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
- * However, if the trust_executable_bit is set, we must use the Cygwin posix
+ * However, if core.filemode is set, we must use the Cygwin posix
* stat/lstat as the Windows stat fuctions do not determine posix filemode.
+ *
+ * Note that git_cygwin_config() does NOT call git_default_config() and this
+ * is deliberate. Many commands read from config to establish initial
+ * values in variables and later tweak them from elsewhere (e.g. command line).
+ * init_stat() is called lazily on demand, typically much late in the program,
+ * and calling git_default_config() from here would break such variables.
*/
static int native_stat = 1;
-extern int trust_executable_bit;
+static int core_filemode;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "core.ignorecygwinfstricks")) {
+ if (!strcmp(var, "core.ignorecygwinfstricks"))
native_stat = git_config_bool(var, value);
- return 0;
- }
- return git_default_config(var, value, cb);
+ else if (!strcmp(var, "core.filemode"))
+ core_filemode = git_config_bool(var, value);
+ return 0;
}
static int init_stat(void)
{
if (have_git_dir()) {
git_config(git_cygwin_config, NULL);
- if (!trust_executable_bit && native_stat) {
+ if (!core_filemode && native_stat) {
cygwin_stat_fn = cygwin_stat;
cygwin_lstat_fn = cygwin_lstat;
} else {
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: david @ 2008-10-24 6:21 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdqbta$rhe$1@ger.gmane.org>
On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:
> I decided to give the simpler GIT_DIR approach another go.
>
> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
> .file.git/ to track file's history. .file.git/info/excludes is
> initialized to the very strong '*' pattern to ensure that things such
> as git status etc only consider the actually tracked file.
>
> The obvious advantage over the previous implementation is that we
> don't rely on fragile and non-portable hardlinks. The disadvantage
> is that something really bad can happen if a command fails to obey
> GIT_DIR or GIT_WORK_TREE correctly.
this is a very interesting approach.
the thought that hit me as I finidhed reading this thread is that we
are very close to having the full continum of file/repository combinations
1. everything in the dir is part of one repository (the normal git case)
2. some of all of the individual files in a dir is it's own repository
(the zit case)
3. the in-between case where you can have multiple repositories that can
have multiple files in them.
how hard would it be to extend zit to support case #3?
offhand I can see it complicating the task of figuing out which repository
to use for a file, but what else?
David Lang
> Command delegation is made a little smarter:
>
> zit somecommand file [args...]
>
> gets delegated to
>
> git somecommand [args...]
>
> with GIT_DIR=.file.git and GIT_WORK_TREE="`pwd`", which works
> surprisingly well. To prevent stupid expressions such as zit add file
> file or zit commit file file, add and commit put the filename back at
> the end of the parameter list.
>
> Commands that seem to work correctly so far are init, add, log,
> status, diff, remote, push, pull, and even rebase -i.
>
> Commands that definitely need some work are rm (should it just remove
> the .file.git/ dir?) and mv (hairy: we would need to rename .file.git
> to .newname.git too, but rollbacks are likely to break things).
>
> The only new command introduced by zit is zit list, which lists all
> zit-tracked files in the current directory, currently in a very
> braindead way (e.g. I'd like it to display the proper status, such as
> C M or whatever; suggestions welcome).
>
> On the TODO list is also some smart way to guess which file we're
> talking about when no file is specified. Basically, the idea is to
> check if there's only one tracked file, or only one changed tracked
> file, and allow a missing file option in that case.
>
> As usual, comments suggestions and critiques welcome.
>
>
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 6:55 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: git
In-Reply-To: <4901077A.7050904@gmx.ch>
On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
> Hi!
>
> Giuseppe Bilotta wrote:
>> So today I decided to start hacking at a git-based but file-oriented
>> content tracker, which I decided to name Zit.
>
> This sounds great and would seem very useful to manage my ~/bin/
> directory which contains a set of unrelated one-file-tools that
> evolve over time. I haven't played with it yet though.
Nice to see I wasn't the only one with such a need 8-)
>> when you choose to start tracking a file with Zit [...]
>> Zit will create a directory .zit.file to hold a git repository
>
> If you have many files you want to track in a single directory
> (like ~/bin/), all those additional directories will quickly feel
> like clutter. If you track every file, it will even double the
> number of things you see with an "ls -a".
Ah, good point, I hadn't thought about that.
> If you decide against a shared repository, maybe you want to
> consider to not use ".zit.file/", but ".zit/file/" as the
> repository? This would reduce the clutter to a single directory,
> just like with ".git". And moving files around wouldn't be that
> much complicated.
Right. I'll give that a shot.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Johannes Sixt @ 2008-10-24 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024024631.GA20365@coredump.intra.peff.net>
Thank you for picking up the topic again and continuing on it. Your series
works nicely here, even without setting diff.*.binary.
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/5] userdiff: require explicitly allowing textconv
From: Johannes Sixt @ 2008-10-24 7:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024025553.GD2831@coredump.intra.peff.net>
Jeff King schrieb:
> This introduces a new diff options, ALLOW_TEXTCONV, which
> controls this behavior. It is off by default, but is
> explicitly turned on for the "log" family of commands, as
> well as the "diff" porcelain.
...
> Johannes, you had mentioned some heuristics. Maybe you would like to
> take a stab at implementing them on top of this?
I'll put it on my todo list for this weekend.
-- Hannes
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 7:14 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm>
On Fri, Oct 24, 2008 at 8:21 AM, <david@lang.hm> wrote:
> On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:
>
>> I decided to give the simpler GIT_DIR approach another go.
>>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
>>
>> The obvious advantage over the previous implementation is that we
>> don't rely on fragile and non-portable hardlinks. The disadvantage
>> is that something really bad can happen if a command fails to obey
>> GIT_DIR or GIT_WORK_TREE correctly.
>
> this is a very interesting approach.
>
> the thought that hit me as I finidhed reading this thread is that we are
> very close to having the full continum of file/repository combinations
>
> 1. everything in the dir is part of one repository (the normal git case)
>
> 2. some of all of the individual files in a dir is it's own repository (the
> zit case)
>
> 3. the in-between case where you can have multiple repositories that can
> have multiple files in them.
>
> how hard would it be to extend zit to support case #3?
>
> offhand I can see it complicating the task of figuring out which repository
> to use for a file, but what else?
I haven't tried this yet, but I think it should be possible without
much problems. The important thing to keep in mind is that the second
parameter to zit (for all commands but zit init) 'only' identifies the
repository, and the filename parameter is NOT passed to git. The only
exceptions are zit add and git commit, and I'm having second thoughts
on add. Anyway, you can always use the 'raw' version of a command to
guarantee that only GIT_DIR and GIT_WORK_TREE are set, thus:
$ zit rawadd somefile -f someotherfile
will force-add someotherfile to somefile's repo. (Force adding is
required because of the blanket exclude.) Of course, it would be
interesting adding to zit the capability to do
$ zit diff someotherfile
to make it guess that it should use somefile's repo. This is possible
with some symlinks for the git repos, probably.
I'll have a look into it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Johannes Sixt @ 2008-10-24 7:15 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024025330.GC2831@coredump.intra.peff.net>
Jeff King schrieb:
> This patch moves the text conversion to a
> diff_filespec_textconv function; this function can be called
> to insert the text-converted contents of the file into the
> filespec. These contents will survive through any
> diff_populate_filespec calls, meaning that it is safe to
> pass the resulting filespec to other diff functions which
> will look at the content.
What do we do when symlinks are involved? Pilot error? Or should we
exclude them from textconv (and diff.*.command, for that matter)
at all times? See a test case below.
> Also, I'm happy to hear comments on which functionality should get
> text-converted. I think I like seeing the --stat report the binary
> changes.
At this time I also think that it is enough to apply textconv only
to generate diffs.
Test case follows:
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index e456746..dab4338 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -19,6 +19,18 @@ cat >expect.text <<'EOF'
+1
EOF
+cat >expect.typechange <<'EOF'
+Binary files a/file and /dev/null differ
+diff --git a/file b/file
+new file mode 120000
+index ad8b3d2..67be421
+--- /dev/null
++++ b/file
+@@ -0,0 +1 @@
++frotz
+\ No newline at end of file
+EOF
+
cat >hexdump <<'EOF'
#!/bin/sh
perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
@@ -75,4 +87,16 @@ test_expect_success 'format-patch produces binary' '
test_cmp expect.binary actual
'
+# make a symlink the hard way that works on symlink-challenged file systems
+test_expect_failure 'textconv does not kick in if there is a type change' '
+ echo -n frotz > file &&
+ git add file &&
+ git ls-files -s | sed -e s/100644/120000/ |
+ git update-index --index-info &&
+ git commit -m typechange &&
+ git show >diff &&
+ find_diff <diff >actual &&
+ test_cmp expect.typechange actual
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-24 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <7viqri35dq.fsf@gitster.siamese.dyndns.org>
2008/10/24 Junio C Hamano <gitster@pobox.com>:
> Perhaps we should use a separate variable as the original patch did, in:
>
> http://article.gmane.org/gmane.comp.version-control.git/97987
>
> How about doing it like this instead?
I like this. Will start testing it over next european night, as soon as
the current test run finishes. In about 6 hours, that is :-/
^ permalink raw reply
* Re: git performance
From: Pete Harlan @ 2008-10-24 7:55 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
> > Yes, it does stat all the files. How many files are you talking about,
> > and what platform? From a warm cache on Linux, the 23,000 files kernel
> > repo takes about a tenth of a second to stat all files for me (and this
>
> I'm talking about 40-50,000 files, on multi-user production linux,
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn
> st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
I did some tests with a repo with ~32k files, and git was slightly
slower than svn with a cold cache (10.2s vs 8.4s), and around twice as
fast with a warm cache (.5s vs 1s).
Git 1.6.0.2, svn 1.4.6. Cache made cold with
"echo 1 >/proc/sys/vm/drop_caches". Timings best of 5 runs.
(I did various benchmarks with svn 1.5.3 also, but there's something
awfully wrong with svn 1.5.x's merging, which takes pathologically
long compared with 1.4 (minutes instead of seconds), and it wasn't
noticeably faster than 1.4 at anything I tested.)
> performance was approx the same for files on local disk versus NFS.
10 minutes seems like a crazy amount of time for 40-50k files. If you
didn't say you'd tested it on local disks, it would really sound like
a bad NFS interaction more than an svn problem.
> Out of curiosity, what are they talking about, when they say "git is
> fast?"
In my comparisons between svn and git, the operation "checkout
revision N of the tree" (i.e., "svn update -r 40000" vs "git checkout
302c7476") took five minutes on subversion and ten seconds using git.
The tests were all local, so git wasn't benefiting from being a DVCS,
it was just eerily fast on some things. Svn was even that slow when
the revisions were 1 commit different, if it was a large enough
commit.
I don't check out whole revisions like that very often, but switching
between branches is a similar operation. It doesn't usually take five
minutes in svn but it's an interruption, and with git it isn't.
For almost everything I tried git was faster, but status wasn't really
one of them. The compelling cases were the number of things that were
faster _enough_ to no longer be an interruption, and being a DVCS, and
rebase, and rebase -i, and gitk, and a smarter blame, and
branching/merging support like it's something you'd do all day long,
not just when you were forced to.
HTH,
--Pete
^ permalink raw reply
* Re: clean/smudge filters for pdf files
From: Michael J Gruber @ 2008-10-24 8:10 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Pierre Habouzit, git
In-Reply-To: <ee2a733e0810231840u1aed8455w7e4c461e2565ad08@mail.gmail.com>
Leo Razoumov venit, vidit, dixit 24.10.2008 03:40:
> On 10/23/08, Pierre Habouzit <madcoder@debian.org> wrote:
>> On Thu, Oct 23, 2008 at 07:44:39PM +0000, Leo Razoumov wrote:
>> > I am trying to improve storage efficiency for PDF files in a git repo.
>> > Following earlier discussions in this list I am trying to set up
>> > proper clean/smudge filters. What follows is my current setup
>> >
>> > # in ~/.gitconfig
>> > [filter "pdf"]
>> > clean = "pdftk - output - uncompress"
>> > smudge = "pdftk - output - compress"
>> >
>> > # in .gitattributes
>> > *.pdf filter=pdf
>> >
>> > Unfortunately, it seems as though that pdftk uncompress followed by
>> > pdftk compress do not leave the file invariant. I tried several
>> > uncompress+compress iterations and the file still keep changing (the
>> > size though stays the same).
>> > Is there any other alternative way to store PDF files in git repo more
>> > efficiently?
>> > Any alternative to pdftk on Linux?
>>
>>
>> actually it uses some kind of zlib algorithm so that's pretty normal you
>> don't have the same result with a packer. Maybe one could write a tool
>> like pristine-tar for that purpose.
>>
>
> With zlib you get the same deterministic result as long as you use the
> same zlib packer and unpacker. With pdftk compress/uncompress seem not
> to form a bijection pair. This issue was briefly discussed on this
> list back in April 2008 but no resolution emerged.
For a different file format I use the pair "gzip -c, gunzip -c" without
any problems, so zlib is not a problem. I do see the effect that
checkouts on different machines may have different compressed files
(same gzip version), but this is a non-issue.
Your experience with pdftk confirms mine. It shuffles things around
becauses it parses the files into objects and then writes them out again
in possibly different order. This is no problem for pdf because it uses
"pointers" (it's a bijection up to reordering), but it's a weird design,
and complicates things for us.
I'm still looking for something viable, I'll let list know when I've
found something...
Michael
^ permalink raw reply
* Re: [PATCH 3/7] gitk: Allow starting gui blame for a specific line.
From: Alexander Gavrilov @ 2008-10-24 8:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18688.26370.467724.404768@cargo.ozlabs.ibm.com>
On Thursday 23 October 2008 15:58:58 Paul Mackerras wrote:
> > + # Now scan the lines to determine offset within the hunk
> > + set parent {}
> > + set dline 0
> > + set s_lno [lindex [split $s_lix "."] 0]
> > +
> > + for {set i $line} {$i > $s_lno} {incr i -1} {
> > + set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
> > + if {$parent eq {}} {
> > + # find first preceeding line that belongs to some parent
> > + for {set j 0} {$j < [llength $old_lines]} {incr j} {
> > + set code [string index $c_line $j]
> > + if {$code ne {-} && $code ne { }} continue
> > + if {$code eq { } && $parent ne {}} continue
> > + set parent $j
> > + if {$code eq {-}} break
> > + }
> > + }
>
> This part worries me a bit. If the user clicks on a line where all
> the $code values are "+" then I think we should blame the current
> commit. Either that, or we disable the context menu item before
> posting it if the user clicks on a line that starts with all "+"
> characters (as many "+" as there are parents).
Good point. How about this variant? I renamed the menu item, and
changed the code to blame the current commit if:
- The display is in the tree mode, or
- The line is added relative to all parents, or
- Diff analysis failed
I also fixed a bug in processing of deleted lines in combined diffs,
and made the parent selection code more readable (hopefully).
--- >8 ---
From: Alexander Gavrilov <angavrilov@gmail.com>
Subject: [PATCH] gitk: Allow starting gui blame for a specific line.
Adds a context menu item to the diff viewer pane that
calls blame, focusing it on the clicked line. In case
of combined diffs, it also automatically deduces which
parent is to be blamed. Lines added by the diff are
blamed on the current commit itself.
The context menu itself is added by this patch. It is
possible to populate it with commands from the flist
menu.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 148 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index f6a3e10..6fbd6bb 100755
--- a/gitk
+++ b/gitk
@@ -2249,6 +2249,7 @@ proc makewindow {} {
bind $cflist <ButtonRelease-1> {treeclick %W %x %y}
global ctxbut
bind $cflist $ctxbut {pop_flist_menu %W %X %Y %x %y}
+ bind $ctext $ctxbut {pop_diff_menu %W %X %Y %x %y}
set maincursor [. cget -cursor]
set textcursor [$ctext cget -cursor]
@@ -2291,6 +2292,13 @@ proc makewindow {} {
{mc "Blame parent commit" command {external_blame 1}}
}
$flist_menu configure -tearoff 0
+
+ global diff_menu
+ set diff_menu .diffctxmenu
+ makemenu $diff_menu {
+ {mc "Blame this line" command {external_blame_diff}}
+ }
+ $diff_menu configure -tearoff 0
}
# Windows sends all mouse wheel events to the current focused window, not
@@ -2993,6 +3001,34 @@ proc pop_flist_menu {w X Y x y} {
tk_popup $flist_menu $X $Y
}
+proc find_ctext_fileinfo {line} {
+ global ctext_file_names ctext_file_lines
+
+ set ok [bsearch $ctext_file_lines $line]
+ set tline [lindex $ctext_file_lines $ok]
+
+ if {$ok >= [llength $ctext_file_lines] || $line < $tline} {
+ return {}
+ } else {
+ return [list [lindex $ctext_file_names $ok] $tline]
+ }
+}
+
+proc pop_diff_menu {w X Y x y} {
+ global ctext diff_menu flist_menu_file
+ global diff_menu_txtpos diff_menu_line
+ global diff_menu_filebase
+
+ stopfinding
+ set diff_menu_txtpos [split [$w index "@$x,$y"] "."]
+ set diff_menu_line [lindex $diff_menu_txtpos 0]
+ set f [find_ctext_fileinfo $diff_menu_line]
+ if {$f eq {}} return
+ set flist_menu_file [lindex $f 0]
+ set diff_menu_filebase [lindex $f 1]
+ tk_popup $diff_menu $X $Y
+}
+
proc flist_hl {only} {
global flist_menu_file findstring gdttype
@@ -3099,7 +3135,96 @@ proc external_diff {} {
}
}
-proc external_blame {parent_idx} {
+proc find_hunk_blamespec {base line} {
+ global ctext
+
+ # Find and parse the hunk header
+ set s_lix [$ctext search -backwards -regexp ^@@ "$line.0 lineend" $base.0]
+ if {$s_lix eq {}} return
+
+ set s_line [$ctext get $s_lix "$s_lix + 1 lines"]
+ if {![regexp {^@@@*(( -\d+(,\d+)?)+) \+(\d+)(,\d+)? @@} $s_line \
+ s_line old_specs osz osz1 new_line nsz]} {
+ return
+ }
+
+ # base lines for the parents
+ set base_lines [list $new_line]
+ foreach old_spec [lrange [split $old_specs " "] 1 end] {
+ if {![regexp -- {-(\d+)(,\d+)?} $old_spec \
+ old_spec old_line osz]} {
+ return
+ }
+ lappend base_lines $old_line
+ }
+
+ # Now scan the lines to determine offset within the hunk
+ set parent {}
+ set dline 0
+ set s_lno [lindex [split $s_lix "."] 0]
+
+ for {set i $line} {$i > $s_lno} {incr i -1} {
+ set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
+ # Determine if the line is removed
+ set chunk [string range $c_line 0 [llength $base_lines]-2]
+ set removed_idx [string first "-" $chunk]
+ # Choose a parent index
+ if {$parent eq {}} {
+ if {$removed_idx >= 0} {
+ set parent $removed_idx
+ incr parent
+ } else {
+ set unchanged_idx [string first " " $chunk]
+ if {$unchanged_idx >= 0} {
+ set parent $unchanged_idx
+ incr parent
+ } else {
+ # blame the current commit
+ set parent 0
+ }
+ }
+ }
+ # then count other lines that belong to it
+ if {$parent > 0} {
+ set code [string index $c_line $parent-1]
+ if {$code eq "-" || ($removed_idx < 0 && $code ne "+")} {
+ incr dline
+ }
+ } else {
+ if {$removed_idx < 0} {
+ incr dline
+ }
+ }
+ }
+
+ if {$parent eq {}} { set parent 0 }
+ incr dline [lindex $base_lines $parent]
+ return [list $parent $dline]
+}
+
+proc external_blame_diff {} {
+ global currentid diffmergeid cmitmode
+ global diff_menu_txtpos diff_menu_line
+ global diff_menu_filebase flist_menu_file
+
+ if {$cmitmode eq "tree"} {
+ set parent_idx 0
+ set line [expr {$diff_menu_line - $diff_menu_filebase - 1}]
+ } else {
+ set hinfo [find_hunk_blamespec $diff_menu_filebase $diff_menu_line]
+ if {$hinfo ne {}} {
+ set parent_idx [lindex $hinfo 0]
+ set line [lindex $hinfo 1]
+ } else {
+ set parent_idx 0
+ set line 0
+ }
+ }
+
+ external_blame $parent_idx $line
+}
+
+proc external_blame {parent_idx {line {}}} {
global flist_menu_file
global nullid nullid2
global parentlist selectedline currentid
@@ -3115,7 +3240,12 @@ proc external_blame {parent_idx} {
return
}
- if {[catch {exec git gui blame $base_commit $flist_menu_file &} err]} {
+ set cmdline [list git gui blame]
+ if {$line ne {} && $line > 1} {
+ lappend cmdline "--line=$line"
+ }
+ lappend cmdline $base_commit $flist_menu_file
+ if {[catch {eval exec $cmdline &} err]} {
error_popup "[mc "git gui blame: command failed:"] $err"
}
}
@@ -6364,6 +6494,7 @@ proc gettreeline {gtf id} {
proc showfile {f} {
global treefilelist treeidlist diffids nullid nullid2
+ global ctext_file_names ctext_file_lines
global ctext commentend
set i [lsearch -exact $treefilelist($diffids) $f]
@@ -6387,6 +6518,8 @@ proc showfile {f} {
filerun $bf [list getblobline $bf $diffids]
$ctext config -state normal
clear_ctext $commentend
+ lappend ctext_file_names $f
+ lappend ctext_file_lines [lindex [split $commentend "."] 0]
$ctext insert end "\n"
$ctext insert end "$f\n" filesep
$ctext config -state disabled
@@ -6447,6 +6580,7 @@ proc mergediff {id} {
proc getmergediffline {mdf id np} {
global diffmergeid ctext cflist mergemax
global difffilestart mdifffd treediffs
+ global ctext_file_names ctext_file_lines
global diffencoding
$ctext conf -state normal
@@ -6465,6 +6599,8 @@ proc getmergediffline {mdf id np} {
lappend difffilestart $here
lappend treediffs($id) $fname
add_flist [list $fname]
+ lappend ctext_file_names $fname
+ lappend ctext_file_lines [lindex [split $here "."] 0]
set diffencoding [get_path_encoding $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
@@ -6733,11 +6869,13 @@ proc setinlist {var i val} {
proc makediffhdr {fname ids} {
global ctext curdiffstart treediffs
+ global ctext_file_names
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
}
+ set ctext_file_names [lreplace $ctext_file_names end end $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
$ctext insert $curdiffstart "$pad $fname $pad" filesep
@@ -6746,6 +6884,7 @@ proc makediffhdr {fname ids} {
proc getblobdiffline {bdf ids} {
global diffids blobdifffd ctext curdiffstart
global diffnexthead diffnextnote difffilestart
+ global ctext_file_names ctext_file_lines
global diffinhdr treediffs
global diffencoding
@@ -6763,6 +6902,8 @@ proc getblobdiffline {bdf ids} {
# start of a new file
$ctext insert end "\n"
set curdiffstart [$ctext index "end - 1c"]
+ lappend ctext_file_names ""
+ lappend ctext_file_lines [lindex [split $curdiffstart "."] 0]
$ctext insert end "\n" filesep
# If the name hasn't changed the length will be odd,
# the middle char will be a space, and the two bits either
@@ -6899,6 +7040,7 @@ proc nextfile {} {
proc clear_ctext {{first 1.0}} {
global ctext smarktop smarkbot
+ global ctext_file_names ctext_file_lines
global pendinglinks
set l [lindex [split $first .] 0]
@@ -6912,6 +7054,8 @@ proc clear_ctext {{first 1.0}} {
if {$first eq "1.0"} {
catch {unset pendinglinks}
}
+ set ctext_file_names {}
+ set ctext_file_lines {}
}
proc settabs {{firstab {}}} {
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: clean/smudge filters for pdf files
From: Michael J Gruber @ 2008-10-24 8:44 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Pierre Habouzit, git
In-Reply-To: <ee2a733e0810231840u1aed8455w7e4c461e2565ad08@mail.gmail.com>
Little addition to my previous reply:
Multivalent apparently almost get's there. After 2 iterations most of
the uncompressed file is stable, except for some binary blob at the end.
Alas, it's Java and not even completely open source.
Michael
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Eric Wong @ 2008-10-24 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <7viqrkv4vd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> The patch may make a path with '~' work, but it (neither in the patch text
> >> nor in the commit log message) does not have much to give readers enough
> >> confidence that the code after the patch is the _final_ one, as opposed to
> >> being just a band-aid for a single symptom that happened to have been
> >> discovered this time.
> >
> > This is definitely a band-aid fix until I or somebody else takes the
> > time to figure out:
> >
> > 1. exactly which characters need to be escaped
> > 2. for which protocols those characters need to be escaped
> > 3. which part(s) of the URI they need to be escaped for
> > (repository root vs SVN path)
> > 4. which versions of SVN needs more (or less) escaping rules
> >
> > (I vote for somebody else, especially for #4 :)
>
> Item 3. above disturbs me. Do you mean that in:
>
> https://sucs.org/~welshbyte/svn/backuptool/trunk/foo~bar.txt
>
> the two tildes might have to be sent to libsvn-perl differently?
Yes, something like this is unfortunately a possibility (as is
having to worry about this at all in git-svn).
> Even if that is the case, I am inclined suggest taking the patch in the
> meantime as an interim workaround, with the understanding that we know the
> patch improves the situation for the tilde before welshbyte and even
> though we do not know if the patch regresses for the latter one between
> foo and bar, it would be much rarer to have tilde in such places.
>
> Care to come up with an updated log message?
From aa4f2cdcf64934e13886fabb3b5e986a5cda79f6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 21 Oct 2008 14:12:15 -0700
Subject: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
This change only fixes the tilde case in the repository URL. A
more comprehensive set of escaping rules and tests will be
needed in the future for complete compatibility when using
uncommon characters.
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the
bug report.
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> strace revealed that git-svn url-encodes ~ while svn does not do that.
>
> For svn we have:
> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>
> While git-svn shows:
> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ef6d773..a97049a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -852,7 +852,7 @@ sub escape_uri_only {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
@@ -3537,7 +3537,7 @@ sub repo_path {
sub url_path {
my ($self, $path) = @_;
if ($self->{url} =~ m#^https?://#) {
- $path =~ s/([^a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
+ $path =~ s/([^~a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
}
$self->{url} . '/' . $self->repo_path($path);
}
@@ -3890,7 +3890,7 @@ sub escape_uri_only {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git-svn: change dashed git-config to git config
From: Eric Wong @ 2008-10-24 9:15 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081023192134.GB8320@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> ---
> When testing git-svn changes, I'll often use git-svn.perl directly on a
> repository of mine, to see how things work. Recently I had this happen:
>
> $ git-svn.perl info
> Use of uninitialized value in scalar chomp at ../git/git-svn.perl line 1202.
> Use of uninitialized value in concatenation (.) or string at ../git/git-svn.perl line 1203.
>
> but the expected output showed up correctly, giving the SVN-like info.
>
> git svn info appeared to work just fine though, despite there being essentially
> no difference between the two. However, if I do the following, this is what I
> see:
>
> $ env /usr/libexec/git-core/git-svn info
> Can't exec "git-config": No such file or directory at /usr/libexec/git-core/git-svn line 1202.
> Use of uninitialized value in scalar chomp at /usr/libexec/git-core/git-svn line 1202.
>
> Again, the SVN info would still appear.
>
> Regardless, I think we want to change this call to use the non-dashed form.
Thanks Deskin,
Acked-by: Eric Wong <normalperson@yhbt.net>
> Deskin Miller
>
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 33e1b50..2e68c68 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1126,7 +1126,7 @@ sub read_repo_config {
> my $v = $opts->{$o};
> my ($key) = ($o =~ /^([a-zA-Z\-]+)/);
> $key =~ s/-//g;
> - my $arg = 'git-config';
> + my $arg = 'git config';
> $arg .= ' --int' if ($o =~ /[:=]i$/);
> $arg .= ' --bool' if ($o !~ /[:=][sfi]$/);
> if (ref $v eq 'ARRAY') {
> --
> 1.6.0.2.554.g3041b
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810232355u6de0479cyc260c80227f44e59@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
> > If you decide against a shared repository, maybe you want to
> > consider to not use ".zit.file/", but ".zit/file/" as the
> > repository? This would reduce the clutter to a single directory,
> > just like with ".git". And moving files around wouldn't be that
> > much complicated.
>
> Right. I'll give that a shot.
By the way RCS which I use for version control of single files use
both approaches: it can store 'file,v' alongside 'file' (just like
your '.zit.file/' or '.file.git/'), but it can also store files on
per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
'.zit/file.git/' solution)
By the way, it would be nice to have VC interface for Emacs for Zit...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdqbta$rhe$1@ger.gmane.org>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
> .file.git/ to track file's history. .file.git/info/excludes is
> initialized to the very strong '*' pattern to ensure that things such
> as git status etc only consider the actually tracked file.
[...]
Could you add it to Git Wiki page:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
I think that the project is interesting enough to be added there
even if it is still in beta, or even alpha, stage.
P.S. Currently I cannot access git.or.cz for some reason (it is
up for everyone else, and even for me on different remote machine).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 10:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <m38wsei8ne.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>
>> > If you decide against a shared repository, maybe you want to
>> > consider to not use ".zit.file/", but ".zit/file/" as the
>> > repository? This would reduce the clutter to a single directory,
>> > just like with ".git". And moving files around wouldn't be that
>> > much complicated.
>>
>> Right. I'll give that a shot.
>
> By the way RCS which I use for version control of single files use
> both approaches: it can store 'file,v' alongside 'file' (just like
> your '.zit.file/' or '.file.git/'), but it can also store files on
> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
> '.zit/file.git/' solution)
Indeed, there's not particular reason why both solutions shouldn't be
available. I'll think about implementing it this way:
$ zit init
will indicate that we want to track many files, and thus it will
create a .zit directory under which RCS files will be available.
$ zit track somefile
will start tracking somefile by setting up .zit/somefile.git if .zit
is available or .somefile.git otherwise.
The only problem then is priority. When looking for a file's repo, do
we look at .file.git first, or .zit/file.git? How does RCS behave in
this case?
> By the way, it would be nice to have VC interface for Emacs for Zit...
I'm afraid someone else will have to take care of that, since Emacs is
not really something I use.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 11:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m34p32i83f.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
> [...]
>
> Could you add it to Git Wiki page:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>
> I think that the project is interesting enough to be added there
> even if it is still in beta, or even alpha, stage.
Ah, good idea. Done, in Version Control Interface layers section
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 11:32 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810240352u28bab2b5p907065680985270a@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>>> If you decide against a shared repository, maybe you want to
>>>> consider to not use ".zit.file/", but ".zit/file/" as the
>>>> repository? This would reduce the clutter to a single directory,
>>>> just like with ".git". And moving files around wouldn't be that
>>>> much complicated.
>>>
>>> Right. I'll give that a shot.
>>
>> By the way RCS which I use for version control of single files use
>> both approaches: it can store 'file,v' alongside 'file' (just like
>> your '.zit.file/' or '.file.git/'), but it can also store files on
>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>> '.zit/file.git/' solution)
>
> Indeed, there's not particular reason why both solutions shouldn't be
> available. [...]
> The only problem then is priority. When looking for a file's repo, do
> we look at .file.git first, or .zit/file.git? How does RCS behave in
> this case?
rcsintro(1) states:
If you don't want to clutter your working directory with RCS files, create
a subdirectory called RCS in your working directory, and move all your RCS
files there. RCS commands will look *first* into that directory to find
needed files.
>> By the way, it would be nice to have VC interface for Emacs for Zit...
>
> I'm afraid someone else will have to take care of that, since Emacs is
> not really something I use.
I'll try to hack it using contrib/emacs/vc-git.el as a base...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <200810241332.32487.jnareb@gmail.com>
On Fri, Oct 24, 2008 at 1:32 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> By the way RCS which I use for version control of single files use
>>> both approaches: it can store 'file,v' alongside 'file' (just like
>>> your '.zit.file/' or '.file.git/'), but it can also store files on
>>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>>> '.zit/file.git/' solution)
>>
>> Indeed, there's not particular reason why both solutions shouldn't be
>> available. [...]
>
>> The only problem then is priority. When looking for a file's repo, do
>> we look at .file.git first, or .zit/file.git? How does RCS behave in
>> this case?
>
> rcsintro(1) states:
>
> If you don't want to clutter your working directory with RCS files, create
> a subdirectory called RCS in your working directory, and move all your RCS
> files there. RCS commands will look *first* into that directory to find
> needed files.
Cool. I pushed changes to this end to git.oblomov.eu/zit --now zit
will look for .zit/file.git first, then for .file.git; if neither is
found, and .zit/ exists, the repo is set to .zit/file.git, otherwise
it's set to .file.git
You can either manually mkdir .zit, or use zit init that does exactly
the same thing.
>>> By the way, it would be nice to have VC interface for Emacs for Zit...
>>
>> I'm afraid someone else will have to take care of that, since Emacs is
>> not really something I use.
>
> I'll try to hack it using contrib/emacs/vc-git.el as a base...
Cool, thanks.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
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