* [PATCH] Make list of features auto-managed.
From: Junio C Hamano @ 2007-06-21 9:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <7vr6o5zt76.fsf@assigned-by-dhcp.pobox.com>
This updates the build procedure so that a mark-up in the form
of:
SP "FEATURE<" feature-name ">" SP
is picked up from the sources, in order to help keeping
supported_features[] array automatically in sync.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> So, first of all, I would want the list of features in
> supported_features[] to come from a separate file, whose sole
> purpose is to have that list. I would even suggest making it an
> generated file, which depends on the source files (not
> necessarily limited to C files), and built from within the build
> procedure.
> ...
> Assuming if this --list-features is a viable approach in the
> long run, my gut feeling of relative order of things is:
>
> (1) We prepare rock-solid runtime with an _EMPTY_ feature array
> in 'master'.
>
> (2) We add automated feature array management in 'master', as
> outlined above.
>
> (3) Merge the above two to 'next'.
>
> (4) Update all existing topics, including the ones that are
> already in 'next', with the feature mark-up in comment
> (i.e. "FEATURE[[[feature-name]]]").
>
> After (3) happens, any new topics that introduce a new feature
> should be accompanied with the feature mark-up.
So here is a PoC for step (2). It loses more lines than it
adds, primarily because we can lose is_feature_name_sane(); it
is done at the build time now.
.gitignore | 1 +
Makefile | 12 +++++++++++-
builtin-blame.c | 1 +
generate-features.sh | 9 +++++++++
help.c | 48 +++++++++++++-----------------------------------
5 files changed, 35 insertions(+), 36 deletions(-)
create mode 100755 generate-features.sh
diff --git a/.gitignore b/.gitignore
index e8b060c..64ee08b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -169,3 +169,4 @@ config.status
config.mak.autogen
config.mak.append
configure
+features.h
diff --git a/Makefile b/Makefile
index c09dfaf..d8d1ddc 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,13 @@ BUILT_INS = \
git-fsck-objects$X git-cherry-pick$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
+# what are the source files
+SOURCE_FILES = $(sort \
+ $(SCRIPT_SH) $(SCRIPT_PERL) $(SCRIPT_PYTHON) \
+ $(patsubst git-%$X,%.c,$(PROGRAMS)) \
+ $(LIB_H) \
+ $(patsubst %.o,%.c,$(LIB_OBJS) $(BUILTIN_OBJS)))
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -755,7 +762,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.o: common-cmds.h
+features.h: $(SOURCE_FILES) generate-features.sh
+ $(QUIET_GEN)./generate-features.sh $(SOURCE_FILES) > $@+ && mv $@+ $@
+
+help.o: common-cmds.h features.h
git-merge-subtree$X: git-merge-recursive$X
$(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..c84d96a 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2162,6 +2162,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
else if (!strcmp("-s", arg))
output_option |= OUTPUT_NO_AUTHOR;
else if (!strcmp("-w", arg))
+ /* FEATURE<blame-ignore-whitespace> */
xdl_opts |= XDF_IGNORE_WHITESPACE;
else if (!strcmp("-S", arg) && ++i < argc)
revs_file = argv[i];
diff --git a/generate-features.sh b/generate-features.sh
new file mode 100755
index 0000000..674c5fe
--- /dev/null
+++ b/generate-features.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+#
+# New features that Porcelains may care about can be marked in the
+# source code with FEATURE<feature name>. This script is driven
+# by Makefile to pick them out and sort them to prepare features.h
+# file, which is included by help.c.
+
+sed -n -e 's|.* FEATURE<\([a-z0-9][-a-z0-9]*[a-z0-9]\)> .*/| "\1",|p' "$@" |
+sort -u
diff --git a/help.c b/help.c
index d050cbf..b0887ea 100644
--- a/help.c
+++ b/help.c
@@ -9,9 +9,10 @@
#include "common-cmds.h"
#include <sys/ioctl.h>
+/* FEATURE<list-features> */
+
static const char *supported_features[] = {
- "blame-ignore-whitespace",
- "list-features",
+#include "features.h"
};
/* most GUI terminals set COLUMNS (although some don't export it) */
@@ -195,51 +196,28 @@ void help_unknown_cmd(const char *cmd)
exit(1);
}
-static int is_feature_name_sane(const char *a)
+static void list_features(void)
{
- if (!*a || *a == '-')
- return 0;
- for (; *a; a++) {
- if (! ((*a >= 'a' && *a <= 'z')
- || (*a >= '0' && *a <= '9')
- || *a == '-'))
- return 0;
- }
- return 1;
+ unsigned cnt = ARRAY_SIZE(supported_features);
+ unsigned i;
+
+ for (i = 0; i < cnt; i++)
+ printf("%s\n", supported_features[i]);
}
static int cmp_feature(const void *a_, const void *b_)
{
const char *a = *((const char **)a_);
const char *b = *((const char **)b_);
- return strcmp(a, b);
-}
-static void list_features()
-{
- unsigned cnt = ARRAY_SIZE(supported_features);
- unsigned i;
-
- qsort(supported_features, cnt,
- sizeof(supported_features[0]), cmp_feature);
- for (i = 0; i < cnt; i++) {
- const char *f = supported_features[i];
- if (!is_feature_name_sane(f))
- die("feature name \"%s\" is bogus", f);
- printf("%s\n", f);
- }
+ return strcmp(a, b);
}
static int supports_feature(const char *the_feature)
{
- unsigned cnt = ARRAY_SIZE(supported_features);
- unsigned i;
-
- for (i = 0; i < cnt; i++) {
- if (!strcmp(supported_features[i], the_feature))
- return 0;
- }
- return 1;
+ return !bsearch(&the_feature, supported_features,
+ (size_t) ARRAY_SIZE(supported_features),
+ sizeof(const char *), cmp_feature);
}
static const char version_usage[] =
--
1.5.2.2.1050.g51a8b
^ permalink raw reply related
* Re: Basename matching during rename/copy detection
From: Junio C Hamano @ 2007-06-21 8:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Shawn O. Pearce, govindsalinas
In-Reply-To: <200706210900.49702.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2007 June 21, Junio C Hamano wrote:
>
>> Having many "identical files" in the preimage is just stupid to
>> begin with (if you know they are identical, why are you storing
>> copies, instead of your build procedure to reuse the same file),
>> so the algorithm did not bother finding a better match among
>> "equals".
>
> That's a really poor argument; it's not git's place to impose restrictions on
> what is stored in it.
It's not even an argument, nor an attempt to justify it. It was
just an explanation of historical fact "It did not bother".
Please re-read the final part of the message, which you omitted
from your quote.
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Andy Parkins @ 2007-06-21 8:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, govindsalinas
In-Reply-To: <7vsl8m3sph.fsf@assigned-by-dhcp.pobox.com>
On Thursday 2007 June 21, Junio C Hamano wrote:
> Having many "identical files" in the preimage is just stupid to
> begin with (if you know they are identical, why are you storing
> copies, instead of your build procedure to reuse the same file),
> so the algorithm did not bother finding a better match among
> "equals".
That's a really poor argument; it's not git's place to impose restrictions on
what is stored in it.
What if it's not a build environment at all but a home directory that's being
stored - should no one be allowed to store copies of files because
it's "stupid"? What if it's a collection of images that all started out the
same, but have gradually had detail added (which is actually what I do in my
GUI programs for toolbar images)? What about files that are used as flags,
and are all identically empty.
None of those seems like an abuse of a VCS to me. In fact, I'd say it's one
of git's strengths that a duplicate file in the working tree doesn't take up
any extra space in the repository.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-06-21 7:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5u7d38h.fsf@assigned-by-dhcp.pobox.com>
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Add a local implementation of hstrerror for the system which do not have it
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Junio C Hamano (5):
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Do not use h_errno after connect(2): the function does not set it
cvsserver: Actually implement --export-all
Daniel Barkalow (1):
Fix pushing to a pattern with no dst
Frank Lichtenheld (3):
cvsserver: Add some useful commandline options
cvsserver: Let --base-path and pserver get along just fine
cvsserver: Actually implement --export-all
Gerrit Pape (1):
git-branch: cleanup config file when deleting branches
Ismail Dönmez (1):
Change default man page path to /usr/share/man
Jakub Narebski (8):
Document git rev-list --full-history
Document git read-tree --trivial
Document git rev-parse --is-inside-git-dir
Document git reflog --stale-fix
Document git rev-list --timestamp
Use tabs for indenting definition list for options in git-log.txt
Document git log --abbrev-commit, as a kind of pretty option
Document git log --full-diff
Junio C Hamano (8):
remote.c: refactor match_explicit_refs()
remote.c: refactor creation of new dst ref
remote.c: minor clean-up of match_explicit()
remote.c: fix "git push" weak match disambiguation
remote.c: "git-push frotz" should update what matches at the source.
git-push: Update description of refspecs and add examples
Documentation: update "stale" links for 1.5.2.2
INSTALL: explain how to build documentation
Lars Hjemli (6):
t7400: barf if git-submodule removes or replaces a file
git-submodule: remember to checkout after clone
Rename sections from "module" to "submodule" in .gitmodules
git-submodule: give submodules proper names
Add gitmodules(5)
gitmodules(5): remove leading period from synopsis
Sam Vilain (1):
git-svn: avoid string eval for defining functions
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-06-21 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* lt/follow (Tue Jun 19 14:22:46 2007 -0700) 1 commit
+ Finally implement "git log --follow"
Has leaks, and it won't graduate to 'master' without
documentation.
Also I am not convinced its handling of merges is sane. If you
have an ancestry graph like this, and the commit A renames the
followed path, it would show the file _before_ rename, which is
very good.
o-------B---A---o----o
/
o----C------'
But the code changes pathspec globally, so when we are looking
at C, it may or may not have that (before-renamed) path there.
At least, the patch is small and would not affect codepath that
does not use this option, so in that sense it is relatively safe
change, though.
* jc/oneline (Fri Jun 15 13:19:07 2007 +0100) 4 commits
+ pp_header(): work around possible memory corruption
+ Fix ALLOC_GROW off-by-one
+ Extend --pretty=oneline to cover the first paragraph,
+ Lift 16kB limit of log message output
* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
+ builtin-add: simplify (and increase accuracy of) exclude handling
+ dir_struct: add collect_ignored option
Will merge this weekend.
* ns/clone (Sat Jun 16 15:26:08 2007 -0700) 1 commit
+ Cloning from a repo without "current branch"
Will merge this weekend.
* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
+ filter-branch: subdirectory filter needs --full-history
+ filter-branch: Simplify parent computation.
+ Teach filter-branch about subdirectory filtering
+ filter-branch: also don't fail in map() if a commit cannot be
mapped
+ filter-branch: Use rev-list arguments to specify revision ranges.
+ filter-branch: fix behaviour of '-k'
+ filter-branch: use $(($i+1)) instead of $((i+1))
+ chmod +x git-filter-branch.sh
+ filter-branch: prevent filters from reading from stdin
+ t7003: make test repeatable
+ Add git-filter-branch
Will merge this weekend.
* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
+ git-svn: allow dcommit to retain local merge information
Haven't heard major breakage report, so hopefully can merge by
the end of the month.
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
+ make git barf when an alias changes environment variables
+ setup_git_directory: fix segfault if repository is found in cwd
+ test GIT_WORK_TREE
+ extend rev-parse test for --is-inside-work-tree
+ Use new semantics of is_bare/inside_git_dir/inside_work_tree
+ introduce GIT_WORK_TREE to specify the work tree
+ test git rev-parse
+ rev-parse: introduce --is-bare-repository
+ rev-parse: document --is-inside-git-dir
I've been resisting this but I think its definition of is-bare
is a bit saner than what we have in 'master', and I think it is
the right direction in the longer term. HOWEVER, I am not sure
about the implementation and corner cases, e.g. what should it
do in receive-pack? You cannot rely on user setting GIT_WORK_TREE
environment -- rather, receive-pack is responsible for setting
up a sane environment for other commands to work in.
* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
- Quiet the output from git-init when cloning, if requested.
- Add an option to quiet git-init.
^ permalink raw reply
* Re: Strange diff behavior?
From: Jason Sewall @ 2007-06-21 7:02 UTC (permalink / raw)
To: git
In-Reply-To: <20070621065043.GA30521@moooo.ath.cx>
As I mentioned in the ps, I git-diff --check shows nothing. As a
matter of fact, I do have color turned on and the pluses are green and
minuses red, but there are none of the characteristic red blocks that
trailing whitespace makes.
On 6/20/07, Matthias Lederhofer <matled@gmx.net> wrote:
> Jason Sewall <jasonsewall@gmail.com> wrote:
> > It seems like every change listed after the first one is meaningless.
> > I really think I just don't understand something about the diff
> > algorithm. Can someone tell my why those empty lines are recorded as
> > changes?
>
> This are whitespace changes.
>
> $ git diff --color
>
> marks whitespaces at the end of the line with a red background color
> so you can see what changed. I also use vim with :set list to see
> whitespace changes, e.g.
>
> $ git diff | vim -c 'set list' -
>
> If you like to have colors (not just in diff) permnanently you can add
> this to your .git/config or ~/.gitconfig:
>
> [color]
> branch = auto
> diff = auto
> status = auto
> pager = true
>
> See also git-config(1) for more information on these and other
> configuration options.
>
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Junio C Hamano @ 2007-06-21 7:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070621061045.GG8477@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> If you want to be less defensive, OK, it would also reduce the
> patch size a bit, but may allow someone to add an insane item to
> the list.
If we were to go this route (which I am not convinced is the
right direction yet---using "git version" to check the version
and say "1.5.3 has blame -w" might be easier to manage, and that
needs to be maintained only by the tools that care about the
particular feature, "blame -w"), we will potentially be talking
about hundreds of features in the long run. I would rather want
to automate this even further, as keeping the feature list and
features together would become huge maintenance headache.
So, first of all, I would want the list of features in
supported_features[] to come from a separate file, whose sole
purpose is to have that list. I would even suggest making it an
generated file, which depends on the source files (not
necessarily limited to C files), and built from within the build
procedure.
Whenever you add a new command line option, you would add a
greppable comment near it, something like...
else if (!strcmp("-s", arg))
output_option |= OUTPUT_NO_AUTHOR;
+ /* FEATURE[[[blame-ignore-whitespace]]] */
+ else if (!strcmp("-w", arg))
+ xdl_opts |= XDF_IGNORE_WHITESPACE;
else if (!strcmp("-S", arg) && ++i < argc)
revs_file = argv[i];
and have Makefile extract them, sort them and build the meat of
supported_features[] array automatically.
Unless we have something like that, I have to worry about merge
conflicts every time a new topic graduates to 'master'.
>> > +static int supports_feature(const char *the_feature)
>>
>> And you can perform a bsearch here. instead of linear.
>
> Sure. But I'm actually expecting more for Porcelain that cares
> to run `git version --list-features` and store that output into
> its own internal table,
Ok, that is probably a sane assumption.
> .... I figured the bsearch would take more
> code than the linear, and probably wasn't worth it in this dark
> little corner of Git.
Huh? Don't you already have compar() function that bsearch(3)
can take?
>> I suspect that this patch is meant for my 'maint' (and
>> 1.5.2.3). Or is it for my 'master'? What's your plan to handle
>> transition?
>
> Eh, sorry, I should have mentioned that. I meant for you to apply
> this to your master, where `git blame -w` is already present.
>
> Currently with next I get:
>
> $ git version --list-features
> git version 1.5.2.2.1050.g51a8b
>
> So what I was planning on doing in git-gui was running that, and if
> I just get one line with `git version` on it (which is an insane
> feature name btw) then I know --list-features is not supported,
> and neither is any other feature that I might be looking for from
> the --list-features command.
>
> On the other hand if --list-features is actually supported instead
> I'll get back at least a line with "list-features" on it, and I
> won't get a line with "git version" on it (as that is an insane
> feature name).
The explaination why "futureproofing" is unnecessary for 'maint'
is good, but that does not necessarily mean --list-featues would
need to list _all_ the features in the version that supports
that. "blame -w" is in 'master' already, for example. Is
"have-mergetool" a feature? Yes, it is. But you already know
the command exists if "git version" knows --list-features.
> Hmm. So assuming that is true, under what rule do you propose we
> add new features to that array in the future? And what name(s)
> do we give to them?
Assuming if this --list-features is a viable approach in the
long run, my gut feeling of relative order of things is:
(1) We prepare rock-solid runtime with an _EMPTY_ feature array
in 'master'.
(2) We add automated feature array management in 'master', as
outlined above.
(3) Merge the above two to 'next'.
(4) Update all existing topics, including the ones that are
already in 'next', with the feature mark-up in comment
(i.e. "FEATURE[[[feature-name]]]").
After (3) happens, any new topics that introduce a new feature
should be accompanied with the feature mark-up.
When an update appears on 'master' _after_ (1) and (2) happens
_but_ Porcelain writers like yourself do not realize that the
feature would be _very_ helpful for their Porcelains, and would
want to be able to tell if it exists via --list-features, long
after we start to support the feature, we might retroactively
have to add the feature mark-up. There will be gap between the
commit that actually introduce and make the feature usable, and
the commit that teaches "git version" to talk about it in such a
case. But I think that should be Ok.
I do not think we want to keep track of every little "features"
if no Porcelain cares about it.
Here is a list of potential "feature names", from the latest
"What's cooking" message.
log-unlimited-message
log-follow
oneline-first-paragraph
svn-merge-local
work-tree-environ
filter-branch
^ permalink raw reply
* Re: Strange diff behavior?
From: Matthias Lederhofer @ 2007-06-21 6:50 UTC (permalink / raw)
To: Jason Sewall; +Cc: git
In-Reply-To: <31e9dd080706201802h9dcbffawd82575d09e082155@mail.gmail.com>
Jason Sewall <jasonsewall@gmail.com> wrote:
> It seems like every change listed after the first one is meaningless.
> I really think I just don't understand something about the diff
> algorithm. Can someone tell my why those empty lines are recorded as
> changes?
This are whitespace changes.
$ git diff --color
marks whitespaces at the end of the line with a red background color
so you can see what changed. I also use vim with :set list to see
whitespace changes, e.g.
$ git diff | vim -c 'set list' -
If you like to have colors (not just in diff) permnanently you can add
this to your .git/config or ~/.gitconfig:
[color]
branch = auto
diff = auto
status = auto
pager = true
See also git-config(1) for more information on these and other
configuration options.
^ permalink raw reply
* Re: Strange diff behavior?
From: Raimund Bauer @ 2007-06-21 6:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jason Sewall, git
In-Reply-To: <Pine.LNX.4.64.0706210212060.4059@racer.site>
On Thu, 2007-06-21 at 02:13 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Jason Sewall wrote:
>
> > It seems like every change listed after the first one is meaningless.
>
> Just a guess: core.autocrlf=true?
My guess: apply.whitespace=strip
> Ciao,
> Dscho
--
best regards
Ray
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Marco Costalba @ 2007-06-21 6:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706200940000.3593@woody.linux-foundation.org>
On 6/20/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> That said, you really would be better off using
>
> git blame -M --incremental
>
That's how it is currently inplemented in qgit:
- Main view revision list + graph: git-rev-list
- File history and annotation: git-rev-list
The possible options are:
ALL GIT LOG
-------------------
- Main view revision list + graph: git-log
- File history and annotation: git-log
Good: easy implementation and a lot of common code to share among
modules, all the current features (see "range fltering" below) are
preserved
Bad: Currently git-log does not support --stdin option, required IMHO
when git-log is runned by a tool, not a user, due to the possibility
of a very long command line.
MIXED
---------
- Main view revision list + graph: git-rev-list
- File history and annotation: git-blame
Good: Gain additional features of git-blame against git-log
Bad: FWIK "git blame -M --incremental" does not support annotating all
the files in history in one go, as it is possible both with
git-rev-list and git-log. You have to re-annotate the new file when
browsing file history with the mouse.
Impementation cannot reuse big chunks of code, so a lot of new code is
needed and probably old one will not disappear.
FWIK "git blame -M --incremental" does not support "code lines range
filtering", when with the mouse you select some lines of code and
after filtering you see the subset of file's history that modified
that range of code. This feature is currently supported by qgit
annotating code.
Also jump to the same currently selected code line when switching to a
different version in file history it is currently supported by
annotate code.
INTERESTING
--------------------
- Main view revision list + graph: git-log
- File history and annotation: git-blame
A curious mix.
Some advice?
Thanks
Marco
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Junio C Hamano @ 2007-06-21 6:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jakub Narebski
In-Reply-To: <20070621045333.GB13977@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> To keep things really simple in git-blame we require that the new
> --gui option be the first argument on the command line, and cannot
> be combined with any other option. If it is the first argument
> then we punt our entire command line as-is into `git gui blame`,
> where that program's option parser will handle selecting out the
> revision and path, if present.
>
> Its simple and not very intrusive, but has the odd behavior that
> no option (like --contents) can be used along with it, because
> git-gui's own blame subcommand doesn't recognize them. On the
> other hand it is a useful DWIMery for `git gui blame`.
Hmm. Now, how does "git-blame" tell if there is usable git-gui
installed with it? Will we have "git-gui --list-features"?
In either case, I think this description is far less than optimum:
> diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
> index 66f1203..96ff02d 100644
> --- a/Documentation/git-blame.txt
> +++ b/Documentation/git-blame.txt
> @@ -10,6 +10,7 @@ SYNOPSIS
> [verse]
> 'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
> [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
> + [--gui]
> [<rev> | --contents <file>] [--] <file>
It essentially is two commands with different calling
conventions. I would probably do this instead if I were doing
this:
SYNOPSIS
--------
[verse]
'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
'git-blame' --gui [<rev>] [--] <file>
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Shawn O. Pearce @ 2007-06-21 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wg55065.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> Unless we are talking about dynamically extensible feature list
> (eh, dll, anybody?), it might be easier to keep (1) the list
> sorted, and (2) free of insane feature name in
> supported_features[] array at the source level. Then you can
> lose that is_feature_name_sane() function.
Yes, this is true. But I'm being overly defensive here. If the
list does get out of order we force it back in --list-features just
to be consistent in output, and t0000 will fail if any item in the
list is insane.
If you want to be less defensive, OK, it would also reduce the
patch size a bit, but may allow someone to add an insane item to
the list.
> > +static int supports_feature(const char *the_feature)
>
> And you can perform a bsearch here. instead of linear.
Sure. But I'm actually expecting more for Porcelain that cares
to run `git version --list-features` and store that output into
its own internal table, then consult that table rather than the
--supports-feature option. I figured the bsearch would take more
code than the linear, and probably wasn't worth it in this dark
little corner of Git.
> > +test_expect_failure \
> > + 'feature "THISNEVERWILLBEAGITFEATURE" is not supported' \
> > + 'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'
>
> I would expect that THISNEW... will get complaint saying "That
> is not a valid feature name, as it has uppercase", from a
> version that has is_feature_name_sane() function.
Eh, probably true. I guess I should make that lowercase so it is
actually a sane name, just one so unlikely that we will never use it.
> I suspect that this patch is meant for my 'maint' (and
> 1.5.2.3). Or is it for my 'master'? What's your plan to handle
> transition?
Eh, sorry, I should have mentioned that. I meant for you to apply
this to your master, where `git blame -w` is already present.
Currently with next I get:
$ git version --list-features
git version 1.5.2.2.1050.g51a8b
So what I was planning on doing in git-gui was running that, and if
I just get one line with `git version` on it (which is an insane
feature name btw) then I know --list-features is not supported,
and neither is any other feature that I might be looking for from
the --list-features command.
On the other hand if --list-features is actually supported instead
I'll get back at least a line with "list-features" on it, and I
won't get a line with "git version" on it (as that is an insane
feature name).
I guess it is good that our cmd_version() routine never actually
checked to see if its argv[] matched what it expects to receive
(nothing up until now). :)
Now I'm fine with you applying this back into a 1.5.2.x maint
release, but because of the cmd_version() behavior I don't think
that is really required. Nor am I looking for you to cherry-pick
back the `git blame -w` feature.
> If this is meant to be only for 1.5.3 and later, then you know
> that "blame -w" is available as well, so the fact you can do
> "git version --list-features" alone tells you that you can use
> "blame -w", among other many things, such as "diff -C -C"
> instead of --find-copies-harder.
Yes, that is true.
> Where does the above discussion lead us? It essentially means,
> in either case, "blame-ignore-whitespace" should not be in that
> supported_features[] array.
Hmm. So assuming that is true, under what rule do you propose we
add new features to that array in the future? And what name(s)
do we give to them?
For a recent hypothetical example, assume this patch was already
applied in your master by the time Linus submitted his useful hack
`git log --follow`. How would we signal in the supported_features[]
that log would understand --follow for a single file pathname?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Sam Vilain @ 2007-06-21 6:01 UTC (permalink / raw)
To: Dave O'Neill; +Cc: git
In-Reply-To: <1182392095394-git-send-email-dmo@roaringpenguin.com>
Dave O'Neill wrote:
> SVK likes to begin all commit messages with a line of the format:
> r12345@hostname: user | YYYY-MM-DD HH:MM:SS -ZZZZ
> which makes the import desperately ugly in git. This adds a -k option to move
> this extra SVK commit line to the end of the commit message, rather than
> keeping it at the beginning.
This is a good idea, of course if somebody didn't specify the magic -I
switch to their 'svk sm' incantation then there will be multiple changes
listed in a single revision
some examples
http://dev.catalystframework.org/svnweb/Catalyst/revision/?rev=6477
svn log -r 7190:7190 http://svn.pugscode.org/pugs
There was also a pretty nasty bug in SVK which pushed huge commitlogs
with no changes
see for example
http://utsl.gen.nz/gitweb/?p=pugs;a=commit;h=817b73f
(or:
svn log -r 14734:14734 http://svn.pugscode.org/pugs
svn diff -r 14733:14734 http://svn.pugscode.org/pugs
)
That occurred often enough that it might even be worth detecting and
dealing with specially. ie, if multiple SVK changesets are seen in a
commit with no changes, mark it as likely bogus.
Yeah, I'm not sure what to say about all this other than "lolsvn".
Sam.
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Junio C Hamano @ 2007-06-21 5:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070621045903.GA14047@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> As a porcelain author I'm finding it difficult to keep track of
> what features I can use in git-gui. Newer versions of Git have
> newer capabilities but they don't always immediately get newer
> version numbers that I can easily test for.
Two and half comments, and a discussion.
> +static const char *supported_features[] = {
> + "blame-ignore-whitespace",
> + "list-features",
> +};
> +
> /* most GUI terminals set COLUMNS (although some don't export it) */
> static int term_columns(void)
> {
> @@ -190,10 +195,78 @@ void help_unknown_cmd(const char *cmd)
> exit(1);
> }
>
> +static int is_feature_name_sane(const char *a)
> +{
> + if (!*a || *a == '-')
> + return 0;
> + for (; *a; a++) {
> + if (! ((*a >= 'a' && *a <= 'z')
> + || (*a >= '0' && *a <= '9')
> + || *a == '-'))
> + return 0;
> + }
> + return 1;
> +}
> +
> +static int cmp_feature(const void *a_, const void *b_)
> +{
> + const char *a = *((const char **)a_);
> + const char *b = *((const char **)b_);
> + return strcmp(a, b);
> +}
> +
> +static void list_features()
> +{
> + unsigned cnt = ARRAY_SIZE(supported_features);
> + unsigned i;
> +
> + qsort(supported_features, cnt,
> + sizeof(supported_features[0]), cmp_feature);
> ...
> +}
Unless we are talking about dynamically extensible feature list
(eh, dll, anybody?), it might be easier to keep (1) the list
sorted, and (2) free of insane feature name in
supported_features[] array at the source level. Then you can
lose that is_feature_name_sane() function.
> +static int supports_feature(const char *the_feature)
> +{
> + unsigned cnt = ARRAY_SIZE(supported_features);
> + unsigned i;
> +
> + for (i = 0; i < cnt; i++) {
> + if (!strcmp(supported_features[i], the_feature))
> + return 0;
> + }
> + return 1;
> +}
And you can perform a bsearch here. instead of linear.
> +test_expect_failure \
> + 'feature "THISNEVERWILLBEAGITFEATURE" is not supported' \
> + 'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'
I would expect that THISNEW... will get complaint saying "That
is not a valid feature name, as it has uppercase", from a
version that has is_feature_name_sane() function.
I suspect that this patch is meant for my 'maint' (and
1.5.2.3). Or is it for my 'master'? What's your plan to handle
transition?
For example, if this appears on 1.5.2.3, then
supported_features[] should not have blame-ignore-whitespace,
unless we are talking about cherry-picking, and I honestly do
not think "blame -w" deserves to go to the maintenance only
series. On the other hand, --list-features could go to 'maint'
under 'future prooofing' category, I guess.
If this is meant to be only for 1.5.3 and later, then you know
that "blame -w" is available as well, so the fact you can do
"git version --list-features" alone tells you that you can use
"blame -w", among other many things, such as "diff -C -C"
instead of --find-copies-harder.
Where does the above discussion lead us? It essentially means,
in either case, "blame-ignore-whitespace" should not be in that
supported_features[] array.
^ permalink raw reply
* Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"
From: Shawn O. Pearce @ 2007-06-21 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5tx5333.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> The blame window shows "who wrote the piece originally" and "who
> moved it there" in two columns. In order to identify the former
> more correctly, it helps to use the new -w option.
...
> diff --git a/lib/blame.tcl b/lib/blame.tcl
> index 139171d..a412a8c 100644
> --- a/lib/blame.tcl
> +++ b/lib/blame.tcl
> @@ -672,7 +672,7 @@ method _read_blame {fd cur_w cur_d cur_s} {
> close $fd
> if {$cur_w eq $w_asim} {
> _exec_blame $this $w_amov @amov_data \
> - [list -M -C -C] \
> + [list -w -C -C] \
> { original location}
> } else {
> set current_fd {}
>
I've wanted to do this since you introduced `git blame -w`. But I
can't use it, because I cannot trust that -w is there. For example
it is not in maint, but the new blame viewer from git-gui is.
Apply my --list-features patch to core Git and I'll activate -w in
git-gui when --list-features claims the 'blame-ignore-whitespace'
feature is available.
;-)
--
Shawn.
^ permalink raw reply
* [PATCH] Introduce git version --list-features for porcelain use
From: Shawn O. Pearce @ 2007-06-21 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
As a porcelain author I'm finding it difficult to keep track of
what features I can use in git-gui. Newer versions of Git have
newer capabilities but they don't always immediately get newer
version numbers that I can easily test for.
This is a simple plumbing option that lets a porcelain ask the
plumbing for its capabilities, at which point the porcelain can
work around anything missing, or recommend to the user that they
upgrade their plumbing layer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Because 'maint' does not support `git-blame -w` I can't apply your
recent (and insanely good idea) 'git-gui: use "blame -w -C -C" for
"where did it come from, originally?"' without something like the
following, so I know that `git blame -w -C -C` will be accepted
by the underlying plumbing. ;-)
help.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t0000-basic.sh | 16 +++++++++++
2 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..9f24a0f 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,11 @@
#include "common-cmds.h"
#include <sys/ioctl.h>
+static const char *supported_features[] = {
+ "blame-ignore-whitespace",
+ "list-features",
+};
+
/* most GUI terminals set COLUMNS (although some don't export it) */
static int term_columns(void)
{
@@ -190,10 +195,78 @@ void help_unknown_cmd(const char *cmd)
exit(1);
}
+static int is_feature_name_sane(const char *a)
+{
+ if (!*a || *a == '-')
+ return 0;
+ for (; *a; a++) {
+ if (! ((*a >= 'a' && *a <= 'z')
+ || (*a >= '0' && *a <= '9')
+ || *a == '-'))
+ return 0;
+ }
+ return 1;
+}
+
+static int cmp_feature(const void *a_, const void *b_)
+{
+ const char *a = *((const char **)a_);
+ const char *b = *((const char **)b_);
+ return strcmp(a, b);
+}
+
+static void list_features()
+{
+ unsigned cnt = ARRAY_SIZE(supported_features);
+ unsigned i;
+
+ qsort(supported_features, cnt,
+ sizeof(supported_features[0]), cmp_feature);
+ for (i = 0; i < cnt; i++) {
+ const char *f = supported_features[i];
+ if (!is_feature_name_sane(f))
+ die("feature name \"%s\" is bogus", f);
+ printf("%s\n", f);
+ }
+}
+
+static int supports_feature(const char *the_feature)
+{
+ unsigned cnt = ARRAY_SIZE(supported_features);
+ unsigned i;
+
+ for (i = 0; i < cnt; i++) {
+ if (!strcmp(supported_features[i], the_feature))
+ return 0;
+ }
+ return 1;
+}
+
+static const char version_usage[] =
+"git-version [(--list-features | --supports-feature=<name>*)]";
+
int cmd_version(int argc, const char **argv, const char *prefix)
{
- printf("git version %s\n", git_version_string);
- return 0;
+ int i, ret = 0, list = 0, test = 0;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--list-features"))
+ list = 1;
+ else if (!prefixcmp(arg, "--supports-feature=")) {
+ test = 1;
+ ret |= supports_feature(arg + 19);
+ } else
+ usage(version_usage);
+ }
+
+ if (list && test)
+ die("cannot use both --list-features and --supports-feature");
+ if (list)
+ list_features();
+ if (!list && !test)
+ printf("git version %s\n", git_version_string);
+ return ret;
}
int cmd_help(int argc, const char **argv, const char *prefix)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 8bfe832..9fc5824 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -31,6 +31,22 @@ fi
. ./test-lib.sh
################################################################
+# git version
+
+test_expect_success \
+ 'git version is functional' \
+ 'git version'
+test_expect_success \
+ 'git version --list-features' \
+ 'git version --list-features'
+test_expect_success \
+ 'feature "list-features" is supported' \
+ 'git version --supports-feature=list-features'
+test_expect_failure \
+ 'feature "THISNEVERWILLBEAGITFEATURE" is not supported' \
+ 'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'
+
+################################################################
# git-init has been done in an empty repository.
# make sure it is empty.
--
1.5.2.2.1050.g51a8b
^ permalink raw reply related
* [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Shawn O. Pearce @ 2007-06-21 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
Jakub Narebski proposed the idea of having a new --gui option for
git-blame that would start `git gui blame` with the arguments that
were given to git-blame on the command line. This actually makes
a lot of sense, as some users may first reach for `git blame` and
find the handy `--gui` option, rather than looking for the blame
subcommand of `git gui`.
To keep things really simple in git-blame we require that the new
--gui option be the first argument on the command line, and cannot
be combined with any other option. If it is the first argument
then we punt our entire command line as-is into `git gui blame`,
where that program's option parser will handle selecting out the
revision and path, if present.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
From Jakub Narebski <jnareb@gmail.com>:
> or have "git blame --gui" invoke "git gui blame"
Not a bad idea. Here's an implementation that does that.
Its simple and not very intrusive, but has the odd behavior that
no option (like --contents) can be used along with it, because
git-gui's own blame subcommand doesn't recognize them. On the
other hand it is a useful DWIMery for `git gui blame`.
Documentation/git-blame.txt | 8 ++++++++
builtin-blame.c | 12 +++++++++++-
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 66f1203..96ff02d 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [--gui]
[<rev> | --contents <file>] [--] <file>
DESCRIPTION
@@ -67,6 +68,13 @@ include::blame-options.txt[]
Ignore whitespace when comparing parent's version and
child's to find where the lines came from.
+--gui::
+ Instead of displaying the blame output on the text console,
+ start git-gui's graphical blame viewer. This option must
+ be the first option supplied, and cannot be combined with
+ any other option described here, except the optional <rev>
+ and the required <file> arguments.
+
THE PORCELAIN FORMAT
--------------------
diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..2f50a4a 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -18,9 +18,10 @@
#include "cache-tree.h"
#include "path-list.h"
#include "mailmap.h"
+#include "exec_cmd.h"
static char blame_usage[] =
-"git-blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [--contents <filename>] [--incremental] [commit] [--] file\n"
+"git-blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [--contents <filename>] [--incremental] [--gui] [commit] [--] file\n"
" -c Use the same output mode as git-annotate (Default: off)\n"
" -b Show blank SHA-1 for boundary commits (Default: off)\n"
" -l Show long commit SHA1 (Default: off)\n"
@@ -34,6 +35,7 @@ static char blame_usage[] =
" -L n,m Process only line range n,m, counting from 1\n"
" -M, -C Find line movements within and across files\n"
" --incremental Show blame entries as we find them, incrementally\n"
+" --gui Use git-gui's graphical blame viewer\n"
" --contents file Use <file>'s contents as the final image\n"
" -S revs-file Use revisions from revs-file instead of calling git-rev-list\n";
@@ -2137,6 +2139,12 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
const char *contents_from = NULL;
cmd_is_annotate = !strcmp(argv[0], "annotate");
+ if (!cmd_is_annotate && argc > 1 && !strcmp(argv[1], "--gui")) {
+ argv[0] = "gui";
+ argv[1] = "blame";
+ execv_git_cmd(argv);
+ die("Cannot execute git-gui blame: %s", strerror(errno));
+ }
git_config(git_blame_config);
save_commit_buffer = 0;
@@ -2214,6 +2222,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
else if (!strcmp("-p", arg) ||
!strcmp("--porcelain", arg))
output_option |= OUTPUT_PORCELAIN;
+ else if (!strcmp("--gui", arg))
+ die("Cannot combine --gui with %s", argv[i - 1]);
else if (!strcmp("--", arg)) {
seen_dashdash = 1;
i++;
--
1.5.2.2.1050.g51a8b
^ permalink raw reply related
* [PATCH 1/2] Document git-gui, git-citool as mainporcelain manual pages
From: Shawn O. Pearce @ 2007-06-21 4:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
Jakub Narebski pointed out that the git-gui blame viewer is not a
widely known feature, but is incredibly useful. Part of the issue
is advertising. Up until now we haven't even referenced git-gui from
within the core Git manual pages, mostly because I just wasn't sure
how I wanted to supply git-gui documentation to end-users, or how
that documentation should integrate with the core Git documentation.
Based upon Jakub's comment that many users may not even know that
the gui is available in a stock Git distribution I'm offering up
two basic manual pages: git-citool and git-gui. These should offer
enough of a starting point for users to identify that the gui exists,
and how to start it. Future releases of git-gui may contain their
own documentation system available from within a running git-gui.
But not today.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
From Jakub Narebski <jnareb@gmail.com>:
> It would be nice though to have git-gui(1) man page describing
> 'blame' subcommand of git-gui
Yes, it would! You might find one below. ;-)
Documentation/cmd-list.perl | 2 +
Documentation/git-citool.txt | 32 ++++++++++++
Documentation/git-gui.txt | 115 ++++++++++++++++++++++++++++++++++++++++++
git.spec.in | 12 +++--
4 files changed, 156 insertions(+), 5 deletions(-)
create mode 100644 Documentation/git-citool.txt
create mode 100644 Documentation/git-gui.txt
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index a181f75..fcea1d7 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -86,6 +86,7 @@ git-check-attr purehelpers
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
+git-citool mainporcelain
git-clean mainporcelain
git-clone mainporcelain
git-commit mainporcelain
@@ -111,6 +112,7 @@ git-fsck ancillaryinterrogators
git-gc mainporcelain
git-get-tar-commit-id ancillaryinterrogators
git-grep mainporcelain
+git-gui mainporcelain
git-hash-object plumbingmanipulators
git-http-fetch synchelpers
git-http-push synchelpers
diff --git a/Documentation/git-citool.txt b/Documentation/git-citool.txt
new file mode 100644
index 0000000..5217ab2
--- /dev/null
+++ b/Documentation/git-citool.txt
@@ -0,0 +1,32 @@
+git-citool(1)
+=============
+
+NAME
+----
+git-citool - Graphical alternative to git-commit
+
+SYNOPSIS
+--------
+'git citool'
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical interface to review modified files, stage
+them into the index, enter a commit message and record the new
+commit onto the current branch. This interface is an alternative
+to the less interactive gitlink:git-commit[1] program.
+
+git-citool is actually a standard alias for 'git gui citool'.
+See gitlink:git-gui[1] for more details.
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
new file mode 100644
index 0000000..bd613b2
--- /dev/null
+++ b/Documentation/git-gui.txt
@@ -0,0 +1,115 @@
+git-gui(1)
+==========
+
+NAME
+----
+git-gui - A portable graphical interface to Git
+
+SYNOPSIS
+--------
+'git gui' [<command>] [arguments]
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical user interface to Git. git-gui focuses
+on allowing users to make changes to their repository by making
+new commits, amending existing ones, creating branches, performing
+local merges, and fetching/pushing to remote repositories.
+
+Unlike gitlink:gitk[1], git-gui focuses on commit generation
+and single file annotation, and does not show project history.
+It does however supply menu actions to start a gitk session from
+within git-gui.
+
+git-gui is known to work on all popular UNIX systems, Mac OS X,
+and Windows (under both Cygwin and MSYS). To the extent possible
+OS specific user interface guidelines are followed, making git-gui
+a fairly native interface for users.
+
+COMMANDS
+--------
+blame::
+ Start a blame viewer on the specified file on the given
+ version (or working directory if not specified).
+
+browser::
+ Start a tree browser showing all files in the specified
+ commit (or 'HEAD' by default). Files selected through the
+ browser are opened in the blame viewer.
+
+citool::
+ Start git-gui and arrange to make exactly one commit before
+ exiting and returning to the shell. The interface is limited
+ to only commit actions, slightly reducing the application's
+ startup time and simplifying the menubar.
+
+version::
+ Display the currently running version of git-gui.
+
+
+Examples
+--------
+git gui blame Makefile::
+
+ Show the contents of the file 'Makefile' in the current
+ working directory, and provide annotations for both the
+ original author of each line, and who moved the line to its
+ current location. The uncommitted file is annotated, and
+ uncommitted changes (if any) are explicitly attributed to
+ 'Not Yet Committed'.
+
+git gui blame v0.99.8 Makefile::
+
+ Show the contents of 'Makefile' in revision 'v0.99.8'
+ and provide annotations for each line. Unlike the above
+ example the file is read from the object database and not
+ the working directory.
+
+git gui citool::
+
+ Make one commit and return to the shell when it is complete.
+
+git citool::
+
+ Same as 'git gui citool' (above).
+
+git gui browser maint::
+
+ Show a browser for the tree of the 'maint' branch. Files
+ selected in the browser can be viewed with the internal
+ blame viewer.
+
+See Also
+--------
+'gitk(1)'::
+ The git repository browser. Shows branches, commit history
+ and file differences. gitk is the utility started by
+ git-gui's Repository Visualize actions.
+
+Other
+-----
+git-gui is actually maintained as an independent project, but stable
+versions are distributed as part of the Git suite for the convience
+of end users.
+
+A git-gui development repository can be obtained from:
+
+ git clone git://repo.or.cz/git-gui.git
+
+or
+
+ git clone http://repo.or.cz/r/git-gui.git
+
+or browsed online at http://repo.or.cz/w/git-gui.git/[].
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/git.spec.in b/git.spec.in
index b9dc1d5..287057e 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -164,11 +164,10 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/git-gui
%{_bindir}/git-citool
%{_datadir}/git-gui/
-# Not Yet...
-# %{!?_without_docs: %{_mandir}/man1/git-gui.1}
-# %{!?_without_docs: %doc Documentation/git-gui.html}
-# %{!?_without_docs: %{_mandir}/man1/git-citool.1}
-# %{!?_without_docs: %doc Documentation/git-citool.html}
+%{!?_without_docs: %{_mandir}/man1/git-gui.1}
+%{!?_without_docs: %doc Documentation/git-gui.html}
+%{!?_without_docs: %{_mandir}/man1/git-citool.1}
+%{!?_without_docs: %doc Documentation/git-citool.html}
%files -n gitk
%defattr(-,root,root)
@@ -188,6 +187,9 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %doc Documentation/technical}
%changelog
+* Thu Jun 21 2007 Shawn O. Pearce <spearce@spearce.org>
+- Added documentation files for git-gui
+
* Tue May 13 2007 Quy Tonthat <qtonthat@gmail.com>
- Added lib files for git-gui
- Added Documentation/technical (As needed by Git Users Manual)
--
1.5.2.2.1050.g51a8b
^ permalink raw reply related
* Re: [PATCH] git-send-email: RFC2822 compliant Message-ID
From: Michael Hendricks @ 2007-06-21 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ipytkt5.fsf@assigned-by-dhcp.pobox.com>
On Wed, Jun 20, 2007 at 01:47:34PM -0700, Junio C Hamano wrote:
> How about doing this instead?
>
> * Move call to make_message_id() to where it matters, namely,
> before the $message_id is needed to be placed in the
> generated e-mail header; this has an important side effect of
> making it clear that $from is already available.
>
> * Throw in Sys::Hostname::hostname() just for fun, although I
> suspect that the code would never trigger due to the modified
> call sequence that makes sure $from is always available.
>
> ---
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 7c0c90b..9f75551 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -412,13 +412,21 @@ sub extract_valid_address {
> # 1 second since the last time we were called.
>
> # We'll setup a template for the message id, using the "from" address:
> -my $message_id_from = extract_valid_address($from);
> -my $message_id_template = "<%s-git-send-email-$message_id_from>";
>
> sub make_message_id
> {
> my $date = time;
> my $pseudo_rand = int (rand(4200));
> + my $du_part;
> + for ($from, $committer, $author) {
> + $du_part = extract_valid_address($_);
> + last if ($du_part ne '');
> + }
> + if ($du_part eq '') {
> + use Sys::Hostname qw();
> + $du_part = 'user@' . Sys::Hostname::hostname();
> + }
> + my $message_id_template = "<%s-git-send-email-$du_part>";
> $message_id = sprintf $message_id_template, "$date$pseudo_rand";
> #print "new message id = $message_id\n"; # Was useful for debugging
> }
> @@ -467,6 +475,8 @@ sub send_message
> $ccline = "\nCc: $cc";
> }
> $from = sanitize_address_rfc822($from);
> + make_message_id();
> +
> my $header = "From: $from
> To: $to${ccline}
> Subject: $subject
> @@ -533,7 +543,6 @@ X-Mailer: git-send-email $gitversion
>
> $reply_to = $initial_reply_to;
> $references = $initial_reply_to || '';
> -make_message_id();
> $subject = $initial_subject;
>
> foreach my $t (@files) {
> @@ -627,7 +636,6 @@ foreach my $t (@files) {
> $references = "$message_id";
> }
> }
> - make_message_id();
> }
>
> if ($compose) {
>
I like it. It eliminates two globals and makes the context of
make_message_id clearer.
--
Michael
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Linus Torvalds @ 2007-06-21 3:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, govindsalinas
In-Reply-To: <20070621030622.GD8477@spearce.org>
On Wed, 20 Jun 2007, Shawn O. Pearce wrote:
>
> I'm wondering if we shouldn't play the game of trying to match
> delete/add pairs up by not only similarity, but also by path
> basename.
I think we should just consider the basename as an "added
similarity bonus".
IOW, we currently sort purely by data similarity, but how about just
adding a small increment for "same base name".
We could make it actually use the similarity of the filename itself as the
basis for the increment, which would be even better, but the trivial thing
is to do something like
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -186,8 +186,11 @@ static int estimate_similarity(struct diff_filespec *src,
*/
if (!dst->size)
score = 0; /* should not happen */
- else
+ else {
score = (int)(src_copied * MAX_SCORE / max_size);
+ if (basename_same(src, dst))
+ score++;
+ }
return score;
}
and just implement that "basename_same()" function.
Or something.
I do agree that the filename logically can and probably _should_ count
towards the "similarity". The filename _is_ part of the data in the global
notion of "content", after all. It's the "index" to the data.
Linus
^ permalink raw reply
* Re: git-gui cannot find share/git-gui under cygwin
From: Shawn O. Pearce @ 2007-06-21 3:30 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <4678236A.9000606@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> wrote:
> Shawn O. Pearce wrote:
> >Yuck. I'm considering applying the following. It works ok on Mac
> >OS X where the bug isn't triggered anyway. ;-) I won't be able to
> >test on Cygwin until tomorrow.
>
> sorry, no joy. The problem is that gitexecdir=/usr/bin, but...
Thanks for the feedback.
> I don't think there is a portable solution here. Maybe just say
>
> if test "$(uname_O)" = Cygwin; then \
> GITGUI_RELATIVE=; \
>
> and be done with it.
Yup. Done. Now in my `maint`, `master` and `pu` branches.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Steven Grimm @ 2007-06-21 3:19 UTC (permalink / raw)
To: Dave O'Neill; +Cc: git
In-Reply-To: <1182392095394-git-send-email-dmo@roaringpenguin.com>
Dave O'Neill wrote:
> SVK likes to begin all commit messages with a line of the format:
> r12345@hostname: user | YYYY-MM-DD HH:MM:SS -ZZZZ
> which makes the import desperately ugly in git. This adds a -k option to move
> this extra SVK commit line to the end of the commit message, rather than
> keeping it at the beginning.
>
Any chance of applying this to git-svn instead? There has been talk of
deprecating git-svnimport since git-svn now does everything
git-svnimport does, and more. (If you believe that's not the case,
please describe what you're doing with git-svnimport that you can't do
with git-svn.)
-Steve
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Junio C Hamano @ 2007-06-21 3:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, govindsalinas
In-Reply-To: <20070621030622.GD8477@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> So Govind Salinas has found an interesting case in the rename
> detection code:
>
> $ git clone git://repo.or.cz/Widgit.git
> $ git diff -M --raw -r 192e^ 192e | grep .resx
> :100755 000000 4c8ab79... 0000000... D Form1.resx
> :100755 100755 9e70146... 9e70146... R100 CommitViewer.resx UI/CommitViewer.resx
> :100755 100755 90929fd... b40ff98... C091 RepoManager.resx UI/Form1.resx
> :100755 100755 90929fd... 90929fd... C100 PreferencesEditor.resx UI/PreferencesEditor.resx
> :100755 100755 90929fd... 90929fd... R100 PreferencesEditor.resx UI/RepoManager.resx
> :100755 100755 90929fd... 8535007... R097 RepoManager.resx UI/RepoTreeView.resx
>
> In this case several files had identical old images, and some
> kept that old image during the rename. Unfortunately because of
> the ordering of the files in the tree Git has decided to "rename"
> the PreferencesEditor.resx file to UI/RepoManager.resx, rather than
> renaming RepoManager.resx to UI/RepoManager.resx. Go Git.
>
> I'm wondering if we shouldn't play the game of trying to match
> delete/add pairs up by not only similarity, but also by path
> basename. In the case above its exactly what Govind thought should
> happen; he moved the file from one directory to another, and didn't
> even change its content during the move. But Git decided "better"
> to use a totally different file in the "rename".
Actually, git did not decide anything, and certainly not better.
Having many "identical files" in the preimage is just stupid to
begin with (if you know they are identical, why are you storing
copies, instead of your build procedure to reuse the same file),
so the algorithm did not bother finding a better match among
"equals".
I am not opposed to a patch that says "Ok, these two preimages
have identical similarity score, *AND* indeed the preimages have
the same contents --- we tiebreak them with other heuristics to
help stupid projects better". And I can see basename similarity
one of the useful heuristics you could use.
^ permalink raw reply
* Basename matching during rename/copy detection
From: Shawn O. Pearce @ 2007-06-21 3:06 UTC (permalink / raw)
To: git; +Cc: govindsalinas
So Govind Salinas has found an interesting case in the rename
detection code:
$ git clone git://repo.or.cz/Widgit.git
$ git diff -M --raw -r 192e^ 192e | grep .resx
:100755 000000 4c8ab79... 0000000... D Form1.resx
:100755 100755 9e70146... 9e70146... R100 CommitViewer.resx UI/CommitViewer.resx
:100755 100755 90929fd... b40ff98... C091 RepoManager.resx UI/Form1.resx
:100755 100755 90929fd... 90929fd... C100 PreferencesEditor.resx UI/PreferencesEditor.resx
:100755 100755 90929fd... 90929fd... R100 PreferencesEditor.resx UI/RepoManager.resx
:100755 100755 90929fd... 8535007... R097 RepoManager.resx UI/RepoTreeView.resx
In this case several files had identical old images, and some
kept that old image during the rename. Unfortunately because of
the ordering of the files in the tree Git has decided to "rename"
the PreferencesEditor.resx file to UI/RepoManager.resx, rather than
renaming RepoManager.resx to UI/RepoManager.resx. Go Git.
I'm wondering if we shouldn't play the game of trying to match
delete/add pairs up by not only similarity, but also by path
basename. In the case above its exactly what Govind thought should
happen; he moved the file from one directory to another, and didn't
even change its content during the move. But Git decided "better"
to use a totally different file in the "rename".
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Set correct date for tags.
From: Junio C Hamano @ 2007-06-21 2:52 UTC (permalink / raw)
To: Dave O'Neill; +Cc: git
In-Reply-To: <11823921031931-git-send-email-dmo@roaringpenguin.com>
I suspect (I haven't looked at the evolution history of these
import scripts) this was copied from git-cvsimport.perl. I
would prefer to fix it the same way as 5c08931, which looks like
this:
commit 5c08931dfc9fa0acbf8667581e4c98d643e66dbe
Author: Elvis Pranskevichus <el@prans.net>
Use git-tag in git-cvsimport
---
git-cvsimport.perl | 26 ++------------------------
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 4e6c9c6..524c9bb 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -771,31 +771,9 @@ sub commit {
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
$xtag =~ s/[\/]/$opt_s/g;
-
- my $pid = open2($in, $out, 'git-mktag');
- print $out "object $cid\n".
- "type commit\n".
- "tag $xtag\n".
- "tagger $author_name <$author_email>\n"
- or die "Cannot create tag object $xtag: $!\n";
- close($out)
- or die "Cannot create tag object $xtag: $!\n";
-
- my $tagobj = <$in>;
- chomp $tagobj;
-
- if ( !close($in) or waitpid($pid, 0) != $pid or
- $? != 0 or $tagobj !~ /^[0123456789abcdef]{40}$/ ) {
- die "Cannot create tag object $xtag: $!\n";
- }
-
-
- open(C,">$git_dir/refs/tags/$xtag")
+
+ system('git-tag', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
- print C "$tagobj\n"
- or die "Cannot write tag $xtag: $!\n";
- close(C)
- or die "Cannot write tag $xtag: $!\n";
print "Created tag '$xtag' on '$branch'\n" if $opt_v;
}
^ permalink raw reply related
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