* [SCRIPT] cg-rpush & locking
From: Tony Lindgren @ 2005-05-31 19:00 UTC (permalink / raw)
To: git; +Cc: Matthias Urlichs
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
Hello all,
Attached is a little script we're using for pushing changes to the
linux-omap tree. I modified it from an earlier script done by
Matthias Urlichs.
It uses rsync over ssh and should work with rsync write access too.
In order to remove lock files using rsync, I've added
a .git/locks subdirectory that contains the lock file.
The reason for this is that it allows replacing the lock directory
with an empty directory using rsync. This removes the lock file
after the remote update is done.
Currently the local lock has some issues with chained pushes...
If somebody is pushing from a remote repo to the local repo while
the local repo is being pushed to some other remote repo, the lock
may get removed.
Of course the lock does not protect from local changes either.
Anybody have any better ideas for locking that also works with
rsync?
Tony
[-- Attachment #2: cg-rpush --]
[-- Type: text/plain, Size: 3901 bytes --]
#!/bin/sh
#
# Pushes changes from the local git repo to remote repo.
#
# Copyright (C) 2005 Tony Lindgren <tony@atomide.com>
#
# Some parts based on an earlier push script,
# Copyright (C) 2005 Matthias Urlichs.
#
# Takes the remote repo's name or url as parameter.
#
# Most likely the remote repo is not rsync writable, but
# you can use rsync over ssh for the push.
#
# When using rsync over ssh, you must use the real repo
# path on the server and an ssh key to avoid typing in
# the password multiple times. For example:
#
# $ export RSYNC_FLAGS="-z --progress"
# $ export RSYNC_RSH="ssh -i /home/user/.ssh/my-git-key"
# $ cg-rpush some.machine:/home/git/repo
#
. ${COGITO_LIB}cg-Xlib
name=$1
BRANCHES=".git/branches"
HEADS=".git/refs/heads"
OBJECTS=".git/objects"
LOCKS=".git/locks"
REMOTE_LOCK="write_lock"
TMP="/tmp"
uri=""
function usage () {
echo "Usage: [RSYNC_FLAGS=\"-e ssh\"] $0 some.machine:/home/git/repo"
exit 1
}
function die () {
if [ -f $LOCKS/$REMOTE_LOCK ]; then
rm -f $LOCKS/$REMOTE_LOCK
fi
echo cg-rpush: $@ >&2
exit 1
}
function clean_locks () {
rm -f $LOCKS/$REMOTE_LOCK
rsync $RSYNC_FLAGS -r --delete $LOCKS/ $uri/$LOCKS
}
function validate_input () {
[ "$name" ] || usage
if [ ! -d ".git" ]; then
die "Could not find local .git directory"
fi
uri=$(cat $BRANCHES/$name 2>/dev/null)
[ "$uri" ] || uri=$name
echo $uri
}
#
# We must use a lock directory to allow removing the remote lock
# files with rsync by copying over it with an empty directory.
# Creating the remote lock file should be safe. However, please note
# that we must also be careful not to remove local .git/locks/write_lock
# in case somebody is pushing to our local repo from a remote machine.
# Currently the local lock file creation can conflict with a lock
# file creation from a remote machine to our local machine.
#
function lock_files () {
echo "Attempting to to create a write lock on remote..."
if [ ! -d $LOCKS ]; then
mkdir $LOCKS;
fi
if [ -f $LOCKS/$REMOTE_LOCK ]; then
echo "Local write_lock already exists: $LOCKS/$REMOTE_LOCK"
exit 1
fi
lock_stamp="$USER@$HOSTNAME $(date)"
echo $lock_stamp > $LOCKS/$REMOTE_LOCK
rsync $RSYNC_FLAGS -r --ignore-existing $LOCKS/ $uri/$LOCKS
# Check what the remote .git/locks/write_lock has
tmpfile=$TMP/remote_lock_$RANDOM
rsync $RSYNC_FLAGS "$uri/$LOCKS/$REMOTE_LOCK" $tmpfile
remote_stamp=$(cat $tmpfile)
rm -f $tmpfile
if [ "$remote_stamp" != "$lock_stamp" ]; then
die "Remote locked by $remote_stamp, please try again later"
fi
}
function check_remote_version () {
echo "Getting remote version..."
tmpfile=$TMP/remote_head_$RANDOM
rsync $RSYNC_FLAGS -Lr "$uri/$HEADS/master" $tmpfile
remote_head=$(cat $tmpfile)
rm -f $tmpfile
if [ -z "$remote_head" ]; then
clean_locks
die "Remote repository does not have $uri/$HEADS/master"
fi
echo "Remote head is at: $remote_head"
if [ "$(git-cat-file -t "$remote_head" 2>/dev/null)" != "commit" ]; then
clean_locks
die "Remote is ahead, please do a pull first"
fi
}
function push_git_objects () {
echo "Pushing .git/objects..."
rsync $RSYNC_FLAGS --ignore-existing --whole-file -v -r \
"$OBJECTS/" "$uri/$OBJECTS/"
}
function update_remote_head () {
local_head=$(cat $HEADS/master)
echo "Updating remote head to: $local_head"
rsync $RSYNC_FLAGS -Lr $HEADS/master "$uri/$HEADS/master"
}
function print_note () {
echo "Remote updated successfully"
echo "NOTE: Not updating checked out remote files in case they"
echo "have been edited locally on the remote machine."
echo "To sync checked out files on remote, you can run cg-cancel"
echo "on remote machine. You can check for uncommitted changes"
echo "on remote with cg-diff first, which should only show"
echo "changes done in this push."
}
#
# Main program
#
uri=$(validate_input)
lock_files
check_remote_version
push_git_objects
update_remote_head
clean_locks
print_note
exit
^ permalink raw reply
* Re: cg-seek messed me up
From: Petr Baudis @ 2005-05-31 18:39 UTC (permalink / raw)
To: Zack Brown; +Cc: Git Mailing List
In-Reply-To: <20050531143318.GB27047@tumblerings.org>
Dear diary, on Tue, May 31, 2005 at 04:33:18PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi folks,
Hi,
> I'm not positive, but I *think* I shot myself in the foot by doing a cg-seek
> when there were uncommitted changes in my working file set. The patching process
> created duplicate areas in the files, while losing other areas and giving
> patch rejects. Before I figured out the problem, I wasn't even able to seek to a
> known state because of this, so I ended up having to recreate the files as best
> as I could from the mess I was left with in the working directory. I realize I
> could have gotten a clean tree by cloning, but this didn't occur to me at the
> time. It seemed like the whole repository was just corrupt.
>
> I think I recovered everything, and I know it was my own mistake, but it
> seems like this will be a common blunder by users. Maybe cg-seek should
> first do a comparison between the working tree and the most recent known
> state. If the two differ, it should exit with an error.
I've rewritten cg-seek to use the magical tree_timewarp function. So
what it will do now is that it will save the local changes, then just
overwrite the tree with the seeked-to target and then it will reapply
the local changes. This should give much better (although still far from
perfect) results and reduce the inconsistencies popping up.
Anyway, anytime you are in trouble, cg-cancel is the way out! ;-)
--
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: [ANNOUNCE] qgit, another git GUI viewer
From: Brandon Philips @ 2005-05-31 18:11 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050531170445.38748.qmail@web26305.mail.ukl.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 577 bytes --]
Hi Marco,
Obligatory screenshot:
http://ifup.org/~philips/qgit.png
Some quick feedback:
> This is qgit, basically a porting of gitk to Qt/C++.
The tarball extracts to the current directory which isn't very friendly.
> Just run make, install the bin anywhere in the path
> and run from any git project working directory to see
> the graph
Out of the box it wouldn't compile for several reasons on my own
computer. I have attached a diff but the only real solution is to use
autotools as my diff will now only work on Gentoo systems.
Hope this helps.
-Brandon Philips
[-- Attachment #1.2: qgit-gentoo-compile.patch --]
[-- Type: text/plain, Size: 1588 bytes --]
--- b/Makefile 2005-05-28 14:38:22.000000000 -0700
+++ a/Makefile 2005-05-31 10:15:05.000000000 -0700
@@ -26,7 +26,7 @@
sub-src: src/$(MAKEFILE) FORCE
cd src && $(MAKE) -f $(MAKEFILE)
-Makefile: qgit.pro /usr/lib/qt3/mkspecs/default/qmake.conf
+Makefile: qgit.pro /usr/qt/3/mkspecs/linux-g++/qmake.conf
$(QMAKE) -o Makefile qgit.pro
qmake: qmake_all
@$(QMAKE) -o Makefile qgit.pro
--- b/src/Makefile 2005-05-28 08:31:26.000000000 -0700
+++ a/src/Makefile 2005-05-31 10:18:15.000000000 -0700
@@ -12,8 +12,8 @@
CXX = g++
LEX = flex
YACC = yacc
-CFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT
-CXXFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT
+CFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -pipe -march=i586 -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT
+CXXFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -pipe -march=i586 -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT
LEXFLAGS =
YACCFLAGS= -d
INCPATH = -I/usr/lib/qt3/mkspecs/default -I. -I$(QTDIR)/include
@@ -123,8 +123,8 @@
$(MOC):
( cd $(QTDIR)/src/moc && $(MAKE) )
-
-Makefile: src.pro /usr/lib/qt3/mkspecs/default/qmake.conf /usr/lib/qt3/lib/libqt-mt.prl
+#####/usr/qt/3/mkspecs/linux-g++/libqt-mt.prl
+Makefile: src.pro /usr/qt/3/mkspecs/linux-g++/qmake.conf
$(QMAKE) -o Makefile src.pro
qmake:
@$(QMAKE) -o Makefile src.pro
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ANNOUNCE] qgit, another git GUI viewer
From: Marco Costalba @ 2005-05-31 17:04 UTC (permalink / raw)
To: git
Hi,
This is qgit, basically a porting of gitk to Qt/C++.
Has mainly all the features of gitk, some differences
are an uglier graph and a quick start alghoritm that
doesn't use git-rev-tree.
Just run make, install the bin anywhere in the path
and run from any git project working directory to see
the graph
Should be quite friendly to use; just go
(double)clicking around.
Download link is:
http://sourceforge.net/project/showfiles.php?group_id=139897&package_id=153471&release_id=331341
Home page:
http://sourceforge.net/projects/qgit/
Hope you enjoy it
Marco Costalba
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* [PATCH] Make git-update-cache --force-remove regular
From: Petr Baudis @ 2005-05-31 16:52 UTC (permalink / raw)
To: torvalds; +Cc: git
Make the --force-remove flag behave same as --add, --remove and
--replace. This means I can do
git-update-cache --force-remove -- file1.c file2.c
which is probably saner and also makes it easier to use in cg-rm.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit 2cd99acef0c74c6218b51e058a3e045e1a8b7b66
tree 4e25708b4fd3ca1589833245a8e48bf87cb7fbde
parent 3e26fef188baa4626457fae25b0b63e1c788efcd
author Petr Baudis <pasky@ucw.cz> Tue, 31 May 2005 18:51:56 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Tue, 31 May 2005 18:51:56 +0200
Documentation/git-update-cache.txt | 4 ++--
update-cache.c | 12 +++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-update-cache.txt b/Documentation/git-update-cache.txt
--- a/Documentation/git-update-cache.txt
+++ b/Documentation/git-update-cache.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git-update-cache'
[--add] [--remove] [--refresh] [--replace]
[--ignore-missing]
- [--force-remove <file>]
+ [--force-remove]
[--cacheinfo <mode> <object> <file>]\*
[--] [<file>]\*
@@ -49,7 +49,7 @@ OPTIONS
--force-remove::
Remove the file from the index even when the working directory
- still has such a file.
+ still has such a file. (Implies --remove.)
--replace::
By default, when a file `path` exists in the index,
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -13,6 +13,7 @@
* files be revision controlled.
*/
static int allow_add = 0, allow_remove = 0, allow_replace = 0, not_new = 0;
+static int force_remove;
/* Three functions to allow overloaded pointer return; see linux/err.h */
static inline void *ERR_PTR(long error)
@@ -376,11 +377,7 @@ int main(int argc, char **argv)
continue;
}
if (!strcmp(path, "--force-remove")) {
- if (argc <= i + 1)
- die("git-update-cache: --force-remove <path>");
- if (remove_file_from_cache(argv[i+1]))
- die("git-update-cache: --force-remove cannot remove %s", argv[i+1]);
- i++;
+ force_remove = 1;
continue;
}
@@ -394,6 +391,11 @@ int main(int argc, char **argv)
fprintf(stderr, "Ignoring path %s\n", argv[i]);
continue;
}
+ if (force_remove) {
+ if (remove_file_from_cache(path))
+ die("git-update-cache: --force-remove cannot remove %s", path);
+ continue;
+ }
if (add_file_to_cache(path))
die("Unable to add %s to database", path);
}
|
--
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: cg-update with local uncommitted changes
From: Petr Baudis @ 2005-05-31 16:04 UTC (permalink / raw)
To: Zack Brown; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <20050530192541.GA27047@tumblerings.org>
Dear diary, on Mon, May 30, 2005 at 09:25:41PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Mon, May 30, 2005 at 04:25:14PM +0200, Marcel Holtmann wrote:
> > Hi Petr,
> >
> > when doing a cg-update and I have local uncommitted changes it fails
> > with the "... needs update" message.
>
> I don't see failures, but I do see the "needs update" message often when
> I do cg-update. If I run cg-update a second time it says the tree is fully
> up-to-date. However, if I then do a cg-diff, I will see tons of diff output.
> This is on a tree (the kernel) that I haven't modified at all, I only track it
> with cg-update.
This is strange. I've just did a cg-update on a kernel tree I've left
untouched for more than a week (and I've even locally modified one file)
and everything went fine.
> I also track Cogito, and I use the latest form of all git and Cogito tools.
> Maybe somewhere along the line I've corrupted my repo by using incompatible
> versions of the git/Cogito toolset.
That's entirely possible given the big output format changes from some
git tools. Hopefully most of those problems should be already fixed.
> I've noticed if I do a fresh cg-clone the problem seems to go away.
Tip of the day: cg-cancel will fix almost any working state messup (any
messup as long as you have proper commit id in your refs/heads/master
file).
--
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: cg-update with local uncommitted changes
From: Petr Baudis @ 2005-05-31 15:58 UTC (permalink / raw)
To: Dan Holmsand; +Cc: git
In-Reply-To: <d7g430$1cq$1@sea.gmane.org>
Dear diary, on Tue, May 31, 2005 at 12:31:28AM CEST, I got a letter
where Dan Holmsand <holmsand@gmail.com> told me that...
> Marcel Holtmann wrote:
> >I also think that it would be great if we cancel the merge if the local
> >changes conflict with the files in the merge. This is how Bitkeeper does
> >it and I think it is the only safe way, because if something fails or
> >rejects we may destroy the local changes.
>
> I definitely agree (been bitten by patching gone wild a couple of times...).
>
> This patch would make cg-merge and cg-admin-uncommit refuse to do
> anything if there are conflicting uncommitted changes. Note: this only
> applies to fast-forward merging, as cg-merge otherwise bails out if
> there are *any* uncommitted changes (which is perhaps going to far).
Well, non-fast-forward cg-merge will do cg-commit and it would blend the
unrelated previously uncommitted changes into that, which is not what
you want.
> [PATCH] Make tree_timewarp safe, by refusing to handle conflicts.
>
> Signed-off-by: Dan Holmsand <holmsand@gmail.com>
I don't really think this makes any sense. What do you then do when you
want to do some merging of the local uncommitted changes and upstream
update?
How have you been bitten, and how could we destroy the local changes?
You get rejects and patch will be pretty vocal about it, so then you
just go and resolve them. The correct direction is to make it do a
three-way merge, not make it do no merge at all.
--
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] allow pathspec to end with a slash
From: Linus Torvalds @ 2005-05-31 15:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Junio,
pathspec is still subtly broken.
Just removing the slash at the end is not the right thing to do, since
that means that
git-diff-files drivers/char/
will trigger on a _file_ "drivers/char", even though the spec makes it
unambiguous that the user only wants to see stuff under that directory.
Again, git-diff-tree gets this right (not to say that it always did - I
had to fix "interesting()" several times, exactly because it's not that
simple).
Linus
^ permalink raw reply
* Re: cg-seek messed me up
From: randy_dunlap @ 2005-05-31 15:23 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: zbrown, git
In-Reply-To: <20050531144506.GC6706@cip.informatik.uni-erlangen.de>
On Tue, 31 May 2005 16:45:07 +0200 Thomas Glanzmann wrote:
| Hello,
| this is exactly why I don't use it at the moment. My own frontend does
| before every pull/push/merge/commit a 'look for dirty files and look for
| uncommited deltas'.
I don't recall where your frontend is.
Can you (re)post a pointer to it?
Thanks,
---
~Randy
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Linus Torvalds @ 2005-05-31 15:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505310735260.1876@ppc970.osdl.org>
On Tue, 31 May 2005, Linus Torvalds wrote:
>
> You should never see a parent before a child from git-rev-list.
Actually, I take that back.
A commit that has several children will see _a_ child before the parent is
shown, but while the time-based ordering means that it _likely_ will order
all children before the parent, now that I think about it, that's not
guaranteed to be true. You could have
A
/ \
B |
\ /
C
|
D
and if C has a date that is before B, then git-rev-list would traverse the
tree (and show it) in the order A C B.
In fact, even D might be listed before B is (eg, the person who committed
B had a clock that was set to the last century, and so the date on that
was wrong).
The thing is, since B has such an "old" date, the traversal assumes that
it is old and very low down in the tree, and that it's better off parsing
other commits first, so it will never look more closely at B and notice
that it has a parent that has already been parsed.
So I guess you'll have to wait for the end and do the toposort after all.
Sorry about the confusion on my part.
Linus
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Linus Torvalds @ 2005-05-31 15:13 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc4032050531005820979ca7@mail.gmail.com>
On Tue, 31 May 2005, Jon Seymour wrote:
>
> A
> / | \
> B C D
> | / /
> E
> | \
> F G
>
> and searching for git-rev-list A ^B it would actually be better to stop
> at E (printing A,B,C,D,E)
Btw, you probably looked at the actual code, so you know this, but maybe
it wasn't clear to everybody else: the code obviously _will_ look at all
of ABCDE before it can even decide that it should print out ACD, since it
really needs to.
What happens is that it walks the tree "time-first" (not depth-first or
breadth-first, but "most-recent-first"), which tends to approximate what
we want, and when it sees "B" it will mark all of its children as
uninteresting since they were clearly seen. So it will actually have
gotten all the way to E before it can tell that it has seen enough.
The thing that makes git-rev-list preferred over git-rev-tree is that it
can avoid looking at F and G and older parents, since it's clear by E that
walking the tree any further would be pointless, and all the commits we
could look at are already marked uninteresting.
But if somebody wanted to actually show this as a _graph_, what you would
probably want is actually all of ABCDE, except you'd get the "interesting"
bit separately (ie ACD would be tagged some way). Then you could show a
sane graph that is colored by whether something is new or not, for
example. That's absolutely trivial to do wiyth the new rev-list algorithm,
in case somebody really cares - it's literally just changing the printout
to show the entries marked "ignored" with some extra marking.
(Well, slightly more too: you'd have to add the uninteresting commits to
the list, and mark the end object itself as being ignored, but that's two
more trivial lines. Right now the code knows that it won't even add some
objects to the output list, so..).
Linus
^ permalink raw reply
* Re: cg-seek messed me up
From: Thomas Glanzmann @ 2005-05-31 14:45 UTC (permalink / raw)
To: Zack Brown; +Cc: Git Mailing List
In-Reply-To: <20050531143318.GB27047@tumblerings.org>
Hello,
this is exactly why I don't use it at the moment. My own frontend does
before every pull/push/merge/commit a 'look for dirty files and look for
uncommited deltas'.
Thomas
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Linus Torvalds @ 2005-05-31 14:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <17052.21846.816147.370354@cargo.ozlabs.ibm.com>
On Tue, 31 May 2005, Paul Mackerras wrote:
>
> I have made gitk use git-rev-list instead of git-rev-tree, but it
> still absorbs the whole of git-rev-list's output before drawing
> anything. I'd like to make it draw the commit graph and list
> incrementally as it gets the output from git-rev-list, but to do that
> I need to know whether git-rev-list could ever print a commit ID
> *after* one of its parents. If it never does that then I can
> restructure the code to do the drawing incrementally fairly easily.
You should never see a parent before a child from git-rev-list. I may have
screwed something up when I move things between the two lists (the
before/after thing needs to first do the reachability thing on one list,
and then moves them to the "potential output list"), but I don't think so.
Anyway, at that point it would be a git-rev-list bug, so if you can make
your code notice and complain ("git-rev-list listed parent before child")
rather than silently show crud, that would help debugging it if it ever
happened.
Linus
^ permalink raw reply
* cg-seek messed me up
From: Zack Brown @ 2005-05-31 14:33 UTC (permalink / raw)
To: Git Mailing List
Hi folks,
I'm not positive, but I *think* I shot myself in the foot by doing a cg-seek
when there were uncommitted changes in my working file set. The patching process
created duplicate areas in the files, while losing other areas and giving
patch rejects. Before I figured out the problem, I wasn't even able to seek to a
known state because of this, so I ended up having to recreate the files as best
as I could from the mess I was left with in the working directory. I realize I
could have gotten a clean tree by cloning, but this didn't occur to me at the
time. It seemed like the whole repository was just corrupt.
I think I recovered everything, and I know it was my own mistake, but it
seems like this will be a common blunder by users. Maybe cg-seek should
first do a comparison between the working tree and the most recent known
state. If the two differ, it should exit with an error.
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Linus Torvalds @ 2005-05-31 14:35 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc4032050531005820979ca7@mail.gmail.com>
On Tue, 31 May 2005, Jon Seymour wrote:
>
> On 5/31/05, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > Somebody should probably take a look at my simplistic algorithm, since it
> > can probably be improved upon and/or fixed for corner-cases.
>
> Seems reasonable, though I think that in a graph like this:
>
> A
> / | \
> B C D
> | / /
> E
> | \
> F G
>
> and searching for git-rev-list A ^B it would actually be better to stop
> at E (printing A,B,C,D,E), rather than B because the contemporaneously
> parallel edits C and D and the common base E are relevant to evaluating
> B since they got merged with B into A from the common starting point E.
You're talking about something else - you worry about showing a graph, for
example.
What git-rev-list A B does is literally for something like a "changelog" -
what commits were added in A that weren't in B, and the list is A, C and
D. Or, more commonly, used for something like
git-rev-list HEAD v2.6.12-rc5 | git-diff-tree --stdin -v -p drivers/usb
which basically says "what changed since 2.6.12-rc5 in the drivers/usb
tree"?
So in that situation, you really do _not_ want to see B and E, even if
you'd need those two to make all the connections. Because you've seen B
and E already (they were in v2.6.12-rc5), and if you're looking for a bug
that didn't happen in that release, you really only want to see the new
stuff.
Linus
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Eric W. Biederman @ 2005-05-31 13:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, I'm at the point where I really think it's getting close to a 1.0, and
> make another tar-ball etc. I obviously feel that it's already way superior
> to CVS, but I also realize that somebody who is used to CVS may not
> actually realize that very easily.
I way behind the power curve on learning git at this point but
one piece of the puzzle that CVS has that I don't believe git does
are multiple people committing to the same repository, especially
remotely. I don't see that as a down side of git but it is a common
way people CVS so it is worth documenting.
Eric
^ permalink raw reply
* Re: [gitweb PATCH] Configure encoding
From: Kay Sievers @ 2005-05-31 12:21 UTC (permalink / raw)
To: Thomas Kolejka; +Cc: Git Mailing List
In-Reply-To: <11399.1117537956@www67.gmx.net>
On Tue, May 31, 2005 at 01:12:36PM +0200, Thomas Kolejka wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Kay Sievers <kay.sievers@vrfy.org>
> > An: Petr Baudis <pasky@ucw.cz>
> > Kopie: Thomas Kolejka <Thomas.Kolejka@gmx.at>, Git Mailing List
> > <git@vger.kernel.org>
> > Betreff: Re: [gitweb PATCH] Configure encoding
> > Datum: Tue, 31 May 2005 12:44:25 +0200
> >
> > On Tue, May 31, 2005 at 12:12:17PM +0200, Petr Baudis wrote:
> > > Dear diary, on Tue, May 31, 2005 at 11:19:55AM CEST, I got a letter
> > > where Kay Sievers <kay.sievers@vrfy.org> told me that...
> > > > On Tue, May 31, 2005 at 09:55:11AM +0200, Thomas Kolejka wrote:
> > > > > The following patch makes it easy to change the encoding:
> > > > >
> > > > >
> > > > > --- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
> > > > > +++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
> > > > > @@ -20,6 +20,9 @@
> > > > > my $my_uri = $cgi->url(-absolute => 1);
> > > > > my $rss_link = "";
> > > > >
> > > > > +my $encoding = "utf-8";
> > > > > +$encoding = "iso-8859-1";
> > > >
> > > > The upstream version will not support anything but the one and only
> > > > sane encoding which is utf-8. It will not provide options to switch
> > > > back to the 80's, sorry. :)
> > >
> > > This matters mainly for commits, right?
> >
> > Yes. Also the content of the files, but fortunately they are just plain
> > ascii most of the time. :)
>
> I've made this changes becausae the german letters like ä, ö, ... are
> displayed ugly in the browser.
So use a sane encoding in your commit-text. We don't store the encoding
with the commit, so you don't have any sane other option besides using
utf-8 if you don't use plain ascii.
> > > Perhaps I should recode from current locale to utf8 in cg-commit?
> >
> > Everthing else than utf-8 is just a complete mess with data shared
> > across multiple machines. All modern distributions defaulting to utf-8
> > anyway, so I think it is sane to recode that utf-8.
>
> The patch is to _change_ the encoding easy .. or to leave it unchanged.
Exactly. Change to other encodings is not supported upstream and will
not be a configuration value, sorry.
Kay
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Paul Mackerras @ 2005-05-31 12:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301847120.1876@ppc970.osdl.org>
Linus Torvalds writes:
> Ok, I just made git-rev-list DTRT when you pass it a "beginning" and
> "end", ie it does proper reachability analysis _without_ parsing the whole
> set of commits.
I have made gitk use git-rev-list instead of git-rev-tree, but it
still absorbs the whole of git-rev-list's output before drawing
anything. I'd like to make it draw the commit graph and list
incrementally as it gets the output from git-rev-list, but to do that
I need to know whether git-rev-list could ever print a commit ID
*after* one of its parents. If it never does that then I can
restructure the code to do the drawing incrementally fairly easily.
Paul.
^ permalink raw reply
* Re: [gitweb PATCH] Configure encoding
From: Thomas Kolejka @ 2005-05-31 11:12 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
In-Reply-To: <20050531104425.GA23755@vrfy.org>
> --- Ursprüngliche Nachricht ---
> Von: Kay Sievers <kay.sievers@vrfy.org>
> An: Petr Baudis <pasky@ucw.cz>
> Kopie: Thomas Kolejka <Thomas.Kolejka@gmx.at>, Git Mailing List
> <git@vger.kernel.org>
> Betreff: Re: [gitweb PATCH] Configure encoding
> Datum: Tue, 31 May 2005 12:44:25 +0200
>
> On Tue, May 31, 2005 at 12:12:17PM +0200, Petr Baudis wrote:
> > Dear diary, on Tue, May 31, 2005 at 11:19:55AM CEST, I got a letter
> > where Kay Sievers <kay.sievers@vrfy.org> told me that...
> > > On Tue, May 31, 2005 at 09:55:11AM +0200, Thomas Kolejka wrote:
> > > > The following patch makes it easy to change the encoding:
> > > >
> > > >
> > > > --- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
> > > > +++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
> > > > @@ -20,6 +20,9 @@
> > > > my $my_uri = $cgi->url(-absolute => 1);
> > > > my $rss_link = "";
> > > >
> > > > +my $encoding = "utf-8";
> > > > +$encoding = "iso-8859-1";
> > >
> > > The upstream version will not support anything but the one and only
> > > sane encoding which is utf-8. It will not provide options to switch
> > > back to the 80's, sorry. :)
> >
> > This matters mainly for commits, right?
>
> Yes. Also the content of the files, but fortunately they are just plain
> ascii most of the time. :)
I've made this changes becausae the german letters like ä, ö, ... are
displayed ugly in the browser.
> > Perhaps I should recode from current locale to utf8 in cg-commit?
>
> Everthing else than utf-8 is just a complete mess with data shared
> across multiple machines. All modern distributions defaulting to utf-8
> anyway, so I think it is sane to recode that utf-8.
>
> Kay
> -
The patch is to _change_ the encoding easy .. or to leave it unchanged.
Thomas
--
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
^ permalink raw reply
* Re: [gitweb PATCH] Configure encoding
From: Kay Sievers @ 2005-05-31 10:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: Thomas Kolejka, Git Mailing List
In-Reply-To: <20050531101217.GA25555@pasky.ji.cz>
On Tue, May 31, 2005 at 12:12:17PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, May 31, 2005 at 11:19:55AM CEST, I got a letter
> where Kay Sievers <kay.sievers@vrfy.org> told me that...
> > On Tue, May 31, 2005 at 09:55:11AM +0200, Thomas Kolejka wrote:
> > > The following patch makes it easy to change the encoding:
> > >
> > >
> > > --- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
> > > +++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
> > > @@ -20,6 +20,9 @@
> > > my $my_uri = $cgi->url(-absolute => 1);
> > > my $rss_link = "";
> > >
> > > +my $encoding = "utf-8";
> > > +$encoding = "iso-8859-1";
> >
> > The upstream version will not support anything but the one and only
> > sane encoding which is utf-8. It will not provide options to switch
> > back to the 80's, sorry. :)
>
> This matters mainly for commits, right?
Yes. Also the content of the files, but fortunately they are just plain
ascii most of the time. :)
> Perhaps I should recode from current locale to utf8 in cg-commit?
Everthing else than utf-8 is just a complete mess with data shared
across multiple machines. All modern distributions defaulting to utf-8
anyway, so I think it is sane to recode that utf-8.
Kay
^ permalink raw reply
* Re: [gitweb PATCH] Configure encoding
From: Petr Baudis @ 2005-05-31 10:12 UTC (permalink / raw)
To: Kay Sievers; +Cc: Thomas Kolejka, Git Mailing List
In-Reply-To: <20050531091955.GA22706@vrfy.org>
Dear diary, on Tue, May 31, 2005 at 11:19:55AM CEST, I got a letter
where Kay Sievers <kay.sievers@vrfy.org> told me that...
> On Tue, May 31, 2005 at 09:55:11AM +0200, Thomas Kolejka wrote:
> > The following patch makes it easy to change the encoding:
> >
> >
> > --- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
> > +++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
> > @@ -20,6 +20,9 @@
> > my $my_uri = $cgi->url(-absolute => 1);
> > my $rss_link = "";
> >
> > +my $encoding = "utf-8";
> > +$encoding = "iso-8859-1";
>
> The upstream version will not support anything but the one and only
> sane encoding which is utf-8. It will not provide options to switch
> back to the 80's, sorry. :)
This matters mainly for commits, right?
Perhaps I should recode from current locale to utf8 in cg-commit?
--
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: [gitweb PATCH] Kill warnings in Webserver Error Log
From: Kay Sievers @ 2005-05-31 9:48 UTC (permalink / raw)
To: Jochen Roemling; +Cc: Git Mailing List
In-Reply-To: <429B6AD4.9010107@roemling.net>
On Mon, May 30, 2005 at 09:34:44PM +0200, Jochen Roemling wrote:
> The following patch kills two warnings in the Web Server Error Log:
>
> [Mon May 30 21:24:15 2005] gitweb.cgi: "my" variable %co masks earlier
> declaration in same scope at /home/www/html/tools/cgi-bin/gitweb.cgi
> line 1658.
> [Mon May 30 21:25:46 2005] gitweb.cgi: "my" variable %co masks earlier
> declaration in same scope at /home/www/html/tools/cgi-bin/gitweb.cgi
> line 1615.
>
> There might be a patch offset of few lines because I deleted my local
> gitweb settings from the patch.
Dou you get the version from:
ftp://ehlo.org/gitweb.cgi
It seems already fixed.
Thanks,
Kay
^ permalink raw reply
* Re: [gitweb PATCH] Configure encoding
From: Kay Sievers @ 2005-05-31 9:19 UTC (permalink / raw)
To: Thomas Kolejka; +Cc: Git Mailing List
In-Reply-To: <1839.1117526111@www5.gmx.net>
On Tue, May 31, 2005 at 09:55:11AM +0200, Thomas Kolejka wrote:
> The following patch makes it easy to change the encoding:
>
>
> --- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
> +++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
> @@ -20,6 +20,9 @@
> my $my_uri = $cgi->url(-absolute => 1);
> my $rss_link = "";
>
> +my $encoding = "utf-8";
> +$encoding = "iso-8859-1";
The upstream version will not support anything but the one and only
sane encoding which is utf-8. It will not provide options to switch
back to the 80's, sorry. :)
Thanks,
Kay
^ permalink raw reply
* Re: git-rev-list: proper lazy reachability
From: Jon Seymour @ 2005-05-31 7:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301847120.1876@ppc970.osdl.org>
On 5/31/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Somebody should probably take a look at my simplistic algorithm, since it
> can probably be improved upon and/or fixed for corner-cases.
Seems reasonable, though I think that in a graph like this:
A
/ | \
B C D
| / /
E
| \
F G
and searching for git-rev-list A ^B
it would actually be better to stop at E (printing A,B,C,D,E), rather
than B because the contemporaneously parallel edits C and D and the
common base E are relevant to evaluating B since they got merged with
B into A from the common starting point E.
In the lingo of my epoch theory, this is searching to the next nearest
epoch boundary past B.
My merge-order patch to rev-list which incorporates epoch theory is
still on its way - it turned out that incrementally finding epoch
boundaries was not quite as simple as I thought it would be. I expect
I'll have a respectable looking patch available this weekend. The
patch I have now works quite well for smaller graphs but fails on
larger graphs because it relies on rational numbers with large
numerators and denominators and these end up overflowing even 64 bit
integers. I think I know how to fix it, but it will take me a few more
days yet.
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* [gitweb PATCH] Configure encoding
From: Thomas Kolejka @ 2005-05-31 7:55 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
The following patch makes it easy to change the encoding:
--- gitweb.cgi.177 2005-05-31 09:43:17.000000000 +0200
+++ gitweb.cgi.p 2005-05-31 09:48:46.000000000 +0200
@@ -20,6 +20,9 @@
my $my_uri = $cgi->url(-absolute => 1);
my $rss_link = "";
+my $encoding = "utf-8";
+$encoding = "iso-8859-1";
+
# absolute fs-path which will be prepended to the project path
my $projectroot = "/pub/scm";
$projectroot = "pub/scm";
@@ -183,9 +186,9 @@
$title .= "/$action";
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8',
-status=> $status);
+ print $cgi->header(-type=>'text/html', -charset => $encoding,
-status=> $status);
print <<EOF;
-<?xml version="1.0" encoding="utf-8"?>
+<?xml version="1.0" encoding="$encoding"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<!-- git web interface v$version, (C) 2005, Kay Sievers
<kay.sievers\@vrfy.org>, Christian Gierke <ch\@gierke.de> -->
@@ -1112,8 +1115,8 @@
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd || die_error(undef, "Reading rev-list failed.");
- print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
- print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
+ print $cgi->header(-type => 'text/xml', -charset => $encoding);
+ print "<?xml version=\"1.0\" encoding=\"$encoding\"?>\n".
"<rss version=\"0.91\">\n";
print "<channel>\n";
print "<title>$project</title>\n".
Thomas
--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
^ 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