* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Junio C Hamano @ 2008-07-03 8:34 UTC (permalink / raw)
To: Eric Raible; +Cc: git, Johannes.Schindelin
In-Reply-To: <279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com>
"Eric Raible" <raible@gmail.com> writes:
> % git rev-parse ":/object name":sha1_name.c
> :/object name:sha1_name.c
> fatal: ambiguous argument ':/object name:sha1_name.c': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> A quick look at int sha1_name.c:get_sha1() shows that it doesn't
> even try to make this work. Is this worth fixing?
Is there anything to fix? In that example, you are looking for a commit
that talks about "object name:sha1_name.c" in the comment.
^ permalink raw reply
* Re: [RFC/PATCH 1/4] Add git-sequencer shell prototype
From: Johannes Schindelin @ 2008-07-03 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, git, Daniel Barkalow, Christian Couder
In-Reply-To: <7vbq1f68rh.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
>
> > git sequencer is planned as a backend for user scripts
> > that execute a sequence of git instructions and perhaps
> > need manual intervention, for example git-rebase or git-am.
>
> ...
> > +output () {
> > + case "$VERBOSE" in
> > + 0)
> > + "$@" >/dev/null
> > + ;;
> > + 1)
> > + output=$("$@" 2>&1 )
> > + status=$?
> > + test $status -ne 0 && printf '%s\n' "$output"
> > + return $status
> > + ;;
> > + 2)
> > + "$@"
> > + ;;
> > + esac
> > +}
>
> Perhaps misnamed? This feels more like "do" or "perform" or "run".
My fault. I like "perform".
> > +require_clean_work_tree () {
> > + # test if working tree is dirty
> > + git rev-parse --verify HEAD >/dev/null &&
> > + git update-index --ignore-submodules --refresh &&
> > + git diff-files --quiet --ignore-submodules &&
> > + git diff-index --cached --quiet HEAD --ignore-submodules -- ||
> > + die 'Working tree is dirty'
> > +}
>
> When is it necessary to ignore submodules and why?
Submodules are not updated by checkout. Indeed, the _only_ Git command
that actually changes the state of a submodule is "git submodule update".
Therefore, it is wrong to assume that rebase/am/whatever works with
submodules as far as the working directory is concerned. Updating
submodules with any Git command other than "git submodule update" is a
_pure_ index operation.
Of course, that means that if you use rebase -i's "edit" command to go
back to a certain revision, edit that, and want to test, it is _your_
responsibility to make sure that the submodules are at their correct
revision.
> Are there cases where submodules should not be ignored?
With above reasoning, it would always be wrong for sequencer to require
the submodules to be up-to-date.
> > +LAST_COUNT=
> > +mark_action_done () {
> > + sed -e 1q <"$TODO" >>"$DONE"
> > + sed -e 1d <"$TODO" >"$TODO.new"
> > + mv -f "$TODO.new" "$TODO"
> > + if test "$VERBOSE" -gt 0
> > + then
> > + count=$(grep -c '^[^#]' <"$DONE")
> > + total=$(expr "$count" + "$(grep -c '^[^#]' <"$TODO")")
>
> Here we are not counting lines that are comments as insns (I am not
> complaining; just making a mental note).
As "count" and "total" are only used for the progress output, anything
else would not make sense.
> > + if test "$LAST_COUNT" != "$count"
> > + then
> > + LAST_COUNT="$count"
> > + test "$VERBOSE" -lt 1 ||
> > + printf 'Sequencing (%d/%d)\r' "$count" "$total"
> > + test "$VERBOSE" -lt 2 || echo
> > + fi
> > + fi
> > +}
> > +
> > +# Generate message, patch and author script files
> > +make_patch () {
> > + parent_sha1=$(git rev-parse --verify "$1"^) ||
> > + die "Cannot get patch for $1^"
> > + git diff-tree -p "$parent_sha1..$1" >"$PATCH"
>
> Could there be a case where we need/want to deal with a root commit
> without parents?
Yes. I had exactly that need a few days ago, where I wanted to import a
few zips, and rebase them on top of an existing branch (which was
generated in the same manner).
I worked around that limitation of rebase (actually, I only tried rebase
-i, come to think of it), by rewriting the first commit object, inserting
the "parent" line. "fast-export > a1; vi a1; fast-import < a1" can be so
much fun!
> > + test -f "$MSG" ||
> > + commit_message "$1" >"$MSG"
> > + test -f "$AUTHOR_SCRIPT" ||
> > + get_author_ident_from_commit "$1" >"$AUTHOR_SCRIPT"
> > +}
> > +
> > +# Generate a patch and die with "conflict" status code
> > +die_with_patch () {
> > + make_patch "$1"
> > + git rerere
> > + die_to_continue "$2"
> > +}
> > +
> > +restore () {
> > + git rerere clear
> > +
> > + HEADNAME=$(cat "$SEQ_DIR/head-name")
> > + HEAD=$(cat "$SEQ_DIR/head")
>
> Perhaps
>
> read HEADNAME <"$SEQ_DIR/head-name"
>
> provided if these values are $IFS safe?
Again, my fault (as this was most likely copied from rebase -i). All the
files written to $DOTEST in rebase -i should be $IFS safe.
> > + case $HEADNAME in
> > + refs/*)
> > + git symbolic-ref HEAD "$HEADNAME"
> > + ;;
> > + esac &&
> > + output git reset --hard "$HEAD"
> > +}
> > +
> > +has_action () {
> > + grep '^[^#]' "$1" >/dev/null
> > +}
> > +
> > +# Check if text file $1 contains a commit message
> > +has_message () {
> > + test -n "$(sed -n -e '/^Signed-off-by:/d;/^[^#]/p' <"$1")"
> > +}
>
> Makes one wonder if we would want to special case other kinds like
> "Acked-by:" as well...
I think this just mimicks "git commit".
> > +# Usage: pick_one (cherry-pick|revert) [-*|--edit] sha1
> > +pick_one () {
> > + what="$1"
> > + # we just assume that this is either cherry-pick or revert
> > + shift
> > +
> > + # check for fast-forward if no options are given
> > + if expr "x$1" : 'x[^-]' >/dev/null
> > + then
> > + test "$(git rev-parse --verify "$1^")" = \
> > + "$(git rev-parse --verify HEAD)" &&
> > + output git reset --hard "$1" &&
> > + return
> > + fi
> > + test "$1" != '--edit' -a "$what" = 'revert' &&
> > + what='revert --no-edit'
>
> This looks somewhat wrong.
>
> When the history looks like ---A---B and we are at A, cherry-picking B can
> be optimized to just advancing to B, but that optimization has a slight
> difference (or two) in the semantics.
>
> (1) The committer information would not record the user and time of the
> sequencer operation, which actually may be a good thing.
This is debatable. But I think you are correct, for all the same reasons
why a merge can result in a fast-forward.
> (2) When $what is revert, this codepath shouldn't be exercised, should
> it?
Yes.
> (3) If B is a merge, even if $what is pick, this codepath shouldn't be
> exercised, should it?
I think it should, again for the same reason why a merge can result in a
fast-forward.
> > +make_squash_message () {
> > + if test -f "$squash_msg"
> > + then
> > + count=$(($(sed -n -e 's/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p' \
> > + <"$squash_msg" | sed -n -e '$p')+1))
> > + echo "# This is a combination of $count commits."
> > + sed -e '1d' -e '2,/^./{
> > + /^$/d
> > + }' <"$squash_msg"
> > + else
> > + count=2
> > + echo '# This is a combination of 2 commits.'
> > + echo '# The first commit message is:'
> > + echo
> > + commit_message HEAD
> > + fi
> > + echo
> > + echo "# This is the $(nth_string "$count") commit message:"
> > + echo
> > + commit_message "$1"
> > +}
> > +
> > +make_squash_message_multiple () {
> > + echo '# This is a dummy to get the 0.' >"$squash_msg"
> > + for cur_sha1 in $(git rev-list --reverse "$sha1..HEAD")
> > + do
> > + make_squash_message "$cur_sha1" >"$MSG"
> > + cp "$MSG" "$squash_msg"
> > + done
> > +}
>
> Hmm, I know this is how rebase-i is written, but we should be able to do
> better than writing and flipping temporary times N times, shouldn't we?
Right, again my fault.
> > +peek_next_command () {
> > + sed -n -e '1s/ .*$//p' <"$TODO"
> > +}
>
> ... which could respond "the next command is '#' (comment)", so we are
> actively counting a comment as a step here. Does this contradict with the
> mental note we made earlier, and if so, does the discrepancy hurt us
> somewhere in this program?
Yes, this is wrong. it must be
sed -n -e '/^#/d' -e '1s .*$//p' < "$TODO"
> > +strategy_check () {
> > + case "$1" in
> > + resolve|recursive|octopus|ours|subtree|theirs)
> > + return
> > + ;;
> > + esac
> > + todo_warn "Strategy '$1' not known."
> > +}
>
> Hmm. Do we need to maintain list of available strategies here and then in
> git-merge separately?
I'd not check in sequencer for the strategy. Especially given that we
want to support user-written strategies in the future.
Ciao,
Dscho
^ permalink raw reply
* Re: PATCH: Allow ':/<oneline prefix>' notation to specify a specific file
From: Eric Raible @ 2008-07-03 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin, peff
On Thu, Jul 3, 2008 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> So when you have ":/A:B:C", you first try to look for string "A:B:C", and
> then when it fails try "A:B" and look for path C?
Exactly. And as you pointed out it doesn't break existing usage by design.
> (1) An obvious micro-optimization. Check if "A:B:C" is a rev, and if and
> only if it fails, run strrchr() to find fallback point;
Done. This version is more careful about return values as well.
> (2) When you do not find either "A:B:C" nor "A:B", perhaps try "A" and
> find "B:C" as a path in it? IOW, you may want to fallback more than
> once;
> (3) If you are given ":/A~20" or ":/A^2", perhaps you would want to do
> something similar?
I agree these are nice but get_sha1_oneline() is time-consuming as is
and I'm not familiar enough with the code to attempt a complete
refactorization.
And without refactoring get_sha1_oneline() would need to be called
repeated for each ~, ^, or : (working backward) until it succeeds.
I'll leave it to Johannes to refactor get_sha1_oneline to handle the
":/A~20" or ":/A^2" cases if he chooses to, as it's currently beyond
my git-fu.
An alternative suggested by Peff:
:/ should stop eating text at the first ':', and allow '\:' for
a literal colon and '\\' for a literal backslash.
is arguably better because it's completely unambiguous and allows
for a simpler implementation but it's not backwards compatible.
I'd be willing to come up with patch for that if people agree that
it's worth it.
Please note that the commit message uses the current subject,
so if this is applied it should be kept consistent.
- Eric
----- 8< -----
Although the rev-parse documentation claims that the tree-ish:path/to/file
syntax is applicable to all tree-ish forms this is not so when using the
:/ "oneline prefix" syntax introduced in v1.5.0.1-227-g28a4d94.
For instance, to see the file changed by this patch one could say:
git show ":/Allow ':/<oneline prefix>'":sha1_name.c
Note that this should but doesn't handle ~ and ^, so it will fail when
trying to show the parent of this commit message by using
git show ":/Allow ':/<oneline prefix>'"^
Signed-off-by: Eric Raible <raible@gmail.com>
---
sha1_name.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b0b2167..415b4ce 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -697,8 +697,20 @@ int get_sha1_with_mode(const char *name, unsigned
char *sha1, unsigned *mode)
int stage = 0;
struct cache_entry *ce;
int pos;
- if (namelen > 2 && name[1] == '/')
- return get_sha1_oneline(name + 2, sha1);
+ if (namelen > 2 && name[1] == '/') {
+ char *copy, *colon;
+ name += 2;
+ ret = get_sha1_oneline(name, sha1);
+ if (!ret || !(colon = strrchr(name, ':')))
+ return ret;
+ copy = xstrdup(name);
+ copy[colon - name] = '\0';
+ ret = get_sha1_oneline(copy, sha1);
+ if (!ret)
+ ret = get_tree_entry(sha1, colon+1, sha1, mode);
+ free(copy);
+ return ret;
+ }
if (namelen < 3 ||
name[2] != ':' ||
name[1] < '0' || '3' < name[1])
--
1.5.6.1.1356.g3885.dirty
^ permalink raw reply related
* Re: bug found (Re: git-fast-export SIGSEGV on solaris + backtrace)
From: Junio C Hamano @ 2008-07-03 8:30 UTC (permalink / raw)
To: namsh; +Cc: git, Pieter de Bie
In-Reply-To: <486C248E.4060205@gmail.com>
SungHyun Nam <goweol@gmail.com> writes:
> And the code says it:
> for (i = 0; i < idnums.size; ++i) {
> deco++;
> if (deco && deco->base && deco->base->type == 1) {
>
> The 'deco' should be post-incremented? or
> Checking code should be (i < idnums.size - 1)?
The variable "deco" is a pointer that walks over a hashtable from its
offset 0 to its end, so it can never be NULL (well, the code increments
before it tests the variable for NULLness, so it is clear that the test is
bogus).
What was I smoking when I applied df6a7ff (builtin-fast-export: Add
importing and exporting of revision marks, 2008-06-11), I have to
wonder...
Thanks for the fix.
^ permalink raw reply
* Non-inetd git-daemon hangs in syslog(3)/fclose(3) if --syslog --verbose accessing non-repositories
From: Brian Foster @ 2008-07-03 12:00 UTC (permalink / raw)
To: git
I've seen several reports of what seems to be the following
problem, but no fixes. I do not understand the root-cause.
I have found, however, what seems to be a work-around.
I'm starting v1.5.2.5 (the Kubuntu 7.10 package) git-daemon
(as a normal-user, *not* super-user) as:
export GIT_TRACE=/tmp/LOG-git-daemon
exec \
git daemon --detach --syslog --verbose --base-path=/pub/scm
The repositories being served are simple (non-bare) clones,
with nothing strange/weird. The remote machine (CentOS),
running a self-built un-modified v1.5.5, can access them Ok:
$ git ls-remote git://SERVER/repo
... works ...
$
However, an invalid path causes both the git-daemon and the
client to hang (I'm too impatient and do not know if either
times out):
$ git ls-remote git://SERVER/repo/garbage
... hangs ...
I can ^C the client, but the server is still hung, and will
not respond to *any* requests. I must kill the git-daemon.
The GIT_TRACE log's contents do not seem to be interesting.
The last entries in the syslog are:
git-daemon: [3705] Connection from <REMOTE>
git-daemon: [3705] Extended attributes (17 bytes) exist <...>
git-daemon: [3705] Request upload-pack for '/repo/garbage'
git-daemon: [3705] '/pub/scm/repo/garbage': unable to chdir or not a git archive
Annoyingly, strace(1)ing git-daemon causes the problem to
vanish! Everything then seems to be work as expected.
But now the syslog contains an additional, 5th, line:
git-daemon: [3705] Disconnected (with error)
(The "with error" is present only in the .../garbage case.)
Attaching to a hung git-daemon with strace shows that it's
hung in futex(2):
$ strace -p3705
Process 3705 attached - interrupt to quit
futex(0x2b502cbf3980, FUTEX_WAIT, 2, NULL <unfinished ...>
... hangs ...
Attaching to a hung git-daemon with gdb(1) results in the
following backtrace:
(gdb) where
#0 0x00002b502c97d1d8 in ?? () from /lib/libc.so.6
#1 0x00002b502c913698 in ?? () from /lib/libc.so.6
#2 0x00002b502c912960 in realloc () from /lib/libc.so.6
#3 0x00002b502c905eb4 in ?? () from /lib/libc.so.6
#4 0x00002b502c8fd897 in fclose () from /lib/libc.so.6
#5 0x00002b502c96d371 in __vsyslog_chk () from /lib/libc.so.6
#6 0x00002b502c96d8a0 in syslog () from /lib/libc.so.6
#7 0x0000000000403896 in ?? ()
#8 <signal handler called>
#9 0x00002b502c9373ab in fork () from /lib/libc.so.6
#10 0x0000000000404443 in ?? ()
#11 0x0000000000404c99 in ?? ()
#12 0x00002b502c8bab44 in __libc_start_main () from /lib/libc.so.6
#13 0x0000000000403179 in ?? ()
#14 0x00007fff7e63eab8 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)
It's fairly clear it's hung doing the syslog(3) of the (missing)
"Disconnected (with error)" message. A interesting point is the
SIGCHLD handler in (git-)daemon.c appears to have been called
before the parent's fork(2) returned. I presume there is a race
here, but admit I do not see it. This (broadly) makes sense; the
server is a Very Fast machine. And strace'ing slows things down.
The workaround is to omit --verbose and hence never try to syslog
the "Disconnected ..." message.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: finding deleted file names
From: Johannes Schindelin @ 2008-07-03 11:57 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0807021701m13b7adddv51537f4cf9d52533@mail.gmail.com>
Hi,
On Thu, 3 Jul 2008, Geoff Russell wrote:
> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a
> fatal error.
>
> fatal: bad object HEAD@{7 days ago}
Sorry, but you haven't grasped the concept of reflogs. The "@{...}" is
purely for the _local_ state.
So clearly, if you did not have the repo 7 days ago, "HEAD@{7.days.ago}"
does not exist.
In a distributed SCM, asking about a branch's state "7 days ago" is
ill-defined at best.
Hth,
Dscho
^ permalink raw reply
* Re: PATCH: allow ':/<oneline prefix>' notation to specify a specific file
From: Junio C Hamano @ 2008-07-03 9:20 UTC (permalink / raw)
To: Eric Raible; +Cc: Junio C Hamano, git, Johannes.Schindelin
In-Reply-To: <279b37b20807030152g13492d5dxf21367ab17719993@mail.gmail.com>
"Eric Raible" <raible@gmail.com> writes:
> This patch allows git show ":/PATCH: allow":sha1_name.c to show the
> change to the file changed by this patch.
> ...
> @@ -697,8 +698,18 @@ int get_sha1_with_mode(const char *name, unsigned
> char *sha1, unsigned *mode)
> int stage = 0;
> struct cache_entry *ce;
> int pos;
> - if (namelen > 2 && name[1] == '/')
> - return get_sha1_oneline(name + 2, sha1);
> + if (namelen > 2 && name[1] == '/') {
> + name += 2;
> + colon = strrchr(name, ':');
> + if (!get_sha1_oneline(name, sha1) || !colon)
> + return 0;
So when you have ":/A:B:C", you first try to look for string "A:B:C", and
then when it fails try "A:B" and look for path C? I think this fallback
makes sense, especially because this cannot break existing use for
positive lookup (it _can_ be called a regression if you are checking to
see if you have a commit that has A:B:C and you want the lookup to fail if
there is A:B that happens to have path C, but I do not think we would care
about that usage).
A few observations:
(1) An obvious micro-optimization. Check if "A:B:C" is a rev, and if and
only if it fails, run strrchr() to find fallback point;
(2) When you do not find either "A:B:C" nor "A:B", perhaps try "A" and
find "B:C" as a path in it? IOW, you may want to fallback more than
once;
(3) If you are given ":/A~20" or ":/A^2", perhaps you would want to do
something similar?
Other than that, I like what the patch is trying to do.
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Jeff King @ 2008-07-03 11:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20080703021541.GK18147@mail.rocksoft.com>
On Thu, Jul 03, 2008 at 11:45:41AM +0930, Tim Stoakes wrote:
> > Jeff had a patch to allow boolean configuration variable "pager.<command>"
> > to override the built-in pager settings during 1.5.6 cycle, and I think it
> > was a reasonable approach to take. People who want to page output from
> > git-status can then set "pager.status = true" in their configuration (and
> > then we can revert c8af1de (make git-status use a pager, 2008-04-23)).
> > Alternatively we could keep the current status-quo for the default, and
> > people can say "pager.status = false" in their configuration.
>
> I'd really like to see this. Setting core.pager to `less -FSRX` or
> similar is not useful for me - I *want* to have -X for eg. `git diff`,
> but I don't want paging at all for status.
OK, here is a revised patch that actually passes the tests. I'm not
incredibly happy with it (see the caveats below), but I think this is
the best we can do without major surgery on the git_dir setup (there
seems to be some nasty interaction between setup_git_env and
setup_git_directory, but several attempts at obvious fixes have left me
pulling my hair out).
-- >8 --
allow per-command pager config
There is great debate over whether some commands should set
up a pager automatically. This patch allows individuals to
set their own pager preferences for each command, overriding
the default. For example, to disable the pager for git
status:
git config pager.status false
If "--pager" or "--no-pager" is specified on the command
line, it takes precedence over the config option.
There are two caveats:
- you can turn on the pager for plumbing commands.
Combined with "core.pager = always", this will probably
break a lot of things. Don't do it.
- This only works for builtin commands. The reason is
somewhat complex:
Calling git_config before we do setup_git_directory
has bad side effects, because it wants to know where
the git_dir is to find ".git/config". Unfortunately,
we cannot call setup_git_directory indiscriminately,
because some builtins (like "init") break if we do.
For builtins, this is OK, since we can just wait until
after we call setup_git_directory. But for aliases, we
don't know until we expand (recursively) which command
we're doing. This should not be a huge problem for
aliases, which can simply use "--pager" or "--no-pager"
in the alias as appropriate.
For external commands, however, we don't know we even
have an external command until we exec it, and by then
it is too late to check the config.
An alternative approach would be to have a config mode
where we don't bother looking at .git/config, but only
at the user and system config files. This would make the
behavior consistent across builtins, aliases, and
external commands, at the cost of not allowing per-repo
pager config for at all.
---
git.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 22ac522..426a17f 100644
--- a/git.c
+++ b/git.c
@@ -9,6 +9,43 @@ const char git_usage_string[] =
const char git_more_info_string[] =
"See 'git help COMMAND' for more information on a specific command.";
+static int use_pager = -1;
+struct pager_config {
+ const char *cmd;
+ int val;
+};
+
+static int pager_command_config(const char *var, const char *value, void *data)
+{
+ struct pager_config *c = data;
+ if (!prefixcmp(var, "pager.") && !strcmp(var + 6, c->cmd))
+ c->val = git_config_bool(var, value);
+ return 0;
+}
+
+/* returns 0 for "no pager", 1 for "use pager", and -1 for "not specified" */
+int check_pager_config(const char *cmd)
+{
+ struct pager_config c;
+ c.cmd = cmd;
+ c.val = -1;
+ git_config(pager_command_config, &c);
+ return c.val;
+}
+
+static void commit_pager_choice(void) {
+ switch (use_pager) {
+ case 0:
+ setenv("GIT_PAGER", "cat", 1);
+ break;
+ case 1:
+ setup_pager();
+ break;
+ default:
+ break;
+ }
+}
+
static int handle_options(const char*** argv, int* argc, int* envchanged)
{
int handled = 0;
@@ -38,9 +75,9 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
exit(0);
}
} else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
- setup_pager();
+ use_pager = 1;
} else if (!strcmp(cmd, "--no-pager")) {
- setenv("GIT_PAGER", "cat", 1);
+ use_pager = 0;
if (envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
@@ -242,8 +279,13 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
prefix = NULL;
if (p->option & RUN_SETUP)
prefix = setup_git_directory();
- if (p->option & USE_PAGER)
- setup_pager();
+
+ if (use_pager == -1 && p->option & RUN_SETUP)
+ use_pager = check_pager_config(p->cmd);
+ if (use_pager == -1 && p->option & USE_PAGER)
+ use_pager = 1;
+ commit_pager_choice();
+
if (p->option & NEED_WORK_TREE)
setup_work_tree();
@@ -453,6 +495,7 @@ int main(int argc, const char **argv)
argv++;
argc--;
handle_options(&argv, &argc, NULL);
+ commit_pager_choice();
if (argc > 0) {
if (!prefixcmp(argv[0], "--"))
argv[0] += 2;
--
1.5.6.1.158.g8cb5.dirty
^ permalink raw reply related
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Johannes Schindelin @ 2008-07-03 11:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano, Edward Z. Yang
In-Reply-To: <200807022104.20146.johannes.sixt@telecom.at>
Hi,
On Wed, 2 Jul 2008, Johannes Sixt wrote:
> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Edward Z. Yang <edwardzyang@thewritingpot.com>
> >
> > PuTTY requires -P while OpenSSH requires -p; if plink is detected
> > as GIT_SSH, use the alternate flag.
> >
> > Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> > connect.c | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/connect.c b/connect.c
> > index 574f42f..0d007f3 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> > char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
> > if (protocol == PROTO_SSH) {
> > const char *ssh = getenv("GIT_SSH");
> > + int putty = ssh && strstr(ssh, "plink");
> > if (!ssh) ssh = "ssh";
> >
> > *arg++ = ssh;
> > if (port) {
> > - *arg++ = "-p";
> > + /* P is for PuTTY, p is for OpenSSH */
> > + *arg++ = putty ? "-P" : "-p";
> > *arg++ = port;
> > }
> > *arg++ = host;
>
> What about installing a wrapper script, plinkssh, that does this:
>
> #!/bin/bash
>
> if test "$1" = -p; then
> port="-P $2"
> shift; shift
> fi
>
> exec plink $port "$@"
>
> and require plink users to set GIT_SSH=plinkssh?
I like that better than this special-casing of plink.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
From: Johannes Schindelin @ 2008-07-03 11:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano
In-Reply-To: <200807022046.28141.johannes.sixt@telecom.at>
Hi,
On Wed, 2 Jul 2008, Johannes Sixt wrote:
> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > On Windows, gpg outputs CR/LF signatures. But since the tag
> > messages are already stripped of the CR by stripspace(), it is
> > arguably nicer to do the same for the tag signature. Actually,
> > this patch does not look for CR/LF, but strips all CRs
> > from the signature.
> >
> > [ spr: ported code to use strbuf ]
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> > builtin-tag.c | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/builtin-tag.c b/builtin-tag.c
> > index e675206..77977ba 100644
> > --- a/builtin-tag.c
> > +++ b/builtin-tag.c
> > @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
> > if (finish_command(&gpg) || !len || len < 0)
> > return error("gpg failed to sign the tag");
> >
> > +#ifdef __MINGW32__
> > + /* strip CR from the line endings */
> > + {
> > + int i, j;
> > + for (i = j = 0; i < buffer->len; i++)
> > + if (buffer->buf[i] != '\r') {
> > + if (i != j)
> > + buffer->buf[j] = buffer->buf[i];
> > + j++;
> > + }
> > + strbuf_setlen(buffer, j);
> > + }
> > +#endif
> > +
> > return 0;
> > }
>
> Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It
> shouldn't hurt on Unix anyway.
I agree, and I would even like to refactor this into its own function.
Probably even move it to strbuf.[ch].
Ciao,
Dscho
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-03 7:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20080703002117.GH12567@machine.or.cz>
Petr Baudis wrote:
>On Wed, Jul 02, 2008 at 07:32:03PM +0200, Stephen R. van den Berg wrote:
>> Also, the graft mechanism specifically is intended as a temporary
>> solution until one uses filter-branch to "finalise" the result into a
>> proper repository which becomes cloneable.
>Grafts are _much_ older than filter-branch and I'm not sure where did
>you get this idea; do we claim that in any documentation?
Not in direct documentation, but it is what breaths down from posts on
the mailinglist like:
http://kerneltrap.org/mailarchive/git/2008/6/10/2085624
Jakub Narebski:
>Then if possible use git-filter-branch to make history recorded in
>grafts file permanent...
Petr Baudis wrote:
>There's nothing ugly or necessarily temporary about grafts. One example
>of completely valid usage is adding previous history of a project to it
>later.
>First, you don't need to carry around all the archived baggage you are
>probably rarely going to access anyway if you don't need to; changing a
>VCS is ideal cutoff point.
That depends on the project, of course, and is not a valid statement in
general. Part of the charm of full history is that git-blame and
git-bisect work, at arbitrary points in the past.
>Second, you don't need to worry about doing perfect conversion at the
>moment of the switch.
Well, you do, if you intend to make it cloneable.
>Third, even if you think you have done it perfectly, it will turn out
>later that something is wrong anyway.
Not necessarily. I have automated the checkout-verification-process which
basically checks out every revision from the respective old repository
and binary-compares it with the corresponding revision in the git
repository. This ensures a full binary match across the board.
With respect to historical merges, I agree, those might not be
completely correctly grafted, but the level of correctness can be
determined at will, and once we achieve somewhere around 99% accuracy,
we consider it done (for this project).
>Fourth, it may not be actually _clear_ what the canonical history should
>be.
That depends on the project. In my project it *is* clear, so this point
doesn't make any difference.
--
Sincerely,
Stephen R. van den Berg.
This is a day for firm decisions! Or is it?
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: complicate example of "man git-command"
From: Junio C Hamano @ 2008-07-03 7:44 UTC (permalink / raw)
To: Christian Couder
Cc: J. Bruce Fields, Jonathan Nieder, git, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <200807030806.37771.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Anyway if we want to get there, perhaps we should use "git help svn" above
> instead of "man git-svn". (Yeah "git help help" might be confusing at
> first.)
I do not particularly like advocating "git help" too strongly like that.
I prefer to keep the user perception of "git" to be just "one of the
programs, nothing special".
If you want to learn about "cat", you say "man cat". If you want to learn
about git, you say "man git", and while you *can* say "git help", the
point is you do *not* have to. You do not have to run "git" to learn
about it.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Johannes Sixt @ 2008-07-03 7:42 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Dmitry Potapov, git
In-Reply-To: <20080703073041.GA28566@cuci.nl>
Stephen R. van den Berg schrieb:
> Actually, ripple-through changes are rare. In the current project it
> seems I need exactly one, but it's buried deep in the past (sadly).
> The reason why I need it, is to make sure that git-bisect will work for
> any revision in the past (i.e. the tree contained/contains some
> too-clever-for-their-own-good $Revision$-expansion dependencies)
But you do know that you don't need to apply the change *now*; you can
apply it at bisect-time? Unless you expect you or your mere mortal
coworkers are going to do dozens of bisects into that part of the history,
I wouldn't change history *like*this*. But of course, I don't understand
the circumstances enough, so... just my 2 cents.
-- Hannes
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-03 7:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Dmitry Potapov, git
In-Reply-To: <486C6B8E.5040202@viscovery.net>
Johannes Sixt wrote:
>Stephen R. van den Berg schrieb:
>> Dmitry Potapov wrote:
>>> On second thought, it may be not necessary. You can extract an old commit
>>> object, edit it, put it into Git with a new SHA1, and then use the graft file to
>>> replace all references from an old to a new one. And you will be able to see
>>> changes immediately in gitk.
>> Hmmmm, interesting thought. That just might solve my problem.
>I don't think it would.
>You want to apply a patch through a part of the history. To do that, it is
>not sufficient to apply the patch to only one commit/tree and then fake
>parenthood of its child commits. You still need to apply the patch to all
>children.
I am aware of that.
There are actually two common cases:
- Historical changes which are confined and don't ripple through. The
above solution works just fine for that.
- Ripple-through changes. They indeed need to be applied to every tree
in the first-parent chain. Even though this is going to take a
considerable amount of time, there still are certain advantages to
doing this using the method described above:
+ You can apply the patch to every commit/tree "interactively" if you want.
(Yes, I know, git-sequencer supports this one as well, but not the
next point).
+ You can view the change at any point in time (including in relation to the
tree that follows it), right after making the amendments (without letting
it ripple through to the end).
+ The ripple-through does not need to be performed in topological order,
i.e. eventually you'll have to touch everything, but you can do it
in the order you see fit (whatever is most efficient to work on).
+ If, at some point during the ripple-through process, you find out
that you forgot some change(s), you can abort or restart the
ripple-through without having spent all that time waiting for a
full-ripple-through.
Actually, ripple-through changes are rare. In the current project it
seems I need exactly one, but it's buried deep in the past (sadly).
The reason why I need it, is to make sure that git-bisect will work for
any revision in the past (i.e. the tree contained/contains some
too-clever-for-their-own-good $Revision$-expansion dependencies)
--
Sincerely,
Stephen R. van den Berg.
This is a day for firm decisions! Or is it?
^ permalink raw reply
* OT: Re: [PATCH 08/15] gitdiffcore(7): fix awkward wording
From: Jonathan Nieder @ 2008-07-03 6:37 UTC (permalink / raw)
To: Jonathan Nieder, Junio C Hamano; +Cc: git, Chris Shoemaker
> The phrase "diff outputs" sounds awkward to my ear (I think
> "output" is meant to be used as a substantive noun.)
Ack! that phrase made no sense. If you know what I meant and
what it's called, I'd like to know :)
Thanks,
Jonathan
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Christian Couder @ 2008-07-03 6:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jan Engelhardt, Linux Kernel, Git Mailing List
In-Reply-To: <486849C0.7050703@garzik.org>
Hi,
Le lundi 30 juin 2008, Jeff Garzik a écrit :
> Jan Engelhardt wrote:
> > On Dec 23 2007 06:13, Jeff Garzik wrote:
> >> Another year, another update! :)
> >>
> >> The kernel hacker's guide to git has received some updates:
> >>
> >> http://linux.yyz.us/git-howto.html
May I suggest adding some stuff about "git bisect", or at least links to
other documentation about it, in this guide?
Especially, you may want to add an example about how to automate testing
using "git bisect run" as you suggest other to do that:
http://www.ussg.iu.edu/hypermail/linux/kernel/0804.1/0633.html
Thanks in advance,
Christian.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-03 6:05 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Dmitry Potapov, git, Mike Hommey, Michael J Gruber
In-Reply-To: <20080702234644.GC21297@leksak.fem-net>
Stephan Beyer wrote:
>On Thu, Jul 03, 2008 at 12:42:30AM +0400, Dmitry Potapov wrote:
>> On Wed, Jul 2, 2008 at 11:31 PM, Stephan Beyer <s-beyer@gmx.net> wrote:
>> > I wonder if grafts can be used in combination with sequencer in such a
>> > way that you rewrite foo~20000..foo~19950 and then fake the parents of
>> > foo~19949 to be the rewritten once.
>> I don't think it is a good idea. During the normal work you should never
>> use grafts.
>I have written this in the context that Stephen only changes some commits
>from a long time ago (foo~20000) and then I showed a way how to avoid that
>sequencer rewrites the rest which takes so long.
>This is not related to "normal work", but to Stephen's use case (if I
>got it right).
You got it right.
>What I've meant, was:
>Instead of faking a lot of parents, changes and even merges using an
>extended grafts file, he could rewrite some patches - which can be fast -
>and then use _only one_ graft to change the parent to the changed and
>rewritten commit.
>This can be done iteratively and seems to be a good agreement in speed
>and reliability.
Indeed.
--
Sincerely,
Stephen R. van den Berg.
This is a day for firm decisions! Or is it?
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: complicate example of "man git-command"
From: Christian Couder @ 2008-07-03 6:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Jonathan Nieder, git, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <7vmyl1kvn6.fsf@gitster.siamese.dyndns.org>
Le mercredi 2 juillet 2008, Junio C Hamano a écrit :
>
> E.g. a typical command description may go like this:
>
> To propagate the changes you made back to the original subversion
> repository, you would use 'git-svn dcommit' command. It does
> these things (long description here). Some examples:
We might kill 2 birds with a single stone by describing "git help" instead
of "git svn" (that the user may never use).
> ------------
> $ ... some example command sequence ...
> $ git svn dcommit
> ------------
>
> For full details, type:
>
> ------------
> $ man git-svn
> ------------
I saw that in another thread "git help" is also being ported to Windows and
I wonder if we want the tutorial to be usable as is by people on Windows
too.
I mean what if people on Windows launch "git help tutorial"? Should they see
nothing or a tutorial for *nix or a special version of the tutorial for
Windows or a tutorial that works everywhere? I think the latter would be
best but I wonder if it is possible.
Anyway if we want to get there, perhaps we should use "git help svn" above
instead of "man git-svn". (Yeah "git help help" might be confusing at
first.)
Thanks,
Christian.
^ permalink raw reply
* [PATCH 14/15] manpages: italicize git subcommand names (which were in teletype font)
From: Jonathan Nieder @ 2008-07-03 5:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields, Eric Wong, Johannes Schindelin
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
Italicize those git subcommand names already in teletype we missed.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/config.txt | 8 ++++----
Documentation/git-svn.txt | 2 +-
Documentation/gitcore-tutorial.txt | 6 +++---
Documentation/gitcvs-migration.txt | 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b431747..a7071df 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -118,8 +118,8 @@ core.fileMode::
See linkgit:git-update-index[1]. True by default.
core.quotepath::
- The commands that output paths (e.g. `ls-files`,
- `diff`), when not given the `-z` option, will quote
+ The commands that output paths (e.g. 'ls-files',
+ 'diff'), when not given the `-z` option, will quote
"unusual" characters in the pathname by enclosing the
pathname in a double-quote pair and with backslashes the
same way strings in C source code are quoted. If this
@@ -557,7 +557,7 @@ diff.autorefreshindex::
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
affects only 'git-diff' Porcelain, and not lower level
- `diff` commands, such as 'git-diff-files'.
+ 'diff' commands, such as 'git-diff-files'.
diff.external::
If this config variable is set, diff generation is not
@@ -636,7 +636,7 @@ gc.packrefs::
prevent `git pack-refs` from being run from 'git-gc'.
gc.pruneexpire::
- When 'git-gc' is run, it will call `prune --expire 2.weeks.ago`.
+ When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
Override the grace period with this config variable.
gc.reflogexpire::
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index dc5b8f6..e7c0f1c 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -551,7 +551,7 @@ CAVEATS
For the sake of simplicity and interoperating with a less-capable system
(SVN), it is recommended that all 'git-svn' users clone, fetch and dcommit
-directly from the SVN server, and avoid all 'git-clone'/`pull`/`merge`/`push`
+directly from the SVN server, and avoid all 'git-clone'/'pull'/'merge'/'push'
operations between git repositories and branches. The recommended
method of exchanging code between git branches and users is
'git-format-patch' and 'git-am', or just 'dcommit'ing to the SVN repository.
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 5acdeb7..dd6a268 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -235,7 +235,7 @@ $ git diff-files
------------
Oops. That wasn't very readable. It just spit out its own internal
-version of a `diff`, but that internal version really just tells you
+version of a 'diff', but that internal version really just tells you
that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
@@ -468,7 +468,7 @@ Inspecting Changes
While creating changes is useful, it's even more useful if you can tell
later what changed. The most useful command for this is another of the
-`diff` family, namely 'git-diff-tree'.
+'diff' family, namely 'git-diff-tree'.
'git-diff-tree' can be given two arbitrary trees, and it will tell you the
differences between them. Perhaps even more commonly, though, you can
@@ -1006,7 +1006,7 @@ the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
You can run `gitk \--all` again to see how the commit ancestry
-looks like, or run `show-branch`, which tells you this.
+looks like, or run 'show-branch', which tells you this.
------------------------------------------------
$ git show-branch master mybranch
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 2737d10..2eb6972 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -46,7 +46,7 @@ them first before running git pull.
[NOTE]
================================
-The `pull` command knows where to get updates from because of certain
+The 'pull' command knows where to get updates from because of certain
configuration variables that were set by the first 'git-clone'
command; see `git config -l` and the linkgit:git-config[1] man
page for details.
@@ -67,7 +67,7 @@ push again.
In the 'git-push' command above we specify the name of the remote branch
to update (`master`). If we leave that out, 'git-push' tries to update
any branches in the remote repository that have the same name as a branch
-in the local repository. So the last `push` can be done with either of:
+in the local repository. So the last 'push' can be done with either of:
------------
$ git push origin
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 13/15] manpages: italicize nongit command names (if they are in teletype font)
From: Jonathan Nieder @ 2008-07-03 5:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Sven Verdoolaege, Martin Langhoff, Jon Loeliger,
Johannes Schindelin, J. Bruce Fields
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
Some manual pages use teletype font to set command names. We
change them to use italics, instead. This creates a visual
distinction between names of commands and command lines that
can be typed at the command line. It is also more consistent
with other man pages outside Git.
In this patch, the commands named are non-git commands like bash.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-apply.txt | 2 +-
Documentation/git-cvsserver.txt | 4 ++--
Documentation/git-fsck.txt | 2 +-
Documentation/git-merge-file.txt | 4 ++--
Documentation/git-merge-index.txt | 4 ++--
Documentation/git-rerere.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/gitattributes.txt | 6 +++---
Documentation/gitcore-tutorial.txt | 14 +++++++-------
Documentation/gitcvs-migration.txt | 4 ++--
Documentation/gitdiffcore.txt | 2 +-
12 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f82c2ce..ca60efd 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -121,7 +121,7 @@ discouraged.
--no-add::
When applying a patch, ignore additions made by the
patch. This can be used to extract the common part between
- two files by first running `diff` on them and applying
+ two files by first running 'diff' on them and applying
the result with this option, which would apply the
deletion part but not addition part.
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 1804701..2aacdc6 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -115,7 +115,7 @@ This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
variable. SSH users restricted to 'git-shell' don't need to override the default
with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
-'git-cvsserver' and pretends that the other end runs the real `cvs` better.
+'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
@@ -328,7 +328,7 @@ is left blank. But if `gitcvs.allbinary` is set to "guess", then
the correct '-k' mode will be guessed based on the contents of
the file.
-For best consistency with `cvs`, it is probably best to override the
+For best consistency with 'cvs', it is probably best to override the
defaults by setting `gitcvs.usecrlfattr` to true,
and `gitcvs.allbinary` to "guess".
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 524e0b1..d5a7647 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -87,7 +87,7 @@ sorted properly etc), but on the whole if 'git-fsck' is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
-(i.e., you can just remove them and do an `rsync` with some other site in
+(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 4ae4bdc..a11c475 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -42,8 +42,8 @@ lines from `<other-file>` respectively.
The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.
-'git-merge-file' is designed to be a minimal clone of RCS `merge`; that is, it
-implements all of RCS merge's functionality which is needed by
+'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
+implements all of RCS 'merge''s functionality which is needed by
linkgit:git[1].
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 5ebed57..ff088c5 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -47,9 +47,9 @@ A sample script called 'git-merge-one-file' is included in the
distribution.
ALERT ALERT ALERT! The git "merge object order" is different from the
-RCS `merge` program merge object order. In the above ordering, the
+RCS 'merge' program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
-`merge` is to have the original in the middle. Don't ask me why.
+'merge' is to have the original in the middle. Don't ask me why.
Examples:
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 666349d..678bfd3 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -45,7 +45,7 @@ will automatically invoke this command.
This displays diffs for the current state of the resolution. It is
useful for tracking what has changed while the user is resolving
conflicts. Additional arguments are passed directly to the system
-`diff` command installed in PATH.
+'diff' command installed in PATH.
'status'::
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index dd12335..dc5b8f6 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -565,7 +565,7 @@ branch.
'git-clone' does not clone branches under the refs/remotes/ hierarchy or
any 'git-svn' metadata, or config. So repositories created and managed with
-using 'git-svn' should use `rsync` for cloning, if cloning is to be done
+using 'git-svn' should use 'rsync' for cloning, if cloning is to be done
at all.
Since 'dcommit' uses rebase internally, any git branches you 'git-push' to
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 992a46d..4d54791 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -493,7 +493,7 @@ other
'GIT_SSH'::
If this environment variable is set then 'git-fetch'
and 'git-push' will use this command instead
- of `ssh` when they need to connect to a remote system.
+ of 'ssh' when they need to connect to a remote system.
The '$GIT_SSH' command will be given exactly two arguments:
the 'username@host' (or just 'host') from the URL and the
shell command to execute on that remote system.
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 0b53044..6a246eb 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -278,7 +278,7 @@ is prefixed with a line of the form:
The text is called 'hunk header', and by default a line that
begins with an alphabet, an underscore or a dollar sign is used,
-which matches what GNU `diff -p` output uses. This default
+which matches what GNU 'diff -p' output uses. This default
selection however is not suited for some contents, and you can
use customized pattern to make a selection.
@@ -322,7 +322,7 @@ and other programs such as `git revert` and `git cherry-pick`.
Set::
Built-in 3-way merge driver is used to merge the
- contents in a way similar to `merge` command of `RCS`
+ contents in a way similar to 'merge' command of `RCS`
suite. This is suitable for ordinary text files.
Unset::
@@ -426,7 +426,7 @@ Checking whitespace errors
^^^^^^^^^^^^
The `core.whitespace` configuration variable allows you to define what
-`diff` and `apply` should consider whitespace errors for all paths in
+'diff' and 'apply' should consider whitespace errors for all paths in
the project (See linkgit:git-config[1]). This attribute gives you finer
control per path.
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 3eba973..5acdeb7 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -61,7 +61,7 @@ Initialized empty Git repository in .git/
which is just git's way of saying that you haven't been doing anything
strange, and that it will have created a local `.git` directory setup for
your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
+inspect that with 'ls'. For your new empty project, it should show you
three entries, among other things:
- a file called `HEAD`, that has `ref: refs/heads/master` in it.
@@ -660,7 +660,7 @@ in the new repository to make sure that the index file is up-to-date.
Note that the second point is true even across machines. You can
duplicate a remote git repository with *any* regular copy mechanism, be it
-`scp`, `rsync` or `wget`.
+'scp', 'rsync' or 'wget'.
When copying a remote repository, you'll want to at a minimum update the
index cache when you do this, and especially with other peoples'
@@ -1066,9 +1066,9 @@ most efficient way to exchange git objects between repositories.
Local directory::
`/path/to/repo.git/`
+
-This transport is the same as SSH transport but uses `sh` to run
+This transport is the same as SSH transport but uses 'sh' to run
both ends on the local machine instead of running other end on
-the remote machine via `ssh`.
+the remote machine via 'ssh'.
git Native::
`git://remote.machine/path/to/repo.git/`
@@ -1275,8 +1275,8 @@ fatal: merge program failed
describe those three versions, and is responsible to leave the
merge results in the working tree.
It is a fairly straightforward shell script, and
-eventually calls `merge` program from RCS suite to perform a
-file-level 3-way merge. In this case, `merge` detects
+eventually calls 'merge' program from RCS suite to perform a
+file-level 3-way merge. In this case, 'merge' detects
conflicts, and the merge result with conflict marks is left in
the working tree.. This can be seen if you run `ls-files
--stage` again at this point:
@@ -1360,7 +1360,7 @@ program on the `$PATH`.
[NOTE]
Many installations of sshd do not invoke your shell as the login
shell when you directly run programs; what this means is that if
-your login shell is `bash`, only `.bashrc` is read and not
+your login shell is 'bash', only `.bashrc` is read and not
`.bash_profile`. As a workaround, make sure `.bashrc` sets up
`$PATH` so that you can run 'git-receive-pack' program.
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 41ad608..2737d10 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -34,7 +34,7 @@ $ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project
------------------------------------------------
-and hack away. The equivalent of `cvs update` is
+and hack away. The equivalent of 'cvs update' is
------------------------------------------------
$ git pull origin
@@ -60,7 +60,7 @@ $ git push origin master
------------------------------------------------
to "push" those commits to the shared repository. If someone else has
-updated the repository more recently, 'git-push', like `cvs commit`, will
+updated the repository more recently, 'git-push', like 'cvs commit', will
complain, in which case you must pull any changes before attempting the
push again.
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 84b95a4..2bdbc3d 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -14,7 +14,7 @@ DESCRIPTION
The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree'
can be told to manipulate differences they find in
-unconventional ways before showing `diff` output. The manipulation
+unconventional ways before showing 'diff' output. The manipulation
is collectively called "diffcore transformation". This short note
describes what they are and how to use them to produce 'diff' output
that is easier to understand than the conventional kind.
--
1.5.5.GIT
^ permalink raw reply related
* ':/<oneline prefix>' notation doesn't support full file syntax
From: Eric Raible @ 2008-07-03 5:42 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin
Although the rev-parse documentation claims that the
tree-ish:path/to/file syntax works is applicable, this is
not so when using the :/ "oneline prefix" syntax:
% git rev-parse v1.5.0.1-227-g28a4d94
28a4d940443806412effa246ecc7768a21553ec7
% git rev-parse ":/object name"
28a4d940443806412effa246ecc7768a21553ec7
% git rev-parse v1.5.0.1-227-g28a4d94:sha1_name.c
0781477a71ac4d76a1b8783868d6649cae7f8507
% git rev-parse ":/object name":sha1_name.c
:/object name:sha1_name.c
fatal: ambiguous argument ':/object name:sha1_name.c': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions
A quick look at int sha1_name.c:get_sha1() shows that it doesn't
even try to make this work. Is this worth fixing?
Or at least documenting?
- Eric
^ permalink raw reply
* [PATCH 08/15] gitdiffcore(7): fix awkward wording
From: Jonathan Nieder @ 2008-07-03 5:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Chris Shoemaker
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
The phrase "diff outputs" sounds awkward to my ear (I think
"output" is meant to be used as a substantive noun.)
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/gitdiffcore.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 0b7daed..1171b5c 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -16,8 +16,8 @@ The diff commands `git-diff-index`, `git-diff-files`, and `git-diff-tree`
can be told to manipulate differences they find in
unconventional ways before showing `diff` output. The manipulation
is collectively called "diffcore transformation". This short note
-describes what they are and how to use them to produce diff outputs
-that are easier to understand than the conventional kind.
+describes what they are and how to use them to produce diff output
+that is easier to understand than the conventional kind.
The chain of operation
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 06/15] Documentation: rewrap to prepare for "git-" vs "git " change
From: Jonathan Nieder @ 2008-07-03 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
Rewrap lines in preparation for added dashes.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/config.txt | 4 ++--
Documentation/user-manual.txt | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 52d01b8..498247a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -627,8 +627,8 @@ gc.autopacklimit::
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
- from the repository. Setting this to `true` lets `git
- gc` to run `git pack-refs`. Setting this to `false` tells
+ from the repository. Setting this to `true` lets `git gc`
+ to run `git pack-refs`. Setting this to `false` tells
`git gc` never to run `git pack-refs`. The default setting is
`notbare`. Enable it only when you know you do not have to
support such clients. The default setting will change to `true`
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index cbfc5d0..61cf30f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2443,8 +2443,8 @@ patches to the new mywork. The result will look like:
................................................
In the process, it may discover conflicts. In that case it will stop
-and allow you to fix the conflicts; after fixing conflicts, use "git
-add" to update the index with those contents, and then, instead of
+and allow you to fix the conflicts; after fixing conflicts, use "git add"
+to update the index with those contents, and then, instead of
running git-commit, just run
-------------------------------------------------
@@ -2700,8 +2700,8 @@ master branch. In more detail:
git fetch and fast-forwards
---------------------------
-In the previous example, when updating an existing branch, "git
-fetch" checks to make sure that the most recent commit on the remote
+In the previous example, when updating an existing branch, "git fetch"
+checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
commit. Git calls this process a <<fast-forwards,fast forward>>.
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 04/15] git(1): add comma
From: Jonathan Nieder @ 2008-07-03 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruces Fields
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index f9e4416..5f4d666 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -141,7 +141,7 @@ help ...'.
--exec-path::
Path to wherever your core git programs are installed.
This can also be controlled by setting the GIT_EXEC_PATH
- environment variable. If no path is given 'git' will print
+ environment variable. If no path is given, 'git' will print
the current setting and then exit.
-p::
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 01/15] git-format-patch(1): fix stray \ in output
From: Jonathan Nieder @ 2008-07-03 4:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder, Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0807022322380.16085@harper.uchicago.edu>
In listing blocks (set off by rows of dashes), the usual
formatting characters of asciidoc are instead rendered verbatim.
When the escaped double-hyphen of olden days is moved into such a
block along with other formatting improvements, it becomes
backslash-dash-dash.
So we remove the backslash.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-format-patch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 894b82d..3c9192a 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -206,7 +206,7 @@ For each commit a separate file is created in the current directory.
project:
+
------------
-$ git format-patch \--root origin
+$ git format-patch --root origin
------------
* The same as the previous one:
--
1.5.5.GIT
^ 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