* Re: [PATCH] Fix unterminated string in set_work_tree and improve error handling
From: Alex Riesen @ 2007-08-03 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <7v7iodqgg9.fsf@assigned-by-dhcp.cox.net>
On 8/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> I sense you haven't read my replacement patch (Dscho Acked it).
I did. I had to pay attention to what I read, though. Sorry.
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 7:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708022206130.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
> I finally broke down, waiting for the sourceforge project to get
> granted. In the meantime, I registered a project at
>
> http://code.google.com/p/msysgit/
>
> (WARNING: temporary only!)
>
> Would you believe that Google code has a restriction to 20MB per
> file, and 100MB in total, and you cannot remove files? The same
> Google that gives you 1TB mail space and counting? Yes, it is
> ludicrous.
>
> Anyway, you can get a complete Development environment in 3 files
> (because one would be too large), and... oh well, just read what is
> written on the website if you're really interested.
Great effort Johannes!
The package work perfectly on XP.
I'm trying to get it to work under Wine, but it (Wine) is not playing
nice with me at the moment. (The whole system barfs of "Access Denied"
and other things. Grrr)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-03 7:11 UTC (permalink / raw)
To: David Kastrup; +Cc: Robert Schiele, git
In-Reply-To: <857iodxyrc.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> ... For autoconf, it is fine to call sed (and you would probably not
> believe how small the portable language subset for sed is) all the
> time. Performance is not an issue. For normal user commands, this is
> different.
Wow, you made me recall a painful past for myself. AIX's sed
was so bad that I had to send in a few bugfixes to autoconf to
work it around. I do not know if I should feel happy to find
somebody to commiserate with...
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Steffen Prohaska @ 2007-08-03 7:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Michael Haggerty, Guilhem Bonnefille, git, users
In-Reply-To: <46a038f90708021608o21480074ybcfada767afc7b04@mail.gmail.com>
On Aug 3, 2007, at 1:08 AM, Martin Langhoff wrote:
> Is there any way we can run tweak cvs2svn to run incrementals, even if
> not as fast as cvsps/git-cvsimport? The "do it remotely" part can be
> worked around in most cases.
What I currently do with parsecvs is to run complete imports again
on the repo. For 'normal' changes to cvs the old import can be fast
forwarded to the new import. However, if you add or remove files or
tweak revision in another abnormal way (cvs admin) this might fail.
In this case I manually search the last common commit and rebase
new commits to the old, already imported branch. I need to do this if
I already publishes the imported branch. Otherwise I can as well just
reset to the newly imported branch and rebase my work on top of it.
Some careful validation (git diff-*) is included in my workflow.
A complete run of parsecvs is fine for me because it is so fast. I run
git-filter-branch afterwards anyway to cleanup some commit messages
and author information. This takes most of the time, because it spawns
off tons of sub processes.
I'd not recommend my approach for incremental imports every hour, but
you can run it every day (although I do less often). You only need to
validate the final result (fast forward or not). The rest can be fully
automated by some shell scripting.
Steffen
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 7:10 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Johannes Schindelin, git
In-Reply-To: <460B6BF8541C4D9B916F02A12E0576F5@ntdev.corp.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Dmitry Kakurin said the following on 03.08.2007 08:56:
> Great job! Because finding and installing MSys, MinGW and dependencies was not trivial at all.
> I have 2 suggestions for this package:
> 1. Remove git repository from it. It will make a download much smaller (~20MB smaller) and include the minimum git functionality to
> pull mingw git from the server (may be even automatically on first startup).
> 2. Add gdb. Not much could be done without it.
>
> With this package (+gdb) it took me about an hour to figure out why git is broken on Vista (this includes learning how to use gdb
> :-). So you should expect much higher level of participation on the Windows side.
>
> P.S. If package becomes sufficiently small for a single file, try to remove 7zip dependency (use WinZip instead). The easier the
> installation the better.
Heh, why don't you try to do this yourself? Johannes as kind enough to
go out of his way to actually do all that he has already.
Seems like you feel strongly for it, so it shouldn't be too much
effort for you. If you provide Johannes with a link to a package of
which you speak, I'm sure he'll happily upload it to the google
project page.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Jeff King @ 2007-08-03 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vy7gtvhgc.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:
> Personally, I almost never run "git status". The command is
> there primarily because other systems had a command called
> "status", and migrant wondered why we didn't. We do not need
> it, and we do not have to use it.
So what is the recommended command to summarize which files have been
modified, which files have been marked for commit, and which remain
untracked?
I find "git-diff --stat" totally insufficient for seeing the progress of
my work. How will it remind me that I have also previously git-added
some changes? They won't be mentioned at all, unless you are really
advocating "git-diff --stat HEAD". How will I be reminded that some
files from my work need to be git-added? git-diff won't mention
untracked files at all.
> You do not have to say, to the above paragraph, that it is
> different from your workflow. I am showing what the opmimum
> workflow would be, and it is up to you not to listen to me.
You are throwing the word "optimum" out here, but I have no idea what
you mean in this context. Optimum with respect to what criteria?
I know you are just trying to show your workflow, and that you
understand that others might have a different workflow. But you seem to
be implying that workflows using "git-status" are lesser for some
reason, and I really think it is a matter of taste.
-Peff
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Dmitry Kakurin @ 2007-08-03 6:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708022206130.14781@racer.site>
Great job! Because finding and installing MSys, MinGW and dependencies was not trivial at all.
I have 2 suggestions for this package:
1. Remove git repository from it. It will make a download much smaller (~20MB smaller) and include the minimum git functionality to
pull mingw git from the server (may be even automatically on first startup).
2. Add gdb. Not much could be done without it.
With this package (+gdb) it took me about an hour to figure out why git is broken on Vista (this includes learning how to use gdb
:-). So you should expect much higher level of participation on the Windows side.
P.S. If package becomes sufficiently small for a single file, try to remove 7zip dependency (use WinZip instead). The easier the
installation the better.
- Dmitry
----- Original Message -----
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Newsgroups: gmane.comp.version-control.git
To: <git@vger.kernel.org>
Sent: Thursday, 2 August 2007 14:23
Subject: Git on MSys (or how to make it easy for Windows users to compile git)
Hi,
I finally broke down, waiting for the sourceforge project to get granted.
In the meantime, I registered a project at
http://code.google.com/p/msysgit/
(WARNING: temporary only!)
Would you believe that Google code has a restriction to 20MB per file, and
100MB in total, and you cannot remove files? The same Google that gives
you 1TB mail space and counting? Yes, it is ludicrous.
Anyway, you can get a complete Development environment in 3 files (because
one would be too large), and... oh well, just read what is written on the
website if you're really interested.
The plan is to move to Source forget ;-) when they finally approve the
project, or stay with Google, should they decide to lift the quota a bit.
Dmitry already reported a buglet preventing gcc to run without changes on
Vista, his theory is that the infamous access() function is at fault. So
if you are unlucky enough to be stuck with Vista, just copy
msysGit/mingw/libexec/gcc/mingw32/3.4.2/cc1.exe to msysGit/mingw/bin/ and
you're set.
Ciao,
Dscho
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Steffen Prohaska @ 2007-08-03 6:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Martin Langhoff, Michael Haggerty, Guilhem Bonnefille, git, users
In-Reply-To: <Pine.LNX.4.64.0708030454200.14781@racer.site>
On Aug 3, 2007, at 6:03 AM, Johannes Schindelin wrote:
> On Fri, 3 Aug 2007, Martin Langhoff wrote:
>
>> On 8/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> cvsps is not a conversion tool at all, though it is used by other
>>> conversion tools to generate the changesets. It appears (I hope
>>> I am
>>> not misinterpreting things) to emphasize speed and incremental
>>> operation, for example attempting to make changesets consistent
>>> from one
>>> run to the next, even if the CVS repository has been changed
>>> prudently
>>> between runs. cvsps does not appear to attempt to create atomic
>>> branch
>>> and tag creation commits or handle CVS's special vendorbranch
>>> behavior.
>>> cvsps operates via the CVS protocol; you don't need filesystem
>>> access
>>> to the CVS repository.
>>
>> 100% in agreement. And though I can't claim to be happy with
>> cvsps, in
>> many scenarios it is mighty useful, in spite of its significant
>> warts.
>> The "does incrementals" is hugely important these days, as lots of
>> people use git to run "vendor branches" of upstream projects that use
>> CVS.
>
> Me too: 100% agreement. A couple of people seem to be content to
> proclaim
> that their incomplete solutions are better, but in the end of the day,
> they are as bad as the programs they purport to replace: incomplete.
>
> For the moment, I help myself with tracking the different branches
> individually, but there, really, git-cvsimport is as good as the other
> "solutions", with the further advantage that they are actually
> hackable,
> and not closed to everybody outside a very small community.
I just want to add a warning. You should be suspicious of branched
imported
using git-cvsimport (which is based on cvsps). If the time the branch is
created differs from the time of the first commit to the branch git-
cvsimport
may get the branching point wrong. This introduces a race condition.
Someone
may have committed changes to a file that is later changed on the
branch. At
that point the history of the imported branch is broken and git reports
_wrong_ changesets.
I ran into this issue and abandoned the use of git-cvsimport. It's
too dangerous
for me. The testcase in [1] illustrates the problem. I still strongly
believe
the warning should be stated in *BOLD* in the documentation.
I'm not saying git-cvsimport is useless. But you should be suspicious
about
the result of the import, especially if you plan to rely on
changesets derived
from the imported repo, for example if you plan to do cherry-picking
or merging
in git; or if you plan to blame people for their stupid changes based
on what
you see in gitk (almost happend to me ;).
Steffen
[1] http://marc.info/?l=git&m=118260312708709&w=2
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-03 6:30 UTC (permalink / raw)
To: Steven Grimm
Cc: Johannes Schindelin, Jean-Fran?ois Veillette, Matthieu Moy, git
In-Reply-To: <20070803053717.GA16379@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Okay, enough arguing about whether the empty diff lines are
> useful or not -- here's a patch to get rid of them.
I do not think this addresses anything but -p (i.e. textual
diff) output. If we _were_ to really do this, I think the patch
I sent earlier today, with possible improvements I suggested,
would be a better direction to go.
^ permalink raw reply
* Re: [PATCH] Fix unterminated string in set_work_tree and improve error handling
From: Junio C Hamano @ 2007-08-03 6:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <81b0412b0708022247s1116f66al1e8751f33bcae581@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
>> >> Consolidating two of your patches, would this be Ok?
>> >
>> > Yes, but you may consider replacing strncpy with strlcpy:
>> >
>> >> + memcpy(dir_buffer, dir, len - suffix_len);
>> >> + dir_buffer[len - suffix_len] = '\0';
>> >
>> > strlcpy(dir_buffer, dir, len - suffix_len + 1);
>>
>> Does that buy us that much? Before going to that codepath, we
>> have made sure the result fits, haven't we?
I sense you haven't read my replacement patch (Dscho Acked it).
I am talking about this part:
+ if (len > suffix_len &&
+ !strcmp(dir + len - suffix_len, "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
+ if ((len - suffix_len) >= sizeof(dir_buffer))
+ die("directory name too long");
+ memcpy(dir_buffer, dir, len - suffix_len);
+ dir_buffer[len - suffix_len] = '\0';
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: David Kastrup @ 2007-08-03 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3az1samx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * With -l, as long as the source repository is healthy, it is
>>> very likely that the recipient would be, too. Also it is
>>> very cheap. You do not get any back-up benefit.
>>
>> Oh, but one does: an overzealous prune or rm -oopswrongoption in one
>> repo does not hurt the other.
>
> That's not "back-up" benefit I was thinking about. It is more
> about protecting your data from hardware failure. You
> physically have bits in two places, preferrably on separate disk
> drives.
>
> And that is what you do not get from hardlinked clone.
Not at the inode/blob level, but at least the directory manipulations
of one are safe from the other.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7vabt9sasl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> (1) that shell does not even grok $(cmd) substitution.
>
> I won't accept a half-baked patch that replaces "$(" with a
> backtick and matching ")" with another backtick. You need
> to at least make sure your interpolated variables within
> the backtick pair work sensibly, and you haven't broken
> existing nesting of command interpolations, if any. I do
> not even want to inspect, comment on and reject that kind
> of changes. Quite frankly, it's not worth my time.
And that's actually not even _half_ of the deal: we are talking about
pandering to legacy shells here, and the amount of variance of just
what level of quoting/backslashing is needed on the inside of `...` in
order to get stuff through with just the right level of quoting is
actually stunning.
I've had my fair share of bad surprises with portable scripts.
Getting a backquote mechanism running on one shell does not mean it
will work on another. Basically, you have to forego nesting stuff and
split it out into small units in separate commands.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 6:08 UTC (permalink / raw)
To: Robert Schiele; +Cc: Junio C Hamano, git
In-Reply-To: <20070803022828.GY29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> On Fri, Aug 03, 2007 at 02:24:38AM +0200, David Kastrup wrote:
>> The situation is that we currently don't avoid the former. Robert
>> said that he had prepared a patch that would do so.
>>
>> It would make sense to either encourage him to present his patch
>
> Well, if you want to see it, just tell me. Do you want to have it with or
> without the arithmetic replacements I did as well?
>From Junio's answer, I gather that indeed this would seem pointless.
$(...) is not going away anytime soon, and I have seen no evidence
that there is a shell in widespread use that supports it, but doesn't
support ${...#...}.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7vabt9sasl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>>> I happen to feel ${parameter#word} is more esoteric than $(cmd).
>>> If a system does not even do the latter, then avoiding the
>>> former to help such a system is a futile effort.
>>
>> The situation is that we currently don't avoid the former. Robert
>> said that he had prepared a patch that would do so.
>> ...
>> But "only a little bit of ${parameter#word}, please" seems pointless.
>
> Absolutely. And we started to adopt #/% substititions some time
> ago. Undoing them just feels going backwards, and we need to judge
> what the merits of going backwards are.
Ok, seems like the sort of cleanups I proposed would not clash with
current git policies. I'll readily agree that the timing of their
adoption might not really fit with a rc4, but posting them for the
queue does not seem outrageous.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] GPG Signing of Commits
From: Alex Riesen @ 2007-08-03 5:52 UTC (permalink / raw)
To: David Soria; +Cc: git
In-Reply-To: <f8tl14$o4r$1@sea.gmane.org>
On 8/3/07, David Soria <sn_@gmx.net> wrote:
> Hi list,
>
> i personally like the feature of signing commit messages using GPG. What
> do you think about the patch? It's just the mechanism taken from git-tag.
> Would be good not just have validation for tags, but for commits.
Where do you verify them? Where do you *propose* to verify them?
^ permalink raw reply
* [PATCH] Fix unterminated string in set_work_tree and improve error handling
From: Alex Riesen @ 2007-08-03 5:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Schindelin
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
Also, check if it fits in the temporary dir_buffer and can be chdir-ed into.
Die for errors.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
setup.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
On 8/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Junio C Hamano, Thu, Aug 02, 2007 23:58:41 +0200:
> >> "Alex Riesen" <raa.lkml@gmail.com> writes:
> >> > + if (chdir(dir))
> >> > + rel = NULL;
> > ...
> >>
> >> Shouldn't it die() instead, though?
> >
> > Dunno. Don't like dying.
>
> I do not understand your reasoning. Why is it better to use
> mysteriously truncated path, which may result in doing something
> the user did not ask you to, rather than saying "No, my
> temporary buffer is not equipped to handle such an insanely long
> pathname"?
AFAIU, it is not only a truncated path which is a problem for chdir,
but any failure to chdir, for any reason. And, if I understand
set_work_tree returning NULL correctly (I assign rel NULL,
which should be returned) - it is an error, and can be handled in
the caller. But...
Hmm... Looking at the code again, rel==NULL just means there
is no prefix! You're right, better let it die.
> >> Consolidating two of your patches, would this be Ok?
> >
> > Yes, but you may consider replacing strncpy with strlcpy:
> >
> >> + memcpy(dir_buffer, dir, len - suffix_len);
> >> + dir_buffer[len - suffix_len] = '\0';
> >
> > strlcpy(dir_buffer, dir, len - suffix_len + 1);
>
> Does that buy us that much? Before going to that codepath, we
> have made sure the result fits, haven't we?
No, we haven't. The code just checks if the given work tree path
is longer than "/.git", to be able to cut off that safely.
[-- Attachment #2: 0001-Check-if-the-given-dir-fits-in-the-temporary-dir_buffe.txt --]
[-- Type: text/plain, Size: 1604 bytes --]
From 7e55d4ed84e5867b217c9e0bc1964444f13eaef2 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 3 Aug 2007 07:41:26 +0200
Subject: [PATCH] Fix unterminated string in set_work_tree and improve error handling
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
setup.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 3653092..6006fc5 100644
--- a/setup.c
+++ b/setup.c
@@ -201,15 +201,18 @@ int is_inside_work_tree(void)
*/
const char *set_work_tree(const char *dir)
{
- char dir_buffer[PATH_MAX];
- static char buffer[PATH_MAX + 1], *rel = NULL;
+ char dir_buffer[PATH_MAX], *rel = NULL;
+ static char buffer[PATH_MAX + 1];
int len, postfix_len = strlen(DEFAULT_GIT_DIR_ENVIRONMENT) + 1;
/* strip the variable 'dir' of the postfix "/.git" if it has it */
len = strlen(dir);
if (len > postfix_len && !strcmp(dir + len - postfix_len,
"/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
- strncpy(dir_buffer, dir, len - postfix_len);
+ if (len - postfix_len < sizeof(dir_buffer))
+ strlcpy(dir_buffer, dir, len - postfix_len + 1);
+ else
+ die("%s is too long", dir);
/* are we inside the default work tree? */
rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
@@ -219,7 +222,8 @@ const char *set_work_tree(const char *dir)
if (!is_absolute_path(dir))
set_git_dir(make_absolute_path(dir));
dir = dir_buffer;
- chdir(dir);
+ if (chdir(dir))
+ die("cannot chdir to %s: %s", dir, strerror(errno));
strcat(rel, "/");
inside_git_dir = 0;
} else {
--
1.5.3.rc3.145.g4d9cdb
^ permalink raw reply related
* [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Steven Grimm @ 2007-08-03 5:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jean-Fran?ois Veillette, Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021614420.14781@racer.site>
The default is now to not show the diff --git header line if the file's
timestamp has changed but the contents and/or file mode haven't.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Okay, enough arguing about whether the empty diff lines are
useful or not -- here's a patch to get rid of them.
This passes all the existing "diff" tests, with one minor tweak
to the symlink test (since it expected the old behavior.)
If someone can find a case where this will spit out an actual
diff but not the "diff --git" line, please tell me how to make
that happen. The code *looks* like it has such a path, but I was
unable to make it happen in my ad-hoc testing and it doesn't
happen in any of the existing diff test cases.
Personally I'm in favor of doing away with the option altogether
and having the code always work the way it works by default with
this patch, but if some people find the old behavior useful they
can still get at it with the new option.
My xmalloc() call allocates a few more bytes than strictly
needed, but I found it was less readable to subtract out the
space taken by the "%s" tokens in the format string.
Documentation/diff-options.txt | 4 ++
diff.c | 46 ++++++++++++++++++++++++++----
diff.h | 3 +-
t/t4011-diff-symlink.sh | 2 +-
t/t4021-diff-untouched.sh | 61 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 108 insertions(+), 8 deletions(-)
create mode 100755 t/t4021-diff-untouched.sh
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 228ccaf..12ad048 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -185,5 +185,9 @@
--no-ext-diff::
Disallow external diff drivers.
+--show-touched::
+ Display the "diff --git" message for files whose modification
+ timestamps have changed, even if the contents don't differ.
+
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
diff --git a/diff.c b/diff.c
index a5fc56b..e1112e5 100644
--- a/diff.c
+++ b/diff.c
@@ -1260,6 +1260,9 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
return NULL;
}
+/* The message that gets printed at the top of a file's diffs */
+#define DIFF_MESSAGE_FORMAT_STRING "%sdiff --git %s %s%s\n"
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -1268,6 +1271,7 @@ static void builtin_diff(const char *name_a,
struct diff_options *o,
int complete_rewrite)
{
+ char *diff_message;
mmfile_t mf1, mf2;
const char *lbl[2];
char *a_one, *b_two;
@@ -1278,25 +1282,50 @@ static void builtin_diff(const char *name_a,
b_two = quote_two("b/", name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
- printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
+
+ /*
+ * Generate the "diff --git" status message. By default we only
+ * show it if we have a difference to display, but the user can
+ * optionally choose to show it for all files that we examine for
+ * content differences (e.g. because their timestamps have changed.)
+ */
+ diff_message = xmalloc(strlen(set) + strlen(reset) +
+ strlen(a_one) + strlen(b_two) +
+ sizeof(DIFF_MESSAGE_FORMAT_STRING));
+ sprintf(diff_message, DIFF_MESSAGE_FORMAT_STRING,
+ set, a_one, b_two, reset);
+ if (o->show_touched) {
+ fputs(diff_message, stdout);
+ *diff_message = '\0';
+ }
+
if (lbl[0][0] == '/') {
/* /dev/null */
- printf("%snew file mode %06o%s\n", set, two->mode, reset);
+ printf("%s%snew file mode %06o%s\n",
+ diff_message, set, two->mode, reset);
+ *diff_message = '\0';
if (xfrm_msg && xfrm_msg[0])
printf("%s%s%s\n", set, xfrm_msg, reset);
}
else if (lbl[1][0] == '/') {
- printf("%sdeleted file mode %06o%s\n", set, one->mode, reset);
+ printf("%s%sdeleted file mode %06o%s\n",
+ diff_message, set, one->mode, reset);
+ *diff_message = '\0';
if (xfrm_msg && xfrm_msg[0])
printf("%s%s%s\n", set, xfrm_msg, reset);
}
else {
if (one->mode != two->mode) {
- printf("%sold mode %06o%s\n", set, one->mode, reset);
+ printf("%s%sold mode %06o%s\n",
+ diff_message, set, one->mode, reset);
printf("%snew mode %06o%s\n", set, two->mode, reset);
+ *diff_message = '\0';
+ }
+ if (xfrm_msg && xfrm_msg[0]) {
+ printf("%s%s%s%s\n",
+ diff_message, set, xfrm_msg, reset);
+ *diff_message = '\0';
}
- if (xfrm_msg && xfrm_msg[0])
- printf("%s%s%s\n", set, xfrm_msg, reset);
/*
* we do not run diff between different kind
* of objects.
@@ -1304,6 +1333,8 @@ static void builtin_diff(const char *name_a,
if ((one->mode ^ two->mode) & S_IFMT)
goto free_ab_and_return;
if (complete_rewrite) {
+ fputs(diff_message, stdout);
+ *diff_message = '\0';
emit_rewrite_diff(name_a, name_b, one, two,
o->color_diff);
o->found_changes = 1;
@@ -1372,6 +1403,7 @@ static void builtin_diff(const char *name_a,
diff_free_filespec_data(two);
free(a_one);
free(b_two);
+ free(diff_message);
return;
}
@@ -2381,6 +2413,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->allow_external = 1;
else if (!strcmp(arg, "--no-ext-diff"))
options->allow_external = 0;
+ else if (!strcmp(arg, "--show-touched"))
+ options->show_touched = 1;
else
return 0;
return 1;
diff --git a/diff.h b/diff.h
index 9fd6d44..e172ecf 100644
--- a/diff.h
+++ b/diff.h
@@ -61,7 +61,8 @@ struct diff_options {
has_changes:1,
quiet:1,
allow_external:1,
- exit_with_status:1;
+ exit_with_status:1,
+ show_touched:1;
int context;
int break_opt;
int detect_rename;
diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index c6d1369..910c6cc 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh
@@ -60,7 +60,7 @@ test_expect_success \
'diff identical, but newly created symlink' \
'sleep 3 &&
ln -s xyzzy frotz &&
- git diff-index -M -p $tree > current &&
+ git diff-index --show-touched -M -p $tree > current &&
compare_diff_patch current expected'
cat > expected << EOF
diff --git a/t/t4021-diff-untouched.sh b/t/t4021-diff-untouched.sh
new file mode 100755
index 0000000..a8153e0
--- /dev/null
+++ b/t/t4021-diff-untouched.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Test display and suppression of unmodified files.
+
+'
+. ./test-lib.sh
+. ../diff-lib.sh
+
+touch empty
+
+test_expect_success 'no output when no changes' '
+
+ echo foobar > file1 &&
+ chmod 644 file1 &&
+ git add file1 &&
+ git commit -m "initial commit" &&
+ git diff > current &&
+ compare_diff_patch current empty
+'
+
+test_expect_success 'no output when file touched' '
+
+ sleep 1 &&
+ touch file1 &&
+ git diff > current &&
+ compare_diff_patch current empty
+'
+
+cat > expected << EOF
+diff --git a/file1 b/file1
+EOF
+
+test_expect_success 'output when --show-touched is used' '
+
+ git diff --show-touched > current &&
+ compare_diff_patch current expected
+'
+
+test_expect_success 'no output when index updated with touched file' '
+
+ git add file1 &&
+ git diff --cached > current &&
+ compare_diff_patch current empty
+'
+
+cat > expected << EOF
+diff --git a/file1 b/file1
+old mode 100644
+new mode 100755
+EOF
+
+test_expect_success 'output when mode is changed' '
+
+ chmod 755 file1 &&
+ git diff > current &&
+ compare_diff_patch current expected
+'
+test_done
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-03 5:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070802223132.GA15212@fieldses.org>
On Aug 3, 2007, at 12:31 AM, J. Bruce Fields wrote:
>>> Also, I like the verb "stage" as a way to explain the part of the
>>> index
>>> file in creating commits, but I've been consistently using the word
>>> "index" throughout the user manual, and I think that's consistent
>>> with
>>> the rest of the documentation--so don't avoid it here.
>>
>> "staging/unstaging" is how git gui calls adding/removing files to and
>> from the index.
>
> I understand what you meant, but a reader of the user manual at this
> point might not, since it's been consistently saying things like
> "to add
> the contents of a new file to the index, use git add". So we
> should use
> the same language here. Unless we want to update the whole thing
> to use
> "stage" and "unstage". I'd rather not.
Agree. But we could briefly introduce git gui's dialect, something like
"git gui lets you select files (use menu 'Commit > Stage to Commit') or
individually diff hunks (use 'Stage Hunk For Commit' in context menu of
diff view) for inclusion in the index."
Steffen
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Johannes Schindelin @ 2007-08-03 4:03 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Michael Haggerty, Guilhem Bonnefille, git, users
In-Reply-To: <46a038f90708021608o21480074ybcfada767afc7b04@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Martin Langhoff wrote:
> On 8/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> > cvsps is not a conversion tool at all, though it is used by other
> > conversion tools to generate the changesets. It appears (I hope I am
> > not misinterpreting things) to emphasize speed and incremental
> > operation, for example attempting to make changesets consistent from one
> > run to the next, even if the CVS repository has been changed prudently
> > between runs. cvsps does not appear to attempt to create atomic branch
> > and tag creation commits or handle CVS's special vendorbranch behavior.
> > cvsps operates via the CVS protocol; you don't need filesystem access
> > to the CVS repository.
>
> 100% in agreement. And though I can't claim to be happy with cvsps, in
> many scenarios it is mighty useful, in spite of its significant warts.
> The "does incrementals" is hugely important these days, as lots of
> people use git to run "vendor branches" of upstream projects that use
> CVS.
Me too: 100% agreement. A couple of people seem to be content to proclaim
that their incomplete solutions are better, but in the end of the day,
they are as bad as the programs they purport to replace: incomplete.
For the moment, I help myself with tracking the different branches
individually, but there, really, git-cvsimport is as good as the other
"solutions", with the further advantage that they are actually hackable,
and not closed to everybody outside a very small community.
So I look forward to testing cvs2svn(git-branch) this weekend.
Ciao,
Dscho
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Shawn O. Pearce @ 2007-08-03 3:12 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Linus Torvalds, Steffen Prohaska, git, users
In-Reply-To: <46B26686.3010002@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 1. The helper branches should be deleted after the tag has been defined.
> I simply couldn't figure out how to do this using git-fast-import, and
> git-fast-import complained when I tried to use a branch called
> "TAG_FIXUP" without the "refs/head/" prefix.
Two issues there:
* Deleting branches:
I currently don't support this in fast-import, but I'll add support
for it. Its actually pretty simple to tell it to drop a branch,
especially if the dang thing doesn't actually exist in the git
repository yet (because its only in-memory).
* Creating a branch without refs/heads/ prefix:
This is a bug. I had good intentions by trying to verify the
name was one that didn't contain special reserved characters,
but I wound up also requiring you to create branches only in the
refs/heads/ namespace. That was not what I wanted to do. I'm
patching it tonight.
--
Shawn.
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Shawn O. Pearce @ 2007-08-03 3:07 UTC (permalink / raw)
To: Simon 'corecode' Schubert
Cc: Steffen Prohaska, Michael Haggerty, git, users
In-Reply-To: <46B2309E.3060804@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> Steffen Prohaska wrote:
> >I remember that togit reported a broken pipe. My feeling was
> >that git-fastimport aborted, which may be reason why tohg
> >worked better.
>
> yah, that pretty much tells me it is shawn's bug :) but without more
> details, it is very hard to diagnose. tohg should tell you which rcs revs
> are the offenders. be sure to use a recent fromcvs however.
Tonight I'm going to try and add crash dump reporting to fast-import.
Once that's in it should make debugging some of these failed imports
easier, as we'll be able to see the immediate commands leading up
to the crash and the internal state of fast-import when it barfed.
Of course one needs to locate an ugly repository and run on it...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-08-03 3:04 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Steffen Prohaska, git
In-Reply-To: <20070802181853.GB31885@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> > +Beyond the basic operation of staging and unstaging complete files,
> > +git gui can also selectively stage diff hunks. You can do so by
...
>
> I wonder whether we could get away with just the brief list of features
> ("lets you view changes in the index and the working file, lets you
> individually select diff hunks for inclusion in the index"), and leave
> the how-to stuff to online guit-gui help, if it's necessary?
Online help? In git-gui? :-)
We don't have an online help system yet. Basically no documentation
has been written for git-gui. No thought has been put into how one
should be organized, maintained, or displayed to the poor human
who is just trying to learn more about Git and this gui thing it
came with.
Yes, Help->Online Documentation is abvailable to most users, but
that just opens your web browser (if it can find one) and points
it to kernel.org's git manual. Not exactly the best material for
learning more about git-gui itself.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-08-03 3:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: J. Bruce Fields, git
In-Reply-To: <107BD473-E055-47D0-9720-9D878BDAB954@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> Maybe, this would be sufficient. I mentioned the pop-up explicitly
> because it wasn't obvious to me right away. The reason might be that
> my brain adjusted too much to the Mac I'm using. Right-clicking and
> pop-ups are rarely used on Macs as the only access point to essential
> features, such as selectively staging diff hunks. Typically an icon
> or menu entry guides you explicitly to every feature. Pop-ups are only
> used for 'optimized' access but never as the only access point.
Steffen, you seem to be more in-tune with the Mac UI standards
than I am. Any suggestions on what I can do in git-gui to make
this feature more obvious to users?
I myself use a Mac OS X based PowerBook as my primary development
system, but I have to admit, I'm not the best GUI developer that has
ever walked on this planet. Far far far from it. I get by, if that.
The fact that git-gui is even usable by mortals is a minor miracle.
So I'd really love to do better. But frankly I'm at a loss here
and just don't know what sort of change to make.
Side note: Someone recently asked me how to move individual files
to the left side of the UI (to stage them). Apparently this person
had been using git-gui for months by just clicking "Add Existing"
(recently renamed to "Stage Changed"). It never occurred to the
user to try clicking the file's individual icons. Or to select
the files they were interested in and look for a menu option that
might work on that selection.
--
Shawn.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-03 2:28 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85wswdwjll.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Fri, Aug 03, 2007 at 02:24:38AM +0200, David Kastrup wrote:
> The situation is that we currently don't avoid the former. Robert
> said that he had prepared a patch that would do so.
>
> It would make sense to either encourage him to present his patch
Well, if you want to see it, just tell me. Do you want to have it with or
without the arithmetic replacements I did as well?
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitweb: Provide RSS feeds for file history
From: Steven Walter @ 2007-08-03 2:05 UTC (permalink / raw)
To: git; +Cc: jnareb
If git_feed is provided a file name, it ought to show only the history
affecting that file. The title was already being set correctly, but all
commits from history were being shown anyway.
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 498b936..26932a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -611,6 +611,7 @@ sub href(%) {
my %mapping = @mapping;
$params{'project'} = $project unless exists $params{'project'};
+ $params{'file_name'} = $file_name unless exists $params{'file_name'};
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
@@ -5365,7 +5366,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch, history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150);
+ my @commitlist = parse_commits($head, 150, 0, "--full-history", $file_name);
my %latest_commit;
my %latest_date;
--
1.5.2.3
--
-Steven Walter <swalter@lexmark.com>
^ 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