* Re: History messup
From: Petr Baudis @ 2005-05-11 20:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, tglx, git, Linus Torvalds
In-Reply-To: <1115665598.12012.422.camel@baythorne.infradead.org>
Dear diary, on Mon, May 09, 2005 at 09:06:38PM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-05-09 at 12:01 -0700, H. Peter Anvin wrote:
> > Seems like a UUID or a SHA-1 identifier would be better.
> >
> > However, one can definitely argue that even the meaning of "a
> > repository" isn't well-defined in the context of git.
>
> Of course it isn't. But neither is the meaning "a committer" or
> "an author" or even "a date".
>
> Including some kind of repo-specific identifier with each commit would
> help us to make sense of the history, just as those other fields do.
FWIW, I recently added .git/branch-name to Cogito, since I needed some
identifier through which to differentiate between the branches
(repositories - it's all blurred in Cogito view) when sending commits
to CIA.
It is strictly per-branch (never to be shared by multiple repositories),
optional, informative and more of a temporary solution for now I had to
cook together in a minute.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-11 21:09 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205051114087d283279@mail.gmail.com>
On 5/12/05, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 11 May 2005, Jon Seymour wrote:
>
> > The repository API would contain functionality equivalent to cat-file,
> > ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of
> > the transport code - things that don't involve use of the index.
> >
> > The workspace API would contain read-tree, write-tree, commit-tree,
> > etc - things that do involve use of the the index.
>
> Unfortunately for this idea, you can't actually check files into or out of
> the repository using the git tools without the index (in memory at least,
> if not on disk). This is a bit like having a libc with all the system
> calls except read and write. Sure, there are a number of programs that
> would be fine that way, but it makes the API unintuitive, and most serious
> programs need the extension anyway.
>
Daniel,
Checking in/checking out is definitely a workspace API function that
involves an index (almost certainly) an on-disk index, but reading and
writing from and to the repository is purely a repository API
function.
There is no reason why the workspace API can't make use of
"lower-level" functions in the repository API. I guess I would argue
that the repository API really shouldn't need much, if any knowledge,
of the workspace API.
The repository API knows about the on-disk structure of repository
objects - it knows how to write writing compressed, SHA1 signed
objects, it also knows how to pack and unpack the various object types
from their on-disk representation into structures manipulated by the
workspace API.
On the otherhand the workspace API knows about managing index
(workspace) state. It knows how to determine whether the
pre-conditions for a commit have been reached. It knows how to read
the workspace structures and coordinate read and writes from and to
the repository.
I really don't think this makes the API unintuitive, but then I don't
really understand why you think this is the case.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com
^ permalink raw reply
* Re: [PATCH Cogito] match pathnames in exclude handling
From: H. Peter Anvin @ 2005-05-11 21:30 UTC (permalink / raw)
To: Matthias Urlichs
Cc: David Mansfield, Jan-Benedict Glaw, Junio C Hamano, Brian Gerst,
git
In-Reply-To: <20050511052546.GC11192@kiste.smurf.noris.de>
Matthias Urlichs wrote:
>
> I already did, last week. (I do need to cleanup my changes...)
>
> The idea is that "foo" matches anywhere, "foo/bar" the exact pathname.
> As a special case, "./foo" matches in the root directory only.
>
> NB: "*" can cross subdirectory paths, so "*/foo/bar" does match
> "a/b/c/foo/bar".
>
How does that mean foo*.c would match foo/bar/quux.c? That's probably a
bad thing.
I do like the (sadly, rarely used) convention that ** matches / whereas
* doesn't.
-hpa
^ permalink raw reply
* Re: [RFC] Embedding asciidoc manpages in the cg scripts
From: Petr Baudis @ 2005-05-11 21:32 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20050511014445.GA14377@diku.dk>
Dear diary, on Wed, May 11, 2005 at 03:44:45AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Index: cg-add
> ===================================================================
> --- 1cfa9d5a4f751f8ddd8b9a40758b8d6d0141264e/cg-add (mode:100755)
> +++ uncommitted/cg-add (mode:100755)
> @@ -1,14 +1,36 @@
> #!/usr/bin/env bash
> #
> -# Add new file to a GIT repository.
> -# Copyright (c) Petr Baudis, 2005
> +# CG-ADD(1)
> +# =========
This is really awful - it carries no interesting information whatsoever
since that is pretty obvious from the fact that it is in file called
cg-add.
> #
> +# NAME
> +# ----
> +# cg-add - add files to a GIT repository
Half of this is useless, too.
I think you should just keep the first paragraph of the files as it is
now. Don't touch it, just parse it.
> +#
> +# SYNOPSIS
> +# --------
No need for this heading either.
> +USAGE="cg-add FILE..."
> +#
> +# DESCRIPTION
> +# -----------
> # Takes a list of file names at the command line, and schedules them
> # for addition to the GIT repository at the next commit.
> +#
> +# The command will fail if one of the given files does not exist.
> +#
> +# cg-add is part of Cogito, an SCM-like toolkit for managing GIT trees.
Useless.
> +#
> +# OPTIONS
> +# -------
> +# No options.
The rest of DESCRIPTION and OPTIONS looks fine.
I'd just expect you to be much less intrusive in the in-file comments
and do more work when processing the stuff. I'm commenting on how it
looks inside of the sources - do whatever is necessary when processing
it to generate a proper-looking manpage from it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-11 21:37 UTC (permalink / raw)
To: Morten Welinder; +Cc: Petr Baudis, git, Linus Torvalds
In-Reply-To: <118833cc050511113122e2d17d@mail.gmail.com>
>>>>> "MW" == Morten Welinder <mwelinder@gmail.com> writes:
MW> Here's the symlink version. Note, that git does not complain but
MW> simply creates (or
MW> overwrites) the wrong file.
MW> Morten
Here is a proposed fix.
------------
Commit 685c391c9a755936175193f8b58973b74eaef930
Author Junio C Hamano <junkio@cox.net>, Wed May 11 14:36:05 2005 -0700
Committer Junio C Hamano <junkio@cox.net>, Wed May 11 14:36:05 2005 -0700
Fix checkout-cache when existing work tree interferes with the checkout.
The checkout-cache command gets confused when checking out a
file in a subdirectory and the work tree has a symlink to the
subdirectory. Also it fails to check things out when there is a
non-directory in the work tree when cache expects a directory
there, and vice versa. This patch fixes the first problem by
making sure all the leading paths in the file being checked out
are indeed directories, and also fixes directory vs
non-directory conflicts when '-f' is specified by removing the
offending paths.
I've added test subdirectory and two tests to check the above
problems are fixed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -32,6 +32,8 @@
* of "-a" causing problems (not possible in the above example,
* but get used to it in scripting!).
*/
+#include <sys/types.h>
+#include <dirent.h>
#include "cache.h"
static int force = 0, quiet = 0, not_new = 0;
@@ -46,22 +48,67 @@ static void create_directories(const cha
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
- mkdir(buf, 0755);
+ if (mkdir(buf, 0755)) {
+ if (errno == EEXIST) {
+ struct stat st;
+ if (!lstat(buf, &st) && S_ISDIR(st.st_mode))
+ continue; /* ok */
+ if (force && !unlink(buf) && !mkdir(buf, 0755))
+ continue;
+ }
+ die("cannot create directory at %s", buf);
+ }
}
free(buf);
}
+static void remove_subtree(const char *path)
+{
+ DIR *dir = opendir(path);
+ struct dirent *de;
+ char pathbuf[PATH_MAX];
+ char *name;
+
+ if (!dir)
+ die("cannot opendir %s", path);
+ strcpy(pathbuf, path);
+ name = pathbuf + strlen(path);
+ *name++ = '/';
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st;
+ if ((de->d_name[0] == '.') &&
+ ((de->d_name[1] == 0) ||
+ ((de->d_name[1] == '.') && de->d_name[2] == 0)))
+ continue;
+ strcpy(name, de->d_name);
+ if (lstat(pathbuf, &st))
+ die("cannot lstat %s", pathbuf);
+ if (S_ISDIR(st.st_mode))
+ remove_subtree(pathbuf);
+ else if (unlink(pathbuf))
+ die("cannot unlink %s", pathbuf);
+ }
+ closedir(dir);
+ if (rmdir(path))
+ die("cannot rmdir %s", path);
+}
+
static int create_file(const char *path, unsigned int mode)
{
int fd;
mode = (mode & 0100) ? 0777 : 0666;
+ create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
if (fd < 0) {
- if (errno == ENOENT) {
+ if ((errno == ENOENT) || (errno == ENOTDIR && force)) {
create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
}
+ else if (errno == EISDIR && force) {
+ remove_subtree(path);
+ fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
+ }
}
return fd;
}
Created: t/t0000.sh (mode:100755)
--- /dev/null
+++ b/t/t0000.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+case "${verbose+set}" in
+set) say= ;;
+*) say=: ;;
+esac
+
+export LANG C
+unset AUTHOR_DATE
+unset AUTHOR_EMAIL
+unset AUTHOR_NAME
+unset COMMIT_AUTHOR_EMAIL
+unset COMMIT_AUTHOR_NAME
+unset GIT_ALTERNATE_OBJECT_DIRECTORIES
+unset GIT_AUTHOR_DATE
+unset GIT_AUTHOR_EMAIL
+unset GIT_AUTHOR_NAME
+unset GIT_COMMITTER_EMAIL
+unset GIT_COMMITTER_NAME
+unset GIT_DIFF_OPTS
+unset GIT_DIR
+unset GIT_EXTERNAL_DIFF
+unset GIT_INDEX_FILE
+unset GIT_OBJECT_DIRECTORY
+unset SHA1_FILE_DIRECTORIES
+unset SHA1_FILE_DIRECTORY
+
+# Test the binaries we have just built.
+PATH=$(pwd)/..:$PATH
+
+# Test repository
+test=test-repo
+rm -fr "$test"
+mkdir "$test"
+cd "$test"
Created: t/t1000-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1000-checkout-cache.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+date >path0
+mkdir path1
+date >path1/file1
+git-update-cache --add path0 path1/file1
+$say git-ls-files --stage
+
+rm -fr path0 path1
+mkdir path0
+date >path0/file0
+date >path1
+$say git-ls-files --stage
+$say find path*
+
+echo >&2 "* checkout-cache sans -f"
+git-checkout-cache -a
+case "$?" in
+0) echo >&2 "*** bug: should not have succeeded." ;;
+*) echo >&2 "*** ok: failed as expected." ;;
+esac
+$say find path*
+
+echo >&2 "* checkout-cache with -f"
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+$say find path*
+if test -f path0 && test -d path1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: checkout failed."
+ exit 1
+fi
Created: t/t1001-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1001-checkout-cache.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+
+show_files() {
+ find path? -ls |
+ sed -e 's/^[0-9]* * [0-9]* * \([-bcdl]\)[^ ]* *[0-9]* *[^ ]* *[^ ]* *[0-9]* [A-Z][a-z][a-z] [0-9][0-9] [^ ]* /fs: \1 /'
+ git-ls-files --stage |
+ sed -e 's/^\([0-9]*\) [0-9a-f]* [0-3] /ca: \1 /'
+ git-ls-tree -r "$1" |
+ sed -e 's/^\([0-9]*\) [^ ]* [0-9a-f]* /tr: \1 /'
+}
+
+mkdir path0
+date >path0/file0
+git-update-cache --add path0/file0
+echo >&2 "* initial state: one file under one directory"
+tree1=$(git-write-tree)
+$say show_files $tree1
+
+mkdir path1
+date >path1/file1
+git-update-cache --add path1/file1
+echo >&2 "* two directories with one file each"
+tree2=$(git-write-tree)
+$say show_files $tree2
+
+rm -fr path1
+git-read-tree -m $tree1
+git-checkout-cache -f -a
+echo >&2 "* go back to initial state"
+$say show_files $tree1
+
+ln -s path0 path1
+git-update-cache --add path1
+echo >&2 "* a symlink where the other side would create a directory."
+tree3=$(git-write-tree)
+$say show_files $tree3
+
+# Morten says "Got that?" here.
+
+git-read-tree $tree2
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+echo >&2 "* read tree2 and checkout"
+$say show_files $tree2
+
+if test ! -h path0 && test -d path0 &&
+ test ! -h path1 && test -d path1 &&
+ test ! -h path0/file0 && test -f path0/file0 &&
+ test ! -h path1/file1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: did not check out correctly."
+ exit 1
+fi
------------------------------------------------
^ permalink raw reply
* [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 21:38 UTC (permalink / raw)
To: git
This is an initial attempt to enable history tracking for multiple
repositories in a consistent state. At the moment this can only be done
by heuristic guessing on the parent dates and the committer names.
This fails for example with Dave Millers net-2.6 and sparc-2.6 trees, as
in both cases the committer name is the same. It fails also completely
in cases where the system clock of the committer is wrong and the merge
is a head forward. The old bk repository contains entries from 1999 and
2027, which will happen also with git over the time.
To identify a repository commit-tree tries to read an environment
variable "GIT_REPOSITORY_ID" and has a fallback to the current working
directory. The environment variable keeps the door open for managed
repository id's, but the current working directory is certainly a quite
helpful information to solve the origin decision for history tracking.
Adding a line after the committer should not break any existing tools
AFAICS.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -110,6 +110,7 @@ int main(int argc, char **argv)
char *gecos, *realgecos, *commitgecos;
char *email, *commitemail, realemail[1000];
char date[20], realdate[20];
+ char *repoid, repoidbuf[MAXPATHLEN];
char *audate;
char comment[1000];
struct passwd *pw;
@@ -154,6 +155,14 @@ int main(int argc, char **argv)
if (audate)
parse_date(audate, date, sizeof(date));
+ repoid = getenv("GIT_REPOSITORY_ID");
+ if (!repoid)
+ repoid = getcwd(repoidbuf, MAXPATHLEN);
+ else {
+ if (strlen(repoid) == 0)
+ die("GIT_REPOSITORY_ID is empty. Fix it !");
+ }
+
remove_special(gecos); remove_special(realgecos); remove_special(commitgecos);
remove_special(email); remove_special(realemail); remove_special(commitemail);
@@ -170,7 +179,8 @@ int main(int argc, char **argv)
/* Person/date information */
add_buffer(&buffer, &size, "author %s <%s> %s\n", gecos, email, date);
- add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", commitgecos, commitemail, realdate);
+ add_buffer(&buffer, &size, "committer %s <%s> %s\n", commitgecos, commitemail, realdate);
+ add_buffer(&buffer, &size, "repoid %s\n\n", repoid);
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Junio C Hamano @ 2005-05-11 21:54 UTC (permalink / raw)
To: tglx, pasky; +Cc: git
In-Reply-To: <1115843429.22180.90.camel@tglx>
>>>>> "TG" == Thomas Gleixner <tglx@linutronix.de> writes:
TG> You moved the stop behind the printf which is inconsistent to the other
TG> stop conditions, but thats a pure cosmetic question as long as it stays
TG> that way for ever.
While I work on the core GIT changes, I often find myself doing
$ jit-log -l --since linus
$ jit-log -l --since git-jc
to see what changes I have in my local work repository, and
seeing the branching point (or origin) at the very end of the
log made me feel assured that I am not losing anything in the
log. But come to think of it, that is really an unnecessary
thing and stopping _before_ the named commit would make more
sense.
Here is a fixed version. I am CC'ing pasky hoping he would pick
it up.
------------
Add --stop-at to git-rev-list command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -32,6 +32,8 @@
* of "-a" causing problems (not possible in the above example,
* but get used to it in scripting!).
*/
+#include <sys/types.h>
+#include <dirent.h>
#include "cache.h"
static int force = 0, quiet = 0, not_new = 0;
@@ -46,22 +48,67 @@ static void create_directories(const cha
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
- mkdir(buf, 0755);
+ if (mkdir(buf, 0755)) {
+ if (errno == EEXIST) {
+ struct stat st;
+ if (!lstat(buf, &st) && S_ISDIR(st.st_mode))
+ continue; /* ok */
+ if (force && !unlink(buf) && !mkdir(buf, 0755))
+ continue;
+ }
+ die("cannot create directory at %s", buf);
+ }
}
free(buf);
}
+static void remove_subtree(const char *path)
+{
+ DIR *dir = opendir(path);
+ struct dirent *de;
+ char pathbuf[PATH_MAX];
+ char *name;
+
+ if (!dir)
+ die("cannot opendir %s", path);
+ strcpy(pathbuf, path);
+ name = pathbuf + strlen(path);
+ *name++ = '/';
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st;
+ if ((de->d_name[0] == '.') &&
+ ((de->d_name[1] == 0) ||
+ ((de->d_name[1] == '.') && de->d_name[2] == 0)))
+ continue;
+ strcpy(name, de->d_name);
+ if (lstat(pathbuf, &st))
+ die("cannot lstat %s", pathbuf);
+ if (S_ISDIR(st.st_mode))
+ remove_subtree(pathbuf);
+ else if (unlink(pathbuf))
+ die("cannot unlink %s", pathbuf);
+ }
+ closedir(dir);
+ if (rmdir(path))
+ die("cannot rmdir %s", path);
+}
+
static int create_file(const char *path, unsigned int mode)
{
int fd;
mode = (mode & 0100) ? 0777 : 0666;
+ create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
if (fd < 0) {
- if (errno == ENOENT) {
+ if ((errno == ENOENT) || (errno == ENOTDIR && force)) {
create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
}
+ else if (errno == EISDIR && force) {
+ remove_subtree(path);
+ fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
+ }
}
return fd;
}
--- a/rev-list.c
+++ b/rev-list.c
@@ -1,12 +1,21 @@
#include "cache.h"
#include "commit.h"
+static const char *rev_list_usage =
+"usage: rev-list [OPTION] commit-id\n"
+" --max-count=nr\n"
+" --max-age=epoch\n"
+" --min-age=epoch\n"
+" --stop-at=commit\n";
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
struct commit_list *list = NULL;
struct commit *commit;
char *commit_arg = NULL;
+ unsigned char stop_at[20];
+ int has_stop_at = 0;
int i;
unsigned long max_age = -1;
unsigned long min_age = -1;
@@ -21,16 +30,17 @@ int main(int argc, char **argv)
max_age = atoi(arg + 10);
} else if (!strncmp(arg, "--min-age=", 10)) {
min_age = atoi(arg + 10);
+ } else if (!strncmp(arg, "--stop-at=", 10)) {
+ if (get_sha1(arg + 10, stop_at))
+ usage(rev_list_usage);
+ has_stop_at = 1;
} else {
commit_arg = arg;
}
}
if (!commit_arg || get_sha1(commit_arg, sha1))
- usage("usage: rev-list [OPTION] commit-id\n"
- " --max-count=nr\n"
- " --max-age=epoch\n"
- " --min-age=epoch\n");
+ usage(rev_list_usage);
commit = lookup_commit(sha1);
if (!commit || parse_commit(commit) < 0)
@@ -46,6 +56,8 @@ int main(int argc, char **argv)
break;
if (max_count != -1 && !max_count--)
break;
+ if (has_stop_at && !memcmp(stop_at, commit->object.sha1, 20))
+ break;
printf("%s\n", sha1_to_hex(commit->object.sha1));
} while (list);
return 0;
Created: t/t0000.sh (mode:100755)
--- /dev/null
+++ b/t/t0000.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+case "${verbose+set}" in
+set) say= ;;
+*) say=: ;;
+esac
+
+export LANG C
+unset AUTHOR_DATE
+unset AUTHOR_EMAIL
+unset AUTHOR_NAME
+unset COMMIT_AUTHOR_EMAIL
+unset COMMIT_AUTHOR_NAME
+unset GIT_ALTERNATE_OBJECT_DIRECTORIES
+unset GIT_AUTHOR_DATE
+unset GIT_AUTHOR_EMAIL
+unset GIT_AUTHOR_NAME
+unset GIT_COMMITTER_EMAIL
+unset GIT_COMMITTER_NAME
+unset GIT_DIFF_OPTS
+unset GIT_DIR
+unset GIT_EXTERNAL_DIFF
+unset GIT_INDEX_FILE
+unset GIT_OBJECT_DIRECTORY
+unset SHA1_FILE_DIRECTORIES
+unset SHA1_FILE_DIRECTORY
+
+# Test the binaries we have just built.
+PATH=$(pwd)/..:$PATH
+
+# Test repository
+test=test-repo
+rm -fr "$test"
+mkdir "$test"
+cd "$test"
Created: t/t1000-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1000-checkout-cache.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+date >path0
+mkdir path1
+date >path1/file1
+git-update-cache --add path0 path1/file1
+$say git-ls-files --stage
+
+rm -fr path0 path1
+mkdir path0
+date >path0/file0
+date >path1
+$say git-ls-files --stage
+$say find path*
+
+echo >&2 "* checkout-cache sans -f"
+git-checkout-cache -a
+case "$?" in
+0) echo >&2 "*** bug: should not have succeeded." ;;
+*) echo >&2 "*** ok: failed as expected." ;;
+esac
+$say find path*
+
+echo >&2 "* checkout-cache with -f"
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+$say find path*
+if test -f path0 && test -d path1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: checkout failed."
+ exit 1
+fi
Created: t/t1001-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1001-checkout-cache.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+
+show_files() {
+ find path? -ls |
+ sed -e 's/^[0-9]* * [0-9]* * \([-bcdl]\)[^ ]* *[0-9]* *[^ ]* *[^ ]* *[0-9]* [A-Z][a-z][a-z] [0-9][0-9] [^ ]* /fs: \1 /'
+ git-ls-files --stage |
+ sed -e 's/^\([0-9]*\) [0-9a-f]* [0-3] /ca: \1 /'
+ git-ls-tree -r "$1" |
+ sed -e 's/^\([0-9]*\) [^ ]* [0-9a-f]* /tr: \1 /'
+}
+
+mkdir path0
+date >path0/file0
+git-update-cache --add path0/file0
+echo >&2 "* initial state: one file under one directory"
+tree1=$(git-write-tree)
+$say show_files $tree1
+
+mkdir path1
+date >path1/file1
+git-update-cache --add path1/file1
+echo >&2 "* two directories with one file each"
+tree2=$(git-write-tree)
+$say show_files $tree2
+
+rm -fr path1
+git-read-tree -m $tree1
+git-checkout-cache -f -a
+echo >&2 "* go back to initial state"
+$say show_files $tree1
+
+ln -s path0 path1
+git-update-cache --add path1
+echo >&2 "* a symlink where the other side would create a directory."
+tree3=$(git-write-tree)
+$say show_files $tree3
+
+# Morten says "Got that?" here.
+
+git-read-tree $tree2
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+echo >&2 "* read tree2 and checkout"
+$say show_files $tree2
+
+if test ! -h path0 && test -d path0 &&
+ test ! -h path1 && test -d path1 &&
+ test ! -h path0/file0 && test -f path0/file0 &&
+ test ! -h path1/file1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: did not check out correctly."
+ exit 1
+fi
------------------------------------------------
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-11 22:00 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115847510.22180.108.camel@tglx>
On Wed, May 11, 2005 5:38 pm, Thomas Gleixner said:
> This is an initial attempt to enable history tracking for multiple
> repositories in a consistent state. At the moment this can only be done
> by heuristic guessing on the parent dates and the committer names.
> This fails for example with Dave Millers net-2.6 and sparc-2.6 trees, as
> in both cases the committer name is the same. It fails also completely
> in cases where the system clock of the committer is wrong and the merge
> is a head forward. The old bk repository contains entries from 1999 and
> 2027, which will happen also with git over the time.
>
> To identify a repository commit-tree tries to read an environment
> variable "GIT_REPOSITORY_ID" and has a fallback to the current working
> directory. The environment variable keeps the door open for managed
> repository id's, but the current working directory is certainly a quite
> helpful information to solve the origin decision for history tracking.
>
> Adding a line after the committer should not break any existing tools
> AFAICS.
To make this useful you're also going to have to change the parent entries
to something like:
parent SHA1 REPOID
At least when the referenced commit has a repoid that doesn't match the
repository from which you obtained the object, ie. fast forward heads.
This implies that you know the repoid of the repository you pulled the
object from!
Otherwise, you still haven't solved the problem of identifying fast
forward heads as you traverse the history.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 22:05 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <2780.10.10.10.24.1115848852.squirrel@linux1>
On Wed, 2005-05-11 at 18:00 -0400, Sean wrote:
> To make this useful you're also going to have to change the parent entries
> to something like:
>
> parent SHA1 REPOID
>
> At least when the referenced commit has a repoid that doesn't match the
> repository from which you obtained the object, ie. fast forward heads.
> This implies that you know the repoid of the repository you pulled the
> object from!
>
> Otherwise, you still haven't solved the problem of identifying fast
> forward heads as you traverse the history.
Err,
each parent is a commit, which is identified by its repoid. Why do you
want to add redundant information ?
tglx
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-11 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Morten Welinder, git, Linus Torvalds
In-Reply-To: <7vpsvxqwab.fsf@assigned-by-dhcp.cox.net>
Here is a re-diff against the current tip of the git-pb tree.
------------
Fix checkout-cache when existing work tree interferes with the checkout.
This is essentially the same one as the last one I sent to the
GIT list, except that the patch is rebased to the current tip of
the git-pb tree, and an unnecessary call to create_directories()
removed.
The checkout-cache command gets confused when checking out a
file in a subdirectory and the work tree has a symlink to the
subdirectory. Also it fails to check things out when there is a
non-directory in the work tree when cache expects a directory
there, and vice versa. This patch fixes the first problem by
making sure all the leading paths in the file being checked out
are indeed directories, and also fixes directory vs
non-directory conflicts when '-f' is specified by removing the
offending paths.
I've added test subdirectory and two tests to check the above
problems are fixed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 49 +++++++++++++++++++++++++++++++++--
t/t0000.sh | 38 +++++++++++++++++++++++++++
t/t1000-checkout-cache.sh | 42 ++++++++++++++++++++++++++++++
t/t1001-checkout-cache.sh | 64 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 190 insertions(+), 3 deletions(-)
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -32,6 +32,8 @@
* of "-a" causing problems (not possible in the above example,
* but get used to it in scripting!).
*/
+#include <sys/types.h>
+#include <dirent.h>
#include "cache.h"
static int force = 0, quiet = 0, not_new = 0;
@@ -46,20 +48,61 @@ static void create_directories(const cha
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
- mkdir(buf, 0755);
+ if (mkdir(buf, 0755)) {
+ if (errno == EEXIST) {
+ struct stat st;
+ if (!lstat(buf, &st) && S_ISDIR(st.st_mode))
+ continue; /* ok */
+ if (force && !unlink(buf) && !mkdir(buf, 0755))
+ continue;
+ }
+ die("cannot create directory at %s", buf);
+ }
}
free(buf);
}
+static void remove_subtree(const char *path)
+{
+ DIR *dir = opendir(path);
+ struct dirent *de;
+ char pathbuf[PATH_MAX];
+ char *name;
+
+ if (!dir)
+ die("cannot opendir %s", path);
+ strcpy(pathbuf, path);
+ name = pathbuf + strlen(path);
+ *name++ = '/';
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st;
+ if ((de->d_name[0] == '.') &&
+ ((de->d_name[1] == 0) ||
+ ((de->d_name[1] == '.') && de->d_name[2] == 0)))
+ continue;
+ strcpy(name, de->d_name);
+ if (lstat(pathbuf, &st))
+ die("cannot lstat %s", pathbuf);
+ if (S_ISDIR(st.st_mode))
+ remove_subtree(pathbuf);
+ else if (unlink(pathbuf))
+ die("cannot unlink %s", pathbuf);
+ }
+ closedir(dir);
+ if (rmdir(path))
+ die("cannot rmdir %s", path);
+}
+
static int create_file(const char *path, unsigned int mode)
{
int fd;
mode = (mode & 0100) ? 0777 : 0666;
+ create_directories(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
if (fd < 0) {
- if (errno == ENOENT) {
- create_directories(path);
+ if (errno == EISDIR && force) {
+ remove_subtree(path);
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
}
}
Created: t/t0000.sh (mode:100755)
--- /dev/null
+++ b/t/t0000.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+case "${verbose+set}" in
+set) say= ;;
+*) say=: ;;
+esac
+
+export LANG C
+unset AUTHOR_DATE
+unset AUTHOR_EMAIL
+unset AUTHOR_NAME
+unset COMMIT_AUTHOR_EMAIL
+unset COMMIT_AUTHOR_NAME
+unset GIT_ALTERNATE_OBJECT_DIRECTORIES
+unset GIT_AUTHOR_DATE
+unset GIT_AUTHOR_EMAIL
+unset GIT_AUTHOR_NAME
+unset GIT_COMMITTER_EMAIL
+unset GIT_COMMITTER_NAME
+unset GIT_DIFF_OPTS
+unset GIT_DIR
+unset GIT_EXTERNAL_DIFF
+unset GIT_INDEX_FILE
+unset GIT_OBJECT_DIRECTORY
+unset SHA1_FILE_DIRECTORIES
+unset SHA1_FILE_DIRECTORY
+
+# Test the binaries we have just built.
+PATH=$(pwd)/..:$PATH
+
+# Test repository
+test=test-repo
+rm -fr "$test"
+mkdir "$test"
+cd "$test"
Created: t/t1000-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1000-checkout-cache.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+date >path0
+mkdir path1
+date >path1/file1
+git-update-cache --add path0 path1/file1
+$say git-ls-files --stage
+
+rm -fr path0 path1
+mkdir path0
+date >path0/file0
+date >path1
+$say git-ls-files --stage
+$say find path*
+
+echo >&2 "* checkout-cache sans -f"
+git-checkout-cache -a
+case "$?" in
+0) echo >&2 "*** bug: should not have succeeded." ;;
+*) echo >&2 "*** ok: failed as expected." ;;
+esac
+$say find path*
+
+echo >&2 "* checkout-cache with -f"
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+$say find path*
+if test -f path0 && test -d path1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: checkout failed."
+ exit 1
+fi
Created: t/t1001-checkout-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t1001-checkout-cache.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./t0000.sh
+git-init-db 2>/dev/null || exit
+
+show_files() {
+ find path? -ls |
+ sed -e 's/^[0-9]* * [0-9]* * \([-bcdl]\)[^ ]* *[0-9]* *[^ ]* *[^ ]* *[0-9]* [A-Z][a-z][a-z] [0-9][0-9] [^ ]* /fs: \1 /'
+ git-ls-files --stage |
+ sed -e 's/^\([0-9]*\) [0-9a-f]* [0-3] /ca: \1 /'
+ git-ls-tree -r "$1" |
+ sed -e 's/^\([0-9]*\) [^ ]* [0-9a-f]* /tr: \1 /'
+}
+
+mkdir path0
+date >path0/file0
+git-update-cache --add path0/file0
+echo >&2 "* initial state: one file under one directory"
+tree1=$(git-write-tree)
+$say show_files $tree1
+
+mkdir path1
+date >path1/file1
+git-update-cache --add path1/file1
+echo >&2 "* two directories with one file each"
+tree2=$(git-write-tree)
+$say show_files $tree2
+
+rm -fr path1
+git-read-tree -m $tree1
+git-checkout-cache -f -a
+echo >&2 "* go back to initial state"
+$say show_files $tree1
+
+ln -s path0 path1
+git-update-cache --add path1
+echo >&2 "* a symlink where the other side would create a directory."
+tree3=$(git-write-tree)
+$say show_files $tree3
+
+# Morten says "Got that?" here.
+
+git-read-tree $tree2
+git-checkout-cache -f -a
+case "$?" in
+0) echo >&2 "*** ok: succeeded as expected." ;;
+*) echo >&2 "*** bug: should have succeeded." ;;
+esac
+echo >&2 "* read tree2 and checkout"
+$say show_files $tree2
+
+if test ! -h path0 && test -d path0 &&
+ test ! -h path1 && test -d path1 &&
+ test ! -h path0/file0 && test -f path0/file0 &&
+ test ! -h path1/file1 && test -f path1/file1
+then
+ echo >&2 "*** ok: checked out correctly."
+else
+ echo >&2 "*** bug: did not check out correctly."
+ exit 1
+fi
------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Petr Baudis @ 2005-05-11 22:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: tglx, git
In-Reply-To: <7vis1pqvi4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, May 11, 2005 at 11:54:11PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "TG" == Thomas Gleixner <tglx@linutronix.de> writes:
>
> TG> You moved the stop behind the printf which is inconsistent to the other
> TG> stop conditions, but thats a pure cosmetic question as long as it stays
> TG> that way for ever.
>
> While I work on the core GIT changes, I often find myself doing
>
> $ jit-log -l --since linus
> $ jit-log -l --since git-jc
>
> to see what changes I have in my local work repository, and
> seeing the branching point (or origin) at the very end of the
> log made me feel assured that I am not losing anything in the
> log. But come to think of it, that is really an unnecessary
> thing and stopping _before_ the named commit would make more
> sense.
>
> Here is a fixed version. I am CC'ing pasky hoping he would pick
> it up.
Yes, looks better and more consistent with the rest of the stuff.
But the very fact that you want this makes me *quite* nervous - I think
this is bad thing to do. The problem is, for something like
o
| \
o |
| o
| o
o /
o
------
it will show the merged revisions properly, but for
o
| \
o |
------
| o
| o
o /
o
it won't show the full merge. Whilst when you do
*-log --since foo
I think you mean it to show everything going into the tree since foo -
that would include the whole branch you cut off now.
Thomas, what are you going to use it for?
> Add --stop-at to git-rev-list command.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
I liked the previous patch revision commit message much better, I have
to admit. ;-)
> ---
> --- a/checkout-cache.c
> +++ b/checkout-cache.c
I assume this is irrelevant here?
> --- a/rev-list.c
> +++ b/rev-list.c
Looks ok.
Could you please also update the documentation appropriately? (If we
have it, let's keep it up to date.)
> Created: t/t0000.sh (mode:100755)
> --- /dev/null
> +++ b/t/t0000.sh
You want this in too?
Starting to build a testsuite sounds like a good idea, but we should
probably first devise some calling convention etc. I personally suck at
automated testing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Embedding asciidoc manpages in the cg scripts
From: David Greaves @ 2005-05-11 22:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jonas Fonseca, git
In-Reply-To: <20050511213217.GG22686@pasky.ji.cz>
Petr Baudis wrote:
>> #
>>+# NAME
>>+# ----
>>+# cg-add - add files to a GIT repository
>>
>>
>
>Half of this is useless, too.
>
>I think you should just keep the first paragraph of the files as it is
>now. Don't touch it, just parse it.
>
>
A bit harsh Petr.
Isn't the idea of using an already written tool that you don't _have_ to
parse it?
Where, consistently, do the cg-files have a 1 line summary.
>>+#
>>+# SYNOPSIS
>>+# --------
>>
>>
>No need for this heading either.
>
>
Actually there is :)
asciidoc won't produce a manpage without it.
>>+USAGE="cg-add FILE..."
>>+#
>>+# DESCRIPTION
>>+# -----------
>> # Takes a list of file names at the command line, and schedules them
>> # for addition to the GIT repository at the next commit.
>>+#
>>+# The command will fail if one of the given files does not exist.
>>+#
>>+# cg-add is part of Cogito, an SCM-like toolkit for managing GIT trees.
>>
>>
>
>Useless.
>
>
Yes - if you happen to have written and breathed the code - not so
useless if you're a normal user.
It cogito is ever installed as part of a distro (maybe even by default)
then it would be nice if "man cg-add" actually mentioned it was part of
cogito and git...
>>+#
>>+# OPTIONS
>>+# -------
>>+# No options.
>>
>>
>
>The rest of DESCRIPTION and OPTIONS looks fine.
>
>I'd just expect you to be much less intrusive in the in-file comments
>and do more work when processing the stuff. I'm commenting on how it
>looks inside of the sources - do whatever is necessary when processing
>it to generate a proper-looking manpage from it.
>
>
Having worked hard on being consistent throughout the git docs I'd say
that a little excess verbiage in the comments is a worthwhile price. I
don't think you can worry about performance or anything - these _are_
shell scripts!
Maybe you'd be happier if they were moved to the bottom of the file and
preceded with:
#asciidoc follows
Or if you don't like that then maybe keep them external.
David
--
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-11 22:24 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115849141.22180.123.camel@tglx>
On Wed, May 11, 2005 6:05 pm, Thomas Gleixner said:
> Err,
> each parent is a commit, which is identified by its repoid. Why do you
> want to add redundant information ?
>
It's not necessarily the repoid you pulled the object from though. It may
be the repoid of another completely separate repository.
Repo A - creates object HEAD = (A)
Repo B - pulls objects from Repo A FAST FORWARD HEAD = (A)
Repo C - pulls from Repo B
Now as you traverse the history in Repo C, the object will show as coming
from Repo A, not Repo B.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 22:30 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <2807.10.10.10.24.1115850254.squirrel@linux1>
On Wed, 2005-05-11 at 18:24 -0400, Sean wrote:
> On Wed, May 11, 2005 6:05 pm, Thomas Gleixner said:
>
> > Err,
> > each parent is a commit, which is identified by its repoid. Why do you
> > want to add redundant information ?
> >
>
> It's not necessarily the repoid you pulled the object from though. It may
> be the repoid of another completely separate repository.
>
> Repo A - creates object HEAD = (A)
> Repo B - pulls objects from Repo A FAST FORWARD HEAD = (A)
> Repo C - pulls from Repo B
>
> Now as you traverse the history in Repo C, the object will show as coming
> from Repo A, not Repo B.
At this point it is completely irrelevant if you pulled from A or B. The
originator of Head A is A forever.
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-11 22:36 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115850619.22180.133.camel@tglx>
On Wed, May 11, 2005 6:30 pm, Thomas Gleixner said:
> At this point it is completely irrelevant if you pulled from A or B. The
> originator of Head A is A forever.
But who cares what repository was used to create the object? You can't
talk to a repository. What you want to know is who created the object,
and Author/Committer completely solves that problem.
If on the otherhand you're trying to reliably track the chain-of-command
that landed the object in your repository, your patch falls short.
Sean
^ permalink raw reply
* Test suite
From: Petr Baudis @ 2005-05-11 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5rxquo5.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 12, 2005 at 12:12:10AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I've added test subdirectory and two tests to check the above
> problems are fixed.
I'd prefer introduction of the infrastructure for this in a separate
commit. I'll focus on it here; I will have a look at the checkout-cache
stuff tomorrow.
> Created: t/t0000.sh (mode:100755)
> --- /dev/null
> +++ b/t/t0000.sh
I'd prefer some better name for this. What about testlib.sh?
> @@ -0,0 +1,38 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2005 Junio C Hamano
> +#
A short description here would be nice.
> +case "${verbose+set}" in
> +set) say= ;;
> +*) say=: ;;
> +esac
Perhaps set $verbose if -v was passed or something.
Looking at how you use it, I wouldn't run the command at all if not
verbose.
> Created: t/t1000-checkout-cache.sh (mode:100755)
> --- /dev/null
> +++ b/t/t1000-checkout-cache.sh
> @@ -0,0 +1,42 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2005 Junio C Hamano
> +#
I think each test in the suite should have a short summary of its focus
in the top comment.
> +. ./t0000.sh
> +git-init-db 2>/dev/null || exit
I'd do this in testlib.sh (you might well blast it away and redo it when
testing init-db).
> +echo >&2 "* checkout-cache sans -f"
> +git-checkout-cache -a
> +case "$?" in
> +0) echo >&2 "*** bug: should not have succeeded." ;;
> +*) echo >&2 "*** ok: failed as expected." ;;
> +esac
And this essentially repeats all over and over.
What about something like
cmdtest "sans -f" git-checkout-cache -a
> +if test -f path0 && test -d path1 && test -f path1/file1
> +then
> + echo >&2 "*** ok: checked out correctly."
> +else
> + echo >&2 "*** bug: checkout failed."
> + exit 1
> +fi
We might get a good function for this later too, for now I'd propose
if test -f path0 && test -d path1 && test -f path1/file1; then
testok "checkout"
else
testfail "checkout" # non-fatal test failure
testfatal "checkout" # fatal test failure, die right away
fi
And at the end the script, you should do
exit $teststatus
which is set to non-zero anytime testfail was invoked.
> Created: t/t1001-checkout-cache.sh (mode:100755)
> --- /dev/null
> +++ b/t/t1001-checkout-cache.sh
> @@ -0,0 +1,64 @@
> +show_files() {
> + find path? -ls |
> + sed -e 's/^[0-9]* * [0-9]* * \([-bcdl]\)[^ ]* *[0-9]* *[^ ]* *[^ ]* *[0-9]* [A-Z][a-z][a-z] [0-9][0-9] [^ ]* /fs: \1 /'
> + git-ls-files --stage |
> + sed -e 's/^\([0-9]*\) [0-9a-f]* [0-3] /ca: \1 /'
> + git-ls-tree -r "$1" |
> + sed -e 's/^\([0-9]*\) [^ ]* [0-9a-f]* /tr: \1 /'
> +}
Ugh. I think a comment would be suitable here. ;-)
> +mkdir path0
> +date >path0/file0
> +git-update-cache --add path0/file0
> +echo >&2 "* initial state: one file under one directory"
> +tree1=$(git-write-tree)
cmdtest --capture-stdout "one file under one directory" git-write-tree
tree1=$(cat $teststdout)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 22:48 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <2853.10.10.10.24.1115850996.squirrel@linux1>
On Wed, 2005-05-11 at 18:36 -0400, Sean wrote:
> On Wed, May 11, 2005 6:30 pm, Thomas Gleixner said:
>
> > At this point it is completely irrelevant if you pulled from A or B. The
> > originator of Head A is A forever.
>
> But who cares what repository was used to create the object? You can't
> talk to a repository. What you want to know is who created the object,
> and Author/Committer completely solves that problem.
Maybe you have missed the point, where one Committer holds more than one
repository. See davem/net-2.6 and davem/sparc-2.6. Not to talk of
Russell King's and Greg's multiple repositories.
The Author is irrelevant, because one Author sends patches to more than
one maintainer. Author _cannot_ be a source of tracking information. If
you want to do heuristic guesses on Author/Committer pairs, then you
make the situation more complex than it is already.
> If on the otherhand you're trying to reliably track the chain-of-command
> that landed the object in your repository, your patch falls short.
As I said before it is completely irrelevant whether fast forward was
pulled into C directly from A or from B.
Whats the relevant content of getting the same thing from A or B ?
If you want to do this, you break the fast forward mechanism and
reinvent the pull ping-pong which is avoided by the fast forwards.
tglx
^ permalink raw reply
* Re: [RFC] Embedding asciidoc manpages in the cg scripts
From: Petr Baudis @ 2005-05-11 22:48 UTC (permalink / raw)
To: David Greaves; +Cc: Jonas Fonseca, git
In-Reply-To: <4282851A.2010305@dgreaves.com>
Dear diary, on Thu, May 12, 2005 at 12:20:10AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Petr Baudis wrote:
>
> >> #
> >>+# NAME
> >>+# ----
> >>+# cg-add - add files to a GIT repository
> >>
> >>
> >
> >Half of this is useless, too.
> >
> >I think you should just keep the first paragraph of the files as it is
> >now. Don't touch it, just parse it.
> >
> >
> A bit harsh Petr.
Sorry, I didn't mean to sound (too) harsh. ;-)
> Isn't the idea of using an already written tool that you don't _have_ to
> parse it?
No, the idea is to get nice output while keeping the input easily human
readable. I'm only stretching that further, since we know more than
asciidoc itself does about the file. :-)
> Where, consistently, do the cg-files have a 1 line summary.
I can't parse this sentence, I fear. All the cg-files have a 1 line
summary, then one or more copyright lines, then the description 'n
stuff. That's fixed format, much like the git commit format.
> >>+#
> >>+# SYNOPSIS
> >>+# --------
> >>
> >>
> >No need for this heading either.
> >
> >
> Actually there is :)
> asciidoc won't produce a manpage without it.
So the script piping this to asciidoc can add this at the proper point.
> >>+USAGE="cg-add FILE..."
> >>+#
> >>+# DESCRIPTION
> >>+# -----------
> >> # Takes a list of file names at the command line, and schedules them
> >> # for addition to the GIT repository at the next commit.
> >>+#
> >>+# The command will fail if one of the given files does not exist.
> >>+#
> >>+# cg-add is part of Cogito, an SCM-like toolkit for managing GIT trees.
> >>
> >>
> >
> >Useless.
> >
> >
> Yes - if you happen to have written and breathed the code - not so
> useless if you're a normal user.
Sorry, I've meant only the "cg-add is part of Cogito, an SCM-like
toolkit for managing GIT trees" part is useless.
> It cogito is ever installed as part of a distro (maybe even by default)
> then it would be nice if "man cg-add" actually mentioned it was part of
> cogito and git...
Yes. I'm fine with it being in the manpage. I just don't want it in the
code since again, it is obvious there. And code (be it program code or
documentation code) duplication is wrong, if you have a non-trivial
chunk repeated over and over everywhere, you probably want to move it to
a single place. That'd be the conversion script here.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Thomas Gleixner @ 2005-05-11 22:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050511221719.GH22686@pasky.ji.cz>
On Thu, 2005-05-12 at 00:17 +0200, Petr Baudis wrote:
> But the very fact that you want this makes me *quite* nervous - I think
> this is bad thing to do. The problem is, for something like
> it won't show the full merge.
>
> I think you mean it to show everything going into the tree since foo -
> that would include the whole branch you cut off now.
>From a SCM POV it does not matter.
Rn o
| \
Rn-1 o |
| o Mn
| o Mn-1
Rn-2 o /
Rn-3 o
If you are in Repository R, then tracking Rn to Rn-123 gives you a
linear result depending on the stop point you chose.
Rn
---- Stop = Rn-1
Rn-1
---- Stop = Rn-2
Rn-2
---- Stop = Rn-3
The diff between Rn and Rn-1 contains always the changes merged from M
> Thomas, what are you going to use it for?
Displaing the the changes between commit shaX and shaY :)
tglx
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Petr Baudis @ 2005-05-11 22:50 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Junio C Hamano, git
In-Reply-To: <1115851742.22180.154.camel@tglx>
Dear diary, on Thu, May 12, 2005 at 12:49:02AM CEST, I got a letter
where Thomas Gleixner <tglx@linutronix.de> told me that...
> Rn o
> | \
> Rn-1 o |
> | o Mn
> | o Mn-1
> Rn-2 o /
> Rn-3 o
>
> If you are in Repository R, then tracking Rn to Rn-123 gives you a
> linear result depending on the stop point you chose.
> Rn
> ---- Stop = Rn-1
> Rn-1
> ---- Stop = Rn-2
Mn
Mn-1
> Rn-2
> ---- Stop = Rn-3
>
> The diff between Rn and Rn-1 contains always the changes merged from M
Yes, but you get the merge commits again since rev-list follows all the
parents.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-11 23:01 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115851718.22180.153.camel@tglx>
On Wed, May 11, 2005 6:48 pm, Thomas Gleixner said:
Hey Thomas,
> Maybe you have missed the point, where one Committer holds more than one
> repository. See davem/net-2.6 and davem/sparc-2.6. Not to talk of
> Russell King's and Greg's multiple repositories.
> The Author is irrelevant, because one Author sends patches to more than
> one maintainer. Author _cannot_ be a source of tracking information. If
> you want to do heuristic guesses on Author/Committer pairs, then you
> make the situation more complex than it is already.
Why would anyone care how many repositories Russell or Greg use? Why does
anyone care if Dave used his repo A, B, or C? Aren't I still just going
to contact him via his author email addy if I have an issue with an object
he has added to the stream?
And if I do care which repo he used, why don't I care about the case i've
outlined where the chain of command information is lost?
> As I said before it is completely irrelevant whether fast forward was
> pulled into C directly from A or from B.
>
> Whats the relevant content of getting the same thing from A or B ?
Exactly!!! So what is relevant of getting the same thing from Dave's A or
B? The only point would be to show chain of command, but you don't seem
interested in that.
> If you want to do this, you break the fast forward mechanism and
> reinvent the pull ping-pong which is avoided by the fast forwards.
Yes, I think there are other ways to avoid the ping pong too.
Sean
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Thomas Gleixner @ 2005-05-11 23:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050511225058.GK22686@pasky.ji.cz>
On Thu, 2005-05-12 at 00:50 +0200, Petr Baudis wrote:
> > Rn
> > ---- Stop = Rn-1
> > Rn-1
> > ---- Stop = Rn-2
>
> Mn
> Mn-1
>
> > Rn-2
> > ---- Stop = Rn-3
> >
> > The diff between Rn and Rn-1 contains always the changes merged from M
>
> Yes, but you get the merge commits again since rev-list follows all the
> parents.
That's plain wrong. The Mn(1) change hit repository r between revision
Rn and Rn-1 and nowhere else.
Date is irrelevant. The only relevant thing is the parent child(s)
relationship.
What you get doing this is history cluttering. In the repository R it is
completely irrelevant when Mn resp. Mn-1 was created. The only relevant
point is when it was merged into repository R.
Bitkeeper does the same bogus thing to make changesets appear in a
linear order. Look at the changeset logs. If you diff the versions
exported by bitkeeper then you get complete nonsense.
Please do not make the same mistake.
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: H. Peter Anvin @ 2005-05-11 23:14 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115847510.22180.108.camel@tglx>
Thomas Gleixner wrote:
> This is an initial attempt to enable history tracking for multiple
> repositories in a consistent state. At the moment this can only be done
> by heuristic guessing on the parent dates and the committer names.
> This fails for example with Dave Millers net-2.6 and sparc-2.6 trees, as
> in both cases the committer name is the same. It fails also completely
> in cases where the system clock of the committer is wrong and the merge
> is a head forward. The old bk repository contains entries from 1999 and
> 2027, which will happen also with git over the time.
>
> To identify a repository commit-tree tries to read an environment
> variable "GIT_REPOSITORY_ID" and has a fallback to the current working
> directory. The environment variable keeps the door open for managed
> repository id's, but the current working directory is certainly a quite
> helpful information to solve the origin decision for history tracking.
>
> Adding a line after the committer should not break any existing tools
> AFAICS.
>
I would like to suggest a few limiters are set on the repoid. In
particular, I'd like to suggest that a repoid is a UUID, that a file is
used to track it (.git/repoid), and that if it doesn't exist, a new one
is created from /dev/urandom.
-hpa
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 23:33 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <2883.10.10.10.24.1115852463.squirrel@linux1>
On Wed, 2005-05-11 at 19:01 -0400, Sean wrote:
> Why would anyone care how many repositories Russell or Greg use? Why does
> anyone care if Dave used his repo A, B, or C? Aren't I still just going
> to contact him via his author email addy if I have an issue with an object
> he has added to the stream?
He? What the hell have the sparc-2.6 and net-2.6 in common except the
same owner/maintainer ? Should we base the heuristics on directories and
filenames ? Cool.
It is relevant for the maintainers to have information which is
consistent over a repository. So the source of change _is_ relevant.
> Exactly!!! So what is relevant of getting the same thing from Dave's A or
> B?
The relevant part is, that it _is_ relevant for Dave to know where the
hell a problem was introduced.
> The only point would be to show chain of command, but you don't seem
> interested in that.
What is the chain of commands good for ? Does the chain of commands
change the history information in a specific repository ?
No.
If you buy food, then it is relevant if you get it from A directly or
via B. The commit and the referenced tree is immutable and does neither
change the consistency nor gets uneatable.
> > If you want to do this, you break the fast forward mechanism and
> > reinvent the pull ping-pong which is avoided by the fast forwards.
>
> Yes, I think there are other ways to avoid the ping pong too.
True, but not with a plain rsync approach
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-11 23:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <428291CD.7010701@zytor.com>
On Wed, 2005-05-11 at 16:14 -0700, H. Peter Anvin wrote:
> I would like to suggest a few limiters are set on the repoid. In
> particular, I'd like to suggest that a repoid is a UUID, that a file is
> used to track it (.git/repoid), and that if it doesn't exist, a new one
> is created from /dev/urandom.
Which is complety error prone due to rsync. Some of the repositories on
kernel.org keep identical copies of .git/description already. Why should
they preserve an unique .git/repoid ?
There is one clean way to solve this. Managed repository id's and a lot
of discipline.
I expect neither of those two things to happen, but a complete working
directory path is better than nothing to make educated guesses.
Committer names (maintainers) can be the same over repositories, but its
unlikely that somebody who manages more than one subsystems uses the
same working directory for them.
tglx
^ 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