* rsync deprecated but promoted?
From: Zack Brown @ 2005-09-25 16:32 UTC (permalink / raw)
To: git
Hi folks,
When I use cogito, it gives a warning saying the rsync method is deprecated and
will be removed in the future. But when I visit kernel.org/git, the page says to
use an rsync URL with cg-clone.
Maybe kernel.org should be updated?
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-25 16:59 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509241526180.3308@g5.osdl.org>
On Sat, 24 Sep 2005, Linus Torvalds wrote:
>
> Anyway, regardless, we could certainly make HEAD be a regular file
> containing the name of the head instead.
>
> It probably wouldn't even require a whole lot of changes. HEAD already
> ends up getting some special attention, since most of the things that look
> for refs only look inside the .git/refs directory.
This patch does some of it. I decided not to special-case HEAD, but to
just improve "read_ref()" a bit.
Changing "read_ref()" was the trivial part - the bigger part that we had
three different implementations of it, and this patch is thus bigger just
because it collapses them all into "read_ref()" and makes the calling
conventions acceptable to all.
NOTE! This makes "symbolic refs" usable in general, ie you can do
echo "ref: refs/tags/v0.99.7" > .git/refs/tags/LATEST
and that essentially makes "LATEST" a symbolic ref that points to the
v0.99.7 tag without using a filesystem symlink. But it does NOT mean that
you can replace the HEAD symlink with a file containing "refs/tags/master"
yet: there are _other_ parts of git that depend on it being a symlink.
(For the most core example, the "write new head" logic depends on just
writing to HEAD, and that symlink will automatically change that write to
the thing the HEAD _points_ to. That's the biggest one).
I'll change those too to accept a regular file, if people agree this is
worthwhile. In theory there are even UNIXes out there that don't support
symlinks, so maybe it's worth it. But maybe people dislike this.
In the meantime, you can test this out with
echo "ref: HEAD" > .git/TEST_HEAD
git-rev-parse HEAD TEST_HEAD master
which - if your HEAD points to master - should print out the same SHA1
three times ;)
Linus
---
Subject: Allow reading "symbolic refs" that point to other refs
This extends the ref reading to understand a "symbolic ref": a ref file
that starts with "ref: " and points to another ref file, and thus
introduces the notion of ref aliases.
This is in preparation of allowing HEAD to eventually not be a symlink,
but one of these symbolic refs instead.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -227,6 +227,7 @@ extern int has_pack_index(const unsigned
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
+extern int read_ref(const char *filename, unsigned char *sha1);
/* General helper functions */
extern void usage(const char *err) NORETURN;
diff --git a/refs.c b/refs.c
--- a/refs.c
+++ b/refs.c
@@ -2,17 +2,38 @@
#include "cache.h"
#include <errno.h>
+#include <ctype.h>
-static int read_ref(const char *refname, unsigned char *sha1)
+/* We allow "recursive" symbolic refs. Only within reason, though */
+#define MAXDEPTH 5
+
+int read_ref(const char *filename, unsigned char *sha1)
{
- int ret = -1;
- int fd = open(git_path("%s", refname), O_RDONLY);
+ int depth = 0;
+ int ret = -1, fd;
+
+ while ((fd = open(filename, O_RDONLY)) >= 0) {
+ char buffer[256];
+ int len = read(fd, buffer, sizeof(buffer)-1);
- if (fd >= 0) {
- char buffer[60];
- if (read(fd, buffer, sizeof(buffer)) >= 40)
- ret = get_sha1_hex(buffer, sha1);
close(fd);
+ if (len < 0)
+ break;
+
+ buffer[len] = 0;
+ while (len && isspace(buffer[len-1]))
+ buffer[--len] = 0;
+
+ if (!strncmp(buffer, "ref: ", 5)) {
+ if (depth > MAXDEPTH)
+ break;
+ depth++;
+ filename = git_path("%s", buffer+5);
+ continue;
+ }
+ if (len >= 40)
+ ret = get_sha1_hex(buffer, sha1);
+ break;
}
return ret;
}
@@ -54,7 +75,7 @@ static int do_for_each_ref(const char *b
break;
continue;
}
- if (read_ref(path, sha1) < 0)
+ if (read_ref(git_path("%s", path), sha1) < 0)
continue;
if (!has_sha1_file(sha1))
continue;
@@ -71,7 +92,7 @@ static int do_for_each_ref(const char *b
int head_ref(int (*fn)(const char *path, const unsigned char *sha1))
{
unsigned char sha1[20];
- if (!read_ref("HEAD", sha1))
+ if (!read_ref(git_path("HEAD"), sha1))
return fn("HEAD", sha1);
return 0;
}
@@ -101,33 +122,14 @@ static char *ref_lock_file_name(const ch
return ret;
}
-static int read_ref_file(const char *filename, unsigned char *sha1) {
- int fd = open(filename, O_RDONLY);
- char hex[41];
- if (fd < 0) {
- return error("Couldn't open %s\n", filename);
- }
- if ((read(fd, hex, 41) < 41) ||
- (hex[40] != '\n') ||
- get_sha1_hex(hex, sha1)) {
- error("Couldn't read a hash from %s\n", filename);
- close(fd);
- return -1;
- }
- close(fd);
- return 0;
-}
-
int get_ref_sha1(const char *ref, unsigned char *sha1)
{
- char *filename;
- int retval;
+ const char *filename;
+
if (check_ref_format(ref))
return -1;
- filename = ref_file_name(ref);
- retval = read_ref_file(filename, sha1);
- free(filename);
- return retval;
+ filename = git_path("refs/%s", ref);
+ return read_ref(filename, sha1);
}
static int lock_ref_file(const char *filename, const char *lock_filename,
@@ -140,7 +142,7 @@ static int lock_ref_file(const char *fil
return error("Couldn't open lock file for %s: %s",
filename, strerror(errno));
}
- retval = read_ref_file(filename, current_sha1);
+ retval = read_ref(filename, current_sha1);
if (old_sha1) {
if (retval) {
close(fd);
diff --git a/sha1_name.c b/sha1_name.c
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -119,21 +119,6 @@ static int get_short_sha1(const char *na
return -1;
}
-static int get_sha1_file(const char *path, unsigned char *result)
-{
- char buffer[60];
- int fd = open(path, O_RDONLY);
- int len;
-
- if (fd < 0)
- return -1;
- len = read(fd, buffer, sizeof(buffer));
- close(fd);
- if (len < 40)
- return -1;
- return get_sha1_hex(buffer, result);
-}
-
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
static const char *prefix[] = {
@@ -150,7 +135,7 @@ static int get_sha1_basic(const char *st
for (p = prefix; *p; p++) {
char *pathname = git_path("%s/%.*s", *p, len, str);
- if (!get_sha1_file(pathname, sha1))
+ if (!read_ref(pathname, sha1))
return 0;
}
^ permalink raw reply
* Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-25 17:00 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0509250854570.22725@localhost.localdomain>
On Sun, 25 Sep 2005, Davide Libenzi wrote:
>
> What you'd have to do, if you chose to use diffutils stuff, is to
> transform the main() of diff in diff_main(), use setjmp/longjmp to capture
> its exit()s, and make it use a proper allocator (if you want to avoid
> leaks upon aborts).
I'd love to use libxdiff instead since you say it can do it, but quite
frankly, the man-page didn't much help me. Do you have an example of how
to generate a uni-diff with it? Something that mortal men can read and say
"oh"?
Linus
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: H. Peter Anvin @ 2005-09-25 17:07 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050925163201.GA29198@tumblerings.org>
Zack Brown wrote:
> Hi folks,
>
> When I use cogito, . it gives a warning saying the rsync method is deprecated and
> will be removed in the future. But when I visit kernel.org/git, the page says to
> use an rsync URL with cg-clone.
>
> Maybe kernel.org should be updated?
No, since it's currently the only method available to the general
public. git-daemon still needs some tweaking before I trust to enable
it; I've been meaning to do this but I've been personally very busy.
-hpa
^ permalink raw reply
* Add "git-update-ref" to update the HEAD (or other) ref
From: Linus Torvalds @ 2005-09-25 18:43 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Davide Libenzi
This is a careful version of the script stuff that currently just
blindly writes HEAD with a new value.
You can use
git-update-ref HEAD <newhead>
or
git-update-ref HEAD <newhead> <oldhead>
where the latter version verifies that the old value of HEAD matches
oldhead.
It basically allows a "ref" file to be a symbolic pointer to another ref
file by starting with the four-byte header sequence of "ref:".
More importantly, it allows the update of a ref file to follow these
symbolic pointers, whether they are symlinks or these "regular file
symbolic refs".
NOTE! It follows _real_ symlinks only if they start with "refs/":
otherwise it will just try to read them and update them as a regular file
(ie it will allow the filesystem to follow them, but will overwrite such a
symlink to somewhere else with a regular filename).
In general, using
git-update-ref HEAD "$head"
should be a _lot_ safer than doing
echo "$head" > "$GIT_DIR/HEAD"
both from a symlink following standpoint _and_ an error checking
standpoint. The "refs/" rule for symlinks means that symlinks that point
to "outside" the tree are safe: they'll be followed for reading but not
for writing (so we'll never write through a ref symlink to some other
tree, if you have copied a whole archive by creating a symlink tree).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is independent of my previous patch, but in the same basic series. It
is useful regardless of whether you use the new symbolic refs or not
because of the much improved error checking.
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -114,6 +114,7 @@ PROGRAMS = \
git-ssh-upload git-tar-tree git-unpack-file \
git-unpack-objects git-update-index git-update-server-info \
git-upload-pack git-verify-pack git-write-tree \
+ git-update-ref \
$(SIMPLE_PROGRAMS)
# Backward compatibility -- to be removed in 0.99.8
diff --git a/update-ref.c b/update-ref.c
new file mode 100644
--- /dev/null
+++ b/update-ref.c
@@ -0,0 +1,124 @@
+#include "cache.h"
+#include "refs.h"
+
+static const char git_update_ref_usage[] = "git-update-ref <refname> <value> [<oldval>]";
+
+#define MAXDEPTH 5
+
+const char *resolve_ref(const char *path, unsigned char *sha1)
+{
+ int depth = MAXDEPTH, len;
+ char buffer[256];
+
+ for (;;) {
+ struct stat st;
+ char *buf;
+ int fd;
+
+ if (--depth < 0)
+ return NULL;
+
+ /* Special case: non-existing file */
+ if (lstat(path, &st) < 0) {
+ if (errno != ENOENT)
+ return NULL;
+ memset(sha1, 0, 20);
+ return path;
+ }
+
+ /* Follow "normalized" - ie "refs/.." symlinks by hand */
+ if (S_ISLNK(st.st_mode)) {
+ len = readlink(path, buffer, sizeof(buffer)-1);
+ if (len >= 5 && !memcmp("refs/", buffer, 5)) {
+ path = git_path("%.*s", len, buffer);
+ continue;
+ }
+ }
+
+ /*
+ * Anything else, just open it and try to use it as
+ * a ref
+ */
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return NULL;
+ len = read(fd, buffer, sizeof(buffer)-1);
+ close(fd);
+
+ /*
+ * Is it a symbolic ref?
+ */
+ if (len < 4 || memcmp("ref:", buffer, 4))
+ break;
+ buf = buffer + 4;
+ len -= 4;
+ while (len && isspace(*buf))
+ buf++, len--;
+ while (len && isspace(buf[len-1]))
+ buf[--len] = 0;
+ path = git_path("%.*s", len, buf);
+ }
+ if (len < 40 || get_sha1_hex(buffer, sha1))
+ return NULL;
+ return path;
+}
+
+int main(int argc, char **argv)
+{
+ char *hex;
+ const char *refname, *value, *oldval, *path, *lockpath;
+ unsigned char sha1[20], oldsha1[20], currsha1[20];
+ int fd, written;
+
+ setup_git_directory();
+ if (argc < 3 || argc > 4)
+ usage(git_update_ref_usage);
+
+ refname = argv[1];
+ value = argv[2];
+ oldval = argv[3];
+ if (get_sha1(value, sha1) < 0)
+ die("%s: not a valid SHA1", value);
+ memset(oldsha1, 0, 20);
+ if (oldval && get_sha1(oldval, oldsha1) < 0)
+ die("%s: not a valid old SHA1", oldval);
+
+ path = resolve_ref(git_path("%s", refname), currsha1);
+ if (!path)
+ die("No such ref: %s", refname);
+
+ if (oldval) {
+ if (memcmp(currsha1, oldsha1, 20))
+ die("Ref %s changed to %s", refname, sha1_to_hex(currsha1));
+ /* Nothing to do? */
+ if (!memcmp(oldsha1, sha1, 20))
+ exit(0);
+ }
+ path = strdup(path);
+ lockpath = mkpath("%s.lock", path);
+
+ fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
+ if (fd < 0)
+ die("Unable to create %s", lockpath);
+ hex = sha1_to_hex(sha1);
+ hex[40] = '\n';
+ written = write(fd, hex, 41);
+ close(fd);
+ if (written != 41) {
+ unlink(lockpath);
+ die("Unable to write to %s", lockpath);
+ }
+
+ /*
+ * FIXME!
+ *
+ * We should re-read the old ref here, and re-verify that it
+ * matches "oldsha1". Otherwise there's a small race.
+ */
+
+ if (rename(lockpath, path) < 0) {
+ unlink(lockpath);
+ die("Unable to create %s", path);
+ }
+ return 0;
+}
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-25 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vll1lr1bq.fsf@assigned-by-dhcp.cox.net>
I said:
> * The fourth minor fix release, GIT 0.99.7d, is available at the
> usual places.
>
> With git:
>
> $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
> $ git checkout -b <new-branch> v0.99.7d
If you pick a suitable name as <new-branch> that the repository
in which you keep track git.git does not yet have, "maint997" for
example, and if your working tree is identical to whatever your
HEAD happens to be, then the above instruction should be read as:
$ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
$ git checkout -b maint997 v0.99.7d
and that would give you the exact contents of v0.99.7d in your
working tree.
But this was really a stupid way to give instructions, and would
probably have caused confusion. Sorry about that, if you were
one of the people who were bitten.
I deliberately did not say:
$ git pull http://kernel.org/pub/scm/git/git.git tag v0.99.7d
because the result would be affected by whatever the random
state the repository was in.
Folks using CVS seem to announce "A new release is available and
tagged as r0.99.7d", people seem to know what they need to do
when seeing that announcement ("cvs update -r r0.99.7d"), and
this command line, as long as the working tree tracks that
remote project CVS repository, would give more-or-less the same
result for everyone no matter what the original state of the
working tree was. GIT is a bit different in that branch names
are local and you do not really "check out a tag".
One straightforward way which would work for everybody would be
(provided you do not have git-src in the current directory):
$ git clone http://kernel.org/pub/scm/git/git.git git-src
$ cd git-src
$ git reset --hard v0.99.7d
This will give all the public branches and tags (renaming of
public "master" to "origin" is done by "git clone"), and match
your "master" to "v0.99.7d".
When you already have a repository to track git.git, I would
recommend to have something like this in .git/remote/origin:
URL: http://kernel.org/pub/scm/git/git.git
Pull: master:origin maint:maint +pu:pu
Then you can say:
$ git fetch origin tag v0.99.7d
This only updates your .git/refs/tags/v0.99.7d and downloads
necessary objects. To see them in your working tree (e.g. for
compilation), you would need to check it out.
Now, how would you check out the v0.99.7d tag? There are two
ways to think about it.
If the reason you want v0.99.7d, not "master" nor "pu", is you
would want to stay with the 0.99.7 but get all the latest safer
fixes, then you can just checkout "maint" branch instead, like
this:
$ git checkout -f maint
This will get you everything in the maintenance branch and may
contain fixes that happened after v0.99.7d -- you are taking my
0.99.7d announce as just a hint to say: "Junio has accumulated
enough maintenance fixes in the maint branch and tagged its tip".
And the announcement is just that. I try to make sure that what
are in the maint branch are just "safer fixes that do not break
existing setup", but I do not do any more special testing than
what I already do to make commits into the maint branch when I
tag the tip of it. In other words, the one that happens to be
tagged as 0.99.7d is not any safer than the next commit that
comes on the maint branch (there is none at this moment). The
later tip of the maint branch had better be more correct than
v0.99.7d -- that is what "fix" usually means ;-).
On the other hand, if the reason you want v0.99.7d is to point
out things broke at that exact commit, you would need to check
out that exact version, not just a random commit that happens to
be at the tip of maint. And you need a branch to check it out
onto in that case. Assuming that you do not have a branch
called "throwaway":
$ git checkout -f -b throwaway v0.99.7d
would give you the working tree that matches what is in v0.99.7d
and a new branch "throwaway" whose tip is the commit tagged as
v0.99.7d. The usual caveat applies: if your working tree and
index had changes since the HEAD commit you had before you did
the above checkout, that change may be lost with '-f' flag. But
the point of this checkout is to get what is in the named tag
exactly, you would want to lose them -- otherwise make a commit
to your branch, or stash away 'git diff HEAD' output, before
doing the checkout.
After that, if you want to see what v0.99.7c used to do, you
could (still remaining on the "throwaway" branch):
$ git reset --hard v0.99.7c
[jc: maybe somebody can send a patch to add the later part of
this message as Documentation/howto/checking-out-a-tag.txt ].
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Josef Weidendorfer @ 2005-09-25 18:56 UTC (permalink / raw)
To: git
In-Reply-To: <20050925070719.67119.qmail@web26309.mail.ukl.yahoo.com>
On Sunday 25 September 2005 09:07, Marco Costalba wrote:
> >> src/rangeselectbase.h QSettings: error creating /.qt
> >>QSettings: error creating /.qt
> ...
> QSettings are there from day one :-<
> I am not able to let them disappear.....very bad. In any case should be
> harmless.
These errors seam to appear because scons does NOT pass through the $HOME
environment variable to subprocesses. "moc", which is producing these
errors, obviously wants to access some config options in $HOME/.qt/.
Somebody knows how to change this?
Josef
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Linus Torvalds @ 2005-09-25 19:05 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509251134480.3308@g5.osdl.org>
On Sun, 25 Sep 2005, Linus Torvalds wrote:
>
> This is a careful version of the script stuff that currently just
> blindly writes HEAD with a new value.
Btw, in case it wasn't clear from the patch, this only introduced
mechanism, it didn't actually use it in any script.
But the point of the exercise is to move towards using git-update-ref in
places like git-fetch.sh, which currently are doing some of it by hand
(and not handling symlinks etc).
So you should be able to do something like
..
old=$(git-rev-parse --verify "$refname^0") >& /dev/null
if [ "$old" ]; then
mb=$(git-merge-base $new $old)
if [ "$mb" != "$old" ]; then
echo "$new is not a fast-forward of $old"
[ "$force" ] || exit 1
old=
fi
fi
git-update-ref "$refname" $new $old
and the actual update phase will re-verify that "old" is still valid (if
it exists at all).
Doing it by hand works, of course, but for example, if we have two
symlinks pointing to the same ref, the current locking in git-fetch.sh is
broken - it may lock the _symlink_, but since the other one _also_ points
to the same thing, there's no locking of the _target_.
git-update-ref should do things like that right. Famous last words ;)
Linus
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Martin Coxall @ 2005-09-25 19:06 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050925163201.GA29198@tumblerings.org>
On 25 Sep 2005, at 17:32, Zack Brown wrote:
> Hi folks,
>
> When I use cogito, it gives a warning saying the rsync method is
> deprecated and
> will be removed in the future. But when I visit kernel.org/git, the
> page says to
> use an rsync URL with cg-clone.
>
> Maybe kernel.org should be updated?
>
It does seem to be sending out a confusing message to us users too,
since an initial clone of Linus's tree with rsync is on my machine 10x
faster than an http clone, so it seems to be sending out something of a
confused/confusing message re: rsync.
Am I right in thinking it's because rsync didn't originally have pack
support, but now it does, Petr has simply forgotten to deprecate the
deprecation message?
Kind Regards,
Martin
^ permalink raw reply
* Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-25 19:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0509250959540.3308@g5.osdl.org>
On Sun, 25 Sep 2005, Linus Torvalds wrote:
> On Sun, 25 Sep 2005, Davide Libenzi wrote:
>>
>> What you'd have to do, if you chose to use diffutils stuff, is to
>> transform the main() of diff in diff_main(), use setjmp/longjmp to capture
>> its exit()s, and make it use a proper allocator (if you want to avoid
>> leaks upon aborts).
>
> I'd love to use libxdiff instead since you say it can do it, but quite
> frankly, the man-page didn't much help me. Do you have an example of how
> to generate a uni-diff with it? Something that mortal men can read and say
> "oh"?
Ahh, you looked at the docs. Don't do that ;) Take a look at the
test/xdiff_test.c for an example on how to use its most important APIs.
There is also a regression test (xregression) that create random files,
renadomly changes them, and then try that (A-B)+B=A and (B-A)+A=B (for
both text and binary). I'm dropping inline an example on how to text-diff ...
- Davide
#include "xmacros.h"
#include "xdiff.h"
#define XDLT_STD_BLKSIZE (1024 * 8)
static int xdlt_load_mmfile(char const *fname, mmfile_t *mf, int binmode) {
char cc;
int fd;
long size, bsize;
char *blk;
if (xdl_init_mmfile(mf, XDLT_STD_BLKSIZE, XDL_MMF_ATOMIC) < 0) {
return -1;
}
if ((fd = open(fname, O_RDONLY)) == -1) {
perror(fname);
xdl_free_mmfile(mf);
return -1;
}
if ((size = bsize = lseek(fd, 0, SEEK_END)) > 0 && !binmode) {
if (lseek(fd, -1, SEEK_END) != (off_t) -1 &&
read(fd, &cc, 1) && cc != '\n')
bsize++;
}
lseek(fd, 0, SEEK_SET);
if (!(blk = (char *) xdl_mmfile_writeallocate(mf, bsize))) {
xdl_free_mmfile(mf);
close(fd);
return -1;
}
if (read(fd, blk, (size_t) size) != (size_t) size) {
perror(fname);
xdl_free_mmfile(mf);
close(fd);
return -1;
}
close(fd);
if (bsize > size)
blk[size] = '\n';
return 0;
}
static int xdlt_outf(void *priv, mmbuffer_t *mb, int nbuf) {
int i;
for (i = 0; i < nbuf; i++)
if (!fwrite(mb[i].ptr, mb[i].size, 1, (FILE *) priv))
return -1;
return 0;
}
static void *wrap_malloc(void *priv, unsigned int size) {
return malloc(size);
}
static void wrap_free(void *priv, void *ptr) {
free(ptr);
}
static void *wrap_realloc(void *priv, void *ptr, unsigned int size) {
return realloc(ptr, size);
}
int sample_textdiff(char const *pre, char const *post, FILE *outf) {
int error;
memallocator_t malt;
mmfile_t mf1, mf2;
xpparam_t xpp;
xdemitconf_t xecfg;
xdemitcb_t ecb;
malt.priv = NULL;
malt.malloc = wrap_malloc;
malt.free = wrap_free;
malt.realloc = wrap_realloc;
xdl_set_allocator(&malt);
if (xdlt_load_mmfile(pre, &mf1, 0) < 0)
return -1;
if (xdlt_load_mmfile(post, &mf2, 0) < 0) {
xdl_free_mmfile(&mf1);
return -1;
}
xpp.flags = 0;
xecfg.ctxlen = 3;
ecb.priv = outf;
ecb.outf = xdlt_outf;
error = xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
xdl_free_mmfile(&mf2);
xdl_free_mmfile(&mf1);
return error;
}
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Josef Weidendorfer @ 2005-09-25 19:19 UTC (permalink / raw)
To: git
In-Reply-To: <20050925055259.50066.qmail@web26302.mail.ukl.yahoo.com>
Hi,
On Sunday 25 September 2005 07:52, Marco Costalba wrote:
> >* The commit time is relative to now, which makes no sense to me. Also,
> >it is in the second column instead of the last one like in gitk, which
> >seems better to me. At least, the column is too narrow and then it
> >blends together with the commit title.
I vote for absolute time, and the date column at the end, too.
Relative has no meaning when searching for an old commit.
Besides, QT allows to reorder the columns with the mouse (the order should be
saved in a config file at end to be persistant over program runs).
> >* Getting to the diff view was non-obvious for me. It'd be nice to have
> >some [diff] button as well somewhere. Or you could also show the diff in
> >the bottom part of screen in the commit view, I think gitk solved this
> >nicely.
>
> I have tought a lot how to pass to the user the information that to see a
> diff you have to double click on the commit:
I like the gitk solution better.
What about making the commit list a QDockWindow, which can be docked to either
side of the window (default: top as currently), but also made a floating
window, so that the commit diff gets the whole main window?
> commit changes as does the file revision content: "pin file" checkbox
> simply avoids the file viewer content to change, only main view is updated.
The "pin" action is really not-obvious. Why not open new windows for different
file annotations? Or one window with tabs for each file?
Perhaps make the main window contain commit diffs and file annotations in
tabs?
> Diagonal line could be nicer but doesn't leave you play some tricks to
> greatly speed up graph drawing. I really like those tricks ;-)
I think that diagonal lines as in gitk make it way easier to get an overview.
What makes drawing of diagonal lines slow?
It should be quite fast to subclass QListViewItem for commit entries and
overwrite QListViewItem::paintCell to use your own drawing; paintCell is
called for visible entries only.
Another wish: The tag/head markers in gitk are really good. In qgit, I only
get another background color, and miss the name.
You can do the same drawing as in gitk via paintCell, too.
> >Nice work otherwise. :-)
Yes, really nice.
Josef
^ permalink raw reply
* cogito push problem
From: Nico -telmich- Schottelius @ 2005-09-25 19:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Hello!
I was trying to push my current work out and recieved this error:
[21:20] hydrogenium:cinit% cg-push main
error: remote ref 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'.
My questions:
- What does that mean to me as an end-user?
- What's the reason that this happened?
- How do I fix that?
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: /bin/sh portability question
From: Nico -telmich- Schottelius @ 2005-09-25 19:26 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
In-Reply-To: <39450.10.10.10.28.1127471685.squirrel@linux1>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Sean [Fri, Sep 23, 2005 at 06:34:45AM -0400]:
> On Fri, September 23, 2005 5:19 am, Junio C Hamano said:
> > "Sean" <seanlkml@sympatico.ca> writes:
> >
> >> If not, would you accept a patch that first converted the shell scripts
> >> to
> >> #!/bin/bash and then added a "make install" option that allowed them to
> >> be
> >> replaced? Something like "make install S=/bin/ash" for instance?
> >
> > $ make SHELL_PATH=/bin/bash
> >
> > Perhaps?
> >
>
> Heh.. so you've already got that working :o) So on Solaris one fix would
> be to just use the SHELL_PATH setting when installing to point to
> /bin/bash. What do you think about making /bin/bash the default?
I think it's a bad idea, because some systems do not have and want bash,
because it's unneeded. On all systems here we've ash as /bin/sh and
/bin/zsh as primary user shell. Thus, /bin/bash does not exist, because
it's not as comfortable as zsh and not as small as ash.
Nico,
who really likes man bash (very well documentated), but not the shell itself
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: /bin/sh portability question
From: Sean @ 2005-09-25 19:36 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Junio C Hamano, git
In-Reply-To: <20050925192608.GD19023@schottelius.org>
On Sun, September 25, 2005 3:26 pm, Nico -telmich- Schottelius said:
> I think it's a bad idea, because some systems do not have and want bash,
> because it's unneeded. On all systems here we've ash as /bin/sh and
> /bin/zsh as primary user shell. Thus, /bin/bash does not exist, because
> it's not as comfortable as zsh and not as small as ash.
Hi Nico,
My guess is that your system configuration is in the minority and that
most target systems have bash installed today. But all you'd have to do
is make a link from /bin/zsh to /bin/bash, or use the SHELL_PATH variable
to change all the scripts to /bin/zsh at install time.
Sean
^ permalink raw reply
* ANNOTATION in qgit-0.95
From: Marco Costalba @ 2005-09-25 19:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Petr Baudis wrote:
I thought about your feedback on annotation:
>
>* Clicking on the file was supposed to bring some annotated view, but if
>it is so, it should write "Annotate" in the window title, and should
>indicate that it is computing it on the background (and is really slow
>in that, or I don't know, but always only single revision was shown
>there). It is unclear what the "pin file" checkbox is supposed to mean,
>and the whole dialog is just very confusing. :-)
>
and I think you peraphs have the flag
edit->settings->general->'load file names in background' unset.
Currently annotation filters out file history looking only at loaded file names, so no file names
means no annotation and this could explaing what you have seen.
Make annotation working also without file names loaded is on my TODO list, in the meantime,
you should need to set the flag and eventually refresh (F5), before to try annotate.
It's my bad I didn't documented properly this requirement.
Indeed the flag 'load file names in background' _should_ always be set.
You need to unset the flag only for very very big archives like the whole
linux history tree (kernel.org:/pub/scm/linux/kernel/git/tglx/history.git) so to keep
memory requirement at a minimum.
Please, let me know if this clears the things a bit.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* scons and $HOME was Re: [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-25 20:03 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
Josef Weidendorfer wrote:
>On Sunday 25 September 2005 09:07, Marco Costalba wrote:
>
>>>>src/rangeselectbase.h QSettings: error creating /.qt
>>>>QSettings: error creating /.qt
>>
>>...
>>QSettings are there from day one :-<
>>I am not able to let them disappear.....very bad. In any case should be
>>harmless.
>
>
>These errors seam to appear because scons does NOT pass through the $HOME
>environment variable to subprocesses. "moc", which is producing these
>errors, obviously wants to access some config options in $HOME/.qt/.
>
>Somebody knows how to change this?
>
$HOME environment variable is passed to scons in SConstruct with
env['HOME'] = os.environ['HOME']
then moc util is called in qt.py inside scons-mini.tar.bz2
That's where I stopped.....
Anyone that can teach qt.py to pass $HOME to moc and uic tools is greatly appreciated.
Marco
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-25 20:37 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
Josef Weidendorfer wrote:
>Hi,
>
>On Sunday 25 September 2005 07:52, Marco Costalba wrote:
>
>>>* The commit time is relative to now, which makes no sense to me. Also,
>>>it is in the second column instead of the last one like in gitk, which
>>>seems better to me. At least, the column is too narrow and then it
>>>blends together with the commit title.
>
>
>I vote for absolute time, and the date column at the end, too.
...and 'date column at the end' wins for 3 votes against 0 ;-)
>Besides, QT allows to reorder the columns with the mouse (the order should be
>saved in a config file at end to be persistant over program runs).
>
Yes, good idea.
>>>* Getting to the diff view was non-obvious for me. It'd be nice to have
>>>some [diff] button as well somewhere. Or you could also show the diff in
>>>the bottom part of screen in the commit view, I think gitk solved this
>>>nicely.
>>
>>I have tought a lot how to pass to the user the information that to see a
>>diff you have to double click on the commit:
>
>
>I like the gitk solution better.
>What about making the commit list a QDockWindow, which can be docked to either
>side of the window (default: top as currently), but also made a floating
>window, so that the commit diff gets the whole main window?
>
Should be nice, but it's a bit of work...maybe I don't know very well QDockWindow.
Peraphs is the commit info pane at the bottom left that could be implemented as a
QDockWindow with the diff attached below the commit info gitk like.....
>
>I think that diagonal lines as in gitk make it way easier to get an overview.
>What makes drawing of diagonal lines slow?
with diagonal line you cannot draw graphs one rev at the time from left to right but you
need some information from previous one and eventually pass some information to next one.
The fact is diagonal lines are originated in a diffrent line from what you are drawing and
you need to bring with you that piece of information.
More, in qgit pixmaps are precalculated in main view ctor and filled in an array, so only
array indexing is used to retrive and copy correct pixmap according to proper lane type.
Adding diagonals pixmaps is not obvious and not simple, at least for me. I tell you this
because I have tried but the design of graph function became overly complex.
>It should be quite fast to subclass QListViewItem for commit entries and
>overwrite QListViewItem::paintCell to use your own drawing; paintCell is
>called for visible entries only.
>
QListViewItem is already subclassed to paint odd/even lines background and tags/heads colors.
Pixmaps are not painted but, as told before, directly copied from a fixed pixmaps array this
is also done in paintCell(). See ListViewLogItem::paintCell() in mainimpl.cpp if interested.
Because paintCell() is called for visible entries only, also commit line setup (columns text,
relative time calculation, tagging, etc) is done in paintCell() the first time item became
visible. So to push to the limit the 'lazy setup' policy and gain speed.
>Another wish: The tag/head markers in gitk are really good. In qgit, I only
>get another background color, and miss the name.
You can see the name in the status bar when you select the item. Also the refs names are
cumulative, i.e. if you select a tag that is also a branch head and, eventually also another kind
of ref, all this information is shown in the status bar.
Status bar has more avaiable space then inline marker this is the reason I chose that way.
>
>Yes, really nice.
>
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Alan Chandler @ 2005-09-25 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vaci1nfwa.fsf@assigned-by-dhcp.cox.net>
On Sunday 25 Sep 2005 19:47, Junio C Hamano wrote:
...
>
> One straightforward way which would work for everybody would be
> (provided you do not have git-src in the current directory):
>
> $ git clone http://kernel.org/pub/scm/git/git.git git-src
> $ cd git-src
I did the above just after your announcement but before the tags etc had got
there (see my earlier question in this thread).
> $ git reset --hard v0.99.7d
Didn't do this
...
> Then you can say:
>
> $ git fetch origin tag v0.99.7d
Did this
...
> Now, how would you check out the v0.99.7d tag? There are two
> ways to think about it.
>
> If the reason you want v0.99.7d, not "master" nor "pu", is you
> would want to stay with the 0.99.7 but get all the latest safer
> fixes, then you can just checkout "maint" branch instead, like
> this:
>
> $ git checkout -f maint
>
I am rather new to all this, but this last step puzzles me.
Before this step, and using gitk --all, I can see the maintenance branch, but
its currently connected to the point where the v0.99.7c tag is and not where
your latest tag is.
So if I followed these instructions, now, wouldn't I just get the v0.997c tag?
Does that mean I have missed some step along the way to get the maint branch
position moved to the new tag?
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Robin Farine @ 2005-09-25 20:46 UTC (permalink / raw)
To: git
In-Reply-To: <200509252056.04403.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer <at> gmx.de> writes:
> On Sunday 25 September 2005 09:07, Marco Costalba wrote:
> > >> src/rangeselectbase.h QSettings: error creating /.qt
> > >>QSettings: error creating /.qt
> > ...
> > QSettings are there from day one :-<
> > I am not able to let them disappear.....very bad. In any case should be
> > harmless.
>
> These errors seam to appear because scons does NOT pass through the $HOME
> environment variable to subprocesses. "moc", which is producing these
> errors, obviously wants to access some config options in $HOME/.qt/.
>
> Somebody knows how to change this?
With SCons, key-value pairs that are meant to appear in process
environment need to be added to the env['ENV'] mapping. In this
case:
env = Environment(...)
env['ENV']['HOME'] = os.environ['HOME']
Environment() creates an SCons build environment which is unrelated
to subprocess environments (even though the same word is used :)).
As a special case, SCons handles the mapping assigned to env['ENV']
as process environment for subprocesses.
Hope this helps,
Robin
^ permalink raw reply
* Re: cogito push problem
From: Petr Baudis @ 2005-09-25 21:09 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20050925192214.GC19023@schottelius.org>
Dear diary, on Sun, Sep 25, 2005 at 09:22:14PM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> Hello!
>
> I was trying to push my current work out and recieved this error:
>
> [21:20] hydrogenium:cinit% cg-push main
> error: remote ref 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'.
>
> My questions:
> - What does that mean to me as an end-user?
> - What's the reason that this happened?
> - How do I fix that?
This means someone probably pushed out some new stuff you don't have
yet (or you did something evil, like uncommitted something you already
pushed out before). So what to do is cg-update, that will merge the new
stuff, then try to cg-push again.
cg-push already spits out a somewhat more helpful message about this in
some cases, I'll make it do so in all cases. Thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: cogito push problem
From: Nico -telmich- Schottelius @ 2005-09-25 21:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050925210908.GA21019@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
Petr Baudis [Sun, Sep 25, 2005 at 11:09:08PM +0200]:
> Dear diary, on Sun, Sep 25, 2005 at 09:22:14PM CEST, I got a letter
> where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> > Hello!
> >
> > I was trying to push my current work out and recieved this error:
> >
> > [21:20] hydrogenium:cinit% cg-push main
> > error: remote ref 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'.
> >
> > My questions:
> > - What does that mean to me as an end-user?
> > - What's the reason that this happened?
> > - How do I fix that?
>
> This means someone probably pushed out some new stuff you don't have
> yet (or you did something evil, like uncommitted something you already
> pushed out before). So what to do is cg-update, that will merge the new
> stuff, then try to cg-push again.
Thanks for your help, cg-update && cg-commit worked fine, because
cg-update overwrote the changes made by me (I checked cg-diff before,
so that was my intention, not cg-update's fault).
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-25 21:57 UTC (permalink / raw)
To: Robin Farine; +Cc: git
Robin Farine wrote:
>Josef Weidendorfer <Josef.Weidendorfer <at> gmx.de> writes:
>
>
>>On Sunday 25 September 2005 09:07, Marco Costalba wrote:
>>
>>>>>src/rangeselectbase.h QSettings: error creating /.qt
>>>>>QSettings: error creating /.qt
>>>
>>>...
>>>QSettings are there from day one :-<
>>>I am not able to let them disappear.....very bad. In any case should be
>>>harmless.
>>
>
>
>With SCons, key-value pairs that are meant to appear in process
>environment need to be added to the env['ENV'] mapping. In this
>case:
>
> env = Environment(...)
> env['ENV']['HOME'] = os.environ['HOME']
>
>Environment() creates an SCons build environment which is unrelated
>to subprocess environments (even though the same word is used :)).
>As a special case, SCons handles the mapping assigned to env['ENV']
>as process environment for subprocesses.
>
>Hope this helps,
>
This helps a lot!
I added the line
env['ENV']['HOME'] = os.environ['HOME']
to my SConstruct and the warning disappeard :-) :-) :-)
This fix is greatly appreciated, thanks a lot Robin.
Marco
P.S: I have just pushed the fix, togheter with some other updates,
to http://digilander.libero.it/mcostalba/qgit.git
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: cogito push problem
From: Petr Baudis @ 2005-09-25 22:02 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20050925215259.GE19023@schottelius.org>
Dear diary, on Sun, Sep 25, 2005 at 11:52:59PM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> Petr Baudis [Sun, Sep 25, 2005 at 11:09:08PM +0200]:
> > Dear diary, on Sun, Sep 25, 2005 at 09:22:14PM CEST, I got a letter
> > where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...
> > > Hello!
> > >
> > > I was trying to push my current work out and recieved this error:
> > >
> > > [21:20] hydrogenium:cinit% cg-push main
> > > error: remote ref 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'.
> > >
> > > My questions:
> > > - What does that mean to me as an end-user?
> > > - What's the reason that this happened?
> > > - How do I fix that?
> >
> > This means someone probably pushed out some new stuff you don't have
> > yet (or you did something evil, like uncommitted something you already
> > pushed out before). So what to do is cg-update, that will merge the new
> > stuff, then try to cg-push again.
>
> Thanks for your help, cg-update && cg-commit worked fine, because
> cg-update overwrote the changes made by me (I checked cg-diff before,
> so that was my intention, not cg-update's fault).
But it definitively shouldn't do that anyway. Was that 0.15.1?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Add "git-update-ref" to update the HEAD (or other) ref
From: Junio C Hamano @ 2005-09-25 22:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.58.0509251153090.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, in case it wasn't clear from the patch, this only introduced
> mechanism, it didn't actually use it in any script.
No I understood it perfectly well thanks -- I am just slow
because I am somewhat sick today.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Tom Prince @ 2005-09-25 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaci1nfwa.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>
> When you already have a repository to track git.git, I would
> recommend to have something like this in .git/remote/origin:
>
> URL: http://kernel.org/pub/scm/git/git.git
> Pull: master:origin maint:maint +pu:pu
>
A warning when you do this. If you say
git pull origin
then your master will be updated with an octopus merge of the three heads.
Tom
^ 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