* gitk patch display corner-case bug
From: Karl Hasselström @ 2006-02-18 23:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In a recently updated stgit tree,
$ git-diff 51cb39db\^ 51cb39db
diff --git a/templates/covermail.tmpl b/templates/covermail.tmpl
index 9789c9c..44cd19e 100644
--- a/templates/covermail.tmpl
+++ b/templates/covermail.tmpl
@@ -4,5 +4,5 @@ Date: %(date)s
%(endofheaders)s
The following series implements...
---
+--
Signature
That is, a trailing whitespace was added after the two dashes.
However, gitk displays this as
index 9789c9c..44cd19e 100644
@@ -2,7 +2,7 @@ From: %(maintainer)s
Subject: [PATCH%(version)s%(number)s] Series short description
Date: %(date)s
%(endofheaders)s
The following series implements...
+--
Signature
Totally correct except that it omitted the line consisting of only
three dashes.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Delay "empty ident" errors until they really matter.
From: Junio C Hamano @ 2006-02-19 4:56 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20060218172731.GV31278@pasky.or.cz>
Previous one warned people upfront to encourage fixing their
environment early, but some people just use repositories and git
tools read-only without making any changes, and in such a case
there is not much point insisting on them having a usable ident.
This round attempts to move the error until either "git-var"
asks for the ident explicitly or "commit-tree" wants to use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Petr Baudis <pasky@suse.cz> writes:
> One dislike from me - you shouldn't care if you ain't gonna do it - it
> makes no sense to require valid gecos if you are never committing
> anything.
You are absolutely right. This is to fix the previous one.
cache.h | 4 ++--
commit-tree.c | 4 ++--
ident.c | 47 +++++++++++++++++++++++++----------------------
var.c | 6 +++---
4 files changed, 32 insertions(+), 29 deletions(-)
749be728d469e9a0acfdc020feff17c2da510083
diff --git a/cache.h b/cache.h
index b5db01f..da73fb3 100644
--- a/cache.h
+++ b/cache.h
@@ -246,8 +246,8 @@ void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
extern int setup_ident(void);
-extern const char *git_author_info(void);
-extern const char *git_committer_info(void);
+extern const char *git_author_info(int);
+extern const char *git_committer_info(int);
struct checkout {
const char *base_dir;
diff --git a/commit-tree.c b/commit-tree.c
index b1c8dca..88871b0 100644
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -118,8 +118,8 @@ int main(int argc, char **argv)
add_buffer(&buffer, &size, "parent %s\n", sha1_to_hex(parent_sha1[i]));
/* Person/date information */
- add_buffer(&buffer, &size, "author %s\n", git_author_info());
- add_buffer(&buffer, &size, "committer %s\n\n", git_committer_info());
+ add_buffer(&buffer, &size, "author %s\n", git_author_info(1));
+ add_buffer(&buffer, &size, "committer %s\n\n", git_committer_info(1));
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
diff --git a/ident.c b/ident.c
index 09d4d71..7c81fe8 100644
--- a/ident.c
+++ b/ident.c
@@ -46,15 +46,6 @@ static void copy_gecos(struct passwd *w,
}
-static const char au_env[] = "GIT_AUTHOR_NAME";
-static const char co_env[] = "GIT_COMMITTER_NAME";
-static const char env_hint[] =
-"\n*** Environment problem:\n"
-"*** Your name cannot be determined from your system services (gecos).\n"
-"*** You would need to set %s and %s\n"
-"*** environment variables; otherwise you won't be able to perform\n"
-"*** certain operations because of \"empty ident\" errors.\n\n";
-
int setup_ident(void)
{
int len;
@@ -66,11 +57,6 @@ int setup_ident(void)
/* Get the name ("gecos") */
copy_gecos(pw, git_default_name, sizeof(git_default_name));
- if (!*git_default_name) {
- if (!getenv(au_env) || !getenv(co_env))
- fprintf(stderr, env_hint, au_env, co_env);
- }
-
/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
len = strlen(pw->pw_name);
if (len > sizeof(git_default_email)/2)
@@ -170,8 +156,18 @@ static int copy(char *buf, int size, int
return offset;
}
+static const char au_env[] = "GIT_AUTHOR_NAME";
+static const char co_env[] = "GIT_COMMITTER_NAME";
+static const char *env_hint =
+"\n*** Environment problem:\n"
+"*** Your name cannot be determined from your system services (gecos).\n"
+"*** You would need to set %s and %s\n"
+"*** environment variables; otherwise you won't be able to perform\n"
+"*** certain operations because of \"empty ident\" errors.\n"
+"*** Alternatively, you can use user.name configuration variable.\n\n";
+
static const char *get_ident(const char *name, const char *email,
- const char *date_str)
+ const char *date_str, int error_on_no_name)
{
static char buffer[1000];
char date[50];
@@ -182,9 +178,14 @@ static const char *get_ident(const char
if (!email)
email = git_default_email;
- if (!*name || !*email)
- die("empty ident %s <%s> not allowed",
- name, email);
+ if (!*name) {
+ if (name == git_default_name && env_hint) {
+ fprintf(stderr, env_hint, au_env, co_env);
+ env_hint = NULL; /* warn only once, for "git-var -l" */
+ }
+ if (error_on_no_name)
+ die("empty ident %s <%s> not allowed", name, email);
+ }
strcpy(date, git_default_date);
if (date_str)
@@ -201,16 +202,18 @@ static const char *get_ident(const char
return buffer;
}
-const char *git_author_info(void)
+const char *git_author_info(int error_on_no_name)
{
return get_ident(getenv("GIT_AUTHOR_NAME"),
getenv("GIT_AUTHOR_EMAIL"),
- getenv("GIT_AUTHOR_DATE"));
+ getenv("GIT_AUTHOR_DATE"),
+ error_on_no_name);
}
-const char *git_committer_info(void)
+const char *git_committer_info(int error_on_no_name)
{
return get_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
- getenv("GIT_COMMITTER_DATE"));
+ getenv("GIT_COMMITTER_DATE"),
+ error_on_no_name);
}
diff --git a/var.c b/var.c
index 59da56d..a57a33b 100644
--- a/var.c
+++ b/var.c
@@ -12,7 +12,7 @@ static const char var_usage[] = "git-var
struct git_var {
const char *name;
- const char *(*read)(void);
+ const char *(*read)(int);
};
static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
@@ -24,7 +24,7 @@ static void list_vars(void)
{
struct git_var *ptr;
for(ptr = git_vars; ptr->read; ptr++) {
- printf("%s=%s\n", ptr->name, ptr->read());
+ printf("%s=%s\n", ptr->name, ptr->read(0));
}
}
@@ -35,7 +35,7 @@ static const char *read_var(const char *
val = NULL;
for(ptr = git_vars; ptr->read; ptr++) {
if (strcmp(var, ptr->name) == 0) {
- val = ptr->read();
+ val = ptr->read(1);
break;
}
}
--
1.2.1.g2902
^ permalink raw reply related
* [PATCH] Keep Porcelainish from failing by broken ident after making changes.
From: Junio C Hamano @ 2006-02-19 4:59 UTC (permalink / raw)
To: git
"empty ident not allowed" error makes commit-tree fail, so we
are already safer in that we would not end up with commit
objects that have bogus names on the author or committer fields.
However, before commit-tree is called there are already changes
made to the index file and the working tree. The operation can
be resumed after fixing the environment problem, but when this
triggers to a newcomer with unusable gecos, the first question
becomes "what did I lose and how would I recover".
This patch modifies some Porcelainish commands to verify
GIT_COMMITTER_IDENT as soon as we know we are going to make some
commits before doing much damage to prevent confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is a follow-up on the previous "delay empty ident" error
one. "git pull random-place" otherwise would confuse and
scare new users, even though what it leaves would often be a
perfectly fine committable state.
git-am.sh | 4 +++-
git-applymbox.sh | 2 ++
git-merge.sh | 5 +++++
git-resolve.sh | 3 +++
4 files changed, 13 insertions(+), 1 deletions(-)
e3b59a44f6705896db80965427a7cf9e2112634b
diff --git a/git-am.sh b/git-am.sh
index 98b9215..85ecada 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -1,11 +1,13 @@
#!/bin/sh
#
-#
+# Copyright (c) 2005, 2006 Junio C Hamano
USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>
or, when resuming [--skip | --resolved]'
. git-sh-setup
+git var GIT_COMMITTER_IDENT >/dev/null || exit
+
stop_here () {
echo "$1" >"$dotest/next"
exit 1
diff --git a/git-applymbox.sh b/git-applymbox.sh
index 61c8c02..5569fdc 100755
--- a/git-applymbox.sh
+++ b/git-applymbox.sh
@@ -21,6 +21,8 @@
USAGE='[-u] [-k] [-q] [-m] (-c .dotest/<num> | mbox) [signoff]'
. git-sh-setup
+git var GIT_COMMITTER_IDENT >/dev/null || exit
+
keep_subject= query_apply= continue= utf8= resume=t
while case "$#" in 0) break ;; esac
do
diff --git a/git-merge.sh b/git-merge.sh
index 74f0761..2b4a603 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -142,6 +142,8 @@ case "$#,$common,$no_commit" in
1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
+ git var GIT_COMMITTER_IDENT >/dev/null || exit
+
echo "Trying really trivial in-index merge..."
git-update-index --refresh 2>/dev/null
if git-read-tree --trivial -m -u $common $head "$1" &&
@@ -179,6 +181,9 @@ case "$#,$common,$no_commit" in
;;
esac
+# We are going to make a new commit.
+git var GIT_COMMITTER_IDENT >/dev/null || exit
+
case "$use_strategies" in
'')
case "$#" in
diff --git a/git-resolve.sh b/git-resolve.sh
index 9263070..b53ede8 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -50,6 +50,9 @@ case "$common" in
;;
esac
+# We are going to make a new commit.
+git var GIT_COMMITTER_IDENT >/dev/null || exit
+
# Find an optimum merge base if there are more than one candidates.
LF='
'
--
1.2.1.g2902
^ permalink raw reply related
* [ANNOUNCE] GIT 1.2.2
From: Junio C Hamano @ 2006-02-19 8:56 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.2.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.2-1.$arch.rpm (RPM)
Carl Worth fixed a longstanding annoyance of failed clone
leaving a half-built cloned directory. Contributions from
people new to the list are much appreciated. Long timers have
just leaned to live with these inconveniences, but I expect such
rough edges will be rounded out quickly as we gain more wider
user base.
The much talked about pack performance enhancement is not in
this release. In principle, 1.2.X series are supposed to be
bugfix only, so I can justifiably be lazy and keep things that
way, but we _could_ argue that the old pack-object had a
performance bug ;-).
We will decide what to do after it hits the master branch. I
think pack-object is important enough to be conservative about,
but at the same time its performance is veriy critical for the
public git server, so as it proves stable we probably would want
to have it on kernel.org.
----------------------------------------------------------------
Changes since v1.2.1 are as follows:
Carl Worth:
Trap exit to clean up created directory if clone fails.
Abstract test_create_repo out for use in tests.
Prevent git-upload-pack segfault if object cannot be found
Eric Wong:
archimport: remove files from the index before adding/updating
Jonas Fonseca:
git-rev-parse: Fix --short= option parsing
Document --short and --git-dir in git-rev-parse(1)
Martin Mares:
Fix retries in git-cvsimport
Shawn Pearce:
Make git-reset delete empty directories
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-02-19 8:56 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
Alexandre Julliard:
Add an Emacs interface in contrib.
Aneesh Kumar:
Add contrib/gitview from Aneesh.
Aneesh Kumar K.V:
Add a README for gitview
gitview: typofix
Carl Worth:
Trap exit to clean up created directory if clone fails.
Abstract test_create_repo out for use in tests.
Prevent git-upload-pack segfault if object cannot be found
Eric Wong:
Introducing contrib/git-svn.
git-svn: fix revision order when XML::Simple is not loaded
git-svn: ensure fetch always works chronologically.
git-svn: remove files from the index before adding/updating
archimport: remove files from the index before adding/updating
Fernando J. Pereda:
Allow building Git in systems without iconv
Jonas Fonseca:
git-rev-parse: Fix --short= option parsing
Document --short and --git-dir in git-rev-parse(1)
Junio C Hamano:
rebase: allow rebasing onto different base.
Detect misspelled pathspec to git-add
topo-order: make --date-order optional.
git-tag: -l to list tags (usability).
Add contrib/README.
SubmittingPatches: note on whitespaces
Martin Mares:
Fix retries in git-cvsimport
Shawn Pearce:
Make git-reset delete empty directories
* The 'next' branch, in addition, has these.
Johannes Schindelin:
Fix cpio call
Optionally support old diffs
Support Irix
Optionally work without python
Junio C Hamano:
pack-objects: reuse data from existing packs.
pack-objects: finishing touches.
git-repack: allow passing a couple of flags to pack-objects.
pack-objects: avoid delta chains that are too long.
Make "empty ident" error message a bit more helpful.
Delay "empty ident" errors until they really matter.
Keep Porcelainish from failing by broken ident after making changes.
fmt-merge-msg: say which branch things were merged into unless 'master'
Allow git-mv to accept ./ in paths.
Linus Torvalds:
Handling large files with GIT
Handling large files with GIT
git-merge-tree: generalize the "traverse <n> trees in sync" functionality
* The 'pu' branch, in addition, has these.
Johannes Schindelin:
Fixes for ancient versions of GNU make
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>/ and --exclude=<prefix>/.
commit-tree: --bind <sha1> <path>/ option.
rev-list: simplify --object list generation.
rev-list: understand bound commits.
fsck-objects, convert-objects: understand bound commits.
^ permalink raw reply
* [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-19 10:00 UTC (permalink / raw)
To: git; +Cc: junkio
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Please consider this more of a RFC then a finished patch.
Where possible, for each tool, the author's description is used as a summary.
I found http://git.or.cz/ a good source.
Tools are listed alphabetically in for each section.
Feel free to add/modify comments or tool's summaries. As stated this is still a
work in progress.
Documentation/git-tools.txt | 90 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 90 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-tools.txt
355a382ecca292363af2a0be4769c2b2fb2ea9e7
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000..7e563db
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,90 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding link.
+
+
+Alternative/Argumentative Porcelains
+------------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of
use, providing
+ generally smoother user experience than the "raw" Core GIT itself and indeed
+ many other version control systems.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but
it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://homepage.ntlworld.com/cmarinas/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the GIT
+ environment. You can easily manage your patches in the
scope of GIT until they
+ get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple TK GUI for browsing history of GIT
repositories easily.
+
+
+ - *gitview* (contrib/)
+
+ gitview is a GTK based repository browser for git
+
+
+ - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
+
+ GITweb provides full-fledged web interface for GIT repositories.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (contrib/)
+
+ git-svn is a simple conduit for changesets between a
single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt
repository and commit
+ series in git back and forth.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select
which files
+ to committed (or ignored / reverted) write commit
messages and perform
+ the commit itself.
+
+
--
1.2.0.g62a4
^ permalink raw reply related
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Catalin Marinas @ 2006-02-19 10:51 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060217043128.14175.60168.stgit@backpacker.hemma.treskal.com>
Karl Hasselström wrote:
> Add an uncommit command, which is exactly the opposite of 'stg
> commit'.
Applied with two minor modifications. See below:
> --- a/stgit/commands/commit.py
> +++ b/stgit/commands/commit.py
> @@ -28,8 +28,9 @@ usage = """%prog [options]
> Merge the applied patches into the base of the current stack and
> remove them from the series while advancing the base.
>
> -Use this command only if you want to permanently store the applied
> -patches and no longer manage them with StGIT."""
> +Use this command if you want to permanently store the applied patches
> +and no longer manage them with StGIT. If you should change your mind
> +later, use 'stg uncommit'."""
I removed this change because, even if uncommit does the opposite of
commit does, the intended use is not to use commit/uncommit in pairs.
> diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
> new file mode 100644
> index 0000000..4ac0dfb
> --- /dev/null
> +++ b/stgit/commands/uncommit.py
> @@ -0,0 +1,80 @@
> +__copyright__ = """
> +Copyright (C) 2006, Catalin Marinas <catalin.marinas@gmail.com>
I added your name on the copyright since this is a new file.
Thanks,
Catalin
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Junio C Hamano @ 2006-02-19 10:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, junkio
In-Reply-To: <e5bfff550602190200j1ef3858as6a1564064dc81fef@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> A brief survey of useful git tools, including third-party
> and external projects.
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
>
> Please consider this more of a RFC then a finished patch.
>
> Where possible, for each tool, the author's description is used as a summary.
> I found http://git.or.cz/ a good source.
Thanks for starting this.
Briefly mentioning tool's strength and weakness without being
too subjective would be very helpful to potential users. We
would encourage competition without making other tools sound
inferiour on subjective terms. So "this is similar to foobar
tool, but runs much faster, but has these limitations" would be
a good style, but "this draws much nicer picture than barboz"
without substantiating why it is nicer may be suboptimal. Also
I am a bit afraid that the summary can become stale unless
maintained actively. Hopefully the respective authors of tools
can keep us updated.
I am of two minds about mentioning things available from the git
repository, but I think it makes the survey more complete and
more useful in general to include them in the list. The private
draft I sent out to you earlier forgot to include the foreign
SCM interfaces.
^ permalink raw reply
* [PATCH] git-rev-list --help anywhere
From: Alex Riesen @ 2006-02-19 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
Junio C Hamano, Sat, Feb 18, 2006 19:55:02 +0100:
> Petr Baudis <pasky@suse.cz> writes:
>
> > $ git-rev-list --help
> > fatal: Not a git repository
>
> Hmph, true. Ideas?
>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
rev-list.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
0855207c43a83007e4c060a03c39269f379fed41
diff --git a/rev-list.c b/rev-list.c
index f2d1105..a059e45 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -755,10 +755,16 @@ static void handle_all(struct commit_lis
int main(int argc, const char **argv)
{
- const char *prefix = setup_git_directory();
+ const char *prefix;
struct commit_list *list = NULL;
int i, limited = 0;
+ for (i = 1 ; i < argc; i++)
+ if ( !strcmp(argv[i], "--help") )
+ usage(rev_list_usage);
+
+ prefix = setup_git_directory();
+
for (i = 1 ; i < argc; i++) {
int flags;
const char *arg = argv[i];
--
1.2.1.g59a08
^ permalink raw reply related
* Re: [PATCH] git-rev-list --help anywhere
From: linux @ 2006-02-19 11:26 UTC (permalink / raw)
To: raa.lkml; +Cc: git
>+ for (i = 1 ; i < argc; i++)
>+ if ( !strcmp(argv[i], "--help") )
>+ usage(rev_list_usage);
You might want to try something more like:
+ for (i = 1 ; i < argc; i++) {
+ if ( !strcmp(argv[i], "--help") )
+ usage(rev_list_usage);
+ if ( !strcmp(argv[i], "--") )
+ break;
+ }
So that you don't break in the perverse but legal case of
having a file named "--help".
^ permalink raw reply
* Re: gitk patch display corner-case bug
From: Paul Mackerras @ 2006-02-19 11:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060218233618.GA29025@diana.vm.bytemark.co.uk>
Karl Hasselström writes:
> Totally correct except that it omitted the line consisting of only
> three dashes.
Could you check that the missing line is present in the output from
git-rev-list --header --parents --topo-order please?
Paul.
^ permalink raw reply
* New shiny gitk
From: Paul Mackerras @ 2006-02-19 11:50 UTC (permalink / raw)
To: git
I just created a branch called "new" in my gitk repository at
git://git.kernel.org/pub/scm/gitk/gitk.git
which has a new improved version of gitk which is much faster than the
old one and has a better graph layout algorithm. I'd like people to
try it out and tell me how they like it and if I broke anything (I'm
pretty sure I broke the "Update" function, for instance).
If you use -d to get commits ordered by date, you will need the latest
version of git-rev-list, which has the --date-order option.
Paul.
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-19 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkw7iphb.fsf@assigned-by-dhcp.cox.net>
On 2/19/06, Junio C Hamano <junkio@cox.net> wrote:
>
> Thanks for starting this.
>
> Briefly mentioning tool's strength and weakness without being
> too subjective would be very helpful to potential users. We
> would encourage competition without making other tools sound
> inferiour on subjective terms. So "this is similar to foobar
> tool, but runs much faster, but has these limitations" would be
> a good style, but "this draws much nicer picture than barboz"
> without substantiating why it is nicer may be suboptimal.
Ok, I resend the patch with 'encouraged competition' comments on,
guess what, qgit.
It is a little bit biased but provable. I speak only for tools I know
well. I would like each tool author writes it's own advertising ;-)
Also added the freshly new contrib/ emacs interface, called pcl-cvs,
as in revision log message.
> I am a bit afraid that the summary can become stale unless
> maintained actively.
This is unavoidable but also a useful 'watchdog' to test active maintenance.
> I am of two minds about mentioning things available from the git
> repository, but I think it makes the survey more complete and
> more useful in general to include them in the list.
>
I agree, we don't have hundreds of tools around, so list all in just
one place perhaps is
not the cleanest thing, but it is more user friendly.
-------------------------- cut ----------------------------------
From: Marco Costalba <mcostalba@gmail.com>
Date: Sun Feb 19 12:52:07 2006 +0100
Subject: [PATCH] Add a Documentation/git-tools.txt
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Documentation/git-tools.txt | 97 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-tools.txt
ce159730f858f50046186301f2d8668c66526627
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000..93a8d8b
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,97 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding link.
+
+
+Alternative/Argumentative Porcelains
+------------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of
use, providing
+ generally smoother user experience than the "raw" Core GIT itself and indeed
+ many other version control systems.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but
it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://homepage.ntlworld.com/cmarinas/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the GIT
+ environment. You can easily manage your patches in the
scope of GIT until they
+ get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple TK GUI for browsing history of GIT
repositories easily.
+
+
+ - *gitview* (contrib/)
+
+ gitview is a GTK based repository browser for git
+
+
+ - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
+
+ GITweb provides full-fledged web interface for GIT repositories.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+ Currently it is the fastest and most feature rich among
the git viewers
+ and commit tools.
+
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (contrib/)
+
+ git-svn is a simple conduit for changesets between a
single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt
repository and commit
+ series in git back and forth.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select
which files
+ to committed (or ignored / reverted) write commit
messages and perform
+ the commit itself.
+
+ - *pcl-cvs* (contrib/)
+
+ This is an Emacs interface for git. The user interface is
modeled on
+ pcl-cvs. It has been developed on Emacs 21 and will
probably need some
+ tweaking to work on XEmacs.
+
--
1.2.0.g709a
^ permalink raw reply related
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Alan Chandler @ 2006-02-19 12:25 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, junkio
In-Reply-To: <e5bfff550602190200j1ef3858as6a1564064dc81fef@mail.gmail.com>
On Sunday 19 February 2006 10:00, Marco Costalba wrote:
> +
> +Alternative/Argumentative Porcelains
> +------------------------------------
Aren't these "Augmentative Procelains" rather than ones that argue a lot.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-19 12:39 UTC (permalink / raw)
To: Alan Chandler; +Cc: git, junkio
In-Reply-To: <200602191225.54311.alan@chandlerfamily.org.uk>
Alan Chandler ha scritto:
> On Sunday 19 February 2006 10:00, Marco Costalba wrote:
>
>>+
>>+Alternative/Argumentative Porcelains
>>+------------------------------------
>
>
> Aren't these "Augmentative Procelains" rather than ones that argue a lot.
>
Yes, you are arguing correctly!
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Karl Hasselström @ 2006-02-19 13:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <43F84D9A.2010905@gmail.com>
On 2006-02-19 10:51:06 +0000, Catalin Marinas wrote:
> Karl Hasselström wrote:
>
> > diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
> > new file mode 100644
> > index 0000000..4ac0dfb
> > --- /dev/null
> > +++ b/stgit/commands/uncommit.py
> > @@ -0,0 +1,80 @@
> > +__copyright__ = """
> > +Copyright (C) 2006, Catalin Marinas <catalin.marinas@gmail.com>
>
> I added your name on the copyright since this is a new file.
I did that too at first, but then I changed it back since I reckoned
more than 50% of the file was copy-pasted from elsewhere. But thanks.
:-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: gitk patch display corner-case bug
From: Karl Hasselström @ 2006-02-19 14:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17400.20764.131417.903578@cargo.ozlabs.ibm.com>
On 2006-02-19 22:06:04 +1100, Paul Mackerras wrote:
> Karl Hasselström writes:
>
> > Totally correct except that it omitted the line consisting of only
> > three dashes.
>
> Could you check that the missing line is present in the output from
> git-rev-list --header --parents --topo-order please?
I'm not sure I follow you. The affected commit is listed first by
"git-rev-list --header --parents --topo-order 51cb39db", but that
commad doesn't show diffs, so the missing line is not there.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Karl Hasselström @ 2006-02-19 14:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060219134558.GA4784@diana.vm.bytemark.co.uk>
On 2006-02-19 14:45:58 +0100, Karl Hasselström wrote:
> On 2006-02-19 10:51:06 +0000, Catalin Marinas wrote:
>
> > I added your name on the copyright since this is a new file.
>
> I did that too at first, but then I changed it back since I reckoned
> more than 50% of the file was copy-pasted from elsewhere. But
> thanks. :-)
By the way, it seems like my name got munged when you edited the
commit.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] So... are people happy with commit/status -v?
From: Christian Biesinger @ 2006-02-19 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvevhj6x4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I usually never do commits from a subdirectory, also I rarely do
> partial commits, so this is not a big issue to me, but are
> people happy with the current commit/status?
The part that annoyed me most was that "git-status --only ." completely
ignores the specified path and tells me about the whole tree, rather
than just the current directory and subdirectories. While I think I'd
prefer it if the commands limited themselves to the current directory by
default, I don't mind the current behaviour, as long as I still have the
possibility to limit to the subdirectory.
^ permalink raw reply
* Re: New shiny gitk
From: Alex Riesen @ 2006-02-19 18:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17400.23434.724188.649656@cargo.ozlabs.ibm.com>
Paul Mackerras, Sun, Feb 19, 2006 12:50:34 +0100:
> I just created a branch called "new" in my gitk repository at
>
> git://git.kernel.org/pub/scm/gitk/gitk.git
>
> which has a new improved version of gitk which is much faster than the
> old one and has a better graph layout algorithm. I'd like people to
> try it out and tell me how they like it and if I broke anything (I'm
> pretty sure I broke the "Update" function, for instance).
aside from speedup and broken Update (both of which I didn't really
notice yet in the linux tree), I really like the new layout. I suggest
to try it on ACPI monster merge and gits "next" branch. It's simplier
to understand now (because of how the lines are highlighted when you
click on them). Well the latter is a hopeless maze anyway, but you
often can see more of the patch description now.
Thanks!
^ permalink raw reply
* Fixing author/email fields in commit messages
From: Jacob Kroon @ 2006-02-19 18:45 UTC (permalink / raw)
To: git
When I started my git repository for my project, I never setup
GIT_AUTHOR_NAME etc. correctly,
so my commit messages used the default information,
"<jacob@skeletor.(none)>", "skeletor" being the
hostname of the computer I'm working on. I'd like to change it so that
the messages will contain correct
information about my e-mail and username. I noticed that this question
has been brought up here before
and that the solution might be to use git-convert-objects, but that it
might need some modifications.
Has anyone come up with a working tool for this task ?
I know how to make the future commits look as expected.
//Jacob
^ permalink raw reply
* Re: [PATCH] git-rev-list --help anywhere
From: Alex Riesen @ 2006-02-19 18:39 UTC (permalink / raw)
To: linux; +Cc: Junio C Hamano, git
In-Reply-To: <20060219112627.18989.qmail@science.horizon.com>
linux@horizon.com, Sun, Feb 19, 2006 12:26:27 +0100:
> >+ for (i = 1 ; i < argc; i++)
> >+ if ( !strcmp(argv[i], "--help") )
> >+ usage(rev_list_usage);
>
> You might want to try something more like:
>
> + for (i = 1 ; i < argc; i++) {
> + if ( !strcmp(argv[i], "--help") )
> + usage(rev_list_usage);
> + if ( !strcmp(argv[i], "--") )
> + break;
> + }
>
> So that you don't break in the perverse but legal case of
> having a file named "--help".
Of course. Thanks!
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
diff --git a/rev-list.c b/rev-list.c
index f2d1105..bcb492e 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -755,11 +755,20 @@ static void handle_all(struct commit_lis
int main(int argc, const char **argv)
{
- const char *prefix = setup_git_directory();
+ const char *prefix;
struct commit_list *list = NULL;
int i, limited = 0;
for (i = 1 ; i < argc; i++) {
+ if ( !strcmp(argv[i], "--help") )
+ usage(rev_list_usage);
+ if ( !strcmp(argv[i], "--") )
+ break;
+ }
+
+ prefix = setup_git_directory();
+
+ for (i = 1 ; i < argc; i++) {
int flags;
const char *arg = argv[i];
char *dotdot;
--
1.2.2.gbc57
^ permalink raw reply related
* Re: [PATCH] git-rev-list --help anywhere
From: Johannes Schindelin @ 2006-02-19 19:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: linux, Junio C Hamano, git
In-Reply-To: <20060219183930.GB10010@steel.home>
Hi,
can someone please enlighten me why you need to see the usage, when you
cannot execute the command anyway?
Puzzled,
Dscho
^ permalink raw reply
* Re: Fixing author/email fields in commit messages
From: Johannes Schindelin @ 2006-02-19 19:27 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <43F8BCB1.2010701@gmail.com>
Hi,
On Sun, 19 Feb 2006, Jacob Kroon wrote:
> When I started my git repository for my project, I never setup
> GIT_AUTHOR_NAME etc. correctly, so my commit messages used the default
> information, "<jacob@skeletor.(none)>", "skeletor" being the hostname of
> the computer I'm working on. I'd like to change it so that the messages
> will contain correct information about my e-mail and username. I noticed
> that this question has been brought up here before and that the solution
> might be to use git-convert-objects, but that it might need some
> modifications.
>
> Has anyone come up with a working tool for this task ?
Unfortunately not.
However, I'd rather start by enhancing git-rebase. You do not really need
to rewrite *all* objects, but only the *commit objects*. Two things seem
to be lacking for what you want:
- an option to rebase "onto an empty commit", and
- an optional filter command to run on the commit messages.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] git-rev-list --help anywhere
From: linux @ 2006-02-19 19:39 UTC (permalink / raw)
To: Johannes.Schindelin, raa.lkml; +Cc: git, junkio, linux
In-Reply-To: <Pine.LNX.4.63.0602192023270.11855@wbgn013.biozentrum.uni-wuerzburg.de>
> can someone please enlighten me why you need to see the usage, when you
> cannot execute the command anyway?
Because you're writing a script, or explaining it to someone over
the phone, or writing shell autocompletion macros, otherwise using
it in some kind of delayed or deferred way.
These ain't no steenkin GUI tools; they can be used in more ways
that typed interactively for immediate execution.
(Have you ever noticed how all the GUI people have rediscovered the
concept of a pathname and a single-character directory separator when
explaining how to navigate a menu/dialog maze? The character '>' seems
to be popular.
Go to menu A
Then go to submenu B
Then select item C to open a dialog
Then go to tab D of that dialog.
Then hit the "Advanced options" button
Then select tab E of that dialog
Then select option F
How exactly is this is an improvement over A/B/C/D/Advanced options/E/F?)
^ 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