* Re: [RFC] allow file list editing during cg-commit
From: Eugene Surovegin @ 2005-05-09 22:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050509084606.GD3599@pasky.ji.cz>
On Mon, May 09, 2005 at 10:46:06AM +0200, Petr Baudis wrote:
[snip]
> The only thing to watch out for is that cg-commit -C produces no such
> list at all; it should deal with that and tell the user he is not going
> to be able to control what is going to be committed then.
>
> Another thing is that at the moment you modify the file list, you should
> set customfiles - otherwise you will commit even cg-adds and cg-rms of
> files you didn't select. But do that really only when you change the
> file list, since it is more expensive.
>
> You should also place an appropriate hint near the CG: lines, saying
> that removing some of them will limit the list of files to be committed.
OK, how about the following patch? I tried to address all issues you
mentioned and also $merging case as well.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Index: cg-commit
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -111,12 +111,16 @@
rm $LOGMSG $LOGMSG2
die 'Nothing to commit'
fi
+ if [ ! "$merging" ]; then
+ echo "CG: By deleting lines beginning with CG:F the associated file" >>$LOGMSG
+ echo "CG: will be removed from the commit list." >>$LOGMSG
+ fi
echo "CG:" >>$LOGMSG
echo "CG: Modified files:" >>$LOGMSG
for file in "${commitfiles[@]}"; do
# TODO: Prepend a letter describing whether it's addition,
# removal or update. Or call git status on those files.
- echo "CG: $file" >>$LOGMSG
+ echo "CG:F $file" >>$LOGMSG
[ "$msgs" ] && ! [ "$forceeditor" ] && echo $file
done
fi
@@ -131,6 +135,17 @@
rm $LOGMSG $LOGMSG2
die 'Commit message not modified, commit aborted'
fi
+ if [ ! "$ignorecache" ] && [ ! "$merging" ]; then
+ eval newcommitfiles=($(grep ^CG:F $LOGMSG2 | sed 's/^CG:F//'))
+ if [ ! "${newcommitfiles[*]}" ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Nothing to commit'
+ fi
+ if [ "${commitfiles[*]}" != "${newcommitfiles[*]}" ]; then
+ commitfiles="${newcommitfiles[*]}"
+ customfiles="${commitfiles[*]}"
+ fi
+ fi
else
cat >>$LOGMSG2
fi
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: H. Peter Anvin @ 2005-05-09 22:20 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: Petr Baudis, Git Mailing List, darcs-devel
In-Reply-To: <7iu0lc129m.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek wrote:
> Ahoj,
>
>
>>FWIW, Cogito does not lock at all yet - this is one of the things which
>>should be fixed soon.
>
>
> I see. Let me know if you decide to use a different name for the lock
> file so I can switch to using the same one as yours.
>
Are you using flock(), or some other contraption that breaks if a
process dies unexpectedly?
-hpa
^ permalink raw reply
* Re: Prototype git commit viewer
From: Paul Mackerras @ 2005-05-09 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050509071341.GA3599@pasky.ji.cz>
Petr Baudis writes:
> What are its advantages to git-viz?
As a kernel developer, when I do a pull from Linus' tree, the question
I want to ask is "who has been making what changes?" That's why gitk
shows the headline and author of each of 30 commits in one screenful.
AFAICS from the screenshots, git-viz doesn't give me that density of
information (and neither did bk revtool, for that matter).
It seems to me that git-viz makes the graph topology the primary thing
and the details of the commits the secondary thing. I want it the
other way around.
Paul.
^ permalink raw reply
* Re: History messup
From: Sean @ 2005-05-09 22:08 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: David Woodhouse, tglx, git, Linus Torvalds
In-Reply-To: <427FBB53.1000801@zytor.com>
On Mon, May 9, 2005 3:34 pm, H. Peter Anvin said:
> I'm particularly thinking of when you copy and clone directories, you
> have to define your semantics more specifically. When do you want to
> *copy* this ID, and when do you want to make sure a new one is created?
What question will a repoid let you answer?
Isn't the real problem, where to store "repoid"? Obviously it would be
stored in each commit created in a repo, but that's not really the
problem. The problem is identifying which repo each branch belongs to as
you traverse the history. This lets you ask questions like, "was this
commit created on this branch, or is it just a copy".
But just as the committer information in each object doesn't help you
identify the branch, nor will having a repoid inside each commit. The
problem is labelling the branch, not the commits found in it. And there
is no place to store the repoid for each branch.
Using the repoid of the first commit found on a branch is pretty close,
but fails because it might be a fast-forward HEAD rather than a genuine
local commit of the source repository. So there is no way to know as you
embark down a branch its repoid, so you have nothing to compare against
the repoid inside each commit you find along its path.
Seems the only solution is a full search of the history, unless there is
some clever way to label branches or detect fast forward heads.
> One possible answer to that is to have .git/repoid and have it
> auto-created (from /dev/urandom) if it doesn't exist, but I also observe
> that at least two people (davem and pavel) have managed to clone "Linus'
> kernel tree" as their description on http://www.kernel.org/git/ ...
:o)
sean
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Juliusz Chroboczek @ 2005-05-09 22:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: darcs-devel, Git Mailing List
In-Reply-To: <20050509212842.GC15712@pasky.ji.cz>
Ahoj,
> FWIW, Cogito does not lock at all yet - this is one of the things which
> should be fixed soon.
I see. Let me know if you decide to use a different name for the lock
file so I can switch to using the same one as yours.
Julek
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Petr Baudis @ 2005-05-09 21:28 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: Git Mailing List, darcs-devel
In-Reply-To: <7ihdhc5le2.fsf@lanthane.pps.jussieu.fr>
Dear diary, on Mon, May 09, 2005 at 08:01:25PM CEST, I got a letter
where Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> told me that...
> 1. Darcs-git uses the fact that Git updates are atomic when reading
> from a Git repository. Darcs-git almost writes to Git repositories
> atomically, with one exception: it performs a non-atomic
> read/update/write cycle on .git/HEAD.
>
> For that reason, I'm taking a high-level lock on .git repositories
> whenever I write them. The lockfile is ``.git/lock''. I haven't
> thought about whether Darcs can be easily coerced into accessing Git
> repos atomically; have people writing Git wrappers found the need for
> a global lock?
FWIW, Cogito does not lock at all yet - this is one of the things which
should be fixed soon.
> - there's no way to have multiple simultaneous caches, short of
> hacking at the values of Git's global variables by hand.
See the Brad Robert's patches of Apr 21. I've decided not to apply them
since it appears a lot has changed since then and it would be some pain;
but they may be a worthy starting point for a more up-to-date patch.
--
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] Renaming environment variables.
From: Sean @ 2005-05-09 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vhdhcxj0z.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, May 9, 2005 4:05 pm, Junio C Hamano said:
> H. Peter Anvin mentioned that using SHA1_whatever as an
> environment variable name is not nice and we should instead use
> names starting with "GIT_" prefix to avoid conflicts.
>
> Here is a patch, requesting for comments.
Junio,
Look quite good; you made short work of that!
However I don't understand your gitenv_bc, wouldn't the following suffice?
char *gitenv_bc(const char *e)
{
int i;
char *val = getenv(e);
if (val)
return val;
for (i=0; i < sizeof(bc_name) / sizeof(bc_name[0]); ++i) {
if (!strcmp(e, bc_name[i].canonical)) {
if (val = getenv(bc_name[i].old))
warn_old_environment();
return val;
}
}
return NULL;
}
Cheers,
Sean
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Thomas Glanzmann @ 2005-05-09 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <7vhdhcxj0z.fsf_-_@assigned-by-dhcp.cox.net>
Hello,
> Here is a patch, requesting for comments.
sounds good. But I would forget about downward compatibility. There is
no need to maintain it at this early stage.
And one thing which bothers me all the time but never spoke up about it:
There is no way to provide a GIT_COMMIT_DATE. This would be useful for
vendortracking a CVS repository for example.
And personally I think GIT_COMMIT_AUTHOR_EMAIL and
GIT_COMMIT_AUTHOR_NAME are to long what about
GIT_COMMITTER_{NAME,EMAIL}? Whatever. You script them or put them in
your environment anyway so no big issue.
Thomas
^ permalink raw reply
* [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-09 20:05 UTC (permalink / raw)
To: git; +Cc: H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7vfywwz11t.fsf@assigned-by-dhcp.cox.net>
H. Peter Anvin mentioned that using SHA1_whatever as an
environment variable name is not nice and we should instead use
names starting with "GIT_" prefix to avoid conflicts.
Here is a patch, requesting for comments.
- Renames the following environment variables:
New name Old Name
GIT_AUTHOR_DATE AUTHOR_DATE
GIT_AUTHOR_EMAIL AUTHOR_EMAIL
GIT_AUTHOR_NAME AUTHOR_NAME
GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
GIT_COMMIT_AUTHOR_NAME COMMIT_AUTHOR_NAME
GIT_ALTERNATE_OBJECTS SHA1_FILE_DIRECTORIES
GIT_OBJECTS SHA1_FILE_DIRECTORY
- Changes all users of the environment variable to fetch
environment variable with the new name.
- Introduces a compatibility macro, gitenv(), which does an
getenv() and if it fails calls gitenv_bc(), which in turn
picks up the value from old name while giving a warning about
using an old name.
I've also updated the documentation and scripts shipped with
Linus GIT distribution.
The transition plan is as follows:
- We will keep the backward compatibility list used by gitenv()
for now, so the current scripts and user environments
continue to work as before. The users will get warnings when
they have old name but not new name in their environment to
the stderr.
- The Porcelain layers should start using new names. However,
just in case it ends up calling old Plumbing layer
implementation, they should also export old names, taking
values from the corresponding new names, during the
transition period.
- After a couple of weeks or so, we would drop the
compatibility support and drop gitenv(). Revert the callers
to directly call getenv() but keep using the new names.
The last part is probably optional and the transition
duration needs to be set to a reasonable value.
Not-quite-signed-off-yet-by: Junio C Hamano <junkio@cox.net>
------------
Documentation/core-git.txt | 17 +++++-----
Makefile | 3 +
README | 2 -
cache.h | 15 +++++++--
commit-tree.c | 10 +++---
diff.c | 10 +++---
git-prune-script | 8 +++--
gitenv.c | 70 +++++++++++++++++++++++++++++++++++++++++++++
init-db.c | 7 ++--
rsh.c | 4 +-
sha1_file.c | 8 ++---
11 files changed, 120 insertions(+), 34 deletions(-)
# - HEAD: Fix git-update-cache --cacheinfo error message.
# + 7: Rename Environment Variables
--- a/Documentation/core-git.txt
+++ b/Documentation/core-git.txt
@@ -210,15 +210,16 @@ Environment Variables
---------------------
Various git commands use the following environment variables:
-- 'AUTHOR_NAME'
-- 'AUTHOR_EMAIL'
-- 'AUTHOR_DATE'
-- 'COMMIT_AUTHOR_NAME'
-- 'COMMIT_AUTHOR_EMAIL'
+- 'GIT_AUTHOR_NAME'
+- 'GIT_AUTHOR_EMAIL'
+- 'GIT_AUTHOR_DATE'
+- 'GIT_COMMIT_AUTHOR_NAME'
+- 'GIT_COMMIT_AUTHOR_EMAIL'
- 'GIT_DIFF_OPTS'
- 'GIT_EXTERNAL_DIFF'
- 'GIT_INDEX_FILE'
-- 'SHA1_FILE_DIRECTORY'
+- 'GIT_OBJECTS'
+- 'GIT_ALTERNATE_OBJECTS'
NAME
@@ -876,7 +877,7 @@ sha1 mismatch <object>::
Environment Variables
---------------------
-SHA1_FILE_DIRECTORY::
+GIT_OBJECTS::
used to specify the object database root (usually .git/objects)
GIT_INDEX_FILE::
@@ -918,7 +919,7 @@ DESCRIPTION
This simply creates an empty git object database - basically a `.git`
directory and `.git/object/??/` directories.
-If the object storage directory is specified via the 'SHA1_FILE_DIRECTORY'
+If the object storage directory is specified via the 'GIT_OBJECTS'
environment variable then the sha1 directories are created underneath -
otherwise the default `.git/objects` directory is used.
--- a/Makefile
+++ b/Makefile
@@ -46,6 +46,8 @@ LIB_OBJS += strbuf.o
LIB_H += diff.h
LIB_OBJS += diff.o
+LIB_OBJS += gitenv.o
+
LIBS = $(LIB_FILE)
LIBS += -lz
@@ -116,6 +118,7 @@ sha1_file.o: $(LIB_H)
usage.o: $(LIB_H)
diff.o: $(LIB_H)
strbuf.o: $(LIB_H)
+gitenv.o: $(LIB_H)
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
--- a/README
+++ b/README
@@ -24,7 +24,7 @@ There are two object abstractions: the "
- The Object Database (SHA1_FILE_DIRECTORY)
+ The Object Database (GIT_OBJECTS)
The object database is literally just a content-addressable collection
--- a/cache.h
+++ b/cache.h
@@ -31,6 +31,13 @@
#endif
/*
+ * Environment variables transition.
+ * We accept older names for now but warn.
+ */
+extern char *gitenv_bc(const char *);
+#define gitenv(e) (getenv(e) ? : gitenv_bc(e))
+
+/*
* Basic data structures for the directory cache
*
* NOTE NOTE NOTE! This is all in the native CPU byte format. It's
@@ -99,16 +106,16 @@ static inline unsigned int create_ce_mod
struct cache_entry **active_cache;
unsigned int active_nr, active_alloc, active_cache_changed;
-#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
+#define DB_ENVIRONMENT "GIT_OBJECTS"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
-#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
+#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECTS"
-#define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
+#define get_object_directory() (gitenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define DEFAULT_INDEX_ENVIRONMENT ".git/index"
-#define get_index_file() (getenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
+#define get_index_file() (gitenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
#define alloc_nr(x) (((x)+16)*3/2)
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -146,11 +146,11 @@ int main(int argc, char **argv)
datestamp(realdate, sizeof(realdate));
strcpy(date, realdate);
- commitgecos = getenv("COMMIT_AUTHOR_NAME") ? : realgecos;
- commitemail = getenv("COMMIT_AUTHOR_EMAIL") ? : realemail;
- gecos = getenv("AUTHOR_NAME") ? : realgecos;
- email = getenv("AUTHOR_EMAIL") ? : realemail;
- audate = getenv("AUTHOR_DATE");
+ commitgecos = gitenv("GIT_COMMIT_AUTHOR_NAME") ? : realgecos;
+ commitemail = gitenv("GIT_COMMIT_AUTHOR_EMAIL") ? : realemail;
+ gecos = gitenv("GIT_AUTHOR_NAME") ? : realgecos;
+ email = gitenv("GIT_AUTHOR_EMAIL") ? : realemail;
+ audate = gitenv("GIT_AUTHOR_DATE");
if (audate)
parse_date(audate, date, sizeof(date));
--- a/diff.c
+++ b/diff.c
@@ -8,11 +8,11 @@
#include "cache.h"
#include "diff.h"
-static char *diff_opts = "-pu";
+static const char *diff_opts = "-pu";
static const char *external_diff(void)
{
- static char *external_diff_cmd = NULL;
+ static const char *external_diff_cmd = NULL;
static int done_preparing = 0;
if (done_preparing)
@@ -26,11 +26,11 @@ static const char *external_diff(void)
*
* GIT_DIFF_OPTS="-c";
*/
- if (getenv("GIT_EXTERNAL_DIFF"))
- external_diff_cmd = getenv("GIT_EXTERNAL_DIFF");
+ if (gitenv("GIT_EXTERNAL_DIFF"))
+ external_diff_cmd = gitenv("GIT_EXTERNAL_DIFF");
/* In case external diff fails... */
- diff_opts = getenv("GIT_DIFF_OPTS") ? : diff_opts;
+ diff_opts = gitenv("GIT_DIFF_OPTS") ? : diff_opts;
done_preparing = 1;
return external_diff_cmd;
--- a/git-prune-script
+++ b/git-prune-script
@@ -28,9 +28,13 @@ sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
- case "$SHA1_FILE_DIRECTORY" in
+ for d in "$GIT_OBJECTS" "$SHA1_FILE_DIRECTORY" ''
+ do
+ test "$d" != "" && test -d "$d" && break
+ done
+ case "$d" in
'') cd .git/objects/ ;;
- *) cd "$SHA1_FILE_DIRECTORY" ;;
+ *) cd "$d" ;;
esac || exit
xargs -r $dryrun rm -f
}
Created: gitenv.c (mode:100644)
--- /dev/null
+++ b/gitenv.c
@@ -0,0 +1,70 @@
+#include "cache.h"
+
+/*
+ * This array must be sorted by its canonical name, because
+ * we do look-up by binary search.
+ */
+static struct backward_compatible_env {
+ const char *canonical;
+ const char *old;
+} bc_name[] = {
+ { "GIT_ALTERNATE_OBJECTS", "SHA1_FILE_DIRECTORIES" },
+ { "GIT_AUTHOR_DATE", "AUTHOR_DATE" },
+ { "GIT_AUTHOR_EMAIL", "AUTHOR_EMAIL" },
+ { "GIT_AUTHOR_NAME", "AUTHOR_NAME" },
+ { "GIT_COMMIT_AUTHOR_EMAIL", "COMMIT_AUTHOR_EMAIL" },
+ { "GIT_COMMIT_AUTHOR_NAME", "COMMIT_AUTHOR_NAME" },
+ { "GIT_OBJECTS", "SHA1_FILE_DIRECTORY" },
+};
+
+static void warn_old_environment(void)
+{
+ int i;
+ static int warned = 0;
+ if (warned)
+ return;
+
+ warned = 1;
+ fprintf(stderr,
+ "warning: GIT environment variables have been renamed.\n"
+ "warning: Please adjust your scripts and environment.\n");
+ for (i = 0; i < sizeof(bc_name) / sizeof(bc_name[0]); i++) {
+ /* warning is needed only when old name is there and
+ * new name is not.
+ */
+ if (!getenv(bc_name[i].canonical) && getenv(bc_name[i].old))
+ fprintf(stderr, "warning: old %s => new %s\n",
+ bc_name[i].old, bc_name[i].canonical);
+ }
+}
+
+char *gitenv_bc(const char *e)
+{
+ int first, last;
+ char *val = getenv(e);
+ if (val)
+ /* inefficient. caller should use gitenv() not gitenv_bc() */
+ return val;
+
+ first = 0;
+ last = sizeof(bc_name) / sizeof(bc_name[0]);
+ while (last > first) {
+ int next = (last + first) >> 1;
+ int cmp = strcmp(e, bc_name[next].canonical);
+ if (!cmp) {
+ val = getenv(bc_name[next].old);
+ /* If the user has only old name, warn.
+ * otherwise stay silent.
+ */
+ if (val)
+ warn_old_environment();
+ return val;
+ }
+ if (cmp < 0) {
+ last = next;
+ continue;
+ }
+ first = next+1;
+ }
+ return NULL;
+}
--- a/init-db.c
+++ b/init-db.c
@@ -5,7 +5,7 @@
*/
#include "cache.h"
-void safe_create_dir(char *dir)
+void safe_create_dir(const char *dir)
{
if (mkdir(dir, 0755) < 0) {
if (errno != EEXIST) {
@@ -23,12 +23,13 @@ void safe_create_dir(char *dir)
*/
int main(int argc, char **argv)
{
- char *sha1_dir, *path;
+ const char *sha1_dir;
+ char *path;
int len, i;
safe_create_dir(".git");
- sha1_dir = getenv(DB_ENVIRONMENT);
+ sha1_dir = gitenv(DB_ENVIRONMENT);
if (!sha1_dir) {
sha1_dir = DEFAULT_DB_ENVIRONMENT;
fprintf(stderr, "defaulting to local storage area\n");
--- a/rsh.c
+++ b/rsh.c
@@ -36,8 +36,8 @@ int setup_connection(int *fd_in, int *fd
*(path++) = '\0';
/* ssh <host> 'cd /<path>; stdio-pull <arg...> <commit-id>' */
snprintf(command, COMMAND_SIZE,
- "cd /%s; SHA1_FILE_DIRECTORY=objects %s",
- path, remote_prog);
+ "cd /%s; %s=objects %s",
+ path, DB_ENVIRONMENT, remote_prog);
posn = command + strlen(command);
for (i = 0; i < rmt_argc; i++) {
*(posn++) = ' ';
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -120,7 +120,7 @@ static void fill_sha1_path(char *pathbuf
*
* Also note that this returns the location for creating. Reading
* SHA1 file can happen from any alternate directory listed in the
- * SHA1_FILE_DIRECTORIES environment variable if it is not found in
+ * DB_ENVIRONMENT environment variable if it is not found in
* the primary object database.
*/
char *sha1_file_name(const unsigned char *sha1)
@@ -128,7 +128,7 @@ char *sha1_file_name(const unsigned char
static char *name, *base;
if (!base) {
- char *sha1_file_directory = get_object_directory();
+ const char *sha1_file_directory = get_object_directory();
int len = strlen(sha1_file_directory);
base = xmalloc(len + 60);
memcpy(base, sha1_file_directory, len);
@@ -151,7 +151,7 @@ static struct alternate_object_database
* alt_odb points at an array of struct alternate_object_database.
* This array is terminated with an element that has both its base
* and name set to NULL. alt_odb[n] comes from n'th non-empty
- * element from colon separated $SHA1_FILE_DIRECTORIES environment
+ * element from colon separated ALTERNATE_DB_ENVIRONMENT environment
* variable, and its base points at a statically allocated buffer
* that contains "/the/directory/corresponding/to/.git/objects/...",
* while its name points just after the slash at the end of
@@ -167,7 +167,7 @@ static void prepare_alt_odb(void)
int pass, totlen, i;
const char *cp, *last;
char *op = 0;
- const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
+ const char *alt = gitenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
/* The first pass counts how large an area to allocate to
* hold the entire alt_odb structure, including array of
^ permalink raw reply
* Re: [darcs-users] Re: Git-aware Darcs: a tutorial
From: Juliusz Chroboczek @ 2005-05-09 19:41 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: darcs-devel, darcs-users, Git Mailing List
In-Reply-To: <427FA400.2060408@zytor.com>
>> Darcs-git is a branch of Darcs that can work with Git repositories.
> How is it, performance-wise?
It depends very much on the command, but in general it's no faster
than plain Darcs right now, except for accessing the working
directory when you have an up-to-date cache. The nice thing, of
course, is that since Darcs-git works on pure Git repositories, you
can always switch to using plain Git commands when an operation is
likely to be too slow, as I've done in the example above.
(Editor's note: ``Patch'' is Darcs-speak for what BK calls a Changeset.)
Commands that only touch the working dir and the top of the history --
darcs what, darcs record, and so on -- are relatively fast; unlike the
native Git equivalents, they stat every file in your tree (I'll be
fixing this RSN), but they don't touch the contents of unchanged
files. Darcs whatsnew on a full kernel takes 4s on my machine.
Commands that read history (darcs changes, darcs send, darcs push) are
very fast until they encounter a merge, as they need to read the full
contents of one of the two branches (just the changed files, of
course). In practice, that means that doing |darcs whatsnew| gets me
the last 90 patches in Linux' history in a few seconds, then stalls.
I've tried to track the problem down, but after an afternoon of work I
had gotten no further. (I've explained the issue in excruciating
detail on Darcs-Devel, if you're interested.)
Commands that push patches around scale rather badly with the amount
of files touched by a patch. In practice, this means that you'll be
able to push around all patches in a kernel tree in a reasonable time,
except for the initial commit (220MB of touched files), which you can
only push using the native Git tools.
And then there is what I consider as the actual showstopper: darcs diff
is completely brain-damaged (very much so in plain Darcs, even more so
in Darcs-git). It needs a complete rewrite.
Juliusz
^ permalink raw reply
* Re: History messup
From: H. Peter Anvin @ 2005-05-09 19:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, git, Linus Torvalds
In-Reply-To: <1115665598.12012.422.camel@baythorne.infradead.org>
David Woodhouse wrote:
>
> 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.
>
I'm particularly thinking of when you copy and clone directories, you
have to define your semantics more specifically. When do you want to
*copy* this ID, and when do you want to make sure a new one is created?
One possible answer to that is to have .git/repoid and have it
auto-created (from /dev/urandom) if it doesn't exist, but I also observe
that at least two people (davem and pavel) have managed to clone "Linus'
kernel tree" as their description on http://www.kernel.org/git/ ...
-hpa
^ permalink raw reply
* Re: History messup
From: David Woodhouse @ 2005-05-09 19:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: tglx, git, Linus Torvalds
In-Reply-To: <427FB3A7.8050906@zytor.com>
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.
--
dwmw2
^ permalink raw reply
* Re: History messup
From: H. Peter Anvin @ 2005-05-09 19:01 UTC (permalink / raw)
To: tglx; +Cc: David Woodhouse, git, Linus Torvalds
In-Reply-To: <1115660903.19236.39.camel@tglx>
Thomas Gleixner wrote:
>
> That would be really great. A line after "parents" like
>
> repoid "username/reponame"
>
> would be sufficient
>
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.
-hpa
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-09 18:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sean, Linus Torvalds, git
In-Reply-To: <427FA5FD.1050000@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> Sean wrote:
>> What about creating a transition plan that uses the GIT_ name if it
>> exists
>> and the SHA1_ name if it doesn't. And mark the SHA1_ name as depreciated.
>> That should be okay to do this week, no?
>>
HPA> Should work.
Thanks, both Sean and H. Peter. Would cook something up.
^ permalink raw reply
* Re: Prototype git commit viewer
From: Krzysztof Halasa @ 2005-05-09 18:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17022.49021.344841.79940@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Over the weekend I hacked up a prototype viewer for git commits in
> Tk. It's called gitk and is at:
>
> http://ozlabs.org/~paulus/gitk
Nice. I wonder how well would it work with a longer history, say all
linux-2.[56] data. It takes gitk ~ 10 seconds to read ~ 1000 Linux
commits from cache now, on my system.
In fact I'm thinking about something working with WWW browser. I've
written a very simple experimental show-tree tool in C and it seems
reading current Linux tree (no HTTP output yet) takes 0.065s with it.
Now I'm thinking about output language. (X)HTML seems to be not
capable (I'm not HTML expert, please correct me if I'm wrong).
Any idea of what can I use?
(will post the source if there is interest)
--
Krzysztof Halasa
^ permalink raw reply
* "git-checkout-cache -f -a" failure
From: Morten Welinder @ 2005-05-09 18:25 UTC (permalink / raw)
To: GIT Mailing List, Linus Torvalds
git-checkout-cache is having problems when files change from directories to
plain files or vice versa. cg-seek seems to be similarly affected.
Note also, that git-checkout-cache's error messages haven't caught up with
the command renaming.
Morten
cd /tmp
mkdir xxx
cd xxx
rm -rf .git empty yyy
touch empty
cg-init </dev/null
cg-tag initial
mkdir yyy
touch yyy/zzz
cg-add yyy/zzz
cg-commit </dev/null
cg-tag dir
rm -rf empty yyy
rm -f .git/HEAD
cat .git/refs/tags/initial > .git/HEAD
git-read-tree -m HEAD
git-checkout-cache -f -a
touch yyy
cg-add yyy
cg-commit </dev/null
cg-tag file
# Got that?
# yyy is a file right now.
git-read-tree `cat .git/refs/tags/dir`
git-checkout-cache -f -a
# error: checkout-cache: unable to create file yyy/zzz (Not a directory)
# Not good!
rm -rf empty yyy
git-read-tree `cat .git/refs/tags/dir`
git-checkout-cache -f -a
# yyy is a directory right now
git-read-tree `cat .git/refs/tags/file`
git-checkout-cache -f -a
# error: checkout-cache: unable to create file yyy (Is a directory)
# Not good!
^ permalink raw reply
* Re: Howto get repository up2date after pull with touching as less as possible files in the working directory
From: Petr Baudis @ 2005-05-09 18:18 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050509174951.GK24216@cip.informatik.uni-erlangen.de>
Dear diary, on Mon, May 09, 2005 at 07:49:51PM CEST, I got a letter
where Thomas Glanzmann <sithglan@stud.uni-erlangen.de> told me that...
> Hello alltogether,
> at the moment I ensrure that there are no dirty files before the pull
> and do a
>
> git-read-tree HEAD
> git-checkout -a -f
> git-update-cache --refresh
>
> this is suboptimal because all the files in my working directory get a
> new timestamp and if I call make everything is recompiled (ccache helps,
> but is not the solution to this problem).
Do git-read-tree -m HEAD instead. That will keep the original stat
information and checkout will rewrite only files it needs to.
--
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] Introduce SHA1_FILE_DIRECTORIES
From: H. Peter Anvin @ 2005-05-09 18:03 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <3087.10.10.10.24.1115656919.squirrel@linux1>
Sean wrote:
>
> What about creating a transition plan that uses the GIT_ name if it exists
> and the SHA1_ name if it doesn't. And mark the SHA1_ name as depreciated.
> That should be okay to do this week, no?
>
Should work.
-hpa
^ permalink raw reply
* Re: History messup
From: Thomas Gleixner @ 2005-05-09 18:05 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, David Woodhouse, Linus Torvalds
In-Reply-To: <20050509170611.GJ24216@cip.informatik.uni-erlangen.de>
On Mon, 2005-05-09 at 19:06 +0200, Thomas Glanzmann wrote:
> If two repositories pull alternating from each other one has never the
> exact state the other has. They would play ping-pong and this is a bad
> thing. That was AFAIK the reason there is no COMMIT object introduced on
> 'head forward' merges.
That makes totaly sense, but for history tracking it is a horror
scenario, unless you dont have head history lists per repository or an
unique repository identifier in the commit blob itself.
tglx
^ permalink raw reply
* Darcs-git: a few notes for Git hackers
From: Juliusz Chroboczek @ 2005-05-09 18:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: darcs-devel
Hi,
Here are a few notes about Git that should probably be taken into
account by people working on Git itself or on Git wrappers. The notes
apply to Linus' Git-0.6, which is the code I'm using in Darcs-git;
some of them might no longer be applicable to Darcs.
1. Darcs-git uses the fact that Git updates are atomic when reading
from a Git repository. Darcs-git almost writes to Git repositories
atomically, with one exception: it performs a non-atomic
read/update/write cycle on .git/HEAD.
For that reason, I'm taking a high-level lock on .git repositories
whenever I write them. The lockfile is ``.git/lock''. I haven't
thought about whether Darcs can be easily coerced into accessing Git
repos atomically; have people writing Git wrappers found the need for
a global lock?
2. The files git.h and git.c in Darcs-git are a simple ``libgit'' that
contains just enough functionality for Darcs-git; they use the
functionality of sha1_file.c and read_cache.c from Git-0.6.
I've found a few problems with the interfaces in these files:
- the global variables sha1_file_directory, active_cache, active_nr
and active_alloc are not marked ``extern'' in cache.h. This breaks
linkers that don't grok common symbols, such as the one in GHCi
(silly GHCi).
- the function write_sha1_file takes the metadata and the data in a
contiguous buffer, which is a problem when the data has been
allocated by a higher layer. I'm currently working around the
problem by memcpy-ing everything into a temp buffer, but that's
obviously not a good thing. I don't care whether write_sha1_file
is changed to use a writev-like interface, or to take the metadata
explicitly (as in char *type, unsigned long length).
- there is no (usable) function to write a tree; there's the code in
write_tree.c, but it's not generally useful. See the function
``git_write_tree_done'' in git.c for the type of interface I'm
thinking of.
- there's no way to have multiple simultaneous caches, short of
hacking at the values of Git's global variables by hand.
As I'd rather not maintain my own version of Git, I'd be mighty
grateful if some friendly Git hacker could fix the above.
Juliusz
^ permalink raw reply
* Re: Git-aware Darcs: a tutorial
From: H. Peter Anvin @ 2005-05-09 17:55 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, darcs-users, Git Mailing List
In-Reply-To: <7i4qdc8isd.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek wrote:
> 0. What is Darcs-git
>
> Darcs-git is a branch of Darcs that can work with Git repositories.
>
> Darcs-git is deliberately Darcs, not Git. All commands either work in
> the same way on Git repositories as on Darcs repositories, or they
> fail. If you're a Darcs user, you'll like darcs-git. If you're a Git
> user, you'll probably find it infuriating.
>
> On the other hand, Darcs-git uses stock Git repositories; a Darcs
> command either works as-is on a Git repository, or fails.
>
How is it, performance-wise?
-hpa
^ permalink raw reply
* Howto get repository up2date after pull with touching as less as possible files in the working directory
From: Thomas Glanzmann @ 2005-05-09 17:49 UTC (permalink / raw)
To: GIT
Hello alltogether,
at the moment I ensrure that there are no dirty files before the pull
and do a
git-read-tree HEAD
git-checkout -a -f
git-update-cache --refresh
this is suboptimal because all the files in my working directory get a
new timestamp and if I call make everything is recompiled (ccache helps,
but is not the solution to this problem).
So what is the right way to touch *only* the files which are dirty. Are
there any shortcuts? Or should I call 'git dirty' pipe that to
git-checkout -f?
Thomas
^ permalink raw reply
* Re: History messup
From: Thomas Gleixner @ 2005-05-09 17:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: git, Linus Torvalds
In-Reply-To: <1115659677.16187.393.camel@hades.cambridge.redhat.com>
On Mon, 2005-05-09 at 18:27 +0100, David Woodhouse wrote:
> On Mon, 2005-05-09 at 16:59 +0000, Thomas Gleixner wrote:
> It's normal practice, and it _has_ to be the case. Otherwise the trees
> would never stabilise -- every time Linus pulled from my tree he would
> create a merge-commit which I don't yet have, and vice versa.
Sure
> Unless a commit also carries a unique repo-id identifying the repository
> in which it originally occurred, you'll only ever be able to track
> history in the way people want by means of heuristics.
That would be really great. A line after "parents" like
repoid "username/reponame"
would be sufficient
tglx
^ permalink raw reply
* Re: kernel.org upgraded to cogito-0.10
From: Kay Sievers @ 2005-05-09 17:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jan-Benedict Glaw, Git Mailing List
In-Reply-To: <427F7FEF.7040406@zytor.com>
On Mon, 2005-05-09 at 08:21 -0700, H. Peter Anvin wrote:
> Jan-Benedict Glaw wrote:
> > On Mon, 2005-05-09 07:17:24 -0700, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> >>I have installed cogito-0.10 on the kernel.org machines.
Very nice!
> > ...and you'd probably revert or fix the bug(s) that make all project's
> > logs look quite empty at http://www.kernel.org/git ...
> >
>
> Kay has a new version of the git web client which is needed for the new
> version... Kay?
The new version of gitweb is installed now.
Kay
^ permalink raw reply
* Re: History messup
From: David Woodhouse @ 2005-05-09 17:27 UTC (permalink / raw)
To: tglx; +Cc: git, Linus Torvalds
In-Reply-To: <1115657971.19236.33.camel@tglx>
On Mon, 2005-05-09 at 16:59 +0000, Thomas Gleixner wrote:
> David merged from Linus repository . Linus synced later with David.
> Linus did not create a new commit for this update and just pointed his
> "HEAD" to Davids "HEAD", which means he forked Davids repository at
> this point.
>
> Due to that the parent->parent history is not longer unique. This
> makes it impossible to do file revision graphs over the various
> repositories in the correct order.
>
> Is this a unique problem or is the omission of a commit in cases like
> that usual practice ? In the latter case proper history tracking is
> almost impossible.
It's normal practice, and it _has_ to be the case. Otherwise the trees
would never stabilise -- every time Linus pulled from my tree he would
create a merge-commit which I don't yet have, and vice versa.
Unless a commit also carries a unique repo-id identifying the repository
in which it originally occurred, you'll only ever be able to track
history in the way people want by means of heuristics.
--
dwmw2
^ 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