* Re: [Census] So who uses git?
From: Chuck Lever @ 2006-02-06 21:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ray Lehtiniemi, Alex Riesen, Radoslaw Szkodzinski, Keith Packard,
Junio C Hamano, cworth, Martin Langhoff, Git Mailing List,
Trond Myklebust
In-Reply-To: <Pine.LNX.4.64.0601311747360.7301@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
Linus Torvalds wrote:
>>for comparison, one of our sandboxes is sitting on an NTFS file system,
>>accessed via SMB:
>>
>> smbfs$ time git update-index --refresh
>> real 11m36.502s
>> user 0m6.830s
>> sys 0m5.086s
>
>
> Ouch, ouch, ouch.
>
> Sounds like every single stat() will go out the wire. I forget what the
> Linux NFS client does, but I _think_ it has a metadata timeout that avoids
> this. But it might be as bad under NFS.
>
> Has anybody used git over NFS? If it's this bad (or even close to), I
> guess the "mark files as up-to-date in the index" approach is a really
> good idea..
>
> Of course, the whole point of git is that you should keep your repository
> close, but sometimes NFS - or similar - is enforced upon you by other
> issues, like the fact that the powers-that-be want anonymous workstations
> and everybody should work with a home-directory automounted over NFS..
yes, i keep my Linux kernel repository in NFS (and my stgit and git
repositories too).
there are some things that are slow precisely because my think time is
longer than the NFS client's attribute timeout, which means that all of
git's lstat()s turn into GETATTRs.
using the "noatime,nodiratime,actimeo=7200" mount options can have some
benefit. however, i found that keeping the repository packed provides
the greatest positive impact. that means that most of the objects are
in a single file, and can be validated with just one GETATTR.
one thing we might conclude from this is that making "packing" an
efficient operation (or even an incremental one) would go a long way to
helping performance on network file systems.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: Push or merge certain commitid
From: Bertrand Jacquin (Beber) @ 2006-02-06 21:09 UTC (permalink / raw)
To: pasky; +Cc: git
In-Reply-To: <4fb292fa0602061307q370443fdlf1f5e2ff575150f7@mail.gmail.com>
On Mon, Feb 06, 2006 at 10:07:18PM +0100, Bertrand Jacquin wrote:
> Hello,
>
> your email address is broken. I'm replying just to the mailing list.
Sorry, my mutt is quiet dead, and didn't send old mails :/
>
> Dear diary, on Mon, Feb 06, 2006 at 09:49:35PM CET, I got a letter
> where "Bertrand Jacquin (Beber)" <beber@guybrush.melee> said that...
> > I don't know if it's really possible to do but I would like to know if
> > there is a way to push or merge just certain commitid specified ?
> > I think it can trouble parents, trees, etc, but here I need that.
>
> As I already said on IRC, you can merge a specified commit by using
> the git-cherry-pick(1) command.
Yes, I read it, and wrote mail befode, sorry for noise
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Of the 3 great composers Mozart tells us what it's like to be human,
> Beethoven tells us what it's like to be Beethoven and Bach tells us
> what it's like to be the universe. -- Douglas Adams
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> Beber
> #e.fr@freenode
--
/* Beber : beber (AT) setibzh (DOT) com
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
^ permalink raw reply
* Re: Push or merge certain commitid
From: Petr Baudis @ 2006-02-06 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <20060206204935.GA20274@guybrush.melee>
Hello,
your email address is broken. I'm replying just to the mailing list.
Dear diary, on Mon, Feb 06, 2006 at 09:49:35PM CET, I got a letter
where "Bertrand Jacquin (Beber)" <beber@guybrush.melee> said that...
> I don't know if it's really possible to do but I would like to know if
> there is a way to push or merge just certain commitid specified ?
> I think it can trouble parents, trees, etc, but here I need that.
As I already said on IRC, you can merge a specified commit by using
the git-cherry-pick(1) command.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* git-http-push and hooks
From: Bertrand Jacquin (Beber) @ 2006-02-06 20:52 UTC (permalink / raw)
To: git
Hi,
Just a silly question :
Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
Also if i push with cg-push on the same repo but with git+ssh
protocol, hooks are execute.
Thanks
--
/* Beber : beber (AT) setibzh (DOT) com
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
^ permalink raw reply
* Push or merge certain commitid
From: Bertrand Jacquin (Beber) @ 2006-02-06 20:49 UTC (permalink / raw)
To: git
Hi,
I don't know if it's really possible to do but I would like to know if
there is a way to push or merge just certain commitid specified ?
I think it can trouble parents, trees, etc, but here I need that.
Thanks
--
/* Beber : beber (AT) setibzh (DOT) com
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
^ permalink raw reply
* Re: What's new in git.git
From: Johannes Schindelin @ 2006-02-06 17:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602060754470.3854@g5.osdl.org>
Hi,
On Mon, 6 Feb 2006, Linus Torvalds wrote:
> Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..
I have. When I tried to pickaxe some ugly bug across several merges. I
guess "--cc" is more effective anyway, so I wouldn't mind to let "-m" go.
Ciao,
Dscho
^ permalink raw reply
* Re: What's new in git.git
From: Junio C Hamano @ 2006-02-06 16:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602060754470.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 5 Feb 2006, Junio C Hamano wrote:
>>
>> * Add -c and --cc to diff-tree and diff-files. They give the
>> "combined diff" output that shows merges more human readably.
>
> Btw, the only concern I have left about "-c" and "--cc" is that I don't
> think the old merge-diff behaviour makes any sense at all, and that we
> should drop it entirely in favour of "-c" and "--cc".
> ...
> Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..
One thing that makes me a bit reluctant is that I am not as
confident as you are about -c doing the right thing. I have not
examined differences between -m -p and -c, especially under
various combinations of other flags like -B, -C and -M. I did
compare output from -c and --cc to check if the logic to drop
"uninteresting" hunks are doing the right thing and I am
reasonably sure that part is good, though.
The code to do -c punts at showing type changes, and there is no
filemode information in the output either. So far nobody has
complained about it, and a type change would be a rare thing
anyway and might not matter in practice. We should however not
just silently ignore rare cases that we do not handle. Instead
we should raise a big red flag; otherwise the rare cases in
which -c cheats can go unnoticed, which feels wrong.
Having said that, the above concern is primarily about debugging
the -c implementation and for that we could always fall back on
running "diff-tree -p H H^2" by hand, so maybe dropping "-m -p"
is an OK thing to do from that point of view.
People who are doing SCM migration part might be using it as a
replacement for "for i; do diff-tree -p H H^$i; done" to extract
diffs from each parent with a single command, though...
^ permalink raw reply
* Re: What's new in git.git
From: Linus Torvalds @ 2006-02-06 16:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vbqxkapr2.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Feb 2006, Junio C Hamano wrote:
>
> * Add -c and --cc to diff-tree and diff-files. They give the
> "combined diff" output that shows merges more human readably.
Btw, the only concern I have left about "-c" and "--cc" is that I don't
think the old merge-diff behaviour makes any sense at all, and that we
should drop it entirely in favour of "-c" and "--cc".
The old merge-diff code was so useless that nobody ever used it. It was
disabled by default (you had to enable it specially with the "-m" flag),
and I don't think anybody really ever did. The output was just not usable.
The only reason it existed at all was really because I _didn't_ do it
right, and I wanted some output.
So I would actually much prefer that "-c" would be the default, and that
"-p" would imply "--cc". With some other option to have the "long format"
diff.
Has anybody on the git list ever used "-m" with git-diff-tree? Speak up..
Linus
^ permalink raw reply
* What's new in git.git
From: Junio C Hamano @ 2006-02-06 7:52 UTC (permalink / raw)
To: git
I was planning to do a 1.2.0 this weekend, but things slipped.
But in a good way. We've had quite a long but good discussion
on how people expect "git commit paths..." to behave, and along
the way the command learned a couple of new tricks.
In 1.2.0, there will be three major changes that might surprise
people who are still using 1.1.0 based releases (e.g. 1.1.6).
People who followed the list traffic and/or the master branch
are familiar with them already:
* Checkout -m option. This allows you to switch branches when
you have local changes to paths that are different in the
current branch and new branch.
* Add -c and --cc to diff-tree and diff-files. They give the
"combined diff" output that shows merges more human readably.
* git-commit updates.
- Allow git-commit from a subdirecotry.
- Aborted "git-commit -a" leaves the index as it was.
- "git commit --only paths..." checks in changes to only
named paths. We may later make this default for "git
commit" with explicit paths.
- Add --author='A U Thor <author@example.com>' command
line option.
These are still in "pu" but I am expecting all of them would
graduate to "master" before 1.2.0:
- git-show (Linus)
- git-daemon updates (Mark Wooding)
- git-http-fetch various fixes (Mark Wooding)
- git-commit updates
- git-read-tree --aggressive to speed up resolve merger
- git-fmt-merge-msg to optionally put shortlog in merge commit log
- fix git-rev-list --parents | git-diff-tree --stdin
- git-rerere
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-06 7:31 UTC (permalink / raw)
To: Michael Fischer; +Cc: git
In-Reply-To: <20060206022553.GB25603@blinkenlights.visv.net>
Michael Fischer <michael@visv.net> writes:
> On Sun, Feb 05, Junio C Hamano wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> > To keep yourself up to date:
>> >
>> > $ git clone git://git.kernel.org/pub/scm/git master.git
>>
>> Silly me. This URL is wrong.
>>
>> $ git clone git://git.kernel.org/pub/scm/git/git master.git
>
> Thanks. Instructions followed, patch tried:
>
> From within a subdirectory:
>
> $ git commit -m"fix the bounce file" bounce.html
> assuming --include paths...
> $
>
> Both my nits are solved. Happy. Thanks.
Thanks for the feedback.
^ permalink raw reply
* Re: Fix git-rev-parse over-eager errors
From: Junio C Hamano @ 2006-02-06 6:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602051355430.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, I think the exact same holds true for the "show_file()" case.
>
> You had added a special-case for a similar problem (the "lstat()" check)
> to disable the check when the path wasn't actually printed out. Strictly
> speaking, I think that should be handled the same way wrt "verify" too.
>
> Ie something like this.
>
> Comments?
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Michael Fischer @ 2006-02-06 2:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vzml5b7az.fsf@assigned-by-dhcp.cox.net>
On Sun, Feb 05, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > To keep yourself up to date:
> >
> > $ git clone git://git.kernel.org/pub/scm/git master.git
>
> Silly me. This URL is wrong.
>
> $ git clone git://git.kernel.org/pub/scm/git/git master.git
Thanks. Instructions followed, patch tried:
>From within a subdirectory:
$ git commit -m"fix the bounce file" bounce.html
assuming --include paths...
$
Both my nits are solved. Happy. Thanks.
Michael
--
Michael Fischer Happiness is a config option.
michael@visv.net Recompile and be happy.
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-06 1:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtg9cq0k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> To keep yourself up to date:
>
> $ git clone git://git.kernel.org/pub/scm/git master.git
Silly me. This URL is wrong.
$ git clone git://git.kernel.org/pub/scm/git/git master.git
^ permalink raw reply
* [PATCH] git-send-email: Fully implement --quiet and document it.
From: Ryan Anderson @ 2006-02-06 1:13 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Ryan Anderson
Also reorganizes the man page to list options alphabetically.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-send-email.txt | 44 +++++++++++++++++++++-----------------
git-send-email.perl | 19 +++++++++++-----
2 files changed, 37 insertions(+), 26 deletions(-)
3b91b8b4e04e5cf42b7e5bd22b1bdda9c50ed781
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index b9bec55..00537d8 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,25 +24,23 @@ OPTIONS
-------
The options available are:
---to::
- Specify the primary recipient of the emails generated.
- Generally, this will be the upstream maintainer of the
- project involved.
+--chain-reply-to, --no-chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series.
+ Default is --chain-reply-to
+
+--compose::
+ Use $EDITOR to edit an introductory message for the
+ patch series.
--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
The user will still be prompted to confirm this entry.
---compose::
- Use \$EDITOR to edit an introductory message for the
- patch series.
-
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
-
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -50,18 +48,24 @@ The options available are:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---chain-reply-to, --no-chain-reply-to::
- If this is set, each email will be sent as a reply to the previous
- email sent. If disabled with "--no-chain-reply-to", all emails after
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series.
- Default is --chain-reply-to
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
--smtp-server::
If set, specifies the outgoing SMTP server to use. Defaults to
localhost.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
+
+--to::
+ Specify the primary recipient of the emails generated.
+ Generally, this will be the upstream maintainer of the
+ project involved.
+
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index 2977b9a..3f1b3ca 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -186,7 +186,9 @@ for my $f (@ARGV) {
}
if (@files) {
- print $_,"\n" for @files;
+ unless ($quiet) {
+ print $_,"\n" for (@files);
+ }
} else {
print <<EOT;
git-send-email [options] <file | directory> [... file | directory ]
@@ -213,6 +215,10 @@ Options:
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
+ --quiet Make git-send-email less verbose. One line per email should be
+ all that is output.
+
+
Error: Please specify a file or a directory on the command line.
EOT
exit(1);
@@ -268,7 +274,9 @@ sub send_message
sendmail(%mail) or die $Mail::Sendmail::error;
- unless ($quiet) {
+ if ($quiet) {
+ printf "Sent %s\n", $subject;
+ } else {
print "OK. Log says:\n", $Mail::Sendmail::log;
print "\n\n"
}
@@ -280,7 +288,6 @@ make_message_id();
$subject = $initial_subject;
foreach my $t (@files) {
- my $F = $t;
open(F,"<",$t) or die "can't open file $t";
@cc = ();
@@ -298,7 +305,7 @@ foreach my $t (@files) {
} elsif (/^(Cc|From):\s+(.*)$/) {
printf("(mbox) Adding cc: %s from line '%s'\n",
- $2, $_);
+ $2, $_) unless $quiet;
push @cc, $2;
}
@@ -310,7 +317,7 @@ foreach my $t (@files) {
# So let's support that, too.
if (@cc == 0) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
- $_, $_);
+ $_, $_) unless $quiet;
push @cc, $_;
@@ -330,7 +337,7 @@ foreach my $t (@files) {
chomp $c;
push @cc, $c;
printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_);
+ $c, $_) unless $quiet;
}
}
}
--
1.1.6.ga5ec-dirty
^ permalink raw reply related
* Re: [PATCH] do not open editor in dumb terminal
From: Junio C Hamano @ 2006-02-06 0:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Amos Waterland, junkio, git, boutcher
In-Reply-To: <20060205174422.GG31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Cogito solves this by [ -t ] and just doing cat instead of $EDITOR if
> the input is not a terminal. Couldn't Junio just do
>
> emacsclient | cg^H^Hgit commit
>
> in that case? (Note that I'm totally clueless about what emacsclient's
> usage actually is.)
It works just like other editors you can sanely use as EDITOR or
VISUAL. Takes list of files to edit on the command line, lets
the user interact with it and modify the files, writes out the
results to the files and exits.
So you could have suggested something like this:
$ ( $EDITOR tmpfile && cat tmpfile ) | cg commit
I think "git commit -F -" reads from stdin so an equilvalent can
be done with "git commit", but I suspect a sane user would
rather do this instead if he uses a temporary file:
$ $EDITOR tmpfile
$ git commit -F tmpfile
^ permalink raw reply
* Re: Add a "git show" command to show a commit
From: Junio C Hamano @ 2006-02-06 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0602051458460.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 5 Feb 2006, Linus Torvalds wrote:
>>
>> You're right. The "--cc" should be in the default flags (instead of -p),
>> not unconditionally on the command line.
>
> In that vein, for "git diff":
Yes, except that would break "git diff HEAD" ;-). Only
diff-tree and diff-files understands --cc. It means slightly
different thing for diff-files, but I do not think the
difference would matter (it shows unmerged case nicer).
I'll fix it up.
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-06 0:03 UTC (permalink / raw)
To: Michael Fischer; +Cc: git
In-Reply-To: <20060205225116.GC24561@blinkenlights.visv.net>
Michael Fischer <michael@visv.net> writes:
[Michael, forgive me to respond in public -- which I know is
against an established netiquette, but I think this comment is
useful to people on the list in general.]
> $ git-applymbox ../patch
> 1 patch(es) to process.
>
> Applying 'git-commit: revamp the git-commit semantics.'
>
> error: Documentation/core-tutorial.txt: does not exist in index
> error: patch failed: git-commit.sh:213
> error: git-commit.sh: patch does not apply
>
> So, kind of hard to give an opinion on it.
>
> I've got 1.1.6 from a couple of days ago, downloaded source.
Ah, sorry, the development happens on the "master" branch. The
maintenance release 1.1.6 has only fixes since 1.1.0 was done,
and lacks all the new developments on the master branch.
Especially this update involves backward incompatible changes,
it will _not_ appear in any of the future 1.1.X releases.
To keep yourself up to date:
$ git clone git://git.kernel.org/pub/scm/git master.git
$ cd master.git
This would give you the latest from the master branch that the
patch would apply cleanly to.
It is in the the pu (proposed updates) branch, so once you make
clone like this, you do not have to apply the patch yourself.
Instead, you could find the commit that merges jc/commit topic
branch on it:
$ git show-branch --topo-order master pu
which probably would show something like this:
...
- [pu^] Merge branch 'jc/commit'
+ [pu^^2] git-commit: revamp the git-commit semantics.
...
The easiest way to try it out is:
$ git checkout -b test pu^
Note: this would also get other topic branches merged on top of
master, but I consider them to be safe. The rule of thumb is
that the closer to the tip of the "pu", the less ready the
change is to be of general use.
Then build it as usual.
$ make && make install
Thanks.
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-05 23:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: git mailing list
In-Reply-To: <43E67745.2080302@gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Because when, at last, you will switch the default to
> '--only', this option could be removed. So it's a temporary
> option with, peraphs, a temporary documentation, and a
> temporary user training to use it: IMHO has a meaning if the
> transition period is long enough.
Hmph, actually I was planning to leave --only in forever if we
go that route. Peoples' scripts would need to explicitly ask
for --only during the transition if they want that semantics,
and removing that support afterwards would mean they would then
need to remove --only from their scripts again.
I was hoping that, once people get used to --include and --only,
they start to "revel in the index" (as Linus puts it), and
realize that defaulting to --only is not such a good idea after
all. When that happens, I could leave --include as the
default without getting complaints from them ;-).
The net effect, if we end up doing so, would be that we gained
an extra flag --only that the user can use to explicitly ask for
a partial commit when they want one, without disrupting the
established workflow of old timers.
The --only semantics is a useful thing in many situations, while
the --include semantics is also a useful thing in many other
cases. The latter might be a better match to the way the git
internal works, but both are equally useful options that support
different workflows. I do not see an inherent reason to declare
one over the other to be "the default". So we could instead
have no defaults at all (i.e. you have to explicitly say which
kind you want if you use paths...).
^ permalink raw reply
* Re: Add a "git show" command to show a commit
From: Linus Torvalds @ 2006-02-05 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602051451360.3854@g5.osdl.org>
On Sun, 5 Feb 2006, Linus Torvalds wrote:
>
> You're right. The "--cc" should be in the default flags (instead of -p),
> not unconditionally on the command line.
In that vein, for "git diff":
Linus
----
diff --git a/git-diff.sh b/git-diff.sh
index 4812ae4..7b3dbe3 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -22,13 +22,13 @@ case "$rev" in
esac
esac
-# If we do not have --name-status, --name-only nor -r, default to -p.
+# If we do not have --name-status, --name-only nor -r, default to --cc.
# If we do not have -B nor -C, default to -M.
case " $flags " in
*" '--name-status' "* | *" '--name-only' "* | *" '-r' "* )
;;
*)
- flags="$flags'-p' " ;;
+ flags="$flags'--cc' " ;;
esac
case " $flags " in
*" '-"[BCM]* | *" '--find-copies-harder' "*)
^ permalink raw reply related
* Re: Add a "git show" command to show a commit
From: Linus Torvalds @ 2006-02-05 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd5i1h1bx.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Feb 2006, Junio C Hamano wrote:
>
> Isn't this "git whatchanged -n1 --cc --always"?
Getting closer, yes.
Especially these days that you can write "-1" instead of "--max-count=1",
and if we make "--cc" the default for "git-whatchanged", I guess we could
just drop this.
> Except that --cc does not make much sense without being -p, so
> the logic to do --name-status and friends are pretty much
> wasted, no?
You're right. The "--cc" should be in the default flags (instead of -p),
not unconditionally on the command line.
Linus
^ permalink raw reply
* Re: Add a "git show" command to show a commit
From: Junio C Hamano @ 2006-02-05 22:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602051144580.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> It's basically just "git-diff-tree" with pretty flags and a pager.
Isn't this "git whatchanged -n1 --cc --always"?
> It tries to have the same logic as "git diff" for the flags.
Except that --cc does not make much sense without being -p, so
the logic to do --name-status and friends are pretty much
wasted, no?
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Marco Costalba @ 2006-02-05 22:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list
In-Reply-To: <7v64ntindq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano ha scritto:
> I was planning to think about the migration strategy _after_ I
> get the feeling that everybody who got confused by the current
> one thinks this is a good change, and I am glad you did that
> work for me ;-).
>
> I think it is sane to add a no-op '--include' to the current
> version.
>
> I am not sure if it is worth to take two-phased introduction of
> this new "temporary index" thing. We could:
>
> * add '--only' that asks for the new "temporary index" thing.
>
> * initially make '--include' the default, not '--only'.
>
> * later switch the default to '--only'.
>
>
I think both are viable choices, with the second one better in
case the planned transition phase is going to be long, while the
first one is better if it is going to be short.
Because when, at last, you will switch the default to '--only', this option could be
removed. So it's a temporary option with, peraphs, a temporary documentation, and
a temporary user training to use it: IMHO has a meaning if the transition period is
long enough.
If we are talking about just one or two weeks, more then enough to update scripts, I think
the first approach is simpler.
In any case to let things more clear could be useful to tag a fresh new git version
for this commit semantics change.
Marco
^ permalink raw reply
* Re: Fix git-rev-parse over-eager errors
From: Linus Torvalds @ 2006-02-05 22:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsm1h8ft.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Feb 2006, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > Using "--verify" together with "--no-flags" makes perfect sense, but
> > git-rev-parse would complain about it when it saw a flag, even though it
> > would never actually use/output that flag.
>
> Ah, makes sense.
Btw, I think the exact same holds true for the "show_file()" case.
You had added a special-case for a similar problem (the "lstat()" check)
to disable the check when the path wasn't actually printed out. Strictly
speaking, I think that should be handled the same way wrt "verify" too.
Ie something like this.
Comments?
Linus
---
diff --git a/rev-parse.c b/rev-parse.c
index d2f0864..124d3ee 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -143,11 +143,14 @@ static void show_datestring(const char *
show(buffer);
}
-static void show_file(const char *arg)
+static int show_file(const char *arg)
{
show_default();
- if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV))
+ if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV)) {
show(arg);
+ return 1;
+ }
+ return 0;
}
int main(int argc, char **argv)
@@ -308,14 +311,13 @@ int main(int argc, char **argv)
show_rev(REVERSED, sha1, arg+1);
continue;
}
+ as_is = 1;
+ if (!show_file(arg))
+ continue;
if (verify)
die("Needed a single revision");
- if ((filter & DO_REVS) &&
- (filter & DO_NONFLAGS) && /* !def && */
- lstat(arg, &st) < 0)
+ if (lstat(arg, &st) < 0)
die("'%s': %s", arg, strerror(errno));
- as_is = 1;
- show_file(arg);
}
show_default();
if (verify && revs_count != 1)
^ permalink raw reply related
* Re: Fix git-rev-parse over-eager errors
From: Junio C Hamano @ 2006-02-05 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602051155460.3854@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Using "--verify" together with "--no-flags" makes perfect sense, but
> git-rev-parse would complain about it when it saw a flag, even though it
> would never actually use/output that flag.
Ah, makes sense.
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-05 20:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550602050536j73f1091dq9afae232f574d0b4@mail.gmail.com>
I was planning to think about the migration strategy _after_ I
get the feeling that everybody who got confused by the current
one thinks this is a good change, and I am glad you did that
work for me ;-).
I think it is sane to add a no-op '--include' to the current
version.
I am not sure if it is worth to take two-phased introduction of
this new "temporary index" thing. We could:
* add '--only' that asks for the new "temporary index" thing.
* initially make '--include' the default, not '--only'.
* later switch the default to '--only'.
^ 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