* Re: [PATCH] post-checkout hook, and related docs and tests
From: Junio C Hamano @ 2007-09-24 23:54 UTC (permalink / raw)
To: Josh England; +Cc: Junio C Hamano, git
In-Reply-To: <1190671558.6078.87.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
> On Mon, 2007-09-24 at 14:07 -0700, Junio C Hamano wrote:
> ...
>> If you want to spacial case
>>
>> $ git checkout otherbranch path.c
>>
>> it raises another issue. Which commit should supply the
>> "extended attribute description" for path.c? Should it be taken
>> from the current commit (aka HEAD), otherbranch, or the index?
>
> This already is a special case and your question is valid but not one
> that git should necessary care about. Since extended attributes are not
> built into git the only way to handle them is through hooks. A such, it
> is up to the hook to worry about these kinds of issues.
The fear I have is that that kind of thinking would necessitate
your hook to be called after the user edits paths.c in any other
way not to confuse users.
What I am questioning is where we should stop, in order to keep
things simpler to explain, and I happen to think that it is far
easier if we can teach that "git checkout other path.c" is
equivalent to "git cat-file blob other:path.c >path.c" followed
by "git add path.c", than saying "checkout is magical and if you
have external hook it can do far more than editing the file
yourself to arrive at the same contents".
But I am obviously not the one who is interested in tracking
extended attributes attached to git contents, and I do not feel
too strongly about one way or the other. I am Ok with it if you
think "checkout is magical" is easier to teach [*1*].
I just wanted to make sure we know what semantics this is
bringing in, and get it clearly documented. That's all.
[Footnote]
*1* I actually suspect this might be the case. I consider that
per-path checkout from a commit is just a fancy and handy way to
edit individual files but that probably comes from knowing how
git works too much and I lost my git virginity too long ago. A
pure "user" who types "git checkout commit path" may actively
expect "checkout" command to do something more magical than
simply updating the index and the work tree files to a random
state that happens to match the state recorded in one commit.
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Junio C Hamano @ 2007-09-24 23:31 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqbsta3g.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> I am somewhat taken aback that a commit message considered offensive
> (though I still have a problem understanding why and certainly did not
> intend this) has been committed into master without giving me a chance
> to amend it.
Heh, that's simple. I changed my mind ;-)
When A and B test for preconditions, and C, D, and E are
operations with error reports as their side effects, we can
write our loop in these forms:
(1) while A && B && C && D && E || false; do :; done
(2) while A && B && C && D && E || break; do :; done
(3) while A && B; do C && D && E || break; do :; done
(4) while :; do A && B && C && D && E || break; done
and all of them are equivalent.
But obviously the only sane version is (3).
If your complaint were against things like (1) and (2), I would
have completely agreed with you. If you want "effects", you do
so between do and done. Although you can use break between do
and done if you need to conditionally break out of the loop
after causing some effect there, between while and do is where
you are only supposed to decide if you want to break out of the
loop without causing "effects".
But what you were complaining about was different.
If we were to ignore broken shells that do not return success
from a case statement with no matching pattern, the following
two are equivalent:
while case "$sth" in foo) break ;; esac; do ...; done
while case "$sth" in foo) false ;; esac; do ...; done
Their "case" are used to decide if you want to break out of the
loop; the former is (1) being a bit more explicit, and (2) used
to be a bit more efficient when false was not built-in.
Now the latter reason is mostly historical and it is not a valid
reason to choose the former over the latter anymore. But that
does not make it any more confusing than the latter to a person
who knows what "break" means in a loop. An explicit 'break' is
still more, eh,... explicit ;-)
But the "break" never was the issue. Return value of "case"
was.
The reason I took your patch and proposed commit log message
(almost) as-is was because you rewrote "case" to "test". That
IS an improvement, especially in the presense of a shell in the
field that does not implement case statement correctly, and you
talk about that in the later part of the commit log message.
The only "offending" part was "I consider...ugly", which is your
opinion but I think you as the patch author deserve to express
that. I do not think it would not have helped the FreeBSD shell
a bit if you removed that "ugliness" by merely replacing "break"
with "false", so I think the comment was not just offending but
irrelevant, though.
All the rest of your commit message is correct. The spec of
"case" might not be obvious to everybody that it ought to return
success when no pattern matched. And I found your wording to
fold the bug decription of some BSD shells there amusing ;-)
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejgnai1z.fsf@gitster.siamese.dyndns.org>
On Mon, 2007-09-24 at 14:07 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > ... Granted, the
> > branch (and HEAD) does not change for this operation, but that shouldn't
> > matter. It is somewhat in line with the principle of 'least-surprise':
> > if the hook runs for 'git checkout otherbranch', but not 'git checkout
> > otherbranch path.c', this could cause confusion and distress to the
> > user. IMO, it is a 'checkout' so the post-checkout hook should run.
> > Why is that so insane?
>
> Because I find it would be surprising if the following commands
> behave differently:
>
> $ git cat-file blob otherbranch:path.c >path.c
> $ git show otherbranch:path.c >path.c
> $ git diff -R otherbranch path.c | git apply
> $ git checkout otherbranch path.c
For all intents and purposes, these would still behave the same. The
existence of a post-checkout hook does not at all affect the outcome of
the checkout. Sure there is potential for someone to do something
stupid inside the hook script, but that is true of any hook.
Most git users would never even enable the hook, but for those that do I
would assume that they'd want the hook to run for all 'git-checkout'
variants -- as I do.
> These are all talking about various ways to _edit_ working tree
> files, and not about switching between revisions.
>
> That's why I said I found that what the second sentence from
> your original description implied ("the hook gets old and new
> commit object name" which means we are talking about switching
> between revisions) was sensible, but it needs to be stressed a
> bit.
>
> If you want to spacial case
>
> $ git checkout otherbranch path.c
>
> it raises another issue. Which commit should supply the
> "extended attribute description" for path.c? Should it be taken
> from the current commit (aka HEAD), otherbranch, or the index?
This already is a special case and your question is valid but not one
that git should necessary care about. Since extended attributes are not
built into git the only way to handle them is through hooks. A such, it
is up to the hook to worry about these kinds of issues. The hook I have
written handles this by updating path.c attributes to match whatever
exists in the (tracked) attributes file of the current HEAD.
This 'git-checkout otherbranch path.c' is a corner case, but one that
can result in broken behavior when handling metadata unless the hook
runs. I just want to close all the holes. I can change the description
of the hook to try to dispel any confusion if that would help.
-JE
^ permalink raw reply
* Re: [PATCH] user-manual: Explain what submodules are good for.
From: J. Bruce Fields @ 2007-09-24 21:33 UTC (permalink / raw)
To: Michael Smith; +Cc: git, Miklos Vajna
In-Reply-To: <11906036491118-git-send-email-msmith@cbnco.com>
On Sun, Sep 23, 2007 at 11:14:09PM -0400, Michael Smith wrote:
> Rework the introduction to the Submodules section to explain why
> someone would use them, and fix up submodule references from the
> tree-object and todo sections.
Thanks!
> +Some large projects are composed of smaller, self-contained parts. For
> +example, an embedded Linux distribution's source tree would include every
> +piece of software in the distribution; a movie player might need to build
> +against a specific, known-working version of a decompression library;
> +several independent programs might all share the same build scripts.
...
> +Git's submodule support allows a repository to contain, as a subdirectory, a
> +checkout of an external project. Submodules maintain their own identity;
> +the submodule support just stores the submodule repository location and
> +commit ID, so other developers who clone the superproject can easily clone
> +all the submodules at the same revision. The gitlink:git-submodule[1]
> +command manages submodules.
That looks helpful, thanks, but a little more detail might be nice.
Imagining myself as a reader trying to decide whether to use submodules
in a given case, I'm not sure this would tell me everything I need to
know. For example, how does this compare to just importing a snapshot
of the library into your tree? (Or possibly using the subtree merge
strategy?)
Some issues that pop to mind are scalability (when does a monolithic
tree get too large to work with?) and backwards compatibility (what
version does everybody working on your project need to have for it to
work? What problems will you see if a few people are stuck with an
older git?) I haven't followed submodule development, though, so may
have missed more important issues.
--b.
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Junio C Hamano @ 2007-09-24 21:07 UTC (permalink / raw)
To: Josh England; +Cc: Junio C Hamano, git
In-Reply-To: <1190662396.6078.63.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
> ... Granted, the
> branch (and HEAD) does not change for this operation, but that shouldn't
> matter. It is somewhat in line with the principle of 'least-surprise':
> if the hook runs for 'git checkout otherbranch', but not 'git checkout
> otherbranch path.c', this could cause confusion and distress to the
> user. IMO, it is a 'checkout' so the post-checkout hook should run.
> Why is that so insane?
Because I find it would be surprising if the following commands
behave differently:
$ git cat-file blob otherbranch:path.c >path.c
$ git show otherbranch:path.c >path.c
$ git diff -R otherbranch path.c | git apply
$ git checkout otherbranch path.c
These are all talking about various ways to _edit_ working tree
files, and not about switching between revisions.
That's why I said I found that what the second sentence from
your original description implied ("the hook gets old and new
commit object name" which means we are talking about switching
between revisions) was sensible, but it needs to be stressed a
bit.
If you want to spacial case
$ git checkout otherbranch path.c
it raises another issue. Which commit should supply the
"extended attribute description" for path.c? Should it be taken
from the current commit (aka HEAD), otherbranch, or the index?
^ permalink raw reply
* [PATCH] Add ability to specify SMTP server port when using git-send-email.
From: Glenn Rempe @ 2007-09-24 20:34 UTC (permalink / raw)
To: git; +Cc: Glenn Rempe
Add ability to specify custom SMTP server port using
smtpserverport config value or --smtp-server-port command
line option.
Will default to port 25 if smtpssl config is set
to false or --smtp-ssl command line is unset.
Will default to port 465 if smtpssl config is set
to true or --smtp-ssl is set.
User can specify any arbitrary port number for standard or
SSL connections.
Users should be aware that sending auth info over non-ssl
connections may be unsafe.
Signed-off-by: Glenn Rempe <glenn@rempe.us>
---
git-send-email.perl | 48 +++++++++++++++++++++++++++++++++++++-----------
1 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4031e86..7c9c302 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -79,6 +79,10 @@ Options:
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
+ --smtp-server-port If set, specifies the port on the outgoing SMTP
+ server to use. Defaults to port 25 unless --smtp-ssl is set in
+ which case it will default to port 465.
+
--smtp-user The username for SMTP-AUTH.
--smtp-pass The password for SMTP-AUTH.
@@ -172,7 +176,7 @@ my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
-my ($smtp_server, $smtp_authuser, $smtp_authpass, $smtp_ssl);
+my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
my ($identity, $aliasfiletype, @alias_files);
my %config_bool_settings = (
@@ -185,6 +189,7 @@ my %config_bool_settings = (
my %config_settings = (
"smtpserver" => \$smtp_server,
+ "smtpserverport" => \$smtp_server_port,
"smtpuser" => \$smtp_authuser,
"smtppass" => \$smtp_authpass,
"cccmd" => \$cc_cmd,
@@ -204,6 +209,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"bcc=s" => \@bcclist,
"chain-reply-to!" => \$chain_reply_to,
"smtp-server=s" => \$smtp_server,
+ "smtp-server-port=s" => \$smtp_server_port,
"smtp-user=s" => \$smtp_authuser,
"smtp-pass=s" => \$smtp_authpass,
"smtp-ssl!" => \$smtp_ssl,
@@ -375,6 +381,14 @@ if (!defined $smtp_server) {
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
+if (!defined $smtp_server_port) {
+ if ($smtp_ssl) {
+ $smtp_server_port = 465 # SSL port
+ } else {
+ $smtp_server_port = 25 # Non-SSL port
+ }
+}
+
if ($compose) {
# Note that this does not need to be secure, but we will make a small
# effort to have it be unique
@@ -604,20 +618,32 @@ X-Mailer: git-send-email $gitversion
} else {
if ($smtp_ssl) {
require Net::SMTP::SSL;
- $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port => 465 );
+ $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port => $smtp_server_port );
}
else {
require Net::SMTP;
- $smtp ||= Net::SMTP->new( $smtp_server );
+ $smtp ||= Net::SMTP->new( $smtp_server . ":" . $smtp_server_port );
}
- $smtp->auth( $smtp_authuser, $smtp_authpass )
- or die $smtp->message if (defined $smtp_authuser);
- $smtp->mail( $raw_from ) or die $smtp->message;
- $smtp->to( @recipients ) or die $smtp->message;
- $smtp->data or die $smtp->message;
- $smtp->datasend("$header\n$message") or die $smtp->message;
- $smtp->dataend() or die $smtp->message;
- $smtp->ok or die "Failed to send $subject\n".$smtp->message;
+
+ # we'll get an ugly error if $smtp was undefined above.
+ # If so we'll catch it and present something friendlier.
+ if ($smtp) {
+
+ if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
+ $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ }
+
+ $smtp->mail( $raw_from ) or die $smtp->message;
+ $smtp->to( @recipients ) or die $smtp->message;
+ $smtp->data or die $smtp->message;
+ $smtp->datasend("$header\n$message") or die $smtp->message;
+ $smtp->dataend() or die $smtp->message;
+ $smtp->ok or die "Failed to send $subject\n".$smtp->message;
+
+ } else {
+ die "Unable to initialize SMTP properly. Is there something wrong with your config?";
+ }
+
}
if ($quiet) {
printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
--
1.5.3.2.83.gc6869
^ permalink raw reply related
* [PATCH] Fixed minor typo in t/t9001-send-email.sh test command line.
From: Glenn Rempe @ 2007-09-24 20:33 UTC (permalink / raw)
To: git; +Cc: Glenn Rempe
The git-send-email command line in the test was missing a single hyphen.
Signed-off-by: Glenn Rempe <glenn@rempe.us>
---
t/t9001-send-email.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index e9ea33c..83f9470 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -30,7 +30,7 @@ test_expect_success 'Extract patches' '
'
test_expect_success 'Send patches' '
- git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
+ git send-email --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
cat >expected <<\EOF
--
1.5.3.2.83.gc6869
^ permalink raw reply related
* Re: [PATCH 7/7] Implement git commit as a builtin command.
From: Kristian Høgsberg @ 2007-09-24 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsujizli.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 12:32 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> >> > +
> >> > + /* update the user index file */
> >> > + add_files_to_cache(fd, files, prefix);
> >> > +
> >> > + if (!initial_commit) {
> >> > + tree = parse_tree_indirect(head_sha1);
> >> > + if (!tree)
> >> > + die("failed to unpack HEAD tree object");
> >> > + if (read_tree(tree, 0, NULL))
> >> > + die("failed to read HEAD tree object");
> >> > + }
> >>
> >> Huh? Doesn't this read_tree() defeat the add_files_to_cache()
> >> you did earlier?
> >
> > This is the case where we add the files on the command line
> > to .git/index, but commit from a clean index file corresponding to HEAD
> > with the files from the command line added (partial commit?). The first
> > add_files_to_cache() updates .git/index, then we do read_tree() to build
> > a tmp index from HEAD and then we add the files again. The tmp index is
> > written to a tmp index file.
>
> Still, if you are doing read_tree() that reads into the same
> in-core cache you have just prepared in the add_fiels_to_cache()
> above, potentially overwriting whatever you did, doesn't it?
> That was what I was puzzled about...
Ah, I understand the confusion - add_files_to_cache() will write out the
cache to the given fd and close it. That's not clear, and I've moved
the write+close part back into prepare_index() in the follow-on patches
I sent that shares out add_files_to_cache() with builtin-add.c.
> > ... As for just using an in-memory
> > index, I wanted to do it that way originally, but you have to write it
> > to disk after all for the pre-commit hook.
>
> Ah, I completely forgot about the hook. Ok, scratch the idea of
> not using a temporary index file. The is not much potential for
> performance gain anyway.
Ok, cool, I'll keep the current structure of the code then.
Kristian
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl53ap5x.fsf@gitster.siamese.dyndns.org>
On Mon, 2007-09-24 at 11:34 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> >> What's the _semantics_ you are trying to achieve?
> >
> > I'd like to get a hook that runs whenever the working dir gets
> > updated. The 'git-checkout otherbranch path.c' case should
> > run it also, so I view that as a bug.
>
> I think that _is_ INSANE. Do you run the hook for these then?
>
> $ edit path.c
> $ git-cat-file otherbranch:path.c >path.c
>
> Why "git checkout otherbranch path.c" should be any different?
It is different because the file is being updated through the 'git
checkout' interface. The user is not copying the file over by hand,
he/she is asking git to do it for them via 'git checkout'. Granted, the
branch (and HEAD) does not change for this operation, but that shouldn't
matter. It is somewhat in line with the principle of 'least-surprise':
if the hook runs for 'git checkout otherbranch', but not 'git checkout
otherbranch path.c', this could cause confusion and distress to the
user. IMO, it is a 'checkout' so the post-checkout hook should run.
Why is that so insane?
Look at it from the perspective of the intended use of this hook. I'm
trying to use this hook to keep working dir metadata (ownership/perms)
in a consistent state. When I do a 'git checkout otherbranch', the hook
runs, updating perms as needed, and all is well. As is, if I 'git
checkout otherbranch path.c', the file is created with the default
umask, the hook is not run, and path.c potentially (likely) has
incorrect perms. The working dir is now in an inconsistent state and
the worst part is that the next commit will propagate the faulty
metadata for that file.
-JE
^ permalink raw reply
* Re: git-send-email is omitting author and date lines
From: Junio C Hamano @ 2007-09-24 18:43 UTC (permalink / raw)
To: martin f krafft; +Cc: Johannes Schindelin, Hanspeter Kunz, git
In-Reply-To: <20070924173014.GB27816@lapse.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.24.1210 +0100]:
>> And that is perfectly okay, since as far as the public is
>> concerned, this is the date of the patch.
>
> If you say so. I don't find this at all convincing.
I think that is the reasoning for the current behaviour of
send-email, but it is not unreasonable to have an option to
always add in-body From: and Date: headers to send-email, with a
blessing from a recent post from Linus to the kernel mailing
list:
http://article.gmane.org/gmane.linux.kernel/582450
Notice the part he says he appreciates Andrew's practice and
talks about message being further forwarded by somebody else.
^ permalink raw reply
* Re: [PATCH] Move option parsing code to parse-options.[ch].
From: Kristian Høgsberg @ 2007-09-24 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl57iz1t.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 12:44 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> > ---
> > Makefile | 2 +-
> > builtin-commit.c | 117 ++++++++----------------------------------------------
> > parse-options.c | 74 ++++++++++++++++++++++++++++++++++
> > parse-options.h | 29 +++++++++++++
> > 4 files changed, 121 insertions(+), 101 deletions(-)
> > create mode 100644 parse-options.c
> > create mode 100644 parse-options.h
>
> Hmmmmmmm. Is it too much to ask to pretend as if the previous
> "builtin-commit.c" that had these parts that did not belong to
> it in the first place never happened?
No problem, I wasn't sure whether to update the patches or to just send
follow-up patches now that it was in pu. I'll resend 7/7 as 3 new
patches that exports add_files_to_cache(), adds option parsing, and
finally builtin-commit.
Kristian
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Junio C Hamano @ 2007-09-24 18:34 UTC (permalink / raw)
To: Josh England; +Cc: git
In-Reply-To: <1190654052.6078.14.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
>> What's the _semantics_ you are trying to achieve?
>
> I'd like to get a hook that runs whenever the working dir gets
> updated. The 'git-checkout otherbranch path.c' case should
> run it also, so I view that as a bug.
I think that _is_ INSANE. Do you run the hook for these then?
$ edit path.c
$ git-cat-file otherbranch:path.c >path.c
Why "git checkout otherbranch path.c" should be any different?
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: Junio C Hamano @ 2007-09-24 18:31 UTC (permalink / raw)
To: David Tweed; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <e1dab3980709241009q71f9a40r1f8b551b417f7475@mail.gmail.com>
"David Tweed" <david.tweed@gmail.com> writes:
> ... I'm just asking if there's a way to say
> "the `working dir' associated with this git dir" explicitly (in the same
> way I can use `HEAD' to refer to the topmost commit on the
> current branch) when you're not somewhere within the 'working dir'.
Not for "git diff <one-tree>" which is a way to diff the _part_
of work tree you are _currently in_ with the given tree, nor for
"git diff" which is to do the same with the index. With these
commands (and others that error out when you run without GIT_DIR
outside the work tree), you are really expected to be _in_ the
subdirectory you are interested in.
GIT_WORK_TREE is somewhat related but is a different issue, by
the way. It is to let you say where the top level of the work
tree is. It does not change the fact that the way for you to
express which subdirectory in the work tree you are interested
in to work tree commands is by your $PWD relative to the top of
the work tree.
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzfh7xd.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote:
> "root" <root@sandia.gov> writes:
>
> > +post-checkout
> > +-----------
> > +
> > +This hook is invoked when a `git-checkout` is run on a local repository.
> > +The hook is given two parameters: the ref of the previous HEAD, and the ref of
> > +the new HEAD. This hook cannot affect the outcome of `git-checkout`.
> > +
> > +This hook can be used to perform repository validity checks, auto-display
> > +differences from the previous HEAD, or set working dir metadata properties.
> > +
>
> People may wonder why this is not run when they do "git checkout
> otherbranch path.c"; the second sentence from the above
> description implies why it shouldn't, but the first sentence
> probably should state it more clearly.
>
> What's the _semantics_ you are trying to achieve?
>
> Why does the hook run every time git-bisect suggests the next
> revision to try?
Its being run since git-bisect calls git-checkout internally, but since
the 'git-checkout $branch' could potentially update the working tree it
may be desirable to have the hook run. Since one stated purpose of the
hook is maintain repository validity or update metadata, running the
hook at this time may be the right thing to do.
> Why does the hook run when rebase starts its work?
I think this case is actually desirable. If the rebase changes some
aspects of the working dir that the hook cares about (eg: metadata),
then the hook will be able handle the situation correctly. Not running
the hook for a rebase operation could result in the working dir being
left in an inconsistent state.
-JE
^ permalink raw reply
* Re: git-send-email is omitting author and date lines
From: martin f krafft @ 2007-09-24 17:30 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano, Hanspeter Kunz, git
In-Reply-To: <Pine.LNX.4.64.0709241209470.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.24.1210 +0100]:
> And that is perfectly okay, since as far as the public is
> concerned, this is the date of the patch.
If you say so. I don't find this at all convincing.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"if i am occasionally a little overdressed, i make up for it by being
always immensely over-educated."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzfh7xd.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote:
> "root" <root@sandia.gov> writes:
>
> > +post-checkout
> > +-----------
> > +
> > +This hook is invoked when a `git-checkout` is run on a local repository.
> > +The hook is given two parameters: the ref of the previous HEAD, and the ref of
> > +the new HEAD. This hook cannot affect the outcome of `git-checkout`.
> > +
> > +This hook can be used to perform repository validity checks, auto-display
> > +differences from the previous HEAD, or set working dir metadata properties.
> > +
>
> People may wonder why this is not run when they do "git checkout
> otherbranch path.c"; the second sentence from the above
> description implies why it shouldn't, but the first sentence
> probably should state it more clearly.
>
> What's the _semantics_ you are trying to achieve?
I'd like to get a hook that runs whenever the working dir gets
updated. The 'git-checkout otherbranch path.c' case should run it also, so I view that as a bug.
> Why does the hook run every time git-bisect suggests the next
> revision to try?
> Why does the hook run when rebase starts its work?
It may be inserted in a ad place or maybe it needs some intelligence in
there to know when *not* to run.
> When "git pull" or "git merge" results in a fast forward, the
> situation is no different from checking out a new revision. Why
> doesn't the hook run in these cases?
This is actually what I'd like to do. I submitted the post-merge patch
some time ago to serve that purpose. Do you think they should both be
rolled into a single post-checkout hook? It would seem to make sense to
me.
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: David Tweed @ 2007-09-24 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v6420au43.fsf@gitster.siamese.dyndns.org>
On 9/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> It would be illustrative if David did the following.
>
> $ cd $HOME
> $ cp -a V W
> $ rm -fr W/.git
> $ cd W
> $ GIT_DIR=$HOME/V/.git git diff @{midnight}
>
> Now we are in a random place outside of the work tree
> (i.e. "W"), and we drive "git diff" with GIT_DIR specified,
> telling it to pretend that we are at the top level of the work
> tree. So ~/W/frotz is compared with "frotz" at the top level of
> the commit (which usually is compared with ~/V/frotz), etc. But
> the directory we happen to be in very much resembles the work
> tree, so it would give identical results to
>
> $ cd $HOME/V
> $ git diff @{midnight}
To separate the two issues, I did all the commands to the diff
above and then removed one directory from the tree in W.
GIT_DIR=$HOME/V/.git git diff master~1
(which ought not need reflogs, right) and it gave a diff between
the contents of W and master~1. I also tried with commit
master@{midnight} and that also gave the difference between
W and the last commit yesterday. So Junio's explanation of what's going on
is right. I'm just asking if there's a way to say
"the `working dir' associated with this git dir" explicitly (in the same
way I can use `HEAD' to refer to the topmost commit on the
current branch) when you're not somewhere within the 'working dir'.
If there's not I can alias around it with
"cd $HOME/V && command && cd -". (As I say, for reasons unrelated
to git usage I don't actually "do work" within the tracked tree.)
Many thanks,
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Problem importing a subversion repository with git-svnimport
From: Guillaume Chazarain @ 2007-09-24 16:49 UTC (permalink / raw)
To: git
Hello,
Here is a simple testcase illustrating a conversion problem between
subversion and git. git-svn handles it fine, but git-svnimport keeps
stuff in the checkout that shouldn't be there.
# git --version => git version 1.5.3.2.99.ge4b2
# svn --version | head -n 1 => svn, version 1.4.3 (r23084)
mkdir test-svn
cd test-svn
svnadmin create svn-repo
svn co file://$PWD/svn-repo svn-check-out
cd svn-check-out
mkdir trunk branches tags
svn add *
svn ci -m 'SVN dirs'
cd trunk
mkdir -p a/b/c/d
echo A > a/A
echo B > a/b/B
echo C > a/b/c/C
echo D > a/b/c/d/D
svn add a
svn ci -m 'Add some data'
svn mv a/b .
svn rm b/c
svn ci -m 'Some shuffling around'
ls -R
cd ../..
mkdir git-repo
cd git-repo
git-svnimport file://$PWD/../svn-repo
ls -R
After the subversion manipulations, the svn checkout only contains the
directories a/ b/ with their respective files A and B.
The checkout from git-svnimport contains these elements, but also the
full c/ directory in b/.
Hope the testcase is clear enough ;-)
--
Guillaume
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Junio C Hamano @ 2007-09-24 16:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Linus Torvalds, Johannes Schindelin, msysgit, git
In-Reply-To: <46F7E2A5.6030202@eudaptics.com>
Johannes Sixt <j.sixt@eudaptics.com> writes:
> Linus Torvalds schrieb:
>
>> ...
>> Or maybe you did fetch a tracking branch?
>
> I don't think I fetched a tracking branch. If I do:
>
> $ mkdir foo && cd foo && git init
> $ git fetch ../git master:refs/heads/master
>
> (where ../git is a clone of git.git with a few local changes), I get
> all the tags. Good or bad?
That's exactly Linus meant "fetching a tracking branch". Your
refspec has non-empty string on the RHS of the colon.
$ git fetch ../git master
is the form without tracking. IOW, not storing into your refs
namespace.
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: Junio C Hamano @ 2007-09-24 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Tweed, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709241400410.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 24 Sep 2007, David Tweed wrote:
>
>> ... In
>> a different directory, OUTSIDE of $HOME/V, I tried
>>
>> env GIT_DIR=$HOME/V/.git git diff master@{midnight}
>>
>> to get the same effect but, whilst I do get a diff output, it
>> looks like a diff of the commit against an empty tree.
>
> Yes, this is fully expected.
>
> The @{time} notation accesses the _reflogs_, which are purely local
> beasts. They are not transmitted when cloning.
Yeah, but my reading of the problem description suggests the two
cases refer to the same repository (hence the same reflogs).
The issue is that the second case runs "git diff <one-tree>" in
a random directory. This form is about comparing the part of
work tree you are in with a given tree, and does not make _any_
sense when outside the work tree. Usually without GIT_DIR
environment, the command would give you an error message.
With $GIT_DIR, but without $GIT_WORK_TREE, the user is telling
the command that it is being run at the top level of the work
tree and the repository metadata is not in the usual ".git"
subdirectory of the top level of the work tree (in this case, by
definition that is "$PWD/.git") but elsewhere where $GIT_DIR
specifies. Because it is very likely that the files under the
random location does not share much resemblance to what are in
$HOME/V, it is not surprising that the output consisted of many
deletions.
It would be illustrative if David did the following.
$ cd $HOME
$ cp -a V W
$ rm -fr W/.git
$ cd W
$ GIT_DIR=$HOME/V/.git git diff @{midnight}
Now we are in a random place outside of the work tree
(i.e. "W"), and we drive "git diff" with GIT_DIR specified,
telling it to pretend that we are at the top level of the work
tree. So ~/W/frotz is compared with "frotz" at the top level of
the commit (which usually is compared with ~/V/frotz), etc. But
the directory we happen to be in very much resembles the work
tree, so it would give identical results to
$ cd $HOME/V
$ git diff @{midnight}
^ permalink raw reply
* Re: git-svn: Deleting directories
From: Adam Roben @ 2007-09-24 16:37 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F7C3EA.2080806@gmail.com>
Russ Brown wrote:
> I've just noticed that when deleting entire directory trees in git, when
> the dcommit happens only the files in that trees get deleted, which
> leaves a 'ghost town' of a directory tree with folders but no files,
> which will no doubt have somewhat confused my svn-using colleagues.
>
> This is obviously an interoperability problem, but I understand that git
> does not track folders and is so tricky to fix.
>
> The question though is how to handle it. Ideally, dcommit will detect
> that an entire directory has gone and send through a changeset which
> deletes just that one directory, instead of the current behaviour of
> explicitly deleting every file in the directory but leaving the
> directories themselves intact.
>
There's a similar problem when renaming a directory. dcommit will
essentially commit a series of moves of individual files rather than
moving the whole directory. Again this is due to git not tracking
directories. I should hope that whatever logic is used for detecting a
directory removal may also be used for detecting a directory rename.
-Adam
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Johannes Schindelin @ 2007-09-24 16:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Linus Torvalds, msysgit, git
In-Reply-To: <46F7E2A5.6030202@eudaptics.com>
Hi,
On Mon, 24 Sep 2007, Johannes Sixt wrote:
> Linus Torvalds schrieb:
> >
> > On Sun, 23 Sep 2007, Johannes Schindelin wrote:
> > > > 6) What was the most frustrating moment when working with Git?
> > > Just the other day, I wanted to fetch a set of changes from a public
> > > repo into my test repo in order to cherry-pick from them - and it
> > > automatically fetched all the tags. But, the heck, I don't want them tags
> > > here, just the commits. I just can't figure out how to avoid the
> > > automatic
> > > fetching of tags.
> >
> > The way this was *supposed* to work is that if you are not fetching a
> > "tracking branch", it should not fetch any tags.
> >
> > Maybe this got broken lately?
> >
> > Or maybe you did fetch a tracking branch?
>
> I don't think I fetched a tracking branch. If I do:
>
> $ mkdir foo && cd foo && git init
> $ git fetch ../git master:refs/heads/master
>
> (where ../git is a clone of git.git with a few local changes), I get all the
> tags. Good or bad?
The ":refs/heads/master" part says that you fetch into a tracking branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Junio C Hamano @ 2007-09-24 16:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miles Bader, Eygene Ryabinkin, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709241502330.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 24 Sep 2007, Miles Bader wrote:
>> ...
>> In practice that's not an issue though -- every reasonable shell has
>> test as a builtin these days, so the "works when test is not a builtin"
>> criteria is really important only for robustness.
>
> AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
>
> _Exactly_ the same reasoning can be said about the old code: _every_
> reasonable shell can grok the code that used to be there!
>
> <rhetoric-question>
> So what exactly was your point again?
> </rhetoric-question>
The points are:
(1) The code used to be there is known to cause trouble with a
deployed shell on FreeBSD of some vintage. It may be true
that the shell is broken, but it does not matter much to
the end user on such systems if breakage is in shell or in
scripts --- the end result is that the user cannot benefit
from git, and we already happen to know the workaround,
which does not make the scripts less readable nor less
portable;
(2) It's not like people who work on git scripts share the
exact same style and tradition. While I do not personally
think there is much readability improvements between the
old code and the new code, if more people find the latter
easier to work with, it's better to switch to the new code
especially because there is no downside.
(2-a) Nobody finds the latter less readable nor impossible
to work with. Even I am not saying that; I only said
I do not think it improves.
(2-b) git is not an educational project. It can be done
elsewhere in a UNIX history class, not here, to teach
people that "case ... esac" used to be much more
preferred over "test" because often the latter was
not built-in and slower.
Regarding "$# != 0" vs "$# -ne 0", I agree with the patch by
David. If the variable were "$something_else", then it might
have been better to use the explicitly numeric form, but I think
any seasoned shell people is much more used to see $# and $? (or
$status after an earlier "status=$?") compared with numeric
string with "=" or "!=".
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Johannes Sixt @ 2007-09-24 16:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <alpine.LFD.0.999.0709240840310.3579@woody.linux-foundation.org>
Linus Torvalds schrieb:
>
> On Sun, 23 Sep 2007, Johannes Schindelin wrote:
>>> 6) What was the most frustrating moment when working with Git?
>> Just the other day, I wanted to fetch a set of changes from a public
>> repo into my test repo in order to cherry-pick from them - and it
>> automatically fetched all the tags. But, the heck, I don't want them tags
>> here, just the commits. I just can't figure out how to avoid the automatic
>> fetching of tags.
>
> The way this was *supposed* to work is that if you are not fetching a
> "tracking branch", it should not fetch any tags.
>
> Maybe this got broken lately?
>
> Or maybe you did fetch a tracking branch?
I don't think I fetched a tracking branch. If I do:
$ mkdir foo && cd foo && git init
$ git fetch ../git master:refs/heads/master
(where ../git is a clone of git.git with a few local changes), I get all the
tags. Good or bad?
-- Hannes
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Linus Torvalds @ 2007-09-24 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, git
In-Reply-To: <Pine.LNX.4.64.0709232153230.28395@racer.site>
On Sun, 23 Sep 2007, Johannes Schindelin wrote:
>
> > 6) What was the most frustrating moment when working with Git?
>
> Just the other day, I wanted to fetch a set of changes from a public
> repo into my test repo in order to cherry-pick from them - and it
> automatically fetched all the tags. But, the heck, I don't want them tags
> here, just the commits. I just can't figure out how to avoid the automatic
> fetching of tags.
The way this was *supposed* to work is that if you are not fetching a
"tracking branch", it should not fetch any tags.
Maybe this got broken lately?
Or maybe you did fetch a tracking branch?
Anyway, I fetch stuff all the time, and if git were to fetch the tags too,
I'd be *really* unhappy. So either the people I work with are just good
people, or more likely it still works the way it's supposed to work: if
you just fetch into FETCH_HEAD (by explicitly giving the remote repository
name, and not using tracking branches), it should not fetch tags for you.
Linus
^ 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