* Re: Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-20 16:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550706192327l187b30eblb5bd5e4e76b3eab6@mail.gmail.com>
On Wed, 20 Jun 2007, Marco Costalba wrote:
>
> now I have one more reason to switch from using git-rev-list to
> git-log in qgit, file history annotation, that is currently based on
> git-rev-list, will automatically gain a powerful feature.
Well, note my other email about how "--follow" does *not* play together
with "--parents", because the two do totally different kinds of filtering
of the commits. So yes, you can use it for file history annotation, but
not for the "graphical history" part that depends on parenthood etc.
That said, you really would be better off using
git blame -M --incremental
for the history annotation. It does the rename following *and* so much
more.
Linus
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Jakub Narebski @ 2007-06-20 16:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706201129550.4059@racer.site>
Johannes Schindelin wrote:
> On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
> > On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:
> > > [foo "bar\nbaz"]
> > > key = value
> > > gives
> > >
> > > foo.barbaz.key=value
> >
> > for me this gives
> >
> > foo.barnbaz.key=value
>
> Yes, of course I had to have a typo in my message. *sigh*
>
> The point is, that I would not expect a "\" to be _ignored_. Either
> interpreted, or throwing an error, but just ignored?
It is interpreted. Perhaps not what you thought it is interpreted, but
it is interpreted. '\x' => 'x' for 'x' which are not in some limited
set. ;-)))
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-06-20 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwszf9md5.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1.1: Type: text/plain, Size: 551 bytes --]
On Friday 11 May 2007 22:44:06 Junio C Hamano wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Most(All?) distros /usr/share/man in MANPATH so I believe this
> > patch shouldn't break anything but well you have the final
> > say. I am ok with doing make mandir=/usr/share/man install-doc
>
> My preference is to do this early after 1.5.2. I do not want to
> touch builds with trivial changes before the final.
Still not applied to 1.5.2.2. Patch attached for convenience.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #1.2: mandir.patch --]
[-- Type: text/x-diff, Size: 309 bytes --]
--- Documentation/Makefile 2007-02-26 21:20:28.000000000 +0200
+++ Documentation/Makefile 2007-02-28 01:18:07.672166995 +0200
@@ -26,7 +26,7 @@
prefix?=$(HOME)
bindir?=$(prefix)/bin
-mandir?=$(prefix)/man
+mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man7dir=$(mandir)/man7
# DESTDIR=
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: filenames with " b" in them create confusing git diff-tree output
From: Junio C Hamano @ 2007-06-20 19:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18041.3163.329391.298926@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> paulus@quango:~/gitk/testrepo$ git diff-tree -r -p -C HEAD
> 71a3074e723c3e5eb599e6b3c47e3267a3cac3bc
> diff --git a/test b/foo b/test b/foo
> new file mode 100644
> index 0000000..f2e4113
> --- /dev/null
> +++ b/test b/foo
> @@ -0,0 +1 @@
> +stuff
>
> Note how there appear to be 4 filenames on the "diff --git" line. At
> present gitk will interpret that as a diff between "test" and
> "foo b/test b/foo", since it looks for " a/" and " b/" to delimit the
> filenames. Of course if the file got renamed it could get even more
> confusing. :)
Your example, "a/test b/foo" vs "b/test b/foo", can be and IS
parsed unambiguously by git-apply (you can try "git apply
--stat" your example). IOW, the code to correctly handle it
already exists ;-)
If you are seeing a rename/copy you would get explicit rename
lines between "diff --git" header and "index HEXHEX..HEXHEX"
line, what we (i.e. git-apply) do is to make sure the
information we get on the "diff --git" header and those on
rename/copy lines match. The latter is more reliable, of
course, as they are in strictly one-line-per-filename format,
and in fact we use the information from there instead of "diff
--git" line for rename patches. And for non-rename case, you
can find all instances of "b/", and see if what follows to the
end of line of which instance of b/ does match what is between
"diff --git a/" and that "b/".
In your example, you have three possible "b/" that indicates the
beginning of a name:
foo b/test b/foo
test b/foo
foo
The leading part after "diff --git a/" for the above three
possibilities are:
test
test b/foo
test b/foo b/test
and you can tell the second one gives the match.
> Would there be any ill effects from quoting filenames with spaces, do
> you think?
It is very common (I would not do that personally but I do not
have a strong reason to advise against when people want to do
so) to have a space in filenames.
^ permalink raw reply
* Re: post-update script to update wc - suggestions welcome
From: Sam Vilain @ 2007-06-20 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Lederhofer
In-Reply-To: <7vr6o7uhwz.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
> Also you would want to see if the thing is bare.
>
> Unfortunately, git-sh-setup's is_bare_repository does a wrong
> thing because receive-pack already runs GIT_DIR set to '.' after
> chdir to it. Matthias's long set of patches currently parked in
> 'pu' is supposed to clarify the semantics of bare/non-bare, so
> it may help though (it has "rev-parse --is-bare-repository).
>
> I think 80% of the time (because other 20% of bare repositories
> are initialized, following an often repeated incorrect procedure
> of making a worktree-full repository and moving its .git/ to
> another place, $name.git --- that is wrong for at least three
> reasons), if $GIT_DIR/index exists, you can treat it as a
> non-bare repository.
>
Great, well in lieu of that, Matthias suggests a reasonable extra
heuristic of whether or not the pathname ends in "/.git" (or "\.git").
Which falls into the "why didn't I think of that" category ;-).
No doubt with those patches the hook can be simplified, especially if it
sets GIT_WORK_TREE.
>> cd ..
>> success=
>> if git-diff-files
>> then
>>
>
> I would suggest running update-index --refresh before running
> diff-files. The user may have cache-dirty file and only that.
>
Ah yes, is that what git-status does that checks the filestamps in the
index and updates them... Handy to know.
>> git-diff-index -z -R --name-status HEAD | perl -n0 -le \
>> 'if ($z^=1) {
>> $status=$_;
>> }
>> else {
>> $filename=$_;
>> printf STDERR "$status\t$filename\n";
>> if($status eq "D"){
>> unlink($filename)
>> or die("unlink($filename) failed; $!")
>> }
>> }' &&
>>
>
> With "--name-only --diff-filter=D" you would not have to do most
> of the above ;-) Use --diff-filter=A without -R, perhaps, to
> make it even shorter.
>
You're right, it was right there!
I think it's a good thing to echo back to the user the output of the
--name-status command, so they can see the changes that were made.
>> git-reset --hard HEAD && success=1
>> fi
>>
>
> Wouldn't "reset --hard HEAD" pretty much unconditionally nuke
> your local changes, including added files to the index? For
> example, if I do this:
>
> $ >foo && git add foo && git reset --hard HEAD
>
> it would remove the newly added 'foo' from both the index and
> the working tree. So I am not quite sure what you are trying to
> achieve with "diff-index | perl" magic.
>
Right, but we've already checked using diff-files that there weren't any
local changes. So all we're saying is "remove all files which won't be
written by git reset --hard, then checkout new versions of files".
Actually there is a slight deficiency in the above script - empty
directories will not be removed, so replacing a directory with a file
will be broken.
> I'll cook up an alternative patch perhaps tomorrow.
>
Cool! I'm sure bzr and darcs users will thank you :-)
Sam.
^ permalink raw reply
* Re: Directory renames (was Re: blame follows renames, but log doesn't)
From: Sam Vilain @ 2007-06-20 20:18 UTC (permalink / raw)
To: Steven Grimm, Git Mailing List
In-Reply-To: <4678204C.6050409@midwinter.com>
Steven Grimm wrote:
> Hope that's illuminating or at least interesting to someone.
I didn't review your test cases in detail, but they seemed to suffer
from what I call "over-trivialization"; the heuristic methods don't work
very well for these non-real-world test cases because they're not long
enough. Are you confident that these deficiencies are still there with
longer examples?
Sam.
^ permalink raw reply
* Re: [PATCH] git-send-email: RFC2822 compliant Message-ID
From: Junio C Hamano @ 2007-06-20 20:18 UTC (permalink / raw)
To: Michael Hendricks; +Cc: git
In-Reply-To: <11823459011323-git-send-email-michael@ndrix.org>
Michael Hendricks <michael@ndrix.org> writes:
> RFC 2822 section 3.6.4 suggests that a "good method" for generating a
> Message-ID is to put the domain name of the host on the right-side of
> the "@" character. Use Perl's Sys::Hostname to do the heavy lifting.
> This module has been in the Perl core since version 5.
Probably is a good idea for 50% of properly configured hosts. I
think hosts can be configured so that hostname() already returns
fqdn in which case your patch is fine but they can also be
configured so that hostname() plus its domainname becomes fqdn,
in which case it is probably not. In any case it is mere
suggestion (not MUST nor even SHOULD), so we should judge its
merits a bit carefully.
What happens if the machine you run send-email on does not have
a valid hostname configured yet? People on home machines or
laptops whose only contact outside are with their ISP
mailservers should be able to send their patches without having
to configure /etc/hostname, shouldn't they? Does Sys::Hostname
die under some condition, such as "the host is not configured
well enough"? If so I suspect the change to replace the
existing one is not acceptable.
I think we should use something safe that gives reasonably
unique identifier and the existing $message_id_from based method
is one way to do so.
The message from vger mailmaster (DSM) suggests that somehow
$message_id_from method returned an empty string. Maybe make
your patch used as a fallback in such a case?
Finally could you resend this with your updated git-send-email?
I suspect that this line in the mail header of your patch:
Message-ID: <11823459011323-git-send-email-michael@ndrix.org>
should have read like so:
Message-ID: <11823459011323-git-send-email@ndrix.org>
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Junio C Hamano @ 2007-06-20 20:20 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200706202242.13100.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> On Friday 11 May 2007 22:44:06 Junio C Hamano wrote:
>> Ismail Dönmez <ismail@pardus.org.tr> writes:
>> > Most(All?) distros /usr/share/man in MANPATH so I believe this
>> > patch shouldn't break anything but well you have the final
>> > say. I am ok with doing make mandir=/usr/share/man install-doc
>>
>> My preference is to do this early after 1.5.2. I do not want to
>> touch builds with trivial changes before the final.
>
> Still not applied to 1.5.2.2. Patch attached for convenience.
Thanks.
I do not think this patch should happen to 1.5.2.X for any value
of X; but I am willing to apply it to 'master' (hence 1.5.3 and
later).
^ permalink raw reply
* Re: filenames with " b" in them create confusing git diff-tree output
From: Linus Torvalds @ 2007-06-20 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7v4pl2v1lf.fsf@assigned-by-dhcp.pobox.com>
On Wed, 20 Jun 2007, Junio C Hamano wrote:
>
> Your example, "a/test b/foo" vs "b/test b/foo", can be and IS
> parsed unambiguously by git-apply (you can try "git apply
> --stat" your example). IOW, the code to correctly handle it
> already exists ;-)
Well, in all fairness, I *did* hate having to write the code to handle all
the name handling in git-apply.
Escaping whitespace (or at least giving the _option_ to do so) might well
be a good way to not have to be as smart as git-apply is.
git-apply didn't have that option, since git-apply has as one primary
motivation the need to be able to handle patches that come from non-git
sources, so git-apply goes to quite some extreme lengths to try to make
sense of an inherently rather ambiguous format (that the git diffs then
*made* unambiguous, but using pretty subtle rules in order to stay
compatible).
Some maybe we should have some generic method of asking for any filename
to be quoted in particular ways?
Linus
^ permalink raw reply
* Re: [PATCH] git-send-email: RFC2822 compliant Message-ID
From: Junio C Hamano @ 2007-06-20 20:47 UTC (permalink / raw)
To: Michael Hendricks; +Cc: git
In-Reply-To: <11823459011323-git-send-email-michael@ndrix.org>
How about doing this instead?
* Move call to make_message_id() to where it matters, namely,
before the $message_id is needed to be placed in the
generated e-mail header; this has an important side effect of
making it clear that $from is already available.
* Throw in Sys::Hostname::hostname() just for fun, although I
suspect that the code would never trigger due to the modified
call sequence that makes sure $from is always available.
---
diff --git a/git-send-email.perl b/git-send-email.perl
index 7c0c90b..9f75551 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -412,13 +412,21 @@ sub extract_valid_address {
# 1 second since the last time we were called.
# We'll setup a template for the message id, using the "from" address:
-my $message_id_from = extract_valid_address($from);
-my $message_id_template = "<%s-git-send-email-$message_id_from>";
sub make_message_id
{
my $date = time;
my $pseudo_rand = int (rand(4200));
+ my $du_part;
+ for ($from, $committer, $author) {
+ $du_part = extract_valid_address($_);
+ last if ($du_part ne '');
+ }
+ if ($du_part eq '') {
+ use Sys::Hostname qw();
+ $du_part = 'user@' . Sys::Hostname::hostname();
+ }
+ my $message_id_template = "<%s-git-send-email-$du_part>";
$message_id = sprintf $message_id_template, "$date$pseudo_rand";
#print "new message id = $message_id\n"; # Was useful for debugging
}
@@ -467,6 +475,8 @@ sub send_message
$ccline = "\nCc: $cc";
}
$from = sanitize_address_rfc822($from);
+ make_message_id();
+
my $header = "From: $from
To: $to${ccline}
Subject: $subject
@@ -533,7 +543,6 @@ X-Mailer: git-send-email $gitversion
$reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
-make_message_id();
$subject = $initial_subject;
foreach my $t (@files) {
@@ -627,7 +636,6 @@ foreach my $t (@files) {
$references = "$message_id";
}
}
- make_message_id();
}
if ($compose) {
^ permalink raw reply related
* Re: filenames with " b" in them create confusing git diff-tree output
From: Junio C Hamano @ 2007-06-20 20:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.98.0706201315310.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Some maybe we should have some generic method of asking for any filename
> to be quoted in particular ways?
Probably, especially if you notice there has been a separate
thread whose title begins with a word "Stupid".
^ permalink raw reply
* Re: Directory renames (was Re: blame follows renames, but log doesn't)
From: Steven Grimm @ 2007-06-20 20:59 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <46798B8E.6040103@vilain.net>
Sam Vilain wrote:
> I didn't review your test cases in detail, but they seemed to suffer
> from what I call "over-trivialization"; the heuristic methods don't work
> very well for these non-real-world test cases because they're not long
> enough. Are you confident that these deficiencies are still there with
> longer examples?
>
Those test cases were a demonstration of something I actually ran into
on a real-world project yesterday. The test cases are trivial and short
simply to make them easy to follow in an email message. If you
substitute longer contents for the test files in my example, you will
see the exact same behavior. The real file in question is around 2KB
long, not a monster but presumably long enough that the heuristics
should work.
Also -- though this doesn't happen to be relevant in the case where I
ran into this -- not all files in real-world projects are huge. If the
heuristics break on small test-case files then they will break on small
real-world files too. If nothing else, a real-world project can itself
contain trivial test data (for testing the project, not testing the
version control system) in the form of lots of small files with similar
or identical contents.
-Steve
^ permalink raw reply
* Re: post-update script to update wc - suggestions welcome
From: Junio C Hamano @ 2007-06-20 21:02 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Matthias Lederhofer
In-Reply-To: <46798AB6.6060403@vilain.net>
Sam Vilain <sam@vilain.net> writes:
>>> cd ..
>>> success=
>>> if git-diff-files
>>> then
>>>
>> ...
>>
>>> git-reset --hard HEAD && success=1
>>> fi
>>>
>>
>> Wouldn't "reset --hard HEAD" pretty much unconditionally nuke
>> your local changes, including added files to the index? For
>> example, if I do this:
>>
>> $ >foo && git add foo && git reset --hard HEAD
>>
>> it would remove the newly added 'foo' from both the index and
>> the working tree. So I am not quite sure what you are trying to
>> achieve with "diff-index | perl" magic.
>
> Right, but we've already checked using diff-files that there weren't any
> local changes. So all we're saying is "remove all files which won't be
> written by git reset --hard, then checkout new versions of files".
I am afraid I am not following your logic.
I missed that "if git-diff-files"; it is not checking (you would
have to ask for --exit-code or something --- traditionally we
never used git-diff-xxxx exit code to indicate if there is any
changes).
Suppose we update that "if" to see if diff-files says "no change
in the working tree wrt the index". But then, I think what you
have at the end, "git reset --hard HEAD", where the HEAD is an
arbitrary commit that does not necessarily have to do anything
with what the index is based on, would remove what is known to
the index but not in HEAD. Which was my point about the
"diff-index piped to perl". I do not think that one is
necessary.
Actually, more importantly, why is it justified to remove a file
that is unchanged since the index, if the updated HEAD does not
have it? That is losing information, isn't it?
Or are you assuming that this is used only for a worktree where
there is NO actual development happens, but just kept up to date
to whatever commit comes at HEAD?
^ permalink raw reply
* Re: Suggestions for documentation
From: Luiz Fernando N. Capitulino @ 2007-06-20 21:06 UTC (permalink / raw)
To: Claudio Scordino; +Cc: git
In-Reply-To: <467786B1.5000009@gmail.com>
Em Tue, 19 Jun 2007 09:33:05 +0200
Claudio Scordino <cloud.of.andor@gmail.com> escreveu:
| Hi,
|
| I just want to suggest to put some missing information in the git manpages.
|
| 1) As my previous question shown, how to clone from a specified port is not
| currently documented. You should just add a sentence saying that the command is
|
| git clone git://server:port/path/
|
| 2) Maybe it is better to highlight that after a push on a remote repository, the
| user has to do a checkout on that repository (people from the CVS and SVN worlds
| get easily confused, otherwise).
|
| Moreover (and I did not fully understood why) if I just use "git checkout"
| without the -f option, I cannot see the changes that have been pushed from the
| cloned repository.
git-rebase documentation needs some change too. We should add some high level
description in one paragraph at the top of the file.
I answer the very same question ('why should I want to use git-rebase?')
three times per week.
I'll submit a patch shortly.
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* Re: [PATCH] Cloning from a repo without "current branch"
From: Nanako Shiraishi @ 2007-06-20 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqff1c3w.fsf@assigned-by-dhcp.pobox.com>
Quoting Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@bluebottle.com> writes:
>
> > diff --git a/git-clone.sh b/git-clone.sh
> > ?*)
>
> Whitespace breakage?
>
> > @@ -384,21 +391,20 @@ then
> > git-config branch."$head_points_at".merge
> > "refs/heads/$head_points_at"
> > + ;;
>
> Again...?
Sorry, I'll re-send from a different mail addr.
Is it alright to send attachments?
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Jakub Narebski @ 2007-06-20 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <4677A7EF.500@midwinter.com>
Steven Grimm wrote:
> What git doesn't handle, but BitKeeper does, is applying directory
> renames to newly created files. I rename the "lib" directory to "util",
> you create a new file lib/strings.c and update lib/Makefile to compile
> it. I pull from you. Under BitKeeper, I will get util/strings.c and the
> change will be applied to my util/Makefile. git will create a brand-new
> "lib" directory containing nothing but the new file, but since the
> Makefile existed before, it will (correctly) apply your change to my
> util/Makefile, which will then break my build because it will refer to a
> file that doesn't exist in the Makefile's directory.
>
> This has bitten me a few times in real life, e.g. in cases where I'm
> importing a third-party source tarfile and reorganizing it a little to
> fit it into my local build system. Every time they add a new source
> file, I have to go manually clean up after it rather than just merging
> the vendor branch into mine like I can do when they don't add anything.
> It is not frequent enough to be a major hassle for me but it sure is
> annoying when it happens (especially since sometimes the build *doesn't*
> break and it takes a while to notice a newly created file isn't where it
> should be.)
I think git can at least try to detect this situation, and perhaps
even resolve this automatically. Namely, if we add file with the
following <path>: <dirname>/<basename>, and <dirname> tree does exists in
the ancestor but does not exist in the other branch, this is CONFLICT(add)
(or something like that), with appropriate explanation.
One way to resolve this CONFLICT(add) automatically would be to check where
all the files in no longer existing <dirname> moved to, and if they all are
of the form <newdir>/<somename> then we should add the <dirname>/<basename>
file under <newdir>/<basename>. If some of them were moved to other
directory, for example contents of one directory got split into two
directories, this is conflict which cannot be resolved automaticaly
(CONFLICT(add/multiple) or something like that perhaps?). And I guess that
SCM which _track_ renaming of directories, like Bazaar-NG, would NOT detect
this as a conflict, and happily add to perhaps wrong directory.
Or we could reuse rename detection, taking modes+filenames as tree contents,
or perhaps set of file contents as tree contents, for our content based
rename detection.
P.S. Allow me to remind you rename _detection_ success story, send here some
time ago by Johannes Schindelin in the "Rename handling" thread:
Message-ID: <Pine.LNX.4.63.0703210120230.22628@wbgn013.biozentrum.uni-wuerzburg.de>
http://permalink.gmane.org/gmane.comp.version-control.git/42770
JS> By now, there have been enough arguments _for_ automatic rename detection,
JS> but I'll add another one.
JS>
JS> A colleague of mine worked on a certain file in a branch, where he copied
JS> the file to another location, and heavily modified it. He did that in a
JS> branch, and when he was satisfied with the result, he deleted the old
JS> file, since he liked the new location better.
JS>
JS> Now, when I pulled, imagine my surprise (knowing the history of the file),
JS> when the pull reported a rename with a substantial similarity!
JS>
JS> So, the automatic renamer did an awesome job.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: post-update script to update wc - suggestions welcome
From: Sam Vilain @ 2007-06-20 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Lederhofer
In-Reply-To: <7vtzt2s5jl.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
> I am afraid I am not following your logic.
>
> I missed that "if git-diff-files"; it is not checking (you would
> have to ask for --exit-code or something --- traditionally we
> never used git-diff-xxxx exit code to indicate if there is any
> changes).
Oh, I expected a diff command to return an error code if differences
were found, like diff does.
> Suppose we update that "if" to see if diff-files says "no change
> in the working tree wrt the index". But then, I think what you
> have at the end, "git reset --hard HEAD", where the HEAD is an
> arbitrary commit that does not necessarily have to do anything
> with what the index is based on, would remove what is known to
> the index but not in HEAD.
Good point. Yes a semi-staged commit would lose information. So we
also need to check that the index matches the previous value of what the
current branch points to.
How about this. We call write-tree and get a tree ID. If we can find
that tree in any of the commits reachable by the reflog or the history
of the current branch then we can be happy that no local changes have
been staged. That will imply that if you want a non-bare repository to
update automatically and use push -f, you need reflog.
> Which was my point about the
> "diff-index piped to perl". I do not think that one is
> necessary.
Sure, I only did that because I didn't think reset --hard would remove
files which were previously in the index but not in the version being
reset to.
> Actually, more importantly, why is it justified to remove a file
> that is unchanged since the index, if the updated HEAD does not
> have it? That is losing information, isn't it?
Well, not if you can confirm that the index matches some previous
version of the branch.
> Or are you assuming that this is used only for a worktree where
> there is NO actual development happens, but just kept up to date
> to whatever commit comes at HEAD?
I was aiming for something safe that people can just chmod +x to get
symmetric push/pull semantics.
Sam.
^ permalink raw reply
* Re: [PATCH] Cloning from a repo without "current branch"
From: Junio C Hamano @ 2007-06-20 22:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <200706202150.l5KLoHkE002843@mi0.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Nanako Shiraishi <nanako3@bluebottle.com> writes:
>>
>> > diff --git a/git-clone.sh b/git-clone.sh
>> > ?*)
>>
>> Whitespace breakage?
>>
>> > @@ -384,21 +391,20 @@ then
>> > git-config branch."$head_points_at".merge
>> > "refs/heads/$head_points_at"
>> > + ;;
>>
>> Again...?
>
> Sorry, I'll re-send from a different mail addr.
> Is it alright to send attachments?
Well, the breakage was trivial enough to fix at my end; no need
to resend.
Thanks for your patch; it is a real fix (well, at least one of
the necessary ones) to a breakage we discussed on the list
recently.
^ permalink raw reply
* Strange diff behavior?
From: Jason Sewall @ 2007-06-21 1:02 UTC (permalink / raw)
To: git
I'm pretty new to git, but I've been using it a lot recently and I'm
really liking it.
I do have a question that I'm 99% sure is a stupid one but I'd like an
answer anyway.
I recently make a few simple changes to a working directory, and
decided to do a diff before I committed it.
The results were something like the diff at the end of this email.
It seems like every change listed after the first one is meaningless.
I really think I just don't understand something about the diff
algorithm. Can someone tell my why those empty lines are recorded as
changes?
Jason
P.S. git diff --check is empty; there's no whitespace on those lines
P.P.S. The diff:
diff --git a/mac.cpp b/mac.cpp
index 02aab7b..34c510b 100644
--- a/mac.cpp
+++ b/mac.cpp
@@ -80,10 +80,10 @@ float grid::bilerp(const uVec & lower, const Vec &
inpos) const
idx[0] += 1;
vals[3] = (*this)(idx); // 1, 1
- float low_val = lerp(pos[0], vals[0], vals[1]);
- float high_val = lerp(pos[0], vals[2], vals[3]);
+ float low_val = cog::lerp(pos[0], vals[0], vals[1]);
+ float high_val = cog::lerp(pos[0], vals[2], vals[3]);
- return lerp(pos[1], low_val, high_val);
+ return cog::lerp(pos[1], low_val, high_val);
}
float grid::max() const
@@ -194,7 +194,7 @@ mac_grid::mac_grid(const Vec & low, const Vec &
high, unsigned int dim) : low_bo
for(idx[0] = (dim_-1)/4+1; idx[0] < 3*(dim_-1)/4; idx[0]++)
cell_type(idx) = SOLID;
-
+
for(idx[0] = 3*(dim_-1)/4+1; idx[0] < (dim_-1); idx[0]++)
cell_type(idx) = SOLID;
}
@@ -636,7 +636,7 @@ void mac_grid::printA(std::ostream & out)
out << "sparse(";
iVec idx;
-
+
out << "[";
for(idx[1] = 0; idx[1] < static_cast<int>(dim_); idx[1]++)
for(idx[0] = 0; idx[0] < static_cast<int>(dim_); idx[0]++)
@@ -645,7 +645,7 @@ void mac_grid::printA(std::ostream & out)
iVec e(idx + iVec(1, 0));
iVec s(idx - iVec(0, 1));
iVec n(idx + iVec(0, 1));
-
+
if(w[0] > 0)
out << row_major_idx(idx, Adiag_.dim_)+1 <<",";
if(s[1] > 0)
@@ -654,7 +654,7 @@ void mac_grid::printA(std::ostream & out)
out << row_major_idx(idx, Adiag_.dim_)+1 <<",";
if(n[1] < static_cast<int>(dim_))
out << row_major_idx(idx, Adiag_.dim_)+1 <<",";
-
+
out << row_major_idx(idx, Adiag_.dim_)+1 <<",";
}
@@ -742,7 +742,7 @@ float mac_grid::dot(const grid & l, const grid & r) const
for(idx[0] = 1; idx[0] < dim_-1; idx[0]++)
if(cell_type(idx) == FLUID)
res += l(idx)*r(idx);
-
+
return res;
}
@@ -903,7 +903,7 @@ void mac_grid::construct_pc()
{
float sfact = Aplusj_(s)*pc_(s);
ichol += sfact*sfact;
-
+
float wfact = Aplusi_(w)*pc_(w);
ichol += wfact*wfact;
}
@@ -940,7 +940,7 @@ void mac_grid::apply_pc(const grid & rhs, grid & res)
{
uVec s(idx-uVec(0, 1));
uVec w(idx-uVec(1, 0));
-
+
float t = rhs(idx);
if(cell_type(s) == FLUID)
t -= Aplusj_(s)*pc_(s)*q_(s);
^ permalink raw reply related
* Re: Strange diff behavior?
From: Johannes Schindelin @ 2007-06-21 1:13 UTC (permalink / raw)
To: Jason Sewall; +Cc: git
In-Reply-To: <31e9dd080706201802h9dcbffawd82575d09e082155@mail.gmail.com>
Hi,
On Wed, 20 Jun 2007, Jason Sewall wrote:
> It seems like every change listed after the first one is meaningless.
Just a guess: core.autocrlf=true?
Ciao,
Dscho
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-21 1:15 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706191358180.3593@woody.linux-foundation.org>
Junio, I note that you merged this into 'next', and also:
On Tue, 19 Jun 2007, Linus Torvalds wrote:
>
> [ long and boring explanation ]
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ----
Note the *four* dashes instead of three, so:
> NOTE! For obvious enough reasons, I limited the rename following to just
> *one* pathname. If somebody wants to extend it to any more, be my guest.
>
> Also, I really might have some silly bug somewhere.
>
> "It Works For Me(tm)", and I tested it with both the git archive and the
> kernel (block/ll_rw_block.c) and it worked beautifully, but I'll also
> admit that the patch is a bit _too_ clever for my taste normally. The
> patch actually looks more straightforward than it really is: that "hook
> directly into diff_tree_sha1()" thing is just too damn clever for words.
>
> People who want to improve on it should get rid of the memory leak I
> introduced - I decided to not bother cleaning up the whole rename diff
> queue, I just reset it. I'm lazy, and I'm a *man*. I do the rough manly
> stuff, others can clean up after me.
>
> *Burp*. That hit the spot. *Scratch*
This also hit the git archives.
My burping and scratching wasn't really *meant* to be part of the official
record, but hey, there you have it.
No problem, and maybe you noticed and thought it amusing, but in case it
went unnoticed, you may want to clean that up when/if moving it to
"master".
Or not. Your choice.
Linus
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Junio C Hamano @ 2007-06-21 1:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706201811440.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> My burping and scratching wasn't really *meant* to be part of the official
> record, but hey, there you have it.
Well, burping and scratching is already part of the public
record ;-) gmane hopefully remembers it forever.
But you are right. I should re-do that one when moving it to master.
^ permalink raw reply
* [PATCH] Set correct date for tags.
From: Dave O'Neill @ 2007-06-21 2:15 UTC (permalink / raw)
To: git; +Cc: Dave O'Neill
Without this, all tags show up as 'unknown' time in gitweb (and probably
elsewhere)
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 7076f41..9526f3d 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -891,7 +891,7 @@ sub commit {
print $out ("object $cid\n".
"type commit\n".
"tag $dest\n".
- "tagger $committer_name <$committer_email> 0 +0000\n") and
+ "tagger $committer_name <$committer_email> $date +0000\n") and
close($out)
or die "Cannot create tag object $dest: $!\n";
--
1.5.2.2.239.g89630
^ permalink raw reply related
* [PATCH] Let git-svnimport clean up SVK commit messages.
From: Dave O'Neill @ 2007-06-21 2:14 UTC (permalink / raw)
To: git; +Cc: Dave O'Neill
SVK likes to begin all commit messages with a line of the format:
r12345@hostname: user | YYYY-MM-DD HH:MM:SS -ZZZZ
which makes the import desperately ugly in git. This adds a -k option to move
this extra SVK commit line to the end of the commit message, rather than
keeping it at the beginning.
---
Documentation/git-svnimport.txt | 6 +++++-
git-svnimport.perl | 18 +++++++++++++++---
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index e97d15e..23a54b0 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
[verse]
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
- [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
+ [ -C <GIT_repository> ] [ -i ] [ -k ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
@@ -68,6 +68,10 @@ When importing incrementally, you might need to edit the .git/svn2git file.
Prepend 'rX: ' to commit messages, where X is the imported
subversion revision.
+-k::
+ Remove SVK-style revision/commiter info from the top of commit
+ messages and move it to the bottom.
+
-I <ignorefile_name>::
Import the svn:ignore directory property to files with this
name in each directory. (The Subversion and GIT ignore
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..7076f41 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -32,20 +32,20 @@ $ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
$opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F,
- $opt_P,$opt_R);
+ $opt_P,$opt_R,$opt_k);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev] [-R repack_each_revs]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
- [-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
+ [-d|-D] [-i] [-k] [-u] [-r] [-I ignorefilename] [-s start_chg]
[-m] [-M regex] [-A author_file] [-S] [-F] [-P project_name] [SVN_URL]
END
exit(1);
}
-getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:R:uv") or usage();
+getopts("A:b:C:dDFhiI:kl:mM:o:rs:t:T:SP:R:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -835,7 +835,19 @@ sub commit {
$pw->writer();
$pr->reader();
+
+ if ( $opt_k ) {
+ # Remove SVK cruft in commit message
+ my ($svk_info) = $message =~ s{(r\d+\@[^:]+:\s+\S+\s+\|\s+\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}\s[\+-]\d{4})\s*}{};
+ if( $svk_info ) {
+ # and stick it on the end so we don't lose it
+ $message .= "\n$svk_info"
+ }
+ }
+
+
$message =~ s/[\s\n]+\z//;
+
$message = "r$revision: $message" if $opt_r;
print $pw "$message\n"
--
1.5.2.2.239.g89630
^ permalink raw reply related
* Re: [PATCH] Set correct date for tags.
From: Junio C Hamano @ 2007-06-21 2:52 UTC (permalink / raw)
To: Dave O'Neill; +Cc: git
In-Reply-To: <11823921031931-git-send-email-dmo@roaringpenguin.com>
I suspect (I haven't looked at the evolution history of these
import scripts) this was copied from git-cvsimport.perl. I
would prefer to fix it the same way as 5c08931, which looks like
this:
commit 5c08931dfc9fa0acbf8667581e4c98d643e66dbe
Author: Elvis Pranskevichus <el@prans.net>
Use git-tag in git-cvsimport
---
git-cvsimport.perl | 26 ++------------------------
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 4e6c9c6..524c9bb 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -771,31 +771,9 @@ sub commit {
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
$xtag =~ s/[\/]/$opt_s/g;
-
- my $pid = open2($in, $out, 'git-mktag');
- print $out "object $cid\n".
- "type commit\n".
- "tag $xtag\n".
- "tagger $author_name <$author_email>\n"
- or die "Cannot create tag object $xtag: $!\n";
- close($out)
- or die "Cannot create tag object $xtag: $!\n";
-
- my $tagobj = <$in>;
- chomp $tagobj;
-
- if ( !close($in) or waitpid($pid, 0) != $pid or
- $? != 0 or $tagobj !~ /^[0123456789abcdef]{40}$/ ) {
- die "Cannot create tag object $xtag: $!\n";
- }
-
-
- open(C,">$git_dir/refs/tags/$xtag")
+
+ system('git-tag', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
- print C "$tagobj\n"
- or die "Cannot write tag $xtag: $!\n";
- close(C)
- or die "Cannot write tag $xtag: $!\n";
print "Created tag '$xtag' on '$branch'\n" if $opt_v;
}
^ 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