* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 21:51 UTC (permalink / raw)
To: 'Johannes Schindelin'
Cc: 'Junio C Hamano', 'Matthieu Moy', git
In-Reply-To: <Pine.LNX.4.64.0712182124410.23902@racer.site>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> Sent: Tuesday, December 18, 2007 1:27 PM
> To: Gerald Gutierrez
> Cc: 'Junio C Hamano'; 'Matthieu Moy'; git@vger.kernel.org
> Subject: RE: git with custom diff for commits
>
> Hi,
>
> On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
>
> > Yes, but wouldn't it be slick to actually teach git's
> internal diff to
> > do things like GNU diff can, like the ignore option -I, case
> > insensitivity, etc. I thought that's what the external diff
> capability
> > is for, but it is not so.
>
> I disagree. Your statement is misleading when you say you
> want the internal diff to do things like GNU diff can.
>
> What you want to do _in fact_ is not only modify the diff
> _output_, but the commit _input_.
>
> And I am not so keen on such filters. If I do not want to
> commit, I do not change it to begin with. Yes, your
> mysqldump is a special case here.
> But it is special anyway, as it is not source code.
I don't understand how it is a benefit to have "git commit" and "git diff"
do different diff functions. It confuses me. A scenario: I keep doing git
diff's and it says there is no difference, but then git commit keeps telling
me there is.
While I understand it was built for the kernel and everybody likes the plain
text format, it is not a stretch of the imagination to have files that are
semantically identical but have byte-wise differences. OpenDocument files,
image files, XML, etc. Cases can be made either way that "the same" means
semantically or byte-wise. It's perfectly fine that the default is
byte-wise. But, if the user takes the time to build a custom diff, then
wouldn't it be reasonable to assume that user means for git to do semantic
comparisons for diff, commit and other git functions, even if there are
inconsequential byte-wise differences in the file itself?
Gerald.
^ permalink raw reply
* Re: git with custom diff for commits
From: Junio C Hamano @ 2007-12-18 21:38 UTC (permalink / raw)
To: Gerald Gutierrez
Cc: 'Junio C Hamano', 'Matthieu Moy',
'Johannes Schindelin', git
In-Reply-To: <000101c841b7$5f1d1060$762a14ac@na.acco.com>
"Gerald Gutierrez" <ggmlfs@gmail.com> writes:
> I thought that's what the external diff capability is for,...
It certainly is. Your external diff gets all the information it needs
to generate whatever custom diff computation it may want to do.
^ permalink raw reply
* Re: [PATCH] Authentication support for pserver
From: Junio C Hamano @ 2007-12-18 21:37 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Martin Langhoff, Ævar Arnfjörð Bjarmason, git
In-Reply-To: <51dd1af80712181310q38255593t989be64799be2e0e@mail.gmail.com>
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com> writes:
>> On this aspect, I see no reason why we wouldn't have the passwords
>> crypt()ed or SHA1'd. Perl includes crypt() in the default
>> distribution, so it wouldn't add any dependency.
>
> It also includes Digest::SHA in the default distribution as of today:)
>
> I could add another option for allowing users to choose their password
> storage, e.g.:
>
> [gitcvs]
> password_storage = plaintext # or sha1, crypt, ...
I personally feel that selectable password storage format is going
overboard. Pick a reasonable one and use it everywhere.
Using some form of crypt is a good idea but then we would need a
separate mode of operation to gitcvs to generate user password.
$ gitcvs adduser junio
Password: ******
Retype password: ******
Added user 'junio' to .git/config
$ exit
I personally do not care about deluser or change-password subcommands,
as you can always go directly to .git/config to remove the user and
recreate anew, but adding them might be nice finishing touches.
$ gitcvs password junio
New password: ******
Retype password: ******
Changed password for user 'junio' in .git/config
$ gitcvs deluser junio
Are you sure you want to remove user 'junio' [y/N]? Y
Removed user 'junio' from .git/config
$ exit
^ permalink raw reply
* Re: [PATCH] git show <tag>: show the tagger
From: Jakub Narebski @ 2007-12-18 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vfxxzzrv8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > For commit objects, the Author is shown, so do the equivalent for
> > tag objects, too.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > I know, it's feature freeze period. But this is arguably a
> > usability bug.
>
> I'll wait for people to argue this fixes a usability bug, then.
IMHO the fact that currently "git show <tag>" _doesn't_ show
author and date of tag is a (usability) bug.
Fortunately "git cat-file -p <tag>" (or "git cat <tag>" with my
current alias) works, and dos show date in human-readable form.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* RE: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-18 21:27 UTC (permalink / raw)
To: Gerald Gutierrez; +Cc: 'Junio C Hamano', 'Matthieu Moy', git
In-Reply-To: <000101c841b7$5f1d1060$762a14ac@na.acco.com>
Hi,
On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
> Yes, but wouldn't it be slick to actually teach git's internal diff to
> do things like GNU diff can, like the ignore option -I, case
> insensitivity, etc. I thought that's what the external diff capability
> is for, but it is not so.
I disagree. Your statement is misleading when you say you want the
internal diff to do things like GNU diff can.
What you want to do _in fact_ is not only modify the diff _output_, but
the commit _input_.
And I am not so keen on such filters. If I do not want to commit, I do
not change it to begin with. Yes, your mysqldump is a special case here.
But it is special anyway, as it is not source code.
Ciao,
Dscho
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Jakub Narebski @ 2007-12-18 21:24 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Dana How
In-Reply-To: <20071218204623.GC2875@steel.home>
On Tue, 18 Dec 2007, Alex Riesen wrote:
> Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>>> Noticed by a collegue of mine. Consider:
>>>
>>> $ cd $GIT/t
>>> $ git show 570f32266:t/test-lib.sh # works
>>> $ git show 570f32266:test-lib.sh # does not work
>>> $ git show 570f32266:./test-lib.sh # does not work
>>> $ git show 570f32266:/t/test-lib.sh # does not work
>>>
>>> Considering that the relative path names work as filters (and many
>>> agreed on that being useful), it would be nice to allow relative
>>> pathnames in blob specifications for git-show and git-cat-file.
>>>
>>> (besides the colon is a good delimiter, even tab-completion
>>> works with it)
>>
>> If you think about it a bit, relative path names nor absolute
>> path names does and should not work. 570f32266:t/test-lib.sh
>> means path t/test-lib.sh staring from 570f32266^{tree}. Where
>> you are in the filesystem is not important and matters not for
>> this syntax. Besides if you access other branch file might be
>> not in filesystem (deleted file, or disjoint branch with separate
>> contents like 'todo' or 'html' branch in git.git repository).
>
> Not convinced. It is *not* the plumbing problem I was trying to
> describe. They discussion, metaphorically, should not have left the
> command-line parser.
>
> I think that we have parsing of the blob locators at the wrong level:
> so that git-show, git-log and git-diff can handle its pathnames as
> they handle path filters (relative to cwd),
What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
IMHO "<tree-ish>:<path>" should be considered (and is considered) as
one object: current working directory doesn't matter at all there,
contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec>
is relative to current working directory.
What should git do in your proposal when we are on master branch in
Documentation subdirectory, and want to check TODO file in todo branch?
"git show todo:TODO" is most natural IMHO.
Note that for true <tree> as <tree-ish> you just don't know where
in the working area directory hierarchy <tree> can be. This means you
do't know relation of <tree> and <path> in <tree>:<path> to cwd.
> and git-cat-file,
> git-diff-tree, git-rev-list, etc can handle theirs always relative to
> the project root.
Not "relative to project root". Relative to tree-ish used on right hand
side in <tree-ish>:<path> extended SHA-1 syntax. It is usually project
root, because when you specify <commit> or <tag> as <tree-ish> it refers
to top/root directory of a project.
> I actually do not see any problem for git-show (being porcelain-level
> program) to treat *each and every* path anywhere relatively to the
> current directory. It is just more comfortable.
This breaks backward compatibility, hard. And IMHO breaks layers.
But if (big if) it was to be implemented, default behavior should be
unchanged, and relative to the cwd (layers!) should use new syntax,
for example
$ cd $GIT/t
$ git show 570f32266:t/test-lib.sh # works
$ git show 570f32266:test-lib.sh # should not work
$ git show 570f32266:./test-lib.sh # should work
$ git show 570f32266:/t/test-lib.sh # should perhaps work
Currently ":/<text>" (but not "<ref>:/<text>") is taken; see
git-rev-parse(1), "Specifying revisions".
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Simple support for tree entry specification with relative pathnames
From: Alex Riesen @ 2007-12-18 21:17 UTC (permalink / raw)
To: Dana How
Cc: Jakub Narebski, git, Junio C Hamano, Johannes Schindelin,
Linus Torvalds
In-Reply-To: <56b7f5510712181303h1e7ae35dpa0adfd6804a7cecd@mail.gmail.com>
Dana How, Tue, Dec 18, 2007 22:03:04 +0100:
> ACK from me...
But NAK from me. Definitely not in this form. Please consider the
patches *only* as an RFC.
> I submitted a similar patch last May 4 which also changed
> sha1_name.c to do this. The patch added a config variable to
> control this (probably not desirable). The patch also handled
> leading/embedded . and .. .
This one (the last in series) too.
> In p4 you can say
> p4 <operation> file#rev
> and file is interpreted relatively.
>
> I wanted to be able to say
> git <operation> tree:file
> and have file interpreted relatively.
> This should only happen when you are inside the work tree.
It is pure coincedence the syntaxes look similar. They are very deeply
different in Git and Perforce.
^ permalink raw reply
* Re: [PATCH] Authentication support for pserver
From: Ævar Arnfjörð Bjarmason @ 2007-12-18 21:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <46a038f90712181238p7529a02bmde21c89956a3f641@mail.gmail.com>
On Dec 18, 2007 8:38 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On Dec 18, 2007 10:41 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > - git/config is very likely to be readable if the site is served via
> > other means, like dumb http protocol, or git+ssh. So even if the
> > password scrambling is mickey-mouse. it might make sense to force the
> > password data to live elsewhere.
>
> On this aspect, I see no reason why we wouldn't have the passwords
> crypt()ed or SHA1'd. Perl includes crypt() in the default
> distribution, so it wouldn't add any dependency.
It also includes Digest::SHA in the default distribution as of today:)
I could add another option for allowing users to choose their password
storage, e.g.:
[gitcvs]
password_storage = plaintext # or sha1, crypt, ...
^ permalink raw reply
* Re: [PATCH] Use pathexpand to preparse the relative pathnames in blob references
From: Dana How @ 2007-12-18 21:06 UTC (permalink / raw)
To: Alex Riesen
Cc: Jakub Narebski, git, Junio C Hamano, Johannes Schindelin,
Linus Torvalds, danahow
In-Reply-To: <20071218205253.GF2875@steel.home>
On Dec 18, 2007 12:52 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> This, OTOH, is a bit intrusive and changes the current behaviour a bit
> too far. git-show cannot use the absolute pathnames in blob locators
> at all now, which I consider bad. An obvious way to use rev:/path is
> blocked by Johannes' get_sha1_oneline. It would have worked, though.
Last May Junio proposed the current :/ should be changed to :?
since it actually searches backwards. Then :/ would be an absolute path,
and : could default to relative (like Unix command line).
Because of this incompatibility I think he wanted to delay it
until 1.5.6 or 1.6 (see old thread).
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] Simple support for tree entry specification with relative pathnames
From: Dana How @ 2007-12-18 21:03 UTC (permalink / raw)
To: Alex Riesen
Cc: Jakub Narebski, git, Junio C Hamano, Johannes Schindelin,
Linus Torvalds, danahow
In-Reply-To: <20071218204752.GD2875@steel.home>
ACK from me...
I submitted a similar patch last May 4 which also
changed sha1_name.c to do this. The patch
added a config variable to control this
(probably not desirable). The patch also handled
leading/embedded . and .. .
In p4 you can say
p4 <operation> file#rev
and file is interpreted relatively.
I wanted to be able to say
git <operation> tree:file
and have file interpreted relatively.
This should only happen when you are inside the work tree.
Good luck!
Dana
On Dec 18, 2007 12:47 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> This allows git show to understand something like this:
>
> $ test -f DIR/file && cd DIR && git show rev:file
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> This is a bit too simplistic and can be fooled easily:
>
> .../t$ git show HEAD:../t/test-lib.sh
>
> wont work. It is short, though.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [PATCH] Use pathexpand to preparse the relative pathnames in blob references
From: Alex Riesen @ 2007-12-18 20:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <20071218204947.GE2875@steel.home>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This, OTOH, is a bit intrusive and changes the current behaviour a bit
too far. git-show cannot use the absolute pathnames in blob locators
at all now, which I consider bad. An obvious way to use rev:/path is
blocked by Johannes' get_sha1_oneline. It would have worked, though.
sha1_name.c | 21 +++++++--------------
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 358aab7..369e7d0 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -661,7 +661,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode)
{
- char *prefixpath;
+ char *prefixpath = NULL;
int ret, bracket_depth;
int namelen = strlen(name);
const char *cp;
@@ -671,8 +671,6 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh
if (!ret)
return ret;
- prefixpath = prefix ? xmalloc(strlen(prefix) + namelen + 1): NULL;
-
/* sha1:path --> object name of path in ent sha1
* :path -> object name of path in index
* :[0-3]:path -> object name of path in index at stage
@@ -694,10 +692,9 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh
namelen = namelen - (cp - name);
if (!active_cache)
read_cache();
- if (prefix) {
- namelen = sprintf(prefixpath, "%s%s", prefix, cp);
- cp = prefixpath;
- }
+ prefixpath = pathexpand(prefix, cp);
+ namelen = strlen(prefixpath);
+ cp = prefixpath;
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
@@ -728,13 +725,9 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh
if (*cp == ':') {
unsigned char tree_sha1[20];
if (!get_sha1_1(name, cp-name, tree_sha1)) {
- if (!prefix)
- ret = get_tree_entry(tree_sha1, cp + 1, sha1, mode);
- else {
- sprintf(prefixpath, "%s%s", prefix, cp + 1);
- ret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);
- free(prefixpath);
- }
+ prefixpath = pathexpand(prefix, cp + 1);
+ ret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);
+ free(prefixpath);
}
}
return ret;
--
1.5.4.rc0.86.g30f5
^ permalink raw reply related
* [PATCH] Introduce pathexpand: syntax-level chdir into the given cwd
From: Alex Riesen @ 2007-12-18 20:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <20071218204752.GD2875@steel.home>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This will be used by the following patch. I actually already have sent
this one in, as suggestion for some problem back then. It is a bit
generic, so it gets its own patch.
cache.h | 2 ++
path.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 054f106..25ce5da 100644
--- a/cache.h
+++ b/cache.h
@@ -383,6 +383,8 @@ static inline int is_absolute_path(const char *path)
return path[0] == '/';
}
const char *make_absolute_path(const char *path);
+/* Returns the analog of "cd path" from a directory "cwd" */
+extern char *pathexpand(const char *cwd, 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 4260952..8231cd8 100644
--- a/path.c
+++ b/path.c
@@ -353,3 +353,62 @@ const char *make_absolute_path(const char *path)
return buf;
}
+
+/*
+ * Returns the analog of "cd path" from a directory "cwd".
+ * The root is defined as empty path (instead of "/")
+ * An attempt to go past the root (with "..") leaves the path at root.
+ * The cwd is not expanded.
+ */
+char *pathexpand(const char *cwd, const char *path)
+{
+ static const char SEP[] = "/";
+ if (!*path) /* empty path -> "." (don't move) */
+ path = ".";
+ if (!cwd || !*cwd || *SEP == *path) /* no cwd, or path begins with "/" */
+ cwd = "";
+
+ while (*cwd && *SEP == *cwd)
+ ++cwd;
+
+ size_t len = strlen(cwd);
+ char *out = malloc(len + 1 + strlen(path) + 1);
+ char *p = strcpy(out, cwd) + len;
+
+ for (; *path; ++path)
+ {
+ char *pl;
+ if (p > out && p[-1] != *SEP)
+ *p++ = *SEP;
+ pl = p;
+ while (*path && *SEP != *path)
+ *p++ = *path++;
+ *p = '\0';
+ /* ..."//"... */
+ if (p == pl)
+ ; /* just ignore */
+ /* ..."/./"... */
+ else if ( p - pl == 1 && '.' == *pl )
+ --p; /* just ignore */
+ /* ..."/../"... */
+ else if ( p - pl == 2 && '.' == pl[0] && '.' == pl[1] )
+ {
+ /* drop the last element of the resulting path */
+ if (pl > out && --pl > out)
+ for (--pl; pl > out && *SEP != *pl; --pl)
+ ;
+ p = pl > out ? ++pl: out;
+ }
+ /* ..."/path/"... */
+ else if (*path)
+ *p++ = *path; /* just add the separator */
+
+ if (!*path)
+ break;
+ }
+ if (p > out+1 && *SEP == p[-1])
+ --p;
+ *p = '\0';
+ return out;
+}
+
--
1.5.4.rc0.86.g30f5
^ permalink raw reply related
* [PATCH] Simple support for tree entry specification with relative pathnames
From: Alex Riesen @ 2007-12-18 20:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <20071218204623.GC2875@steel.home>
This allows git show to understand something like this:
$ test -f DIR/file && cd DIR && git show rev:file
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This is a bit too simplistic and can be fooled easily:
.../t$ git show HEAD:../t/test-lib.sh
wont work. It is short, though.
cache.h | 1 +
revision.c | 4 ++--
sha1_name.c | 27 ++++++++++++++++++++++++---
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 39331c2..054f106 100644
--- a/cache.h
+++ b/cache.h
@@ -416,6 +416,7 @@ static inline unsigned int hexval(unsigned char c)
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);
+extern int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
extern int read_ref(const char *filename, unsigned char *sha1);
diff --git a/revision.c b/revision.c
index 7e2f4f1..cac283c 100644
--- a/revision.c
+++ b/revision.c
@@ -855,7 +855,7 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
local_flags = UNINTERESTING;
arg++;
}
- if (get_sha1_with_mode(arg, sha1, &mode))
+ if (get_sha1_with_prefix(revs->prefix, arg, sha1, &mode))
return -1;
if (!cant_be_filename)
verify_non_filename(revs->prefix, arg);
@@ -1280,7 +1280,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
unsigned char sha1[20];
struct object *object;
unsigned mode;
- if (get_sha1_with_mode(def, sha1, &mode))
+ if (get_sha1_with_prefix(revs->prefix, def, sha1, &mode))
die("bad default revision '%s'", def);
object = get_reference(revs, def, sha1, 0);
add_pending_object_with_mode(revs, object, def, mode);
diff --git a/sha1_name.c b/sha1_name.c
index 13e1164..358aab7 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -656,6 +656,12 @@ int get_sha1(const char *name, unsigned char *sha1)
int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
{
+ return get_sha1_with_prefix(NULL, name, sha1, mode);
+}
+
+int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode)
+{
+ char *prefixpath;
int ret, bracket_depth;
int namelen = strlen(name);
const char *cp;
@@ -664,6 +670,9 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
ret = get_sha1_1(name, namelen, sha1);
if (!ret)
return ret;
+
+ prefixpath = prefix ? xmalloc(strlen(prefix) + namelen + 1): NULL;
+
/* sha1:path --> object name of path in ent sha1
* :path -> object name of path in index
* :[0-3]:path -> object name of path in index at stage
@@ -685,6 +694,10 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
namelen = namelen - (cp - name);
if (!active_cache)
read_cache();
+ if (prefix) {
+ namelen = sprintf(prefixpath, "%s%s", prefix, cp);
+ cp = prefixpath;
+ }
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
@@ -696,10 +709,12 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
if (ce_stage(ce) == stage) {
hashcpy(sha1, ce->sha1);
*mode = ntohl(ce->ce_mode);
+ free(prefixpath);
return 0;
}
pos++;
}
+ free(prefixpath);
return -1;
}
for (cp = name, bracket_depth = 0; *cp; cp++) {
@@ -712,9 +727,15 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp-name, tree_sha1)) {
+ if (!prefix)
+ ret = get_tree_entry(tree_sha1, cp + 1, sha1, mode);
+ else {
+ sprintf(prefixpath, "%s%s", prefix, cp + 1);
+ ret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);
+ free(prefixpath);
+ }
+ }
}
return ret;
}
--
1.5.4.rc0.86.g30f5
^ permalink raw reply related
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 20:48 UTC (permalink / raw)
To: 'Junio C Hamano'
Cc: 'Matthieu Moy', 'Johannes Schindelin', git
In-Reply-To: <7vzlw7ybx7.fsf@gitster.siamese.dyndns.org>
Yes, but wouldn't it be slick to actually teach git's internal diff to do
things like GNU diff can, like the ignore option -I, case insensitivity,
etc. I thought that's what the external diff capability is for, but it is
not so.
Gerald.
> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Tuesday, December 18, 2007 12:40 PM
> To: Gerald Gutierrez
> Cc: 'Junio C Hamano'; 'Matthieu Moy'; 'Johannes Schindelin';
> git@vger.kernel.org
> Subject: Re: git with custom diff for commits
>
> "Gerald Gutierrez" <ggmlfs@gmail.com> writes:
>
> > I ended up doing the following, which sounds similar to the above.
> > Instead of doing mysqldump into data.sql, it goes into data.sql.2
> > which I compare with the checked in data.sql using "diff -I
> <timestamp
> > RE>". If there are no differences, I delete data.sql.2. If
> there are
> > differences, I move
> > data.sql.2 into data.sql and check in. Perhaps not as elegant but
> > certainly works.
>
> Heh, that's essentially how automated html/man branches are
> managed ;-)
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Alex Riesen @ 2007-12-18 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <m3d4t3q4e5.fsf@roke.D-201>
Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Noticed by a collegue of mine. Consider:
> >
> > $ cd $GIT/t
> > $ git show 570f32266:t/test-lib.sh # works
> > $ git show 570f32266:test-lib.sh # does not work
> > $ git show 570f32266:./test-lib.sh # does not work
> > $ git show 570f32266:/t/test-lib.sh # does not work
> >
> > Considering that the relative path names work as filters (and many
> > agreed on that being useful), it would be nice to allow relative
> > pathnames in blob specifications for git-show and git-cat-file.
> >
> > (besides the colon is a good delimiter, even tab-completion works with it)
>
> If you think about it a bit, relative path names nor absolute
> path names does and should not work. 570f32266:t/test-lib.sh
> means path t/test-lib.sh staring from 570f32266^{tree}. Where
> you are in the filesystem is not important and matters not for
> this syntax. Besides if you access other branch file might be
> not in filesystem (deleted file, or disjoint branch with separate
> contents like 'todo' or 'html' branch in git.git repository).
Not convinced. It is *not* the plumbing problem I was trying to
describe. They discussion, metaphorically, should not have left the
command-line parser.
I think that we have parsing of the blob locators at the wrong level:
so that git-show, git-log and git-diff can handle its pathnames as
they handle path filters (relative to cwd), and git-cat-file,
git-diff-tree, git-rev-list, etc can handle theirs always relative to
the project root.
I actually do not see any problem for git-show (being porcelain-level
program) to treat *each and every* path anywhere relatively to the
current directory. It is just more comfortable.
Please consider the following patches.
^ permalink raw reply
* Re: git with custom diff for commits
From: Junio C Hamano @ 2007-12-18 20:40 UTC (permalink / raw)
To: Gerald Gutierrez
Cc: 'Junio C Hamano', 'Matthieu Moy',
'Johannes Schindelin', git
In-Reply-To: <000001c841b5$89fcef00$762a14ac@na.acco.com>
"Gerald Gutierrez" <ggmlfs@gmail.com> writes:
> I ended up doing the following, which sounds similar to the above. Instead
> of doing mysqldump into data.sql, it goes into data.sql.2 which I compare
> with the checked in data.sql using "diff -I <timestamp RE>". If there are no
> differences, I delete data.sql.2. If there are differences, I move
> data.sql.2 into data.sql and check in. Perhaps not as elegant but certainly
> works.
Heh, that's essentially how automated html/man branches are managed ;-)
^ permalink raw reply
* Re: [PATCH] Authentication support for pserver
From: Martin Langhoff @ 2007-12-18 20:39 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, git, martyn, martin
In-Reply-To: <46a038f90712180141x2f27e6cei5ef53339fd3f90dc@mail.gmail.com>
On Dec 18, 2007 10:41 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> - git/config is very likely to be readable if the site is served via
> other means, like dumb http protocol, or git+ssh. So even if the
> password scrambling is mickey-mouse. it might make sense to force the
> password data to live elsewhere.
On this aspect, I see no reason why we wouldn't have the passwords
crypt()ed or SHA1'd. Perl includes crypt() in the default
distribution, so it wouldn't add any dependency.
The protocol may be ROT13'ing the passwords, but we don't have to
double-ROT13 them in our storage format ;-)
cheers,
martin
^ permalink raw reply
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-18 20:35 UTC (permalink / raw)
To: 'Junio C Hamano', 'Matthieu Moy'
Cc: 'Johannes Schindelin', git
In-Reply-To: <7vodco1him.fsf@gitster.siamese.dyndns.org>
>
> So my updated suggestion would be:
>
> - Keep a checkout of that mysql dump;
>
> - Make the dump procedure to dump to that checkout area;
>
> - Run "git diff HEAD", perhaps with the external diff that
> filters out
> the cruft as suggested in the thread, and run "git checkout $path"
> for paths that had only meaningless changes;
>
> - Run "git commit" if the above step did not nuke all changes.
>
I ended up doing the following, which sounds similar to the above. Instead
of doing mysqldump into data.sql, it goes into data.sql.2 which I compare
with the checked in data.sql using "diff -I <timestamp RE>". If there are no
differences, I delete data.sql.2. If there are differences, I move
data.sql.2 into data.sql and check in. Perhaps not as elegant but certainly
works.
Gerald.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-18 20:24 UTC (permalink / raw)
To: Jeff King
Cc: Martin Langhoff, Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <20071218111136.GA6266@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I can think of two other user-visible changes which have been discussed
> that might warrant such a version bump:
>
> - option parsing tweaks (hopefully these should be minor, but it is
> clear that we cannot be 100% consistent while retaining the
> identical previous behavior)
This could have a fallout, like *-default disambiguation which scripts
did not have to implement.
> - moving dashed forms out of paths
This is already planned for 1.5.5 and it is not among "other
user-visible changes". Technically the use of git-foo form without
preparing the environment has not been supported for quite some time,
but people have come to rely on it and I'd agree this warrants a 1.6.0.
^ permalink raw reply
* Re: [PATCH w/ test] rebase -p -i: handle "no changes" gracefully
From: Junio C Hamano @ 2007-12-18 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pieter de Bie, Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0712172100450.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Since commit 376ccb8cbb453343998e734d8a1ce79f57a4e092, unchanged
> SHA-1s are no longer mapped via $REWRITTEN. But the updating
> phase was not prepared for the old head not being rewritten.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Mon, 17 Dec 2007, Junio C Hamano wrote:
>
> > Hmph, care to add a test to t3404?
>
> How about this?
Looks good. Thanks.
^ permalink raw reply
* Re: [PATCH] Improved submodule merge support
From: Johannes Schindelin @ 2007-12-18 20:21 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: gitster, git
In-Reply-To: <20071218195028.GA25510@pvv.org>
Hi,
On Tue, 18 Dec 2007, Finn Arne Gangstad wrote:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 2a58dad..33ccc40 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -1463,10 +1467,13 @@ static int process_entry(const char *path, struct stage_data *entry,
> mfi = merge_file(&o, &a, &b,
> branch1, branch2);
>
> + clean_merge = mfi.clean;
> if (mfi.clean)
> update_file(1, mfi.sha, mfi.mode, path);
> + else if (S_ISGITLINK(mfi.mode))
> + output(1, "CONFLICT (submodule): Merge conflict in %s "
> + "- needs %s", path, sha1_to_hex(b.sha1));
> else {
> - clean_merge = 0;
> output(1, "CONFLICT (%s): Merge conflict in %s",
> reason, path);
>
It took me a little while to find that the unilateral assignment to
clean_merge does not break things. But as it was only set to 1 at the
beginning of the function, and no loops are involved, this change is
correct.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-18 20:12 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Junio C Hamano, Martin Langhoff, Joel Becker,
Jakub Narebski, git
In-Reply-To: <20071218193035.GA4583@sigill.intra.peff.net>
On Tue, 18 Dec 2007, Jeff King wrote:
> So there will be user-visible changes (though I don't expect them to be
> huge...there simply aren't that many variables with optional arguments).
OTOH, there are quite a bunch of changes affecting the user experience.
Many of the feedback messages printed by Git were completely revamped,
starting with the progress display to the fetch summary.
Nicolas
^ permalink raw reply
* Re: [PATCH] git show <tag>: show the tagger
From: Junio C Hamano @ 2007-12-18 20:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712181800250.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For commit objects, the Author is shown, so do the equivalent for
> tag objects, too.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I know, it's feature freeze period. But this is arguably a
> usability bug.
I'll wait for people to argue this fixes a usability bug, then.
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Junio C Hamano @ 2007-12-18 20:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pascal Obry, Johannes Sixt, Pascal Obry, git
In-Reply-To: <alpine.LFD.0.9999.0712180840060.21557@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 18 Dec 2007, Pascal Obry wrote:
>
>> Johannes Sixt a écrit :
>> > that we need another diff option for it. Ok, on my keyboard 0 is typed
>> > with the right hand, and 1 with the left hand, but... ??
>>
>> Because you just did not read my follow-up message :)
>>
>> I need this has I do not have the way to change the server applying the
>> patch. So nothing wrong with my hands or fingers :)
> ....
> So I think you'd need separate arguments for the from/to prefixes, and not
> try to shoehorn it into one argument. With possibly some simple form to
> say "no prefix". So maybe something like
>
> --src-prefix=<string> // default "a/"
> --dst-prefix=<string> // default "b/"
> --no-prefix // shorthand for --src-prefix="" --dst-prefix=""
>
> would work for everybody?
One worry I have is that "diff --git" is validated more strictly than
other diffs by "git-apply", and patches generated with arbitrary prefix
would break it. It might make sense to drop " --git" from the patch
header if we allow a/ and b/ to be changed inconsistently.
^ permalink raw reply
* Re: [PATCH v4] Teach diff machinery to display other prefixes than "a/" and "b/"
From: Linus Torvalds @ 2007-12-18 19:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, Pascal Obry, Johannes Sixt, Pascal Obry, git
In-Reply-To: <Pine.LNX.4.64.0712181930130.23902@racer.site>
On Tue, 18 Dec 2007, Johannes Schindelin wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Thanks,
Linus
^ 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