* Re: [PATCH 1/2] Suggest use of 'git add' when 'nothing to commit' gets shown.
From: Andreas Ericsson @ 2006-12-15 9:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <20061215001350.GA26755@spearce.org>
Shawn O. Pearce wrote:
> else
> if [ -z "$(git-ls-files)" ]; then
> - echo >&2 Nothing to commit
> + echo >&2 "Nothing to commit (use \"git add\" include for commit)"
s/git add include/git add to include/
> exit 1
> fi
> PARENTS=""
> diff --git a/wt-status.c b/wt-status.c
> index 6e9414d..f9ed54f 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
> int i;
> if (q->nr)
> wt_status_print_header("Changed but not updated",
> - "use git-add on files to include for commit");
> + "use \"git add\" on files to include for commit");
Here it's "on files", whereas in other threads people have stated that
git add adds content, so perhaps
use \"git add file1 file2\" to include for commit
which also gives a nice "simplest-possible-usage" message.
> if (!shown_header) {
> wt_status_print_header("Untracked files",
> - "use \"git add\" to add to commit");
> + "use \"git add\" on files to include for commit");
Same here.
> if (!s->commitable)
> - printf("%s\n", s->amend ? "# No changes" : "nothing to commit");
> + printf("%s (use \"git add\" include for commit)\n",
> + s->amend ? "# No changes" : "Nothing to commit");
> }
This is same as first one (missing "to " before "include").
It would probably be nice to use one and the same message everywhere though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] git-show: grok blobs, trees and tags, too
From: Santi Béjar @ 2006-12-15 9:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612141129320.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Since git-show is pure Porcelain, it is the ideal candidate to
> pretty print other things than commits, too.
I think "git show ${tag}" should be more like "git show ${commit}",
that is, with the tagger and date information and the indent, as:
$ git show v1.4.4.2
tag v1.4.4.2
Tagger: Junio C Hamano <junkio@cox.net>
Date: ${Date}
GIT 1.4.4.2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBFdx8+wMbZpPMRm5oRAsOXAJsGY8DIYey1TZlEXIGq5+8MNgEl1QCfQC0f
c5SmdLmAm2KPsCf+bCuoK+k=
=oDuA
-----END PGP SIGNATURE-----
commit 49ed2bc4660c7cd0592cf21cc514080574d06320
...
>
> +EXAMPLES
> +--------
> +
> +git show v1.0.0::
> + Shows the tag `v1.0.0`.
and the commit (or object) it references.
I would add:
git show v1.0.0^{}::
Shows only the commit referenced by the tag `v1.0.0`.
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Andy Parkins @ 2006-12-15 9:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre
In-Reply-To: <7vfybiyqk0.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 December 15 00:02, Junio C Hamano wrote:
> Andy, which version of git do you run (I presume they are the
> same version, as you are doing the local fetching), and which
> version of git was the "slightly out of date" repository
> prepared with?
One of them is switched off and in another place at the moment, so this is
from memory:
The initial repository was made with origin/master from a few days ago, that's
the one I've been calling "out-of-date". I cloned that to another computer
and continued adding patches using "1.4.4.1.g3ece-dirty" (the dirt is just my
colour branch patch on top of ba988a83). The fetch is being done back on the
original system which has the newer git but older repository.
I hadn't realised it was quite a serious as these responses are making it
sound. I'll gather more precise data upon my return home.
On the up-to-date computer I've just made a fresh repository, set .git/config
to point locally at the full repository and ran git-fetch. Interestingly,
that has worked perfectly.
Clearly it is version-specific. I'll do a bit of bisection later and see if I
can nail the problem down.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Jakub Narebski @ 2006-12-15 9:55 UTC (permalink / raw)
To: git
In-Reply-To: <20061214111557.GA24297@spearce.org>
Shawn O. Pearce wrote:
> +# Define NO_FAST_WORKING_DIRECTORY if accessing objects in pack files is
> +# generally faster on your platform than accessing the working directory.
> +#
Hmmm... I wonder if generated by autoconf ./configure script can autodetect
that. Probably not.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git fetch slow as molasses due to tag downloading
From: Jakub Narebski @ 2006-12-15 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612141701440.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> IMHO this should be solved as a filter: "git-show-ref --stdin
> --show-invalid". Thus, git does not have to traverse _every_ ref for
> _every_ incoming tag.
Can you make it so? TIA.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* RE: What's in git.git (stable)
From: Raimund Bauer @ 2006-12-15 9:55 UTC (permalink / raw)
To: 'Andy Parkins', git
In-Reply-To: <200612150858.25988.andyparkins@gmail.com>
> Yep. Although you've persuaded me with the above example, I
> think this is the
> correct path. It's not wise to add every bell and whistle
> just because we
> can. As long as there is /a/ way to achieve every task,
> that's good enough,
> we don't need every way to achieve every task. We might even
> argue that
> git's flexibility is what makes it harder to learn. It's
> similar to UNIX in
> that respect - hard to learn, easy to use.
So we prefer to tell users "You can do what you want with these 3 commands,
since we don't want to confuse use with another option to do it with just
1"?
> Andy
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH] Cleanup git-diff documentation
From: Jakub Narebski @ 2006-12-15 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <9A80051B-1F6B-4FFD-B33F-84121D3A422F@silverinsanity.com>
Brian Gernhardt wrote:
> -This command shows changes between four combinations of states.
> +Show changes between two trees, a tree and the working tree, a
> +tree and the index file, or the index file and the working tree.
> +The combination of what is compared with what is determined by
> +the number of trees given to the command.
You talk here about "number of _trees_" while later you use <commit>,
not <tree> or <tree-ish>. Only at the very end you say that <commit>
(<commit-ish> because you can use tags as well) can be replaced by
any <tree-ish>.
That said, I like this clarification, especially the fact that
I don't have to go to git-diff-tree(1) to find diff options.
> 'git-diff' [--options] [--] [<path>...]::
> @@ -25,11 +28,11 @@ This command shows changes between four
> combinations of states.
> 'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
> This form is to view the changes you staged for the next
> - commit relative to the named <tree-ish>. Typically you
> + commit relative to the named <commit>. Typically you
> would want comparison with the latest commit, so if you
> do not give <commit>, it defaults to HEAD.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-show: grok blobs, trees and tags, too
From: Johannes Schindelin @ 2006-12-15 10:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eltng7$te5$2@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 485 bytes --]
Hi,
On Fri, 15 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > +For tags, it shows the tag message and the referenced objects.
> [...]
> > +EXAMPLES
> > +--------
> > +
> > +git show v1.0.0::
> > + Shows the tag `v1.0.0`.
>
> This changes semantic. Before this patch "git show v1.0.0" showed
> _commit_, not a tag. Well, you can get commit using "git show
> v1.0.0^{}"...
As Santi pointed out, this also shows the commit. Not only the tag.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-show: grok blobs, trees and tags, too
From: Johannes Schindelin @ 2006-12-15 10:22 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, junkio
In-Reply-To: <8aa486160612150118y44744533t16af6d3086ac6b21@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1081 bytes --]
Hi,
On Fri, 15 Dec 2006, Santi Béjar wrote:
> On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Since git-show is pure Porcelain, it is the ideal candidate to
> > pretty print other things than commits, too.
>
> I think "git show ${tag}" should be more like "git show ${commit}",
> that is, with the tagger and date information and the indent, as:
>
> $ git show v1.4.4.2
> tag v1.4.4.2
> Tagger: Junio C Hamano <junkio@cox.net>
> Date: ${Date}
>
> GIT 1.4.4.2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQBFdx8+wMbZpPMRm5oRAsOXAJsGY8DIYey1TZlEXIGq5+8MNgEl1QCfQC0f
> c5SmdLmAm2KPsCf+bCuoK+k=
> =oDuA
> -----END PGP SIGNATURE-----
> commit 49ed2bc4660c7cd0592cf21cc514080574d06320
> ...
Okay. You code it?
> > +EXAMPLES
> > +--------
> > +
> > +git show v1.0.0::
> > + Shows the tag `v1.0.0`.
>
> and the commit (or object) it references.
>
> I would add:
>
> git show v1.0.0^{}::
> Shows only the commit referenced by the tag `v1.0.0`.
Okay. You provide a patch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Jakub Narebski @ 2006-12-15 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612141710400.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:
>
>> Wouldn't it be better to mention the id of the local repository too?
>>
>> Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into
>> 'master' of 'hanwen@xs4all.nl'
>>
>> this would give more information when these commit messages get pushed
>> to someone else.
>
> And why not put your address and birthday in there, too?
>
> Frankly, it does not matter. In my private git repository I see that I
> often merged from this machine to that machine, criss-crossing often. It
> does not buy me anything to even know _where_ I got it from.
>
> Besides, the information you are most likely looking for is the committer,
> which is recorded anyway.
>
> The single most useful information in the Merge message is the name of the
> branch I merged, since it is more often than not a topic branch, which is
> aptly named.
By the way, I run git with merge.summary=true, and it is very nice and
usually shows the correct thing... but because git doesn't mark branching
points in any way sometimes under feature branch header there are changes
not related to given topic, but which were on given branch; the
fast-forward case I think.
That said, I'm all for not having "master" branch special-cased, besides
having it default name for branch in git-init-db.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Jakub Narebski @ 2006-12-15 10:35 UTC (permalink / raw)
To: git
In-Reply-To: <20061214215725.GA26202@spearce.org>
Shawn Pearce wrote:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> On Thursday 2006, December 14 21:30, Junio C Hamano wrote:
>>
>> > I guess that question indicates that the part of my message you
>> > did not quote was not written cleanly enough.
>>
>> It was; I'm just stupid.
>>
>> Let's make the special case "linux-master" and then Linus gets what he wants
>> and consistency is restored.
>>
>> No? Okay, I give up then. :-)
>
> What about we do instead:
>
> [branch]
> mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)' into '%(localref)'
> %(summary)"
> [branch "master"]
> mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)'
> %(summary)"
I disagree about '%(summary)' part, as it is controlled by merge.summary
configuration variable. If you want per branch configuration, why not
branch.<branchname>.mergesummary?
By the way, the above ignores the fact, that besides having hardcoded
that we don't say "into master", we have _two_ merge subject templates:
one for merging from remote, one for merging from local. We might not
have %(remoteurl), then what?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 10:53 UTC (permalink / raw)
To: git
In-Reply-To: <200612142352.kBENq8Ie002603@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
>> Perhaps under "[user] expert" control.
>
> Nope. You'd be surprised what kind of people consider themselves
> "experts"... I'd prefer adding -v/--verbose flags to all commands (if
> nothing else, for symmetry's sake), have a '[default] --verbose' controlling
> this across the board (perhaps also '[default "command"] --verbose'), with
> '[default]' setting default switches.
Nice idea... but configuration variables have to have name.
So it would be
$ git repo-config defaults.command --verbose
resulting in
[defaults]
command = --verbose
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Jakub Narebski @ 2006-12-15 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <200612140908.36952.andyparkins@gmail.com>
Andy Parkins wrote:
> On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:
>
>> git cat-file -p $REV:$file
>>
>> not sure how much easier it gets than that. Load in the bash
>> completion from contrib/completion and you can even tab complete
>> the $file part.
>
> Yes. I was a little unfair on that one; I forgot about the REV:file syntax.
> However, it's still not simple for a new user; I think I'd say "draw" if
> the "-p" weren't a requirement.
$ git repo-config alias.less "-p cat-file -p"
$ git repo-config alias.cat "cat-file -p"
remedies that.
[...]
>> How is it unfriendly? What specifically would you change to make
>> it more friendly?
>
> $ git-ls-tree v1.0.0
> 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile
>
> I'm a newbie: what's that number at the front? What's a blob? What's that
> great big number - I've only seen commit hashes that look like that, and that
> isn't one. Definitely not friendly.
The number in front is octal mode of a file or directory. "blob"
is a file (or symbolic link), "tree" is a directory, all of this
can be found in git(7).
The "great big number" is blob hash. All objects are identified
and referenced by SHA-1 hash of its contents: be it commits, blobs
(contents of a file), trees (content of a directory), tags.
You can always use --abbrev option to have it shortened.
> $ svn list -r 14
> Makefile
>
> It could probably be fixed by making git-ls-files capable of understanding
> tree-ish.
Perhaps we should add git-ls which would be porcelain frontend
to git-ls-files and git-ls-tree, just like git-diff is frontend
to git-diff-files, git-diff-index and git-diff-tree (and also does
pure blob diff).
"svn list -r 14" equivalent is "git ls-tree --name-only v1.0.0".
You can always do
$ git repo-config alias.list "ls-tree --name-only"
(or use --name-status instead of --name-only).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Jakub Narebski @ 2006-12-15 11:35 UTC (permalink / raw)
To: git
In-Reply-To: <m2slfilbfi.fsf@ziti.local>
Seth Falcon wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
>> Andy Parkins <andyparkins@gmail.com> wrote:
>>> svn cat::
>>> Output the contents of specified files or URLs. Optionally at a
>>> specific revision.
>>> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
>>
>> better:
>>
>> git cat-file -p $REV:$file
>
> FWIW, after some amount of git experience, I had a need for git
> cat-file and I found it hard to use. Why? Because following the
> pattern of some other commands, I really expected the following to work:
>
> git cat-file -p HEAD^2 $file
>
> Since that is similar to
>
> git diff HEAD^^ $file
> git checkout HEAD $file
You mean
git diff HEAD^^ -- $file
git checkout HEAD -- $file
It's not $file, it is $path, and it is limiter. git-cat-file (the name
is certainly historical artefact and it should be git-cat-object) doesn't
support limiters.
> Where else uses the colon syntax?
Everything where you have <object> or <tree-ish> you can use colon
syntax. For example:
$ git ls-tree pu:Documentation
$ git grep -e --merge next:Documentation
$ git diff v1.4.2:gitweb/gitweb.cgi gitweb/web:gitweb/gitweb.perl
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Jerome Lovy @ 2006-12-15 11:38 UTC (permalink / raw)
To: git
Hi,
While I am very happy with the refactorings undertaken with regard to
"git add/git commit" (both for UI and documentation), I am still a
little confused by the different ways I seem to find to express the idea
"I want to add (sort of) all file contents".
To be more specific, I find the following in the current documentation:
git add <dir>
"adds content from all files under <dir> directory and its
subdirectories."
(as interpreted from the "EXAMPLES" section of the git-add
man-page)
(BTW, could this <dir> usage be documented in the SYNOPSIS and
DESCRIPTION sections (admittedly at a 2nd rank after the
currently documented usage) as well as in the EXAMPLES ?
Besides this reference sections would probably include the
<dir>/<regexp> usage that I've not mentioned here for the sake
of simplicity.)
Moreover, the tutorial documents the typical usage "git add ."
git commit -a|--all
"automatically stage files that have been modified and deleted,
but new files you have not told git about are not affected."
Granted, the latter semantics for "all" is not exactly the same as the
former. Nonetheless, I think it would be very nice to only have to
memorize one way to express "all".
To this end, I would be very happy with the following:
(X-mas is coming soon, isn't it ;-) )
git add <dir>
same semantics
git commit -a|--add <files>
"adds content from the specified files before committing
(files that are already tracked have their current content
staged)"
git commit -a|--add <dir>
"adds content from all files under <dir> directory and its
subdirectories before committing"
(once again, for simplification of my explanations, I omit the
<dir>/<regexp> usage here)
git commit -u|--update <dir>
"automatically stage files that have been modified and deleted
under <dir> directory and its subdirectories, but new files you
have not told git about are not affected."
(once again, for simplification of my explanations, I omit the
<dir>/<regexp> usage here)
(This would allow the typical usage "git commit -u ." which is
barely longer than the current "git commit -a")
For interface completeness, "git commit -u|--update <files>" could also
exist but would probably be of no use.
To sum up, "all" would be consistently expressed with the <dir> syntax.
"git commit -a" would not mean "--all" anymore. Lastly, a distinction
would be made between "--add" and "--update":
- "git commit -add" would have the same semantics as "git add"
- "git commit --update" on the other hand would only affect the files
already tracked
Thank you for your patient attention.
Jérôme Lovy
^ permalink raw reply
* Re: [PATCH] Add --add option to git-repo-config
From: Brian Gernhardt @ 2006-12-15 11:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eltno8$vos$1@sea.gmane.org>
On Dec 15, 2006, at 3:54 AM, Jakub Narebski wrote:
> Brian Gernhardt wrote:
>
>> 'git-repo-config' [--global] [type] name [value [value_regex]]
>> +'git-repo-config' [--global] [type] --add name value
>
> In few places it seems that original has one space at beginning of
> line,
> and added value lacks this space.
>
> Otherwise, very nice patch. Thanks!
None of the originals have spaces at the beginning of the lines in my
repo. I think that's an artifact of Mail.app mangling whitespace at
the beginning of the line when copy/pasting patches. I thought it
only happened in a couple places and tried to fix it by hand.
Apparently that didn't work, and I need to install mutt or something
to send things from the command line. In the meantime, I can re-send
the patch as an attachment, if that'll help.
^ permalink raw reply
* Re: svn versus git
From: Andy Parkins @ 2006-12-15 12:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <elu0n5$u0i$1@sea.gmane.org>
On Friday 2006 December 15 11:27, Jakub Narebski wrote:
> > $ git-ls-tree v1.0.0
> > 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile
> >
> > I'm a newbie: what's that number at the front? What's a blob? What's
> > that great big number - I've only seen commit hashes that look like that,
> > and that isn't one. Definitely not friendly.
>
> The number in front is octal mode of a file or directory. "blob"
> is a file (or symbolic link), "tree" is a directory, all of this
> can be found in git(7).
Sorry, when I said "I'm a newbie", I meant "pretend I'm a newbie" :-)
My point was that this is all too confusing for a newbie; the fact that you
had to descend to talk about SHA-1 and blob hashes, really serves to
strengthen my point. What does a non-developer care about hashes, blobs,
trees, commits, or objects?
In this case however, I withdrew my complaint because it's argued that
git-ls-files is not the right tool for this purpose anyway.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Andreas Ericsson @ 2006-12-15 12:09 UTC (permalink / raw)
To: t2a2e9z8ncbs9qg; +Cc: git
In-Reply-To: <elu1cn$k3$1@sea.gmane.org>
Jerome Lovy wrote:
> Hi,
>
> While I am very happy with the refactorings undertaken with regard to
> "git add/git commit" (both for UI and documentation), I am still a
> little confused by the different ways I seem to find to express the idea
> "I want to add (sort of) all file contents".
>
> To be more specific, I find the following in the current documentation:
>
> git add <dir>
> "adds content from all files under <dir> directory and its
> subdirectories."
> (as interpreted from the "EXAMPLES" section of the git-add
> man-page)
> (BTW, could this <dir> usage be documented in the SYNOPSIS and
> DESCRIPTION sections (admittedly at a 2nd rank after the
> currently documented usage) as well as in the EXAMPLES ?
> Besides this reference sections would probably include the
> <dir>/<regexp> usage that I've not mentioned here for the sake
> of simplicity.)
>
> Moreover, the tutorial documents the typical usage "git add ."
>
> git commit -a|--all
> "automatically stage files that have been modified and deleted,
> but new files you have not told git about are not affected."
>
> Granted, the latter semantics for "all" is not exactly the same as the
> former. Nonetheless, I think it would be very nice to only have to
> memorize one way to express "all".
>
But the former isn't "all"; It's a specific directory, although "."
happens to *look* like "all", you can run "git add ." in a subdirectory
inside the repository and it won't mean "all" anymore. Likewise, you can
say "git commit ." from a subdirectory and have it commit all changes to
all tracked files under that directory.
> To this end, I would be very happy with the following:
> (X-mas is coming soon, isn't it ;-) )
>
> git add <dir>
> same semantics
>
> git commit -a|--add <files>
> "adds content from the specified files before committing
> (files that are already tracked have their current content
> staged)"
>
> git commit -a|--add <dir>
> "adds content from all files under <dir> directory and its
> subdirectories before committing"
> (once again, for simplification of my explanations, I omit the
> <dir>/<regexp> usage here)
>
> git commit -u|--update <dir>
> "automatically stage files that have been modified and deleted
> under <dir> directory and its subdirectories, but new files you
> have not told git about are not affected."
> (once again, for simplification of my explanations, I omit the
> <dir>/<regexp> usage here)
>
But this isn't "commit" at all. It's "git add".
> (This would allow the typical usage "git commit -u ." which is
> barely longer than the current "git commit -a")
>
> For interface completeness, "git commit -u|--update <files>" could also
> exist but would probably be of no use.
>
> To sum up, "all" would be consistently expressed with the <dir> syntax.
> "git commit -a" would not mean "--all" anymore. Lastly, a distinction
> would be made between "--add" and "--update":
> - "git commit -add" would have the same semantics as "git add"
This is bollocks. git commit should commit things. We'll be in some
serious trouble if "git commit -a" stops working the way it has and
starts just adding things to index.
> - "git commit --update" on the other hand would only affect the files
> already tracked
>
I fail to see what you're after with the changes propsed in this mail.
Is there a use-case you've encountered where you wanted to do something
that wasn't possible, or easy enough, that made you post this?
Unless it's a very, very good reason I most urgently think we're better
off keeping the current "git commit -a" behaviour.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* [PATCH] Add --add option to git-repo-config
From: Brian Gernhardt @ 2006-12-15 12:39 UTC (permalink / raw)
To: git
For multivars, the "git-repo-config name value ^$" is useful but
nonintuitive and troublesome to do repeatedly (since the value is not
at the end of the command line). This commit simply adds an --add
option that adds a new value to a multivar. Particularly useful for
tracking a new branch on a remote:
git-repo-config --add remote.origin.fetch +next:origin/next
Includes documentation and test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
This is unchanged from my last patch, but not mangled by OS X's
clipboard or Mail.app.
Documentation/git-repo-config.txt | 14 +++++++++++++-
builtin-repo-config.c | 6 ++++--
t/t1300-repo-config.sh | 10 ++++++++++
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 5bede9a..b379ec5 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -10,6 +10,7 @@ SYNOPSIS
--------
[verse]
'git-repo-config' [--global] [type] name [value [value_regex]]
+'git-repo-config' [--global] [type] --add name value
'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
'git-repo-config' [--global] [type] --get name [value_regex]
'git-repo-config' [--global] [type] --get-all name [value_regex]
@@ -23,7 +24,8 @@ You can query/set/replace/unset options with this command. The name is
actually the section and the key separated by a dot, and the value will be
escaped.
-If you want to set/unset an option which can occur on multiple
+Multiple lines can be added to an option by using the '--add' option.
+If you want to update or unset an option which can occur on multiple
lines, a POSIX regexp `value_regex` needs to be given. Only the
existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
@@ -53,6 +55,10 @@ OPTIONS
Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally the value_regex).
+--add::
+ Adds a new line to the option without altering any existing
+ values. This is the same as providing '^$' as the value_regex.
+
--get::
Get the value for a given key (optionally filtered by a regex
matching the value). Returns error code 1 if the key was not
@@ -194,6 +200,12 @@ To actually match only values with an exclamation mark, you have to
% git repo-config section.key value '[!]'
------------
+To add a new proxy, without altering any of the existing ones, use
+
+------------
+% git repo-config core.gitproxy '"proxy" for example.com'
+------------
+
include::config.txt[]
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index 7b6e572..64fbdb7 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -3,7 +3,7 @@
#include <regex.h>
static const char git_config_set_usage[] =
-"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
+"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --list";
static char *key;
static regex_t *key_regexp;
@@ -190,7 +190,9 @@ int cmd_repo_config(int argc, const char **argv, const char *prefix)
use_key_regexp = 1;
do_all = 1;
return get_value(argv[2], argv[3]);
- } else if (!strcmp(argv[1], "--replace-all"))
+ } else if (!strcmp(argv[1], "--add"))
+ return git_config_set_multivar(argv[2], argv[3], "^$", 0);
+ else if (!strcmp(argv[1], "--replace-all"))
return git_config_set_multivar(argv[2], argv[3], NULL, 1);
else
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 0de2497..16cd642 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -265,6 +265,16 @@ EOF
test_expect_success '--get-regexp' \
'git-repo-config --get-regexp in > output && cmp output expect'
+git-repo-config --add nextsection.nonewline "wow4 for you"
+
+cat > expect << EOF
+wow2 for me
+wow4 for you
+EOF
+
+test_expect_success '--add' \
+ 'git-repo-config --get-all nextsection.nonewline > output && cmp output expect'
+
cat > .git/config << EOF
[novalue]
variable
--
1.4.4.1.GIT
^ permalink raw reply related
* [PATCH] Make git-diff documentation use [--] when it should.
From: Brian Gernhardt @ 2006-12-15 12:39 UTC (permalink / raw)
To: git
Two of the cases has "[--] [<path>...]" and two had "-- [<path>...]".
Not terribly consistent and potentially confusing. Also add "[--]" to
the synopsis so that it's obvious you can use it from the very
beginning.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Documentation/git-diff.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 127d68c..10fdf88 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -8,7 +8,7 @@ git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
--------
-'git-diff' [ --diff-options ] <tree-ish>{0,2} [<path>...]
+'git-diff' [ --diff-options ] <tree-ish>{0,2} [--] [<path>...]
DESCRIPTION
-----------
@@ -30,7 +30,7 @@ tree and the index file, or the index file and the working tree.
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
-'git-diff' [--options] <commit> -- [<path>...]::
+'git-diff' [--options] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
@@ -38,7 +38,7 @@ tree and the index file, or the index file and the working tree.
branch name to compare with the tip of a different
branch.
-'git-diff' [--options] <commit> <commit> -- [<path>...]::
+'git-diff' [--options] <commit> <commit> [--] [<path>...]::
This form is to view the changes between two <commit>,
for example, tips of two branches.
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: svn versus git
From: Jakub Narebski @ 2006-12-15 12:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612150009230.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Thu, 14 Dec 2006, Arkadiusz Miskiewicz wrote:
>
>> ps. I'm blind or there is no documentation about what utilities are
>> needed to get git fully working? (like sed, coreutils, grep, rcs package
>> (merge tool afaik needed)...).
>
> Open the file "INSTALL".
Which doesn't mention 'sed' for example.
I have checked only commands in POSIX shell script; this list does not
include tests in t/ directory, which uses multitude of other tools.
Git has built-in grep since at least v1.4.0, but 'grep' is used in
generate-cmdlist.sh, git-commit.sh, git-instaweb.sh, git-quiltimport.sh and
git-tag.sh.
'cut' is used only in git-instaweb.sh; other commands do without it.
'sort' is used in check-builtins.sh, generate-cmdlist.sh, git-ls-remote.sh,
git-tag.sh. Both tools are from coreutils package. And git uses other tools
from coreutils too: uniq, printf, tail,...
Git has built-in diff since at least v1.4.0, but diff is used in
git-merge-one-file.sh
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
From: Jakub Narebski @ 2006-12-15 14:10 UTC (permalink / raw)
To: git
In-Reply-To: <20061214230902.GA26506@spearce.org>
Shawn O. Pearce wrote:
> Back in the old days of Git when people messed around with their
> GIT_DIR environment variable more often it was nice to know whether
> or not git-init-db created a .git directory or used GIT_DIR.
>
> But now that we are making excuses in the documentation about why
> this message gets printed by git-init-db we should just remove it
> entirely. It doesn't really help the user to understand what just
> happened. It also breaks from our normal behavior of not printing
> anything if the command was successful.
>
> Suggested by Andy Parkins in his Git 'niggles' list
> (<200612132237.10051.andyparkins@gmail.com>).
Perhaps we should print something _if_ GIT_DIR is set, then?
> * Set up the default .git directory contents
> */
> git_dir = getenv(GIT_DIR_ENVIRONMENT);
> - if (!git_dir) {
> + if (!git_dir)
> git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
> - fprintf(stderr, "defaulting to local storage area\n");
> - }
> safe_create_dir(git_dir, 0);
>
I'd rather leave block, even if it consist now of single statement.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Provide more meaningful output from 'git init-db'.
From: Jakub Narebski @ 2006-12-15 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <20061215054458.GA27750@spearce.org>
Shawn O. Pearce wrote:
> So now we print out what we did ("Initialized empty" or
> "Reinitialized existing"), what type of repository ("" or "shared"),
> and what location the repository will be in ("$GIT_DIR").
> ----------------
> -defaulting to local storage area
> +Initialized empty Git repository in .git/
> ----------------
> + printf("%s%s Git repository in %s/\n",
> + reinit ? "Reinitialized existing" : "Initialized empty",
> + shared_repository ? " shared" : "",
> + git_dir);
It seems like this lack this " in " part you have mentioned in
commit message and in tutorial.
+1. Very nice. Making git more newbie-friendly.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Jakub Narebski @ 2006-12-15 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <87slfh4xkm.wl%cworth@cworth.org>
Carl Worth wrote:
> On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote:
>> * gitweb made it appear as though a whole lot of Carl's recent
>> work was somehow undone in the merge.
>
> That looks like a simple gitweb bug. None of the other tools, (gitk,
> git log -p), consider a trivial merge commit like this as having
> anything interesting in it worth displaying.
It's not a bug, it is rather lack of feature (or misfeature).
Gitweb deals with multiparent commits (merge commits) that it uses
_first_ parent. No special casing merges (like git-show doesn't
show whatchanged/patch for merges), no support for -c/--cc diff
(combined diff format).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-15 14:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612141205490.18171@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
>
>> But I'm not sure that git-add should output anything. Last I checked
>> the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
>> files into a directory. Likewise I don't think that knowing that
>> 6781 files were added is useful, what if it should have really been
>> 6782 files? I'm unlikely to know, care, or realize it.
>
> git-add -v does output added files already.
Ha! Now only get it to accept --verbose as long alternative to -v option,
and add -v/--verbose option to other similar commands (git-mv for example).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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