* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-03 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vslmm8rcd.fsf@assigned-by-dhcp.cox.net>
On 6/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > I just pushed out an update to the "new" branch of the gitk.git
> > repository, which adds a feature that I have often wished for: it will
> > now show the nearest preceding and following tags when you select a
> > commit. This is very useful if you need to identify which release was
> > the first to incorporate a particular patch, or if you need to know
> > which release a patch might have been based on.
>
> Another thing that would equally be useful is to show which
> branch a particular commit is on, so for example I can pick one
> commit while doing "gitk next" to view the next branch and see
> which topic it belongs to, and "gitk this-topic" to see which
> commits on that topic, if any, are not yet in the "next" branch.
>
If I have understood correctly the patch runs a 'git rev-list --all
--topo-order --parents'
and then does a tree walking.
I am wandering if there exist any native git way to found the previous tag.
As example given a selected revision with id <sha> is it possible to
do something like this to fond the ancestor?
1) get the tag list with git-peek-remote or something similar if tags
are not already loaded
2) given the tagList vector with n elements run
git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
^tagList[n-1]
3) take the last sha spit out by git-rev-list, be it <lastSha>.
4) Previous nearest tag is the parent of lastSha
I've missed something?
Marco
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-03 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Fonseca
In-Reply-To: <7vslmm8rcd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Another thing that would equally be useful is to show which
> branch a particular commit is on, so for example I can pick one
> commit while doing "gitk next" to view the next branch and see
> which topic it belongs to, and "gitk this-topic" to see which
> commits on that topic, if any, are not yet in the "next" branch.
That wouldn't be hard to do, it's just a matter of finding which heads
are descendents of the selected commit. I think that with heads, you
would want to see all the descendent heads, rather than just the
nearest ones (those that aren't descendents of another descendent
head) as I do with tags. What do you think? If one head is a
descendent of another, and both are descendents of the selected
commit, should I show both?
> BTW, what's the maintenance/rewind policy on the "new" branch of
> gitk.git? If you are never going to rewind it, I could pull it
> in "next" (and keep pulling your "master" in my "master") for
> wider exposure if you like.
I intend to pull "new" into "master" shortly, assuming I don't get any
bug reports for the "new" branch. :)
If you pull my "new" into your "next", and you then pull your "next"
into your "master", and I pull my "new" into my "master", and you pull
my "master" into your "master", won't we end up with duplicate merges?
Paul.
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Linus Torvalds @ 2006-06-03 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Waitz
In-Reply-To: <7vy7we8w1h.fsf@assigned-by-dhcp.cox.net>
On Sat, 3 Jun 2006, Junio C Hamano wrote:
>
> I think this patch fixes the regression. Comments?
The approach looks fine, but with your changes, the "deleted" flag makes
no sense any more and looks redundant. It's not actually used for anything
except deciding if we need to re-write the active_cache[] thing, and you
migth as well use either "last" or "unmerged" for that.
(yeah, "last" and "unmerged" becomes non-null one entry earlier than
"deleted", but that's actually just confusing, I think, and now depends on
the fact that we don't have to re-write the first entry).
The whole "*dst++ = ce" _could_ be unconditional, the only reason I made
it conditional at all is to avoid dirtying the mmap when not necessary (ie
it's a performance optimization, and it's not one where that off-by-one
matters).
So I think you could make it clearer by dropping "deleted" entirely, and
just making the store be conditional on "last".
Linus
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Jonas Fonseca @ 2006-06-03 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vslmm8rcd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sat, Jun 03, 2006:
> For a graphical interface like gitk it may not be such a big
> deal (you can always follow the line), but an interface like tig
> that shows commits in a linear fashion it would make a big
> difference in usability.
I already took your hint from the other day on irc and have begun on
implementing this revision graph visualization for tig. :)
The problem is of course to come up with some ascii-art which is both
readable and dense. Below is my mockup of something not using line
graphics, however using line graphics it might be possible to get
something more unambiguos but also more "edgy".
* [release] Sync docs
M Merge ...
|`* [master] Fix spelling
| * Implement ...
M | Merge ...
|`M Merge ...
| |`* Topic B ...
| | * Topic B ...
| * | Topic A
| * | Topic A
| *' Update docs
: :
M | Merge ...
|`M Merge ...
| *`. Topic B ...
| * | Topic B ...
| | * Topic A
| | * Topic A
| *' Update docs
: :
M | Merge ...
|`M Merge ...
| *`. Topic B ...
| * | Topic B ...
| | * Topic A
M `.`. Merge
|`* | | Update docs
--
Jonas Fonseca
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Jakub Narebski @ 2006-06-03 15:33 UTC (permalink / raw)
To: git
In-Reply-To: <20060603151240.GA4024@diku.dk>
Jonas Fonseca wrote:
> I already took your hint from the other day on irc and have begun on
> implementing this revision graph visualization for tig. :)
>
> The problem is of course to come up with some ascii-art which is both
> readable and dense. Below is my mockup of something not using line
> graphics,[...]
As I can see you use 'vertical' layout. Do I understand correctly that '*'
refers to commit on marked (by column) branch, and '|' means pass-thru?
BTW. you might want to take a look at http://revctrl.org/ diagrams;
AFAICT all the git documentation uses 'horizontal' layout, which is good
for example but perhaps not for long-lived development...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Jonas Fonseca @ 2006-06-03 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5sa47$qv8$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote Sat, Jun 03, 2006:
> Jonas Fonseca wrote:
>
> > I already took your hint from the other day on irc and have begun on
> > implementing this revision graph visualization for tig. :)
> >
> > The problem is of course to come up with some ascii-art which is both
> > readable and dense. Below is my mockup of something not using line
> > graphics,[...]
>
> As I can see you use 'vertical' layout. Do I understand correctly that '*'
> refers to commit on marked (by column) branch, and '|' means pass-thru?
Yes, and 'M' marks merges. Putting information in the "commit node"
should make certain things more obvious. You could encode information
such as whether a commit is a "unique head" (nothing other revisions
references this commit). For example the first commit will always be
unique, but when using --all other heads might show up "unique".
+ [master] ...
* ...
| + [unmerged/topic] ...
| * ...
*' ...
> BTW. you might want to take a look at http://revctrl.org/ diagrams;
> AFAICT all the git documentation uses 'horizontal' layout, which is good
> for example but perhaps not for long-lived development...
Looking at the examples on http://revctrl.org/StaircaseMerge: it might
be more readable but not as dense as I would like, namely one commit pr
line.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] Builtin git-rev-parse.
From: Christian Couder @ 2006-06-03 16:45 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 7 +++----
rev-parse.c => builtin-rev-parse.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index b6fce39..004c216 100644
--- a/Makefile
+++ b/Makefile
@@ -154,8 +154,7 @@ PROGRAMS = \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-mailinfo$X git-merge-base$X \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
- git-peek-remote$X git-prune-packed$X \
- git-receive-pack$X git-rev-parse$X \
+ git-peek-remote$X git-prune-packed$X git-receive-pack$X \
git-send-pack$X git-shell$X \
git-show-index$X git-ssh-fetch$X \
git-ssh-upload$X git-unpack-file$X \
@@ -168,7 +167,7 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-add$X git-rm$X git-rev-list$X \
- git-check-ref-format$X \
+ git-check-ref-format$X git-rev-parse$X \
git-init-db$X git-tar-tree$X git-upload-tar$X git-format-patch$X \
git-ls-files$X git-ls-tree$X \
git-read-tree$X git-commit-tree$X \
@@ -222,7 +221,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-add.o builtin-rev-list.o builtin-check-ref-format.o \
- builtin-rm.o builtin-init-db.o \
+ builtin-rm.o builtin-init-db.o builtin-rev-parse.o \
builtin-tar-tree.o builtin-upload-tar.o \
builtin-ls-files.o builtin-ls-tree.o \
builtin-read-tree.o builtin-commit-tree.o \
diff --git a/rev-parse.c b/builtin-rev-parse.c
similarity index 99%
rename from rev-parse.c
rename to builtin-rev-parse.c
index 4e2d9fb..c353a48 100644
--- a/rev-parse.c
+++ b/builtin-rev-parse.c
@@ -7,6 +7,7 @@ #include "cache.h"
#include "commit.h"
#include "refs.h"
#include "quote.h"
+#include "builtin.h"
#define DO_REVS 1
#define DO_NOREV 2
@@ -163,7 +164,7 @@ static int show_file(const char *arg)
return 0;
}
-int main(int argc, char **argv)
+int cmd_rev_parse(int argc, const char **argv, char **envp)
{
int i, as_is = 0, verify = 0;
unsigned char sha1[20];
diff --git a/builtin.h b/builtin.h
index 738ec3d..ffa9340 100644
--- a/builtin.h
+++ b/builtin.h
@@ -43,5 +43,6 @@ extern int cmd_diff_index(int argc, cons
extern int cmd_diff_stages(int argc, const char **argv, char **envp);
extern int cmd_diff_tree(int argc, const char **argv, char **envp);
extern int cmd_cat_file(int argc, const char **argv, char **envp);
+extern int cmd_rev_parse(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 10ea934..bc463c9 100644
--- a/git.c
+++ b/git.c
@@ -69,7 +69,8 @@ static void handle_internal_command(int
{ "diff-index", cmd_diff_index },
{ "diff-stages", cmd_diff_stages },
{ "diff-tree", cmd_diff_tree },
- { "cat-file", cmd_cat_file }
+ { "cat-file", cmd_cat_file },
+ { "rev-parse", cmd_rev_parse }
};
int i;
--
1.3.3.ge13b
^ permalink raw reply related
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-03 16:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17537.32585.260926.48759@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> ... I think that with heads, you
> would want to see all the descendent heads, rather than just the
> nearest ones (those that aren't descendents of another descendent
> head) as I do with tags. What do you think? If one head is a
> descendent of another, and both are descendents of the selected
> commit, should I show both?
That would be useful I think.
>> BTW, what's the maintenance/rewind policy on the "new" branch of
>> gitk.git? If you are never going to rewind it, I could pull it
>> in "next" (and keep pulling your "master" in my "master") for
>> wider exposure if you like.
>
> I intend to pull "new" into "master" shortly, assuming I don't get any
> bug reports for the "new" branch. :)
>
> If you pull my "new" into your "next", and you then pull your "next"
> into your "master", and I pull my "new" into my "master", and you pull
> my "master" into your "master", won't we end up with duplicate merges?
Yes, but I rarely if ever pull "next" as a whole into "master".
^ permalink raw reply
* [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst H. von Brand @ 2006-06-03 17:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
- Fix the regular expressions for local addresses
- Fix the fallback regexp for non-local addresses, simplify the logic
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
git-send-email.perl | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index ed1d89b..a7a7797 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -314,18 +314,15 @@ sub extract_valid_address {
my $address = shift;
# check for a local address:
- return $address if ($address =~ /^([\w\-]+)$/);
+ return $address if ($address =~ /^([\w\-.]+)$/);
if ($have_email_valid) {
return Email::Valid->address($address);
} else {
# less robust/correct than the monster regexp in Email::Valid,
# but still does a 99% job, and one less dependency
- my $cleaned_address;
- if ($address =~ /([^\"<>\s]+@[^<>\s]+)/) {
- $cleaned_address = $1;
- }
- return $cleaned_address;
+ $address =~ /([\w\-.]+@[\w\-.]+)/;
+ return $1;
}
}
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 0/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Result of a run of aspell(1) over the *.txt files in Documentation. Also
fixed several other typoes.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
^ permalink raw reply
* [PATCH 2/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664482083-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/core-tutorial.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 5a831ad..1185897 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -184,7 +184,7 @@ you'll have to use the object name, not
----------------
where the `-t` tells `git-cat-file` to tell you what the "type" of the
-object is. git will tell you that you have a "blob" object (ie just a
+object is. git will tell you that you have a "blob" object (i.e., just a
regular file), and you can see the contents with
----------------
@@ -619,7 +619,7 @@ that tag. You create these annotated tag
----------------
which will sign the current `HEAD` (but you can also give it another
-argument that specifies the thing to tag, ie you could have tagged the
+argument that specifies the thing to tag, i.e., you could have tagged the
current `mybranch` point by using `git tag <tagname> mybranch`).
You normally only do signed tags for major releases or things
@@ -1097,7 +1097,7 @@ commit object by downloading from `repo.
using the object name of that commit object. Then it reads the
commit object to find out its parent commits and the associate
tree object; it repeats this process until it gets all the
-necessary objects. Because of this behaviour, they are
+necessary objects. Because of this behavior, they are
sometimes also called 'commit walkers'.
+
The 'commit walkers' are sometimes also called 'dumb
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 3/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366450549-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/cvs-migration.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index fa94efd..826d089 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -1,7 +1,7 @@
git for CVS users
=================
-So you're a CVS user. That's ok, it's a treatable condition. The job of
+So you're a CVS user. That's OK, it's a treatable condition. The job of
this document is to put you on the road to recovery, by helping you
convert an existing cvs repository to git, and by showing you how to use a
git repository in a cvs-like fashion.
@@ -159,7 +159,7 @@ other than `master`.
[NOTE]
============
-Because of this behaviour, if the shared repository and the developer's
+Because of this behavior, if the shared repository and the developer's
repository both have branches named `origin`, then a push like the above
attempts to update the `origin` branch in the shared repository from the
developer's `origin` branch. The results may be unexpected, so it's
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 6/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664643454-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-commit.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 38df59c..0fe66f2 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -98,7 +98,7 @@ but can be used to amend a merge commit.
Instead of committing only the files specified on the
command line, update them in the index file and then
commit the whole index. This is the traditional
- behaviour.
+ behavior.
-o|--only::
Commit only the files specified on the command line.
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 5/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <114936645851-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-blame.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 5189878..0a1fa00 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -16,7 +16,7 @@ which introduced the line. Start annotat
OPTIONS
-------
--c, --compability::
+-c, --compatibility::
Use the same output mode as git-annotate (Default: off).
-l, --long::
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 4/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664521468-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-apply.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index e93ea1f..9cc7c74 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -113,7 +113,7 @@ OPTIONS
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
You can use different `<option>` to control this
- behaviour:
+ behavior:
+
* `nowarn` turns off the trailing whitespace warning.
* `warn` outputs warnings for a few such errors, but applies the
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 7/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664652868-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-cvsserver.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 4dc13c3..952635d 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -94,7 +94,7 @@ To get a checkout with the Eclipse CVS c
4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the
"launch commit wizard" to avoid committing the .project file.
-Protocol notes: If you are using anonymous acces via pserver, just select that.
+Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
'git-cvsserver'. Not that password support is not good when using 'ext',
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 9/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664673957-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-diff-index.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index 5d2096a..9cd43f1 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -101,7 +101,7 @@ have not actually done a "git-update-ind
torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
-ie it shows that the tree has changed, and that `kernel/sched.c` has is
+i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 16/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366483572-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-read-tree.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 844cfda..02c7e99 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -205,7 +205,7 @@ The `git-write-tree` command refuses to
will complain about unmerged entries if it sees a single entry that is not
stage 0.
-Ok, this all sounds like a collection of totally nonsensical rules,
+OK, this all sounds like a collection of totally nonsensical rules,
but it's actually exactly what you want in order to do a fast
merge. The different stages represent the "result tree" (stage 0, aka
"merged"), the original tree (stage 1, aka "orig"), and the two trees
@@ -226,7 +226,7 @@ populated. Here is an outline of how th
- the index file saves and restores with all this information, so you
can merge things incrementally, but as long as it has entries in
- stages 1/2/3 (ie "unmerged entries") you can't write the result. So
+ stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So
now the merge algorithm ends up being really simple:
* you walk the index in order, and ignore all entries of stage 0,
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 8/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366466232-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-daemon.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 924a676..4c357da 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -20,7 +20,7 @@ aka 9418. It waits for a connection, and
when it gets one.
It's careful in that there's a magic request-line that gives the command and
-what directory to upload, and it verifies that the directory is ok.
+what directory to upload, and it verifies that the directory is OK.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
@@ -28,7 +28,7 @@ for export this way (unless the '--expor
pass some directory paths as 'git-daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
-This is ideally suited for read-only updates, ie pulling from git repositories.
+This is ideally suited for read-only updates, i.e., pulling from git repositories.
OPTIONS
-------
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 12/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664701494-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-fsck-objects.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
index 93ce9dc..d0af99d 100644
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -71,7 +71,7 @@ sorted properly etc), but on the whole i
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
-(ie 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
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 14/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664773328-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-merge-index.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 332e023..6cd0601 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -69,7 +69,7 @@ or
fatal: merge program failed
where the latter example shows how "git-merge-index" will stop trying to
-merge once anything has returned an error (ie "cat" returned an error
+merge once anything has returned an error (i.e., "cat" returned an error
for the AA file, because it didn't exist in the original, and thus
"git-merge-index" didn't even try to merge the MM thing).
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 17/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664892352-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-repo-config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 660c18f..d5142e0 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -49,7 +49,7 @@ OPTIONS
-------
--replace-all::
- Default behaviour is to replace at most one line. This replaces
+ Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally the value_regex).
--get::
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 11/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366468410-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-diff.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 7267bcd..7ab2080 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -85,7 +85,7 @@ Limiting the diff output::
nor deletion.
<2> show only names and the nature of change, but not actual
diff output. --name-status disables usual patch generation
-which in turn also disables recursive behaviour, so without -r
+which in turn also disables recursive behavior, so without -r
you would only see the directory name if there is a change in a
file in a subdirectory.
<3> limit diff output to named subtrees.
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 10/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664672829-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-diff-tree.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 906830d..f7e8ff2 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -32,7 +32,7 @@ include::diff-options.txt[]
<path>...::
If provided, the results are limited to a subset of files
matching one of these prefix strings.
- ie file matches `/^<pattern1>|<pattern2>|.../`
+ i.e., file matches `/^<pattern1>|<pattern2>|.../`
Note that this parameter does not provide any wildcard or regexp
features.
@@ -54,7 +54,7 @@ include::diff-options.txt[]
+
When a single commit is given on one line of such input, it compares
the commit with its parents. The following flags further affects its
-behaviour. This does not apply to the case where two <tree-ish>
+behavior. This does not apply to the case where two <tree-ish>
separated with a single space are given.
-m::
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 13/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493664763628-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-grep.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 74102b7..7b810df 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -30,7 +30,7 @@ OPTIONS
-------
--cached::
Instead of searching in the working tree files, check
- the blobs registerd in the index file.
+ the blobs registered in the index file.
-a | --text::
Process binary files as if they were text.
@@ -65,7 +65,7 @@ OPTIONS
-[ABC] <context>::
Show `context` trailing (`A` -- after), or leading (`B`
-- before), or both (`C` -- context) lines, and place a
- line containing `--` between continguous groups of
+ line containing `--` between contiguous groups of
matches.
-f <file>::
--
1.3.3.g86f7
^ 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