* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-12 7:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5ot40w9.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
stop t1400 hiding errors in tests
Benoit Sigoure (1):
git-send-email: Change the prompt for the subject of the initial
message.
Gerrit Pape (1):
git-mailsplit: with maildirs not only process cur/, but also new/
Jonas Fonseca (1):
instaweb: Minor cleanups and fixes for potential problems
Junio C Hamano (3):
refresh_index_quietly(): express "optional" nature of index writing
better
Makefile: add missing dependency on wt-status.h
Start preparing for 1.5.3.6
Nicolas Pitre (3):
print warning/error/fatal messages in one shot
git-hash-object should honor config variables
fix index-pack with packs >4GB containing deltas on 32-bit machines
Ralf Wildenhues (2):
Avoid a few unportable, needlessly nested "...`...".
Fix sed string regex escaping in module_name.
Sergei Organov (1):
SubmittingPatches: improve the 'Patch:' section of the checklist
Vincent Zanotti (1):
gitweb: correct month in date display for atom feeds
* The 'master' branch has these since the last announcement
in addition to the above.
Gerrit Pape (3):
hooks--update: fix test for properly set up project description
file
hooks--update: decline deleting tags or branches by default, add
config options
contrib/hooks/post-receive-email: remove cruft, $committer is not
used
Johannes Schindelin (4):
parse-options: abbreviation engine fix.
builtin-reset: do not call "ls-files --unmerged"
builtin-reset: avoid forking "update-index --refresh"
builtin-blame: set up the work_tree before the first file access
Johannes Sixt (1):
upload-pack: Use finish_{command,async}() instead of waitpid().
Junio C Hamano (6):
Style: place opening brace of a function definition at column 1
Update draft release notes for 1.5.4
Documentation: lost-found is now deprecated.
Make check-docs target detect removed commands
Documentation: remove documentation for removed tools.
git-commit: a bit more tests
Lars Hjemli (1):
for-each-ref: fix setup of option-parsing for --sort
Michele Ballabio (1):
test-lib.sh: move error line after error() declaration
Nicolas Pitre (1):
add a howto document about corrupted blob recovery
Ralf Wildenhues (1):
git-bisect.sh: Fix sed script to work with AIX and BSD sed.
Sergei Organov (1):
core-tutorial.txt: Fix git-show-branch example and its description
Steffen Prohaska (2):
push: mention --verbose option in documentation
push: teach push to pass --verbose option to transport layer
^ permalink raw reply
* [PATCH 3/3 v2] git-svn log: handle unreachable revisions like "svn log"
From: David D Kilzer @ 2007-11-12 6:56 UTC (permalink / raw)
To: git; +Cc: gitster, David D Kilzer
In-Reply-To: <1194761435-7286-4-git-send-email-ddkilzer@kilzer.net>
When unreachable revisions are given to "svn log", it displays all commit
logs in the given range that exist in the current tree. (If no commit
logs are found in the current tree, it simply prints a single commit log
separator.) This patch makes "git-svn log" behave the same way.
Ten tests added to t/t9116-git-svn-log.sh.
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net>
---
No changes were needed to parts 1 and 2 of this series, so I am not
reposting them.
Updated this patch based on feedback from Benoit Sigoure and Eric Wong:
- Commented find_rev_before() and find_rev_after().
- Changed commit_log_separator() into a constant.
- Made return statement safer by adding another check in git_svn_log_cmd().
- Changed echo statement to printf in t/t9116-git-svn-log.sh.
All tests pass on maint branch.
git-svn.perl | 63 ++++++++++++++++++++++++++++++++--------------
t/t9116-git-svn-log.sh | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+), 19 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 39585d8..f017f94 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2256,10 +2256,15 @@ sub rev_db_get {
$ret;
}
+# Finds the first svn revision that exists on (if $eq_ok is true) or
+# before $rev for the current branch. It will not search any lower
+# than $min_rev. Returns the git commit hash and svn revision number
+# if found, else (undef, undef).
sub find_rev_before {
- my ($self, $rev, $eq_ok) = @_;
+ my ($self, $rev, $eq_ok, $min_rev) = @_;
--$rev unless $eq_ok;
- while ($rev > 0) {
+ $min_rev ||= 1;
+ while ($rev >= $min_rev) {
if (my $c = $self->rev_db_get($rev)) {
return ($rev, $c);
}
@@ -2268,6 +2273,23 @@ sub find_rev_before {
return (undef, undef);
}
+# Finds the first svn revision that exists on (if $eq_ok is true) or
+# after $rev for the current branch. It will not search any higher
+# than $max_rev. Returns the git commit hash and svn revision number
+# if found, else (undef, undef).
+sub find_rev_after {
+ my ($self, $rev, $eq_ok, $max_rev) = @_;
+ ++$rev unless $eq_ok;
+ $max_rev ||= $self->rev_db_max();
+ while ($rev <= $max_rev) {
+ if (my $c = $self->rev_db_get($rev)) {
+ return ($rev, $c);
+ }
+ ++$rev;
+ }
+ return (undef, undef);
+}
+
sub _new {
my ($class, $repo_id, $ref_id, $path) = @_;
unless (defined $repo_id && length $repo_id) {
@@ -3494,6 +3516,7 @@ package Git::SVN::Log;
use strict;
use warnings;
use POSIX qw/strftime/;
+use constant commit_log_separator => ('-' x 72) . "\n";
use vars qw/$TZ $limit $color $pager $non_recursive $verbose $oneline
%rusers $show_commit $incremental/;
my $l_fmt;
@@ -3587,19 +3610,19 @@ sub git_svn_log_cmd {
push @cmd, $c;
}
} elsif (defined $r_max) {
- my ($c_min, $c_max);
- $c_max = $gs->rev_db_get($r_max);
- $c_min = $gs->rev_db_get($r_min);
- if (defined $c_min && defined $c_max) {
- if ($r_max > $r_min) {
- push @cmd, "--boundary", "$c_min..$c_max";
- } else {
- push @cmd, "--boundary", "$c_max..$c_min";
- }
- } elsif ($r_max > $r_min) {
- push @cmd, $c_max;
+ if ($r_max < $r_min) {
+ ($r_min, $r_max) = ($r_max, $r_min);
+ }
+ my (undef, $c_max) = $gs->find_rev_before($r_max, 1, $r_min);
+ my (undef, $c_min) = $gs->find_rev_after($r_min, 1, $r_max);
+ # If there are no commits in the range, both $c_max and $c_min
+ # will be undefined. If there is at least 1 commit in the
+ # range, both will be defined.
+ return () if !defined $c_min || !defined $c_max;
+ if ($c_min eq $c_max) {
+ push @cmd, '--max-count=1', $c_min;
} else {
- push @cmd, $c_min;
+ push @cmd, '--boundary', "$c_min..$c_max";
}
}
return (@cmd, @files);
@@ -3707,7 +3730,7 @@ sub show_commit_changed_paths {
sub show_commit_normal {
my ($c) = @_;
- print '-' x72, "\nr$c->{r} | ";
+ print commit_log_separator, "r$c->{r} | ";
print "$c->{c} | " if $show_commit;
print "$c->{a} | ", strftime("%Y-%m-%d %H:%M:%S %z (%a, %d %b %Y)",
localtime($c->{t_utc})), ' | ';
@@ -3768,6 +3791,10 @@ sub cmd_show_log {
config_pager();
@args = git_svn_log_cmd($r_min, $r_max, @args);
+ if (!@args) {
+ print commit_log_separator unless $incremental || $oneline;
+ return;
+ }
my $log = command_output_pipe(@args);
run_pager();
my (@k, $c, $d, $stat);
@@ -3816,14 +3843,12 @@ sub cmd_show_log {
process_commit($c, $r_min, $r_max, \@k);
}
if (@k) {
- my $swap = $r_max;
- $r_max = $r_min;
- $r_min = $swap;
+ ($r_min, $r_max) = ($r_max, $r_min);
process_commit($_, $r_min, $r_max) foreach reverse @k;
}
out:
close $log;
- print '-' x72,"\n" unless $incremental || $oneline;
+ print commit_log_separator unless $incremental || $oneline;
}
package Git::SVN::Migration;
diff --git a/t/t9116-git-svn-log.sh b/t/t9116-git-svn-log.sh
index 5000892..902ed41 100755
--- a/t/t9116-git-svn-log.sh
+++ b/t/t9116-git-svn-log.sh
@@ -30,6 +30,12 @@ test_expect_success 'setup repository and import' "
git reset --hard trunk &&
echo aye >> README &&
git commit -a -m aye &&
+ git svn dcommit &&
+ git reset --hard b &&
+ echo spy >> README &&
+ git commit -a -m spy &&
+ echo try >> README &&
+ git commit -a -m try &&
git svn dcommit
"
@@ -59,4 +65,64 @@ test_expect_success 'test descending revision range' "
git svn log -r 4:1 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r4-r2-r1 -
"
+printf 'r1 \nr2 \n' > expected-range-r1-r2
+
+test_expect_success 'test ascending revision range with unreachable revision' "
+ git reset --hard trunk &&
+ git svn log -r 1:3 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r1-r2 -
+ "
+
+printf 'r2 \nr1 \n' > expected-range-r2-r1
+
+test_expect_success 'test descending revision range with unreachable revision' "
+ git reset --hard trunk &&
+ git svn log -r 3:1 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r2-r1 -
+ "
+
+printf 'r2 \n' > expected-range-r2
+
+test_expect_success 'test ascending revision range with unreachable upper boundary revision and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 2:3 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r2 -
+ "
+
+test_expect_success 'test descending revision range with unreachable upper boundary revision and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 3:2 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r2 -
+ "
+
+printf 'r4 \n' > expected-range-r4
+
+test_expect_success 'test ascending revision range with unreachable lower boundary revision and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 3:4 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r4 -
+ "
+
+test_expect_success 'test descending revision range with unreachable lower boundary revision and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 4:3 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r4 -
+ "
+
+printf -- '------------------------------------------------------------------------\n' > expected-separator
+
+test_expect_success 'test ascending revision range with unreachable boundary revisions and no commits' "
+ git reset --hard trunk &&
+ git svn log -r 5:6 | diff -u expected-separator -
+ "
+
+test_expect_success 'test descending revision range with unreachable boundary revisions and no commits' "
+ git reset --hard trunk &&
+ git svn log -r 6:5 | diff -u expected-separator -
+ "
+
+test_expect_success 'test ascending revision range with unreachable boundary revisions and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 3:5 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r4 -
+ "
+
+test_expect_success 'test descending revision range with unreachable boundary revisions and 1 commit' "
+ git reset --hard trunk &&
+ git svn log -r 5:3 | grep '^r[0-9]' | cut -d'|' -f1 | diff -u expected-range-r4 -
+ "
+
test_done
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Theodore Tso @ 2007-11-12 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzlxk8apz.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 06:21:44PM -0800, Junio C Hamano wrote:
> Theodore Ts'o <tytso@mit.edu> writes:
>
> > Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
> > "git help" is less intimidating.
> >
> > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> >
> > -apply
> > -archive
> > -prune
> > -revert
> > -show-branch
>
> I am fine with this list, perhaps except apply.
I was borderline on apply, but given that people are familiar with
patch -p1, the only real advantage git-apply has is that automatically
deals with new files (which "git commit -a" or "git add -u" won't
automatically get).
What did you think about cherry-pick? Was that omitted by accident?
> On the other hand, if you are shooting *really* for the absolute
> minimum set for the beginners, I would kill rm and possibly mv)
> in addition to your list:
Those did cross my mind as well. :-)
> I have a bit of reservation about revert, but I'd imagine we
> could kill it, and also fetch, pull and push, if you are
> shooting for *real* beginners who work alone. I think the only
> valid justification to drop "revert" from the list is to assume
> that the audience do not interact with the outside world, and
> dropping fetch/pull/push from the list is in line with that.
My mental model for git newbies is that they would probably be pulling
from upstream repositories (so I was tempted to remove git-init from
the common commands list), but they would rarely be cherry-picking or
reverting other people's changes.
They probably would be submitting changes back upstream using e-mail
before they learn how to publish their own repository, so commands I'd
be tempted to add would include git-format-patch, git-send-email, and
git-cherry. But these commands are pretty complicated for beginners....
- Ted
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-12 6:25 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111446u3e19be7ch90cf79f1d3efc3ef@mail.gmail.com>
On Nov 11, 2007, at 11:46 PM, Jon Smirl wrote:
> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
>>
>>> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>>> jonsmirl@terra:~/mpc5200b$ git remote show linus
>>>>> * remote linus
>>>>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>>>> linux-2.6.git
>>>>>
>>>>> How do I push the definition of the linus remote repo?
>>>>
>>>> You can't. Remotes are local to a repository. They cannot be
>>>> "pushed" nor will they be "cloned" or "fetched".
>>>
>>> Dreamhost is way slow compared to kernel.org, so it is better to
>>> clone
>>> from kernel.org first and then pull from dreamhost. What is the
>>> right
>>> sequence of commands so that a new user will end up with a kernel
>>> they
>>> can use 'git pull' on to get updates from dreamhost? I'll add
>>> these to
>>> the repo description page.
>>>
>>> I'm trying this locally and I can't figure out the right sequence of
>>> git command to redirect origin from kernel.org to dreamhost.
>>
>> How about the following (untested sequence)
>>
>> mkdir linux-2.6
>> cd linux-2.6
>> git init
>> git remote add linus git://git.kernel.org/pub/scm/linux/
>> kernel/git/
>> torvalds/linux-2.6.git
>> git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
>> mpc5200b.git
>> git fetch linus
>> git fetch origin
>> git checkout -b master origin/master
>>
>> The general idea should be correct. You have a non-standard
>> setup, so avoid git-clone.
>
> What should I do to standardize the setup so that 'clone/pull' will
> work on it?
Pull should work after you checked out origin/master. Pull should
fetch from origin and merge to local master.
But I don't see a way how you could use clone for your setup.
> I created a master branch. I gave up on fighting with
> gitweb and no branch named master.
I don't understand your comment about gitweb.
> I'd like to do this, but I can't figure out how.
>
> git clone linus
> move origin to digispeaker
> git pull
>
> There doesn't seem to be a simple way to redirect the origin.
I don't know a simple way.
Steffen
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Ping Yin @ 2007-11-12 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Ts'o, Git Mailing List
In-Reply-To: <7vzlxk8apz.fsf@gitster.siamese.dyndns.org>
> I have a bit of reservation about revert, but I'd imagine we
> could kill it, and also fetch, pull and push, if you are
> shooting for *real* beginners who work alone. I think the only
> valid justification to drop "revert" from the list is to assume
> that the audience do not interact with the outside world, and
> dropping fetch/pull/push from the list is in line with that.
many "real" beginners are users of CVS/svn, so the very first thing
they want to do is simulating the cvs/svn operation, so IMHO pull
(update) and push(commit) should be kept.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ping Yin
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Ping Yin @ 2007-11-12 5:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcjscyhu.fsf@gitster.siamese.dyndns.org>
On Nov 12, 2007 4:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> If "superprojects is not so super", why are you using submodule
> to bind these, instead of using a single project that tracks
> developments of such closely tied parts?
>
For small modules crossing over mutiple projects, the submodule way
may be more suitable. And such submodule (such as common config files,
common templates) may be binded tightly with superproject
>
--
Ping Yin
^ permalink raw reply
* Re: git packs
From: Martin Langhoff @ 2007-11-12 4:46 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <00593593-E943-4DA0-AA9B-FDBB866E7EFB@mac.com>
On Nov 11, 2007 6:40 AM, bob <kranki@mac.com> wrote:
> I am now going to split out the jpg(s), pdf(s)
> and (.mov) files from the repository and just
> manage them external to the git repository
> which will fix my git problem.
For version-less synchronization of large files I'd suggest unison (as
a smarter rsync, it's excellent) or the newfangled tra.
hth,
martin
^ permalink raw reply
* [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc
From: Jing Xue @ 2007-11-12 4:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vsl3c8afm.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 06:27:57PM -0800, Junio C Hamano wrote:
>
> I think "changes ... can be removed" risks to give a confused
> mental model that somehow git tracks changes.
I see what you mean. "Changes" shouldn't be the subject here.
> "A file can be
> reverted back to that of the last commit with ..." would be
> less risky.
On top of that, I somehow still want to make it relevant to that
git-reset instead of git-rm should be used to revert git-add. So how
about this?
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-add.txt | 1 +
Documentation/git-commit.txt | 13 ++++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -224,6 +224,7 @@ See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
+gitlink:git-reset[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..4b26cae 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,11 +154,14 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1]. Removal
-of a file is staged with gitlink:git-rm[1]. After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far. This is the most basic form of the
+called the "index" with gitlink:git-add[1]. A file can be
+reverted back, only in the index but not in the working tree,
+to that of the last commit with `git-reset HEAD -- <file>`,
+which effectively reverts `git-add` and prevents this file from
+participating in the next commit. After building the state to
+be committed incrementally with these commands, `git commit`
+(without any pathname parameter) is used to record what has
+been staged so far. This is the most basic form of the
command. An example:
------------
^ permalink raw reply related
* [PATCH] for-each-ref: fix off by one read.
From: Christian Couder @ 2007-11-12 4:37 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-for-each-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 598d4e1..89ea37c 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -306,7 +306,7 @@ static const char *find_wholine(const char *who, int wholen, const char *buf, un
if (!eol)
return "";
eol++;
- if (eol[1] == '\n')
+ if (*eol == '\n')
return ""; /* end of header */
buf = eol;
}
--
1.5.3.5.577.g4d1b9-dirty
^ permalink raw reply related
* Re: git packs
From: Nicolas Pitre @ 2007-11-12 4:21 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <B298202C-3D54-498D-A348-0338914FBA46@mac.com>
On Sun, 11 Nov 2007, bob wrote:
> I applied the patch and these commands:
>
> cd rmwHtmlOld
> rm -fr .git
> git init
> git config core.compression 0
> git add .
Note that I did "git config core.compression 0" simply to disable
zlib compression altogether when creating the test repo just so it gets
created faster. even then, auto-generating and cloning a 8GB test
repository isn't particularly quick.
> I then got the same error as before, "Bus error". Rats!
Do you get that with a 32-bit or 64-bit build of Git?
> Then I modified your script since I do not have seq or
> your test-genrandom.
test-genrandom is built with Git. It is just not installed anywhere.
> I substituted:
>
> dd count=XX if=/dev/random of=file_$i
>
> where XX is adjusted to meet dd's requirements. Also,
Again I used test-genrandom instead of /dev/random or /dev/urandom
simply because the former is much faster.
> I found after searching for a while, that the following
> works just like your seq command:
>
> xyzzy="1 2 3 4"
> for i in $xyzzy
> do
> ...
> done
>
> Your script then ran flawlessly.
However 'seq -w 1 2 63' should be replaced with "01 03 05 07 09 11 13
15" and so on up to 63, and 'seq -w 2 2 64' is "02 04 06 08 10 12 16"
and so on.
> I looked through index-pack.c some more, but it is
> very hard to figure it out without doing a lot of research
> since there doesn't seem to be anything that describes
> the layout of a pack. The link towards the end of the user's
> manual doesn't work for me.
Look at Documentation/technical/pack-format.txt in the Git source tree.
> The difference between your test and my data is that
> instead of having a few large files, I have 11,500 files
> of varying sizes. On average though, the file size is
> about 370k.
Are you saying that the test repo with big files works for you but not
your own data set?
Would you please recap what your problem is?
With my one line patch you should not get the "serious inflate
inconsistency" error anymore. The bus error must be another issue.
Nicolas
^ permalink raw reply
* [PATCH] git-branch: remove mention of non-existent '-b' option
From: Jeff King @ 2007-11-12 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This looks like a cut and paste error from the git-checkout
explanation of --no-track.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5e81aa4..5ce905d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -105,7 +105,7 @@ OPTIONS
'--track' were given.
--no-track::
- When -b is given and a branch is created off a remote branch,
+ When a branch is created off a remote branch,
set up configuration so that git-pull will not retrieve data
from the remote branch, ignoring the branch.autosetupmerge
configuration variable.
--
1.5.3.5.1664.gcd60
^ permalink raw reply related
* Re: git packs
From: bob @ 2007-11-12 2:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711102331270.21255@xanadu.home>
I applied the patch and these commands:
cd rmwHtmlOld
rm -fr .git
git init
git config core.compression 0
git add .
I then got the same error as before, "Bus error". Rats!
Then I modified your script since I do not have seq or
your test-genrandom. I substituted:
dd count=XX if=/dev/random of=file_$i
where XX is adjusted to meet dd's requirements. Also,
I found after searching for a while, that the following
works just like your seq command:
xyzzy="1 2 3 4"
for i in $xyzzy
do
...
done
Your script then ran flawlessly.
I looked through index-pack.c some more, but it is
very hard to figure it out without doing a lot of research
since there doesn't seem to be anything that describes
the layout of a pack. The link towards the end of the user's
manual doesn't work for me.
The difference between your test and my data is that
instead of having a few large files, I have 11,500 files
of varying sizes. On average though, the file size is
about 370k.
HTH
On Nov 10, 2007, at 11:35 PM, Nicolas Pitre wrote:
> On Sat, 10 Nov 2007, bob wrote:
>
>> I will try a few things and see if I can get a script put together
>> that generates the inflate problem. The data that I am
>> using is a backup of my original repository. So, I can
>> play all that I want. But it would be a lot easier if I
>> could just generate some files using dd or something.
>
> Please see the patch I just posted to the list. That should fix your
> problem. I even included a small script to create a repository
> confirming the problem and allowing to test the fix.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] git-svn log: handle unreachable revisions like "svn log"
From: Eric Wong @ 2007-11-12 2:50 UTC (permalink / raw)
To: David D. Kilzer; +Cc: Benoit Sigoure, git, gitster
In-Reply-To: <189577.85054.qm@web52407.mail.re2.yahoo.com>
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
Hi Dave, thanks for the patches, and thanks to Benoit for the review.
> Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
>
> > thanks for the patches, the series looks good to me, I added some
> > comments below, for this patch.
>
> Thanks for the review, Benoit! Comments below.
>
> > On Nov 11, 2007, at 7:10 AM, David D Kilzer wrote:
> >
> > > sub find_rev_before {
> > > - my ($self, $rev, $eq_ok) = @_;
> > > + my ($self, $rev, $eq_ok, $min_rev) = @_;
> >
> > Could you please document this function? I guess that you had to
> > figure out what each argument was for, so please save the time of the
> > contributors that will read this code after you :)
>
> What is the format for documenting functions in git Perl scripts? I
> haven't see any "perlpod" use anywhere. Do you just want comments
> before the function?
Just a regular comment is enough, perlpod uses too much space.
> This method returns the git commit hash and svn revision of the first svn
> revision that exists on the current branch that is less than $rev (or
> less-than-or-equal-to $rev if $eq_ok is true).
>
> Please note that I don't have a full understanding of how find_rev_before()
> works (other than it's computing an offset into a sparse? data file based on
> the revision number) since I'm still new to git.
Pretty much. The .rev_db format is documented above the _rev_db_set
sub. I'm considering replacing the current rev_db format with something
more compact for larger repos, though.
> > > +sub find_rev_after {
> > > + my ($self, $rev, $eq_ok, $max_rev) = @_;
> > > + ++$rev unless $eq_ok;
> > > + $max_rev ||= $self->rev_db_max();
> > > + while ($rev <= $max_rev) {
> > > + if (my $c = $self->rev_db_get($rev)) {
> > > + return ($rev, $c);
> > > + }
> > > + ++$rev;
> > > + }
> > > + return (undef, undef);
> > > +}
> >
> > Too much code duplication. It should be possible to write a sub
> > find_rev_ (or _find_rev, don't know what's the naming convention for
> > internal details) that takes a 5th argument, an anonymous sub that
> > does the comparison. So that basically, find_rev_before will be
> > something along these (untested) lines:
> >
> > sub find_rev_before {
> > my ($self, $rev, $eq_ok, $min_rev) = @_;
> > return find_rev_($self, $rev, $eq_ok, $min_rev, sub { my ($a, $b) =
> > @_; return $a >= $b; });
> > }
>
> I think that combining find_rev_before() and find_rev_after() would greatly
> sacrifice readability of the code in exchange for removing ~10 lines of code.
> Also, you must do more than just replace the comparison in the while() loop:
>
> - before() decrements $rev while after() increments it
> - stop limits are different ($max_rev versus $min_rev)
>
> This is what such a method might look like (untested). Since you already
> requested find_rev_before() be documented, is this really going to help?
>
> sub find_rev_ {
> my ($self, $rev, $eq_ok, $is_before, $limit_rev) = @_;
> ($is_before ? --$rev : ++$rev) unless $eq_ok;
> $limit_rev ||= ($is_before ? 1 : $self->rev_db_max());
> while ($is_before ? $rev >= $limit_rev : $rev <= $limit_rev) {
> if (my $c = $self->rev_db_get($rev)) {
> return ($rev, $c);
> }
> $is_before ? --$rev : ++$rev;
> }
> return (undef, undef);
> }
find_rev_ is too complicated, please keep them as separate functions.
> Defining wrapper functions would help, but I still think it's just as clear to
> keep the two methods separate.
>
> sub find_rev_before() {
> my ($self, $rev, $eq_ok, $min_rev) = @_;
> return $self->find_rev_($rev, $eq_ok, 1, $min_rev);
> }
>
> sub find_rev_after() {
> my ($self, $rev, $eq_ok, $max_rev) = @_;
> return $self->find_rev_($rev, $eq_ok, 0, $max_rev);
> }
>
> Do you agree, or do you think the methods should still be combined?
>
> > > + if ($r_max < $r_min) {
> > > + ($r_min, $r_max) = ($r_max, $r_min);
> > > + }
> > > + my (undef, $c_max) = $gs->find_rev_before($r_max, 1, $r_min);
> > > + my (undef, $c_min) = $gs->find_rev_after($r_min, 1, $r_max);
> > > + # If there are no commits in the range, both $c_max and $c_min
> > > + # will be undefined. If there is at least 1 commit in the
> > > + # range, both will be defined.
> > > + return () if !defined $c_min;
> >
> > Fair enough but I'd strengthen the test by writing something like:
> > return () if not defined $c_min || not defined $c_max;
> > unless you can prove that `rev_db_get' can never return `undef' or
> > something like that.
I prefer '!' instead of 'not' unless operator precedence matters.
> Will make this change.
>
> > > +sub commit_log_separator {
> > > + return ('-' x 72) . "\n";
> > > +}
> > > +
> >
> > This is basically a constant, I think that declaring it with a
> > prototype helps Perl to optimize it:
> > sub commit_log_separator() {
use constant commit_log_separator => ('-' x 72) . "\n";
is probably most readable...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: prevent dcommitting if the index is dirty.
From: Eric Wong @ 2007-11-12 2:28 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <1194806501-4796-1-git-send-email-tsuna@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> dcommit uses rebase `sync' the history with what has just been pushed to
> SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now
> the user will get an error message if he attempts to dcommit with a dirty
> index.
>
> Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Thanks,
Minor nit below about indentation (which Junio can fix when applying),
but nevertheless:
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 3 +++
> t/t9106-git-svn-dcommit-clobber-series.sh | 6 ++++++
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index dd93e32..a15df4f 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -390,6 +390,9 @@ sub cmd_set_tree {
>
> sub cmd_dcommit {
> my $head = shift;
> + git_cmd_try { command_oneline(qw/diff-index --quiet HEAD/) }
> + 'Cannot dcommit with a dirty index. Commit your changes first'
> + . "or stash them with `git stash'.\n";
We use tabs for indentation, and spaces for alignment.
> $head ||= 'HEAD';
> my @refs;
> my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] replace reference to git-rm with git-reset in git-commit doc
From: Junio C Hamano @ 2007-11-12 2:27 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20071112003845.GA7595@fawkes>
Jing Xue <jingxue@digizenstudio.com> writes:
> On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:
>>
>> The message in git-commit suggesting to use 'git rm --cached' to unstage is
>> just plain wrong. It really should mention 'git reset'.
>
> Hopefully this makes it clearer. I have also updated the faq in wiki to
> clarify.
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index e54fb12..7c63dd8 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -154,12 +154,12 @@ EXAMPLES
> --------
> When recording your own work, the contents of modified files in
> your working tree are temporarily stored to a staging area
> +called the "index" with gitlink:git-add[1]. File changes
> +previously staged can be removed with `git-reset
> +HEAD -- <file>`.
I think "changes ... can be removed" risks to give a confused
mental model that somehow git tracks changes. "A file can be
reverted back to that of the last commit with ..." would be
less risky.
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Junio C Hamano @ 2007-11-12 2:21 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Git Mailing List
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
Theodore Ts'o <tytso@mit.edu> writes:
> Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
> "git help" is less intimidating.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> -apply
> -archive
> -prune
> -revert
> -show-branch
I am fine with this list, perhaps except apply.
On the other hand, if you are shooting *really* for the absolute
minimum set for the beginners, I would kill rm and possibly mv)
in addition to your list:
- git-rm is always easier to do with "rm -fr file-or-dir",
followed by "git commit -a". Of course "git rm --cached" and
partial commits that contain removal cannot be emulated
easily this way, but this is an alternative suggestion to aim
for *real* beginners who do not use the index.
- git-mv is on my list for the same reason as "rm", but it is a
bit more cumbersome if you want to move a directory, because
"mv old new && git add new" would not work for people without
a correctly set-up .gitignore (and if we are talking about
beginners, we should expect user's .gitignore is borked).
I have a bit of reservation about revert, but I'd imagine we
could kill it, and also fetch, pull and push, if you are
shooting for *real* beginners who work alone. I think the only
valid justification to drop "revert" from the list is to assume
that the audience do not interact with the outside world, and
dropping fetch/pull/push from the list is in line with that.
^ permalink raw reply
* Re: Is it possible for git to remember the options preference for "git log"?
From: eric miao @ 2007-11-12 2:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111954520.29952@iabervon.org>
On Nov 12, 2007 9:02 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> On Mon, 12 Nov 2007, eric miao wrote:
>
> > All,
> >
> > Most of the time I'm using git-log for inspecting a brief history
> > and insert/remove/modify commits between, which I have to
> > type "git log --abbrev-commit --pretty=oneline" every time. Is
> > it possible for git to remember this command line options
> > preference?
> >
> > And no, I don't really want to use shell's alias or something
> > else, I was just used to type "git xxx" :-)
>
> Git has a built-in alias mechanism, which is probably what you want. If
> you put in your config file:
>
> [alias]
> xxx = log --abbrev-commit --pretty=online
>
Thanks, this is exactly what I want.
> then you can type "git xxx" and it'll do what you want. Changing the
> default behavior of the basic commands is looked down on because there are
> scripts that use them to get their input, and those scripts have
> particular formats they expect.
>
Ye, agree, I don't think that's a good idea either.
> -Daniel
> *This .sig left intentionally blank*
>
--
Cheers
- eric
^ permalink raw reply
* [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-12 1:48 UTC (permalink / raw)
To: gitster; +Cc: git, johannes.schindelin, Shawn Bohrer
This replaces git-clean.sh with builtin-clean.c, and moves
git-clean.sh to the examples.
This also introduces a change in behavior when removing directories
explicitly specified as a path. For example currently:
1. When dir has only untracked files, these two behave differently:
$ git clean -n dir
$ git clean -n dir/
the former says "Would not remove dir/", while the latter would say
"Would remove dir/untracked" for all paths under it, but not the
directory itself.
With -d, the former would stop refusing, however since the user
explicitly asked to remove the directory the -d is no longer required.
2. When there are more parameters:
$ git clean -n dir foo
$ git clean -n dir/ foo
both cases refuse to remove dir/ unless -d is specified. Once again
since both cases requested to remove dir the -d is no longer required.
Thanks to Johannes Schindelin for the conversion to using the
parse-options API.
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
On Wed, Nov 07, 2007 at 11:37:50PM -0600, Shawn Bohrer wrote:
> On Wed, Nov 07, 2007 at 12:42:16PM -0800, Junio C Hamano wrote:
> >
> > Having said that, I do not particularly agree with the way the
> > new implementation resolves the existing inconsistencies.
> >
> > Wouldn't it be better to remove "dir" when the user explicitly
> > told you to clean "dir", with or without the trailing slash?
> > That's what the user asked you to do, isn't it?
>
> Yes I suppose I agree. Of course I need to spend some more time staring
> at the code to figure out how to do so. Perhaps I can figure out what
> is causing the original inconsistency in git-ls-files while I'm at it.
OK, I failed to fix the inconsistency between a single and multiple
paths so I'm not sure if this patch is much better. The problem appears
to be that when dir.show_others_directories is set directories that only
contain untracked files are not recursed, which is fine with a single
path because you can adjust the path, base and baselen to
read_directory(). With multiple paths you need to find a common prefix
to all of the paths before calling read_directory() which causes the
inconsistency.
If anyone as a suggestion on how to fix this I'm all for it, but even
with the inconsistency we are no worse than we were with git-clean.sh
Makefile | 3 +-
builtin-clean.c | 154 +++++++++++++++++++++++++
builtin.h | 1 +
git-clean.sh => contrib/examples/git-clean.sh | 0
git.c | 1 +
5 files changed, 158 insertions(+), 1 deletions(-)
create mode 100644 builtin-clean.c
rename git-clean.sh => contrib/examples/git-clean.sh (100%)
diff --git a/Makefile b/Makefile
index a2fcdb8..ef7420d 100644
--- a/Makefile
+++ b/Makefile
@@ -213,7 +213,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
- git-clean.sh git-clone.sh git-commit.sh \
+ git-clone.sh git-commit.sh \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh \
@@ -329,6 +329,7 @@ BUILTIN_OBJS = \
builtin-check-attr.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
+ builtin-clean.o \
builtin-commit-tree.o \
builtin-count-objects.o \
builtin-describe.o \
diff --git a/builtin-clean.c b/builtin-clean.c
new file mode 100644
index 0000000..55658e7
--- /dev/null
+++ b/builtin-clean.c
@@ -0,0 +1,154 @@
+/*
+ * "git clean" builtin command
+ *
+ * Copyright (C) 2007 Shawn Bohrer
+ *
+ * Based on git-clean.sh by Pavel Roskin
+ */
+
+#include "builtin.h"
+#include "cache.h"
+#include "dir.h"
+#include "parse-options.h"
+
+static int force;
+
+static const char *const builtin_clean_usage[] = {
+ "git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...",
+ NULL
+};
+
+static int git_clean_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "clean.requireforce"))
+ force = !git_config_bool(var, value);
+ return 0;
+}
+
+int cmd_clean(int argc, const char **argv, const char *prefix)
+{
+ int j;
+ int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int ignored_only = 0, baselen = 0;
+ struct strbuf directory;
+ struct dir_struct dir;
+ const char *path, *base;
+ static const char **pathspec;
+ struct option options[] = {
+ OPT__QUIET(&quiet),
+ OPT__DRY_RUN(&show_only),
+ OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('d', NULL, &remove_directories,
+ "remove whole directories"),
+ OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
+ OPT_BOOLEAN('X', NULL, &ignored_only,
+ "remove only ignored files"),
+ OPT_END()
+ };
+
+ git_config(git_clean_config);
+ argc = parse_options(argc, argv, options, builtin_clean_usage, 0);
+
+ memset(&dir, 0, sizeof(dir));
+ if (ignored_only) {
+ dir.show_ignored =1;
+ dir.exclude_per_dir = ".gitignore";
+ }
+
+ if (ignored && ignored_only)
+ die("-x and -X cannot be used together");
+
+ if (!show_only && !force)
+ die("clean.requireForce set and -n or -f not given; refusing to clean");
+
+ dir.show_other_directories = 1;
+
+ if (!ignored) {
+ dir.exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), F_OK)) {
+ char *exclude_path = git_path("info/exclude");
+ add_excludes_from_file(&dir, exclude_path);
+ }
+ }
+
+ pathspec = get_pathspec(prefix, argv);
+ read_cache();
+
+ /*
+ * Calculate common prefix for the pathspec, and
+ * use that to optimize the directory walk
+ */
+ baselen = common_prefix(pathspec);
+ path = ".";
+ base = "";
+ if (baselen)
+ path = base = xmemdupz(*pathspec, baselen);
+ read_directory(&dir, path, base, baselen, pathspec);
+ strbuf_init(&directory, 0);
+
+ for (j = 0; j < dir.nr; ++j) {
+ struct dir_entry *ent = dir.entries[j];
+ int len, pos, specs;
+ struct cache_entry *ce;
+ struct stat st;
+ char *seen;
+
+ /*
+ * Remove the '/' at the end that directory
+ * walking adds for directory entries.
+ */
+ len = ent->len;
+ if (len && ent->name[len-1] == '/')
+ len--;
+ pos = cache_name_pos(ent->name, len);
+ if (0 <= pos)
+ continue; /* exact match */
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == len &&
+ !memcmp(ce->name, ent->name, len))
+ continue; /* Yup, this one exists unmerged */
+ }
+
+ if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
+ int matched_path = 0;
+ strbuf_addstr(&directory, ent->name);
+ if (pathspec) {
+ for (specs =0; pathspec[specs]; ++specs)
+ /* nothing */;
+ seen = xcalloc(specs, 1);
+ /* Check if directory was explictly passed as
+ * pathspec. If so we want to remove it */
+ if (match_pathspec(pathspec, ent->name, ent->len,
+ baselen, seen))
+ matched_path = 1;
+ free(seen);
+ }
+ if (show_only && (remove_directories || matched_path)) {
+ printf("Would remove %s\n", directory.buf);
+ } else if (quiet && (remove_directories || matched_path)) {
+ remove_dir_recursively(&directory, 0);
+ } else if (remove_directories || matched_path) {
+ printf("Removing %s\n", directory.buf);
+ remove_dir_recursively(&directory, 0);
+ } else if (show_only) {
+ printf("Would not remove %s\n", directory.buf);
+ } else {
+ printf("Not removing %s\n", directory.buf);
+ }
+ strbuf_reset(&directory);
+ } else {
+ if (show_only) {
+ printf("Would remove %s\n", ent->name);
+ continue;
+ } else if (!quiet) {
+ printf("Removing %s\n", ent->name);
+ }
+ unlink(ent->name);
+ }
+ }
+
+ strbuf_release(&directory);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 525107f..5476a92 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,6 +24,7 @@ extern int cmd_check_attr(int argc, const char **argv, const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char *prefix);
extern int cmd_cherry(int argc, const char **argv, const char *prefix);
extern int cmd_cherry_pick(int argc, const char **argv, const char *prefix);
+extern int cmd_clean(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);
extern int cmd_count_objects(int argc, const char **argv, const char *prefix);
extern int cmd_describe(int argc, const char **argv, const char *prefix);
diff --git a/git-clean.sh b/contrib/examples/git-clean.sh
similarity index 100%
rename from git-clean.sh
rename to contrib/examples/git-clean.sh
diff --git a/git.c b/git.c
index 204a6f7..3fa8e4d 100644
--- a/git.c
+++ b/git.c
@@ -293,6 +293,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
{ "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "clean", cmd_clean, RUN_SETUP | NEED_WORK_TREE },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "config", cmd_config },
{ "count-objects", cmd_count_objects, RUN_SETUP },
--
1.5.3.GIT
^ permalink raw reply related
* Re: Deprecate git-fetch-pack?
From: Ask Bjørn Hansen @ 2007-11-12 1:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Theodore Tso, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711112247350.4362@racer.site>
On Nov 11, 2007, at 2:50 PM, Johannes Schindelin wrote:
> I beg to differ. The biggest problem with a new user seeing all those
> completions is that this user is scared.
How about moving the plumbing commands to libexec/ or some such? (Or
libexec/git/ - then you can put it back in your PATH if you really
want easy access to run them directly).
Maybe I'm being pedantic, but it's not about "scaring the user" --
it's simply that the "visible commands" is part of the UI and having
it unnecessarily complex (many more commands than the user needs to
learn) makes it much harder to get started using git. It's a very
practical thing.
I strongly second Theodore's suggestions for cleaning up some of the
help texts, too.
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: Is it possible for git to remember the options preference for "git log"?
From: Daniel Barkalow @ 2007-11-12 1:02 UTC (permalink / raw)
To: eric miao; +Cc: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
On Mon, 12 Nov 2007, eric miao wrote:
> All,
>
> Most of the time I'm using git-log for inspecting a brief history
> and insert/remove/modify commits between, which I have to
> type "git log --abbrev-commit --pretty=oneline" every time. Is
> it possible for git to remember this command line options
> preference?
>
> And no, I don't really want to use shell's alias or something
> else, I was just used to type "git xxx" :-)
Git has a built-in alias mechanism, which is probably what you want. If
you put in your config file:
[alias]
xxx = log --abbrev-commit --pretty=online
then you can type "git xxx" and it'll do what you want. Changing the
default behavior of the basic commands is looked down on because there are
scripts that use them to get their input, and those scripts have
particular formats they expect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <20071111235819.GB7392@thunk.org>
Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
"git help" is less intimidating.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
generate-cmdlist.sh | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 17df47b..1ba27ec 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -11,12 +11,9 @@ static struct cmdname_help common_cmds[] = {"
sort <<\EOF |
add
-apply
-archive
bisect
branch
checkout
-cherry-pick
clone
commit
diff
@@ -26,15 +23,12 @@ init
log
merge
mv
-prune
pull
push
rebase
reset
-revert
rm
show
-show-branch
status
tag
EOF
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* [PATCH,RFC 2/2] Remove hint to use "git help -a"
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
The newbie user will run away screaming when they see all possible
commands. The expert user will already know about the -a option from
reading the git man page.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
help.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..f539b80 100644
--- a/help.c
+++ b/help.c
@@ -162,7 +162,6 @@ static void list_common_cmds_help(void)
mput_char(' ', longest - strlen(common_cmds[i].name));
puts(common_cmds[i].help);
}
- puts("(use 'git help -a' to get a list of all installed git commands)");
}
static void show_man_page(const char *git_cmd)
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* Re: Is it possible for git to remember the options preference for "git log"?
From: Jakub Narebski @ 2007-11-12 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
eric miao wrote:
> Most of the time I'm using git-log for inspecting a brief history
> and insert/remove/modify commits between, which I have to
> type "git log --abbrev-commit --pretty=oneline" every time. Is
> it possible for git to remember this command line options
> preference?
>
> And no, I don't really want to use shell's alias or something
> else, I was just used to type "git xxx" :-)
You can always use (global) _git_ alias ;-p
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
From: Adam J. Richter @ 2007-11-12 0:39 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Hi Catalin,
I want to report two problems, at least one of which may be
due to some other environmental change such as a git upgrade.
The first bug is less perhaps serious, and perhaps not new,
but it's easier to describe this one first.
I have a small stack of patches in stgit for a source tree.
One of these patches modified a yacc grammer "parser.y", which, in
turn, causes the yacc files y.tab.{c,h} to be rebuilt. y.tab.{c,h}
are included in the source tree for build environments that lack yacc.
Sometimes my attempts to check out a new source tree and rebuild would
result in y.tab.{c,h} not being built, probably due to 1 second
timestamp granularity somewhere (the ext3 file system, make, git,
stgit, whatever), probably not stgit's fault.
So, did repeated "stg pop" commands to get to the point where
the change to parser.y is applied, did an "stg new", deleted
y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh". So far, so
good. Then I tried to do an "stg push" to re-integrate the next
patch, and I got a complaint from stgit about some git object not
existing. This patch did not touch y.tab.{c,h} or any files touched
by any of the other patches I had pushed on. I don't know stgit well
enough to recover from the situation gracefully, so I just wiped the
stgit tree and tried to apply the patches again, which brings me to
bug #2.
I made a new stgit tree of the program (bash), pulling from a
local git tree, and attempted to apply the first patch, with usuaul
"stg new...make changes...stg refresh". Then stg refresh informed
printed this message ("invalid_multibyte_sequence" is the name of the
new patch):
Checking for changes in the working directory ... done
Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)
"stg diff" still shows the changes as if I had not done an
"stg refresh". Obviously, stg commits have worked for me in the past.
I suspect that a recent upgrade of git or other system software
triggered the break.
I'll try to pass along what I find if I start debugging this
problem, but I probably won't be able to get into that immediately, so
I am just passing this data along for now in the hopes that it may be
helpful for someone else.
Adam
^ permalink raw reply
* [PATCH] replace reference to git-rm with git-reset in git-commit doc
From: Jing Xue @ 2007-11-12 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <20071111140518.GA3847@efreet.light.src>
On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:
>
> The message in git-commit suggesting to use 'git rm --cached' to unstage is
> just plain wrong. It really should mention 'git reset'.
Hopefully this makes it clearer. I have also updated the faq in wiki to
clarify.
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-add.txt | 1 +
Documentation/git-commit.txt | 12 ++++++------
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -224,6 +224,7 @@ See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
+gitlink:git-reset[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..7c63dd8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,12 +154,12 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1]. Removal
-of a file is staged with gitlink:git-rm[1]. After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far. This is the most basic form of the
-command. An example:
+called the "index" with gitlink:git-add[1]. File changes
+previously staged can be removed with `git-reset
+HEAD -- <file>`. After building the state to be committed
+incrementally with these commands, `git commit` (without any
+pathname parameter) is used to record what has been staged so
+far. This is the most basic form of the command. An example:
------------
$ edit hello.c
^ 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