* [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
* Re: [PATCH 1/3] rebase -i: handle --continue more like non-interactive rebase
From: Johannes Schindelin @ 2007-08-01 15:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, gitster
In-Reply-To: <20070712222640.GA30532@steel.home>
Hi,
On Fri, 13 Jul 2007, Alex Riesen wrote:
> Johannes Schindelin, Sun, Jul 08, 2007 04:01:29 +0200:
> > Non-interactive rebase requires the working tree to be clean, but
> > applies what is in the index without requiring the user to do it
> > herself. Imitate that, but (since we are interactive, after all)
> > fire up an editor with the commit message.
>
> Could we also have "git rebase <base> <branch>"?
Don't we do that already? AFAICT it is already in the synopsis, ever
since rebase -i was introduced into the "next" branch, on June 25...
Ciao,
Dscho
^ permalink raw reply
* git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-01 16:17 UTC (permalink / raw)
To: git
Hi,
When a file is "touched" (ie. stat information not matching the index,
but the content still matching), git-status doesn't report the file as
modified (as expected), but git-diff does (with an empty diff):
$ git st
# On branch master
nothing to commit (working directory clean)
$ ls
bar
$ touch bar
$ git diff
diff --git a/bar b/bar <--- here ---<
$ git status
# On branch master
nothing to commit (working directory clean)
$ git diff <--- status updated
the stat in the index.
Is this intended, or just that the code that reconciles the file and
the index has been written for status, but not used in diff?
Thanks,
--
Matthieu
^ permalink raw reply
* Re: Git clone error
From: Linus Torvalds @ 2007-08-01 16:19 UTC (permalink / raw)
To: Denis Bueno; +Cc: Git Mailing List
In-Reply-To: <C2D5F3B2.2B00%denbuen@sandia.gov>
On Wed, 1 Aug 2007, Denis Bueno wrote:
>
> Indeed:
>
> scripts[10] > git fsck --full
> error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or missing
> missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429
>
> Fortunately, it's the only one.
Ok. That's the "easy" case, although the fact that the file went missing
in the first place is certainly worrisome.
I think you said you were using OS X - have you seen crashes or are you
using something like the experimental ZFS support?
Memory and disk corruption is also a possibility, so running fsck (I have
*no* idea how you do that under OS X, but I bet others on the list know)
is a good idea.
Also, *if* you actually have the file
.git/objects/b2/8b949a1a3c8eb37ca6eefd024508fa8b253429
and it's not just missing entirely, please move it out, ie do something
like
mv .git/objects/b2/8b949a1a3c8eb37ca6eefd024508fa8b253429 ~/corrupt-object
You want to move it away from the .git/objects directory in any case,
because if it exists (but is corrupted), git will never overwrite it with
the non-corrupted version. And you don't want to just delete it, because
I'd love to see exactly *what* the corruption was.
> > 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
Ok, great. So it's the very first version of "condor/condor-uninstall.sh".
If you can find that original version, great. If not, you can get the
*second* version by doing
git cat-file blob 9dbd5bb59198ab59e1850f838f2ed27c77364cde > second-version
and if you remember what your changes were, try to just edit that back to
the exact thing it was in the first version, if you can (note that by
"exact", I do mean *exact*. Whitespace and all).
> 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*.
Actually you can literally just do
git add my-regenerated-file
and it would do the right thing. But it also changes your index, so a
better way would often be to do
git hash-object -w <filename>
which will take any random file, and hash it into the object database.
So if you were able to re-generate the original, you should now have a
*non*corrupted .git/objects/b2/8b949a1a3c8eb37ca6eefd024508fa8b253429
file, and git-fsck will be happy again!
And after that, I'd really like to see both the corrupt and the
non-corrupt object, to try to figure out what the corruption is.
> If I just recreate a version I'm happy with, can I add that to the repo and
> go from there?
Well, it's not so much a version _you_ are happy with: you'd have to be
able to re-create the exact old version (with the exact same SHA1), in
order for git to be happy.
> 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?
No, things like Ctrl-C are safe: we create new objects by writing them to
a temporary file, and then using an atomic rename() operation on them
(actually, a "link() + unlink()", but we fall back to "rename()" if that
fails - some filesystems cannot link files between directories).
So the only way to get corruption is literally with a broken filesystem,
or memory corruption. Of course, if the OS's "rename()" is broken, and
isn't atomic (ie if it's "copy + delete" operation).
Of course, git bugs could do this, but quite frankly, this is (a) very
simple code, and (b) we really haven't had bugs in this area.
Git does end up finding corruption that other VCS's don't. The strong
hashes and the fact that fsck (and, in fact, even simple operations like
clone) will check every single hash, means that single-bit corruption gets
noticed (and is a fatal error) every time. Other SCM's? Not so much.
Linus
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Carl Worth @ 2007-08-01 15:49 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>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Wed, 01 Aug 2007 03:15:25 -0700, Junio C Hamano wrote:
>
> 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.
Personally, I think it would be a great default.
And I think the frequency with which you type this command is not a
good metric for deciding if a command-line option should be required.
Instead, the focus should be on having good defaults for a good user
experience, (for example, the benchmarking that started this thread
that gave a bad first impression of git).
So, just making git-clone go as fast as possible when local, without
requiring any additional options from the user, would be a very good
thing.
As for the concern that new users might do local clones in the hope to
get some redundancy, hopefully the fact that the operation is
instantaneous will give plenty of clue to the user that no redundancy
has been provided. That should be enough to send the user looking for
the documentation to find the --no-hard-links option.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git clone error
From: Steffen Prohaska @ 2007-08-01 16:37 UTC (permalink / raw)
To: Denis Bueno; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <alpine.LFD.0.999.0708010846360.3582@woody.linux-foundation.org>
On Aug 1, 2007, at 6:19 PM, Linus Torvalds wrote:
>
> Memory and disk corruption is also a possibility, so running fsck
> (I have
> *no* idea how you do that under OS X, but I bet others on the list
> know)
> is a good idea.
AppleJack is the easiest way I know of:
http://applejack.sourceforge.net/
Steffen
^ permalink raw reply
* Re: Git clone error
From: Linus Torvalds @ 2007-08-01 16:36 UTC (permalink / raw)
To: Denis Bueno; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.999.0708010846360.3582@woody.linux-foundation.org>
On Wed, 1 Aug 2007, Linus Torvalds wrote:
>
> > If I just recreate a version I'm happy with, can I add that to the repo and
> > go from there?
>
> Well, it's not so much a version _you_ are happy with: you'd have to be
> able to re-create the exact old version (with the exact same SHA1), in
> order for git to be happy.
Btw, if you really cannot re-generate it, you'd basically need to create a
whole new git archive without that blob (or basically with that blob
replaced by another version).
We don't have wonderfully good support for that, because, quite frankly,
we've not had this happen before. I think every time before, people have
had the blob in some other copy of their git archive.
But the thing to use is "git filter-branch", which can take a git history
and munge it arbitrarily. It would be the "tree-filter" that you'd use to
replace that one blob that you cannot regenerate with another (ie you
might decide to just replace the original version of the file with that
*second* version, and regenerate the tree that way).
I'm cc'ing Dscho explicitly to see if he can help you with the exact
syntax, and maybe we could even make this into a user-manual entry about
how to handle corruption. I don't think we have anything in the
documentation about this - we only cover the trivial cases where the
objects are all good, but you've lost the pointers into it because you
removed a branch by mistake or something.
Linus
^ permalink raw reply
* Re: [NOT-SERIOUS PATCH] Make get_relative_cwd() not accept NULL for a directory
From: Junio C Hamano @ 2007-08-01 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0708011624260.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.
That is also fine; it only needs to be clarified somehow to
people who might wonder what get_relative_cwd() function is used
for and how to use it in their programs. The comment that says
"As a convenience" may need to become a bit more elaborate to
say why it is convenient for the callers to do so (e.g. "The
caller may have called another function that returns a directory
to obtain the 'dir', which may have returned NULL as a way to
say 'there is nothing applicable in your case', and in such a
case, your $(cwd) relative to that 'dir' is also something that
cannot be used, hence a NULL is returned").
^ permalink raw reply
* Re: [PATCH] Try to be consistent with capitalization in the documentation
From: Junio C Hamano @ 2007-08-01 17:00 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git
In-Reply-To: <514D28CB-25F8-49B2-921E-8EFA60BE864C@gmail.com>
Steve Hoelzer <shoelzer@gmail.com> writes:
> Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
> ---
>
> Try to be consistent with capitalization in the documentation.
It looks like that all the originals are trying to consistently
start with lowercase in an explanatory list. Is this really
needed?
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Linus Torvalds @ 2007-08-01 17:03 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Theodore Tso, Jakub Narebski, Git Mailing List
In-Reply-To: <87tzrjfe5h.wl%cworth@cworth.org>
On Wed, 1 Aug 2007, Carl Worth wrote:
>
> On Wed, 01 Aug 2007 03:15:25 -0700, Junio C Hamano wrote:
> >
> > 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.
>
> Personally, I think it would be a great default.
I suspect it probably *would* make sense to default to "-l". Even if it
makes me get goose-bumps. I freely admit that my worries are totally
illogical.
We might make it something like: "if you use an url, we don't default to
local", so the difference would be that
git clone file:///directory/to/repo
would work the way it does now, but
git clone /directory/to/repo
would default to "-l" behaviour. That kind of would make sense (and should
be easy to implement: it would be a trivial fixup to "connect.c".
Something like this adds support for "file://". And then git-clone could
just do something like
# if the source is a local directory, default to local
if [ -d "$src" ]; then
use_local=yes
fi
or similar.
Linus
---
connect.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/connect.c b/connect.c
index 715cdc0..ae49c5a 100644
--- a/connect.c
+++ b/connect.c
@@ -145,6 +145,8 @@ static enum protocol get_protocol(const char *name)
return PROTO_SSH;
if (!strcmp(name, "ssh+git"))
return PROTO_SSH;
+ if (!strcmp(name, "file"))
+ return PROTO_LOCAL;
die("I don't handle protocol '%s'", name);
}
@@ -498,13 +500,13 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
end = host;
path = strchr(end, c);
- if (c == ':') {
- if (path) {
+ if (path) {
+ if (c == ':') {
protocol = PROTO_SSH;
*path++ = '\0';
- } else
- path = host;
- }
+ }
+ } else
+ path = end;
if (!path || !*path)
die("No path specified. See 'man git-pull' for valid url syntax");
^ permalink raw reply related
* Re: Interpreting EDITOR/VISUAL environment variables.
From: Junio C Hamano @ 2007-08-01 17:12 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86abtbnzpr.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> 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?
I've been torn on this one. From the point of view of
"specified behaviour in the documentation", which is "EDITOR and
VISUAL name the editor of your choice", not splicing is not
violating the letter (I am not talking about our documentation
here, but many other programs'). Splicing and shell quoting
other parameters, while it is technically not a problem at all
doing that in scripts, feels "dirty". Maybe it's just me.
Both cvs and svn seems to splice, I suspect they just do a
straight system(3) invocation.
We recently normalized the script callers not to splice at all
(the scripts were hand-rolling "the VISUAL or EDITOR or vi" and
slightly differently). It obviously has negative (i.e. setting
EDITOR to "emacsclient --alternate-editor vi" does not work) as
well as positive side (i.e. "/home/dak/My Programs/editor" would
work).
^ permalink raw reply
* Re: [PATCH] Try to be consistent with capitalization in the documentation
From: Steve Hoelzer @ 2007-08-01 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir7z5gx7.fsf@assigned-by-dhcp.cox.net>
On 8/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> Steve Hoelzer <shoelzer@gmail.com> writes:
>
> > Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
> > ---
> >
> > Try to be consistent with capitalization in the documentation.
>
> It looks like that all the originals are trying to consistently
> start with lowercase in an explanatory list. Is this really
> needed?
The lists I changed were indeed all lowercase, but other lists in
those files are all uppercase. I was aiming for consistency across all
list items and all lists.
Steve
^ permalink raw reply
* Re: Git clone error
From: Johannes Schindelin @ 2007-08-01 17:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Denis Bueno, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0708010929070.3582@woody.linux-foundation.org>
Hi,
On Wed, 1 Aug 2007, Linus Torvalds wrote:
> On Wed, 1 Aug 2007, Linus Torvalds wrote:
> >
> > > If I just recreate a version I'm happy with, can I add that to the repo and
> > > go from there?
> >
> > Well, it's not so much a version _you_ are happy with: you'd have to
> > be able to re-create the exact old version (with the exact same SHA1),
> > in order for git to be happy.
>
> Btw, if you really cannot re-generate it, you'd basically need to create
> a whole new git archive without that blob (or basically with that blob
> replaced by another version).
>
> We don't have wonderfully good support for that, because, quite frankly,
> we've not had this happen before. I think every time before, people have
> had the blob in some other copy of their git archive.
>
> But the thing to use is "git filter-branch", which can take a git history
> and munge it arbitrarily. It would be the "tree-filter" that you'd use to
> replace that one blob that you cannot regenerate with another (ie you
> might decide to just replace the original version of the file with that
> *second* version, and regenerate the tree that way).
>
> I'm cc'ing Dscho explicitly to see if he can help you with the exact
> syntax, and maybe we could even make this into a user-manual entry about
> how to handle corruption. I don't think we have anything in the
> documentation about this - we only cover the trivial cases where the
> objects are all good, but you've lost the pointers into it because you
> removed a branch by mistake or something.
I doubt it would be that easy; the tree filter expects a _valid_ tree,
which it checks out, and only then you can filter it.
But this is what I would do if I had the problem: I would try to create
a state which is as close to the corrupt revision as possible,
use a graft to replace the initial commit with that revision, and
rewrite the branch. I'd probably start by doing something like this:
$ git symbolic-ref HEAD refs/heads/recreate-first && rm .git/index
$ git ls-tree -r --name-only <initial-commit> |
grep -v "^condor/condor-uninstall.sh$" |
xargs git checkout <initial-commit>
$ git checkout <second-commit> condor/condor-uninstall.sh
[possibly some minor hacking on the latter file to make it work]
$ git commit -c <initial-commit>
This starts a new branch, which has no ancestor yet. It takes all files
except the corrupt one from the first commit, and a replacement of the
corrupt one from the second commit. Then it takes all the meta-data from
the first commit to create a replacement for the first commit.
Now I'd graft the second commit onto the first:
$ git rev-parse <second-commit> recreate-first >> .git/info/grafts
This explicitely tells git to disregard the parent information given in
<second-commit>, and to pretend that the recreated commit is its parent.
BEWARE! Grafts are a powerful weapon, and you can spend tons of
time looking for an error, when all you did was grafting parts of
the history onto other parts of the history. For example, I was
searching several nights for the bug preventing me to push one of
my repos, and it always gave an "unpacking" error. Once I moved
the grafts out of the way, it miraculously worked.
After that, just call git-filter-branch (not yet released, but will
probably be part of 1.5.3):
$ git filter-branch <branchname>
Many things can go wrong through that process, so you want to make sure
that all steps actually worked as intended (especially since I tested
none of this, but wrote it in the mail program)!
Hth,
Dscho
^ permalink raw reply
* Re: git-commit --amend -m "..." complains?!?
From: Junio C Hamano @ 2007-08-01 17:18 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86643znxgz.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> 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.
The option --amend is about "reusing the original commit message
and make amending edit on top". If you are restarting the
message from scratch, --amend does not make much sense.
You can do:
$ git reset HEAD^
$ git commit -m "blah"
if you do not want to reuse the commit message.
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-01 17:26 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwswf8c1i.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> $ touch bar
> $ git diff
> diff --git a/bar b/bar <--- here ---<
> $ git status
> # On branch master
> nothing to commit (working directory clean)
> $ git diff <--- status updated
> the stat in the index.
>
> Is this intended,
Yes. Very much so, intentionally, from very early days of git.
This serves as a reminder to the user that he started editing
but changed his mind to end up with the same contents as the
original, until the next "update-index --refresh" (which is
internally invoked from "status").
If the feature still makes sense in the modern world is a
different story, but I do find it useful.
Not the made-up "touch" example, but often in real life, I
explore a solution by first making changes to one part of the
system, realizing a better way is to change the caller of what I
initially thought should be changed, edit the file back and
modify the caller which is in another file. The former file
will show that empty "header-only" diff as the reminder of what
I did.
After that, when I reach the point to run "git status", because
I have been reminded, I already know about these "tried but
discarded" changes, and I find the fact that the they are forgot
by that operation very convenient.
^ permalink raw reply
* Re: [PATCH] Add a --user option to git-config
From: Ramsay Jones @ 2007-07-31 21:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <Pine.LNX.4.64.0707282103150.14781@racer.site>
Johannes Schindelin wrote:
> On Sat, 28 Jul 2007, Ramsay Jones wrote:
>
>> At present, the --global option is something of a misnomer, so
>> we introduce the --user option as a synonym, with the intention
>> of removing the old option in the future.
>
> Ack for the intention, except for "removing the old option in the future".
> We do not need to advertise it, but breaking existing functionality, which
> might be used by scripts and aliases is bad.
>
Yep, which is why I made it a synonym; git-gui uses the --global option, for
example, and I'm confident that other (user) scripts use it too. The "future"
I had in mind was something like 1 year down the road, but it could be longer
(or forever) if necessary.
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Add a --user option to git-config
From: Johannes Schindelin @ 2007-08-01 18:13 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <46AFAF7D.7010306@ramsay1.demon.co.uk>
Hi,
On Tue, 31 Jul 2007, Ramsay Jones wrote:
> Johannes Schindelin wrote:
> > On Sat, 28 Jul 2007, Ramsay Jones wrote:
> >
> >> At present, the --global option is something of a misnomer, so
> >> we introduce the --user option as a synonym, with the intention
> >> of removing the old option in the future.
> >
> > Ack for the intention, except for "removing the old option in the future".
> > We do not need to advertise it, but breaking existing functionality, which
> > might be used by scripts and aliases is bad.
> >
>
> Yep, which is why I made it a synonym; git-gui uses the --global option, for
> example, and I'm confident that other (user) scripts use it too. The "future"
> I had in mind was something like 1 year down the road, but it could be longer
> (or forever) if necessary.
Please read my reply as "I vote against ever removing the --global
option".
Ciao,
Dscho
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: David Kastrup @ 2007-08-01 18:17 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0708010937050.3582@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I suspect it probably *would* make sense to default to "-l". Even if it
> makes me get goose-bumps. I freely admit that my worries are totally
> illogical.
>
> We might make it something like: "if you use an url, we don't default to
> local",
Couldn't git clone http://host/directory/to/repo tell the proxy that
it should enter off-line mode and stop updating?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] get_relative_cwd(): clarify why it handles dir == NULL
From: Johannes Schindelin @ 2007-08-01 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vmyxb5h0g.fsf@assigned-by-dhcp.cox.net>
The comment did not make a good case why it makes sense. It does so now.
Pointed out by Junio Hamano.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
dir.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/dir.c b/dir.c
index b3329f4..791c566 100644
--- a/dir.c
+++ b/dir.c
@@ -646,7 +646,16 @@ 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.
+ *
+ * As a convenience, it also returns NULL if 'dir' is already NULL. The
+ * reason for this behaviour is that it is natural for functions returning
+ * directory names to return NULL to say "this directory does not exist"
+ * or "this directory is invalid". These cases are usually handled the
+ * same as if the cwd is not inside 'dir' at all, so get_relative_cwd()
+ * returns NULL for both of them.
+ *
+ * Most notably, get_relative_cwd(buffer, size, get_git_work_tree())
+ * unifies the handling of "outside work tree" with "no work tree at all".
*/
char *get_relative_cwd(char *buffer, int size, const char *dir)
{
--
1.5.3.rc3.112.gf60b6
^ permalink raw reply related
* Re: [PATCH] Add a --user option to git-config
From: Junio C Hamano @ 2007-08-01 18:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <Pine.LNX.4.64.0708011913070.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Yep, which is why I made it a synonym; git-gui uses the
>> --global option, for example, and I'm confident that other
>> (user) scripts use it too. The "future" I had in mind was
>> something like 1 year down the road, but it could be longer
>> (or forever) if necessary.
>
> Please read my reply as "I vote against ever removing the --global
> option".
I would say with --system present, I do not see much point
having the new alias --user either. Get used to it. It is
global across the repositories you have control over.
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: Yann Dirson @ 2007-08-01 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7vd4y75gcy.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 01, 2007 at 10:12:13AM -0700, Junio C Hamano wrote:
> We recently normalized the script callers not to splice at all
> (the scripts were hand-rolling "the VISUAL or EDITOR or vi" and
> slightly differently). It obviously has negative (i.e. setting
> EDITOR to "emacsclient --alternate-editor vi" does not work) as
> well as positive side (i.e. "/home/dak/My Programs/editor" would
> work).
And, indeed, --alternate-editor could be supplemented by another
envvar to be able to work in our situation. Maybe the various emacsen
vendors would be willing to integrate such a patch ?
Best regards,
--
Yann
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Alexandre Julliard @ 2007-08-01 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Yes. Very much so, intentionally, from very early days of git.
> This serves as a reminder to the user that he started editing
> but changed his mind to end up with the same contents as the
> original, until the next "update-index --refresh" (which is
> internally invoked from "status").
It would be nice to have a way to refresh a single file though. For
instance in vc-git.el the workfile-unchanged-p function currently has
to rehash the file every time to see if it really changed, because we
can't afford to refresh the whole project at that point.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-01 19:07 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Matthieu Moy, git
In-Reply-To: <87vebzkrid.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> .... For
> instance in vc-git.el the workfile-unchanged-p function currently has
> to rehash the file every time to see if it really changed, because we
> can't afford to refresh the whole project at that point.
Maybe I am missing something. Why can't you "afford to"?
"update-index --refresh" looks at only the files whose cached
stat information does indicate there might be chanegs. It does
not rehash already up-to-date ones.
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: David Kastrup @ 2007-08-01 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4y75gcy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> 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?
>
> I've been torn on this one. From the point of view of
> "specified behaviour in the documentation", which is "EDITOR and
> VISUAL name the editor of your choice", not splicing is not
> violating the letter (I am not talking about our documentation
> here, but many other programs'). Splicing and shell quoting
> other parameters, while it is technically not a problem at all
> doing that in scripts, feels "dirty". Maybe it's just me.
>
> Both cvs and svn seems to splice, I suspect they just do a
> straight system(3) invocation.
>
> We recently normalized the script callers not to splice at all
> (the scripts were hand-rolling "the VISUAL or EDITOR or vi" and
> slightly differently). It obviously has negative (i.e. setting
> EDITOR to "emacsclient --alternate-editor vi" does not work) as
> well as positive side (i.e. "/home/dak/My Programs/editor" would
> work).
Well, I just checked the behavior with "less", "more", "mail" and
"mailx", quite traditional commands that would not have a reason to
complicate things by using "system" and quoting instead of exec.
less, mail and mailx apparently go via system, more (wtf?!?)
apparently via exec.
Taken together with the behavior by cvs and svn, I think we should not
just throw EDITOR/VISUAL into one exec arg.
Then there are two implementations to pick from:
a) Using system and shell-quoting the filename. Advantage: one can
set EDITOR='"/home/dak/My Programs/editor"' and have it work.
Disadvantage: shell-quoting a file name seems shell- and
system-dependent.
It turns out all three contestants still in the race apparently do a).
If nobody has a sensible idea how to shell-quote generally enough...
Under Unix, one has the option of using "..." and quoting the three of
"$\ with \ or using '...' and replacing every contained ' with '\''.
I don't think that there is a library function generally available.
The " quote type would probably be more typical.
It turns out that gitk and gitk-wish _already_ do this. So the
normalization does not seem to have covered them if I read the code
correctly:
proc shellquote {str} {
if {![string match "*\['\"\\ \t]*" $str]} {
return $str
}
if {![string match "*\['\"\\]*" $str]} {
return "\"$str\""
}
if {![string match "*'*" $str]} {
return "'$str'"
}
return "\"[string map {\" \\\" \\ \\\\} $str]\""
}
Note that the first case does not cover strings with newlines in them,
though, and the second does not help with dollar signs. And I have no
clue what the last return does. Presumably maps " to \" and \ to \\
inside of double quotes.
b) splitting EDITOR/VISUAL at spaces and using exec. Nobody else
appears to do this, so may neither should be.
It appears that the C code already has quote.c, so it is probably more
or less doable.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Alexandre Julliard @ 2007-08-01 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vvebz3wh3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Alexandre Julliard <julliard@winehq.org> writes:
>
>> .... For
>> instance in vc-git.el the workfile-unchanged-p function currently has
>> to rehash the file every time to see if it really changed, because we
>> can't afford to refresh the whole project at that point.
>
> Maybe I am missing something. Why can't you "afford to"?
>
> "update-index --refresh" looks at only the files whose cached
> stat information does indicate there might be chanegs. It does
> not rehash already up-to-date ones.
No, but it goes through the tree and stats every single file. On a
large project that can be slow, especially if you don't have enough
RAM to keep it all in cache, so it's not something we can do while the
user is interacting with a file.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox