* [PATCH] Add commit.status, --status, and --no-status
From: James P. Howard, II @ 2009-12-07 22:45 UTC (permalink / raw)
To: git; +Cc: James P. Howard, II
In-Reply-To: <20091206131217.GA12851@sigill.intra.peff.net>
This commit provides support for commit.status, --status, and
--no-status, which control whether or not the git status information
is included in the commit message template when using an editor to
prepare the commit message. It does not affect the effects of a
user's commit.template settings.
Signed-off-by: James P. Howard, II <jh@jameshoward.us>
---
Documentation/config.txt | 5 +++++
Documentation/git-commit.txt | 14 +++++++++++++-
builtin-commit.c | 9 +++++++--
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..5561560 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -705,6 +705,11 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.status
+ A boolean to enable/disable inclusion of status information in the
+ commit message template when using an editor to prepare the commit
+ message. Defaults to true.
+
commit.template::
Specify a file to use as the template for new commit messages.
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d227cec..0e53518 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,8 @@ SYNOPSIS
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+ [--cleanup=<mode>] [--status | --no-status] [--]
+ [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -207,6 +208,17 @@ specified.
to be committed, paths with local changes that will be left
uncommitted and paths that are untracked.
+--status::
+ Include the output of linkgit:git-status[1] in the commit
+ message template when using an editor to prepare the commit
+ message. Defaults to on, but can be used to override
+ configuration variable commit.status.
+
+--no-status::
+ Do not include the output of linkgit:git-status[1] in the
+ commit message template when using an editor to prepare the
+ default commit message.
+
\--::
Do not interpret any more arguments as options.
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..095c186 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -67,7 +67,7 @@ static enum {
} cleanup_mode;
static char *cleanup_arg;
-static int use_editor = 1, initial_commit, in_merge;
+static int use_editor = 1, initial_commit, in_merge, include_status = 1;
static const char *only_include_assumed;
static struct strbuf message;
@@ -97,6 +97,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_FILENAME('t', "template", &template_file, "use specified template file"),
OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
+ OPT_BOOLEAN(0, "status", &include_status, "include status in commit message template"),
OPT_GROUP("Commit contents options"),
OPT_BOOLEAN('a', "all", &all, "commit all changed files"),
@@ -547,7 +548,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
/* This checks if committer ident is explicitly given */
git_committer_info(0);
- if (use_editor) {
+ if (use_editor && include_status) {
char *author_ident;
const char *committer_ident;
@@ -1006,6 +1007,10 @@ static int git_commit_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "commit.template"))
return git_config_pathname(&template_file, k, v);
+ if (!strcmp(k, "commit.status")) {
+ include_status = git_config_bool(k, v);
+ return 0;
+ }
return git_status_config(k, v, s);
}
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-07 22:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091206042206.GC23983@coredump.intra.peff.net>
On Sat, Dec 5, 2009 at 23:22, Jeff King <peff@peff.net> wrote:
> Probably "--no-status" would be a good name, as the generated template
> is the format generated by "git status".
I have produced a patch against master that implements this in, what I
hope, is a better way.
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [RFC PATCH v3 0/8] Remote helpers smart transport extensions
From: Nanako Shiraishi @ 2009-12-07 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Nicolas Pitre, Ilari Liusvaara, git
In-Reply-To: <7vein635vn.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.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.
Thanks everybody for quick answers and thank you, Junio,
for a detailed explanation. Now I understand.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-apply fails on creating a new file, with both -p and --directory specified
From: James Vega @ 2009-12-07 21:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vws1e3ma1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> "Steven J. Murdoch" <git+Steven.Murdoch <at> cl.cam.ac.uk> writes:
>
> > This appears to be because I was both using -p to strip some path
> > components, and --directory to add different ones in. Only creating
> > new files was affected.
>
> A very nicely done report.
>
> In addition to your test case, I suspect that a patch that only changes
> mode would have acted funny with -p<n> option.
>
It looks like this may have introduced a bug when staging a file
removal. Here's an example git session showing the issue:
$ git init test
Initialized empty Git repository in /local_disk/tmp/test/.git/
$ cd test
$ echo "foo" > foo
$ git add foo
$ git commit -m 'Add foo'
[master (root-commit) 3643b5d] Add foo
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ mv foo bar
$ git add -p
diff --git a/foo b/foo
index 257cc56..0000000
--- a/foo
+++ /dev/null
@@ -1 +0,0 @@
-foo
Stage this hunk [y,n,q,a,d,/,e,?]? y
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# new file: dev/null
# deleted: foo
#
# Changed but not updated:
# (use "git add/rm ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# deleted: dev/null
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# bar
Replacing the 'git add -p' with
git diff | sed '/^deleted file/d' | git apply --cached
also exhibits the problem.
^ permalink raw reply related
* Re: [RFC PATCH v3 5/8] Support taking over transports
From: Ilari Liusvaara @ 2009-12-07 21:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091207174947.GF17173@spearce.org>
On Mon, Dec 07, 2009 at 09:49:47AM -0800, Shawn O. Pearce wrote:
>
> > + 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.
I dropped the buffering change.
> 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.
Doesn't work. Stream buffering can only be changed before first
I/O.
I figured out a solution. Dup the file descriptor second time and
make another FILE* for it. Then send the connect and read the
response over the new stream. This avoids overreading and allows
other I/O to be buffered. After connect attempt, the new streaam
can be closed.
This way most of the I/O can be buffered, only reading responses
to connect commands can't, and that is at most 1 byte if fallbacks
aren't required. And the thing fits nicely inside _process_connect().
Oh, and no protocol change needed.
-Ilari
^ permalink raw reply
* Re: How do you best store structured data in git repositories?
From: Sebastian Setzer @ 2009-12-07 21:20 UTC (permalink / raw)
To: git
In-Reply-To: <20091204001359.GA6709@gmail.com>
On Thursday, Dec 03 2009 at 16:14 -0800, David Aguilar wrote:
> On Wed, Dec 02, 2009 at 04:17:10PM -0500, Avery Pennarun wrote:
> > On Wed, Dec 2, 2009 at 4:08 PM, Sebastian Setzer
> > <sebastianspublicaddress@googlemail.com> wrote:
> > > Do you use XML for this purpose?
> >
> > XML is terrible for most data storage purposes.
>
> I agree 100%.
>
> JSON's not too bad for data structures and is known to
> be friendly to XML expats.
>
Sorry, I didn't want to start a flamewar against XML. I'm no big friend
of XML myself, but I don't know of an (open source) diff-/merge tool for
any general purpose file format other than XML or plain text.
When you mention other formats, I'd be interested in
- why this format is good for storage in git
- if there are merge tools available which ensure that, after a merge,
the structure (and maybe additional contraints) is still valid.
Thanks for your comments,
Sebastian
^ permalink raw reply
* Re: [PATCH 2/2] git-rm doc: Describe how to sync index & work tree
From: Junio C Hamano @ 2009-12-07 21:08 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B1D4AFE.6090708@gmail.com>
Looks sensible.
I think mentioning "add -u" in the same section as "commit -a" would be
helpful, as these two are more for user's own development (as opposed to
vendor-code-drop). I'd perhaps squash something like this in. Please say
"yes", "don't, it is horrible", or something in between ;-)
--
Documentation/git-rm.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index c622972..42161d7 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -94,7 +94,8 @@ 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.
+automatically notice and record all removals. `git add -u`
+can be used for a similar effect without commiting.
Using "git add -A"
~~~~~~~~~~~~~~~~~~
^ permalink raw reply related
* Re: [BUG] git config does not reuse section name
From: Junio C Hamano @ 2009-12-07 20:54 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Yakup Akbay, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0912071223l21c70e2ax9b0e3c9976ae9d7@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> 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.
Hmm, sad. I thought it was mostly his code...
^ permalink raw reply
* Re: [RFC/PATCHv10 08/11] Notes API: get_note(): Return the note annotating the given object
From: Junio C Hamano @ 2009-12-07 20:52 UTC (permalink / raw)
To: Johan Herland; +Cc: git, spearce
In-Reply-To: <1260185254-1523-9-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Created by a simple cleanup and rename of lookup_notes().
>
> Signed-off-by: Johan Herland <johan@herland.net>
> ---
> notes.c | 15 ++++++++-------
> notes.h | 3 +++
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/notes.c b/notes.c
> index 79bfa24..110404a 100644
> --- a/notes.c
> +++ b/notes.c
> @@ -379,12 +379,13 @@ void add_note(const unsigned char *object_sha1, const unsigned char *note_sha1)
> note_tree_insert(&root_node, 0, l, PTR_TYPE_NOTE);
> }
>
> -static unsigned char *lookup_notes(const unsigned char *object_sha1)
> +const unsigned char *get_note(const unsigned char *object_sha1)
Is there a need to find "note for this commit in the set of notes 3 days
ago"? IOW, reading note for the given commit not from the tip of the
history of the refs/notes/commits but from say refs/notes/commits~4?
Similarly, is there a need to ask for a history of notes for a given
commit, something like "git log refs/notes/commit/$this_commit" in a world
without any fanout?
Obviously, "there is no need because..." is the best answer I'd be happy
with. "There may be in the future but we haven't identified a good use
case and we don't implement what we do not need now." is also perfectly
acceptable.
IOW, I am not suggesting to change it---I just want to know how much
thought went in before deciding to implement the interface this way.
^ permalink raw reply
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Junio C Hamano @ 2009-12-07 20:42 UTC (permalink / raw)
To: Johan Herland; +Cc: git, spearce
In-Reply-To: <1260185254-1523-2-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> This patch teaches 'git fast-import' to automatically organize note objects
> in a fast-import stream into an appropriate fanout structure.
I really hate to sound like a clueless newbie, but that is what I am in
the area of 'notes', so I have two questions.
- What is the semantics of having more than one note to the same commit
in the input stream? Does the 'notes' part also have history and the
latest one overwrite the earlier one by creating a new commit that
points at the new 'notes' tree? I've always thought of 'notes' as an
unversioned metainfo, but I realize that versioning them would make
sense (you can and obviously would want to inspect the story behind the
current note attached to one particular commit).
- If however 'notes' want to have a history, how would it interact with
this rebalancing of the tree? Rebalancing makes a lot of sense if the
'notes' mechanism deals with the only one latest version because it can
keep the optimal look-up performance. There were some talks about
specialized merge strategies that can be made aware of rebalancing, but
is there a plan to deal with "git log -p notes" side, and how?
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support remote archive from external protocol helpers
From: Ilari Liusvaara @ 2009-12-07 20:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091207181227.GH17173@spearce.org>
On Mon, Dec 07, 2009 at 10:12:27AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> There is no such thing as invoke anymore.
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
* 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
* 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: 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: [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: [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: [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
* [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
* [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
* [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 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
* 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
* 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 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
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