* Re: [PATCH] Add another fast-import example, this time for .zip files
From: Johannes Schindelin @ 2008-06-30 22:53 UTC (permalink / raw)
To: spearce, git
In-Reply-To: <alpine.DEB.1.00.0806301948130.9925@racer>
Hi,
On Mon, 30 Jun 2008, Johannes Schindelin wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I needed that today.
... and I needed that on top, which I forgot to commit, and therefore
never sent in my first mail on this subject:
-- snipsnap --
diff --git a/contrib/fast-import/import-zip.py b/contrib/fast-import/import-zips.py
similarity index 85%
rename from contrib/fast-import/import-zip.py
rename to contrib/fast-import/import-zips.py
index 4200a66..fcf5823 100755
--- a/contrib/fast-import/import-zip.py
+++ b/contrib/fast-import/import-zips.py
@@ -40,6 +40,11 @@ for zipfile in argv[1:]:
if commit_time < info.date_time:
commit_time = info.date_time
+ if common_prefix == None:
+ common_prefix = name[:name.rfind('/') + 1]
+ else:
+ while not name.startswith(common_prefix):
+ common_prefix = name[:name.rfind('/') + 1]
mark[name] = ':' + str(next_mark)
next_mark += 1
@@ -56,7 +61,8 @@ for zipfile in argv[1:]:
'', 'deleteall'))
for name in mark.keys():
- fast_import.write('M 100644 ' + mark[name] + ' ' + name + "\n")
+ fast_import.write('M 100644 ' + mark[name] + ' ' +
+ name[len(common_prefix):] + "\n")
printlines(('', 'tag ' + path.basename(zipfile), \
'from ' + branch_ref, 'tagger ' + committer, \
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Petr Baudis @ 2008-06-30 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian H??gsberg, git, akpm, Stephen Rothwell
In-Reply-To: <7vabh2vaav.fsf@gitster.siamese.dyndns.org>
On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote:
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't. If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).
Cogito is getting somewhat broken by removing of the git- plumbing from
$PATH anyway (you have to hack around it; and I'm not saying it's bad
thing).
But it is actually quite resilient against this kind of stuff (as it was
constructed to be able to run on very rudimental repositories dating
early to the dawn of time). All versions supporting .git/branches [*] will
autocreate the .git/branches directory if missing.
[*] .git/branches was actually called .git/remotes even earlier; yay,
how rich our history is. ;-)
> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from. This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here. It is not a
> big deal, but it still is a backward incompatible change.
Now, I think it would be nice to keep backward compatibility here. I'm
still _regularly_ running into people who still use Cogito (and it's not
because they know me :-)) and are only now doing the switch, or only
planning to yet.
(On the other hand, using Git on repositories created by old Git
versions or Cogito can be quite a confusing experience for non-expert
users - things related to remote repositories behave differently to what
the documentation describes, obviously. Maybe it _would_ be reasonable
option to do something radical when hitting old repository, like
"(Re-)clone me for non-confusing user experience, pretty please, or
git-config force_old_repo 1 if you know what are you doing.")
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andrew Morton @ 2008-06-30 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: krh, git, sfr, pasky
In-Reply-To: <7vabh2vaav.fsf@gitster.siamese.dyndns.org>
On Mon, 30 Jun 2008 15:15:52 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from. This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here. It is not a
> big deal, but it still is a backward incompatible change.
I do find the more compact format of .git/branches/git-foo to be
convenient. For example, my scripts go looking in there for the URL
and add that to the patch changelog so that people can reconstruct -mm's
git-foo.patch from the relevant git tree.
That being said,
- It wouldn't bother me to have to type `mkdir .git/branches' after
`git init'!
- It's bad to have the same info in two places, and to have to
support two different ways of doing the same thing for ever. So I
could understand a wish to remove .git/branches/ support completely.
I'll cope :)
For me the biggest part of migrating would be working out what on
earth the format of the new files is. Maybe it's documented
somewhere undiscoverable, dunno.
^ permalink raw reply
* Re: [PATCH 01/15] Move split_cmdline() to alias.c
From: Olivier Marin @ 2008-06-30 22:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0806291542070.9925@racer>
Johannes Schindelin a écrit :
>
> I am generally not a fan of crossing bridges miles before you reach them.
>
OK, as you want. :-) I don't really care about this patch, anyway.
Olivier.
^ permalink raw reply
* [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Adam Brewster @ 2008-06-30 22:49 UTC (permalink / raw)
To: git; +Cc: Adam Brewster, Jakub Narebski
In-Reply-To: <1214272713-7808-1-git-send-email-adambrewster@gmail.com>
Git-basis is a perl script that remembers bases for use by git-bundle.
Code from rev-parse was borrowed to allow git-bundle to handle --stdin.
Signed-off-by: Adam Brewster <adambrewster@gmail.com>
---
As promised, here's another patch with documentation. The code is
identical to the previous version.
I know this is a minor patch, but I think the result is a more usable
git-bundle feature, and I'd like to see it included in future releases
if there are no objections.
Documentation/git-basis.txt | 82 +++++++++++++++++++++++++++++++++++++++++++
bundle.c | 22 ++++++++++-
git-basis | 71 +++++++++++++++++++++++++++++++++++++
3 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/git-basis.txt
create mode 100755 git-basis
diff --git a/Documentation/git-basis.txt b/Documentation/git-basis.txt
new file mode 100644
index 0000000..3624890
--- /dev/null
+++ b/Documentation/git-basis.txt
@@ -0,0 +1,82 @@
+git-basis(1)
+============
+
+NAME
+----
+git-basis - Track sets of references available on remote systems (bases)
+
+SYNOPSIS
+--------
+[verse]
+'git-basis' <basis> [<basis>...]
+'git-basis' --update <basis> [<basis>...] < <object list or bundle>
+
+DESCRIPTION
+-----------
+Maintains lists of objects that are known to be accessible on remote
+computer systems that are not accessible by network.
+
+OPTIONS
+-------
+
+basis::
+ List of bases to operate on. Any valid filename can be
+ the name of a basis. Bases that do not exist are taken
+ to be empty.
+
+--update::
+ Tells git-basis to read a list of objects from stdin and
+ add them to each of the given bases. git-basis produces
+ no output when this option is given. Bases will be created
+ if necessary.
+
+object list or bundle::
+ Git-basis --update reads object names, one per line from stdin.
+ Leading caret ("^") characters are ignored, as is anything
+ after the object name. Lines that don't begin with an object
+ name are ignored. The output of linkgit:git-ls-remote[1] or a
+ bundle created by linkgit:git-bundle[1] are both suitable input.
+
+DISCUSSION
+----------
+git-basis is probably only useful with linkgit:git-bundle[1].
+
+To create a bundle that excludes all objects that are part of my-basis,
+use
+
+git-basis my-basis | git-bundle create my-bundle --all --stdin
+
+To add the objects in my-bundle to my-basis, use
+
+git-basis --update my-basis < my-bundle
+
+DETAILS
+-------
+Bases are stored as plain text files under .git/bases/. One object
+entry per line.
+
+git-basis without --update reads all of the basis names given on the
+command line, and outputs the intersection of them to stdout, with each
+object prefixed by "^".
+
+git-basis --update reads object names from stdin, and adds all of the
+references to each of the bases listed. Duplicate references will not
+be listed twice, but otherwise redundant information will be included.
+
+BUGS
+----
+Likely.
+
+Bug reports are welcome, and patches are encouraged.
+
+SEE ALSO
+--------
+linkgit:git-bundle[1]
+
+AUTHOR
+------
+Written by Adam Brewster <asb@bu.edu>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/bundle.c b/bundle.c
index 0ba5df1..0af12d7 100644
--- a/bundle.c
+++ b/bundle.c
@@ -227,8 +227,26 @@ int create_bundle(struct bundle_header *header,
const char *path,
/* write references */
argc = setup_revisions(argc, argv, &revs, NULL);
- if (argc > 1)
- return error("unrecognized argument: %s'", argv[1]);
+
+ for (i = 1; i < argc; i++) {
+ if ( !strcmp(argv[i], "--stdin") ) {
+ char line[1000];
+ while (fgets(line, sizeof(line),
stdin) != NULL) {
+ int len = strlen(line);
+ if (len && line[len - 1] == '\n')
+ line[--len] = 0;
+ if (!len)
+ break;
+ if (line[0] == '-')
+ die("options not supported in
--stdin mode");
+ if (handle_revision_arg(line, &revs, 0, 1))
+ die("bad revision '%s'", line);
+ }
+ continue;
+ }
+
+ return error("unrecognized argument: %s'", argv[i]);
+ }
for (i = 0; i < revs.pending.nr; i++) {
struct object_array_entry *e = revs.pending.objects + i;
diff --git a/git-basis b/git-basis
new file mode 100755
index 0000000..891635c
--- /dev/null
+++ b/git-basis
@@ -0,0 +1,71 @@
+#!/usr/bin/perl
+
+use strict;
+
+use Git;
+
+my $r = Git->repository();
+my $d = $r->repo_path();
+
+if ( ! -d "$d/bases" ) {
+ system( "mkdir '$d/bases'" );
+}
+
+if ( $#ARGV == -1 ) {
+ print "usage: git-basis [--update] basis1...\n";
+ exit;
+} elsif ( $ARGV[0] eq '--update' ) {
+ shift @ARGV;
+
+ my %new = ();
+ while (<STDIN>) {
+ if (!/^^?([a-z0-9]{40})/) {next;}
+ $new{$1} = 1;
+ }
+
+ foreach my $f (@ARGV) {
+ my %these = ();
+ open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<F>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ $these{$1} = 1;
+ }
+ close F;
+ open F, ">>$d/bases/$f" || die "Can't open bases/$f: $!";
+ print F "\#" . `date`;
+ foreach my $b (keys %new) {
+ if (exists($these{$b})) {next;}
+ print F "$b\n";
+ }
+ close F;
+ }
+} else {
+ my $n = 0;
+ my %basis = ();
+
+ my $f = shift @ARGV;
+ open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<F>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ $basis{$1} = $n;
+ }
+ close F;
+
+ foreach $f (@ARGV) {
+ open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<F>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ if (!exists($basis{$1})) {next;}
+
+ if ($basis{$1} == $n) {$basis{$1}++;}
+ else {delete $basis{$1};}
+ }
+ close F;
+ $n++;
+ }
+
+ foreach my $b (keys %basis) {
+ if ( $basis{$b} != $n ) {next;}
+ print "^$b\n";
+ }
+}
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev
From: Junio C Hamano @ 2008-06-30 22:48 UTC (permalink / raw)
To: Christian Couder
Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git,
Linus Torvalds
In-Reply-To: <7v3amuv8yg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> Before this patch "git bisect" doesn't really work when it is given
>> some good revs that are siblings of the bad rev.
>>
>> For example if there is the following history:
>>
>> A-B-C-D
>> \E-F
>>
>> and we launch "git bisect start D F" then only C and D will be
>> considered as possible first bad commit. This is wrong because A, B and
>> E may be bad too if the bug exists everywhere except in F that fixes it.
>
> Please don't.
>
> bisect is about finding a single regression by partitioning the graph into
> older good section and newer bad section with a *single* "first bad
> commit".
>
> Your "this could also be possible" scenario is already outside the
> realm. You are assuming A, B and F is good, and D is bad. But if E is
> bad, then that breakage cannot possibly affect the transition between B
> and D from good to bad (E cannot break D), so C must *also* be bad.
... which means you are dealing with *two* breakages. That's outside what
bisect deals with.
And this does not need to have forked development. If the graph were like
this:
A-B-C-D-E-F
and if F is bad and B is good, with your logic, after checking that D is
already bad, we cannot discount E --- after somehow fixing D, we _might_
also be introducing another breakage with E. You cannot even check for
that anyway, but the logic is the same.
^ permalink raw reply
* Re: [PATCH 13/13] Build in merge
From: Miklos Vajna @ 2008-06-30 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7vlk0n4h0a.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]
On Sun, Jun 29, 2008 at 10:40:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Actually reset_hard does not return if an error occures:
>
> I know that; didn't I already say "Luckily no"? The point was it was not
> apparent from the above 6 lines alone.
Ah, OK.
>
> >> > + for (i = 0; i < use_strategies.nr; i++) {
> >> > + if ((unsigned int)use_strategies.items[i].util &
> >> > + NO_FAST_FORWARD)
> >> > + allow_fast_forward = 0;
> >> > + if ((unsigned int)use_strategies.items[i].util & NO_TRIVIAL)
> >> > + allow_trivial = 0;
> >>
> >> Can we abstract out these ugly casts? Any code that use path_list to
> >> store anything but list of paths (i.e. some value keyed with string) tends
> >> to have this readability issue.
> >
> > If you don't cast, you can't use the & operator. If I change the
> > path_list_item's util to be an unsigned number then I break fast-export.
> > I think if we _really_ want to get rid of those casts, we could have
> > something like:
>
> No, no, no. That is not what I meant.
>
> The places that use use_strategies in your code knows too much about the
> internal implementation detail of path_list, while path_list pretends to
> be a general purpose "table keyed with string" facility. The fact is that
> the table is not a very useful general purpose abstraction unless you are
> pointing at some structures that exist regardless of your use of path_list
> (e.g. you have some "struct object" and you hold pointers in a path_list).
> It does not work very well as an abstraction for use case like yours.
>
> With something like:
>
> static inline unsigned nth_strategy_flags(struct path_list *s, int nth)
> {
> return (unsigned) s->items[nth].util;
> }
>
> the checks would be more like:
>
> if (nth_strategy_flags(&use_strategies, i) & NO_FAST_FORWARD)
> ...
>
> or even:
>
> static inline check_nth_strategy_flags(struct path_list_item *i, unsigned flags)
> {
> return !((unsigned) i->util & flags);
> }
>
> if (check_nth_strategy_flags(&use_strategies,items[i], NO_FAST_FORWARD)
> ...
>
> either of which would be much easier on the eye.
Probably this is subjective, but I think the previous form is easier to
read, so I choose that one.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev
From: Junio C Hamano @ 2008-06-30 22:44 UTC (permalink / raw)
To: Christian Couder
Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git,
Linus Torvalds
In-Reply-To: <20080701004211.ba9b89c9.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Before this patch "git bisect" doesn't really work when it is given
> some good revs that are siblings of the bad rev.
>
> For example if there is the following history:
>
> A-B-C-D
> \E-F
>
> and we launch "git bisect start D F" then only C and D will be
> considered as possible first bad commit. This is wrong because A, B and
> E may be bad too if the bug exists everywhere except in F that fixes it.
Please don't.
bisect is about finding a single regression by partitioning the graph into
older good section and newer bad section with a *single* "first bad
commit".
For your "this could also be possible" scenario is already outside the
realm. You are assuming A, B and F is good, and D is bad. But if E is
bad, then that breakage cannot possibly affect the transition between B
and D from good to bad (E cannot break D), so C must *also* be bad.
^ permalink raw reply
* Re: [PATCH 13/13] Build in merge
From: Olivier Marin @ 2008-06-30 22:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <e8d1385cc49a06ca3fae28231ebc66a333ce4ffb.1214789764.git.vmiklos@frugalware.org>
Miklos Vajna a écrit :
>
> +static void finish(const unsigned char *new_head, const char *msg)
> +{
[...]
> + if (new_head && show_diffstat) {
> + struct diff_options opts;
> + diff_setup(&opts);
> + opts.output_format |=
> + DIFF_FORMAT_SUMMARY | DIFF_FORMAT_DIFFSTAT;
> + opts.detect_rename = DIFF_DETECT_RENAME;
> + if (diff_use_color_default > 0)
> + DIFF_OPT_SET(&opts, COLOR_DIFF);
Ah, I missed that. You should call diff_setup_done(), to finish diff_setup()
and have a recursive diffstat.
For example:
$ git checkout -b test c0f5c69
$ git merge 2dce956
Updating c0f5c69..2dce956
Fast forward
help.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
is wrong. Correct diffstat is:
$ git diff --stat c0f5c69..2dce956
Documentation/gitcli.txt | 37 +++++++++++++++++++++++++++++++++----
Documentation/gittutorial-2.txt | 10 +++++-----
help.c | 22 ++++++++++++++--------
t/test-lib.sh | 2 +-
4 files changed, 53 insertions(+), 18 deletions(-)
> + diff_tree_sha1(head, new_head, "", &opts);
> + diffcore_std(&opts);
> + diff_flush(&opts);
> + }
[...]
> +int cmd_merge(int argc, const char **argv, const char *prefix)
> +{
[...]
> + git_config(git_merge_config, NULL);
> +
> + /* for color.diff and diff.color */
> + git_config(git_diff_ui_config, NULL);
Also, what about doing "return git_diff_ui_config(k, v, cb)" at the end of
git_merge_config() instead, to avoid parsing config files twice.
> +
> + /* for color.ui */
> + if (diff_use_color_default == -1)
> + diff_use_color_default = git_use_color_default;
> +
Olivier.
^ permalink raw reply
* [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev
From: Christian Couder @ 2008-06-30 22:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git,
Linus Torvalds
Before this patch "git bisect" doesn't really work when it is given
some good revs that are siblings of the bad rev.
For example if there is the following history:
A-B-C-D
\E-F
and we launch "git bisect start D F" then only C and D will be
considered as possible first bad commit. This is wrong because A, B and
E may be bad too if the bug exists everywhere except in F that fixes it.
Maybe there is a way to make the above work, but for now the purpose of
this patch is to fix the problem by checking that all good revs are
ancestor of the bad rev and by erroring out if this is not the case.
To do that we run "git rev-list ^bad good" and we check that it outputs
nothing.
This check will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars". The downside of that is
that now we can't tell between a mistake and a "siblings" case.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 32 +++++++++++++++-----------------
t/t6030-bisect-porcelain.sh | 19 +++++++++++++++++++
2 files changed, 34 insertions(+), 17 deletions(-)
Maybe we can improve on this patch by trying to tell between
a mistake and a "siblings" case to give a better error
message.
diff --git a/git-bisect.sh b/git-bisect.sh
index 991b2ef..90a9d74 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -242,33 +242,18 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
-eval_rev_list() {
- _eval="$1"
-
- eval $_eval
- res=$?
-
- if [ $res -ne 0 ]; then
- echo >&2 "'git rev-list --bisect-vars' failed:"
- echo >&2 "maybe you mistake good and bad revs?"
- exit $res
- fi
-
- return $res
-}
-
filter_skipped() {
_eval="$1"
_skip="$2"
if [ -z "$_skip" ]; then
- eval_rev_list "$_eval"
+ eval "$_eval"
return
fi
# Let's parse the output of:
# "git rev-list --bisect-vars --bisect-all ..."
- eval_rev_list "$_eval" | while read hash line
+ eval "$_eval" | while read hash line
do
case "$VARS,$FOUND,$TRIED,$hash" in
# We display some vars.
@@ -331,6 +316,18 @@ exit_if_skipped_commits () {
fi
}
+check_good_are_ancestor_of_bad() {
+ _bad="^$1"
+ _good=$(echo $2 | sed -e 's/\^//g')
+ _side=$(git rev-list $_good $_bad)
+ if test -n "$_side"; then
+ echo >&2 "Some good revs are not ancestor of the bad rev."
+ echo >&2 "git bisect cannot work properly in this case."
+ echo >&2 "Maybe you mistake good and bad revs?"
+ return 1
+ fi
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
@@ -345,6 +342,7 @@ bisect_next() {
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '\012' ' ') &&
+ check_good_are_ancestor_of_bad "$bad" "$good" &&
eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..b3f3869 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -350,6 +350,25 @@ test_expect_success 'bisect does not create a "bisect" branch' '
git branch -D bisect
'
+# This creates a "side" branch to test "siblings" cases.
+test_expect_success 'bisect errors out when good and bad are siblings' '
+ git bisect reset &&
+ git checkout -b side $HASH4 &&
+ add_line_into_file "5(side): first line on a side branch" hello &&
+ SIDE_HASH5=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "6(side): second line on a side branch" hello &&
+ SIDE_HASH6=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "7(side): third line on a side branch" hello &&
+ SIDE_HASH7=$(git rev-parse --verify HEAD) &&
+ test_must_fail git bisect start "$HASH7" "$SIDE_HASH7" &&
+ test_must_fail git bisect start "$SIDE_HASH7" "$HASH7" &&
+ test_must_fail git bisect start "$HASH7" HEAD &&
+ test_must_fail git bisect start "$SIDE_HASH5" "$HASH7" &&
+ test_must_fail test -e .git/BISECT_START &&
+ test -z "$(git for-each-ref "refs/bisect/*")" &&
+ test "$(git rev-parse --verify HEAD)" = "$SIDE_HASH7"
+'
+
#
#
test_done
--
1.5.6.7.g5b8fa.dirty
^ permalink raw reply related
* [RFC/PATCH 7/7] Documentation formatting and cleanup
From: Jonathan Nieder @ 2008-06-30 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
[184 KB patch online at
<http://home.uchicago.edu/~jrnieder/20080701-git-doc-style.txt>]
Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.
While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
1) I am using `teletype text` both for command names and
for command lines. Probably I should be using italics
for the command names.
2) Should these changes be split up more?
Documentation/git-annotate.txt | 2 +-
Documentation/git-apply.txt | 12 ++--
Documentation/git-archimport.txt | 6 +-
Documentation/git-archive.txt | 6 +-
Documentation/git-bisect.txt | 8 +-
Documentation/git-blame.txt | 4 +-
Documentation/git-branch.txt | 8 +-
Documentation/git-bundle.txt | 27 +++---
Documentation/git-check-ref-format.txt | 2 +-
Documentation/git-checkout-index.txt | 2 +-
Documentation/git-checkout.txt | 4 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-cherry.txt | 8 +-
Documentation/git-citool.txt | 4 +-
Documentation/git-clean.txt | 4 +-
Documentation/git-clone.txt | 12 ++--
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 20 +++---
Documentation/git-config.txt | 12 ++--
Documentation/git-cvsexportcommit.txt | 7 +-
Documentation/git-cvsimport.txt | 18 ++--
Documentation/git-cvsserver.txt | 43 +++++-----
Documentation/git-daemon.txt | 22 +++---
Documentation/git-describe.txt | 8 +-
Documentation/git-diff-files.txt | 2 +-
Documentation/git-diff-index.txt | 26 +++---
Documentation/git-diff-tree.txt | 10 +-
Documentation/git-fast-export.txt | 8 +-
Documentation/git-fast-import.txt | 16 ++--
Documentation/git-fetch-pack.txt | 16 ++--
Documentation/git-fetch.txt | 2 +-
Documentation/git-filter-branch.txt | 12 ++--
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-format-patch.txt | 4 +-
Documentation/git-fsck.txt | 6 +-
Documentation/git-gc.txt | 10 +-
Documentation/git-get-tar-commit-id.txt | 6 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-gui.txt | 24 +++---
Documentation/git-hash-object.txt | 2 +-
Documentation/git-help.txt | 6 +-
Documentation/git-http-fetch.txt | 2 +-
Documentation/git-imap-send.txt | 2 +-
Documentation/git-index-pack.txt | 8 +-
Documentation/git-instaweb.txt | 4 +-
Documentation/git-log.txt | 4 +-
Documentation/git-ls-files.txt | 8 +-
Documentation/git-ls-remote.txt | 2 +-
Documentation/git-mailinfo.txt | 4 +-
Documentation/git-merge-base.txt | 8 +-
Documentation/git-merge-file.txt | 10 +-
Documentation/git-merge-index.txt | 14 ++--
Documentation/git-merge-one-file.txt | 4 +-
Documentation/git-merge.txt | 14 ++--
Documentation/git-mergetool.txt | 2 +-
Documentation/git-name-rev.txt | 6 +-
Documentation/git-pack-objects.txt | 8 +-
Documentation/git-pack-redundant.txt | 4 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/git-peek-remote.txt | 4 +-
Documentation/git-prune.txt | 10 +-
Documentation/git-pull.txt | 3 +-
Documentation/git-push.txt | 2 +-
Documentation/git-read-tree.txt | 14 ++--
Documentation/git-rebase.txt | 22 +++---
Documentation/git-receive-pack.txt | 16 ++--
Documentation/git-repack.txt | 11 ++-
Documentation/git-rerere.txt | 10 +-
Documentation/git-reset.txt | 2 +-
Documentation/git-rev-list.txt | 6 +-
Documentation/git-rev-parse.txt | 12 ++--
Documentation/git-rm.txt | 2 +-
Documentation/git-send-pack.txt | 14 ++--
Documentation/git-shell.txt | 2 +-
Documentation/git-shortlog.txt | 2 +-
Documentation/git-show-branch.txt | 4 +-
Documentation/git-show-index.txt | 4 +-
Documentation/git-show-ref.txt | 4 +-
Documentation/git-show.txt | 6 +-
Documentation/git-stash.txt | 12 ++--
Documentation/git-submodule.txt | 4 +-
Documentation/git-svn.txt | 133 +++++++++++++++----------------
Documentation/git-symbolic-ref.txt | 2 +-
Documentation/git-tag.txt | 8 +-
Documentation/git-tar-tree.txt | 4 +-
Documentation/git-unpack-objects.txt | 2 +-
Documentation/git-update-index.txt | 14 ++--
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 6 +-
Documentation/git-verify-pack.txt | 4 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 6 +-
Documentation/git-whatchanged.txt | 4 +-
Documentation/git.txt | 10 +-
Documentation/gitattributes.txt | 12 ++--
Documentation/gitcore-tutorial.txt | 18 ++--
Documentation/gitcvs-migration.txt | 4 +-
Documentation/gitdiffcore.txt | 34 ++++----
Documentation/gitignore.txt | 4 +-
Documentation/gitk.txt | 3 +-
Documentation/gitrepository-layout.txt | 2 +-
Documentation/gittutorial-2.txt | 28 +++---
Documentation/gittutorial.txt | 46 ++++++------
103 files changed, 510 insertions(+), 509 deletions(-)
See <http://home.uchicago.edu/~jrnieder/20080701-git-doc-style.txt>.
^ permalink raw reply
* [PATCH 6/7] Documentation: be consistent about "git-" versus "git "
From: Jonathan Nieder @ 2008-06-30 22:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.GSO.4.62.0806301716150.7190@harper.uchicago.edu>
[Patch at <http://home.uchicago.edu/~jrnieder/20080701-git-doc-hyphens.txt>]
Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Documentation/git-add.txt | 2 +-
Documentation/git-am.txt | 4 +-
Documentation/git-annotate.txt | 2 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 2 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-bisect.txt | 2 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-branch.txt | 8 +-
Documentation/git-bundle.txt | 14 ++--
Documentation/git-cat-file.txt | 4 +-
Documentation/git-check-attr.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout-index.txt | 20 +++---
Documentation/git-checkout.txt | 8 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-cherry.txt | 2 +-
Documentation/git-clean.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 4 +-
Documentation/git-config.txt | 26 ++++----
Documentation/git-count-objects.txt | 4 +-
Documentation/git-cvsexportcommit.txt | 8 +-
Documentation/git-cvsimport.txt | 4 +-
Documentation/git-cvsserver.txt | 2 +-
Documentation/git-daemon.txt | 2 +-
Documentation/git-describe.txt | 10 ++--
Documentation/git-diff-files.txt | 2 +-
Documentation/git-diff-index.txt | 12 ++--
Documentation/git-diff-tree.txt | 8 +-
Documentation/git-diff.txt | 18 +++---
Documentation/git-fast-export.txt | 2 +-
Documentation/git-fast-import.txt | 8 +-
Documentation/git-fetch-pack.txt | 2 +-
Documentation/git-fetch.txt | 4 +-
Documentation/git-filter-branch.txt | 4 +-
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-for-each-ref.txt | 8 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-fsck-objects.txt | 2 +-
Documentation/git-fsck.txt | 4 +-
Documentation/git-gc.txt | 6 +-
Documentation/git-get-tar-commit-id.txt | 2 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-http-fetch.txt | 2 +-
Documentation/git-http-push.txt | 2 +-
Documentation/git-imap-send.txt | 4 +-
Documentation/git-index-pack.txt | 4 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 6 +-
Documentation/git-instaweb.txt | 4 +-
Documentation/git-log.txt | 2 +-
Documentation/git-lost-found.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-ls-remote.txt | 2 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/git-mailinfo.txt | 4 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge-base.txt | 4 +-
Documentation/git-merge-file.txt | 4 +-
Documentation/git-merge-index.txt | 6 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-merge.txt | 10 ++--
Documentation/git-mergetool.txt | 16 +++---
Documentation/git-mktag.txt | 2 +-
Documentation/git-mktree.txt | 2 +-
Documentation/git-mv.txt | 6 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-pack-objects.txt | 2 +-
Documentation/git-pack-redundant.txt | 6 +-
Documentation/git-pack-refs.txt | 4 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/git-peek-remote.txt | 2 +-
Documentation/git-prune-packed.txt | 2 +-
Documentation/git-prune.txt | 4 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-quiltimport.txt | 2 +-
Documentation/git-read-tree.txt | 32 +++++-----
Documentation/git-rebase.txt | 20 +++---
Documentation/git-receive-pack.txt | 10 ++--
Documentation/git-relink.txt | 2 +-
Documentation/git-remote.txt | 12 ++--
Documentation/git-repack.txt | 10 ++--
Documentation/git-repo-config.txt | 2 +-
Documentation/git-request-pull.txt | 2 +-
Documentation/git-rerere.txt | 4 +-
Documentation/git-rev-list.txt | 10 ++--
Documentation/git-rev-parse.txt | 6 +-
Documentation/git-revert.txt | 2 +-
Documentation/git-rm.txt | 8 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 2 +-
Documentation/git-shortlog.txt | 6 +-
Documentation/git-show-branch.txt | 4 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-show-ref.txt | 6 +-
Documentation/git-show.txt | 2 +-
Documentation/git-stash.txt | 12 ++--
Documentation/git-status.txt | 6 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 10 ++--
Documentation/git-svn.txt | 34 +++++-----
Documentation/git-symbolic-ref.txt | 2 +-
Documentation/git-tag.txt | 14 ++--
Documentation/git-tar-tree.txt | 2 +-
Documentation/git-unpack-file.txt | 2 +-
Documentation/git-unpack-objects.txt | 2 +-
Documentation/git-update-index.txt | 12 ++--
Documentation/git-update-ref.txt | 10 ++--
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 4 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 6 +-
Documentation/git-whatchanged.txt | 6 +-
Documentation/git-write-tree.txt | 2 +-
Documentation/gitattributes.txt | 14 ++--
Documentation/gitcore-tutorial.txt | 102 +++++++++++++++---------------
Documentation/gitcvs-migration.txt | 8 +-
Documentation/gitdiffcore.txt | 2 +-
Documentation/githooks.txt | 10 ++--
Documentation/gitignore.txt | 4 +-
Documentation/gitrepository-layout.txt | 18 +++---
Documentation/gittutorial-2.txt | 18 +++---
Documentation/gittutorial.txt | 30 +++++-----
Documentation/user-manual.txt | 76 +++++++++++-----------
131 files changed, 462 insertions(+), 462 deletions(-)
Because it is long, I haven't sent the patch. You can find it at
<http://home.uchicago.edu/~jrnieder/20080701-git-doc-hyphens.txt>.
^ permalink raw reply
* [PATCH 5/7] Documentation: prepare to be consistent about "git-" versus "git "
From: Jonathan Nieder @ 2008-06-30 22:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
With the dashed forms of git commands not in $(bindir), we have
to change many instances of "git-command" to "git command". Also,
for consistency it is at times appropriate to make the opposite
change. In some cases, the change is not so simple as changing one
character.
This patch gets rid of some of those cases by rewrapping lines.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-mailinfo.txt | 4 ++--
Documentation/git-tag.txt | 4 ++--
Documentation/gitrepository-layout.txt | 8 ++++----
Documentation/gittutorial.txt | 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 183dc1d..6a73b73 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -29,8 +29,8 @@ OPTIONS
among which (1) remove 'Re:' or 're:', (2) leading
whitespaces, (3) '[' up to ']', typically '[PATCH]', and
then prepends "[PATCH] ". This flag forbids this
- munging, and is most useful when used to read back 'git
- format-patch -k' output.
+ munging, and is most useful when used to read back
+ 'git format-patch -k' output.
-u::
The commit log message, author name and author email are
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 8f40f4b..0c41711 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -122,8 +122,8 @@ others have already seen the old one. So just use "git tag -f"
again, as if you hadn't already published the old one.
However, Git does *not* (and it should not) change tags behind
-users back. So if somebody already got the old tag, doing a "git
-pull" on your tree shouldn't just make them overwrite the old
+users back. So if somebody already got the old tag, doing a
+"git pull" on your tree shouldn't just make them overwrite the old
one.
If somebody got a release tag from you, you cannot just change
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index b75508a..2afc5a3 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -167,14 +167,14 @@ info/grafts::
info/exclude::
This file, by convention among Porcelains, stores the
exclude pattern list. `.gitignore` is the per-directory
- ignore file. `git status`, `git add`, `git rm` and `git
- clean` look at it but the core git commands do not look
+ ignore file. `git status`, `git add`, `git rm` and
+ `git clean` look at it but the core git commands do not look
at it. See also: linkgit:gitignore[5].
remotes::
Stores shorthands to be used to give URL and default
- refnames to interact with remote repository to `git
- fetch`, `git pull` and `git push` commands.
+ refnames to interact with remote repository to
+ `git fetch`, `git pull` and `git push` commands.
logs::
Records of changes made to refs are stored in this
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index b833167..144bacd 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -19,8 +19,8 @@ If you are instead primarily interested in using git to fetch a project,
for example, to test the latest version, you may prefer to start with
the first two chapters of link:user-manual.html[The Git User's Manual].
-First, note that you can get documentation for a command such as "git
-log --graph" with:
+First, note that you can get documentation for a command such as
+"git log --graph" with:
------------------------------------------------
$ man git-log
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 4/7] git-daemon(1): don't assume git-daemon is in /usr/bin
From: Jonathan Nieder @ 2008-06-30 22:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
In the example inetd.conf lines in git-daemon(1), it was
assumed that `git-daemon` resides in the user's /usr/bin.
With this patch, we only assume `git` is in /usr/bin.
The stronger assumption fails in the default installation
nowadays.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-daemon.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 344f24e..b71eb94 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -206,8 +206,8 @@ git-daemon as inetd server::
/etc/inetd all on one line:
+
------------------------------------------------
- git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose --export-all
+ git stream tcp nowait nobody /usr/bin/git
+ git daemon --inetd --verbose --export-all
/pub/foo /pub/bar
------------------------------------------------
@@ -219,8 +219,8 @@ git-daemon as inetd server for virtual hosts::
`/etc/inetd` all on one line:
+
------------------------------------------------
- git stream tcp nowait nobody /usr/bin/git-daemon
- git-daemon --inetd --verbose --export-all
+ git stream tcp nowait nobody /usr/bin/git
+ git daemon --inetd --verbose --export-all
--interpolated-path=/pub/%H%D
/pub/www.example.org/software
/pub/www.example.com/software
@@ -241,7 +241,7 @@ git-daemon as regular daemon for virtual hosts::
their IP addresses, start the daemon like this:
+
------------------------------------------------
- git-daemon --verbose --export-all
+ git daemon --verbose --export-all
--interpolated-path=/pub/%IP/%D
/pub/192.168.1.200/software
/pub/10.10.220.23/software
--
1.5.5.GIT
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, akpm, Stephen Rothwell, pasky
In-Reply-To: <1214834970.3382.4.camel@gaara.bos.redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> ...
>> It already is beginning to become clear what 1.6.0 will look like. What's
>> already in 'next' all are well intentioned (I do not guarantee they are
>> already bug-free --- that is what cooking them in 'next' is for) and are
>> good set of feature enhancements. Bigger changes will be:
> ...
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory. How does that
> sound?
What's the benefit of the removal that outweighs the downside? I can
imagine two contradicting voices from new end users.
(1) With current git, I ran "git init" and I have an empty
.git/branches/, but my remote information created with "git clone"
and "git remote add" all go to .git/config these days. Why do I have
to have this empty directory that I do not use?
(2) It is documented that "git fetch" can use files in .git/branches/ as
the source specification, but when I ran "git init", it does not
create the directory with Kristian's git. I need to do an extra
"mkdir .git/branches/" myself. Why?
You are obviously coming from the former camp, but do you have a good
answer to people from the other camp?
I do not recall if Cogito required to have .git/branches created by us or
it can create it on demand if we don't. If the latter, that would be
great, otherwise remaining users would be in the latter camp as well, and
we may have to make sure Cogito is really dead already (or wait for it to
die), or Cogito gets updated for its remaining users to tolerate the
initial lack of the directory (and wait for that version percolates down
to the users).
Some people rely on (or at least "like") the convenience of being able to
create a single-liner file in .git/branches/ to easily add, and remove
such a file to easily remove where they integrate from. This is
especially so when they have dozens of source repositories to fetch from.
I do not think we want to remove support for .git/branches as a way to
specify fetch sources (this is why I am CC'ing Andrew who I know uses
branches, and Stephen who is also a heavy integrator even though I do not
know if he is in branches camp or uses more modern style), but they now
have to do an extra "mkdir .git/branches" after "git init" to continue
their workflow if we adopt the change you are proposing here. It is not a
big deal, but it still is a backward incompatible change.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Kristian Høgsberg, git
In-Reply-To: <m3myl2hq45.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Kristian Høgsberg <krh@redhat.com> writes:
>
>>
>> A small detail I've suggested scheduling for 1.6 before is removing (or
>> rather, stop creating) the empty .git/branches directory. How does that
>> sound?
>
> Perhaps also stop creating .git/description (remove
> 'templates/this--description' file), now that it is mentioned in
> gitweb/README and/or gitweb/INSTALL?
>
> (Do you want a patch?)
Not yet. I would first like to see a justification that makes sense.
I do not see much connection between your mentioning the file in README
and the file's removal. You currently say "By default it is set to ..."
and you would have to change it to "By default it does not exist so you
have to create one". Does it have much difference? Either way the user
needs to open the file with the editor and edit it, and the current file
at least says "Please edit me". I am not sure if removal is an
improvement.
The sample templates/hooks--update.sample seems to check if the contents
of the description file makes sense, without even checking if it exists.
That also needs to be updated.
Actually, the sample hook should be updated independent of this issue.
I'd suggest to simply remove the check from the sample hook. Setting
description and installing the hook is part of the initial public
repository deployment task, and once the description is set, the hook does
not have to check it over and over again. Allowing arrival of new commits
while the description is not set won't hurt anything (somebody would
notice and tell "please set a better description" to the repository owner,
and doing so at that point will fix things without anybody having to redo
any old pushes), and forbidding push from the hook for lack of description
does not make any sense.
^ permalink raw reply
* [PATCH 3/7] Documentation: complicate example of "man git-command"
From: Jonathan Nieder @ 2008-06-30 22:10 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger, J. Bruce Fields
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
The manual page for the command invoked as "git clone" is named
git-clone(1), and similarly for the rest of the git commands.
Make sure our first example of this in tutorials makes it clear
that it is the first two words of a command line that make up the
command's name (that is: for example, the effect of "git svn
dcommit" is described in git-svn(1)).
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
If I didn't make this change, consistency would mean
saying "you can get documentation for a command such
as `git-diff` with `man git-diff`", which might not be
very enlightening.
Documentation/gittutorial.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 3d16e3d..b833167 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -20,10 +20,10 @@ for example, to test the latest version, you may prefer to start with
the first two chapters of link:user-manual.html[The Git User's Manual].
First, note that you can get documentation for a command such as "git
-diff" with:
+log --graph" with:
------------------------------------------------
-$ man git-diff
+$ man git-log
------------------------------------------------
It is a good idea to introduce yourself to git with your name and
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ca4363f..36ab372 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -18,7 +18,7 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone", just use
+pages. For a command such as "git clone <repo>", just use
------------------------------------------------
$ man git-clone
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 2/7] whitespace fix in Documentation/git-repack.txt
From: Jonathan Nieder @ 2008-06-30 22:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
Change leading spaces to tabs to match the rest of the file.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-repack.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 04d6f1f..9011d06 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -55,15 +55,15 @@ OPTIONS
Also runs linkgit:git-prune-packed[1].
-l::
- Pass the `--local` option to `git pack-objects`, see
+ Pass the `--local` option to `git pack-objects`, see
linkgit:git-pack-objects[1].
-f::
- Pass the `--no-reuse-delta` option to `git pack-objects`, see
+ Pass the `--no-reuse-delta` option to `git pack-objects`, see
linkgit:git-pack-objects[1].
-q::
- Pass the `-q` option to `git pack-objects`, see
+ Pass the `-q` option to `git pack-objects`, see
linkgit:git-pack-objects[1].
-n::
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 1/7] Documentation: fix links to tutorials and other new manual pages
From: Jonathan Nieder @ 2008-06-30 22:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0806301650530.7190@harper.uchicago.edu>
With the conversion of HTML documentation to man pages
tutorial.html -> gittutorial (7)
tutorial-2.html -> gittutorial-2 (7)
cvs-migration.html -> gitcvs-migration (7)
diffcore.html -> gitdiffcore (7)
repository-layout.html -> gitrepository-layout (5)
hooks.html -> githooks (5)
glossary.html -> gitglossary (7)
core-tutorial.html -> gitcore-tutorial (7)
and the automatic update of references to these pages,
a little debris was left behind. We clear it away.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/diff-options.txt | 2 +-
Documentation/git-add.txt | 2 +-
Documentation/git-commit.txt | 4 ++--
Documentation/git-update-server-info.txt | 2 +-
Documentation/git.txt | 20 ++++++++++----------
Documentation/gitcore-tutorial.txt | 9 ++++-----
Documentation/gitcvs-migration.txt | 12 ++++++------
Documentation/gitrepository-layout.txt | 2 +-
Documentation/gittutorial-2.txt | 12 +++++-------
Documentation/gittutorial.txt | 8 ++++----
Documentation/user-manual.txt | 7 +++----
11 files changed, 38 insertions(+), 42 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 5721548..cba90fd 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -241,4 +241,4 @@ endif::git-format-patch[]
Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
-linkgit:gitdiffcore[7][diffcore documentation].
+linkgit:gitdiffcore[7].
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index b8e3fa6..2b0ccb3 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,7 +107,7 @@ Configuration
The optional configuration variable 'core.excludesfile' indicates a path to a
file containing patterns of file names to exclude from git-add, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
-those in info/exclude. See linkgit:gitrepository-layout[5][repository layout].
+those in info/exclude. See linkgit:gitrepository-layout[5].
EXAMPLES
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d0fe192..656d4db 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -97,7 +97,7 @@ OPTIONS
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
- See also linkgit:githooks[5][hooks].
+ See also linkgit:githooks[5].
--allow-empty::
Usually recording a commit that has the exact same tree as its
@@ -316,7 +316,7 @@ order).
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
-and `post-commit` hooks. See linkgit:githooks[5][hooks] for more
+and `post-commit` hooks. See linkgit:githooks[5] for more
information.
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
index d21be41..0102410 100644
--- a/Documentation/git-update-server-info.txt
+++ b/Documentation/git-update-server-info.txt
@@ -31,7 +31,7 @@ OUTPUT
------
Currently the command updates the following files. Please see
-linkgit:gitrepository-layout[5][repository-layout] for description of
+linkgit:gitrepository-layout[5] for description of
what they are for:
* objects/info/packs
diff --git a/Documentation/git.txt b/Documentation/git.txt
index a791ce7..27eebfb 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -20,11 +20,11 @@ Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.
-See this linkgit:gittutorial[7][tutorial] to get started, then see
+See linkgit:gittutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of commands, and
"man git-commandname" for documentation of each command. CVS users may
-also want to read linkgit:gitcvs-migration[7][CVS migration]. See
-link:user-manual.html[Git User's Manual] for a more in-depth
+also want to read linkgit:gitcvs-migration[7]. See
+the link:user-manual.html[Git User's Manual] for a more in-depth
introduction.
The COMMAND is either a name of a Git command (see below) or an alias
@@ -182,13 +182,14 @@ See the references above to get started using git. The following is
probably more detail than necessary for a first-time user.
The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial] both provide
+user-manual] and linkgit:gitcore-tutorial[7] both provide
introductions to the underlying git architecture.
See also the link:howto-index.html[howto] documents for some useful
examples.
-The internals are documented link:technical/api-index.html[here].
+The internals are documented in the
+link:technical/api-index.html[GIT API documentation].
GIT COMMANDS
------------
@@ -372,10 +373,9 @@ For a more complete list of ways to spell object names, see
File/Directory Structure
------------------------
-Please see the linkgit:gitrepository-layout[5][repository layout]
-document.
+Please see the linkgit:gitrepository-layout[5] document.
-Read linkgit:githooks[5][hooks] for more details about each hook.
+Read linkgit:githooks[5] for more details about each hook.
Higher level SCMs may provide and manage additional information in the
`$GIT_DIR`.
@@ -383,7 +383,7 @@ Higher level SCMs may provide and manage additional information in the
Terminology
-----------
-Please see the linkgit:gitglossary[7][glossary] document.
+Please see linkgit:gitglossary[7].
Environment Variables
@@ -535,7 +535,7 @@ Discussion[[Discussion]]
More detail on the following is available from the
link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial].
+user-manual] and linkgit:gitcore-tutorial[7].
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index cb4ec40..6bb32a8 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git programs to set up and
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with linkgit:gittutorial[7][a tutorial introduction to git] or
-link:user-manual.html[the git user manual].
+to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
+link:user-manual.html[the GIT User Manual].
However, an understanding of these low-level tools can be helpful if
you want to understand git's internals.
@@ -108,8 +108,7 @@ references in these `refs` subdirectories when you actually start
populating your tree.
[NOTE]
-An advanced user may want to take a look at the
-linkgit:gitrepository-layout[5][repository layout] document
+An advanced user may want to take a look at linkgit:gitrepository-layout[5]
after finishing this tutorial.
You have now created your first git repository. Of course, since it's
@@ -1589,7 +1588,7 @@ suggested in the previous section may be new to you. You do not
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-See linkgit:gitcvs-migration[7][git for CVS users] for the details.
+See linkgit:gitcvs-migration[7] for the details.
Bundling your work together
---------------------------
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 1db3f52..d652658 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -18,9 +18,9 @@ important than any other. However, you can emulate the CVS model by
designating a single shared repository which people can synchronize with;
this document explains how to do that.
-Some basic familiarity with git is required. This
-linkgit:gittutorial[7][tutorial introduction to git] and the
-linkgit:gitglossary[7][git glossary] should be sufficient.
+Some basic familiarity with git is required. Having gone through
+linkgit:gittutorial[7] and
+linkgit:gitglossary[7] should be sufficient.
Developing against a shared repository
--------------------------------------
@@ -81,8 +81,8 @@ Setting Up a Shared Repository
------------------------------
We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-linkgit:gittutorial[7][tutorial]), or imported from an already existing CVS
+possibly created from scratch or from a tarball (see
+linkgit:gittutorial[7]), or imported from an already existing CVS
repository (see the next section).
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
@@ -148,7 +148,7 @@ Advanced Shared Repository Management
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See linkgit:githooks[5][Hooks used by git].
+repository to a mailing list. See linkgit:githooks[5].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 03c52ff..b75508a 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -135,7 +135,7 @@ hooks::
commands. A handful of sample hooks are installed when
`git init` is run, but all of them are disabled by
default. To enable, they need to be made executable.
- Read linkgit:githooks[5][hooks] for more details about
+ Read linkgit:githooks[5] for more details about
each hook.
index::
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 31e8a23..2c54670 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -12,8 +12,7 @@ git *
DESCRIPTION
-----------
-You should work through linkgit:gittutorial[7][A tutorial introduction to
-git] before reading this tutorial.
+You should work through linkgit:gittutorial[7] before reading this tutorial.
The goal of this tutorial is to introduce two fundamental pieces of
git's architecture--the object database and the index file--and to
@@ -390,7 +389,7 @@ in the index file is identical to the one in the working directory.
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See the linkgit:gitcore-tutorial[7][core tutorial] and the relevant man
+See linkgit:gitcore-tutorial[7] and the relevant man
pages for details.
What next?
@@ -399,20 +398,19 @@ What next?
At this point you should know everything necessary to read the man
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
-should be able to find any unknown jargon in the
-linkgit:gitglossary[7][Glossary].
+should be able to find any unknown jargon in linkgit:gitglossary[7].
The link:user-manual.html[Git User's Manual] provides a more
comprehensive introduction to git.
-The linkgit:gitcvs-migration[7][CVS migration] document explains how to
+linkgit:gitcvs-migration[7] explains how to
import a CVS repository into git, and shows how to use git in a
CVS-like way.
For some interesting examples of git use, see the
link:howto-index.html[howtos].
-For git developers, the linkgit:gitcore-tutorial[7][Core tutorial] goes
+For git developers, linkgit:gitcore-tutorial[7] goes
into detail on the lower-level git mechanisms involved in, for
example, creating a new commit.
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index d465aab..3d16e3d 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -392,7 +392,7 @@ see linkgit:git-pull[1] for details.
Git can also be used in a CVS-like mode, with a central repository
that various users push changes to; see linkgit:git-push[1] and
-linkgit:gitcvs-migration[7][git for CVS users].
+linkgit:gitcvs-migration[7].
Exploring history
-----------------
@@ -571,9 +571,9 @@ is based:
used to create commits, check out working directories, and
hold the various trees involved in a merge.
-linkgit:gittutorial-2[7][Part two of this tutorial] explains the object
+Part two of this tutorial explains the object
database, the index file, and a few other odds and ends that you'll
-need to make the most of git.
+need to make the most of git. You can find it at linkgit:gittutorial-2[7].
If you don't want to continue with that right away, a few other
digressions that may be interesting at this point are:
@@ -592,7 +592,7 @@ digressions that may be interesting at this point are:
* link:everyday.html[Everyday GIT with 20 Commands Or So]
- * linkgit:gitcvs-migration[7][git for CVS users].
+ * linkgit:gitcvs-migration[7]: Git for CVS users.
SEE ALSO
--------
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 64a820b..ca4363f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1879,8 +1879,7 @@ $ chmod a+x hooks/post-update
-------------------------------------------------
(For an explanation of the last two lines, see
-linkgit:git-update-server-info[1], and the documentation
-linkgit:githooks[5][Hooks used by git].)
+linkgit:git-update-server-info[1] and linkgit:githooks[5].)
Advertise the URL of proj.git. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
@@ -1992,7 +1991,7 @@ the right to push to the same repository. In that case, the correct
solution is to retry the push after first updating your work by either a
pull or a fetch followed by a rebase; see the
<<setting-up-a-shared-repository,next section>> and
-linkgit:gitcvs-migration[7][git for CVS users] for more.
+linkgit:gitcvs-migration[7] for more.
[[setting-up-a-shared-repository]]
Setting up a shared repository
@@ -2001,7 +2000,7 @@ Setting up a shared repository
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-linkgit:gitcvs-migration[7][git for CVS users] for instructions on how to
+linkgit:gitcvs-migration[7] for instructions on how to
set this up.
However, while there is nothing wrong with git's support for shared
--
1.5.5.GIT
^ permalink raw reply related
* Re: [PATCH v8] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Jakub Narebski @ 2008-06-30 22:01 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <48681EC8.8000606@gmail.com>
[back-to-list]
On Mon, 30 Jun 2008, Lea Wiemann wrote:
> [off-list]
[...]
> By the way, I found the supercat (spc) colorizer very helpful for the
> mechanize tests, since the output tends to be long and the lines wrap a
> lot. Here are my regexes:
>
> $ cat ~/.spcrc/spcrc-test_more
> # HTML COLOR NAME COL A N T STRING or REGULAR EXPRESSION
> #################### ### # # # #########################################
> Black blk r (.*)
> Green grn b r (^ok .*)
> Red red b r (^not ok)
> Yellow yel b r (^not ok .* # TODO.*)
> Green grn r (^ok .*\[auto\].*)
> Red red r (^not ok .*\[auto\].*)
> Yellow yel r (^not ok .*\[auto\].* # TODO.*)
> Black blk r ( - .*)
> Green grn r r (\* passed all .*)
> Red red r r (\* failed .*)
>
> Then you can just run
>
> ./t9503-gitweb-Mechanize.sh -v -l 2>&1 | spc -t test_more
>
> Hope it's useful!
Hmmm... it would be nice if 'test_external*' functions supported syntax
highlighting of command output if it follows TAP: Test Anything Protocol
http://www.perlfoundation.org/perl5/index.cgi?testing#tap_test_anything_protocol
in a manner similar to coloring native tests (using git_expect_success,
git_expect_failure etc.).
Test::More as far as I know produces TAP-compatibile output.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 0/7] Some superficial documentation changes
From: Jonathan Nieder @ 2008-06-30 21:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger
This patch series is an updated version of a patch I sent this morning.
The purpose of the patches is to make the absence of git- commands not
so jarring while reading the manual. It does this by holding fast to a
distinction between programs (like git-clone) and command lines (like
"git clone <repo>").
Issues:
- It is a huge patch touching most of the manpages, not made by any
automated process
- Sometimes it is not clear whether a mention of git-diff, say, is
referring to the `git-diff` program or the command line `git diff`
(without any options). So we guess.
- Most non-git man pages use 'italics' for the names of programs, but I
stuck to `teletype text` because that is what seems to be most common
in the Git docs. If people want to change this, I can send a separate
patch to that end.
- There are not enough cross-references (the "see also" sections are
too often absent).
But at least I was able to check that patch 6/7 (which redistributes the
dashes in the world) doesn't touch anything but spaces and hyphens.
Hopefully that should make this easier to review.
Enjoy...
Documentation: fix links to tutorials and other new manual pages
whitespace fix in Documentation/git-repack.txt
Documentation: complicate example of "man git-blah"
git-daemon(1): don't assume git-daemon in /usr/bin
Documentation: prepare to be consistent about "git-" versus "git "
Documentation: be consistent about "git-" versus "git "
Documentation formatting and cleanup
Documentation/diff-options.txt | 2 +-
Documentation/git-add.txt | 4 +-
Documentation/git-am.txt | 4 +-
Documentation/git-annotate.txt | 2 +-
Documentation/git-apply.txt | 14 ++--
Documentation/git-archimport.txt | 8 +-
Documentation/git-archive.txt | 8 +-
Documentation/git-bisect.txt | 8 +-
Documentation/git-blame.txt | 6 +-
Documentation/git-branch.txt | 16 ++--
Documentation/git-bundle.txt | 41 ++++----
Documentation/git-cat-file.txt | 4 +-
Documentation/git-check-attr.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout-index.txt | 22 ++--
Documentation/git-checkout.txt | 12 +-
Documentation/git-cherry-pick.txt | 4 +-
Documentation/git-cherry.txt | 10 +-
Documentation/git-citool.txt | 4 +-
Documentation/git-clean.txt | 6 +-
Documentation/git-clone.txt | 14 ++--
Documentation/git-commit-tree.txt | 4 +-
Documentation/git-commit.txt | 28 +++---
Documentation/git-config.txt | 38 ++++----
Documentation/git-count-objects.txt | 4 +-
Documentation/git-cvsexportcommit.txt | 13 ++-
Documentation/git-cvsimport.txt | 20 ++--
Documentation/git-cvsserver.txt | 45 +++++-----
Documentation/git-daemon.txt | 34 ++++----
Documentation/git-describe.txt | 14 ++--
Documentation/git-diff-files.txt | 4 +-
Documentation/git-diff-index.txt | 34 ++++----
Documentation/git-diff-tree.txt | 18 ++--
Documentation/git-diff.txt | 18 ++--
Documentation/git-fast-export.txt | 10 +-
Documentation/git-fast-import.txt | 24 +++---
Documentation/git-fetch-pack.txt | 18 ++--
Documentation/git-fetch.txt | 4 +-
Documentation/git-filter-branch.txt | 14 ++--
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-for-each-ref.txt | 8 +-
Documentation/git-format-patch.txt | 6 +-
Documentation/git-fsck-objects.txt | 2 +-
Documentation/git-fsck.txt | 10 +-
Documentation/git-gc.txt | 16 ++--
Documentation/git-get-tar-commit-id.txt | 8 +-
Documentation/git-grep.txt | 4 +-
Documentation/git-gui.txt | 24 +++---
Documentation/git-hash-object.txt | 4 +-
Documentation/git-help.txt | 6 +-
Documentation/git-http-fetch.txt | 4 +-
Documentation/git-http-push.txt | 2 +-
Documentation/git-imap-send.txt | 6 +-
Documentation/git-index-pack.txt | 12 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 6 +-
Documentation/git-instaweb.txt | 8 +-
Documentation/git-log.txt | 6 +-
Documentation/git-lost-found.txt | 2 +-
Documentation/git-ls-files.txt | 10 +-
Documentation/git-ls-remote.txt | 4 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/git-mailinfo.txt | 8 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge-base.txt | 10 +-
Documentation/git-merge-file.txt | 14 ++--
Documentation/git-merge-index.txt | 20 ++--
Documentation/git-merge-one-file.txt | 4 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-merge.txt | 24 +++--
Documentation/git-mergetool.txt | 18 ++--
Documentation/git-mktag.txt | 2 +-
Documentation/git-mktree.txt | 2 +-
Documentation/git-mv.txt | 6 +-
Documentation/git-name-rev.txt | 8 +-
Documentation/git-pack-objects.txt | 10 +-
Documentation/git-pack-redundant.txt | 10 +-
Documentation/git-pack-refs.txt | 4 +-
Documentation/git-patch-id.txt | 4 +-
Documentation/git-peek-remote.txt | 6 +-
Documentation/git-prune-packed.txt | 2 +-
Documentation/git-prune.txt | 14 ++--
Documentation/git-pull.txt | 5 +-
Documentation/git-push.txt | 4 +-
Documentation/git-quiltimport.txt | 2 +-
Documentation/git-read-tree.txt | 46 +++++-----
Documentation/git-rebase.txt | 38 ++++----
Documentation/git-receive-pack.txt | 24 +++---
Documentation/git-relink.txt | 2 +-
Documentation/git-remote.txt | 12 +-
Documentation/git-repack.txt | 15 ++--
Documentation/git-repo-config.txt | 2 +-
Documentation/git-request-pull.txt | 2 +-
Documentation/git-rerere.txt | 14 ++--
Documentation/git-reset.txt | 2 +-
Documentation/git-rev-list.txt | 16 ++--
Documentation/git-rev-parse.txt | 18 ++--
Documentation/git-revert.txt | 2 +-
Documentation/git-rm.txt | 10 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 16 ++--
Documentation/git-shell.txt | 2 +-
Documentation/git-shortlog.txt | 6 +-
Documentation/git-show-branch.txt | 8 +-
Documentation/git-show-index.txt | 6 +-
Documentation/git-show-ref.txt | 10 +-
Documentation/git-show.txt | 8 +-
Documentation/git-stash.txt | 22 ++--
Documentation/git-status.txt | 6 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 14 ++--
Documentation/git-svn.txt | 153 +++++++++++++++---------------
Documentation/git-symbolic-ref.txt | 4 +-
Documentation/git-tag.txt | 18 ++--
Documentation/git-tar-tree.txt | 6 +-
Documentation/git-unpack-file.txt | 2 +-
Documentation/git-unpack-objects.txt | 4 +-
Documentation/git-update-index.txt | 26 +++---
Documentation/git-update-ref.txt | 10 +-
Documentation/git-update-server-info.txt | 4 +-
Documentation/git-upload-archive.txt | 4 +-
Documentation/git-upload-pack.txt | 8 +-
Documentation/git-var.txt | 4 +-
Documentation/git-verify-pack.txt | 6 +-
Documentation/git-verify-tag.txt | 4 +-
Documentation/git-web--browse.txt | 10 +-
Documentation/git-whatchanged.txt | 10 +-
Documentation/git-write-tree.txt | 2 +-
Documentation/git.txt | 30 +++---
Documentation/gitattributes.txt | 18 ++--
Documentation/gitcore-tutorial.txt | 127 ++++++++++++-------------
Documentation/gitcvs-migration.txt | 24 +++---
Documentation/gitdiffcore.txt | 34 ++++----
Documentation/githooks.txt | 10 +-
Documentation/gitignore.txt | 8 +-
Documentation/gitk.txt | 3 +-
Documentation/gitrepository-layout.txt | 24 +++---
Documentation/gittutorial-2.txt | 40 ++++----
Documentation/gittutorial.txt | 66 +++++++-------
Documentation/user-manual.txt | 85 ++++++++---------
140 files changed, 961 insertions(+), 964 deletions(-)
^ permalink raw reply
* Re: [PATCH v8] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Jakub Narebski @ 2008-06-30 21:55 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <48682934.6090406@gmail.com>
On Mon, 30 Jun 2008, Lea Wiemann wrote:
> Jakub Narebski wrote:
>>
>> some time ago I have send a patch which converted support for
>> links with hash and without action to use redirect instead of
>> silently filling correct action based on type of object [...]
>> IMHO it is better as it should prevent bookmarking "expensive" URL.
>
> Haha, I'd actually suggest the opposite. ;-) Figuring out the right
> action is almost free since you have to fetch the object anyways, so I
> doubt it'll make any difference performance-wise (though it'd be
> interesting to benchmark this).
It is one fork more[*1*], which doesn't matter on operating systems
like Linux where forking is fairly cheap.
But perhaps avoiding redirect would be better solution... well, yet
another solution would be to leave it up to gitweb configuration ;-)
[*1*] Or pre-fetching object (together with its type) which might be
large, into memory.
> However, gitweb's URLs are
> prohibitively long -- so that nobody uses them in email --, and
> (automatically?) dropping the action parameter where possible would be a
> good first step to shortening them. Another idea would be to shorten
> the hashes.
About shortening the hashes: _usually_ 8. characters is enough... but
sometimes it isn't. What then?
[...]
>> [Git::Commit:] you should not error out on unknown header in commit object,
>
> Unless this can actually happen in practice, I'd rather die aggressively
> -- it prevents errors (like cache hiccups) slipping through unnoticed.
If Git::Commit is to be *generic* object oriented interface to git
repository (and not only for gitweb), it has either to skip unknown
commit headers, or save them as-is.
As to checking cache: you can always check if header name is sane...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: how does git svn work
From: Brian Gernhardt @ 2008-06-30 20:57 UTC (permalink / raw)
To: Thomas Koch; +Cc: Git Mailing List
In-Reply-To: <200806302157.32828.thomas@koch.ro>
On Jun 30, 2008, at 3:57 PM, Thomas Koch wrote:
> In particular I want to follow the repository at:
> http://pubsvn.ez.no/nextgen/
>
> The layout is like
> /trunk
> /stable
> |- 4.0
> |- 3.9
> |- 3.8
> ...
> /releases
> |- 4.0
> |- 4.0r1
> |- 3.9
> |- 3.9r1
> |- 3.9r2
>
>
> I do not know, whether git-svn can create branches automatically for
> each directory under /stable and one main branch for trunk or
> whether I
> need to create one svn-remote definition for every svn directory I
> want
> to track.
I'm not sure what commands git-svn uses, but it looks like the
following command should work:
git svn clone --trunk=trunk --tags=releases --branches=stable http://pubsvn.ez.no/nextgen/
nextgen
That should create a nextgen git repository with a master branch
following SVN stable, and automatically grabbing anything under stable
or releases as a new branch. (I actually marked releases as a tag but
I think git-svn treats them as branches, since they can change on the
SVN side.)
~~ Brian
^ permalink raw reply
* how does git svn work
From: Thomas Koch @ 2008-06-30 19:57 UTC (permalink / raw)
To: Git Mailing List
Hi,
is there a document explaining the internals of GIT-SVN? I'd like to
know, which SVN commands are executed in the background and how git-svn
recognizes branch creation in SVN.
In particular I want to follow the repository at:
http://pubsvn.ez.no/nextgen/
The layout is like
/trunk
/stable
|- 4.0
|- 3.9
|- 3.8
...
/releases
|- 4.0
|- 4.0r1
|- 3.9
|- 3.9r1
|- 3.9r2
I do not know, whether git-svn can create branches automatically for
each directory under /stable and one main branch for trunk or whether I
need to create one svn-remote definition for every svn directory I want
to track.
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* how does git svn work
From: Thomas Koch @ 2008-06-30 19:57 UTC (permalink / raw)
To: Git Mailing List
Hi,
is there a document explaining the internals of GIT-SVN? I'd like to
know, which SVN commands are executed in the background and how git-svn
recognizes branch creation in SVN.
In particular I want to follow the repository at:
http://pubsvn.ez.no/nextgen/
The layout is like
/trunk
/stable
|- 4.0
|- 3.9
|- 3.8
...
/releases
|- 4.0
|- 4.0r1
|- 3.9
|- 3.9r1
|- 3.9r2
I do not know, whether git-svn can create branches automatically for
each directory under /stable and one main branch for trunk or whether I
need to create one svn-remote definition for every svn directory I want
to track.
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ 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