* Re: [PATCH] built-in "git grep" (git grip).
From: Jakub Narebski @ 2006-05-02 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <44571967.7080807@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> Yes, I understand, but I just don't like using 'grip'. And it would be
>> nice to have some convention for further not-ready-yet built-in
>> replacements for script versions of commands, for example adding letter
>> 'b' as 'built-in' at the beginning of command name: 'bgrep', 'bdiff'. Or
>> use postfix 'n' or '-ng' to denote transitionary not-ready-yet new
>> version of command: 'grepn', 'diffn' or 'grep-ng', 'diff-ng'.
>>
>
> Forcing the user to remember what's implemented as built-ins is not a
> good idea. It was for that exact reason the "git-<command>-script" were
> all renamed "git-<command>" once upon a time.
>
> "git grip" work just fine for me, since it's only intended for testing
> and performance improvements so far. I also think it's clearer for
> end-users looking for a grep command if they're not faced with
> fgrep/egrep/ggrep/bgrep alongside plain "grep".
Well, scratch 'bgrep' idea, even if I had no intend for 'bgrep' to be
persistent name; it was meant as transitionary name. Well, that doesn't
matter much because someone interested in testing new, not-ready-yet
versions of commands (I like 'grepn' idea) usually would follow git
development, and would know (or not) about new version of 'git grep' being
'git grip' (and not 'git grepn').
What about forcing using external grep, and the fact that grep is linked
with libpcre?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Andreas Ericsson @ 2006-05-02 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e34cb4$is1$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> Jakub Narebski <jnareb@gmail.com> writes:
>
>
>>Wouldn't "git ggrep" (from git-aware grep) or "git bgrep" (from built-in
>>grep), similar to the egrep and fgrep from the grep package?
>
>
> Yes, I understand, but I just don't like using 'grip'. And it would be nice
> to have some convention for further not-ready-yet built-in replacements for
> script versions of commands, for example adding letter 'b' as 'built-in' at
> the beginning of command name: 'bgrep', 'bdiff'. Or use postfix 'n' or
> '-ng' to denote transitionary not-ready-yet new version of command:
> 'grepn', 'diffn' or 'grep-ng', 'diff-ng'.
>
Forcing the user to remember what's implemented as built-ins is not a
good idea. It was for that exact reason the "git-<command>-script" were
all renamed "git-<command>" once upon a time.
"git grip" work just fine for me, since it's only intended for testing
and performance improvements so far. I also think it's clearer for
end-users looking for a grep command if they're not faced with
fgrep/egrep/ggrep/bgrep alongside plain "grep".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Bug in git log
From: Junio C Hamano @ 2006-05-02 8:24 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060502075122.GA8203@spinlock.ch>
Matthias Kestenholz <lists@irregular.ch> writes:
> Inside your git source directory, do:
>
> First bug using old whatchanged script (not builtin version)
>
> $ ./git-whatchanged.sh -- unresolve.c
> fatal: ambiguous argument 'unresolve.c': unknown revision or
> filename
> Use '--' to separate filenames from revisions
>
> $ ./git-whatchanged.sh -- -- unresolve.c
> [...] gives the expected output
That indeed sounds funny. I was hoping to see it myself but did
not reproduce for me X-<.
> $ git log -- unresolve.c
> $ git log -- -- unresolve.c
> $ git whatchanged -- unresolve.c
>
> both give no output.
I do not have an older version between 0.99.9m and 1.3.1, but
1.3.1 (the current stale release) does not seem to have this
"double dash" problem. Neither the tonight's "master" version
(746437) nor "next".
We used to have a build problem where we forgot to remove
libgit.a and an old object from the archive was used by
mistake. Could you try rm -f libgit.a and rebuild your git to
see if it helps?
^ permalink raw reply
* Bug in git log
From: Matthias Kestenholz @ 2006-05-02 7:51 UTC (permalink / raw)
To: git
Hello list,
I found a bug in the new builtin git log which I am unable to fix
myself.
Inside your git source directory, do:
First bug using old whatchanged script (not builtin version)
$ ./git-whatchanged.sh -- unresolve.c
fatal: ambiguous argument 'unresolve.c': unknown revision or
filename
Use '--' to separate filenames from revisions
$ ./git-whatchanged.sh -- -- unresolve.c
[...] gives the expected output
$ git log -- unresolve.c
$ git log -- -- unresolve.c
$ git whatchanged -- unresolve.c
both give no output.
I checked the argument parsing stage and everything seemed sane (the
second double-dash was not necessary anymore)
However, the following works as expected:
$ git log -- git-log.sh
It seems that the problem shows only if there was no commit
modifying the asked-for file. unresolve.c is introduced in commit
ec167793d84ba7b765e1eb71b0257ce7baca2d26 and removed in the
subsequent commit 2bd452d3b9f62ecc3406307cd6a5553856d21ff2 and is
never modified.
/Matthias
--
:wq
^ permalink raw reply
* cg-mkpatch use case
From: Belmar-Letelier @ 2006-05-02 7:47 UTC (permalink / raw)
To: git
Hello,
I have 3 questions about cg-mkpatch
1. I've receive a file "xxx.patch", this content came from
cg-mkpatch, but I can't apply it.
For example if I try git-am I get::
$ git-am --signoff xxx.patch
Patch does not have a valid e-mail address.
What is the Cogito way to apply the result of "cg-mkpatch"
2. What are the difference between usecases with "cg-mkpatch"
and "git-format-patch" ?
3. It seem that if a commit as a binary file they are no way to manage
it by email patches. Any plan about this in Cogito ?
--
Luis
^ permalink raw reply
* [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-02 7:38 UTC (permalink / raw)
To: git
In-Reply-To: <20060501225335.GI20847@admingilde.org>
When adding an alternate object store then add entries from its
info/alternates files, too.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
sha1_file.c | 166 +++++++++++++++++++++++++++++++++--------------------------
1 files changed, 94 insertions(+), 72 deletions(-)
6ef777610f4e314fd93ecf672b9898fb95a7d5af
diff --git a/sha1_file.c b/sha1_file.c
index f2d33af..fb5778c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -216,6 +216,8 @@ char *sha1_pack_index_name(const unsigne
struct alternate_object_database *alt_odb_list;
static struct alternate_object_database **alt_odb_tail;
+static void read_info_alternates(const char * alternates);
+
/*
* Prepare alternate object database registry.
*
@@ -231,13 +233,78 @@ static struct alternate_object_database
* SHA1, an extra slash for the first level indirection, and the
* terminating NUL.
*/
+static int link_alt_odb_entry(const char * entry, int len, const char * relative_base)
+{
+ struct stat st;
+ const char *objdir = get_object_directory();
+ struct alternate_object_database *ent;
+ struct alternate_object_database *alt;
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = len;
+ int entlen = pfxlen + 43;
+ int base_len = -1;
+
+ if (*entry != '/' && relative_base) {
+ /* Relative alt-odb */
+ if (base_len < 0)
+ base_len = strlen(relative_base) + 1;
+ entlen += base_len;
+ pfxlen += base_len;
+ }
+ ent = xmalloc(sizeof(*ent) + entlen);
+
+ if (*entry != '/' && relative_base) {
+ memcpy(ent->base, relative_base, base_len - 1);
+ ent->base[base_len - 1] = '/';
+ memcpy(ent->base + base_len, entry, len);
+ }
+ else
+ memcpy(ent->base, entry, pfxlen);
+
+ ent->name = ent->base + pfxlen + 1;
+ ent->base[pfxlen + 3] = '/';
+ ent->base[pfxlen] = ent->base[entlen-1] = 0;
+
+ /* Detect cases where alternate disappeared */
+ if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
+ error("object directory %s does not exist; "
+ "check .git/objects/info/alternates.",
+ ent->base);
+ free(ent);
+ return -1;
+ }
+
+ /* Prevent the common mistake of listing the same
+ * thing twice, or object directory itself.
+ */
+ for (alt = alt_odb_list; alt; alt = alt->next) {
+ if (!memcmp(ent->base, alt->base, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+ }
+ if (!memcmp(ent->base, objdir, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+
+ /* add the alternate entry */
+ *alt_odb_tail = ent;
+ alt_odb_tail = &(ent->next);
+ ent->next = NULL;
+
+ /* recursively add alternates */
+ read_info_alternates(ent->base);
+
+ ent->base[pfxlen] = '/';
+
+ return 0;
+}
+
static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
const char *relative_base)
{
const char *cp, *last;
- struct alternate_object_database *ent;
- const char *objdir = get_object_directory();
- int base_len = -1;
last = alt;
while (last < ep) {
@@ -248,61 +315,10 @@ static void link_alt_odb_entries(const c
last = cp + 1;
continue;
}
- for ( ; cp < ep && *cp != sep; cp++)
- ;
+ while (cp < ep && *cp != sep)
+ cp++;
if (last != cp) {
- struct stat st;
- struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = cp - last;
- int entlen = pfxlen + 43;
-
- if (*last != '/' && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
- }
- ent = xmalloc(sizeof(*ent) + entlen);
-
- if (*last != '/' && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len,
- last, cp - last);
- }
- else
- memcpy(ent->base, last, pfxlen);
-
- ent->name = ent->base + pfxlen + 1;
- ent->base[pfxlen + 3] = '/';
- ent->base[pfxlen] = ent->base[entlen-1] = 0;
-
- /* Detect cases where alternate disappeared */
- if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
- error("object directory %s does not exist; "
- "check .git/objects/info/alternates.",
- ent->base);
- goto bad;
- }
- ent->base[pfxlen] = '/';
-
- /* Prevent the common mistake of listing the same
- * thing twice, or object directory itself.
- */
- for (alt = alt_odb_list; alt; alt = alt->next)
- if (!memcmp(ent->base, alt->base, pfxlen))
- goto bad;
- if (!memcmp(ent->base, objdir, pfxlen)) {
- bad:
- free(ent);
- }
- else {
- *alt_odb_tail = ent;
- alt_odb_tail = &(ent->next);
- ent->next = NULL;
- }
+ link_alt_odb_entry(last, cp - last, relative_base);
}
while (cp < ep && *cp == sep)
cp++;
@@ -310,23 +326,14 @@ static void link_alt_odb_entries(const c
}
}
-void prepare_alt_odb(void)
+static void read_info_alternates(const char * relative_base)
{
- char path[PATH_MAX];
char *map;
- int fd;
struct stat st;
- char *alt;
-
- alt = getenv(ALTERNATE_DB_ENVIRONMENT);
- if (!alt) alt = "";
-
- if (alt_odb_tail)
- return;
- alt_odb_tail = &alt_odb_list;
- link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+ char path[PATH_MAX];
+ int fd;
- sprintf(path, "%s/info/alternates", get_object_directory());
+ sprintf(path, "%s/info/alternates", relative_base);
fd = open(path, O_RDONLY);
if (fd < 0)
return;
@@ -339,11 +346,26 @@ void prepare_alt_odb(void)
if (map == MAP_FAILED)
return;
- link_alt_odb_entries(map, map + st.st_size, '\n',
- get_object_directory());
+ link_alt_odb_entries(map, map + st.st_size, '\n', relative_base);
+
munmap(map, st.st_size);
}
+void prepare_alt_odb(void)
+{
+ char *alt;
+
+ alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+ if (!alt) alt = "";
+
+ if (alt_odb_tail)
+ return;
+ alt_odb_tail = &alt_odb_list;
+ link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+
+ read_info_alternates(get_object_directory());
+}
+
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
{
char *name = sha1_file_name(sha1);
--
1.3.1.g6ef7
--
Martin Waitz
^ permalink raw reply related
* Re: git-bisect broken in 1.2.4
From: Olaf Hering @ 2006-05-02 7:33 UTC (permalink / raw)
To: Junio C Hamano, pasky; +Cc: git, Uwe Zeisberger
In-Reply-To: <7vpsiwopkv.fsf@assigned-by-dhcp.cox.net>
On Tue, May 02, Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > Olaf Hering wrote:
> >> Did SuSE just pick up a bad version of git, 1.2.4?
> >> git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
> >> contain the commit id anymore, but 'ref: refs/heads/bisect'
> >>
> >> CONFIG_LOCALVERSION_AUTO depends on the id.
> > Probably you should update to at least linux-v2.6.15-g117a93d. The
> > script to determine the localversion[1] depends on .git/HEAD being a
> > symlink.
> >
> > Since
> >
> > git-1.1.4-g2fabd21
> >
> > .git/HEAD isn't a symlink any more (per default at least).
>
> Ouch. Although what Uwe says is all correct, we should not say
> "don't try kernel older than 2615-117a". That makes bisect
> rather useless.
>
> > You can rebuild git with USE_SYMLINK_HEAD if you really want the old
> > behaviour.
>
> That probably is a sane thing to do.
Ok, thanks for the patch.
Petr, can you update our git package in time?
^ permalink raw reply
* Re: git-bisect broken in 1.2.4
From: Junio C Hamano @ 2006-05-02 7:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: git, Uwe Zeisberger
In-Reply-To: <20060502070155.GA861@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Olaf Hering wrote:
>> Did SuSE just pick up a bad version of git, 1.2.4?
>> git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
>> contain the commit id anymore, but 'ref: refs/heads/bisect'
>>
>> CONFIG_LOCALVERSION_AUTO depends on the id.
> Probably you should update to at least linux-v2.6.15-g117a93d. The
> script to determine the localversion[1] depends on .git/HEAD being a
> symlink.
>
> Since
>
> git-1.1.4-g2fabd21
>
> .git/HEAD isn't a symlink any more (per default at least).
Ouch. Although what Uwe says is all correct, we should not say
"don't try kernel older than 2615-117a". That makes bisect
rather useless.
> You can rebuild git with USE_SYMLINK_HEAD if you really want the old
> behaviour.
That probably is a sane thing to do.
We should introduce prefer_symlink_refs configuration to work
with projects whose older version of build infrastructure
depends on symlink refs.
The patch is on top of post 1.3.1 git, but .c and .h part should
apply more-or-less cleanly to older code base. You should
be able to say:
[core]
prefersymlinkrefs = true
in .git/config file, maybe do "git checkout -f master" to switch
branch and make .git/HEAD into symlink, and do the bisect again.
Sorry for the screwup.
-- >8 --
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b27b0d5..d1a4bec 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -64,9 +64,11 @@ core.ignoreStat::
slow, such as Microsoft Windows. See gitlink:git-update-index[1].
False by default.
-core.onlyUseSymrefs::
- Always use the "symref" format instead of symbolic links for HEAD
- and other symbolic reference files. True by default.
+core.preferSymlinkRefs::
+ Instead of the default "symref" format for HEAD
+ and other symbolic reference files, use symbolic links.
+ This is sometimes needed to work with old scripts that
+ expect HEAD to be a symbolic link.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/Makefile b/Makefile
index 2374335..ecbdde6 100644
--- a/Makefile
+++ b/Makefile
@@ -28,8 +28,8 @@ # Define NO_STRCASESTR if you don't have
#
# Define NO_SETENV if you don't have setenv in the C library.
#
-# Define USE_SYMLINK_HEAD if you want .git/HEAD to be a symbolic link.
-# Don't enable it on Windows.
+# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
+# Enable it on Windows. By default, symrefs are still used.
#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
@@ -265,6 +265,7 @@ ifeq ($(uname_O),Cygwin)
NO_D_TYPE_IN_DIRENT = YesPlease
NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
+ NO_SYMLINK_HEAD = YesPlease
NEEDS_LIBICONV = YesPlease
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
@@ -388,6 +389,9 @@ endif
ifdef NO_D_INO_IN_DIRENT
ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
+ifdef NO_SYMLINK_HEAD
+ ALL_CFLAGS += -DNO_SYMLINK_HEAD
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/cache.h b/cache.h
index a0cf8ca..d186b44 100644
--- a/cache.h
+++ b/cache.h
@@ -170,7 +170,7 @@ extern void rollback_index_file(struct c
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
extern int assume_unchanged;
-extern int only_use_symrefs;
+extern int prefer_symlink_refs;
extern int warn_ambiguous_refs;
extern int diff_rename_limit_default;
extern int shared_repository;
diff --git a/config.c b/config.c
index 4e1f0c2..6cd31a3 100644
--- a/config.c
+++ b/config.c
@@ -227,8 +227,8 @@ int git_default_config(const char *var,
return 0;
}
- if (!strcmp(var, "core.symrefsonly")) {
- only_use_symrefs = git_config_bool(var, value);
+ if (!strcmp(var, "core.prefersymlinkrefs")) {
+ prefer_symlink_refs = git_config_bool(var, value);
return 0;
}
diff --git a/environment.c b/environment.c
index 6df6478..444c99e 100644
--- a/environment.c
+++ b/environment.c
@@ -13,7 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int assume_unchanged = 0;
-int only_use_symrefs = 0;
+int prefer_symlink_refs = 0;
int warn_ambiguous_refs = 1;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
diff --git a/refs.c b/refs.c
index 03398cc..275b914 100644
--- a/refs.c
+++ b/refs.c
@@ -76,8 +76,8 @@ int create_symref(const char *git_HEAD,
char ref[1000];
int fd, len, written;
-#ifdef USE_SYMLINK_HEAD
- if (!only_use_symrefs) {
+#ifndef NO_SYMLINK_HEAD
+ if (prefer_symlink_refs) {
unlink(git_HEAD);
if (!symlink(refs_heads_master, git_HEAD))
return 0;
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Martin Langhoff @ 2006-05-02 7:08 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <4456A616.6070402@vilain.net>
On 5/2/06, Sam Vilain <sam@vilain.net> wrote:
> Here I'm a little bit confused still. Surely criss-crossing branches
> already don't converge unless the commits are in the same order.
They do under GIT. No matter how much you criss-cross, every time you
identify a merge base for the next merge, you are identifying the last
commit in common on both branches.
While maybe you didn't have that commit being the tip of a head in
your repo, it _is_ the last common point. If your criss-crossing is
messy and a few commits are out of order or cherry picked, git-merge
has a good chance of spotting it. The whole mechanism tends pulls
quite consistently towards convergence.
If the notes in the commit msg aren't consistent and we lose the
natural tendency towards convergence that's a major drawback. On the
other hand, if two branches have exchanged patches "out of band",
git-merge still gets it right most of the time, so perhaps slightly
different headers in the commit messages are tolerable?
Junio had written:
> >On the other hand, a "note" field that records on which branch
> >of which repository each commit was made (you need to give each
> >repository-branch an UUID) when you do create a new commit would
> >be a sensible thing to have if somebody cares deeply enough.
I really don't like that -- goes against the grain of really simple,
portable repos. I cp -pr repo{,_tmp} all the time to do risky merges
or save a heavy download from a remote server. Let me run away from
this idea... quick before Linus kills us all ;-)
I did feel a couple of times the need of remembering where I had
checked this in -- but it went away quite quickly, must have been a
leftover of my Arch days ;-). And it actually got solved by agreeing
within my team to a commit message format pretty much like what's used
in the kernel. Because the truth is that most of my heads and branches
have very "local" names.
cheers,
martin
^ permalink raw reply
* Re: [RFC] Terms to add to glossary
From: Jakub Narebski @ 2006-05-02 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xpkq5hw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> cherry-picking::
> In SCM jargon, "cherry pick" means to choose a subset of
> changes out of a series of changes (typically commits)
> and record them as a separate series of changes on top
> of different codebase. In GIT, this is performed by
> "git cherry-pick" command to extract the change
> introduced by an existing commit and to record it based
> on the tip of the current branch as a new commit.
That's better.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git-bisect broken in 1.2.4
From: Uwe Zeisberger @ 2006-05-02 7:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060501181020.GA21263@suse.de>
Olaf Hering wrote:
> Did SuSE just pick up a bad version of git, 1.2.4?
> git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
> contain the commit id anymore, but 'ref: refs/heads/bisect'
>
> CONFIG_LOCALVERSION_AUTO depends on the id.
Probably you should update to at least linux-v2.6.15-g117a93d. The
script to determine the localversion[1] depends on .git/HEAD being a
symlink.
Since
git-1.1.4-g2fabd21
.git/HEAD isn't a symlink any more (per default at least).
You can rebuild git with USE_SYMLINK_HEAD if you really want the old
behaviour.
Best regards,
Uwe
[1] scripts/setlocalversion
--
Uwe Zeisberger
http://www.google.com/search?q=gigabyte+in+bit
^ permalink raw reply
* Re: [RFC] Terms to add to glossary
From: Junio C Hamano @ 2006-05-02 6:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e35sin$c1l$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> cherry picking::
> In SCM jargon, cherry picking is used to describe the action of
> selecting which commit should be ported from one branch to another.
> In GIT it means given one existing commit, apply the change
> the patch introduces, and record a new commit that records it.
I am not sure what the focus of the above description is. I
myself got more confused after reading it than before ;-). My
impression was that we have been using the word "cherry-pick" in
pretty standard way, but are you trying to stress that we use
the word in a different sense?
"Action of selecting" is done by the user, perhaps with or
without help from the tool. After deciding which one to "port",
the way to perform the actual "port" would be different from SCM
to SCM, and in GIT it is often done with the "git-cherry-pick"
command. Are you saying the command is misnamed, and we should
call a program that helps the user in "action of selecting"
cherry-pick (actually, I think "git cherry" fits that
description)?
If the focus is not to highlight the distinction but to help the
end user, something like this might be better.
cherry-picking::
In SCM jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits)
and record them as a separate series of changes on top
of different codebase. In GIT, this is performed by
"git cherry-pick" command to extract the change
introduced by an existing commit and to record it based
on the tip of the current branch as a new commit.
^ permalink raw reply
* Re: [RFC] Terms to add to glossary
From: Jakub Narebski @ 2006-05-02 5:48 UTC (permalink / raw)
To: git
In-Reply-To: <e332g6$hpl$1@sea.gmane.org>
pickaxe::
"pickaxe" ("a tool for the software archaeologist") support is
an additional layer to interrogation commands that can be used
to further specify exactly what you're looking for, if you already
know the specific area that changed. It refers to -S option
in git-diff-tree.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] cache-tree: replace a sscanf() by two strtol() calls
From: Johannes Schindelin @ 2006-05-02 1:31 UTC (permalink / raw)
To: git, junkio
On one of my systems, sscanf() first calls strlen() on the buffer. But
this buffer is not terminated by NUL. So git crashed.
strtol() does not share that problem, as it stops reading after the
first non-digit.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Maybe, a better solution would be to store the integers in
binary form. But I am not familiar with that part of git, and
further, it would break setups which already have an index
with cache-tree information.
cache-tree.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
4325bb506d03a0e30a5d4dd197601a53f0375df9
diff --git a/cache-tree.c b/cache-tree.c
index 28b78f8..bd7c1aa 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -439,6 +439,7 @@ void *cache_tree_write(struct cache_tree
static struct cache_tree *read_one(const char **buffer, unsigned long *size_p)
{
const char *buf = *buffer;
+ char *endptr;
unsigned long size = *size_p;
struct cache_tree *it;
int i, subtree_nr;
@@ -453,8 +454,16 @@ static struct cache_tree *read_one(const
goto free_return;
buf++; size--;
it = cache_tree();
- if (sscanf(buf, "%d %d\n", &it->entry_count, &subtree_nr) != 2)
+ it->entry_count = strtol(buf, &endptr, 10);
+ if (buf == endptr)
goto free_return;
+ size -= (endptr - buf);
+ buf = endptr + 1;
+ subtree_nr = strtol(buf, &endptr, 10);
+ if (buf == endptr)
+ goto free_return;
+ size -= (endptr - buf);
+ buf = endptr + 1;
while (size && *buf && *buf != '\n') {
size--;
buf++;
--
1.3.1.g5d53-dirty
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Sam Vilain @ 2006-05-02 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vlktms02x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>Aha, now I see reason in the madness. So, the "prior" head is not stored
>>in the trees, and tracking the progress of actual head transitions is
>>loosely defined / a research topic. But demonstrably derivable. That
>>works for me.
>>
>>
>I do not think there is any madness involved here, but I should
>
>
Sorry, it was a figure of speech. It's more like, what appeared to be
madness no longer looks so.
>point out that the above example happens to work only because
>Linus and David are two different people. If Linus did the
>David's work in a separate repository, or even in the same
>repository but on a separate branch, people following the Linus
>tip might still want to know about the fast-forward, but that is
>something you cannot truly tell by the digging like what I did
>in the previous message.
>
>That is why I earlier said this:
>
> *1* IOW, we _are_ losing some information by not recording the
> fact that fast-forward was done while doing so.
>
> That record should _not_ be in the commit chain. At the
> mechanical level, recording that in the commit chain means two
> criss-crossing branches never converge at the commit chain
> level, which is already bad.
>
>
Here I'm a little bit confused still. Surely criss-crossing branches
already don't converge unless the commits are in the same order.
Oh, I see. Even if they *are* in the same order, the commit IDs would
end up different due to these extra headers.
> At the philosophical level, the
> commit chain is a mesh of many possible "global" histories, and
> the record that somebody (a particular branch in a particular
> repository) was at what point in the mesh at given time does not
> belong there.
>
> But from the repository-owner's point of view, that _might_ be a
> useful information to keep. I am just saying this preemptively
> so that if somebody wants to record it, that should not be
> recorded in the commit object.
>
>
That makes sense.
>On the other hand, a "note" field that records on which branch
>of which repository each commit was made (you need to give each
>repository-branch an UUID) when you do create a new commit would
>be a sensible thing to have if somebody cares deeply enough. It
>is an information that is global in nature, and with that, you
>could do the digging like I did without relying on the committer
>identity, but instead using the branch identity.
>
>
That sounds reasonable. The UUID doesn't need to replicate, either, just
tag the commits that were made against it.
This extra information falls into the informational, "forensic" history
tracing category. ie, we don't know now whether we'll need it, but we'll
store it anyway just to be sure to not make later operations impossible.
I think the large remaining question is around what conventions apply to
the use of the "note" field. We have perhaps the first example of a well
formed piece of "forensic" information that belongs in the commit chain
and could possibly be added by plumbing. I can't think of any more of
those, but the rename/copy tracking case is a bit different. In this
case, it doesn't belong in the plumbing, yet you want a reasonable
convention for storing this information to apply. Also the other cases
outlined in the original post might do well to have a common convention
so that the information is more portable between porcelain.
Sam.
^ permalink raw reply
* [PATCH] builtin-grep: do not use setup_revisions()
From: Junio C Hamano @ 2006-05-01 23:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v64kpsftv.fsf_-_@assigned-by-dhcp.cox.net>
Grep may want to grok multiple revisions, but it does not make
much sense to walk revisions while doing so. This stops calling
the code to parse parameters for the revision walker. The
parameter parsing for the optional "-e" option becomes a lot
simpler with it as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> * Still haven't improved the "-e" issue (and to a lesser extent
> I think requiring -- is not right in this context either),...
So I did this. This removes the ability to say:
git grep master..next -e foobar -- Documentation
but if you want to walk the revision graph, you are interested
in commits that actually changes things to be subject to grep,
not just all commits in the range, so if that is what you are
doing, you are better off using the pickaxe.
builtin-grep.c | 255 +++++++++++++++++++++++++++++---------------------------
1 files changed, 134 insertions(+), 121 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index c3e6701..4be1514 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -8,8 +8,7 @@ #include "blob.h"
#include "tree.h"
#include "commit.h"
#include "tag.h"
-#include "diff.h"
-#include "revision.h"
+#include "tree-walk.h"
#include "builtin.h"
#include <regex.h>
#include <fnmatch.h>
@@ -18,15 +17,15 @@ #include <fnmatch.h>
* git grep pathspecs are somewhat different from diff-tree pathspecs;
* pathname wildcards are allowed.
*/
-static int pathspec_matches(struct diff_options *opt, const char *name)
+static int pathspec_matches(const char **paths, const char *name)
{
int namelen, i;
- if (!opt->nr_paths)
+ if (!paths || !*paths)
return 1;
namelen = strlen(name);
- for (i = 0; i < opt->nr_paths; i++) {
- const char *match = opt->paths[i];
- int matchlen = opt->pathlens[i];
+ for (i = 0; paths[i]; i++) {
+ const char *match = paths[i];
+ int matchlen = strlen(match);
const char *slash, *cp;
if ((matchlen <= namelen) &&
@@ -241,7 +240,7 @@ static int grep_file(struct grep_opt *op
return i;
}
-static int grep_cache(struct grep_opt *opt, struct rev_info *revs, int cached)
+static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
{
int hit = 0;
int nr;
@@ -251,7 +250,7 @@ static int grep_cache(struct grep_opt *o
struct cache_entry *ce = active_cache[nr];
if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
continue;
- if (!pathspec_matches(&revs->diffopt, ce->name))
+ if (!pathspec_matches(paths, ce->name))
continue;
if (cached)
hit |= grep_sha1(opt, ce->sha1, ce->name);
@@ -261,7 +260,7 @@ static int grep_cache(struct grep_opt *o
return hit;
}
-static int grep_tree(struct grep_opt *opt, struct rev_info *revs,
+static int grep_tree(struct grep_opt *opt, const char **paths,
struct tree_desc *tree,
const char *tree_name, const char *base)
{
@@ -297,7 +296,7 @@ static int grep_tree(struct grep_opt *op
*/
strcpy(path_buf + len + pathlen, "/");
- if (!pathspec_matches(&revs->diffopt, down))
+ if (!pathspec_matches(paths, down))
;
else if (S_ISREG(mode))
hit |= grep_sha1(opt, sha1, path_buf);
@@ -310,7 +309,7 @@ static int grep_tree(struct grep_opt *op
die("unable to read tree (%s)",
sha1_to_hex(sha1));
sub.buf = data;
- hit |= grep_tree(opt, revs, &sub, tree_name, down);
+ hit |= grep_tree(opt, paths, &sub, tree_name, down);
free(data);
}
update_tree_entry(tree);
@@ -318,7 +317,7 @@ static int grep_tree(struct grep_opt *op
return hit;
}
-static int grep_object(struct grep_opt *opt, struct rev_info *revs,
+static int grep_object(struct grep_opt *opt, const char **paths,
struct object *obj, const char *name)
{
if (!strcmp(obj->type, blob_type))
@@ -333,7 +332,7 @@ static int grep_object(struct grep_opt *
if (!data)
die("unable to read tree (%s)", sha1_to_hex(obj->sha1));
tree.buf = data;
- hit = grep_tree(opt, revs, &tree, name, "");
+ hit = grep_tree(opt, paths, &tree, name, "");
free(data);
return hit;
}
@@ -345,102 +344,119 @@ static const char builtin_grep_usage[] =
int cmd_grep(int argc, const char **argv, char **envp)
{
- struct rev_info rev;
- const char **dst, **src;
int err;
int hit = 0;
- int no_more_arg = 0;
- int seen_range = 0;
+ int no_more_flags = 0;
int seen_noncommit = 0;
int cached = 0;
struct grep_opt opt;
- struct object_list *list;
+ struct object_list *list, **tail, *object_list = NULL;
+ const char *prefix = setup_git_directory();
+ const char **paths = NULL;
memset(&opt, 0, sizeof(opt));
opt.regflags = REG_NEWLINE;
/*
- * Interpret and remove the grep options upfront. Sigh...
+ * No point using rev_info, really.
*/
- for (dst = src = &argv[1]; src < argc + argv; ) {
- const char *arg = *src++;
- if (!no_more_arg) {
- if (!strcmp("--", arg)) {
- no_more_arg = 1;
- *dst++ = arg;
- continue;
- }
- if (!strcmp("--cached", arg)) {
- cached = 1;
- continue;
- }
- if (!strcmp("-i", arg) ||
- !strcmp("--ignore-case", arg)) {
- opt.regflags |= REG_ICASE;
- continue;
- }
- if (!strcmp("-v", arg) ||
- !strcmp("--invert-match", arg)) {
- opt.invert = 1;
- continue;
- }
- if (!strcmp("-E", arg) ||
- !strcmp("--extended-regexp", arg)) {
- opt.regflags |= REG_EXTENDED;
- continue;
- }
- if (!strcmp("-G", arg) ||
- !strcmp("--basic-regexp", arg)) {
- opt.regflags &= ~REG_EXTENDED;
- continue;
- }
- if (!strcmp("-e", arg)) {
- if (src < argc + argv) {
- opt.pattern = *src++;
- continue;
- }
+ while (1 < argc) {
+ const char *arg = argv[1];
+ argc--; argv++;
+ if (!strcmp("--cached", arg)) {
+ cached = 1;
+ continue;
+ }
+ if (!strcmp("-i", arg) ||
+ !strcmp("--ignore-case", arg)) {
+ opt.regflags |= REG_ICASE;
+ continue;
+ }
+ if (!strcmp("-v", arg) ||
+ !strcmp("--invert-match", arg)) {
+ opt.invert = 1;
+ continue;
+ }
+ if (!strcmp("-E", arg) ||
+ !strcmp("--extended-regexp", arg)) {
+ opt.regflags |= REG_EXTENDED;
+ continue;
+ }
+ if (!strcmp("-G", arg) ||
+ !strcmp("--basic-regexp", arg)) {
+ opt.regflags &= ~REG_EXTENDED;
+ continue;
+ }
+ if (!strcmp("-n", arg)) {
+ opt.linenum = 1;
+ continue;
+ }
+ if (!strcmp("-H", arg)) {
+ /* We always show the pathname, so this
+ * is a noop.
+ */
+ continue;
+ }
+ if (!strcmp("-l", arg) ||
+ !strcmp("--files-with-matches", arg)) {
+ opt.name_only = 1;
+ continue;
+ }
+ if (!strcmp("-A", arg) ||
+ !strcmp("-B", arg) ||
+ !strcmp("-C", arg)) {
+ unsigned num;
+ if (argc <= 1 ||
+ sscanf(*++argv, "%u", &num) != 1)
usage(builtin_grep_usage);
+ argc--;
+ switch (arg[1]) {
+ case 'A':
+ opt.post_context = num;
+ break;
+ case 'C':
+ opt.post_context = num;
+ case 'B':
+ opt.pre_context = num;
+ break;
}
- if (!strcmp("-n", arg)) {
- opt.linenum = 1;
- continue;
- }
- if (!strcmp("-H", arg)) {
- /* We always show the pathname, so this
- * is a noop.
+ continue;
+ }
+ if (!strcmp("-e", arg)) {
+ if (1 < argc) {
+ /* We probably would want to do
+ * -e pat1 -e pat2 as well later...
*/
+ if (opt.pattern)
+ die("more than one pattern?");
+ opt.pattern = *++argv;
+ argc--;
continue;
}
- if (!strcmp("-l", arg) ||
- !strcmp("--files-with-matches", arg)) {
- opt.name_only = 1;
- continue;
- }
- if (!strcmp("-A", arg) ||
- !strcmp("-B", arg) ||
- !strcmp("-C", arg)) {
- unsigned num;
- if ((argc + argv <= src) ||
- sscanf(*src++, "%u", &num) != 1)
- usage(builtin_grep_usage);
- switch (arg[1]) {
- case 'A':
- opt.post_context = num;
- break;
- case 'C':
- opt.post_context = num;
- case 'B':
- opt.pre_context = num;
- break;
- }
- continue;
- }
+ usage(builtin_grep_usage);
+ }
+ if (!strcmp("--", arg)) {
+ no_more_flags = 1;
+ continue;
+ }
+ /* Either unrecognized option or a single pattern */
+ if (!no_more_flags && *arg == '-')
+ usage(builtin_grep_usage);
+ if (!opt.pattern) {
+ opt.pattern = arg;
+ break;
+ }
+ else {
+ /* We are looking at the first path or rev;
+ * it is found at argv[0] after leaving the
+ * loop.
+ */
+ argc++; argv--;
+ break;
}
- *dst++ = arg;
}
if (!opt.pattern)
die("no pattern given.");
-
err = regcomp(&opt.regexp, opt.pattern, opt.regflags);
if (err) {
char errbuf[1024];
@@ -448,11 +464,32 @@ int cmd_grep(int argc, const char **argv
regfree(&opt.regexp);
die("'%s': %s", opt.pattern, errbuf);
}
+ tail = &object_list;
+ while (1 < argc) {
+ struct object *object;
+ struct object_list *elem;
+ const char *arg = argv[1];
+ unsigned char sha1[20];
+ if (get_sha1(arg, sha1) < 0)
+ break;
+ object = parse_object(sha1);
+ if (!object)
+ die("bad object %s", arg);
+ elem = object_list_insert(object, tail);
+ elem->name = arg;
+ tail = &elem->next;
+ argc--; argv++;
+ }
+ if (1 < argc)
+ paths = get_pathspec(prefix, argv + 1);
+ else if (prefix) {
+ paths = xcalloc(2, sizeof(const char *));
+ paths[0] = prefix;
+ paths[1] = NULL;
+ }
- init_revisions(&rev);
- *dst = NULL;
- argc = setup_revisions(dst - argv, argv, &rev, NULL);
-
+ if (!object_list)
+ return !grep_cache(&opt, paths, cached);
/*
* Do not walk "grep -e foo master next pu -- Documentation/"
* but do walk "grep -e foo master..next -- Documentation/".
@@ -460,43 +497,19 @@ int cmd_grep(int argc, const char **argv
* "grep -e foo v1.0.0:Documentation/ master..next"
* so detect that and complain.
*/
- for (list = rev.pending_objects; list; list = list->next) {
+ for (list = object_list; list; list = list->next) {
struct object *real_obj;
- if (list->item->flags & UNINTERESTING)
- seen_range = 1;
real_obj = deref_tag(list->item, NULL, 0);
if (strcmp(real_obj->type, commit_type))
seen_noncommit = 1;
}
- if (!rev.pending_objects)
- return !grep_cache(&opt, &rev, cached);
if (cached)
die("both --cached and revisions given.");
- if (seen_range && seen_noncommit)
- die("both A..B and non commit are given.");
- if (seen_range) {
- struct commit *commit;
- prepare_revision_walk(&rev);
- while ((commit = get_revision(&rev)) != NULL) {
- unsigned char *sha1 = commit->object.sha1;
- const char *n = find_unique_abbrev(sha1, rev.abbrev);
- char rev_name[41];
- strcpy(rev_name, n);
- if (grep_object(&opt, &rev, &commit->object, rev_name))
- hit = 1;
- commit->buffer = NULL;
- }
- return !hit;
- }
-
- /* all of them are non-commit; do not walk, and
- * do not lose their names.
- */
- for (list = rev.pending_objects; list; list = list->next) {
+ for (list = object_list; list; list = list->next) {
struct object *real_obj;
real_obj = deref_tag(list->item, NULL, 0);
- if (grep_object(&opt, &rev, real_obj, list->name))
+ if (grep_object(&opt, paths, real_obj, list->name))
hit = 1;
}
return !hit;
--
1.3.1.gd233
^ permalink raw reply related
* Re: git-unpack-objects
From: Junio C Hamano @ 2006-05-01 23:09 UTC (permalink / raw)
To: git
In-Reply-To: <625fc13d0605011552j4189338bx14083657acffc18e@mail.gmail.com>
"Josh Boyer" <jwboyer@gmail.com> writes:
> I was playing around with git repack and decided to "undo" the repack
> I did using git-unpack objects. Below is the output:
>
> [jwboyer@vader linux-2.6]$ git-unpack-objects <
> .git/objects/pack/pack-497d1e639572013de48eeb00cb95738d2ca959e1.pack
> Unpacking 236950 objects
> 100% (236950/236950) done
> [jwboyer@vader linux-2.6]$ ls -l .git/objects/
> total 8
> drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 info
> drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 pack
> [jwboyer@vader linux-2.6]$
>
> As you can see, the objects don't seem to get unpacked back into the
> .git directory. So either I am misunderstanding what that command is
> supposed to do, or it isn't working properly.
>
> Any ideas?
unpack tries to unpack and if it already has the object it
skips.
If you really wanted to do it, here is a way to do so.
mv .git/objets/pack/pack-49*.pack \
.git/objets/pack/pack-49*.idx .
git unpack-objects <pack-49*.pack
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-01 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvdsbuj.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
hoi :)
On Mon, May 01, 2006 at 01:56:36PM -0700, Junio C Hamano wrote:
> If you have a local copy of Linus, Jeff and David trees, you
> could arrange Jeff tree to borrow from Linus and David, and
> David tree to borrow from Linus and Jeff. I wonder what the new
> code does when you add a new repository that borrows from Jeff
> and David. Does it borrow from Linus twice? Four times? Does
> it stop without falling into endless recursion? I did not do
> this myself because I was lazy and did not want to address these
> issues.
I haven't tested these corner cases extensively yet, but from reading
the code it should behave like this:
If you have loops or multiple references to the same repository then
only the first occurance is used. When reading a reference to an alternate
object store for the second time it is simply ignored.
But of course you should be careful when you set up alternate files.
Having two repositories reference each other and then simultanously
running git-prune in both is obviously not a good idea ;-).
... more testing ...
Well of course practice and reality always differ... I'll send an
updated patch shortly ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-unpack-objects
From: Josh Boyer @ 2006-05-01 22:52 UTC (permalink / raw)
To: Git Mailing List
I was playing around with git repack and decided to "undo" the repack
I did using git-unpack objects. Below is the output:
[jwboyer@vader linux-2.6]$ git-unpack-objects <
.git/objects/pack/pack-497d1e639572013de48eeb00cb95738d2ca959e1.pack
Unpacking 236950 objects
100% (236950/236950) done
[jwboyer@vader linux-2.6]$ ls -l .git/objects/
total 8
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 info
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 pack
[jwboyer@vader linux-2.6]$
As you can see, the objects don't seem to get unpacked back into the
.git directory. So either I am misunderstanding what that command is
supposed to do, or it isn't working properly.
Any ideas?
thx,
josh
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-01 16:23 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605011338i5498f857lf230d9a965aa759@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3876 bytes --]
OK, I replaced the eclipse file (yoda) with the latest from the head.
Then I changed it in my git project, committed it, and pushed it to the
shared repo. Finally, I did a "compare with latest from head" and it
proceeded to update the file and then said that there were no changes.
Here's the log:
Valid-responses ok error M E Checked-in Valid-requests Template
Set-sticky MT Clear-static-directory Module-expansion
Set-static-directory Clear-sticky New-entry Merged Removed Updated
Remove-entry Update-existing Copy-file Created Notified Mod-time
valid-requests
Valid-requests remove add status Entry watchers ci tag log co Modified
Questionable admin Root history valid-requests Global_option Argumentx
annotate Valid-responses Unchanged Directory rlog Argument
expand-modules diff editors update
ok
Root /tmp/public.git
CMD> cvs -n update -d "/yoda/yoda"
Global_option -n
Argument -d
Directory .
/tmp/public.git/yoda
Entry /yoda/1.9///
Modified yoda
u=rw,g=rw,o=r
48
Argument yoda
Directory .
/tmp/public.git/yoda
update
M C yoda
Update-existing ./
/tmp/public.git/yoda/yoda
/yoda/1.10/+//
u=rw,g=rw,o=rw
95
ok
RESULT> Status OK: org.eclipse.team.cvs.core code=0 ok null
Valid-responses ok error M E Checked-in Valid-requests Template
Set-sticky MT Clear-static-directory Module-expansion
Set-static-directory Clear-sticky New-entry Merged Removed Updated
Remove-entry Update-existing Copy-file Created Notified Mod-time
valid-requests
Valid-requests remove add status Entry watchers ci tag log co Modified
Questionable admin Root history valid-requests Global_option Argumentx
annotate Valid-responses Unchanged Directory rlog Argument
expand-modules diff editors update
ok
Root /tmp/public.git
CMD> cvs status "yoda"
Directory .
/tmp/public.git/yoda
Entry /yoda/0///
Modified yoda
u=rw,g=rw,o=r
0
Argument yoda
Directory .
/tmp/public.git/yoda
status
M ===================================================================
M File: yoda Status: Needs Checkout
M Working revision: 0
M Repository revision: 1.10 /tmp/public.git/yoda/yoda,v
M Sticky Tag: (none)
M Sticky Date: (none)
M Sticky Options: (none)
M
ok
RESULT> Status OK: org.eclipse.team.cvs.core code=0 ok null
Martin Langhoff wrote:
> On 5/1/06, Bill Burdick <bill@mobilereasoning.com> wrote:
>
>> OK, I changed the way I was testing this to match your usage plan and I
>> still got the same results. It works just fine for vanilla CVS; cvs
>> status shows the re revision in the repo and cvs update brings it in.
>
>
> That's a good start!
>
>> Eclipse has the same funky behavior: Compare with latest at the project
>> level shows no differences, but compare with latest on the changed file
>> actually does an update instead of popping up the Eclipse diff viewer.
>
>
> Hmmm. Eclipse does some weird funky sh*t sometimes. Can you ask it to
> get you a log? There's an option in Eclipse CVS control settings that
> will enable logging of cvs commands to the console. Enable it, and
> then start Eclipse from the commandline, piping stderr and stdout to a
> logfile.
>
> There are also some weird differences depending on how you ask for the
> update or diff. I hate doing this but I'll have to ask you to tell me
> exactly how you ask for the diff and for the update.
>
> And the platform you are running Eclipse on.
>
>> By the way, I had trouble at first accessing the repo with SSH because
>> of permissions on the sqlite db. I'm not totally sure about the
>> implications for multiple users, but maybe just using a common group
>> will work fine?
>
>
> Yes, a common group is the thing to do.
>
> $ chgrp gitusers *sqlite
> $ chmod g+w *sqlite
>
>> I'm really happy with git and git-cvsserver! I'm hoping to be able to
>> standardize on it for our Eclipse work. It seems like it should be
>
>
> Great to hear that!
>
> cheers,
>
>
>
> martin
>
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Junio C Hamano @ 2006-05-01 20:56 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060501203631.GH20847@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> When adding an alternate object store then add entries from its
> info/alternates files, too.
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
Happy. Sometimes it pays off to leave things that can be
improved as they are, mention just "we might want to do this
instead", and forget about it myself. Somebody else comes in
and fixes it for me ;-).
If you have a local copy of Linus, Jeff and David trees, you
could arrange Jeff tree to borrow from Linus and David, and
David tree to borrow from Linus and Jeff. I wonder what the new
code does when you add a new repository that borrows from Jeff
and David. Does it borrow from Linus twice? Four times? Does
it stop without falling into endless recursion? I did not do
this myself because I was lazy and did not want to address these
issues.
^ permalink raw reply
* Re: [RFC] Terms to add to glossary
From: Jakub Narebski @ 2006-05-01 20:55 UTC (permalink / raw)
To: git
In-Reply-To: <e332g6$hpl$1@sea.gmane.org>
cherry picking::
In SCM jargon, cherry picking is used to describe the action of
selecting which commit should be ported from one branch to another.
In GIT it means given one existing commit, apply the change
the patch introduces, and record a new commit that records it.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Martin Langhoff @ 2006-05-01 20:38 UTC (permalink / raw)
To: Bill Burdick; +Cc: git
In-Reply-To: <4455B863.8040808@mobilereasoning.com>
On 5/1/06, Bill Burdick <bill@mobilereasoning.com> wrote:
> OK, I changed the way I was testing this to match your usage plan and I
> still got the same results. It works just fine for vanilla CVS; cvs
> status shows the re revision in the repo and cvs update brings it in.
That's a good start!
> Eclipse has the same funky behavior: Compare with latest at the project
> level shows no differences, but compare with latest on the changed file
> actually does an update instead of popping up the Eclipse diff viewer.
Hmmm. Eclipse does some weird funky sh*t sometimes. Can you ask it to
get you a log? There's an option in Eclipse CVS control settings that
will enable logging of cvs commands to the console. Enable it, and
then start Eclipse from the commandline, piping stderr and stdout to a
logfile.
There are also some weird differences depending on how you ask for the
update or diff. I hate doing this but I'll have to ask you to tell me
exactly how you ask for the diff and for the update.
And the platform you are running Eclipse on.
> By the way, I had trouble at first accessing the repo with SSH because
> of permissions on the sqlite db. I'm not totally sure about the
> implications for multiple users, but maybe just using a common group
> will work fine?
Yes, a common group is the thing to do.
$ chgrp gitusers *sqlite
$ chmod g+w *sqlite
> I'm really happy with git and git-cvsserver! I'm hoping to be able to
> standardize on it for our Eclipse work. It seems like it should be
Great to hear that!
cheers,
martin
^ permalink raw reply
* [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-01 20:36 UTC (permalink / raw)
To: git
When adding an alternate object store then add entries from its
info/alternates files, too.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
sha1_file.c | 165 +++++++++++++++++++++++++++++++++--------------------------
1 files changed, 93 insertions(+), 72 deletions(-)
7fabfb214a971b8b45ec36dcf47929f4bf0917eb
diff --git a/sha1_file.c b/sha1_file.c
index f2d33af..ff9c989 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -216,6 +216,8 @@ char *sha1_pack_index_name(const unsigne
struct alternate_object_database *alt_odb_list;
static struct alternate_object_database **alt_odb_tail;
+static void read_info_alternates(const char * alternates);
+
/*
* Prepare alternate object database registry.
*
@@ -231,13 +233,77 @@ static struct alternate_object_database
* SHA1, an extra slash for the first level indirection, and the
* terminating NUL.
*/
+static int link_alt_odb_entry(const char * entry, int len, const char * relative_base)
+{
+ struct stat st;
+ const char *objdir = get_object_directory();
+ struct alternate_object_database *ent;
+ struct alternate_object_database *alt;
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = len;
+ int entlen = pfxlen + 43;
+ int base_len = -1;
+
+ if (*entry != '/' && relative_base) {
+ /* Relative alt-odb */
+ if (base_len < 0)
+ base_len = strlen(relative_base) + 1;
+ entlen += base_len;
+ pfxlen += base_len;
+ }
+ ent = xmalloc(sizeof(*ent) + entlen);
+
+ if (*entry != '/' && relative_base) {
+ memcpy(ent->base, relative_base, base_len - 1);
+ ent->base[base_len - 1] = '/';
+ memcpy(ent->base + base_len, entry, len);
+ }
+ else
+ memcpy(ent->base, entry, pfxlen);
+
+ ent->name = ent->base + pfxlen + 1;
+ ent->base[pfxlen + 3] = '/';
+ ent->base[pfxlen] = ent->base[entlen-1] = 0;
+
+ /* Detect cases where alternate disappeared */
+ if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
+ error("object directory %s does not exist; "
+ "check .git/objects/info/alternates.",
+ ent->base);
+ free(ent);
+ return -1;
+ }
+
+ /* Prevent the common mistake of listing the same
+ * thing twice, or object directory itself.
+ */
+ for (alt = alt_odb_list; alt; alt = alt->next)
+ if (!memcmp(ent->base, alt->base, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+ if (!memcmp(ent->base, objdir, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+
+ /* recursively add alternates */
+ read_info_alternates(ent->base);
+
+ ent->base[pfxlen] = '/';
+
+ /* add the alternate entry */
+ *alt_odb_tail = ent;
+ alt_odb_tail = &(ent->next);
+ ent->next = NULL;
+
+ return 0;
+}
+
static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
const char *relative_base)
{
const char *cp, *last;
- struct alternate_object_database *ent;
- const char *objdir = get_object_directory();
- int base_len = -1;
last = alt;
while (last < ep) {
@@ -248,61 +314,10 @@ static void link_alt_odb_entries(const c
last = cp + 1;
continue;
}
- for ( ; cp < ep && *cp != sep; cp++)
- ;
+ while (cp < ep && *cp != sep)
+ cp++;
if (last != cp) {
- struct stat st;
- struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = cp - last;
- int entlen = pfxlen + 43;
-
- if (*last != '/' && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
- }
- ent = xmalloc(sizeof(*ent) + entlen);
-
- if (*last != '/' && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len,
- last, cp - last);
- }
- else
- memcpy(ent->base, last, pfxlen);
-
- ent->name = ent->base + pfxlen + 1;
- ent->base[pfxlen + 3] = '/';
- ent->base[pfxlen] = ent->base[entlen-1] = 0;
-
- /* Detect cases where alternate disappeared */
- if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
- error("object directory %s does not exist; "
- "check .git/objects/info/alternates.",
- ent->base);
- goto bad;
- }
- ent->base[pfxlen] = '/';
-
- /* Prevent the common mistake of listing the same
- * thing twice, or object directory itself.
- */
- for (alt = alt_odb_list; alt; alt = alt->next)
- if (!memcmp(ent->base, alt->base, pfxlen))
- goto bad;
- if (!memcmp(ent->base, objdir, pfxlen)) {
- bad:
- free(ent);
- }
- else {
- *alt_odb_tail = ent;
- alt_odb_tail = &(ent->next);
- ent->next = NULL;
- }
+ link_alt_odb_entry(last, cp - last, relative_base);
}
while (cp < ep && *cp == sep)
cp++;
@@ -310,23 +325,14 @@ static void link_alt_odb_entries(const c
}
}
-void prepare_alt_odb(void)
+static void read_info_alternates(const char * relative_base)
{
- char path[PATH_MAX];
char *map;
- int fd;
struct stat st;
- char *alt;
-
- alt = getenv(ALTERNATE_DB_ENVIRONMENT);
- if (!alt) alt = "";
-
- if (alt_odb_tail)
- return;
- alt_odb_tail = &alt_odb_list;
- link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+ char path[PATH_MAX];
+ int fd;
- sprintf(path, "%s/info/alternates", get_object_directory());
+ sprintf(path, "%s/info/alternates", relative_base);
fd = open(path, O_RDONLY);
if (fd < 0)
return;
@@ -339,11 +345,26 @@ void prepare_alt_odb(void)
if (map == MAP_FAILED)
return;
- link_alt_odb_entries(map, map + st.st_size, '\n',
- get_object_directory());
+ link_alt_odb_entries(map, map + st.st_size, '\n', relative_base);
+
munmap(map, st.st_size);
}
+void prepare_alt_odb(void)
+{
+ char *alt;
+
+ alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+ if (!alt) alt = "";
+
+ if (alt_odb_tail)
+ return;
+ alt_odb_tail = &alt_odb_list;
+ link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+
+ read_info_alternates(get_object_directory());
+}
+
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
{
char *name = sha1_file_name(sha1);
--
1.3.1.gc585-dirty
--
Martin Waitz
^ permalink raw reply related
* [PATCH] builtin-grep: wildcard pathspec fixes
From: Junio C Hamano @ 2006-05-01 19:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605010842130.21189@g5.osdl.org>
This tweaks the pathspec wildcard used in builtin-grep to match
that of ls-files. With this:
git grep -e DEBUG -- '*/Kconfig*'
would work like the shell script version, and you could even do:
git grep -e DEBUG --cached -- '*/Kconfig*' ;# from index
git grep -e DEBUG v2.6.12 -- '*/Kconfig*' ;# from rev
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Still haven't improved the "-e" issue (and to a lesser extent
I think requiring -- is not right in this context either), but
builtin-grep.c | 85 +++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 62 insertions(+), 23 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 36150bf..653b65e 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -12,33 +12,66 @@ #include "diff.h"
#include "revision.h"
#include "builtin.h"
#include <regex.h>
+#include <fnmatch.h>
+/*
+ * git grep pathspecs are somewhat different from diff-tree pathspecs;
+ * pathname wildcards are allowed.
+ */
static int pathspec_matches(struct diff_options *opt, const char *name)
{
- int i, j;
- int namelen;
+ int namelen, i;
if (!opt->nr_paths)
return 1;
namelen = strlen(name);
for (i = 0; i < opt->nr_paths; i++) {
const char *match = opt->paths[i];
int matchlen = opt->pathlens[i];
- if (matchlen <= namelen) {
- if (!strncmp(name, match, matchlen))
- return 1;
+ const char *slash, *cp;
+
+ if ((matchlen <= namelen) &&
+ !strncmp(name, match, matchlen) &&
+ (match[matchlen-1] == '/' ||
+ name[matchlen] == '\0' || name[matchlen] == '/'))
+ return 1;
+ if (!fnmatch(match, name, 0))
+ return 1;
+ if (name[namelen-1] != '/')
continue;
- }
- /* If name is "Documentation" and pathspec is
- * "Documentation/", they should match. Maybe
- * we would want to strip it in get_pathspec()???
+
+ /* We are being asked if the name directory is worth
+ * descending into.
+ *
+ * Find the longest leading directory name that does
+ * not have metacharacter in the pathspec; the name
+ * we are looking at must overlap with that directory.
*/
- if (strncmp(name, match, namelen))
- continue;
- for (j = namelen; j < matchlen; j++)
- if (match[j] != '/')
+ for (cp = match, slash = NULL; cp - match < matchlen; cp++) {
+ char ch = *cp;
+ if (ch == '/')
+ slash = cp;
+ if (ch == '*' || ch == '[')
break;
- if (matchlen <= j)
- return 1;
+ }
+ if (!slash)
+ slash = match; /* toplevel */
+ else
+ slash++;
+ if (namelen <= slash - match) {
+ /* Looking at "Documentation/" and
+ * the pattern says "Documentation/howto/", or
+ * "Documentation/diff*.txt".
+ */
+ if (!memcmp(match, name, namelen))
+ return 1;
+ }
+ else {
+ /* Looking at "Documentation/howto/" and
+ * the pattern says "Documentation/h*".
+ */
+ if (!memcmp(match, name, slash - match))
+ return 1;
+ }
}
return 0;
}
@@ -232,17 +265,17 @@ static int grep_tree(struct grep_opt *op
int hit = 0;
const char *path;
const unsigned char *sha1;
- char *down_base;
+ char *down;
char *path_buf = xmalloc(PATH_MAX + strlen(tree_name) + 100);
if (tree_name[0]) {
int offset = sprintf(path_buf, "%s:", tree_name);
- down_base = path_buf + offset;
- strcat(down_base, base);
+ down = path_buf + offset;
+ strcat(down, base);
}
else {
- down_base = path_buf;
- strcpy(down_base, base);
+ down = path_buf;
+ strcpy(down, base);
}
len = strlen(path_buf);
@@ -252,7 +285,14 @@ static int grep_tree(struct grep_opt *op
pathlen = strlen(path);
strcpy(path_buf + len, path);
- if (!pathspec_matches(&revs->diffopt, down_base))
+ if (S_ISDIR(mode))
+ /* Match "abc/" against pathspec to
+ * decide if we want to descend into "abc"
+ * directory.
+ */
+ strcpy(path_buf + len + pathlen, "/");
+
+ if (!pathspec_matches(&revs->diffopt, down))
;
else if (S_ISREG(mode))
hit |= grep_sha1(opt, sha1, path_buf);
@@ -264,9 +304,8 @@ static int grep_tree(struct grep_opt *op
if (!data)
die("unable to read tree (%s)",
sha1_to_hex(sha1));
- strcpy(path_buf + len + pathlen, "/");
sub.buf = data;
- hit = grep_tree(opt, revs, &sub, tree_name, down_base);
+ hit |= grep_tree(opt, revs, &sub, tree_name, down);
free(data);
}
update_tree_entry(tree);
--
1.3.1.gd233
^ permalink raw reply related
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