* 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
* Fix git-rev-parse over-eager errors
From: Linus Torvalds @ 2006-02-05 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602051144580.3854@g5.osdl.org>
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.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is independent of the "git show" patches, although the problem was
triggered by the "git show" usage of git-rev-parse. It's a bug whether git
show is merged or not, though.
diff --git a/rev-parse.c b/rev-parse.c
index 6bf205a..9cec33b 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,12 +107,15 @@ static void show_rev(int type, const uns
}
/* Output a flag, only if filter allows it. */
-static void show_flag(char *arg)
+static int show_flag(char *arg)
{
if (!(filter & DO_FLAGS))
- return;
- if (filter & (is_rev_argument(arg) ? DO_REVS : DO_NOREV))
+ return 0;
+ if (filter & (is_rev_argument(arg) ? DO_REVS : DO_NOREV)) {
show(arg);
+ return 1;
+ }
+ return 0;
}
static void show_default(void)
@@ -296,9 +299,8 @@ int main(int argc, char **argv)
show_datestring("--min-age=", arg+8);
continue;
}
- if (verify)
+ if (show_flag(arg) && verify)
die("Needed a single revision");
- show_flag(arg);
continue;
}
^ permalink raw reply related
* Add a "git show" command to show a commit
From: Linus Torvalds @ 2006-02-05 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602051141020.3854@g5.osdl.org>
It's basically just "git-diff-tree" with pretty flags and a pager.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This uses the "--always" flag, btw, so it depends on the previous patch I
sent. If you disagree with that, just remove it.
This is actually something I do pretty often, and I've grown tired of
doing
git-diff-tree -p --pretty cmit-id | less -S
so this is really nothing but a fairly flexible replacement for that.
It tries to have the same logic as "git diff" for the flags.
diff --git a/Makefile b/Makefile
index 2aa2385..473e58d 100644
--- a/Makefile
+++ b/Makefile
@@ -112,7 +112,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh \
- git-lost-found.sh
+ git-lost-found.sh git-show.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-show.sh b/git-show.sh
new file mode 100644
index 0000000..476bca4
--- /dev/null
+++ b/git-show.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+rev=$(git-rev-parse --verify --revs-only --no-flags --sq --default HEAD "$@") || exit
+flags=$(git-rev-parse --no-revs --flags --sq "$@")
+files=$(git-rev-parse --no-revs --no-flags --sq "$@")
+
+# Match the behaviour of "git diff":
+# - if we do not have --name-status, --name-only nor -r, default to -p.
+# - if we do not have -B nor -C, default to -M.
+case " $flags " in
+*" '--name-status' "* | *" '--name-only' "* | *" '-r' "* )
+ ;;
+*)
+ flags="$flags'-p' " ;;
+esac
+case " $flags " in
+*" '-"[BCM]* | *" '--find-copies-harder' "*)
+ ;; # something like -M50.
+*)
+ flags="$flags'-M' " ;;
+esac
+
+eval "git-diff-tree --always --cc --pretty $flags $rev -- $files" | LESS=-S ${PAGER:-less}
^ permalink raw reply related
* Re: The merge from hell...
From: Linus Torvalds @ 2006-02-05 19:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Costalba, Git Mailing List, Paul Mackerras, Marco Costalba
In-Reply-To: <7v7j8erqjr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2 Feb 2006, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > Ahh. You're mis-using git-diff-tree.
> >
> > git-diff-tree will _never_ show the commit log if the diff ends up being
> > empty.
>
> True, I should fix the documentation.
>
> It _might_ make sense for certain users like gitk and gitview if
> we had a single tool that gives --pretty and its diff even if
> the diff is empty. Having said that, the flag --cc -m is too
> specific. If some uses want to see the commit log even for an
> empty diff, that flag should not be something only --cc honors.
Here's an "--always" flag that does that.
Linus
---
diff --git a/diff-tree.c b/diff-tree.c
index 6593a69..2df23c6 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -10,6 +10,7 @@ static int show_empty_combined = 0;
static int combine_merges = 0;
static int dense_combined_merges = 0;
static int read_stdin = 0;
+static int always_show_header = 0;
static const char *header = NULL;
static const char *header_prefix = "";
@@ -93,6 +94,10 @@ static const char *generate_header(const
offset += pretty_print_commit(commit_format, commit, len,
this_header + offset,
sizeof(this_header) - offset, abbrev);
+ if (always_show_header) {
+ puts(this_header);
+ return NULL;
+ }
return this_header;
}
@@ -262,6 +267,10 @@ int main(int argc, const char **argv)
no_commit_id = 1;
continue;
}
+ if (!strcmp(arg, "--always")) {
+ always_show_header = 1;
+ continue;
+ }
usage(diff_tree_usage);
}
if (diff_options.output_format == DIFF_FORMAT_PATCH)
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox