* Re: I want to release a "git-1.0"
From: jeff millar @ 2005-05-30 20:33 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
Linus Torvalds wrote:
>So before I do that, is there something people think is just too hard for
>somebody coming from the CVS world to understand?
>
I'm a fairly clueless cvs user, trying to use cg/git as a way to track a
single
user project...using cogito, because that's easier, right?
The usage pattern that causing me problems right now.
cg-init a whole directory tree (trying with /etc and a software project
directory)
note that too many files got included (*.cache, *.backup, *.o, binaries,
etc)
want to stop tracking them, cg-rm also removes the file, don't want that.
What's the best way to stop tracking files?
jeff
^ permalink raw reply
* [PATCH] cg-mkpatch: use git-apply --stat
From: Jonas Fonseca @ 2005-05-30 20:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Change cg-mkpatch to use git-apply --stat instead of optional diffstat.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
cg-mkpatch | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/cg-mkpatch b/cg-mkpatch
--- a/cg-mkpatch
+++ b/cg-mkpatch
@@ -42,7 +42,6 @@ USAGE="cg-mkpatch [-s] [-r REVISION[:REV
. ${COGITO_LIB}cg-Xlib
omit_header=
-has_diffstat=
log_start=
log_end=
mergebase=
@@ -71,11 +70,8 @@ showpatch () {
echo commit $id
cat $header
-
- if [ "$has_diffstat" ]; then
- echo
- cat $patch | diffstat -p1
- fi
+ echo
+ cat $patch | git-apply --stat
fi
;;
*)
@@ -116,10 +112,6 @@ while [ "$1" ]; do
shift
done
-if ! [ "$omit_header" ]; then
- which diffstat >/dev/null 2>&1 && has_diffstat=1
-fi
-
if [ "$mergebase" ]; then
[ "$log_start" ] || log_start="origin"
[ "$log_end" ] || log_end="master"
--
Jonas Fonseca
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Nicolas Pitre @ 2005-05-30 20:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
On Mon, 30 May 2005, Linus Torvalds wrote:
>
> Ok, I'm at the point where I really think it's getting close to a 1.0, and
> make another tar-ball etc.
Any chance you could merge my latest mkdelta patch _please_ ???
I just posted it twice in the last 4 days and it still didn't appear in
your repository.
Again, the current version of mkdelta in your tree has a bug that can
screw things up, and it is fixed in the latest patch of course.
Nicolas
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Junio C Hamano @ 2005-05-30 20:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
I'd really appreciate if you reconsider diff-* -O for inclusion
before 1.0 happens. It is probably the lowest impact among the
diffcore family.
Don't I deserve it ;-)?
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Junio C Hamano @ 2005-05-30 21:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I was showing off raw git to Steve Chamberlain yesterday, and showing it
LT> to him made some things pretty obvious - one of them being that
LT> "git-init-db" really needed to set up the initial refs etc). So I wrote
LT> this silly "git-commit-script" to make it at least half-way palatable, but
LT> what else do people feel is "too hard"?
I think you need to clarify your intended audience first before
soliciting "list of things that would help CVS user to convert
to GIT". Specifically, which variant of GIT you are talking
about.
I think you are talking about using the bare Plumbing. I
suspect that some of the things you said "too hard" may be
coming from the fact that you did not use Cogito in the "showing
off" you did. I imagine Cogito users do not experience the
trouble you felt with git-init-db, since I presume they would
rather use cg-init which IIUIC sets up the .git/refs structure
for its taste.
Having said that, I am in the same camp as you are in, in that
the (secondary) goal of my involvement in this project so far
has been to make the bare Plumbing confortable enough to use, to
make the choice of Porcelain more or less irrelevant. As such,
I am all for such a tutorial to convert CVS people to Plumbing
GIT.
Not that I'd volunteer writing big part of such a document. I
suck at documentation, not just math ;-).
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: David Greaves @ 2005-05-30 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
Linus Torvalds wrote:
>So before I do a 1.0 release, I want to write some stupid git tutorial for
>a complete beginner that has only used CVS before, with a real example of
>how to use raw git, and along those lines I actually want the thing to
>show how to do something useful.
>
>So before I do that, is there something people think is just too hard for
>somebody coming from the CVS world to understand? I already realized that
>the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
>to put into a sane tutorial.
>
>I was showing off raw git to Steve Chamberlain yesterday, and showing it
>to him made some things pretty obvious - one of them being that
>"git-init-db" really needed to set up the initial refs etc). So I wrote
>this silly "git-commit-script" to make it at least half-way palatable, but
>what else do people feel is "too hard"?
>
>I think I'll move the "cvs2git" script thing to git proper before the 1.0
>release (again, in order to have the tutorial able to show what to do if
>you already have an existing CVS tree), what else?
>
>
It seems to me that a tutorial for end users is inappropriate.
You should be writing a tutorial for porcelain implementors :)
Anyway, a while back I split the commands into manipulation and
interrogation and then into ancillary commands and scripts. Do you
actually agree with this grouping?
http://www.kernel.org/pub/software/scm/git/docs/git.html
It may help to position who should be doing what.
Also, if you're writing a git-init-script, it may be that you're simply
scripting common processes and could helpfully maintain consistency by
either pulling some of the really trivial Cogito scripts (cg-init,
cg-add, cg-rm) into the core 'ancillary' area or suggesting
modifications to Cogito as the current 'best of breed' implementation of
the low-level git usage process. Cogito also 'fixes' some useability
issues such as using "git-update-cache --add" == "cg-add"
I know you _can_ use git as an end user - but it seems that it's
designed to be used by plumbers.
Oh, I'd also like to see something along the lines of my cg-Xignore
before git hits 1.0
On the tutorial side - yesterday I started pulling together stuff from
the list about merging to complete the README where it says [ fixme:
talk about resolving merges here ]
I haven't done much other than collect some discussion from the list and
the text from git-read-tree.txt.
I do think this area needs more explanation as the whole 'stage' thing
is pretty alien to CVS.
I also noted a few people asking "so I did this merge - what do I do now?"
The working directory/cache/repository is also confusing sometimes -
especially when the cache and working-dir unexpectedly don't match.
I also see in my notes: "improve the docs around update-cache."
David
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Dave Jones @ 2005-05-30 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
>
> 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.
>
> So before I do a 1.0 release, I want to write some stupid git tutorial for
> a complete beginner that has only used CVS before, with a real example of
> how to use raw git, and along those lines I actually want the thing to
> show how to do something useful.
>
> So before I do that, is there something people think is just too hard for
> somebody coming from the CVS world to understand? I already realized that
> the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
> to put into a sane tutorial.
>
> I was showing off raw git to Steve Chamberlain yesterday, and showing it
> to him made some things pretty obvious - one of them being that
> "git-init-db" really needed to set up the initial refs etc). So I wrote
> this silly "git-commit-script" to make it at least half-way palatable, but
> what else do people feel is "too hard"?
I finally got around to actually trying to use git to maintain the
cpufreq repository the last few days after reading Jeff Garzik's mini-howto[1]
It's not particularly complicated, but the number one thing that's bugged me is this..
# commit changes
GIT_AUTHOR_NAME="John Doe" \
GIT_AUTHOR_EMAIL="jdoe@foo.com" \
GIT_COMMITTER_NAME="Jeff Garzik" \
GIT_COMMITTER_EMAIL="jgarzik@pobox.com" \
git-commit-tree `git-write-tree` \
-p $(cat .git/HEAD ) \
< changelog.txt \
> .git/HEAD
For merging a lot of csets, thats a lot of typing per cset. So my .bashrc
now sets up GIT_COMMITTER_NAME & GIT_COMMITTER_EMAIL, because I don't
foresee myself changing either of those anytime soon, which takes it down
to
GIT_AUTHOR_NAME="John Doe" \
GIT_AUTHOR_EMAIL="jdoe@foo.com" \
git-commit-tree `git-write-tree` \
-p $(cat .git/HEAD ) \
< changelog.txt \
> .git/HEAD
per-cset. Maybe I have early on-set dementia, but the number of times
I've typoed those two remaining environment variables is bizarre.
I must've hit every known combination possible in my merge of ~30 patches.
I could make the latter 4 lines of the above a shell alias to save some
typing, but those shell vars still bug me. Hmm, maybe I could create a
wrapper that splits a "Dave Jones <davej@redhat.com" style string into two vars.
I realise you've got a nifty bunch of tools to apply a whole mbox of
patches, but that's not ideal if all of my patches aren't in mboxes
(some I create myself and toss in my spool, some I pull from bugzilla etc..)
Typos aside, the other thing that seems non-intuitive is the splitting up
of the patch & changelog comment into seperate files during the patch-apply
stage.
Maybe your new git-commit-script wonder-tool fixes up all these problems
already, I'll take a look after food.
Its pretty nifty stuff, but for merging a lot of patches in non-mbox format,
either I'm doing something wrong, or its, well.. painful.
Dave
[1] http://lkml.org/lkml/2005/5/26/11/index.html
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Ryan Anderson @ 2005-05-30 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
>
> I think I'll move the "cvs2git" script thing to git proper before the 1.0
> release (again, in order to have the tutorial able to show what to do if
> you already have an existing CVS tree), what else?
Umm, why do you maintain two seperate "git" related trees?
Why not merge all of git-tools in, in a tools/ subdirectory?
I've been meaning to ask the same question about "gitweb" for that
matter. The distributions that want seperate packages for dependency
reasons can handle that easily inside one tree, anyway, I believe.
I'd guess part of this is a holdover from the fact that you needed an
independent tree for BitKeeper, but does it still make sense?
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Dan Holmsand @ 2005-05-30 22:31 UTC (permalink / raw)
To: git
In-Reply-To: <1117480796.7072.204.camel@pegasus>
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
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).
/dan
[PATCH] Make tree_timewarp safe, by refusing to handle conflicts.
Signed-off-by: Dan Holmsand <holmsand@gmail.com>
[-- Attachment #2: merge.patch.txt --]
[-- Type: text/plain, Size: 2855 bytes --]
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -50,47 +50,22 @@ showdate () {
}
-# Usage: tree_timewarp DIRECTION_STR ROLLBACK_BOOL BASE BRANCH
+# Usage: tree_timewarp BASE BRANCH
tree_timewarp () {
- dirstr=$1; shift
- rollback=$1; shift
- base=$1; shift
- branch=$1; shift
-
- patchfile=$(mktemp -t gituncommit.XXXXXX)
- if [ "$rollback" ]; then
- cg-diff >$patchfile
- [ -s "$patchfile" ] &&
- echo "Warning: uncommitted local changes, trying to bring them $dirstr" >&2
- else
- # XXX: This may be suboptimal, but it is also non-trivial to keep
- # the adds/removes properly. So this is just a quick hack to get it
- # working without much fuss.
- cg-diff -r $branch >$patchfile
- fi
-
- git-read-tree -m "$branch" || die "$branch: bad commit"
- echo "$branch" > $_git/HEAD
-
- # Kill gone files
- git-diff-tree -z -r $base $branch | xargs -0 bash -c '
- while [ "$1" ]; do
- header="$1"; shift
- file="$1"; shift
-
- # match ":100755 000000 14d43b1abf... 000000000... D"
- if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
- rm -- "$file"
- fi
- done
- ' padding
- git-checkout-cache -f -a
-
- # FIXME: Can produce bogus "contains only garbage" messages.
- cat $patchfile | cg-patch
- rm $patchfile
+ local conflicts base=$1 branch=$2
git-update-cache --refresh >/dev/null
+ conflicts=$( (git-diff-tree -r $base $branch;
+ git-diff-cache -r HEAD) | cut -f2- | sort | uniq -d )
+ [ -z "$conflicts" ] ||
+ die "conflicting uncommitted changes: $conflicts"
+
+ git-read-tree -m $branch || die "read-tree failed"
+ git-diff-tree -r $base $branch | cut -f5- -d' ' | grep '^[NM]' |
+ cut -f2- | tr \\n \\0 | xargs -0 git-checkout-cache -u -f --
+ git-diff-tree -r $base $branch | cut -f5- -d' ' | grep '^[D]' |
+ cut -f2- | tr \\n \\0 | xargs -0 rm -f --
+ echo "$branch" > $_git/HEAD
}
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -39,10 +39,15 @@ commit=$(commit-id "$1") || exit 1
git-rev-list $base | grep -q $commit || \
die "$commit: not an ancestor of HEAD"
-parent=$(parent-id "$commit") || exit 1
+parent=$(parent-id "$commit" | head -n 1) || exit 1
[ "$parent" ] || die "cannot rewind behind the initial commit"
echo "Rewinding $base (HEAD) -> $parent" >&2
-tree_timewarp "backwards" "$rollback_tree" $base $parent
+if [ "$rollback_tree" ]; then
+ tree_timewarp $base $parent
+else
+ git-read-tree -m $parent || die "git-read-tree failed"
+ echo "$parent" > $_git/HEAD
+fi
diff --git a/cg-merge b/cg-merge
--- a/cg-merge
+++ b/cg-merge
@@ -65,7 +65,7 @@ if [ "$head" = "$base" ]; then
echo "Fast-forwarding $base -> $branch" >&2
echo -e "\ton top of $head..." >&2
- tree_timewarp "forward" "yes, rollback (or rather rollforth) the tree!" $base $branch
+ tree_timewarp $base $branch
exit 0
fi
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Chris Wedgwood @ 2005-05-30 22:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
> So before I do that, is there something people think is just too
> hard for somebody coming from the CVS world to understand? I already
> realized that the "git-write-tree" + "git-commit-tree" interfaces
> were just _too_ hard to put into a sane tutorial.
I'm still at a loss how to do the equivalent of annotate. I know a
couple of front ends can do this but I have no idea what command line
magic would be equivalent.
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Dmitry Torokhov @ 2005-05-30 22:55 UTC (permalink / raw)
To: git; +Cc: Dave Jones, Linus Torvalds
In-Reply-To: <20050530221214.GA29556@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Monday 30 May 2005 17:12, Dave Jones wrote:
> I realise you've got a nifty bunch of tools to apply a whole mbox of
> patches, but that's not ideal if all of my patches aren't in mboxes
> (some I create myself and toss in my spool, some I pull from bugzilla etc..)
I mercilessly hacked Linus's scripts from git-tools repo to work with
non-mailbox patches, maybe you can make use of them too. Note that
stripspace.c is not changed in any way whatsoever and mailsplit.c was
changed to handle my personal preference of having patch description
in the form of:
Input: make blah blah change
---
And Linus's script would eat that line.
--
Dmitry
[-- Attachment #2: applypatch --]
[-- Type: application/x-shellscript, Size: 888 bytes --]
[-- Attachment #3: apply_parsed_patch --]
[-- Type: application/x-shellscript, Size: 2123 bytes --]
[-- Attachment #4: stripspace.c --]
[-- Type: text/x-csrc, Size: 786 bytes --]
#include <stdio.h>
#include <string.h>
#include <ctype.h>
/*
* Remove empty lines from the beginning and end.
*
* Turn multiple consecutive empty lines into just one
* empty line.
*/
static void cleanup(char *line)
{
int len = strlen(line);
if (len > 1 && line[len-1] == '\n') {
do {
unsigned char c = line[len-2];
if (!isspace(c))
break;
line[len-2] = '\n';
len--;
line[len] = 0;
} while (len > 1);
}
}
int main(int argc, char **argv)
{
int empties = -1;
char line[1024];
while (fgets(line, sizeof(line), stdin)) {
cleanup(line);
/* Not just an empty line? */
if (line[0] != '\n') {
if (empties > 0)
putchar('\n');
empties = 0;
fputs(line, stdout);
continue;
}
if (empties < 0)
continue;
empties++;
}
return 0;
}
[-- Attachment #5: mailsplit.c --]
[-- Type: text/x-csrc, Size: 2526 bytes --]
/*
* Totally braindamaged mbox splitter program.
*
* It just splits a mbox into a list of files: "0001" "0002" ..
* so you can process them further from there.
*/
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <string.h>
#include <stdio.h>
#include <ctype.h>
#include <assert.h>
static int usage(void)
{
fprintf(stderr, "mailsplit <mbox> <directory>\n");
exit(1);
}
static int linelen(const char *map, unsigned long size)
{
int len = 0, c;
do {
c = *map;
map++;
size--;
len++;
} while (size && c != '\n');
return len;
}
static int is_from_line(const char *line, int len)
{
const char *colon;
if (len < 20 || memcmp("From ", line, 5))
return 0;
colon = line + len - 2;
line += 5;
for (;;) {
if (colon < line)
return 0;
if (*--colon == ':')
break;
}
if (!isdigit(colon[-4]) ||
!isdigit(colon[-2]) ||
!isdigit(colon[-1]) ||
!isdigit(colon[ 1]) ||
!isdigit(colon[ 2]))
return 0;
/* year */
if (strtol(colon+3, NULL, 10) <= 90)
return 0;
/* Ok, close enough */
return 1;
}
static int parse_email(const void *map, unsigned long size)
{
unsigned long offset;
if (size < 6 || memcmp("From ", map, 5))
goto corrupt;
/* Make sure we don't trigger on this first line */
map++; size--; offset=1;
/*
* Search for a line beginning with "From ", and
* having smething that looks like a date format.
*/
do {
int len = linelen(map, size);
if (is_from_line(map, len))
return offset;
map += len;
size -= len;
offset += len;
} while (size);
return offset;
corrupt:
fprintf(stderr, "corrupt mailbox\n");
exit(1);
}
int main(int argc, char **argv)
{
int fd, nr;
struct stat st;
unsigned long size;
void *map;
if (argc != 3)
usage();
fd = open(argv[1], O_RDONLY);
if (fd < 0) {
perror(argv[1]);
exit(1);
}
if (chdir(argv[2]) < 0)
usage();
if (fstat(fd, &st) < 0) {
perror("stat");
exit(1);
}
size = st.st_size;
map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
if (-1 == (int)(long)map) {
perror("mmap");
exit(1);
}
close(fd);
nr = 0;
do {
char name[10];
unsigned long len = parse_email(map, size);
assert(len <= size);
sprintf(name, "%04d", ++nr);
fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0600);
if (fd < 0) {
perror(name);
exit(1);
}
if (write(fd, map, len) != len) {
perror("write");
exit(1);
}
close(fd);
map += len;
size -= len;
} while (size > 0);
return 0;
}
^ permalink raw reply
* Re: More gitweb queries..
From: Paul Mackerras @ 2005-05-30 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505271145570.17402@ppc970.osdl.org>
Linus Torvalds writes:
> On that small note, I also find "gitk" very cool indeed, too bad about
> the fact that tk/tcl seems to always end up looking so _ugly_. Is there
> any way to get anti-aliased fonts and a less 'Motify' blocky look from
> tcl/tk? Every time I see that, I feel like I'm back in the last century
> or something.
Tcl/Tk 8.5 will have anti-aliased fonts (8.5a2 is available on
sourceforge). There is apparently some support for widget styling in
8.4 which I will have to look into. The Motif look doesn't bother me,
but it does seem to bother you and Ben H. :)
> Combining some of the features of the two (that über-cool revision
> history graph from gitk rules, for example) might be cool. I get the
> urge to do octopus-merges in the kernel just because of how good they
> look in gitk ;) ]
Yes, it's nice that a relatively simple algorithm without much
lookahead produces reasonable results.
Paul.
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Junio C Hamano @ 2005-05-30 23:15 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <200505301755.15371.dtor_core@ameritech.net>
On a related topic of making bare Plumbing a bit easier to use,
here is what I use to prepare patches, one patch per file, to be
sent to Linus via e-mail.
Usage:
$ git-format-patch-script HEAD linus
Assuming that "linus" is the tip of the tree from Linus
(typically stored in .git/branches/linus if you use Cogito), and
HEAD is your additions on top of it, the above command will
produce patches in the format you have been seeing on this list
from me, one file per commit, in .patches/XXXX-patch-title.txt
file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sed -e 's/^X//' >git-format-patch-script <<\EOF
X#!/bin/sh
X#
X# Copyright (c) 2005 Junio C Hamano
X#
Xjunio="$1"
Xlinus="$2"
X
Xtmp=.tmp-series$$
Xtrap 'rm -f $tmp-*' 0 1 2 3 15
X
Xseries=$tmp-series
X
XtitleScript='
X 1,/^$/d
X : loop
X /^$/b loop
X s/[^-a-z.A-Z_0-9]/-/g
X s/^--*//g
X s/--*$//g
X s/---*/-/g
X s/$/.txt/
X s/\.\.\.*/\./g
X q
X'
XO=
Xif test -f .git/patch-order
Xthen
X O=-O.git/patch-order
Xfi
Xgit-rev-list "$junio" "$linus" >$series
Xtotal=`wc -l <$series`
Xi=$total
Xwhile read commit
Xdo
X title=`git-cat-file commit "$commit" | sed -e "$titleScript"`
X num=`printf "%d/%d" $i $total`
X file=`printf '%04d-%s' $i "$title"`
X i=`expr "$i" - 1`
X echo "$file"
X {
X mailScript='
X 1,/^$/d
X : loop
X /^$/b loop
X s|^|[PATCH '"$num"'] |
X : body
X p
X n
X b body'
X
X git-cat-file commit "$commit" | sed -ne "$mailScript"
X echo '---'
X git-diff-tree -p $O "$commit" | diffstat -p1
X echo
X git-diff-tree -p $O "$commit"
X } >".patches/$file"
Xdone <$series
EOF
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Dmitry Torokhov @ 2005-05-30 23:23 UTC (permalink / raw)
To: git; +Cc: Dave Jones, Linus Torvalds
In-Reply-To: <200505301755.15371.dtor_core@ameritech.net>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Monday 30 May 2005 17:55, Dmitry Torokhov wrote:
> On Monday 30 May 2005 17:12, Dave Jones wrote:
> > I realise you've got a nifty bunch of tools to apply a whole mbox of
> > patches, but that's not ideal if all of my patches aren't in mboxes
> > (some I create myself and toss in my spool, some I pull from bugzilla etc..)
>
> I mercilessly hacked Linus's scripts from git-tools repo to work with
> non-mailbox patches, maybe you can make use of them too. Note that
> stripspace.c is not changed in any way whatsoever and mailsplit.c was
> changed to handle my personal preference of having patch description
> in the form of:
>
> Input: make blah blah change
> ---
>
> And Linus's script would eat that line.
>
Oops, make it mailinfo.c, not mailsplit.c
--
Dmitry
[-- Attachment #2: mailinfo.c --]
[-- Type: text/x-csrc, Size: 5691 bytes --]
/*
* Another stupid program, this one parsing the headers of an
* email to figure out authorship and subject
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
static FILE *cmitmsg, *patchfile, *filelist;
static char line[1000];
static char date[1000];
static char name[1000];
static char email[1000];
static char subject[1000];
static char *sanity_check(char *name, char *email)
{
int len = strlen(name);
if (len < 3 || len > 60)
return email;
if (strchr(name, '@') || strchr(name, '<') || strchr(name, '>'))
return email;
return name;
}
static int handle_from(char *line)
{
char *at = strchr(line, '@');
char *dst;
if (!at)
return 0;
/*
* If we already have one email, don't take any confusing lines
*/
if (*email && strchr(at + 1, '@'))
return 0;
while (at > line) {
char c = at[-1];
if (isspace(c) || c == '<')
break;
at--;
}
dst = email;
for (;;) {
unsigned char c = *at;
if (!c || c == '>' || isspace(c))
break;
*at++ = ' ';
*dst++ = c;
}
*dst++ = 0;
at = line + strlen(line);
while (at > line) {
unsigned char c = *--at;
if (isalnum(c))
break;
*at = 0;
}
at = line;
for (;;) {
unsigned char c = *at;
if (!c)
break;
if (isalnum(c))
break;
at++;
}
at = sanity_check(at, email);
strcpy(name, at);
return 1;
}
static void handle_date(char *line)
{
strcpy(date, line);
}
static void handle_subject(char *line)
{
strcpy(subject, line);
}
static void add_subject_line(char *line)
{
while (isspace(*line))
line++;
*--line = ' ';
strcat(subject, line);
}
static int check_special_line(char *line, int len)
{
static int cont = -1;
if (!memcmp(line, "From:", 5) && isspace(line[5])) {
handle_from(line + 6);
cont = 0;
return 1;
}
if (!memcmp(line, "Date:", 5) && isspace(line[5])) {
handle_date(line + 6);
cont = 0;
return 1;
}
if (!memcmp(line, "Subject:", 8) && isspace(line[8])) {
handle_subject(line + 9);
cont = 1;
return 1;
}
if (isspace(*line)) {
switch (cont) {
case 0:
fprintf(stderr,
"I don't do 'Date:' or 'From:' line continuations\n");
break;
case 1:
add_subject_line(line);
return 1;
default:
break;
}
}
cont = -1;
return 0;
}
static char *cleanup_subject(char *subject)
{
for (;;) {
char *p;
int len, remove;
switch (*subject) {
case 'r':
case 'R':
if (!memcmp("e:", subject + 1, 2)) {
subject += 3;
continue;
}
break;
case ' ':
case '\t':
case ':':
subject++;
continue;
case '[':
p = strchr(subject, ']');
if (!p) {
subject++;
continue;
}
len = strlen(p);
remove = p - subject;
if (remove <= len * 2) {
subject = p + 1;
continue;
}
break;
}
return subject;
}
}
static void cleanup_space(char *buf)
{
unsigned char c;
while ((c = *buf) != 0) {
buf++;
if (isspace(c)) {
buf[-1] = ' ';
c = *buf;
while (isspace(c)) {
int len = strlen(buf);
memmove(buf, buf + 1, len);
c = *buf;
}
}
}
}
/*
* Hacky hacky. This depends not only on -p1, but on
* filenames not having some special characters in them,
* like tilde.
*/
static void show_filename(char *line)
{
int len;
char *name = strchr(line, '/');
if (!name || !isspace(*line))
return;
name++;
len = 0;
for (;;) {
unsigned char c = name[len];
switch (c) {
default:
len++;
continue;
case 0:
case ' ':
case '\t':
case '\n':
break;
/* patch tends to special-case these things.. */
case '~':
break;
}
break;
}
/* remove ".orig" from the end - common patch behaviour */
if (len > 5 && !memcmp(name + len - 5, ".orig", 5))
len -= 5;
if (!len)
return;
fprintf(filelist, "%.*s\n", len, name);
}
static void handle_rest(void)
{
char *sub = cleanup_subject(subject);
cleanup_space(name);
cleanup_space(date);
cleanup_space(email);
cleanup_space(sub);
printf("Author: %s\nEmail: %s\nSubject: %s\nDate: %s\n\n", name, email,
sub, date);
FILE *out = cmitmsg;
do {
/* Track filename information from the patch.. */
if (!memcmp("---", line, 3)) {
out = patchfile;
show_filename(line + 3);
}
if (!memcmp("+++", line, 3))
show_filename(line + 3);
fputs(line, out);
} while (fgets(line, sizeof(line), stdin) != NULL);
if (out == cmitmsg) {
fprintf(stderr, "No patch found\n");
exit(1);
}
fclose(cmitmsg);
fclose(patchfile);
}
static int eatspace(char *line)
{
int len = strlen(line);
while (len > 0 && isspace(line[len - 1]))
line[--len] = 0;
return len;
}
static void handle_body(void)
{
int has_from = 0;
/* First line of body can be a From: */
while (fgets(line, sizeof(line), stdin) != NULL) {
int len = eatspace(line);
if (!len)
continue;
if (!memcmp("From:", line, 5) && isspace(line[5])) {
if (!has_from && handle_from(line + 6)) {
has_from = 1;
continue;
}
}
line[len] = '\n';
handle_rest();
break;
}
}
static void usage(void)
{
fprintf(stderr, "mailinfo msg-file path-file filelist-file < email\n");
exit(1);
}
int main(int argc, char **argv)
{
int mail_patch = 0;
if (argc != 4)
usage();
cmitmsg = fopen(argv[1], "w");
if (!cmitmsg) {
perror(argv[1]);
exit(1);
}
patchfile = fopen(argv[2], "w");
if (!patchfile) {
perror(argv[2]);
exit(1);
}
filelist = fopen(argv[3], "w");
if (!filelist) {
perror(argv[3]);
exit(1);
}
while (fgets(line, sizeof(line), stdin) != NULL) {
int len = eatspace(line);
if (!len) {
if (!mail_patch)
fputs("\n", cmitmsg);
handle_body();
break;
}
if (check_special_line(line, len)) {
mail_patch = 1;
rewind(cmitmsg);
}
if (!mail_patch) {
line[len] = '\n';
fputs(line, cmitmsg);
}
}
return 0;
}
^ permalink raw reply
* [PATCH] Show dissimilarity index for D and N case.
From: Junio C Hamano @ 2005-05-30 23:40 UTC (permalink / raw)
To: torvalds; +Cc: git
The way broken deletes and creates are shown in the -p
(diff-patch) output format has become consistent with how
rename/copy edits are shown. They will show "dissimilarity
index" value, immediately following the "deleted file mode" and
"new file mode" lines.
The git-apply is taught to grok such an extended header.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 6 ++++++
diff.c | 20 ++++++++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -336,6 +336,11 @@ static int gitdiff_similarity(const char
return 0;
}
+static int gitdiff_dissimilarity(const char *line, struct patch *patch)
+{
+ return 0;
+}
+
/*
* This is normal for a diff that doesn't change anything: we'll fall through
* into the next diff. Tell the parser to break out.
@@ -437,6 +442,7 @@ static int parse_git_header(char *line,
{ "rename from ", gitdiff_renamesrc },
{ "rename to ", gitdiff_renamedst },
{ "similarity index ", gitdiff_similarity },
+ { "dissimilarity index ", gitdiff_dissimilarity },
{ "", gitdiff_unrecognized },
};
int i;
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -132,10 +132,16 @@ static void builtin_diff(const char *nam
diff_arg, input_name_sq[0], input_name_sq[1]);
printf("diff --git a/%s b/%s\n", name_a, name_b);
- if (!path1[0][0])
+ if (!path1[0][0]) {
printf("new file mode %s\n", temp[1].mode);
- else if (!path1[1][0])
+ if (xfrm_msg && xfrm_msg[0])
+ puts(xfrm_msg);
+ }
+ else if (!path1[1][0]) {
printf("deleted file mode %s\n", temp[0].mode);
+ if (xfrm_msg && xfrm_msg[0])
+ puts(xfrm_msg);
+ }
else {
if (strcmp(temp[0].mode, temp[1].mode)) {
printf("old mode %s\n", temp[0].mode);
@@ -733,6 +739,16 @@ static void diff_flush_patch(struct diff
p->one->path, p->two->path);
msg = msg_;
break;
+ case 'D': case 'N':
+ if (DIFF_PAIR_BROKEN(p)) {
+ sprintf(msg_,
+ "dissimilarity index %d%%",
+ (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ msg = msg_;
+ }
+ else
+ msg = NULL;
+ break;
default:
msg = NULL;
}
------------
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Chris Wedgwood @ 2005-05-30 23:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <972477.0a6782ba1d3b9f05216ed520ef720fcf.ANY@taniwha.stupidest.org>
On Mon, May 30, 2005 at 03:32:42PM -0700, Chris Wedgwood wrote:
> I'm still at a loss how to do the equivalent of annotate. I know a
> couple of front ends can do this but I have no idea what command line
> magic would be equivalent.
A few people asked what does this now. Git Tracker does, a (random)
example of which might be:
http://www.tglx.de/cgi-bin/gittracker/annotate/tracker-linux/torvalds/linux-2.6.git/mm/mmap.c?blob=de54acd9942f9929004921042721df5cdfe2b6c7
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Petr Baudis @ 2005-05-31 0:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505301253070.1876@ppc970.osdl.org>
Dear diary, on Mon, May 30, 2005 at 10:00:42PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> 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.
Can we (well, me) count on the output format of the git commands being
stabilized now and not change in a backwards-incompatible way from now
on? I would like to finally remove the git itself from Cogito, but for
that I have to be able to rely on the fact that as long as the user has
git version >=N, it will work (assuming that Cogito is bugless ;-).
> So before I do a 1.0 release, I want to write some stupid git tutorial for
> a complete beginner that has only used CVS before, with a real example of
> how to use raw git, and along those lines I actually want the thing to
> show how to do something useful.
Is there actually much point in using raw git directly? You don't
usually invoke the syscalls directly from the user programs either (and
you usually actually use stdio for the casual stuff). I guess the
raw git usage can get quite long and tiresome sometimes.
--
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: I want to release a "git-1.0"
From: Linus Torvalds @ 2005-05-31 0:52 UTC (permalink / raw)
To: Dave Jones; +Cc: Git Mailing List
In-Reply-To: <20050530221214.GA29556@redhat.com>
On Mon, 30 May 2005, Dave Jones wrote:
>
> GIT_AUTHOR_NAME="John Doe" \
> GIT_AUTHOR_EMAIL="jdoe@foo.com" \
> git-commit-tree `git-write-tree` \
> -p $(cat .git/HEAD ) \
> < changelog.txt \
> > .git/HEAD
You _really_ want to script this.
Also, I'd seriously suggest you avoid using ".git/HEAD" _and_ writing to
.git/HEAD in the same command. Maybe it works, maybe it doesn't.
So script it with something like
#!/bin/sh
export GIT_AUTHOR_NAME="$1"
export GIT_AUTHOR_EMAIL="$2"
tree=$(git-write-tree) || exit 1
commit=$(git-commit-tree $tree -p HEAD) || exit 1
echo $commit > .git/HEAD
and now you can just do
commit-as "John Doe" "jdoe@foo.com" < changelog.txt
or something like that.
The git commands really are designed to be scripted.
Linus
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Linus Torvalds @ 2005-05-31 0:58 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Git Mailing List
In-Reply-To: <20050530221922.GC21076@mythryan2.michonline.com>
On Mon, 30 May 2005, Ryan Anderson wrote:
>
> Umm, why do you maintain two seperate "git" related trees?
Well, my "tools" thing really isn't git proper, and may not make much
sense in the git distribution.
That said, I'm actually moving things into git as they turn useful. For
example, I move the "stripspace" program into git (which means it got
renamed into "git-stripspace", since it ended up being useful for the
stand-alone git-commit-scripts too.
But how many non-Linux projects really apply mailboxes of patches? It
doesn't seem to be very "core".
> Why not merge all of git-tools in, in a tools/ subdirectory?
I'll think about it. It does look like at least about half of the git
tools end up being pretty core.
> I've been meaning to ask the same question about "gitweb" for that
> matter.
Well, there the issue definitely boils down to "different maintainers". I
don't want to connect things that don't need to be connected.
> I'd guess part of this is a holdover from the fact that you needed an
> independent tree for BitKeeper, but does it still make sense?
Well, I see the "tools" thing really as my private tools that may or may
not make sense for anybody else. Even the cvs2git thing is just so
_stupid_, since I bet you can do it quite cleanly in perl without having
that strange "convert cvsps output into a shellscript" stage (admittedly,
it was _really_ convenient for debugging to have that separate stage, so
while it looks a bit hacky, it ended up being very powerful).
Linus
^ permalink raw reply
* Re: I want to release a "git-1.0"
From: Linus Torvalds @ 2005-05-31 1:06 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Git Mailing List
In-Reply-To: <972477.0a6782ba1d3b9f05216ed520ef720fcf.ANY@taniwha.stupidest.org>
On Mon, 30 May 2005, Chris Wedgwood wrote:
>
> I'm still at a loss how to do the equivalent of annotate. I know a
> couple of front ends can do this but I have no idea what command line
> magic would be equivalent.
There isn't any. It's actually pretty nasty to do, following history
backwards and keeping track of lines as they are added. I know how, I'm
just really lazy and hoping somebody else will do it, since I really end
up not caring that much myself.
I notice that Thomas Gleixner seems to have one, but that one is based on
a database, and doesn't look usable as a standalone command..
Linus
^ permalink raw reply
* Re: [COGITO PATCH] Fix cg-log and cg-status for non-GNU sed/sort
From: Mark Allen @ 2005-05-31 1:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050529234911.GZ1036@pasky.ji.cz>
--- Petr Baudis <pasky@ucw.cz> wrote:
> I think we don't really need -r anyway. Could you please try with the
> 'i' flag instead of 'I'? (The manpage is somewhat unclear on the
> difference and portability.) Also, could you try if it works with the
> newlines?
I tried with an i\ which is what the sed on Darwin wants, and it didn't work very well...
so, I just removed the I and i\ and that worked pretty nicely. I shaved off the -r and
made for a simpler patch.
I also added $has_gnudate to cg-Xlib and modified the logic in showdate to use the
appropriate command depending on whether $has_gnudate is true or false.
Finally, I stripped the -z from sort because it seems to do the right thing anyway
without it and it makes the sort on Darwin unhappy.
Anyway, here's another try, this against the tip of the most recent cogito tree.
---
Modify cg-log, cg-Xlib and cg-status for non-GNU sed, sort and date.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -42,9 +42,13 @@ mktemp () {
showdate () {
date="$1"
sec=${date[0]}; tz=${date[1]}
- dtz=${tz/+/}
- lsec=$(expr $dtz / 100 \* 3600 + $dtz % 100 \* 60 + $sec)
- pdate="$(date -Rud "1970-01-01 UTC + $lsec sec" 2>/dev/null)"
+ if [ ! "$has_gnudate" ]; then
+ pdate="$(date -u -r ${date[0]} 2>/dev/null)"
+ else
+ dtz=${tz/+/}
+ lsec=$(expr $dtz / 100 \* 3600 + $dtz % 100 \* 60 + $sec)
+ pdate="$(date -Rud "1970-01-01 UTC + $lsec sec" 2>/dev/null)"
+ fi
echo "${pdate/+0000/$tz}"
}
@@ -137,3 +141,4 @@ fi
export BROKEN_MKTEMP=1
del=$($(which mktemp) -t 2>/dev/null) && { rm $del; export BROKEN_MKTEMP=; }
+has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
diff --git a/cg-log b/cg-log
--- a/cg-log
+++ b/cg-log
@@ -190,8 +190,7 @@ $revls | $revsort | while read time comm
date=(${rest#*> })
pdate="$(showdate $date)"
if [ "$pdate" ]; then
- echo -n $color$key $rest | sed "s/>.*/>
$pdate/"
- echo $coldefault
+ echo -n $color$key $rest | sed "s/>.*/>
$pdate$coldefault/"
else
echo $color$key $rest $coldefault
fi
@@ -208,9 +207,9 @@ $revls | $revsort | while read time comm
if [ -n "$list_files" ]; then
list_commit_files "$tree1" "$tree2"
fi
- echo; sed -re '
- / *Signed-off-by:.*/Is//'$colsignoff'&'$
coldefault'/
- / *Acked-by:.*/Is//'$colsignoff'&'$colde
fault'/
+ echo; sed -e '
+ / *Signed-off-by:.*/s//'$colsignoff'&'$c
oldefault'/
+ / *Acked-by:.*/s//'$colsignoff'&'$coldef
ault'/
s/./ &/
'
;;
diff --git a/cg-status b/cg-status
--- a/cg-status
+++ b/cg-status
@@ -41,7 +41,7 @@ fi
{
git-ls-files -z -t --others --deleted --unmerged $EXCLUDE
-} | sort -z -k 2 | xargs -0 sh -c '
+} | sort -k 2 | xargs -0 sh -c '
while [ "$1" ]; do
tag=${1% *};
filename=${1#* };
^ permalink raw reply
* Re: [PATCH] Cleanup cogito command usage reporting
From: Jonas Fonseca @ 2005-05-31 1:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050530084558.GE1036@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote Mon, May 30, 2005:
> Dear diary, on Mon, May 30, 2005 at 05:05:21AM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> told me that...
> > [ Sorry for the resend. This should bring all usage strings in sync. I
> > forgot to add the new options. ]
> >
> > - Synchronize usage strings with those in cg-help. The command
> > identifiers are still not as descriptive, though.
>
> Ok, I'll focus on this point (the rest seems fine). I think it's
> inferior this way, since you are losing information, and for no benefit.
Yes, I was thinking more about getting nice simple generic command
identifiers that was easy to describe than thinking about self
documenting usage strings.
> > diff --git a/cg-clone b/cg-clone
> > --- a/cg-clone
> > +++ b/cg-clone
> > @@ -15,11 +15,12 @@
> > -USAGE="cg-clone [-s] LOCATION [<directory>]"
> > +USAGE="cg-clone [-s] LOCATION [DESTINATION]"
> > @@ -30,7 +31,7 @@ if [ "$1" = "-s" ]; then
> > fi
> >
> > location=$1
> > -[ "$location" ] || die "usage: cg-clone [-s] SOURCE_LOC [DESTDIR]"
> > +[ "$location" ] || usage
>
> LOCATION -> SOURCE_LOC is fine in this context (if we would ever want
> DEST_LOC, it would be better to stick with SOURCE_LOC, though). But
> DESTDIR->DESTINATION is losing information. In cogito.txt you describe
> DESTINATION as a general target location, but it's really a directory
> here. And it's shorter.
Done. Apart from the SOURCE_LOC.
> > diff --git a/cg-export b/cg-export
> > --- a/cg-export
> > +++ b/cg-export
> > @@ -22,7 +22,7 @@ USAGE="cg-export DESTINATION [TREE]"
> > dest=$1
> > id=$(tree-id $2)
> >
> > -([ "$dest" ] && [ "$id" ]) || die "usage: cg-export DEST [TREE_ID]"
> > +([ "$dest" ] && [ "$id" ]) || usage
>
> I'm for DESTDIR here too, and what harm does the _ID part make here? I
> think it's non-obvious otherwise - "TREE" can be understood as some
> directory name too.
TREE_ID it is and then DESTFILE (since it expects *.tar.* argument).
> > diff --git a/cg-help b/cg-help
> > --- a/cg-help
> > +++ b/cg-help
> > @@ -43,7 +43,7 @@ Available commands:
> > cg-export DEST [TREE_ID]
> > cg-help [COMMAND]
> > cg-init
> > - cg-log [-c] [-f] [-m] [-r FROM_ID[:TO_ID]] [FILE]...
> > + cg-log [-c] [-f] [-m] [-uUSERNAME] [-r FROM_ID[:TO_ID]] [FILE]...
> > cg-ls [TREE_ID]
> > cg-merge [-c] [-b BASE_ID] FROM_ID
> > cg-mkpatch [-m] [-s] [-r FROM_ID[:TO_ID]]
>
> So what about bringing those in sync too? (Or alternatively letting it
> be now and build the output dynamically in another patch.)
Dropped.
> > diff --git a/cg-merge b/cg-merge
> > --- a/cg-merge
> > +++ b/cg-merge
> > @@ -38,11 +38,11 @@ fi
> > base=
> > if [ "$1" = "-b" ]; then
> > shift
> > - [ "$1" ] || die "usage: cg-merge [-c] [-b BASE_ID] FROM_ID"
> > + [ "$1" ] || usage
>
> I think BASE_ID->REVISION is loosing information too. What about
> BASE_COMMIT or something?
Changed to BASE_COMMIT.
===
Cleanup USAGE strings to be more self-documenting like those listed in
cg-help but with the following changes:
BNAME -> BRANCHNAME
TNAME -> TAGNAME
OBJTYPE -> OBJECT_TYPE
Updated the cogito manpage to reflect the change of command identifiers.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/make-cogito-asciidoc | 16 +++++++---------
cg-Xlib | 3 +++
cg-add | 2 +-
cg-admin-lsobj | 2 +-
cg-admin-uncommit | 2 +-
cg-branch-add | 4 ++--
cg-clone | 5 +++--
cg-commit | 4 ++--
cg-diff | 4 ++--
cg-export | 4 ++--
cg-help | 2 +-
cg-log | 4 ++--
cg-ls | 2 +-
cg-merge | 8 ++++----
cg-mkpatch | 4 ++--
cg-pull | 2 +-
cg-rm | 2 +-
cg-seek | 2 +-
cg-tag | 4 ++--
cg-update | 2 +-
20 files changed, 40 insertions(+), 38 deletions(-)
diff --git a/Documentation/make-cogito-asciidoc b/Documentation/make-cogito-asciidoc
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -106,20 +106,17 @@ $(print_command_listing $HELPER_COMMANDS
Command Identifiers
-------------------
-BRANCH::
- Indicates a branch name added with the $(link cg-branch-add) name.
+BRANCH_NAME::
+ Indicates a branch name added with the $(link cg-branch-add) command.
COMMAND::
Indicates a 'Cogito' command. The \`cg-\` prefix is optional.
-DESTINATION::
- Indicates a path to a location file.
-
LOCATION::
Indicates a local file path or a URI. See $(link cg-branch-add) for a
list of supported URI schemes.
-REVISION::
+COMMIT_ID, FROM_ID, TO_ID, BASE_COMMIT::
Indicates an ID resolving to a commit. The following expressions can
be used interchangably as IDs:
- empty string, 'this' or 'HEAD' (current HEAD)
@@ -129,17 +126,18 @@ REVISION::
- commit object hash (as returned by 'commit-id')
- tree object hash (as returned by 'tree-id')
-TAG::
+TAG_NAME::
Indicates a free form tag name.
-TYPE::
+OBJECT_TYPE::
Indicates a git object type i.e.: 'blob', 'commit', 'tree' or 'tag'.
USERNAME::
Indicates a free form user name.
FILE::
- Indicates a filename - always relative to the root of the repository.
+ Indicates an already existing filename - always relative to the root
+ of the repository.
COPYRIGHT
---------
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -17,6 +17,9 @@ die () {
exit 1
}
+usage() {
+ die "usage: $USAGE"
+}
mktemp () {
if [ ! "$BROKEN_MKTEMP" ]; then
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -17,7 +17,7 @@ USAGE="cg-add FILE..."
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || die "usage: cg-add FILE..."
+[ "$1" ] || usage
TMPFILE=$(mktemp -t gitadd.XXXXXX)
find "$@" -type f > $TMPFILE || die "not all files exist, nothing added"
diff --git a/cg-admin-lsobj b/cg-admin-lsobj
--- a/cg-admin-lsobj
+++ b/cg-admin-lsobj
@@ -35,7 +35,7 @@
# echo -e "\n==================\nme $i"; cat-file commit $i;
# done
-USAGE="cg-admin-lsobj [TYPE]"
+USAGE="cg-admin-lsobj [OBJECT_TYPE]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -17,7 +17,7 @@
# therefore generating tree with local changes against the target
# commit, consisting of the changes in the rolled back commits.
-USAGE="cg-admin-uncommit [-t] [REVISION]"
+USAGE="cg-admin-uncommit [-t] [COMMIT_ID]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-branch-add b/cg-branch-add
--- a/cg-branch-add
+++ b/cg-branch-add
@@ -30,14 +30,14 @@
#
# and refer to it as 'repo-testing' anytime later.
-USAGE="cg-branch-add BRANCH LOCATION"
+USAGE="cg-branch-add BRANCH_NAME LOCATION"
. ${COGITO_LIB}cg-Xlib
name=$1
location=$2
-([ "$name" ] && [ "$location" ]) || die "usage: cg-branch-add NAME SOURCE_LOC"
+([ "$name" ] && [ "$location" ]) || usage
(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
die "name contains invalid characters"
if [ "$name" = "this" ] || [ "$name" = "HEAD" ]; then
diff --git a/cg-clone b/cg-clone
--- a/cg-clone
+++ b/cg-clone
@@ -15,8 +15,9 @@
# -------
# -s::
# Clone in the current directory instead of creating a new one.
+# Specifying both -s and a desination directory makes no sense .
-USAGE="cg-clone [-s] LOCATION [<directory>]"
+USAGE="cg-clone [-s] LOCATION [DESTDIR]"
. ${COGITO_LIB}cg-Xlib
@@ -27,7 +28,7 @@ if [ "$1" = "-s" ]; then
fi
location=$1
-[ "$location" ] || die "usage: cg-clone [-s] SOURCE_LOC [DESTDIR]"
+[ "$location" ] || usage
location=${location%/}
destdir=$2
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -20,7 +20,7 @@
# Note, this is used internally by Cogito when merging. This option
# does not make sense when files are given on the command line.
#
-# -m<message>::
+# -mMESSAGE::
# Specify the commit message, which is used instead of starting
# up an editor (if the input is not `stdin`, the input is appended
# after all the '-m' messages). Multiple '-m' parameters are appended
@@ -72,7 +72,7 @@
# EDITOR::
# The editor used for entering revision log information.
-USAGE="cg-commit [-m<message>]... [-C] [-e | -E] [FILE]..."
+USAGE="cg-commit [-mMESSAGE]... [-C] [-e | -E] [FILE]..."
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-diff b/cg-diff
--- a/cg-diff
+++ b/cg-diff
@@ -16,7 +16,7 @@
# Instead of one ID denotes a parent commit to the specified ID
# (which must not be a tree, obviously).
#
-# -r REVISION[:REVISION]::
+# -r FROM_ID[:TO_ID]::
# Specify the revisions to diff using either '-r rev1:rev2' or
# '-r rev1 -r rev2'. If no revision is specified, the current
# working tree is implied. Note that no revision is different from
@@ -27,7 +27,7 @@
# Base the diff at the merge base of the -r arguments (defaulting
# to master and origin).
-USAGE="cg-diff [-p] [-r REVISION[:REVISION]] [FILE]..."
+USAGE="cg-diff [-c] [-m] [-p] [-r FROM_ID[:TO_ID] [FILE]..."
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-export b/cg-export
--- a/cg-export
+++ b/cg-export
@@ -10,14 +10,14 @@
# for generating a tarball. Other destination specifiers are assumed
# to be directory names, and the tree is exported to the given directory.
-USAGE="cg-export DESTINATION [TREE]"
+USAGE="cg-export DESTFILE [TREE_ID]"
. ${COGITO_LIB}cg-Xlib
dest=$1
id=$(tree-id $2)
-([ "$dest" ] && [ "$id" ]) || die "usage: cg-export DEST [TREE_ID]"
+([ "$dest" ] && [ "$id" ]) || usage
[ -e "$dest" ] && die "$dest already exists."
diff --git a/cg-log b/cg-log
--- a/cg-log
+++ b/cg-log
@@ -24,7 +24,7 @@
# -f::
# List affected files.
#
-# -r REVISION[:REVISION]::
+# -r FROM_ID[:TO_ID]::
# Limit the log information to a set of revisions using either
# '-r FROM_ID[:TO_ID]' or '-r FROM_ID -r TO_ID'. In both cases the
# option expects IDs which resolve to commits and will include the
@@ -55,7 +55,7 @@
#
# $ cg-log -r releasetag-0.9:releasetag-0.10
-USAGE="cg-log [-c] [-f] [-uUSERNAME] [-r REVISION[:REVISION]] FILE..."
+USAGE="cg-log [-c] [-f] [m] [-uUSERNAME] [-r FROM_ID[:TO_ID] FILE..."
. ${COGITO_LIB}cg-Xlib
# Try to fix the annoying "Broken pipe" output. May not help, but apparently
diff --git a/cg-ls b/cg-ls
--- a/cg-ls
+++ b/cg-ls
@@ -29,7 +29,7 @@
#
# 100644 blob c7dacd0ea28994e3c754ca4eadb2e08c011ee3d3 README
-USAGE="cg-ls [TREE]"
+USAGE="cg-ls [TREE_ID]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-merge b/cg-merge
--- a/cg-merge
+++ b/cg-merge
@@ -12,14 +12,14 @@
#
# OPTIONS
# -------
-# -b REVISION::
+# -b BASE_COMMIT::
# Parameter specifies the base commit for the merge.
#
# -c::
# Parameter specifies that you want to have tree merge never
# autocomitted, but want to review and commit it manually.
-USAGE="cg-merge [-c] [-b REVISION] BRANCH"
+USAGE="cg-merge [-c] [-b BASE_COMMIT] BRANCH_NAME"
. ${COGITO_LIB}cg-Xlib
@@ -35,11 +35,11 @@ fi
base=
if [ "$1" = "-b" ]; then
shift
- [ "$1" ] || die "usage: cg-merge [-c] [-b BASE_ID] FROM_ID"
+ [ "$1" ] || usage
base=$(commit-id "$1") || exit 1; shift
fi
-[ "$1" ] || die "usage: cg-merge [-c] [-b BASE_ID] FROM_ID"
+[ "$1" ] || usage
branchname="$1"
branch=$(commit-id "$branchname") || exit 1
diff --git a/cg-mkpatch b/cg-mkpatch
--- a/cg-mkpatch
+++ b/cg-mkpatch
@@ -11,7 +11,7 @@
# Specify whether to print a short version of the patch without
# a patch header with meta info such as author and committer.
#
-# -r REVISION[:REVISION]::
+# -r FROM_ID[:TO_ID]::
# Specify a set of commits to make patches from using either
# '-r FROM_ID[:TO_ID]' or '-r FROM_ID -r TO_ID'. In both cases the
# option expects IDs which resolve to commits and will include the
@@ -34,7 +34,7 @@
# the line
# `!-------------------------------------------------------------flip-`
-USAGE="cg-mkpatch [-s] [-r REVISION[:REVISION]]"
+USAGE="cg-mkpatch [-m] [-s] [-r FROM_ID[:TO_ID]]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -7,7 +7,7 @@
#
# See `cg-branch-add` for some description.
-USAGE="cg-pull [BRANCH]"
+USAGE="cg-pull [BRANCH_NAME]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-rm b/cg-rm
--- a/cg-rm
+++ b/cg-rm
@@ -10,7 +10,7 @@ USAGE="cg-rm FILE..."
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || die "usage: cg-rm FILE..."
+[ "$1" ] || usage
rm -f "$@"
git-update-cache --remove -- "$@"
diff --git a/cg-seek b/cg-seek
--- a/cg-seek
+++ b/cg-seek
@@ -19,7 +19,7 @@
# the right thing too. If you want to migrate your working tree to another
# branch, use `cg-clone`.
-USAGE="cg-seek REVISION"
+USAGE="cg-seek [COMMIT_ID]"
. ${COGITO_LIB}cg-Xlib
diff --git a/cg-tag b/cg-tag
--- a/cg-tag
+++ b/cg-tag
@@ -8,14 +8,14 @@
#
# Takes the tag name and optionally the associated ID as arguments.
-USAGE="cg-tag TAG [REVISION]"
+USAGE="cg-tag TAG_NAME [COMMIT_ID]"
. ${COGITO_LIB}cg-Xlib
name=$1
id=$2
-[ "$name" ] || die "usage: cg-tag TNAME [COMMIT_ID]"
+[ "$name" ] || usage
[ "$id" ] || id=$(commit-id)
(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
diff --git a/cg-update b/cg-update
--- a/cg-update
+++ b/cg-update
@@ -8,7 +8,7 @@
# If local changes conflict with those of the branch updated from the
# merge will be blocked.
-USAGE="cg-update [BRANCH]"
+USAGE="cg-update [BRANCH_NAME]"
. ${COGITO_LIB}cg-Xlib
--
Jonas Fonseca
^ permalink raw reply
* git-rev-list: proper lazy reachability
From: Linus Torvalds @ 2005-05-31 1:58 UTC (permalink / raw)
To: Git Mailing List
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.
It's probably buggy, so don't get too excited, but it seems to give the
right results for something like
git-rev-list v2.6.12-rc5 v2.6.12-rc4
which is basically "give me a rev-list of everything that is in rc5 but is
not in rc4".
So now "git-rev-list a b" should be equivalent to "git-rev-tree a ^b",
except it's faster, and it doesn't print out anything else.
Because it doesn't need to go all the way back to the root (only far
enough back to be able to determine that there can be no more unreachable
entries), it should be constant-time in the total history size. Doesn't
matter if you've got a million revisions, if you asked for the difference
between two "close" ones, it will be fast.
Somebody should probably take a look at my simplistic algorithm, since it
can probably be improved upon and/or fixed for corner-cases.
Linus
^ permalink raw reply
* Re: More gitweb queries..
From: Jeff Epler @ 2005-05-31 2:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Kay Sievers, Git Mailing List
In-Reply-To: <17051.39850.556062.543875@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
On Tue, May 31, 2005 at 09:03:06AM +1000, Paul Mackerras wrote:
> Tcl/Tk 8.5 will have anti-aliased fonts (8.5a2 is available on
> sourceforge). There is apparently some support for widget styling in
> 8.4 which I will have to look into. The Motif look doesn't bother me,
> but it does seem to bother you and Ben H. :)
I have a somewhat stale copy of Tk 8.5 CVS and Tile CVS here. I tried
gitk on it. I added the lines
package require tile; namespace import -force ::ttk::*
tile::setTheme alt
near the top, which is a simple way to use the new "tile" theme engine
with an included, redmond-style theme.
Here's a screenshot:
http://emergent.unpy.net/index.cgi-files/sandbox/gitk-tk85+tile.png
I have no idea why the menu is in greek. The rest of the buttons and
labels were too, before I switched to Tile for rendering them.
I get an odd traceback that I don't get using the same gitk with
tcl-8.4.5:
number too large to represent as a Posix time
while executing
"return -options $opts $retval"
(procedure "ConvertUTCToLocal" line 20)
invoked from within
"ConvertUTCToLocal $date[set date {}] $timezone"
(procedure "::tcl::clock::format" line 10)
invoked from within
"clock format $audate -format "%Y-%m-%d %H:%M:%S""
(procedure "readcommit" line 37)
invoked from within
"readcommit $p"
(procedure "drawgraph" line 52)
invoked from within
"drawgraph"
("after" script)
which stops the graph before it's complete. Laying out the graph seems
much slower than with tk8.4.
Jeff
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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