* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Junio C Hamano @ 2007-11-11 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711112227420.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Maybe call_editor() instead of edit_buffer()? Since we technically read
> the file specified by "path" into the buffer "buffer", after having called
> the editor.
Calling $EDITOR to edit the buffer is an implementation detail
of letting the user edit the buffer. I think the function name
should express what it does more than how it does it.
My suggested name does not convey the "letting the user" part,
though.
^ permalink raw reply
* [PATCH] Fix rev-list when showing objects involving submodules
From: Johannes Schindelin @ 2007-11-11 23:35 UTC (permalink / raw)
To: git, gitster
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees. This is not so. Since we do
not traverse into submodules (yet), the gitlinks should be ignored.
Noticed by Ilari on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
revision.c | 2 +-
t/t6008-rev-list-submodule.sh | 42 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletions(-)
create mode 100755 t/t6008-rev-list-submodule.sh
diff --git a/revision.c b/revision.c
index 931f978..81b5a93 100644
--- a/revision.c
+++ b/revision.c
@@ -69,7 +69,7 @@ void mark_tree_uninteresting(struct tree *tree)
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
mark_tree_uninteresting(lookup_tree(entry.sha1));
- else
+ else if (!S_ISGITLINK(entry.mode))
mark_blob_uninteresting(lookup_blob(entry.sha1));
}
diff --git a/t/t6008-rev-list-submodule.sh b/t/t6008-rev-list-submodule.sh
new file mode 100755
index 0000000..88e96fb
--- /dev/null
+++ b/t/t6008-rev-list-submodule.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git rev-list involving submodules that this repo has'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ : > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo 1 > file &&
+ test_tick &&
+ git commit -m second file &&
+ echo 2 > file &&
+ test_tick &&
+ git commit -m third file &&
+
+ rm .git/index &&
+
+ : > super-file &&
+ git add super-file &&
+ git submodule add . sub &&
+ git symbolic-ref HEAD refs/heads/super &&
+ test_tick &&
+ git commit -m super-initial &&
+ echo 1 > super-file &&
+ test_tick &&
+ git commit -m super-first super-file &&
+ echo 2 > super-file &&
+ test_tick &&
+ git commit -m super-second super-file
+'
+
+test_expect_success "Ilari's test" '
+ git rev-list --objects super master ^super^
+'
+
+test_done
--
1.5.3.5.1695.g146d07
^ permalink raw reply related
* Re: Deprecate git-fetch-pack?
From: Theodore Tso @ 2007-11-11 23:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711112247350.4362@racer.site>
On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:
> I beg to differ. The biggest problem with a new user seeing all those
> completions is that this user is scared.
Well, if we introduce the new user only to "git subcomand", and the
documentation is relatively gentle, I would suspect would solve most
of the problem. Note BTW, that if your thesis is true, "git help -a"
(which is recommended in the last line of output by "git help") should
cause the typical new user to faint dead away. :-)
Some other areas that would be worth fixing, in terms of user usability.
1) The references to the tutorial, everyday git, etc., don't actually
have working references in the git man page. (i.e., what you see when
you run the command "man git"). It would be nice if that were fixed.
2) The command which are displayed by "git help" should use some
serious rethinking. Ideally, it would be nice if the output fit in a
single 24-line terminal window. Some candidates for removal:
a) prune: "git prune" definitely doesn't deserve to be on the
front and center as displayed by "git help". Maybe replace it
with "gc", but now that we have gc.auto, I'm not sure it's
worth it at all.
b) revert: Is that really that common of a command?
c) show-branch: The output is terrifying without explanation
There are other commands I'm not so sure about, but it is worth
flagging them. One way that might be helpful is to group the commands
into subcommands, much like gdb does, so you could do something like
"git help other-repos" (where all commands that involve interacting
with other repositories are summarized), and so on.
> But yes, I was only proposing to deprecate all usage of git-<bla> in the
> documentation.
I agree that de-emphasizing git-<blah> isn't a bad thing. But I think
we need to look at the big picture here, since "git help" is often one
of the first things a new user might try (and obviously very few git
developers look at it, or "prune" probably would have been removed
from git help a long time ago :-), and the last thing that git help
suggests (and so therefore it will very visible to the newbie user),
is "git help -a" --- and that displays every single git command under
creation, porcelain or plumbing, in one gigantic sorted list.
Oops, so much for first impressions. :-)
- Ted
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Jakub Narebski @ 2007-11-12 0:16 UTC (permalink / raw)
To: git
In-Reply-To: <20071111235819.GB7392@thunk.org>
Theodore Tso wrote:
> 2) The command which are displayed by "git help" should use some
> serious rethinking. Ideally, it would be nice if the output fit in a
> single 24-line terminal window. Some candidates for removal:
>
> a) prune: "git prune" definitely doesn't deserve to be on the
> front and center as displayed by "git help". Maybe replace it
> with "gc", but now that we have gc.auto, I'm not sure it's
> worth it at all.
I would replace it by "git gc" (you have to run 'git gc --prune' by hand
on quiescent repository), or remove it altogether.
> b) revert: Is that really that common of a command?
It is useful command, perhaps short description should be improved.
BTW. if we have cherry-pick, then we should have revert.
> c) show-branch: The output is terrifying without explanation
I agree. I would replace it by gitk, or gui (git-gui / "git gui").
> There are other commands I'm not so sure about, but it is worth
> flagging them. One way that might be helpful is to group the commands
> into subcommands, much like gdb does, so you could do something like
> "git help other-repos" (where all commands that involve interacting
> with other repositories are summarized), and so on.
I think that "git-rm" could be removed, because "rm <file>; git commit ..."
works just fine.
See also discussion about results of Git User's Survey 2007, somewhere
around
http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62205
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-12 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vy7d8xlej.fsf_-_@gitster.siamese.dyndns.org>
... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.
---
Documentation/core-tutorial.txt | 5 -----
Documentation/git-get-tar-commit-id.txt | 4 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
Maybe also fixing these references would be in order.
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index ebd2492..401d1de 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1090,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
-+
-There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
-programs, which are 'commit walkers'; they outlived their
-usefulness when git Native and SSH transports were introduced,
-and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
index 9b5f86f..ef1b19c 100644
--- a/Documentation/git-get-tar-commit-id.txt
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
-git-tar-tree. It reads only the first 1024 bytes of input, thus its
+gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of <tarfile> very much.
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
-using git-tar-tree or if the first parameter of git-tar-tree had been
+using git-archive or if the first parameter of git-tar-tree had been
a tree ID instead of a commit ID or tag.
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-12 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071112002410.GA21970@diku.dk>
Subject: [PATCH] Documentation: Fix references to deprecated commands
... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/core-tutorial.txt | 5 -----
Documentation/git-get-tar-commit-id.txt | 4 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
Now with SOB and ...
Jonas Fonseca <fonseca@diku.dk> wrote Mon, Nov 12, 2007:
> diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> index 9b5f86f..ef1b19c 100644
> --- a/Documentation/git-get-tar-commit-id.txt
> +++ b/Documentation/git-get-tar-commit-id.txt
> @@ -14,12 +14,12 @@ SYNOPSIS
> return code of 1. This can happen if <tarfile> had not been created
> -using git-tar-tree or if the first parameter of git-tar-tree had been
> +using git-archive or if the first parameter of git-tar-tree had been
> a tree ID instead of a commit ID or tag.
... s//g
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index ebd2492..401d1de 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1090,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
-+
-There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
-programs, which are 'commit walkers'; they outlived their
-usefulness when git Native and SSH transports were introduced,
-and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
index 9b5f86f..ef1b19c 100644
--- a/Documentation/git-get-tar-commit-id.txt
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
-git-tar-tree. It reads only the first 1024 bytes of input, thus its
+gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of <tarfile> very much.
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
-using git-tar-tree or if the first parameter of git-tar-tree had been
+using git-archive or if the <treeish> parameter of git-archive had been
a tree ID instead of a commit ID or tag.
--
Jonas Fonseca
^ permalink raw reply related
* Is it possible for git to remember the options preference for "git log"?
From: eric miao @ 2007-11-12 0:33 UTC (permalink / raw)
To: git
All,
Most of the time I'm using git-log for inspecting a brief history
and insert/remove/modify commits between, which I have to
type "git log --abbrev-commit --pretty=oneline" every time. Is
it possible for git to remember this command line options
preference?
And no, I don't really want to use shell's alias or something
else, I was just used to type "git xxx" :-)
--
Cheers
- eric
^ permalink raw reply
* [PATCH] replace reference to git-rm with git-reset in git-commit doc
From: Jing Xue @ 2007-11-12 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <20071111140518.GA3847@efreet.light.src>
On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:
>
> The message in git-commit suggesting to use 'git rm --cached' to unstage is
> just plain wrong. It really should mention 'git reset'.
Hopefully this makes it clearer. I have also updated the faq in wiki to
clarify.
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-add.txt | 1 +
Documentation/git-commit.txt | 12 ++++++------
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -224,6 +224,7 @@ See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
+gitlink:git-reset[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..7c63dd8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,12 +154,12 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1]. Removal
-of a file is staged with gitlink:git-rm[1]. After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far. This is the most basic form of the
-command. An example:
+called the "index" with gitlink:git-add[1]. File changes
+previously staged can be removed with `git-reset
+HEAD -- <file>`. After building the state to be committed
+incrementally with these commands, `git commit` (without any
+pathname parameter) is used to record what has been staged so
+far. This is the most basic form of the command. An example:
------------
$ edit hello.c
^ permalink raw reply related
* stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
From: Adam J. Richter @ 2007-11-12 0:39 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Hi Catalin,
I want to report two problems, at least one of which may be
due to some other environmental change such as a git upgrade.
The first bug is less perhaps serious, and perhaps not new,
but it's easier to describe this one first.
I have a small stack of patches in stgit for a source tree.
One of these patches modified a yacc grammer "parser.y", which, in
turn, causes the yacc files y.tab.{c,h} to be rebuilt. y.tab.{c,h}
are included in the source tree for build environments that lack yacc.
Sometimes my attempts to check out a new source tree and rebuild would
result in y.tab.{c,h} not being built, probably due to 1 second
timestamp granularity somewhere (the ext3 file system, make, git,
stgit, whatever), probably not stgit's fault.
So, did repeated "stg pop" commands to get to the point where
the change to parser.y is applied, did an "stg new", deleted
y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh". So far, so
good. Then I tried to do an "stg push" to re-integrate the next
patch, and I got a complaint from stgit about some git object not
existing. This patch did not touch y.tab.{c,h} or any files touched
by any of the other patches I had pushed on. I don't know stgit well
enough to recover from the situation gracefully, so I just wiped the
stgit tree and tried to apply the patches again, which brings me to
bug #2.
I made a new stgit tree of the program (bash), pulling from a
local git tree, and attempted to apply the first patch, with usuaul
"stg new...make changes...stg refresh". Then stg refresh informed
printed this message ("invalid_multibyte_sequence" is the name of the
new patch):
Checking for changes in the working directory ... done
Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)
"stg diff" still shows the changes as if I had not done an
"stg refresh". Obviously, stg commits have worked for me in the past.
I suspect that a recent upgrade of git or other system software
triggered the break.
I'll try to pass along what I find if I start debugging this
problem, but I probably won't be able to get into that immediately, so
I am just passing this data along for now in the hopes that it may be
helpful for someone else.
Adam
^ permalink raw reply
* Re: Is it possible for git to remember the options preference for "git log"?
From: Jakub Narebski @ 2007-11-12 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
eric miao wrote:
> Most of the time I'm using git-log for inspecting a brief history
> and insert/remove/modify commits between, which I have to
> type "git log --abbrev-commit --pretty=oneline" every time. Is
> it possible for git to remember this command line options
> preference?
>
> And no, I don't really want to use shell's alias or something
> else, I was just used to type "git xxx" :-)
You can always use (global) _git_ alias ;-p
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH,RFC 2/2] Remove hint to use "git help -a"
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
The newbie user will run away screaming when they see all possible
commands. The expert user will already know about the -a option from
reading the git man page.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
help.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..f539b80 100644
--- a/help.c
+++ b/help.c
@@ -162,7 +162,6 @@ static void list_common_cmds_help(void)
mput_char(' ', longest - strlen(common_cmds[i].name));
puts(common_cmds[i].help);
}
- puts("(use 'git help -a' to get a list of all installed git commands)");
}
static void show_man_page(const char *git_cmd)
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <20071111235819.GB7392@thunk.org>
Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
"git help" is less intimidating.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
generate-cmdlist.sh | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 17df47b..1ba27ec 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -11,12 +11,9 @@ static struct cmdname_help common_cmds[] = {"
sort <<\EOF |
add
-apply
-archive
bisect
branch
checkout
-cherry-pick
clone
commit
diff
@@ -26,15 +23,12 @@ init
log
merge
mv
-prune
pull
push
rebase
reset
-revert
rm
show
-show-branch
status
tag
EOF
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* Re: Is it possible for git to remember the options preference for "git log"?
From: Daniel Barkalow @ 2007-11-12 1:02 UTC (permalink / raw)
To: eric miao; +Cc: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
On Mon, 12 Nov 2007, eric miao wrote:
> All,
>
> Most of the time I'm using git-log for inspecting a brief history
> and insert/remove/modify commits between, which I have to
> type "git log --abbrev-commit --pretty=oneline" every time. Is
> it possible for git to remember this command line options
> preference?
>
> And no, I don't really want to use shell's alias or something
> else, I was just used to type "git xxx" :-)
Git has a built-in alias mechanism, which is probably what you want. If
you put in your config file:
[alias]
xxx = log --abbrev-commit --pretty=online
then you can type "git xxx" and it'll do what you want. Changing the
default behavior of the basic commands is looked down on because there are
scripts that use them to get their input, and those scripts have
particular formats they expect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Ask Bjørn Hansen @ 2007-11-12 1:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Theodore Tso, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711112247350.4362@racer.site>
On Nov 11, 2007, at 2:50 PM, Johannes Schindelin wrote:
> I beg to differ. The biggest problem with a new user seeing all those
> completions is that this user is scared.
How about moving the plumbing commands to libexec/ or some such? (Or
libexec/git/ - then you can put it back in your PATH if you really
want easy access to run them directly).
Maybe I'm being pedantic, but it's not about "scaring the user" --
it's simply that the "visible commands" is part of the UI and having
it unnecessarily complex (many more commands than the user needs to
learn) makes it much harder to get started using git. It's a very
practical thing.
I strongly second Theodore's suggestions for cleaning up some of the
help texts, too.
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-12 1:48 UTC (permalink / raw)
To: gitster; +Cc: git, johannes.schindelin, Shawn Bohrer
This replaces git-clean.sh with builtin-clean.c, and moves
git-clean.sh to the examples.
This also introduces a change in behavior when removing directories
explicitly specified as a path. For example currently:
1. When dir has only untracked files, these two behave differently:
$ git clean -n dir
$ git clean -n dir/
the former says "Would not remove dir/", while the latter would say
"Would remove dir/untracked" for all paths under it, but not the
directory itself.
With -d, the former would stop refusing, however since the user
explicitly asked to remove the directory the -d is no longer required.
2. When there are more parameters:
$ git clean -n dir foo
$ git clean -n dir/ foo
both cases refuse to remove dir/ unless -d is specified. Once again
since both cases requested to remove dir the -d is no longer required.
Thanks to Johannes Schindelin for the conversion to using the
parse-options API.
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
On Wed, Nov 07, 2007 at 11:37:50PM -0600, Shawn Bohrer wrote:
> On Wed, Nov 07, 2007 at 12:42:16PM -0800, Junio C Hamano wrote:
> >
> > Having said that, I do not particularly agree with the way the
> > new implementation resolves the existing inconsistencies.
> >
> > Wouldn't it be better to remove "dir" when the user explicitly
> > told you to clean "dir", with or without the trailing slash?
> > That's what the user asked you to do, isn't it?
>
> Yes I suppose I agree. Of course I need to spend some more time staring
> at the code to figure out how to do so. Perhaps I can figure out what
> is causing the original inconsistency in git-ls-files while I'm at it.
OK, I failed to fix the inconsistency between a single and multiple
paths so I'm not sure if this patch is much better. The problem appears
to be that when dir.show_others_directories is set directories that only
contain untracked files are not recursed, which is fine with a single
path because you can adjust the path, base and baselen to
read_directory(). With multiple paths you need to find a common prefix
to all of the paths before calling read_directory() which causes the
inconsistency.
If anyone as a suggestion on how to fix this I'm all for it, but even
with the inconsistency we are no worse than we were with git-clean.sh
Makefile | 3 +-
builtin-clean.c | 154 +++++++++++++++++++++++++
builtin.h | 1 +
git-clean.sh => contrib/examples/git-clean.sh | 0
git.c | 1 +
5 files changed, 158 insertions(+), 1 deletions(-)
create mode 100644 builtin-clean.c
rename git-clean.sh => contrib/examples/git-clean.sh (100%)
diff --git a/Makefile b/Makefile
index a2fcdb8..ef7420d 100644
--- a/Makefile
+++ b/Makefile
@@ -213,7 +213,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
- git-clean.sh git-clone.sh git-commit.sh \
+ git-clone.sh git-commit.sh \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh \
@@ -329,6 +329,7 @@ BUILTIN_OBJS = \
builtin-check-attr.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
+ builtin-clean.o \
builtin-commit-tree.o \
builtin-count-objects.o \
builtin-describe.o \
diff --git a/builtin-clean.c b/builtin-clean.c
new file mode 100644
index 0000000..55658e7
--- /dev/null
+++ b/builtin-clean.c
@@ -0,0 +1,154 @@
+/*
+ * "git clean" builtin command
+ *
+ * Copyright (C) 2007 Shawn Bohrer
+ *
+ * Based on git-clean.sh by Pavel Roskin
+ */
+
+#include "builtin.h"
+#include "cache.h"
+#include "dir.h"
+#include "parse-options.h"
+
+static int force;
+
+static const char *const builtin_clean_usage[] = {
+ "git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...",
+ NULL
+};
+
+static int git_clean_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "clean.requireforce"))
+ force = !git_config_bool(var, value);
+ return 0;
+}
+
+int cmd_clean(int argc, const char **argv, const char *prefix)
+{
+ int j;
+ int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int ignored_only = 0, baselen = 0;
+ struct strbuf directory;
+ struct dir_struct dir;
+ const char *path, *base;
+ static const char **pathspec;
+ struct option options[] = {
+ OPT__QUIET(&quiet),
+ OPT__DRY_RUN(&show_only),
+ OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('d', NULL, &remove_directories,
+ "remove whole directories"),
+ OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
+ OPT_BOOLEAN('X', NULL, &ignored_only,
+ "remove only ignored files"),
+ OPT_END()
+ };
+
+ git_config(git_clean_config);
+ argc = parse_options(argc, argv, options, builtin_clean_usage, 0);
+
+ memset(&dir, 0, sizeof(dir));
+ if (ignored_only) {
+ dir.show_ignored =1;
+ dir.exclude_per_dir = ".gitignore";
+ }
+
+ if (ignored && ignored_only)
+ die("-x and -X cannot be used together");
+
+ if (!show_only && !force)
+ die("clean.requireForce set and -n or -f not given; refusing to clean");
+
+ dir.show_other_directories = 1;
+
+ if (!ignored) {
+ dir.exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), F_OK)) {
+ char *exclude_path = git_path("info/exclude");
+ add_excludes_from_file(&dir, exclude_path);
+ }
+ }
+
+ pathspec = get_pathspec(prefix, argv);
+ read_cache();
+
+ /*
+ * Calculate common prefix for the pathspec, and
+ * use that to optimize the directory walk
+ */
+ baselen = common_prefix(pathspec);
+ path = ".";
+ base = "";
+ if (baselen)
+ path = base = xmemdupz(*pathspec, baselen);
+ read_directory(&dir, path, base, baselen, pathspec);
+ strbuf_init(&directory, 0);
+
+ for (j = 0; j < dir.nr; ++j) {
+ struct dir_entry *ent = dir.entries[j];
+ int len, pos, specs;
+ struct cache_entry *ce;
+ struct stat st;
+ char *seen;
+
+ /*
+ * Remove the '/' at the end that directory
+ * walking adds for directory entries.
+ */
+ len = ent->len;
+ if (len && ent->name[len-1] == '/')
+ len--;
+ pos = cache_name_pos(ent->name, len);
+ if (0 <= pos)
+ continue; /* exact match */
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == len &&
+ !memcmp(ce->name, ent->name, len))
+ continue; /* Yup, this one exists unmerged */
+ }
+
+ if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
+ int matched_path = 0;
+ strbuf_addstr(&directory, ent->name);
+ if (pathspec) {
+ for (specs =0; pathspec[specs]; ++specs)
+ /* nothing */;
+ seen = xcalloc(specs, 1);
+ /* Check if directory was explictly passed as
+ * pathspec. If so we want to remove it */
+ if (match_pathspec(pathspec, ent->name, ent->len,
+ baselen, seen))
+ matched_path = 1;
+ free(seen);
+ }
+ if (show_only && (remove_directories || matched_path)) {
+ printf("Would remove %s\n", directory.buf);
+ } else if (quiet && (remove_directories || matched_path)) {
+ remove_dir_recursively(&directory, 0);
+ } else if (remove_directories || matched_path) {
+ printf("Removing %s\n", directory.buf);
+ remove_dir_recursively(&directory, 0);
+ } else if (show_only) {
+ printf("Would not remove %s\n", directory.buf);
+ } else {
+ printf("Not removing %s\n", directory.buf);
+ }
+ strbuf_reset(&directory);
+ } else {
+ if (show_only) {
+ printf("Would remove %s\n", ent->name);
+ continue;
+ } else if (!quiet) {
+ printf("Removing %s\n", ent->name);
+ }
+ unlink(ent->name);
+ }
+ }
+
+ strbuf_release(&directory);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 525107f..5476a92 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,6 +24,7 @@ extern int cmd_check_attr(int argc, const char **argv, const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char *prefix);
extern int cmd_cherry(int argc, const char **argv, const char *prefix);
extern int cmd_cherry_pick(int argc, const char **argv, const char *prefix);
+extern int cmd_clean(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);
extern int cmd_count_objects(int argc, const char **argv, const char *prefix);
extern int cmd_describe(int argc, const char **argv, const char *prefix);
diff --git a/git-clean.sh b/contrib/examples/git-clean.sh
similarity index 100%
rename from git-clean.sh
rename to contrib/examples/git-clean.sh
diff --git a/git.c b/git.c
index 204a6f7..3fa8e4d 100644
--- a/git.c
+++ b/git.c
@@ -293,6 +293,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
{ "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "clean", cmd_clean, RUN_SETUP | NEED_WORK_TREE },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "config", cmd_config },
{ "count-objects", cmd_count_objects, RUN_SETUP },
--
1.5.3.GIT
^ permalink raw reply related
* Re: Is it possible for git to remember the options preference for "git log"?
From: eric miao @ 2007-11-12 2:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111954520.29952@iabervon.org>
On Nov 12, 2007 9:02 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> On Mon, 12 Nov 2007, eric miao wrote:
>
> > All,
> >
> > Most of the time I'm using git-log for inspecting a brief history
> > and insert/remove/modify commits between, which I have to
> > type "git log --abbrev-commit --pretty=oneline" every time. Is
> > it possible for git to remember this command line options
> > preference?
> >
> > And no, I don't really want to use shell's alias or something
> > else, I was just used to type "git xxx" :-)
>
> Git has a built-in alias mechanism, which is probably what you want. If
> you put in your config file:
>
> [alias]
> xxx = log --abbrev-commit --pretty=online
>
Thanks, this is exactly what I want.
> then you can type "git xxx" and it'll do what you want. Changing the
> default behavior of the basic commands is looked down on because there are
> scripts that use them to get their input, and those scripts have
> particular formats they expect.
>
Ye, agree, I don't think that's a good idea either.
> -Daniel
> *This .sig left intentionally blank*
>
--
Cheers
- eric
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Junio C Hamano @ 2007-11-12 2:21 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Git Mailing List
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
Theodore Ts'o <tytso@mit.edu> writes:
> Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
> "git help" is less intimidating.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> -apply
> -archive
> -prune
> -revert
> -show-branch
I am fine with this list, perhaps except apply.
On the other hand, if you are shooting *really* for the absolute
minimum set for the beginners, I would kill rm and possibly mv)
in addition to your list:
- git-rm is always easier to do with "rm -fr file-or-dir",
followed by "git commit -a". Of course "git rm --cached" and
partial commits that contain removal cannot be emulated
easily this way, but this is an alternative suggestion to aim
for *real* beginners who do not use the index.
- git-mv is on my list for the same reason as "rm", but it is a
bit more cumbersome if you want to move a directory, because
"mv old new && git add new" would not work for people without
a correctly set-up .gitignore (and if we are talking about
beginners, we should expect user's .gitignore is borked).
I have a bit of reservation about revert, but I'd imagine we
could kill it, and also fetch, pull and push, if you are
shooting for *real* beginners who work alone. I think the only
valid justification to drop "revert" from the list is to assume
that the audience do not interact with the outside world, and
dropping fetch/pull/push from the list is in line with that.
^ permalink raw reply
* Re: [PATCH] replace reference to git-rm with git-reset in git-commit doc
From: Junio C Hamano @ 2007-11-12 2:27 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20071112003845.GA7595@fawkes>
Jing Xue <jingxue@digizenstudio.com> writes:
> On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:
>>
>> The message in git-commit suggesting to use 'git rm --cached' to unstage is
>> just plain wrong. It really should mention 'git reset'.
>
> Hopefully this makes it clearer. I have also updated the faq in wiki to
> clarify.
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index e54fb12..7c63dd8 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -154,12 +154,12 @@ EXAMPLES
> --------
> When recording your own work, the contents of modified files in
> your working tree are temporarily stored to a staging area
> +called the "index" with gitlink:git-add[1]. File changes
> +previously staged can be removed with `git-reset
> +HEAD -- <file>`.
I think "changes ... can be removed" risks to give a confused
mental model that somehow git tracks changes. "A file can be
reverted back to that of the last commit with ..." would be
less risky.
^ permalink raw reply
* Re: [PATCH] git-svn: prevent dcommitting if the index is dirty.
From: Eric Wong @ 2007-11-12 2:28 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <1194806501-4796-1-git-send-email-tsuna@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> dcommit uses rebase `sync' the history with what has just been pushed to
> SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now
> the user will get an error message if he attempts to dcommit with a dirty
> index.
>
> Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Thanks,
Minor nit below about indentation (which Junio can fix when applying),
but nevertheless:
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 3 +++
> t/t9106-git-svn-dcommit-clobber-series.sh | 6 ++++++
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index dd93e32..a15df4f 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -390,6 +390,9 @@ sub cmd_set_tree {
>
> sub cmd_dcommit {
> my $head = shift;
> + git_cmd_try { command_oneline(qw/diff-index --quiet HEAD/) }
> + 'Cannot dcommit with a dirty index. Commit your changes first'
> + . "or stash them with `git stash'.\n";
We use tabs for indentation, and spaces for alignment.
> $head ||= 'HEAD';
> my @refs;
> my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 3/3] git-svn log: handle unreachable revisions like "svn log"
From: Eric Wong @ 2007-11-12 2:50 UTC (permalink / raw)
To: David D. Kilzer; +Cc: Benoit Sigoure, git, gitster
In-Reply-To: <189577.85054.qm@web52407.mail.re2.yahoo.com>
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
Hi Dave, thanks for the patches, and thanks to Benoit for the review.
> Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
>
> > thanks for the patches, the series looks good to me, I added some
> > comments below, for this patch.
>
> Thanks for the review, Benoit! Comments below.
>
> > On Nov 11, 2007, at 7:10 AM, David D Kilzer wrote:
> >
> > > sub find_rev_before {
> > > - my ($self, $rev, $eq_ok) = @_;
> > > + my ($self, $rev, $eq_ok, $min_rev) = @_;
> >
> > Could you please document this function? I guess that you had to
> > figure out what each argument was for, so please save the time of the
> > contributors that will read this code after you :)
>
> What is the format for documenting functions in git Perl scripts? I
> haven't see any "perlpod" use anywhere. Do you just want comments
> before the function?
Just a regular comment is enough, perlpod uses too much space.
> This method returns the git commit hash and svn revision of the first svn
> revision that exists on the current branch that is less than $rev (or
> less-than-or-equal-to $rev if $eq_ok is true).
>
> Please note that I don't have a full understanding of how find_rev_before()
> works (other than it's computing an offset into a sparse? data file based on
> the revision number) since I'm still new to git.
Pretty much. The .rev_db format is documented above the _rev_db_set
sub. I'm considering replacing the current rev_db format with something
more compact for larger repos, though.
> > > +sub find_rev_after {
> > > + my ($self, $rev, $eq_ok, $max_rev) = @_;
> > > + ++$rev unless $eq_ok;
> > > + $max_rev ||= $self->rev_db_max();
> > > + while ($rev <= $max_rev) {
> > > + if (my $c = $self->rev_db_get($rev)) {
> > > + return ($rev, $c);
> > > + }
> > > + ++$rev;
> > > + }
> > > + return (undef, undef);
> > > +}
> >
> > Too much code duplication. It should be possible to write a sub
> > find_rev_ (or _find_rev, don't know what's the naming convention for
> > internal details) that takes a 5th argument, an anonymous sub that
> > does the comparison. So that basically, find_rev_before will be
> > something along these (untested) lines:
> >
> > sub find_rev_before {
> > my ($self, $rev, $eq_ok, $min_rev) = @_;
> > return find_rev_($self, $rev, $eq_ok, $min_rev, sub { my ($a, $b) =
> > @_; return $a >= $b; });
> > }
>
> I think that combining find_rev_before() and find_rev_after() would greatly
> sacrifice readability of the code in exchange for removing ~10 lines of code.
> Also, you must do more than just replace the comparison in the while() loop:
>
> - before() decrements $rev while after() increments it
> - stop limits are different ($max_rev versus $min_rev)
>
> This is what such a method might look like (untested). Since you already
> requested find_rev_before() be documented, is this really going to help?
>
> sub find_rev_ {
> my ($self, $rev, $eq_ok, $is_before, $limit_rev) = @_;
> ($is_before ? --$rev : ++$rev) unless $eq_ok;
> $limit_rev ||= ($is_before ? 1 : $self->rev_db_max());
> while ($is_before ? $rev >= $limit_rev : $rev <= $limit_rev) {
> if (my $c = $self->rev_db_get($rev)) {
> return ($rev, $c);
> }
> $is_before ? --$rev : ++$rev;
> }
> return (undef, undef);
> }
find_rev_ is too complicated, please keep them as separate functions.
> Defining wrapper functions would help, but I still think it's just as clear to
> keep the two methods separate.
>
> sub find_rev_before() {
> my ($self, $rev, $eq_ok, $min_rev) = @_;
> return $self->find_rev_($rev, $eq_ok, 1, $min_rev);
> }
>
> sub find_rev_after() {
> my ($self, $rev, $eq_ok, $max_rev) = @_;
> return $self->find_rev_($rev, $eq_ok, 0, $max_rev);
> }
>
> Do you agree, or do you think the methods should still be combined?
>
> > > + if ($r_max < $r_min) {
> > > + ($r_min, $r_max) = ($r_max, $r_min);
> > > + }
> > > + my (undef, $c_max) = $gs->find_rev_before($r_max, 1, $r_min);
> > > + my (undef, $c_min) = $gs->find_rev_after($r_min, 1, $r_max);
> > > + # If there are no commits in the range, both $c_max and $c_min
> > > + # will be undefined. If there is at least 1 commit in the
> > > + # range, both will be defined.
> > > + return () if !defined $c_min;
> >
> > Fair enough but I'd strengthen the test by writing something like:
> > return () if not defined $c_min || not defined $c_max;
> > unless you can prove that `rev_db_get' can never return `undef' or
> > something like that.
I prefer '!' instead of 'not' unless operator precedence matters.
> Will make this change.
>
> > > +sub commit_log_separator {
> > > + return ('-' x 72) . "\n";
> > > +}
> > > +
> >
> > This is basically a constant, I think that declaring it with a
> > prototype helps Perl to optimize it:
> > sub commit_log_separator() {
use constant commit_log_separator => ('-' x 72) . "\n";
is probably most readable...
--
Eric Wong
^ permalink raw reply
* Re: git packs
From: bob @ 2007-11-12 2:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711102331270.21255@xanadu.home>
I applied the patch and these commands:
cd rmwHtmlOld
rm -fr .git
git init
git config core.compression 0
git add .
I then got the same error as before, "Bus error". Rats!
Then I modified your script since I do not have seq or
your test-genrandom. I substituted:
dd count=XX if=/dev/random of=file_$i
where XX is adjusted to meet dd's requirements. Also,
I found after searching for a while, that the following
works just like your seq command:
xyzzy="1 2 3 4"
for i in $xyzzy
do
...
done
Your script then ran flawlessly.
I looked through index-pack.c some more, but it is
very hard to figure it out without doing a lot of research
since there doesn't seem to be anything that describes
the layout of a pack. The link towards the end of the user's
manual doesn't work for me.
The difference between your test and my data is that
instead of having a few large files, I have 11,500 files
of varying sizes. On average though, the file size is
about 370k.
HTH
On Nov 10, 2007, at 11:35 PM, Nicolas Pitre wrote:
> On Sat, 10 Nov 2007, bob wrote:
>
>> I will try a few things and see if I can get a script put together
>> that generates the inflate problem. The data that I am
>> using is a backup of my original repository. So, I can
>> play all that I want. But it would be a lot easier if I
>> could just generate some files using dd or something.
>
> Please see the patch I just posted to the list. That should fix your
> problem. I even included a small script to create a repository
> confirming the problem and allowing to test the fix.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] git-branch: remove mention of non-existent '-b' option
From: Jeff King @ 2007-11-12 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This looks like a cut and paste error from the git-checkout
explanation of --no-track.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5e81aa4..5ce905d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -105,7 +105,7 @@ OPTIONS
'--track' were given.
--no-track::
- When -b is given and a branch is created off a remote branch,
+ When a branch is created off a remote branch,
set up configuration so that git-pull will not retrieve data
from the remote branch, ignoring the branch.autosetupmerge
configuration variable.
--
1.5.3.5.1664.gcd60
^ permalink raw reply related
* Re: git packs
From: Nicolas Pitre @ 2007-11-12 4:21 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <B298202C-3D54-498D-A348-0338914FBA46@mac.com>
On Sun, 11 Nov 2007, bob wrote:
> I applied the patch and these commands:
>
> cd rmwHtmlOld
> rm -fr .git
> git init
> git config core.compression 0
> git add .
Note that I did "git config core.compression 0" simply to disable
zlib compression altogether when creating the test repo just so it gets
created faster. even then, auto-generating and cloning a 8GB test
repository isn't particularly quick.
> I then got the same error as before, "Bus error". Rats!
Do you get that with a 32-bit or 64-bit build of Git?
> Then I modified your script since I do not have seq or
> your test-genrandom.
test-genrandom is built with Git. It is just not installed anywhere.
> I substituted:
>
> dd count=XX if=/dev/random of=file_$i
>
> where XX is adjusted to meet dd's requirements. Also,
Again I used test-genrandom instead of /dev/random or /dev/urandom
simply because the former is much faster.
> I found after searching for a while, that the following
> works just like your seq command:
>
> xyzzy="1 2 3 4"
> for i in $xyzzy
> do
> ...
> done
>
> Your script then ran flawlessly.
However 'seq -w 1 2 63' should be replaced with "01 03 05 07 09 11 13
15" and so on up to 63, and 'seq -w 2 2 64' is "02 04 06 08 10 12 16"
and so on.
> I looked through index-pack.c some more, but it is
> very hard to figure it out without doing a lot of research
> since there doesn't seem to be anything that describes
> the layout of a pack. The link towards the end of the user's
> manual doesn't work for me.
Look at Documentation/technical/pack-format.txt in the Git source tree.
> The difference between your test and my data is that
> instead of having a few large files, I have 11,500 files
> of varying sizes. On average though, the file size is
> about 370k.
Are you saying that the test repo with big files works for you but not
your own data set?
Would you please recap what your problem is?
With my one line patch you should not get the "serious inflate
inconsistency" error anymore. The bus error must be another issue.
Nicolas
^ permalink raw reply
* [PATCH] for-each-ref: fix off by one read.
From: Christian Couder @ 2007-11-12 4:37 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-for-each-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 598d4e1..89ea37c 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -306,7 +306,7 @@ static const char *find_wholine(const char *who, int wholen, const char *buf, un
if (!eol)
return "";
eol++;
- if (eol[1] == '\n')
+ if (*eol == '\n')
return ""; /* end of header */
buf = eol;
}
--
1.5.3.5.577.g4d1b9-dirty
^ permalink raw reply related
* [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc
From: Jing Xue @ 2007-11-12 4:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vsl3c8afm.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 06:27:57PM -0800, Junio C Hamano wrote:
>
> I think "changes ... can be removed" risks to give a confused
> mental model that somehow git tracks changes.
I see what you mean. "Changes" shouldn't be the subject here.
> "A file can be
> reverted back to that of the last commit with ..." would be
> less risky.
On top of that, I somehow still want to make it relevant to that
git-reset instead of git-rm should be used to revert git-add. So how
about this?
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-add.txt | 1 +
Documentation/git-commit.txt | 13 ++++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -224,6 +224,7 @@ See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
+gitlink:git-reset[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..4b26cae 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,11 +154,14 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1]. Removal
-of a file is staged with gitlink:git-rm[1]. After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far. This is the most basic form of the
+called the "index" with gitlink:git-add[1]. A file can be
+reverted back, only in the index but not in the working tree,
+to that of the last commit with `git-reset HEAD -- <file>`,
+which effectively reverts `git-add` and prevents this file from
+participating in the next commit. After building the state to
+be committed incrementally with these commands, `git commit`
+(without any pathname parameter) is used to record what has
+been staged so far. This is the most basic form of the
command. An example:
------------
^ permalink raw reply related
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