* help: bisect single file from repos
From: walter harms @ 2009-12-07 12:59 UTC (permalink / raw)
To: git
Hi list,
i am new to git (using: git version 1.6.0.2).
I would like to bisect a single file but i have only commit id, no tags.
Background:
I have a copy of the busybox git repos, and i know there is (perhaps) a bug
in ash.c.
how can i do that ?
re,
wh
^ permalink raw reply
* Re: [RFC/PATCH] Detailed diagnostic when parsing an object name fails.
From: Matthieu Moy @ 2009-12-07 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <vpqiqcrd93l.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> Perhaps the second step would be to teach the machinery to understand a
>> syntax like "<tree-ish>:./<path>" and have it prefix the path to the
>> current subdirectory from the root of the work tree, and with such an
>> enhancement, the suggestion given by this patch would probably change to
>> "Did you mean 'HEAD:./test-lib.sh'?", but that would be a separate
>> topic.
>
> Exactly. I think this HEAD:./relative-path syntax has been discussed
> here already, but I don't remember the outcome of the discussion. If
> it's ever implemented, my patch, modified as you suggest will help
> users to discover the feature ;-).
I gave it a try, and it seems it's not as easy to implement as it
seems.
The main task is to teach get_sha1_with_mode_1(..., prefix, ...) to
notice a ./ in "HEAD:./filename", and to replace it with prefix, which
is easy. The problem is to get "prefix" reliably. Since
get_sha1_with_mode_1 is called by get_sha1, which doesn't know about
prefix, and which is called from at least 92 places in the code, this
would require changing all these calls to add the "prefix" argument
(and to find out where to get this prefix from).
So, I guess I'll give up :-(. (unless someone either show a great
motivation for the feature, or a magic formula to make the patch
short)
FYI, here's the toy patch I started (works for "git show HEAD:./file",
but not for "git rev-parse HEAD:./file" for example):
diff --git a/cache.h b/cache.h
index c122bfa..a44f06f 100644
--- a/cache.h
+++ b/cache.h
@@ -708,10 +708,10 @@ static inline unsigned int hexval(unsigned char c)
#define DEFAULT_ABBREV 7
extern int get_sha1(const char *str, unsigned char *sha1);
-extern int get_sha1_with_mode_1(const char *str, unsigned char *sha1, unsigned *mode, int gently, const char *prefix);
-static inline int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode)
+extern int get_sha1_with_mode_1(const char *str, unsigned char *sha1, unsigned *mode, const char *prefix, int gently);
+static inline int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode, const char *prefix)
{
- return get_sha1_with_mode_1(str, sha1, mode, 1, NULL);
+ return get_sha1_with_mode_1(str, sha1, mode, prefix, 1);
}
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
diff --git a/revision.c b/revision.c
index 25fa14d..19ddb21 100644
--- a/revision.c
+++ b/revision.c
@@ -944,7 +944,7 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
local_flags = UNINTERESTING;
arg++;
}
- if (get_sha1_with_mode(arg, sha1, &mode))
+ if (get_sha1_with_mode(arg, sha1, &mode, revs->prefix))
return -1;
if (!cant_be_filename)
verify_non_filename(revs->prefix, arg);
@@ -1419,7 +1419,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
unsigned char sha1[20];
struct object *object;
unsigned mode;
- if (get_sha1_with_mode(revs->def, sha1, &mode))
+ if (get_sha1_with_mode(revs->def, sha1, &mode, revs->prefix))
die("bad default revision '%s'", revs->def);
object = get_reference(revs, revs->def, sha1, 0);
add_pending_object_with_mode(revs, object, revs->def, mode);
diff --git a/setup.c b/setup.c
index 5792eb7..60c1e08 100644
--- a/setup.c
+++ b/setup.c
@@ -79,7 +79,7 @@ static void NORETURN die_verify_filename(const char *prefix, const char *arg)
unsigned char sha1[20];
unsigned mode;
/* try a detailed diagnostic ... */
- get_sha1_with_mode_1(arg, sha1, &mode, 0, prefix);
+ get_sha1_with_mode_1(arg, sha1, &mode, prefix, 0);
/* ... or fall back the most general message. */
die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
"Use '--' to separate paths from revisions", arg);
diff --git a/sha1_name.c b/sha1_name.c
index ca8f9db..330d3fe 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -801,7 +801,7 @@ release_return:
int get_sha1(const char *name, unsigned char *sha1)
{
unsigned unused;
- return get_sha1_with_mode(name, sha1, &unused);
+ return get_sha1_with_mode(name, sha1, &unused, NULL);
}
/* Must be called only when object_name:filename doesn't exist. */
@@ -893,7 +893,7 @@ static void diagnose_invalid_index_path(int stage,
}
-int get_sha1_with_mode_1(const char *name, unsigned char *sha1, unsigned *mode, int gently, const char *prefix)
+int get_sha1_with_mode_1(const char *name, unsigned char *sha1, unsigned *mode, const char *prefix, int gently)
{
int ret, bracket_depth;
int namelen = strlen(name);
@@ -961,11 +961,26 @@ int get_sha1_with_mode_1(const char *name, unsigned char *sha1, unsigned *mode,
}
if (!get_sha1_1(name, cp-name, tree_sha1)) {
const char *filename = cp+1;
- ret = get_tree_entry(tree_sha1, filename, sha1, mode);
- if (!gently) {
- diagnose_invalid_sha1_path(prefix, filename,
- tree_sha1, object_name);
- free(object_name);
+ if (filename[0] == '.' && filename[1] == '/') {
+ if (!prefix)
+ prefix = "";
+ char *absfilename = xmalloc((strlen(filename) - 2)
+ + strlen(prefix) + 1);
+ strcpy(absfilename, prefix);
+ strcat(absfilename, filename+2);
+ ret = get_tree_entry(tree_sha1, absfilename, sha1, mode);
+ if (!gently) {
+ diagnose_invalid_sha1_path(prefix, absfilename,
+ tree_sha1, object_name);
+ free(object_name);
+ }
+ } else {
+ ret = get_tree_entry(tree_sha1, filename, sha1, mode);
+ if (!gently) {
+ diagnose_invalid_sha1_path(prefix, filename,
+ tree_sha1, object_name);
+ free(object_name);
+ }
}
return ret;
} else {
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply related
* Re: help: bisect single file from repos
From: Michael J Gruber @ 2009-12-07 15:08 UTC (permalink / raw)
To: wharms; +Cc: git
In-Reply-To: <4B1CFC4C.6090406@bfs.de>
walter harms venit, vidit, dixit 07.12.2009 13:59:
> Hi list,
> i am new to git (using: git version 1.6.0.2).
though your git is not that new ;)
> I would like to bisect a single file but i have only commit id, no tags.
>
> Background:
> I have a copy of the busybox git repos, and i know there is (perhaps) a bug
> in ash.c.
>
> how can i do that ?
You don't need any tags for bisecting. The man page of git-bisect has
several examples on how to use it. Do you have a test script which
exposes the bug?
Michael
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Todd Zullinger @ 2009-12-07 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Michael J Gruber, git
In-Reply-To: <7vzl5vbp7y.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Junio C Hamano wrote:
>> This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
>
> I'd change this to point at "file://$(htmldir)/", though.
Thanks. I can delete the mail with an updated patch that I started
over the weekend and didn't finish, which did that as well. ;)
Many thanks for all your hard work Junio.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aim Low, Reach Your Goals, Avoid Disappointment.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2009, #02; Sat, 05)
From: Shawn O. Pearce @ 2009-12-07 15:37 UTC (permalink / raw)
To: Martin Storsj?, Junio C Hamano; +Cc: git, rctay89
In-Reply-To: <alpine.DEB.2.00.0912061738580.5582@cone.home.martin.st>
Martin Storsj? <martin@martin.st> wrote:
> On Sun, 6 Dec 2009, Junio C Hamano wrote:
> >
> > * tr/http-updates (2009-12-01) 3 commits
> > - Allow curl to rewind the RPC read buffer
> > - Add an option for using any HTTP authentication scheme, not only basic
> > - http: maintain curl sessions
> >
> > There was a discussion on a better structure not to require rewinding in
> > the first place? I didn't follow it closely...
>
> I think the conclusion is: Rewinding support isn't strictly necessary,
> there's a number of mechanisms in both git and curl that should make sure
> that those cases shouldn't surface. A few of them in curl have an
> unfortunate conincidence of bugs up until the latest version, though,
> leaving much fewer mechanisms in place to avoid this.
>
> Since that patch is quite non-intrusive I think it's a good safeguard,
> though. What do you think, Tay, keep it or leave it?
I think the conclusion of the thread was that what you have queued
in tr/http-updates is OK as-is. The patch to grow the postbuffer
to store the entire request wasn't a good idea and got dropped.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 0/8] Remote helpers smart transport extensions
From: Nicolas Pitre @ 2009-12-07 15:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Ilari Liusvaara, git
In-Reply-To: <20091207210608.6117@nanako3.lavabit.com>
On Mon, 7 Dec 2009, Nanako Shiraishi wrote:
> Quoting Junio C Hamano <gitster@pobox.com>
>
> > I queued to ease the discussion in 'pu'. I had to fix-up some conflicts
> > while doing so. Please sanity check the result.
>
> I see that you changed many "char* variable" to "char *variable", but
> what is the reason for these changes?
The * is an attribute of the variable and not of the type. This makes
for clearer code.
Nicolas
^ permalink raw reply
* Re: help: bisect single file from repos
From: walter harms @ 2009-12-07 16:05 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B1D1A5A.9060004@drmicha.warpmail.net>
Michael J Gruber schrieb:
> walter harms venit, vidit, dixit 07.12.2009 13:59:
>> Hi list,
>> i am new to git (using: git version 1.6.0.2).
>
> though your git is not that new ;)
>
>> I would like to bisect a single file but i have only commit id, no tags.
>>
>> Background:
>> I have a copy of the busybox git repos, and i know there is (perhaps) a bug
>> in ash.c.
>>
>> how can i do that ?
>
> You don't need any tags for bisecting. The man page of git-bisect has
> several examples on how to use it. Do you have a test script which
> exposes the bug?
>
unfortunately no, the error shows up very nicely when booting my embdedded system
but not else (this is the reason i would to bisect that file only and not busybox
completely). And from the man pages i got the impression that it is only possible the
start with a tag.
i already had the hint that i need to do:
git bisect start bad_commit_id good_commit_id -- ash.c
Ntl, there is one more question, how can i make sure that
i use the right version ? first i toughed that cherry-pick is the right idea
but it seems that that will apply onyl certain patches ?
re,
wh
^ permalink raw reply
* Re: [Admins] Re: git-svn breakage on repository rename
From: Jérôme Petazzoni @ 2009-12-07 16:21 UTC (permalink / raw)
To: Guido Stevens; +Cc: Eric Wong, wichert, George Kuk, admins, clark.alex, git
In-Reply-To: <4B1BDAC4.9070305@cosent.net>
Guido Stevens wrote:
> Thanks everybody for helping to solve this problem! I can now integrate
> the analysis of Products.CMFPlone into the overall Plone ecosystem
> analysis, and it would have been very awkward not to be able to do that
> because of this renaming issue. Again: thanks.
>
You're very welcome :-)
^ permalink raw reply
* Re: [RFC PATCH v3 0/8] Remote helpers smart transport extensions
From: Ilari Liusvaara @ 2009-12-07 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hsz9qxj.fsf@alter.siamese.dyndns.org>
On Sun, Dec 06, 2009 at 11:36:08PM -0800, Junio C Hamano wrote:
> I queued to ease the discussion in 'pu'. I had to fix-up some conflicts
> while doing so. Please sanity check the result.
The conflict resolution seems sane.
Sorry about leaving lots of codingstyle stuff unfixed.
-Ilari
^ permalink raw reply
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Shawn O. Pearce @ 2009-12-07 16:41 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <1260185254-1523-2-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> As stated in the cover letter, I simply cannot store note information in
> the tree_entry mode bits. So, I chose this somewhat more simple and crude
> approach, which I still think solves the problems quite nicely.
Oh, duh. Of course you can't. You lose the note mode when the
tree is flushed to disk, purged from memory, and reloaded later.
Whoops, sorry I missed that during the last round of review.
> +static uintmax_t do_change_note_fanout(
> + struct tree_entry *orig_root, struct tree_entry *root,
> + char *hex_sha1, unsigned int hex_sha1_len,
> + char *fullpath, unsigned int fullpath_len,
> + unsigned char fanout)
I think this function winds up processing all notes twice. Yuck.
tree_content_set() adds a new tree entry to the end of the current
tree. So when converting "1a9029b006484e8b9aca06ff261beb2324bb9916"
into "1a" (to go from fanout 0 to fanout 1) we'll place 1a at the
end of orig_root, and this function will walk 1a/ recursively,
examining 1a9029b006484e8b9aca06ff261beb2324bb9916 all over again.
If we're here, isn't it likely that *all* notes are in the wrong
path in the tree, and we need to move them all to a new location?
If that's true then should we instead just build an entirely new
tree and swap the root when we are done?
As we empty out a tree the object will be recycled into a pool of
trees which can be reused at a later point. It might actually make
sense to build the new tree under a different root. We won't scan
entries we've moved, and the memory difference should be fairly
small as tree_content_remove() will make a subtree available for
reuse as soon as its empty. So we're only dealing with a handful
of additional tree objects as we do the conversion.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Shawn O. Pearce @ 2009-12-07 16:43 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <1260185254-1523-2-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> +static unsigned char convert_num_notes_to_fanout(uintmax_t num_notes)
> +{
> + unsigned char fanout = 0;
> + while ((num_notes >>= 8))
> + fanout++;
> + return fanout;
> +}
> +
> +static void construct_path_with_fanout(const char *hex_sha1,
> + unsigned char fanout, char *path)
> +{
> + unsigned int i = 0, j = 0;
> + if (fanout >= 20)
> + die("Too large fanout (%u)", fanout);
Shouldn't convert_num_notes_to_fanout have a guard to prevent this
case from happening?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 5/8] Support taking over transports
From: Shawn O. Pearce @ 2009-12-07 17:49 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260116931-16549-6-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> @@ -109,9 +120,21 @@ static struct child_process *get_helper(struct transport *transport)
> die("Unable to run helper: git %s", helper->argv[0]);
> data->helper = helper;
>
> + /* Open the output as FILE* so strbuf_getline() can be used.
> + Do this with duped fd because fclose() will close the fd,
> + and stuff like disowning will require the fd to remain.
> +
> + Set the stream to unbuffered because some reads are critical
> + in sense that any overreading will cause deadlocks.
> + */
> + duped = dup(helper->out);
Formatting error here, the line is indented wrong.
> + if (duped < 0)
> + die_errno("Can't dup helper output fd");
> + data->out = xfdopen(duped, "r");
> + setvbuf(data->out, NULL, _IONBF, 0);
I wonder if this is really a good idea. Most helpers actually
use a lot of text based IO to communicate. Disabling buffering
for those helpers to avoid overreading the advertisement from a
connect is a problem.
Maybe we could leave buffering on, but use a handshake protocol
with the helper during connect:
(1) > "connect git-upload-pack\n"
(2) < "\n"
(3) > "begin\n"
During 2 we are still buffered, but the only content on the pipe
should be the single blank line, so we pull that in and the FILE*
buffer should be empty.
After writing message 2 the remote helper blocks reading for the
"begin\n" message 3. This gives the transport-helper.c code time
to switch off the FILE* and start using raw IO off the pipe before
any data starts coming down the line.
It does mean that the helper may need to run unbuffered IO, but
if the helper is only a smart helper supporting connect then this
isn't really a problem. It can run buffered IO until connect is
received, switch to unbuffered, and use unbuffered for the single
"begin\n" message it has to consume before it starts writing output
or reading input.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 6/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-07 18:11 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260116931-16549-7-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> diff --git a/transport-helper.c b/transport-helper.c
> index 3d99fe1..e0254bc 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> static int fetch(struct transport *transport,
> int nr_heads, struct ref **to_fetch)
> {
> struct helper_data *data = transport->data;
> int i, count;
>
> + if (process_connect(transport, 0)) {
> + transport_take_over(transport);
> + return transport->fetch(transport, nr_heads, to_fetch);
> + }
We should already be connected because of the prior call into
get_refs_list(). If I read your code correctly we'd try to open
a new connection right here, which makes no sense. But its also
possible for us to be in a different transport, so we do code with
the assumption that we didn't get invoked through get_refs_list()
first and therefore need to open the connection ourselves.
Also, given the above invocation pattern, I see no reason why you
need the disown virtual function on struct transport*. Just pass
the #@!**! struct child* into transport_take_over() from the 3
call sites here and get rid of that unnecessary indirection.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support remote archive from external protocol helpers
From: Shawn O. Pearce @ 2009-12-07 18:12 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260116931-16549-8-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> Helpers which support invoke/connect also should support remote archive
There is no such thing as invoke anymore.
--
Shawn.
^ permalink raw reply
* [PATCH 0/2] git-add/rm documentation
From: Björn Gustavsson @ 2009-12-07 18:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The following patch series can be applied on top
of bg/maint-add-all-doc in 'pu'.
Björn Gustavsson (2):
git-add/rm doc: Consistently back-quote
git-rm doc: Describe how to sync index & work tree
Documentation/git-add.txt | 24 +++++++++---------
Documentation/git-rm.txt | 59 +++++++++++++++++++++++++++++++++++++++++---
2 files changed, 67 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 1/2] git-add/rm doc: Consistently back-quote
From: Björn Gustavsson @ 2009-12-07 18:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Consistently back-quote commands, options and file names.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/git-add.txt | 24 ++++++++++++------------
Documentation/git-rm.txt | 6 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ed68ea3..1f1b199 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -24,22 +24,22 @@ remove paths that do not exist in the working tree anymore.
The "index" holds a snapshot of the content of the working tree, and it
is this snapshot that is taken as the contents of the next commit. Thus
after making any changes to the working directory, and before running
-the commit command, you must use the 'add' command to add any new or
+the commit command, you must use the `add` command to add any new or
modified files to the index.
This command can be performed multiple times before a commit. It only
adds the content of the specified file(s) at the time the add command is
run; if you want subsequent changes included in the next commit, then
-you must run 'git add' again to add the new content to the index.
+you must run `git add` again to add the new content to the index.
-The 'git status' command can be used to obtain a summary of which
+The `git status` command can be used to obtain a summary of which
files have changes that are staged for the next commit.
-The 'git add' command will not add ignored files by default. If any
-ignored files were explicitly specified on the command line, 'git add'
+The `git add` command will not add ignored files by default. If any
+ignored files were explicitly specified on the command line, `git add`
will fail with a list of ignored files. Ignored files reached by
directory recursion or filename globbing performed by Git (quote your
-globs before the shell) will be silently ignored. The 'add' command can
+globs before the shell) will be silently ignored. The `add` command can
be used to add ignored files with the `-f` (force) option.
Please see linkgit:git-commit[1] for alternative ways to add content to a
@@ -119,8 +119,8 @@ subdirectories.
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
- such files with 'git diff' and committing them with 'git commit
- -a'.
+ such files with `git diff` and committing them with `git commit
+ -a`.
--refresh::
Don't add the file(s), but only refresh their stat()
@@ -140,7 +140,7 @@ subdirectories.
Configuration
-------------
-The optional configuration variable 'core.excludesfile' indicates a path to a
+The optional configuration variable `core.excludesfile` indicates a path to a
file containing patterns of file names to exclude from git-add, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
those in info/exclude. See linkgit:gitrepository-layout[5].
@@ -188,7 +188,7 @@ and type return, like this:
What now> 1
------------
-You also could say "s" or "sta" or "status" above as long as the
+You also could say `s` or `sta` or `status` above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
@@ -196,9 +196,9 @@ The main command loop has 6 subcommands (plus help and quit).
status::
This shows the change between HEAD and index (i.e. what will be
- committed if you say "git commit"), and between index and
+ committed if you say `git commit`), and between index and
working tree files (i.e. what you could stage further before
- "git commit" using "git-add") for each path. A sample output
+ `git commit` using `git add`) for each path. A sample output
looks like this:
+
------------
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 5afb1e7..d4162f6 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -12,13 +12,13 @@ SYNOPSIS
DESCRIPTION
-----------
Remove files from the index, or from the working tree and the index.
-'git-rm' will not remove a file from just your working directory.
+`git rm` will not remove a file from just your working directory.
(There is no option to remove a file only from the work tree
and yet keep it in the index; use `/bin/rm` if you want to do that.)
The files being removed have to be identical to the tip of the branch,
and no updates to their contents can be staged in the index,
though that default behavior can be overridden with the `-f` option.
-When '--cached' is given, the staged content has to
+When `--cached` is given, the staged content has to
match either the tip of the branch or the file on disk,
allowing the file to be removed from just the index.
@@ -64,7 +64,7 @@ OPTIONS
-q::
--quiet::
- 'git-rm' normally outputs one line (in the form of an "rm" command)
+ `git rm` normally outputs one line (in the form of an `rm` command)
for each file removed. This option suppresses that output.
--
1.6.6.rc1.31.g1a56b
^ permalink raw reply related
* [PATCH 2/2] git-rm doc: Describe how to sync index & work tree
From: Björn Gustavsson @ 2009-12-07 18:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Newcomers to git that want to remove from the index only the
files that have disappeared from the working tree will probably
look for a way to do that in the documentation for 'git rm'.
Therefore, describe how that can be done (even though it involves
other commands than 'git rm'). Based on a suggestion by Junio,
but re-arranged and rewritten to better fit into the style of
command reference.
While at it, change a single occurrence of "work tree" to "working
tree" for consistency.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
To better fit a reference page (IMO), I have changed the
order of the commands, and have put the straightforward
command last as it is the least useful, and I have removed
the "bad examples" (using two commands instead of simply
'git add -A'). I realize that those examples have their value,
too, but since most people scan a reference page quickly
to find what they'll need, it will just confuse them.
Documentation/git-rm.txt | 53 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index d4162f6..c622972 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -13,7 +13,7 @@ DESCRIPTION
-----------
Remove files from the index, or from the working tree and the index.
`git rm` will not remove a file from just your working directory.
-(There is no option to remove a file only from the work tree
+(There is no option to remove a file only from the working tree
and yet keep it in the index; use `/bin/rm` if you want to do that.)
The files being removed have to be identical to the tip of the branch,
and no updates to their contents can be staged in the index,
@@ -81,6 +81,57 @@ two directories `d` and `d2`, there is a difference between
using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will
also remove all of directory `d2`.
+REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM
+--------------------------------------------------------
+There is no option for `git rm` to remove from the index only
+the paths that have disappeared from the filesystem. However,
+depending on the use case, there are several ways that can be
+done.
+
+Using "git commit -a"
+~~~~~~~~~~~~~~~~~~~~~
+If you intend that your next commit should record all modifications
+of tracked files in the working tree and record all removals of
+files that have been removed from the working tree with `rm`
+(as opposed to `git rm`), use `git commit -a`, as it will
+automatically notice and record all removals.
+
+Using "git add -A"
+~~~~~~~~~~~~~~~~~~
+When accepting a new code drop for a vendor branch, you probably
+want to record both the removal of paths and additions of new paths
+as well as modifications of existing paths.
+
+Typically you would first remove all tracked files from the working
+tree using this command:
+
+----------------
+git ls-files -z | xargs -0 rm -f
+----------------
+
+and then "untar" the new code in the working tree. Alternately
+you could "rsync" the changes into the working tree.
+
+After that, the easiest way to record all removals, additions, and
+modifications in the working tree is:
+
+----------------
+git add -A
+----------------
+
+See linkgit:git-add[1].
+
+Other ways
+~~~~~~~~~~
+If all you really want to do is to remove from the index the files
+that are no longer present in the working tree (perhaps because
+your working tree is dirty so that you cannot use `git commit -a`),
+use the following command:
+
+----------------
+git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
+----------------
+
EXAMPLES
--------
git rm Documentation/\\*.txt::
--
1.6.6.rc1.31.g1a56b
^ permalink raw reply related
* [BUG] git config does not reuse section name
From: Yakup Akbay @ 2009-12-07 17:06 UTC (permalink / raw)
To: git
When I repeat the following n times
$ git config color.ui always
$ git config --unset color.ui
it ends up the section name [color] n times in the .git/config file.
like this for n=4:
[color]
[color]
[color]
[color]
Using git version 1.6.5.3 (I don't know whether this is already fixed in
in later versions)
Yakup
^ permalink raw reply
* Re: [BUG] git config does not reuse section name
From: Junio C Hamano @ 2009-12-07 20:04 UTC (permalink / raw)
To: Yakup Akbay; +Cc: git, Johannes Schindelin
In-Reply-To: <4B1D360B.4070203@ubicom.com>
Yakup Akbay <yakbay@ubicom.com> writes:
> When I repeat the following n times
>
> $ git config color.ui always
> $ git config --unset color.ui
>
>
> it ends up the section name [color] n times in the .git/config file.
>
>
>
> like this for n=4:
>
> [color]
> [color]
> [color]
> [color]
>
>
> Using git version 1.6.5.3 (I don't know whether this is already fixed
> in in later versions)
If I recall correctly, this hasn't been even noticed/reported/recognized
as an issue, ever since the "git repo-config" was introduced (which later
was renamed to "git config"). Dscho, do you remember details?
^ permalink raw reply
* Re: [RFC PATCH v3 0/8] Remote helpers smart transport extensions
From: Junio C Hamano @ 2009-12-07 20:05 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091207163338.GA27516@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Sun, Dec 06, 2009 at 11:36:08PM -0800, Junio C Hamano wrote:
>> I queued to ease the discussion in 'pu'. I had to fix-up some conflicts
>> while doing so. Please sanity check the result.
>
> The conflict resolution seems sane.
>
> Sorry about leaving lots of codingstyle stuff unfixed.
No problem at all, and thanks.
^ permalink raw reply
* Re: [RFC PATCH v3 0/8] Remote helpers smart transport extensions
From: Junio C Hamano @ 2009-12-07 20:07 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Ilari Liusvaara, git
In-Reply-To: <20091207210608.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> I queued to ease the discussion in 'pu'. I had to fix-up some conflicts
>> while doing so. Please sanity check the result.
>
> I see that you changed many "char* variable" to "char *variable", but
> what is the reason for these changes?
Nico already gave you correct and more concise version; this more verbose
explanation is primarily for you who said a few times that you are not
fluent in C. Others can skip this message without missing anything.
I haven't asked people why they choose to write like this:
char* string;
beyond "that is how we were taught and what we are used to".
But if I have to guess, it is because it makes it appear as if you are
being consistent between basic types like "int" and pointer types like
"char *". E.g. these both look like "<type> <variable>;"
int variable;
char* variable;
The example in CodingGuidelines gives a clear illustration that this
however is not the way how C language works. IOW, the syntax for
declaration is not "<type> <var1>, <var2>,...;". E.g.
char* var1, var2;
declares var1, which is a pointer to a char, and var2, which is a char.
That is what Nico means by '* is an attribute of the variable and not of
the type'.
The only sane way to read declaration in C is to read from inside to
outside, starting from a variable name. When you read "char **argv", for
example, you treat it as "char (*(*argv))", and read it from the variable
name:
- It declares argv; what's the type of it I wonder...
- It is a pointer, because the asterisk in front of it tells us that
we can dereference it. Now, what's the type of the result of
dereferencing argv, i.e. "*argv", I wonder...
- That "*argv" is a pointer, because the asterisk in front of it again
tells us that we can dereference it. Now, what's the type of
dereferencing that "*argv", i.e. "**argv", I wonder...
- Ah, it is a "char", that is what this declaration says.
And the style we use (which is the same as Linux kernel style) naturally
matches the way how you read this declaration.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2009, #02; Sat, 05)
From: Junio C Hamano @ 2009-12-07 20:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Storsj?, git, rctay89
In-Reply-To: <20091207153736.GC17173@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Martin Storsj? <martin@martin.st> wrote:
>> On Sun, 6 Dec 2009, Junio C Hamano wrote:
>> >
>> > * tr/http-updates (2009-12-01) 3 commits
>> > - Allow curl to rewind the RPC read buffer
>> > - Add an option for using any HTTP authentication scheme, not only basic
>> > - http: maintain curl sessions
>> >
>> > There was a discussion on a better structure not to require rewinding in
>> > the first place? I didn't follow it closely...
>>
>> I think the conclusion is: Rewinding support isn't strictly necessary,
>> there's a number of mechanisms in both git and curl that should make sure
>> that those cases shouldn't surface. A few of them in curl have an
>> unfortunate conincidence of bugs up until the latest version, though,
>> leaving much fewer mechanisms in place to avoid this.
>>
>> Since that patch is quite non-intrusive I think it's a good safeguard,
>> though. What do you think, Tay, keep it or leave it?
>
> I think the conclusion of the thread was that what you have queued
> in tr/http-updates is OK as-is. The patch to grow the postbuffer
> to store the entire request wasn't a good idea and got dropped.
Thanks.
^ permalink raw reply
* Re: [BUG] git config does not reuse section name
From: Sverre Rabbelier @ 2009-12-07 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yakup Akbay, git, Johannes Schindelin
In-Reply-To: <7vy6le35zv.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Dec 7, 2009 at 21:04, Junio C Hamano <gitster@pobox.com> wrote:
> If I recall correctly, this hasn't been even noticed/reported/recognized
> as an issue, ever since the "git repo-config" was introduced (which later
> was renamed to "git config").
I poked Dscho about it at some point.
> Dscho, do you remember details?
He told me that the 'git config' code is so horrible that it's
nigh-impossible to change the behavior, hence why he didn't do it :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH v3 6/8] Support remote helpers implementing smart transports
From: Ilari Liusvaara @ 2009-12-07 20:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091207181148.GG17173@spearce.org>
On Mon, Dec 07, 2009 at 10:11:48AM -0800, Shawn O. Pearce wrote:
>
> We should already be connected because of the prior call into
> get_refs_list(). If I read your code correctly we'd try to open
> a new connection right here, which makes no sense.
The have prior connection case can't happen since take_over_transport()
overwrites the method pointers.
> But its also
> possible for us to be in a different transport, so we do code with
> the assumption that we didn't get invoked through get_refs_list()
> first and therefore need to open the connection ourselves.
Right. The reason why the code is there is in case somebody invokes
fetch() first.
The same things apply to push function too.
> Also, given the above invocation pattern, I see no reason why you
> need the disown virtual function on struct transport*. Just pass
> the #@!**! struct child* into transport_take_over() from the 3
> call sites here and get rid of that unnecessary indirection.
Fixed.
-Ilari
^ permalink raw reply
* [PATCH] git-gui: Unstaging a partly staged entry didn't update file_states correctly
From: Jens Lehmann @ 2009-12-07 20:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano
When unstaging a partly staged file or submodule, the file_states list
was not updated properly (unless unstaged linewise). Its index_info part
did not contain the former head_info as it should have but kept its old
value.
This seems not to have had any bad effects but diminishes the value of
the file_states list for future enhancements.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I noticed this while whipping up another - soon to be released - patch
where the file_states list is used to access the hash values of staged
and unstaged changes.
AFAICS this buglet did not have negative effects until now because the
index_info hash value is not used.
git-gui/git-gui.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 037a1f2..9495789 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1613,6 +1613,9 @@ proc merge_state {path new_state {head_info {}} {index_info {}}} {
} elseif {$s0 ne {_} && [string index $state 0] eq {_}
&& $head_info eq {}} {
set head_info $index_info
+ } elseif {$s0 eq {_} && [string index $state 0] ne {_}} {
+ set index_info $head_info
+ set head_info {}
}
set file_states($path) [list $s0$s1 $icon \
--
1.6.6.rc1.245.gcec33.dirty
^ 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