* Re: MinGW build environment for Git
From: Dmitry Kakurin @ 2007-08-01 9:08 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <46B016FC.4050005@trolltech.com>
On 7/31/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> Dmitry Kakurin said the following on 30.07.2007 01:14:
> > I want to be able to build MinGW port of Git on Windows. I've tried
> > to follow steps in README.MinGW to setup this environment myself
> > (install MinGW, MSys, ZLib etc.) but after wasting a lot of time
> > with no result I give up. So, could somebody please just pkzip
> > their environment (everything required) and share the zip file with
> > me (privately or publicly)? I also think that an even better idea
> > is to create a new Git repository with MinGW build environment.
> > This will make contributing to MinGW port of Git MUCH easier.
>
> Aaron has done this, and you can find the link on his blog, here:
> http://www.ekips.org/cgi-bin/aaron.cgi/2007/02/27
I've downloaded and installed it. But I could not make it work :-(.
First I had this problem:
$ make
GIT_VERSION = 1.5.3.GIT
* new build flags or prefix
CC convert-objects.o
gcc.exe: installation problem, cannot exec `cc1': No such file or directory
make: *** [convert-objects.o] Error 1
Then I've copied cc1.exe and some others from
C:\mingw4git\libexec\gcc\mingw32 into /bin.
$ make
CC convert-objects.o
In file included from cache.h:4,
from convert-objects.c:1:
git-compat-util.h:51:22: sys/wait.h: No such file or directory
Searching entire (downloaded) tree for wait.h gives nothing.
'make configure' does not work:
$ make configure
GEN configure
configure.ac+:4: error: Autoconf version 2.59 or higher is required
configure.ac+:4: the top level
autom4te: /bin/m4 failed with exit status: 1
make: *** [configure] Error 1
What do I do now?
-Dmitry
^ permalink raw reply
* Re: dangling blob which is not dangling at all
From: Rogan Dawes @ 2007-08-01 9:13 UTC (permalink / raw)
To: Steven Grimm; +Cc: Domenico Andreoli, git
In-Reply-To: <46B045D3.4070208@midwinter.com>
Steven Grimm wrote:
> Domenico Andreoli wrote:
>> What is this reflog thing and why is required?
>>
>
> It is a log of where each ref pointed at any given time. Or rather, a
> log of changes to refs, with timestamps. It is not *required* per se
> (you can turn it off and almost all of git will continue to work as
> before) but it's handy in that you can say stuff like
>
> git checkout -b newbranch master@"{4 days ago}"
>
> and git will give you a new branch pointing at the rev that master
> pointed to 4 days ago, even if it's a rev that is no longer reachable
> from any of the existing heads (e.g., because you did a "git rebase" and
> the rev in question was replaced by a new one.) Obviously as soon as you
> do a "git gc" you will lose the ability to go back to unreachable revs
> using the reflog.
>
Not strictly true. "git gc" does take the reflogs into account when
determining reachability, but it also prunes the reflogs periodically to
prevent them from growing without bound (and preventing pruning of
otherwise unreachable objects).
From the git-gc manpage:
CONFIGURATION
The optional configuration variable gc.reflogExpire can be set to
indicate how long historical entries within each branch's reflog should
remain available in this repository. The setting is expressed as a
length of time, for example 90 days or 3 months. It defaults to 90
days.
Regards,
Rogan
^ permalink raw reply
* Re: [PATCH] Allow git_author|committer_info be called in the same expression
From: Junio C Hamano @ 2007-08-01 9:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Kristian Høgsberg, git
In-Reply-To: <81b0412b0707310957x62ac9d28j60104bffb46a80b7@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> const char *git_committer_info(int error_on_no_name)
> {
> - return fmt_ident(getenv("GIT_COMMITTER_NAME"),
> - getenv("GIT_COMMITTER_EMAIL"),
> - getenv("GIT_COMMITTER_DATE"),
> - error_on_no_name);
> + static char *buffer;
> + if (!buffer)
> + buffer = xmalloc(FMT_IDENT_BUFSIZE);
It is not like we are aiming to run on embedded devices, I think
trying to save static memory when the function is not called
by doing things like this is not worth it. Why not just:
static char buffer[FMT_IDENT_BUFSIZE];
instead?
In any case, I'd really like to slow things down and ask
everybody to concentrate on finding and fixing bugs in what are
scheduled for 1.5.3 for a week or so.
That means the current "master".
I did not merge Johannes's work tree rationalization patch to
"master" yet (it is now part of "next"), but I would like to
have it in, as it makes the code much easier to read compared to
the work-tree changes currently in "master". Even though the
one currently in "master" does not seem to regress the normal
usage of not using GIT_WORK_TREE environment, we would be better
off if a new feature is released in a shape that is maintainable.
Other than that topic, everything on "next" will be post 1.5.3.
Please.
I'd like to do -rc4 this weekend, and then 1.5.3 final by mid
August at the latest, but hopefully sooner.
As to parts of the system that other people are primarily in
charge of, git-gui 0.8.0 is already in as promised, updates to
gitk were merged, and we've had a nice set of improvements from
Jakub on gitweb already. Bruce seems to have a beginning of the
user manual reorganization, but I am getting the feeling it is
not ready yet.
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Theodore Tso @ 2007-08-01 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <7vodhrby6f.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 31, 2007 at 10:50:48PM -0700, Junio C Hamano wrote:
> I would call aversion to -l a superstition, while aversion to -s
> has a sound technical reasons. The latter means you need to know
> what you are doing --- namely, you are making the clone still
> dependent on the original.
So would you accept a patch which adds a git-config variable which
specifies whether or not local clones should use hard links by default
(defaulting to yes), and which adds a --no-hard-links option to
git-clone to override the config option?
I could imagine a situation where if you are using a git repository
exclusively on a local system, with no remote repositories to act as
backups, where you might want git clone to to make full copies to
provide backups in case of filesystem or disk induced corruption. But
most of the time there are enough copies of the the repo on other
machines that the need for making separate copies of the git
objects/packs isn't really needed.
- Ted
^ permalink raw reply
* Re: [PATCH] Allow git_author|committer_info be called in the same expression
From: Alex Riesen @ 2007-08-01 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, git, Paul Mackerras
In-Reply-To: <7vhcnj7gkt.fsf@assigned-by-dhcp.cox.net>
On 8/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > const char *git_committer_info(int error_on_no_name)
> > {
> > - return fmt_ident(getenv("GIT_COMMITTER_NAME"),
> > - getenv("GIT_COMMITTER_EMAIL"),
> > - getenv("GIT_COMMITTER_DATE"),
> > - error_on_no_name);
> > + static char *buffer;
> > + if (!buffer)
> > + buffer = xmalloc(FMT_IDENT_BUFSIZE);
>
> It is not like we are aiming to run on embedded devices, I think
Actually, I am planning to run it on Neo1973 (Openmoko),
which is quite embedded with its 128mb.
> trying to save static memory when the function is not called
> by doing things like this is not worth it. Why not just:
>
> static char buffer[FMT_IDENT_BUFSIZE];
>
> instead?
Just a custom. This is a big bugger, err... buffer.
> As to parts of the system that other people are primarily in
> charge of, git-gui 0.8.0 is already in as promised, updates to
> gitk were merged, and we've had a nice set of improvements from
BTW, gitk. Have you seen the gitk patches regarding errors in non-GIT
and not-yet-GIT directory?
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Junio C Hamano @ 2007-08-01 10:15 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <20070801092428.GB28106@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Tue, Jul 31, 2007 at 10:50:48PM -0700, Junio C Hamano wrote:
>> I would call aversion to -l a superstition, while aversion to -s
>> has a sound technical reasons. The latter means you need to know
>> what you are doing --- namely, you are making the clone still
>> dependent on the original.
>
> So would you accept a patch which adds a git-config variable which
> specifies whether or not local clones should use hard links by default
> (defaulting to yes), and which adds a --no-hard-links option to
> git-clone to override the config option?
Are you suggesting to make -l the default for local, in other
words? I personally do not make local clone often enough that I
am not disturbed having to type extra " -l" on the command line.
But giving a way to force "copy not hardlink" while still
avoiding "the same as the networked case by doing pack transfer"
overhead may be a good thing to do.
Perhaps if the destination is local,
- if -s is given, just set up alternates, do nothing else;
- by default, do "always copy never hardlink";
- with -l, do "hardlink if possible";
Hmmmm...
^ permalink raw reply
* Re: MinGW build environment for Git
From: Johannes Schindelin @ 2007-08-01 10:44 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <a1bbc6950708010208v15071005w3bcc471bef172fcc@mail.gmail.com>
Hi,
On Wed, 1 Aug 2007, Dmitry Kakurin wrote:
> On 7/31/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > Dmitry Kakurin said the following on 30.07.2007 01:14:
> > > I want to be able to build MinGW port of Git on Windows. I've tried
> > > to follow steps in README.MinGW to setup this environment myself
> > > (install MinGW, MSys, ZLib etc.) but after wasting a lot of time
> > > with no result I give up. So, could somebody please just pkzip
> > > their environment (everything required) and share the zip file with
> > > me (privately or publicly)? I also think that an even better idea
> > > is to create a new Git repository with MinGW build environment.
> > > This will make contributing to MinGW port of Git MUCH easier.
> >
> > Aaron has done this, and you can find the link on his blog, here:
> > http://www.ekips.org/cgi-bin/aaron.cgi/2007/02/27
>
> I've downloaded and installed it. But I could not make it work :-(.
> First I had this problem:
> $ make
> GIT_VERSION = 1.5.3.GIT
> * new build flags or prefix
> CC convert-objects.o
> gcc.exe: installation problem, cannot exec `cc1': No such file or directory
> make: *** [convert-objects.o] Error 1
>
> Then I've copied cc1.exe and some others from
> C:\mingw4git\libexec\gcc\mingw32 into /bin.
>
> $ make
> CC convert-objects.o
> In file included from cache.h:4,
> from convert-objects.c:1:
> git-compat-util.h:51:22: sys/wait.h: No such file or directory
>
> Searching entire (downloaded) tree for wait.h gives nothing.
>
> 'make configure' does not work:
> $ make configure
> GEN configure
> configure.ac+:4: error: Autoconf version 2.59 or higher is required
> configure.ac+:4: the top level
> autom4te: /bin/m4 failed with exit status: 1
> make: *** [configure] Error 1
>
> What do I do now?
This looks like you downloaded git.git. Official releases do not have
MinGW support yet! You have to get the MinGW port from repo.or.cz:
http://repo.or.cz/w/git/mingw.git
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/9] work-tree clean ups
From: Johannes Schindelin @ 2007-08-01 10:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0708010211071.14781@racer.site>
Hi,
On Wed, 1 Aug 2007, Johannes Schindelin wrote:
> On Tue, 31 Jul 2007, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > There is not really much that can be done about step 6/9: if we are in a
> > > work tree: that does not mean that we are _not_ in the git_dir. (And no,
> > > this does not break git-clean, as a work tree is a work tree is a work
> > > tree. If the user was stupid enough to specify the same directory as
> > > GIT_DIR and GIT_WORK_TREE, then that is _her_ problem. Git is a powerful
> > > tool, and you can harm yourself with it. Tough.)
> >
> > I think we might have a slight misunderstanding. The "clean"
> > issue that was raised in an ancient thread was this sequence:
> >
> > $ git init
> > $ cd .git
> > $ git clean
> >
> > It did not involve GIT_DIR (nor GIT_WORK_TREE as it was not even
> > there).
>
> I very much _did_ mean that case. When "git clean" is run in ".git/", it
> should not say that it is in the working tree. But I guess that my patch
> series is not really looking out for that; I'll make that an add-on
> patch. (But that _will_ have to wait until tomorrow afternoon.)
I should not have answered so early.
In setup.c, I put in a comment that explains clearly where (in the absence
of GIT_DIR) setup_git_directory_gently() looks for the git directory:
/*
* Test in the following order (relative to the cwd):
* - .git/
* - ./ (bare)
* - ../.git/
* - ../ (bare)
* - ../../.git/
* etc.
*/
At least I hope that this explanation is clear.
So what happens in this case:
$ git init
$ cd .git
$ git clean
In setup_git_directory_gently(), it is tested first if there is a
subdirectory .git/. No, none. Then it is tested if "." is a git
directory. Yes! So, work_tree is set to NULL tentatively (to be
overridden by either core.worktree or GIT_WORK_TREE), and it is assumed to
be bare (also subject to overriding). So all is well!
You might have noticed that I left out --work-tree= handling; when
--work-tree=<something> is specified, GIT_WORK_TREE is _forced_ to the new
value, so it is literally handled by the same code as GIT_WORK_TREE.
Ciao,
Dscho
^ permalink raw reply
* git rebase--interactive, doesn't ignore commits already in upstream
From: Mark Levedahl @ 2007-08-01 11:28 UTC (permalink / raw)
To: Git Mailing List
git rebase -i does not correctly ignore commits in the local branch that
are also in upstream. For example, create a branch that is two commits
back from upstream, add one of those on to the local branch
upstream=83b3df7d58
git checkout -f $upstream
git checkout -b foo $upstream~2
git cherry-pick $upstream~1
git rebase -i $upstream
"git rebase -i" happily presents commit "$upstream~1" in the list to be
applied to upstream. This of course results in a conflict. Should the
user simply delete the offending commit from the presented list, git
rebase -i then refuses to do anything, saying "Nothing to do."
Bare "git rebase" handles this case correctly (essentially fast forwards
the branch to upstream.
Mark
^ permalink raw reply
* Re: [PATCH 2/4] Add functions get_relative_cwd() and is_inside_dir()
From: Johannes Schindelin @ 2007-08-01 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vwswfbywq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 31 Jul 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> The function get_relative_cwd() works just as getcwd(), only that it
> >> takes an absolute path as additional parameter, returning the prefix
> >> of the current working directory relative to the given path. If the
> >> cwd is no subdirectory of the given path, it returns NULL.
> >> ...
> >> +/*
> >> + * get_relative_cwd() gets the prefix of the current working directory
> >> + * relative to 'dir'. If we are not inside 'dir', it returns NULL.
> >> + * As a convenience, it also returns NULL if 'dir' is already NULL.
> >> + */
> >> +char *get_relative_cwd(char *buffer, int size, const char *dir)
> >> +{
> >> + char *cwd = buffer;
> >> +
> >> + if (!dir || !getcwd(buffer, size))
> >> + return NULL;
> >
> > When is it not a fatal error if get_relative_cwd() is called
> > with a NULL dir parameter, or getcwd() fails?
> >
> > If there is no valid such cases, I would rather have this
> > die(), former with "BUG" and the latter with strerror(errno).
>
> Heh, it turns out that there is this lazy or clever (depending
> on the viewpoint) caller that passes the return value of
> get_git_work_tree() to this function and expect this to return
> NULL when no work tree is found.
Right. I thought I had said that (something along the lines: it is more
convenient not having to check the directory), but I probably did not.
> The callers of the is_* functions are much cleaner and in that sense the
> series is a definite improvement, but this one particular obscurity
> makes me wonder if it is replacing one unholy mess with a smaller but
> still unholy mess.
>
> Will apply on "master" and will be part of -rc4, but we probably would
> want to have a longer pre-final freeze than usual to really make sure
> this one is good.
I'll provide a patch which makes the callers of get_relative_cwd() holy,
and skip the check in get_relative_cwd(), okay?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] Clean up work-tree handling
From: Johannes Schindelin @ 2007-08-01 11:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7v3az3deac.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 31 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The old version of work-tree support was an unholy mess, barely readable,
> > and not to the point.
> >
> > For example, why do you have to provide a worktree, when it is not used?
> > As in "git status". Now it works.
> > ...
>
> Without continuing with negatives, let's try to define the new,
> corrected world order.
>
> I do not think the following is exactly what your cleaned-up
> version tries to perform, but I am writing this down primarily
> to demonstrate the style and the level of detail I expect to
> accompany a clean-up patch like this.
After reading your description I sink into the ground in shame. I really
like the style this has, and agree that something as nice as this should
have been there.
> - is_inside_git_dir(): this returns true if the $cwd is the git
> directory or its subdirectory. [IS THIS STILL NEEDED???]
Hmmm.
> - is_inside_work_tree(): this returns true if the $cwd is
> inside work tree (i.e. either at the toplevel of the work
> tree or its subdirectory). [NEEDSHELP: is .git in the usual
> layout considered "is_inside_work_tree()"? Should it?]
.git/ is not considered part of the work tree, even if it is _physically_
there.
> After writing the above down, it strikes me odd that we do not
> have a predicate that says "we know the work tree is there".
>
> If a command wants a work tree, and if you are outside the work
> tree, then is_inside_work_tree() returns false and
> get_git_work_tree() returns non NULL, so that is a good pair of
> interface that can be mixed and matched (e.g. you can chdir to
> the former to perform the whole tree operation, or refuse to
> perform, based on is_inside_work_tree being false, cwd relative
> operations).
Yes. Builtins which need a working tree expect to start at the toplevel
of the work tree (which I like to call "working directory", because it is
described as such in the glossary AFAIR), and therefore they chdir() to
the toplevel in any case.
I'll be running "master"+worktree+branch-newdir for the remainder of the
1.5.3-rc period, to be sure that all works as intended.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] Clean up work-tree handling
From: Johannes Schindelin @ 2007-08-01 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vvebz7hpw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 1 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/builtin-ls-files.c b/builtin-ls-files.c
> > index 61577ea..d36181a 100644
> > --- a/builtin-ls-files.c
> > +++ b/builtin-ls-files.c
> > @@ -469,9 +469,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
> > break;
> > }
> >
> > - if (require_work_tree &&
> > - (!is_inside_work_tree() || is_inside_git_dir()))
> > - die("This operation must be run in a work tree");
> > + if (require_work_tree && !is_inside_work_tree()) {
> > + const char *work_tree = get_git_work_tree();
> > + if (!work_tree || chdir(work_tree))
> > + die("This operation must be run in a work tree");
> > + }
> >
> > pathspec = get_pathspec(prefix, argv + i);
> >
>
> Similarly to this change, I am wondering if we would want to fix
> verify_non_filename() in setup.c, which does this:
>
> /*
> * Verify a filename that we got as an argument for a pathspec
> * entry. Note that a filename that begins with "-" never verifies
> * as true, because even if such a filename were to exist, we want
> * it to be preceded by the "--" marker (or we want the user to
> * use a format like "./-filename")
> */
> void verify_filename(const char *prefix, const char *arg)
> {
> ...
> }
>
> /*
> * Opposite of the above: the command line did not have -- marker
> * and we parsed the arg as a refname. It should not be interpretable
> * as a filename.
> */
> void verify_non_filename(const char *prefix, const char *arg)
> {
> const char *name;
> struct stat st;
>
> if (!is_inside_work_tree() || is_inside_git_dir())
> return;
> if (*arg == '-')
> return; /* flag */
> name = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;
> if (!lstat(name, &st))
> die("ambiguous argument '%s': both revision and filename\n"
> "Use '--' to separate filenames from revisions", arg);
> if (errno != ENOENT)
> die("'%s': %s", arg, strerror(errno));
> }
>
> At this point, we are given an ambiguous parameter, that could
> be naming a path in the work tree. If we are not in the work
> tree, then it is understandable that we do not have to barf.
> The other check (i.e. "|| is_inside_git_dir()") does not hurt
> (iow, it is not an incorrect check per-se), because if you did
> "cd .git && git log HEAD" then the HEAD parameter cannot be
> naming the path ".git/HEAD" in the work tree, but (1) that is
> already covered by .git/ being "outside of work tree", and (2)
> it is not something this function wants to check anyway
> (i.e. "can the parameter be naming a file in the work tree?").
>
> Am I mistaken and/or confused?
I think you are completely right. Inside a bare repository, "git log
FETCH_HEAD" should not need to complain. And I think that the
"is_inside_git_dir()" could be _replaced_ by "!is_inside_work_tree()",
since that is the intent of that call.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Hack git-add--interactive to make it work with ActiveState Perl
From: Alex Riesen @ 2007-08-01 13:09 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
It wont work for arguments with special characters (like ", : or *).
It is generally not possible on Windows, so I didn't even try.
---
git-add--interactive.perl | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
[-- Attachment #2: 0001-Hack-git-add-interactive-to-make-it-work-with-ActiveS.txt --]
[-- Type: text/plain, Size: 1824 bytes --]
From 0206b165dab71b0dc6396f88cfb8f70f67277ddf Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 1 Aug 2007 14:57:43 +0200
Subject: [PATCH] Hack git-add--interactive to make it work with ActiveState Perl
It wont work for arguments with special characters (like ", : or *).
It is generally not possible on Windows, so I didn't even try.
---
git-add--interactive.perl | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index dc30380..7921cde 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -3,9 +3,16 @@
use strict;
sub run_cmd_pipe {
- my $fh = undef;
- open($fh, '-|', @_) or die;
- return <$fh>;
+ if ($^O eq 'MSWin32') {
+ my @invalid = grep {m/[":*]/} @_;
+ die "$^O does not support: @invalid\n" if @invalid;
+ my @args = map { m/ /o ? "\"$_\"": $_ } @_;
+ return qx{@args};
+ } else {
+ my $fh = undef;
+ open($fh, '-|', @_) or die;
+ return <$fh>;
+ }
}
my ($GIT_DIR) = run_cmd_pipe(qw(git rev-parse --git-dir));
@@ -17,7 +24,7 @@ chomp($GIT_DIR);
sub refresh {
my $fh;
- open $fh, '-|', qw(git update-index --refresh)
+ open $fh, 'git update-index --refresh |'
or die;
while (<$fh>) {
;# ignore 'needs update'
@@ -296,7 +303,7 @@ sub revert_cmd {
my @lines = run_cmd_pipe(qw(git ls-tree HEAD --),
map { $_->{VALUE} } @update);
my $fh;
- open $fh, '|-', qw(git update-index --index-info)
+ open $fh, '| git update-index --index-info'
or die;
for (@lines) {
print $fh $_;
@@ -725,7 +732,7 @@ sub patch_update_cmd {
if (@result) {
my $fh;
- open $fh, '|-', qw(git apply --cached);
+ open $fh, '| git apply --cached';
for (@{$head->{TEXT}}, @result) {
print $fh $_;
}
--
1.5.3.rc3.145.g4d9cdb
^ permalink raw reply related
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Alex Riesen @ 2007-08-01 13:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>
On 8/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> Theodore Tso <tytso@mit.edu> writes:
> > So would you accept a patch which adds a git-config variable which
> > specifies whether or not local clones should use hard links by default
> > (defaulting to yes), and which adds a --no-hard-links option to
> > git-clone to override the config option?
>
> Are you suggesting to make -l the default for local, in other
> words? I personally do not make local clone often enough that I
> am not disturbed having to type extra " -l" on the command line.
...as long as the underlying filesystem _supports_ hardlinks.
BTW, we need a warning when falling back to normal copy,
if git-clone -l is used. The user _asked_ for a hard-linked
clone, but silently got something else. Something like this:
diff --git a/git-clone.sh b/git-clone.sh
index 0922554..a744f5b 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -266,6 +266,7 @@ yes,yes)
l=
if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
then
+ echo >&2 "Hardlinks not supported. Falling back to copy"
l=l
fi &&
rm -f "$GIT_DIR/objects/sample" &&
^ permalink raw reply related
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Alex Riesen @ 2007-08-01 13:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <81b0412b0708010620h6bf44aarb35da301db967855@mail.gmail.com>
On 8/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
> then
> + echo >&2 "Hardlinks not supported. Falling back to copy"
> l=l
> fi &&
Err, the other way around, of course.
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Alex Riesen @ 2007-08-01 13:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <81b0412b0708010620g776fb89ei574ece00ac45bf30@mail.gmail.com>
On 8/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 8/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> > if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
> > then
> > + echo >&2 "Hardlinks not supported. Falling back to copy"
> > l=l
> > fi &&
>
> Err, the other way around, of course.
>
diff --git a/git-clone.sh b/git-clone.sh
index 0922554..483b91d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -264,8 +264,10 @@ yes,yes)
test -f "$repo/$sample_file" || exit
l=
- if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
+ if ! ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
then
+ echo >&2 "Hardlinks not supported. Falling back to copy"
+ else
l=l
fi &&
rm -f "$GIT_DIR/objects/sample" &&
^ permalink raw reply related
* Interpreting EDITOR/VISUAL environment variables.
From: David Kastrup @ 2007-08-01 13:36 UTC (permalink / raw)
To: git
Whatever I have been able to Google, is completely silent on this
matter. If anybody has an idea where to find authoritative
information, holler.
In the meantime, in the Emacs manual there is the following bit of
information:
(info "(emacs) Invoking Emacsclient")
The option `-a COMMAND' or `--alternate-editor=COMMAND' specifies a
command to run if `emacsclient' fails to contact Emacs. This is useful
when running `emacsclient' in a script. For example, the following
setting for the `EDITOR' environment variable will always give you an
editor, even if no Emacs server is running:
EDITOR="emacsclient --alternate-editor emacs +%d %s"
That makes it likely that the way to call an editor should be via
system. However, there are certainly programs around which will not
interpret the +%d and %s thingies. My current setting is
EDITOR="emacsclient --alternate-editor vi"
and this seems to do the trick with most applications. Not so with
git-commit and other git scripts. The easiest way out will be to
create something like ~/bin/myemacsclient which does the respective
argument splicing. I am just not sure this is the "canonically
correct way" of interpreting $EDITOR.
Actually, splicing $EDITOR into a system command is a nuisance because
it means having to shell-quote its arguments. So the current
interpretation is likely easier to maintain.
Is it the correct one?
--
David Kastrup
^ permalink raw reply
* Re: git-gui: diff/console part does not show UTF-8 Japanese
From: Shawn O. Pearce @ 2007-08-01 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, GIT mailing list
In-Reply-To: <7vvebz602q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@bluebottle.com> writes:
>
> > I was testing git-gui (i18n branch). I can see the translated
> > message in the UI buttons and menus, and also commit message part shows
> > Japanese strings, but I cannot get the diff part at the bottom to show
> > Japanese. Because I did set the two fonts to the same font from the
> > Edit/Option menu, I do not think it is the problem with the font
> > settings.
> >
> > Can anybody help?
>
> I can see the same breakage in regular git-gui without i18n.
> Curious. The commit message shows Japanese but diff part is
> bogus.
>
> And the breakage is not just Japanese. I can see this with
> Kristian's name by resetting a branch to 12ace0b2 and then
> attempting to amend it. Interestingly enough, gitk shows the
> patch as expected. I do not quite know how it is arranged
> there, though.
>
> Now, I freely admit I do not quite know what I am doing, but
> this patch that tries to mimick the handling of commit log
> message seems to help it for git-gui.
>
> I do think using i18n.commitencoding for payload is wrong,
> though.
Yea, it is wrong. The patch is logically fine as-is, there's nothing
wrong with it except this part. I think the reason that gitk shows
the patch as expected is because it is using i18n.commitencoding
for the payload, and that's only happening as a side-effect of how
it used it for the commit message itself. Call it dumb luck the
thing even displays right.
To really Do The Right Thing(tm) here I think we need to store an
encoding for each file path so we know what we are looking at when
we see the file content. E.g. a gitattributes enc attribute?
For some files we might be able to guess. But I have to admit,
I'm not up on my encoding guessing algorithms. ;-)
For XML files we can probably guess its XML ("starts with <?xml")
and we can guess the encoding from that header line. But not
everything that contains Japanese characters is an XML file.
Like .po files for instance.
Where it gets even more interesting is how do I show a patch
where the encoding changed? E.g. reencode a file from ISO-8859-1
into UTF-8? A number of lines would probably be identical, except
for their encoding. So the user would want to see that they are
the same. So we really should be able to show the old line using
its old encoding, and the new line using its new encoding. Hmmph.
As a stop-gap I guess I could include a "Change Encoding" option
for the diff pane and let you set the encoding to a specific name.
But I really think git-gui should be able to do better than that.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-01 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7he6ufj.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 18, 2007 at 12:29:52AM -0700, Junio C Hamano wrote:
> Passing of ce instead of path in the unpack-trees callchain
> looks like the right thing to do. Good job.
Actually, my patch only fixes the tip of the iceberg.
If you have a submodule checked out and you go back (or forward)
to a revision of the supermodule that contains a different
revision of the submodule and then switch to another revision,
it will complain that the submodule is not uptodate, because
git simply didn't update the submodule in the first move.
Now, you may say that I simply need to run 'git submodule update'
after every such move, but this is very inconvenient, especially
if you're doing a bisect or a rebase.
How do other people deal with this problem?
How about just replacing the body of ce_compare_gitlink
with "return 0" until git actually (optionally) updates
the submodules during an update of the supermodule?
skimo
^ permalink raw reply
* Re: dangling blob which is not dangling at all
From: Domenico Andreoli @ 2007-08-01 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <46B04EB7.80006@dawes.za.net>
On Wed, Aug 01, 2007 at 11:13:27AM +0200, Rogan Dawes wrote:
> Steven Grimm wrote:
>> Domenico Andreoli wrote:
>>> What is this reflog thing and why is required?
>>>
>> It is a log of where each ref pointed at any given time. Or rather, a log
>> of changes to refs, with timestamps. It is not *required* per se (you can
>> turn it off and almost all of git will continue to work as before) but
>> it's handy in that you can say stuff like
>> git checkout -b newbranch master@"{4 days ago}"
>> and git will give you a new branch pointing at the rev that master pointed
>> to 4 days ago, even if it's a rev that is no longer reachable from any of
>> the existing heads (e.g., because you did a "git rebase" and the rev in
>> question was replaced by a new one.) Obviously as soon as you do a "git
>> gc" you will lose the ability to go back to unreachable revs using the
>> reflog.
>
> Not strictly true. "git gc" does take the reflogs into account when
> determining reachability, but it also prunes the reflogs periodically to
> prevent them from growing without bound (and preventing pruning of
> otherwise unreachable objects).
so, besides playing with head refs by hand and forcing pushing to
"not strict subset" heads, having dangling commits may be physiologic?
and the only way to leak commits is from heads? on the countary, has
one a severely broken repository?
many thanks,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: Git clone error
From: Denis Bueno @ 2007-08-01 14:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707311924590.4161@woody.linux-foundation.org>
On 07/31/2007 20:38, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
> Please do
>
> cd /Volumes/work/scripts
> git fsck --full
>
> which I would guess will almost certainly talk about some kind of problems
> with that object "b28b949a1a3c8eb37ca6eefd024508fa8b253429". And possibly
> more.
Indeed:
scripts[10] > git fsck --full
error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or
missing
missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429
Fortunately, it's the only one.
> There are certainly ways to figure out what that object _should_ be,
> though. For example, if that object is the only corrupted entry, and it's
> a blob (ie pure data object), what you can generally do is still use the
> repo (as long as you avoid that particular blob), and do things like
>
> git log --raw -r --no-abbrev
scripts[11] > git log --raw -r --no-abbrev | grep
b28b949a1a3c8eb37ca6eefd024508fa8b253429
:100755 100755 b28b949a1a3c8eb37ca6eefd024508fa8b253429
9dbd5bb59198ab59e1850f838f2ed27c77364cde M condor/condor-uninstall.sh
:000000 100755 0000000000000000000000000000000000000000
b28b949a1a3c8eb37ca6eefd024508fa8b253429 A condor/condor-uninstall.sh
> and you'll see the git history with all blobs named with their SHA1's.
> Then you can just search for that b28b949.. name, and you'll see exactly
> which file (in which version) it was, and if you can just find a backup of
> that file (or re-create it *exactly* from previous versions and your
> memory of it), you can re-generate the git object and thus save your
> repository.
When you say "re-generate", do you mean `git add <file> ; git commit
<file>`? Or something a bit more clever? I suspect you actually meant the
latter, since you suggest recreating it *exactly*.
If I just recreate a version I'm happy with, can I add that to the repo and
go from there?
> Of course, a much easier option tends to be to just have a backup
> repository that has that object in it, and then you can literally just
> copy that b28b949 object over.
No such luck, but I'll back up my repos in the future. Any hint on what
might have caused this kind of corruption? That repo was created on my
laptop and only edited there; it's not a clone from some other machine.
It's possible that I have Ctrl-C'd some git operation in the past -- could
that have caused it?
Is there anything (e.g. trapping signals if a blob is being written until
it's done, or backing out of the current blob on SIG{INT,HUP}) that could
make this kind of corruption less easy to encounter? I ask because I have
used VC systems (i.e. CVS, SVN, darcs, and now git) for 4+ years (not long
by any means, but long enough) and the only repository corruption I had ever
encountered was after I went mucking about in a CVS repo's internal
representation -- and I deserved that.
Denis
--
"Dealing with failure is easy: Work hard to improve. Success is also easy to
handle: You've solved the wrong problem. Work hard to improve." -- Perlis
^ permalink raw reply
* git-commit --amend -m "..." complains?!?
From: David Kastrup @ 2007-08-01 14:25 UTC (permalink / raw)
To: git
I get
Option -m cannot be combined with -c/-C/-F/--amend.
but that makes no sense: of course there is ample reason for providing
an amended commit message on the command line. -c, -C and -F indeed
all provide an alternative commit message, but --amend doesn't.
So what is the beef?
--
David Kastrup
^ permalink raw reply
* [PATCH] rebase -i: ignore patches that are in upstream already
From: Johannes Schindelin @ 2007-08-01 14:59 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <46B06E56.2040206@gmail.com>
Non-interactive rebase had this already, exploiting format-patch's option
--ignore-if-in-upstream. We replicate the same behaviour here with
--cherry-pick.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 1 Aug 2007, Mark Levedahl wrote:
> git rebase -i does not correctly ignore commits in the local
> branch that are also in upstream. For example, create a branch
> that is two commits back from upstream, add one of those on to
> the local branch
>
> upstream=83b3df7d58
> git checkout -f $upstream
> git checkout -b foo $upstream~2
> git cherry-pick $upstream~1
> git rebase -i $upstream
>
> "git rebase -i" happily presents commit "$upstream~1" in the
> list to be applied to upstream. This of course results in a
> conflict. Should the user simply delete the offending commit
> from the presented list, git rebase -i then refuses to do
> anything, saying "Nothing to do."
>
> Bare "git rebase" handles this case correctly (essentially fast
> forwards the branch to upstream.
Right.
git-rebase--interactive.sh | 5 +++--
t/t3404-rebase-interactive.sh | 15 +++++++++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 061cd0a..d3addd4 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -463,8 +463,9 @@ do
#
EOF
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse $UPSTREAM..$HEAD | \
- sed "s/^/pick /" >> "$TODO"
+ --abbrev=7 --reverse --left-right --cherry-pick \
+ $UPSTREAM...$HEAD | \
+ sed -n "s/^>/pick /p" >> "$TODO"
test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
die_abort "Nothing to do"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 817f614..dc436d7 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -68,6 +68,9 @@ test "\$1" = .git/COMMIT_EDITMSG && {
test -z "\$FAKE_COMMIT_AMEND" || echo "\$FAKE_COMMIT_AMEND" >> "\$1"
exit
}
+test -z "\$EXPECT_COUNT" ||
+ test "\$EXPECT_COUNT" = \$(grep -ve "^#" -e "^$" < "\$1" | wc -l) ||
+ exit
test -z "\$FAKE_LINES" && exit
grep -v "^#" < "\$1" > "\$1".tmp
rm "\$1"
@@ -251,4 +254,16 @@ test_expect_success 'interrupted squash works as expected' '
test $one = $(git rev-parse HEAD~2)
'
+test_expect_success 'ignore patch if in upstream' '
+ HEAD=$(git rev-parse HEAD) &&
+ git checkout -b has-cherry-picked HEAD^ &&
+ echo unrelated > file7 &&
+ git add file7 &&
+ test_tick &&
+ git commit -m "unrelated change" &&
+ git cherry-pick $HEAD &&
+ EXPECT_COUNT=1 git rebase -i $HEAD &&
+ test $HEAD = $(git rev-parse HEAD^)
+'
+
test_done
--
1.5.3.rc3.112.gf60b6
^ permalink raw reply related
* [NOT-SERIOUS PATCH] Make get_relative_cwd() not accept NULL for a directory
From: Johannes Schindelin @ 2007-08-01 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vwswfbywq.fsf@assigned-by-dhcp.cox.net>
Earlier, get_relative_cwd() interpreted "dir == NULL" as "outside of the dir",
and therefore returned NULL. Be more strict now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
As promised.
Okay, I made up my mind. Allowing "dir == NULL" is not only a matter of
convenience. It is the most natural way to say that "dir" is an invalid
or non-existing directory.
Besides, this patch adds 14.286% more lines than it removes ;-)
But ultimately, it is your decision, Junio, and I am d'accord with
what you choose.
dir.c | 3 ---
setup.c | 10 +++++++---
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index b3329f4..cfcde13 100644
--- a/dir.c
+++ b/dir.c
@@ -646,7 +646,6 @@ file_exists(const char *f)
/*
* get_relative_cwd() gets the prefix of the current working directory
* relative to 'dir'. If we are not inside 'dir', it returns NULL.
- * As a convenience, it also returns NULL if 'dir' is already NULL.
*/
char *get_relative_cwd(char *buffer, int size, const char *dir)
{
@@ -656,8 +655,6 @@ char *get_relative_cwd(char *buffer, int size, const char *dir)
* a lazy caller can pass a NULL returned from get_git_work_tree()
* and rely on this function to return NULL.
*/
- if (!dir)
- return NULL;
if (!getcwd(buffer, size))
die("can't find the current directory: %s", strerror(errno));
diff --git a/setup.c b/setup.c
index 3653092..2f720f8 100644
--- a/setup.c
+++ b/setup.c
@@ -183,8 +183,10 @@ int is_inside_git_dir(void)
int is_inside_work_tree(void)
{
- if (inside_work_tree < 0)
- inside_work_tree = is_inside_dir(get_git_work_tree());
+ if (inside_work_tree < 0) {
+ const char *work_tree = get_git_work_tree();
+ inside_work_tree = work_tree ? is_inside_dir(work_tree) : 0;
+ }
return inside_work_tree;
}
@@ -370,10 +372,12 @@ const char *setup_git_directory(void)
/* If the work tree is not the default one, recompute prefix */
if (inside_work_tree < 0) {
static char buffer[PATH_MAX + 1];
+ const char *work_tree;
char *rel;
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
- rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
+ work_tree = get_git_work_tree();
+ rel = work_tree ? get_relative_cwd(buffer, PATH_MAX, work_tree) : NULL;
return rel && *rel ? strcat(rel, "/") : NULL;
}
--
1.5.3.rc3.112.gf60b6
^ permalink raw reply related
* [PATCH] Try to be consistent with capitalization in the documentation
From: Steve Hoelzer @ 2007-08-01 15:43 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
---
Try to be consistent with capitalization in the documentation.
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bc6aa88..198ab47 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -134,8 +134,8 @@ $ git branch -d -r origin/todo origin/html origin/
man <1>
$ git branch -D test <2>
------------
+
-<1> delete remote-tracking branches "todo", "html", "man"
-<2> delete "test" branch even if the "master" branch does not have all
+<1> Delete remote-tracking branches "todo", "html", "man".
+<2> Delete "test" branch even if the "master" branch does not have all
commits from test branch.
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index b1f5e7f..b36e705 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -76,10 +76,10 @@ $ git diff --cached <2>
$ git diff HEAD <3>
------------
+
-<1> changes in the working tree not yet staged for the next commit.
-<2> changes between the index and your last commit; what you
+<1> Changes in the working tree not yet staged for the next commit.
+<2> Changes between the index and your last commit; what you
would be committing if you run "git commit" without "-a" option.
-<3> changes in the working tree since your last commit; what you
+<3> Changes in the working tree since your last commit; what you
would be committing if you run "git commit -a"
Comparing with arbitrary commits::
@@ -90,12 +90,12 @@ $ git diff HEAD -- ./test <2>
$ git diff HEAD^ HEAD <3>
------------
+
-<1> instead of using the tip of the current branch, compare with the
+<1> Instead of using the tip of the current branch, compare with the
tip of "test" branch.
-<2> instead of comparing with the tip of "test" branch, compare with
+<2> Instead of comparing with the tip of "test" branch, compare with
the tip of the current branch, but limit the comparison to the
file "test".
-<3> compare the version before the last commit and the last commit.
+<3> Compare the version before the last commit and the last commit.
Limiting the diff output::
@@ -106,11 +106,11 @@ $ git diff --name-status <2>
$ git diff arch/i386 include/asm-i386 <3>
------------
+
-<1> show only modification, rename and copy, but not addition
+<1> Show only modification, rename and copy, but not addition
nor deletion.
-<2> show only names and the nature of change, but not actual
+<2> Show only names and the nature of change, but not actual
diff output.
-<3> limit diff output to named subtrees.
+<3> Limit diff output to named subtrees.
Munging the diff output::
+
@@ -119,9 +119,9 @@ $ git diff --find-copies-harder -B -C <1>
$ git diff -R <2>
------------
+
-<1> spend extra cycles to find renames, copies and complete
+<1> Spend extra cycles to find renames, copies and complete
rewrites (very expensive).
-<2> output diff in reverse.
+<2> Output diff in reverse.
Author
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 2c9db98..2e1b7b6 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -107,11 +107,11 @@ pull after you are done and ready.
When things cleanly merge, these things happen:
-1. the results are updated both in the index file and in your
- working tree,
-2. index file is written out as a tree,
-3. the tree gets committed, and
-4. the `HEAD` pointer gets advanced.
+1. The results are updated both in the index file and in your
+ working tree.
+2. Index file is written out as a tree.
+3. The tree gets committed.
+4. The `HEAD` pointer gets advanced.
Because of 2., we require that the original state of the index
file to match exactly the current `HEAD` commit; otherwise we
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 19c5b9b..15e3aca 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -63,7 +63,7 @@ $ git commit -a -c ORIG_HEAD <3>
<1> This is most often done when you remembered what you
just committed is incomplete, or you misspelled your commit
message, or both. Leaves working tree as it was before "reset".
-<2> make corrections to working tree files.
+<2> Make corrections to working tree files.
<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
commit by starting with its log message. If you do not need to
edit the message further, you can give -C option instead.
@@ -106,17 +106,17 @@ $ git reset <3>
$ git pull git://info.example.com/ nitfol <4>
------------
+
-<1> you are happily working on something, and find the changes
+<1> You are happily working on something, and find the changes
in these files are in good order. You do not want to see them
when you run "git diff", because you plan to work on other files
and changes with these files are distracting.
-<2> somebody asks you to pull, and the changes sounds worthy of
merging.
-<3> however, you already dirtied the index (i.e. your index does
+<2> Somebody asks you to pull, and the changes sounds worthy of
merging.
+<3> However, you already dirtied the index (i.e. your index does
not match the HEAD commit). But you know the pull you are going
to make does not affect frotz.c nor filfre.c, so you revert the
index changes for these two files. Your changes in working tree
remain there.
-<4> then you can pull and merge, leaving frotz.c and filfre.c
+<4> Then you can pull and merge, leaving frotz.c and filfre.c
changes still in the working tree.
Undo a merge or pull::
@@ -133,15 +133,15 @@ Fast forward
$ git reset --hard ORIG_HEAD <4>
------------
+
-<1> try to update from the upstream resulted in a lot of
+<1> Try to update from the upstream resulted in a lot of
conflicts; you were not ready to spend a lot of time merging
right now, so you decide to do that later.
<2> "pull" has not made merge commit, so "git reset --hard"
which is a synonym for "git reset --hard HEAD" clears the mess
from the index file and the working tree.
-<3> merge a topic branch into the current branch, which resulted
+<3> Merge a topic branch into the current branch, which resulted
in a fast forward.
-<4> but you decided that the topic branch is not ready for public
+<4> But you decided that the topic branch is not ready for public
consumption yet. "pull" or "merge" always leaves the original
tip of the current branch in ORIG_HEAD, so resetting hard to it
brings your index file and the working tree back to that state,
^ 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