* [zooko@zooko.com: [Revctrl] colliding md5 hashes of human-meaningful documents]
From: Petr Baudis @ 2005-06-12 8:25 UTC (permalink / raw)
To: git; +Cc: torvalds
----- Forwarded message from zooko@zooko.com -----
There is nothing theoretically surprising about this, but hopefully its
concreteness and the accompanying scenario will make an impression on people
on people. The same technique should work to generate two documents with
identical SHA1 hashes.
http://www.cits.rub.de/MD5Collisions/
----- End forwarded message -----
I expected the two postscript files differing in some huge binary blob,
but it turns out the binary part is very small (about 256 bytes) and
only few (about nine) bytes are different, contrary to how people have
predicted the collisions. This is much more close to finding a collision
between similar pure C files, I think. Rather unsettling.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* git-whatchanged doesn't display date human understandable
From: Thomas Glanzmann @ 2005-06-12 9:34 UTC (permalink / raw)
To: GIT
Hello,
what option to I have to tweak to get timestamps human understandable
again:
git-whatchanged | head -5
diff-tree 422dee18f8b39b4c14332afbdf75a5c519bdbed2 (from 16df05aa0464e5e17d4ef023b78bc7b98546cb9a)
tree 2ed70720e7103ae700a9dceac55c77d562057467
parent 16df05aa0464e5e17d4ef023b78bc7b98546cb9a
author vrsieh <vrsieh> 1082362048 +0000
committer vrsieh <vrsieh> 1082362048 +0000
~~~~~~~~~~~~~~~~
This seems to happen with Linus git tree HEAD.
Thomas
^ permalink raw reply
* [PATCH] cg-Xlib: make showdate show timezone
From: Dan Holmsand @ 2005-06-12 11:40 UTC (permalink / raw)
To: Git Mailing List; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
This makes timezones show up again in showdate's default
format. Hopefully, this also makes showdate a little more
portable.
It also speeds things up a little, by avoiding an extra fork.
Signed-off-by: Dan Holmsand <holmsand@gmail.com>
---
[-- Attachment #2: showdate.patch.txt --]
[-- Type: text/plain, Size: 777 bytes --]
cg-Xlib | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -68,14 +68,12 @@ showdate () {
# bash doesn't like leading zeros
[ "${tzhours:1:1}" = 0 ] && tzhours=${2:0:1}${2:2:1}
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
+ [ "$format" ] || format="+%a, %d %b %Y %H:%M:%S $2"
if [ "$has_gnudate" ]; then
- [ "$format" ] || format=-R
- pdate=$(date -ud "1970-01-01 UTC + $secs sec" "$format")
+ LANG=C date -ud "1970-01-01 UTC + $secs sec" "$format"
else
- [ "$format" ] || format=--
- pdate=$(date -u -r $secs "$format")
+ LANG=C date -u -r $secs "$format"
fi
- echo "${pdate/+0000/$tz}"
}
# Usage: tree_timewarp [--no-head-update] DIRECTION_STR ROLLBACK_BOOL BASE BRANCH
^ permalink raw reply
* Re: [PATCH] cg-Xlib: make showdate show timezone
From: Petr Baudis @ 2005-06-12 11:52 UTC (permalink / raw)
To: Dan Holmsand; +Cc: Git Mailing List
In-Reply-To: <42AC1F49.9010808@gmail.com>
Dear diary, on Sun, Jun 12, 2005 at 01:40:57PM CEST, I got a letter
where Dan Holmsand <holmsand@gmail.com> told me that...
> This makes timezones show up again in showdate's default
> format. Hopefully, this also makes showdate a little more
> portable.
>
> It also speeds things up a little, by avoiding an extra fork.
>
> Signed-off-by: Dan Holmsand <holmsand@gmail.com>
Thanks, applied. But what's the point of calling date with LANG=C? If
the user wants his locale to get used, why prevent him?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [OT] mutually supervised developers
From: David Roundy @ 2005-06-12 11:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Petr Baudis, darcs-devel
In-Reply-To: <Pine.LNX.4.58.0506111612140.2286@ppc970.osdl.org>
On Sat, Jun 11, 2005 at 04:14:38PM -0700, Linus Torvalds wrote:
> On Sat, 11 Jun 2005, Junio C Hamano wrote:
> >
> > I am wondering if the world would be a better place if this
> > fictitious project sets up public repositories in the following
> > way:
> >
> > (1) each developer's own repository is public;
> >
> > (2) these developers pull from each other "only good stuff",
> > rejecting things he or she feels questionable. Let's
> > forget that current GIT does not give a direct support for
> > cherrypicking for now.
> >
> > (3) the public canonical repository is updated to contain the
> > intersection (_not_ union) of these developer repositories.
> > Let's also forget that current GIT does not have automated
> > way to do such a thing.
>
> I've thought about it, but one problem ends up being the history.
>
> Even if both developers have the same patches, they may not have gotten
> them in the same order, which means that it's basically impossible to
> retain history when doign an intersection. Unions are different - we can
> just add the new history when we create a union.
Right, cherry picking and history don't go well together--which is why
darcs doesn't normally store a real history (although it can do so--you
just can't keep certain portions of the history unless you accept the
patches involved).
There are also issues in defining the intersection of all patches. Ideally
if you take the union of that intersection with one of the original
repositories, you'd get that same repository back, but most naive
implementations of union/intersection won't have that property, which would
lead to confusion and inconvenience.
This sort of workflow would actually be pretty easy to implement in darcs,
if someone were interested.
On Sat, 11 Jun 2005, Junio C Hamano wrote:
> Would people find something like this arrangement workable and
> worthwhile?
I think the biggest issue would be the one mentioned about the problems
with a single lazy developer. But I think rather than some sort of
majority rule (or "if three developers think it's okay, then it's okay"),
keeping the number of relevant developers down would make sense. This also
makes sense in that unless you've got seriously dedicated developers, you
don't want to force everyone to read every patch. I think if you went with
a system like this and wanted many maintainers involved, it would probably
best to organize things hierarchically.
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: [zooko@zooko.com: [Revctrl] colliding md5 hashes of human-meaningful documents]
From: Morten Welinder @ 2005-06-12 13:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050612082555.GB6620@pasky.ji.cz>
I looked at this.
If you can find just *one* colliding pair that does not contain a
few select bytes like 0x22 (quote), 0x5c (backslash) and
perhaps 0x0a then it is trivial to make a colliding pair of
C programs.
Call the initial pair (A,B) and make the programs
/* Common prefix that happens to have integer block size
ending just before the A below. */
const char junk[] = "AB";
/* "AA" in program 1, "AB" in program 2. */
...
int
main ()
{
int hsize = sizeof (junk) / 2;
if (memcmp (junk, junk + hsize, hsize))
return do_program_2 ();
else
return do_program_1 ();
}
^ permalink raw reply
* qgit-0.5
From: Marco Costalba @ 2005-06-12 13:35 UTC (permalink / raw)
To: git
Here is qgit-0.5, a git GUI viewer
New in this version:
- selection of diff target: parent (default), HEAD or a choosen SHA;
SHA to diff with can be inserted manually, with copy/paste or
directly selected with CTRL + MOUSE PRESS on the log viewer (see screenshots)
- yellow background on tags in log viewer
- alternate background color in log viewer
- thanks to Stanislav Karchebny scons build problems should be
resolved now
You can download from
http://prdownloads.sourceforge.net/qgit/qgit-0.5.tar.bz2?download
To try qgit:
1) Unpack downloaded file
2) make
3) cd bin
4) copy qgit bin file anywhere in your path
Tip: try to browse file history with diff viewer open (screenshot below)
http://sourceforge.net/project/screenshots.php?group_id=139897
There are also some (new) screenshots:
http://sourceforge.net/project/screenshots.php?group_id=139897&ssid=13699
http://sourceforge.net/project/screenshots.php?group_id=139897&ssid=13695
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: reducing line crossings in gitk
From: Matthias Urlichs @ 2005-06-12 14:30 UTC (permalink / raw)
To: git
In-Reply-To: <17066.53047.660907.453399@cargo.ozlabs.ibm.com>
Hi, Paul Mackerras wrote:
> I could add a heuristic to look for this case and reverse the order of
> the parents, which would reduce the line crossings and make the graph
> look neater. Would this be worth the slight loss of information (in
> that the stuff pulled in would no longer always be to the right)?
Yes.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
All interesting actions are overdetermined. -- Arthur D. Hlavaty
^ permalink raw reply
* Re: [zooko@zooko.com: [Revctrl] colliding md5 hashes of human-meaningful documents]
From: Martin Uecker @ 2005-06-12 14:53 UTC (permalink / raw)
To: git; +Cc: zooko
In-Reply-To: <20050612082555.GB6620@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
On Sun, Jun 12, 2005 at 10:25:55AM +0200, Petr Baudis wrote:
> ----- Forwarded message from zooko@zooko.com -----
>
> There is nothing theoretically surprising about this, but hopefully its
> concreteness and the accompanying scenario will make an impression on people
> on people. The same technique should work to generate two documents with
> identical SHA1 hashes.
>
> http://www.cits.rub.de/MD5Collisions/
>
> ----- End forwarded message -----
>
> I expected the two postscript files differing in some huge binary blob,
> but it turns out the binary part is very small (about 256 bytes) and
> only few (about nine) bytes are different, contrary to how people have
> predicted the collisions. This is much more close to finding a collision
> between similar pure C files, I think. Rather unsettling.
>
This attack scenario doesn't demonstrate the danger of hash
collisions but the danger of signing documents you do not
understand. The same technique works exactly in the same way
with postscript files which are actually identical but produce
different output under different conditions (time, fonts
installed on the printer whatever).
Never sign anything but plain text or documents which are
created in a controlled way and avoid signing documents
you did not create yourself.
Martin
--
One night, when little Giana from Milano was fast asleep,
she had a strange dream.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* cogito and tags propagation
From: Jon Smirl @ 2005-06-12 15:50 UTC (permalink / raw)
To: git
If I add a tag to tree A, then go to tree B which depends on A and do
cg update. It says the branch is already fully merged. It's not
counting the addition of a tag as something that marks the tree dirty.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] apply.c: tolerate diff from a dirty but unchanged path
From: Linus Torvalds @ 2005-06-12 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vpsusqxsy.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 11 Jun 2005, Junio C Hamano wrote:
>
> Here is a proposed fix.
This is wrong. It will make us reject all patches that don't end the magic
sequence of "@@ -", ie it will make us reject pure renames etc.
I'll fix it up,
Linus
^ permalink raw reply
* Re: [zooko@zooko.com: [Revctrl] colliding md5 hashes of human-meaningful documents]
From: Linus Torvalds @ 2005-06-12 17:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050612082555.GB6620@pasky.ji.cz>
On Sun, 12 Jun 2005, Petr Baudis wrote:
>
> I expected the two postscript files differing in some huge binary blob,
> but it turns out the binary part is very small (about 256 bytes) and
> only few (about nine) bytes are different, contrary to how people have
> predicted the collisions. This is much more close to finding a collision
> between similar pure C files, I think. Rather unsettling.
This is not close at all. The "small" binary blob (256 bytes) only encodes
one single bit of information.
In other words, they've really changed _one_ bit of information by doing a
256-byte random binary blob. Anybody who calls that "small" didn't really
look closely.
Is it clever? Yes. But it isn't about making one C file look like another,
it's using the property of controlling _both_ of the files, and making
them contain all the information, and then making the the single-bit
change collapse the output into two different modes by using a postscript
interpreter to make it print out the same.
Is it a real problem? Yes, because a _lot_ of document formats are
structured and are amenable to things like this. But the problem here is
the fact that you can fool somebody into signing something without
realizing that it has a lot of hidden information thanks to having formats
that can hide the blobs.
So the problem is totally different from the way git uses a hash. In the
git model, an attacker by definition cannot control both versions of a
file, since if he controls just _one_ version, he doesn't need to do the
attack in the first place!
Put another way: you could use this exact example for a version of git
that uses md5-sums instead of sha1's, but it wouldn't show anything at all
about a git vulnerability even so.
The one thing it does show is that you should probably never sign anything
but a nice human-readable ASCII file that you actually opened in your own
editor.
Linus
^ permalink raw reply
* Re: [PATCH] apply.c: tolerate diff from a dirty but unchanged path
From: Linus Torvalds @ 2005-06-12 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506120900200.2286@ppc970.osdl.org>
On Sun, 12 Jun 2005, Linus Torvalds wrote:
>
> I'll fix it up,
One-liner fix checked in: we should ignore all git headers that are just a
single line. A valid git header is _always_ multiple lines: either you
have the "---/+++" lines of a diff, or you have the old/new lines of a
mode or name change.
So the
if (git_hdr_len < 0)
test of the return value of "parse_git_header()" was changed into
if (git_hdr_len <= len)
and that cleanly solves the problem.
Linus
^ permalink raw reply
* Re: [PATCH] cg-Xlib: make showdate show timezone
From: Dan Holmsand @ 2005-06-12 17:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050612115259.GD6620@pasky.ji.cz>
Petr Baudis wrote:
> Thanks, applied. But what's the point of calling date with LANG=C? If
> the user wants his locale to get used, why prevent him?
Because otherwise, you won't get an RFC-2822 date (which is what you
explicitly wanted a couple of days ago, and what we had before).
Also, it would look pretty awkward to have parts of the output localized
(the date string), and all other parts not ("author", "date", whatnot).
/dan
^ permalink raw reply
* Re: cogito and tags propagation
From: Zack Brown @ 2005-06-12 17:49 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910506120850f762078@mail.gmail.com>
On Sun, Jun 12, 2005 at 11:50:08AM -0400, Jon Smirl wrote:
> If I add a tag to tree A, then go to tree B which depends on A and do
> cg update. It says the branch is already fully merged. It's not
> counting the addition of a tag as something that marks the tree dirty.
My impression is that tags are local to a given repo, i.e. they are not included
by default in the publically accessible data. The repo owner has to somehow
'tell' people about the tags, in order for them to be able to get them.
Apparently this is useful because it allows smaller groups to work together with
their own 'local' tags, without polluting the main tree.
Be well,
Zack
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* Re: cogito and tags propagation
From: Jon Smirl @ 2005-06-12 17:54 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050612174905.GA18751@tumblerings.org>
On 6/12/05, Zack Brown <zbrown@tumblerings.org> wrote:
> On Sun, Jun 12, 2005 at 11:50:08AM -0400, Jon Smirl wrote:
> > If I add a tag to tree A, then go to tree B which depends on A and do
> > cg update. It says the branch is already fully merged. It's not
> > counting the addition of a tag as something that marks the tree dirty.
>
> My impression is that tags are local to a given repo, i.e. they are not included
> by default in the publically accessible data. The repo owner has to somehow
> 'tell' people about the tags, in order for them to be able to get them.
I have a bunch of tags in my repo that have been cloned from linus. So
the tags do move through the system. But it seems that they need a
commit to make them move, apparently creating a new tag doesn't count
as a commit (and make a new tree head id).
[jonsmirl@jonsmirl .git]$ ls refs/tags
v2.6.11 v2.6.11-tree v2.6.12-rc2 v2.6.12-rc3 v2.6.12-rc4
v2.6.12-rc5 v2.6.12-rc6
>
> Apparently this is useful because it allows smaller groups to work together with
> their own 'local' tags, without polluting the main tree.
>
> Be well,
> Zack
>
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Zack Brown
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] apply.c: tolerate diff from a dirty but unchanged path
From: Junio C Hamano @ 2005-06-12 18:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506121003450.2286@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> One-liner fix checked in: we should ignore all git headers that are just a
LT> single line. A valid git header is _always_ multiple lines: either you
LT> have the "---/+++" lines of a diff, or you have the old/new lines of a
LT> mode or name change.
Yup. I was about to say "it always amazes me" but by now I
should instead say "I am used to see" that your fix to my
crapola is always cleaner, simpler, and shorter.
By the way, just to help you sort the heap of recent patches
from me, here is the list of patches from me not in your tree
that I think you _could_ consider. Other patches I posted to
the list that have not been merged are mostly earlier attempts
that I consider you have already discarded; there _could_ be
something I am forgetting, but if even I myself forget, they
probably do not matter ;-):
------------
This is a fix for a bug that would embarrass me unless fixed.
Subject: [PATCH] Fix rename/copy when dealing with temporarily broken...
Date: Sat, 11 Jun 2005 20:55:20 -0700
Message-ID: <7vwtp0p6tz.fsf@assigned-by-dhcp.cox.net>
A good test case is to run and compare these two in the GIT
repository. The latter case is mishandled with unpatched code:
commit=7ef76925d9c19ef74874e1735e2436e56d0c4897
git-diff-tree -C $commit
git-diff-tree -B -C $commit
------------
This one adjusts what the tutorial tells the user to expect to
the reality with the "corrected" -B behaviour we already have in
your tree. We must have this before 1.0 in order not to confuse
the reader. Unless you drop -B from git-status-script, that is.
Subject: [PATCH 5/4] Tutorial update to adjust for -B fix
Date: Fri, 03 Jun 2005 12:11:07 -0700
Message-ID: <7vd5r3l0hg.fsf_-_@assigned-by-dhcp.cox.net>
------------
These two are enhancements that would help writing the
ultra-smart three-way merge that would look at not just merge
base and two heads, but the changes in the ancestry chain:
Message-ID: <7vpsut7k89.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH] diff-tree: --find-copies-harder
Date: Fri, 10 Jun 2005 18:31:02 -0700
Message-ID: <7vr7f8p6qu.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH] Add --diff-filter= output restriction to diff-* family.
Date: Sat, 11 Jun 2005 20:57:13 -0700
I mentioned them in the reply to this message from you:
Date: Thu, 9 Jun 2005 08:15:52 -0700 (PDT)
Subject: Re: [PATCH 3/3] read-tree -m 3-way: handle more trivial merges
Message-ID: <Pine.LNX.4.58.0506090800580.2286@ppc970.osdl.org>
No, I think this is quite possibly wrong for several reasons.
...
So I just need a little convincing that this is a good idea.
------------
These are reworked "help carrying forward local changes in 2-way
fast forward".
Message-ID: <7vd5qt7k2d.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH 1/3] Clean up read-tree two-way tests.
Date: Fri, 10 Jun 2005 18:34:34 -0700
Message-ID: <7v7jh17jzr.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH 2/3] read-tree --emu23.
Date: Fri, 10 Jun 2005 18:36:08 -0700
Message-ID: <7v1x797jx0.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH 3/3] read-tree: fix too strong index requirement #5ALT
Date: Fri, 10 Jun 2005 18:37:47 -0700
Message-ID: <7voeadxlvo.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH 4/3] Finish making --emu23 equivalent to pure 2-way merge.
Date: Sat, 11 Jun 2005 02:50:51 -0700
Message-ID: <7vfyvpxlqi.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH 5/3] read-tree: loosen too strict index requirements
Date: Sat, 11 Jun 2005 02:53:57 -0700
The first four implement --emu23, a two-tree fast forward
emulated internally using the three-way mechanism. This is to
help cases where the user has local changes since the old head
by not refusing to run in many cases straight 2-tree fast
forward would refuse, and letting the user use the usual
merge-cache three-way merge postprocessing machinery to carry
local changes forward instead.
The changes these four introduce do affect 3-way in 3 cases,
which you objected, but this set has smaller impact than my
earlier attempts. It only resolves 3 extra cases the original
3-way refuses to touch (my earlier one made it to resolve 3
cases that involve removed paths as well, none of which this
round touches, and leaves stages in the resulting index). The
cases new code internally resolves, instead of refusing to run,
are:
- only "merged head" created a new path, and the index happened
to have the same change; we resolve it internally by taking
the "merged head" and keep the index dirty if it was (#2ALT).
- only "our head" created a new path, and the cache entry is
dirty (i.e. user has local changes in the work tree file); we
resolve it internally by taking "our head" and keep the index
dirty if it was (#3ALT).
- both "merged head" and "our head" created a new path
identically, and the cache entry is dirty; we resolve it
internally by taking "our head" and keep the index dirty if
it was (#5ALT).
I think your earlier objection of "closing the door to the
clever merge algorithm" would not apply to these three cases.
Note that --emu23 does not need 3-way code to resolve the #2ALT
case, but needs the other two cases not refused; the patch makes
it resolve #2ALT case only to keep things symmetric with #3ALT
case --- otherwise users of 3-way merge would get confusing (but
still correct) results.
The last one [5/3] deals with the case where a path is only
changed in the merged head in 3-way case, and the index already
happens to have a version from the merged head (probably the
user was playing with a patch floating around in the mailing
list before initiating the merge). In this case we can make the
3-way merge succeed instead of refusing to run, and that is what
this patch is about. This does not change the outcome of the
merge, and I think your "closing the door" objection would not
apply to it.
------------
This is to enhance the git-*-script suite. I do not mind too
much if it stays outside, but I think it would be useful to
other people as well, not just me.
Message-ID: <7vll5h7k5t.fsf@assigned-by-dhcp.cox.net>
Subject: [PATCH] Add script for patch submission via e-mail.
Date: Fri, 10 Jun 2005 18:32:30 -0700
------------
This attempts to split the "too big main() that does it all"
which you hated. Purely cosmetic at this point but as you
pointed out it is a good discipline to help later maintenance to
have a set of smaller single-task functions.
Message-ID: <7vu0k56517.fsf_-_@assigned-by-dhcp.cox.net>
Subject: [PATCH] diff-stages: unuglify the too big main() function.
Date: Fri, 10 Jun 2005 18:44:36 -0700
^ permalink raw reply
* [PATCH] replace sha1sum with sum in test suite for portability
From: Mark Allen @ 2005-06-13 0:19 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
Replace sha1sum with sum in t1002 for portability.
This patch replaces sha1sum because some systems do not have GNU coreutils "out of the
box" and not having sha1sum will make the test fail. I chose to replace sha1sum with sum
(after considering several different checksumming methods) because by default GNU sum
runs in a "BSD compatibility mode" so it should Just Work across OSes as long as its
installed.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
[-- Attachment #2: 2003972814-test-portability.patch.txt --]
[-- Type: text/plain, Size: 5108 bytes --]
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -51,7 +51,7 @@ test_expect_success \
treeM=`git-write-tree` &&
echo treeM $treeM &&
git-ls-tree $treeM &&
- sha1sum bozbar frotz nitfol >M.sha1 &&
+ sum bozbar frotz nitfol >M.sum &&
git-diff-tree $treeH $treeM'
test_expect_success \
@@ -60,7 +60,8 @@ test_expect_success \
git-read-tree -m -u $treeH $treeM &&
git-ls-files --stage >1-3.out &&
cmp M.out 1-3.out &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual3.sum &&
+ cmp M.sum actual3.sum &&
check_cache_at bozbar clean &&
check_cache_at frotz clean &&
check_cache_at nitfol clean'
@@ -76,7 +77,8 @@ test_expect_success \
diff --unified=0 M.out 4.out >4diff.out
compare_change 4diff.out expected &&
check_cache_at yomin clean &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual4.sum &&
+ cmp M.sum actual4.sum &&
echo yomin >yomin1 &&
diff yomin yomin1 &&
rm -f yomin1'
@@ -92,7 +94,8 @@ test_expect_success \
diff --unified=0 M.out 5.out >5diff.out
compare_change 5diff.out expected &&
check_cache_at yomin dirty &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual5.sum &&
+ cmp M.sum actual5.sum &&
: dirty index should have prevented -u from checking it out. &&
echo yomin yomin >yomin1 &&
diff yomin yomin1 &&
@@ -106,7 +109,8 @@ test_expect_success \
git-ls-files --stage >6.out &&
diff --unified=0 M.out 6.out &&
check_cache_at frotz clean &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual3.sum &&
+ cmp M.sum actual3.sum &&
echo frotz >frotz1 &&
diff frotz frotz1 &&
rm -f frotz1'
@@ -121,7 +125,8 @@ test_expect_success \
git-ls-files --stage >7.out &&
diff --unified=0 M.out 7.out &&
check_cache_at frotz dirty &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum bozbar frotz nitfol >actual7.sum &&
+ if cmp M.sum actual7.sum; then false; else :; fi &&
: dirty index should have prevented -u from checking it out. &&
echo frotz frotz >frotz1 &&
diff frotz frotz1 &&
@@ -150,7 +155,8 @@ test_expect_success \
git-read-tree -m -u $treeH $treeM &&
git-ls-files --stage >10.out &&
cmp M.out 10.out &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual10.sum &&
+ cmp M.sum actual10.sum'
test_expect_success \
'11 - dirty path removed.' \
@@ -189,9 +195,12 @@ test_expect_success \
git-ls-files --stage >14.out || exit
diff --unified=0 M.out 14.out >14diff.out
compare_change 14diff.out expected &&
+ sum bozbar frotz >actual14.sum &&
+ grep -v nitfol M.sum > expected14.sum &&
+ cmp expected14.sum actual14.sum &&
+ sum bozbar frotz nitfol >actual14a.sum &&
+ if cmp M.sum actual14a.sum; then false; else :; fi &&
check_cache_at nitfol clean &&
- grep -v nitfol M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
echo nitfol nitfol >nitfol1 &&
diff nitfol nitfol1 &&
rm -f nitfol1'
@@ -207,8 +216,11 @@ test_expect_success \
diff --unified=0 M.out 15.out >15diff.out
compare_change 15diff.out expected &&
check_cache_at nitfol dirty &&
- grep -v nitfol M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum bozbar frotz >actual15.sum &&
+ grep -v nitfol M.sum > expected15.sum &&
+ cmp expected15.sum actual15.sum &&
+ sum bozbar frotz nitfol >actual15a.sum &&
+ if cmp M.sum actual15a.sum; then false; else :; fi &&
echo nitfol nitfol nitfol >nitfol1 &&
diff nitfol nitfol1 &&
rm -f nitfol1'
@@ -237,7 +249,8 @@ test_expect_success \
git-ls-files --stage >18.out &&
diff --unified=0 M.out 18.out &&
check_cache_at bozbar clean &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual18.sum &&
+ cmp M.sum actual18.sum'
test_expect_success \
'19 - local change already having a good result, further modified.' \
@@ -249,8 +262,11 @@ test_expect_success \
git-ls-files --stage >19.out &&
diff --unified=0 M.out 19.out &&
check_cache_at bozbar dirty &&
- grep -v bozbar M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum frotz nitfol >actual19.sum &&
+ grep -v bozbar M.sum > expected19.sum &&
+ cmp expected19.sum actual19.sum &&
+ sum bozbar frotz nitfol >actual19a.sum &&
+ if cmp M.sum actual19a.sum; then false; else :; fi &&
echo gnusto gnusto >bozbar1 &&
diff bozbar bozbar1 &&
rm -f bozbar1'
@@ -264,7 +280,8 @@ test_expect_success \
git-ls-files --stage >20.out &&
diff --unified=0 M.out 20.out &&
check_cache_at bozbar clean &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual20.sum &&
+ cmp M.sum actual20.sum'
test_expect_success \
'21 - no local change, dirty cache.' \
^ permalink raw reply
* [PATCH] Unset TZ in t5000
From: Mark Allen @ 2005-06-13 0:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
Unset TZ in t5000 and remove GNU awkism
The t5000 test script fails at test #4 on my box because my copy of tar adjusts the time
in the tarfile for local time if TZ is set. Explicitly unset TZ so that it reports GMT
time. Additionally, my version of AWK doesn't like the "length" directive, so this patch
removes it.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
[-- Attachment #2: 3951729877-unset-tz-t5000.patch.txt --]
[-- Type: text/plain, Size: 481 bytes --]
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -50,8 +50,8 @@ test_expect_success \
test_expect_success \
'validate file modification time' \
- 'tar tvf b.tar a/a |
- awk \{print\ \$4,\ length\(\$5\)\<7\ ?\ \$5\":00\"\ :\ \$5\} >b.mtime &&
+ 'TZ= tar tvf b.tar a/a |
+ awk \{print\ \$4\"\ \"\$5\} >b.mtime &&
echo "2005-05-27 22:00:00" >expected.mtime &&
diff expected.mtime b.mtime'
^ permalink raw reply
* [PATCH] Support commit_format fully in diff-tree
From: Junio C Hamano @ 2005-06-13 0:44 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linus Torvalds, git
In-Reply-To: <20050612093413.GR20432@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Hello,
TG> what option to I have to tweak to get timestamps human understandable
TG> again:
TG> git-whatchanged | head -5
------------
This steals --pretty command line option from rev-list and
teaches diff-tree to do the same. With this change,
$ git-whatchanged --pretty
would work as expected.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Sorry, but this patch does not include documentation updates
*** or additional tests like my usual ones. I would appreciate
*** it if others on the list give help with them. I will be
*** offline for about a week or so, and trying to clean my stack
*** as much as possible before I have to leave.
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff : diff-tree.c
# - linus: git-apply: ignore empty git headers
# + (working tree)
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -398,7 +398,20 @@ static int diff_tree_stdin(char *line)
}
static char *diff_tree_usage =
-"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-O<orderfile>] [-m] [-s] [-v] [-t] <tree-ish> <tree-ish>";
+"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-O<orderfile>] [-m] [-s] [-v] [--pretty] [-t] <tree-ish> <tree-ish>";
+
+static enum cmit_fmt get_commit_format(const char *arg)
+{
+ if (!*arg)
+ return CMIT_FMT_DEFAULT;
+ if (!strcmp(arg, "=raw"))
+ return CMIT_FMT_RAW;
+ if (!strcmp(arg, "=medium"))
+ return CMIT_FMT_MEDIUM;
+ if (!strcmp(arg, "=short"))
+ return CMIT_FMT_SHORT;
+ usage(diff_tree_usage);
+}
int main(int argc, const char **argv)
{
@@ -492,6 +505,11 @@ int main(int argc, const char **argv)
header_prefix = "diff-tree ";
continue;
}
+ if (!strncmp(arg, "--pretty", 8)) {
+ verbose_header = 1;
+ commit_format = get_commit_format(arg+8);
+ continue;
+ }
if (!strcmp(arg, "--stdin")) {
read_stdin = 1;
continue;
Compilation finished at Sun Jun 12 17:39:24
^ permalink raw reply
* Re: qgit-0.5
From: Peter TB Brett @ 2005-06-13 8:40 UTC (permalink / raw)
To: mcostalba; +Cc: git
Hi Marco,
> Here is qgit-0.5, a git GUI viewer
Looking great so far!
Just a note though -- you don't seem to be using the SF Release System
correctly. You've now got *two packages* called qgit, when what you want
is two *releases* in the qgit package.
Of course, I might be barking up the wrong tree and you meant to do it
like that all along.
Peter Brett
P.S. Any hope of integration into Konqueror? *begs pathetically*
--
E-mail: peter@peter-b.co.uk
Website: http://www.peter-b.co.uk
"If you're not part of the solution, you're part of the precipitate."
^ permalink raw reply
* Re: [PATCH] Unset TZ in t5000
From: Rene Scharfe @ 2005-06-13 15:54 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20050613002444.80848.qmail@web41213.mail.yahoo.com>
Mark Allen schrieb:
> Unset TZ in t5000 and remove GNU awkism
>
> The t5000 test script fails at test #4 on my box because my copy of
> tar adjusts the time in the tarfile for local time if TZ is set.
> Explicitly unset TZ so that it reports GMT time.
Good idea.
> Additionally, my version of AWK doesn't like the "length" directive,
> so this patch removes it.
What kind of AWK is that? The One True AWK certainly has a length
function for strings and POSIX mandates it, too, so it's not a GNUism.
The expression
length($5)<7 ? $5":00" : $5
(where $5 is a time value) is there to cope with tars that format the
time like hh:mm instead of the expected hh:mm:ss. If you have to remove
the call to "length", please replace the thing with something
equivalent, like
match($5, /:.*:/) ? $5 : $5":00"
or similar, instead of simply dropping that test.
Thanks,
Rene
^ permalink raw reply
* Re: [PATCH] Fix rename/copy when dealing with temporarily broken pairs.
From: Jon Seymour @ 2005-06-13 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtp0p6tz.fsf@assigned-by-dhcp.cox.net>
G'day Junio,
On 6/12/05, Junio C Hamano <junkio@cox.net> wrote:
> When rename/copy uses a file that was broken by diffcore-break
> as the source, and the broken filepair gets merged back later,
> the output was mislabeled as a rename. In this case, the source
> file ends up staying in the output, so we should label it as a
> copy instead.
I've got a patch series that renames a file, but the patches generated by your
git-format-patch-script fail to rename the file to the new name.
I wondered if this patch might fix it, but it doesn't seem to.
Here's a hunk from the patch:
diff --git a/epoch.c b/traversal.c
similarity index 100%
rename from epoch.c
rename to traversal.c
--- a/epoch.c
+++ b/traversal.c
@@ -14,7 +14,7 @@
#include "cache.h"
#include "commit.h"
-#include "epoch.h"
+#include "traversal.h"
struct fraction {
BIGNUM numerator;
What tool am I meant to be using to apply the patch?
I am currently using "patch -p1"
jon.
^ permalink raw reply
* Re: [PATCH] Unset TZ in t5000
From: Mark Allen @ 2005-06-13 17:27 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <42ADAC4D.7050408@lsrfire.ath.cx>
--- Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> What kind of AWK is that? The One True AWK certainly has a length
> function for strings and POSIX mandates it, too, so it's not a GNUism.
>
> The expression
>
> length($5)<7 ? $5":00" : $5
>
> (where $5 is a time value) is there to cope with tars that format the
> time like hh:mm instead of the expected hh:mm:ss. If you have to remove
> the call to "length", please replace the thing with something
> equivalent, like
>
> match($5, /:.*:/) ? $5 : $5":00"
>
> or similar, instead of simply dropping that test.
Hi Rene,
I'll test your suggestion later tonight (US time) when I get home from work. Sorry I
don't know much about awk. (I usually break out perl for any job I used to give awk) When
I ran the t5000 script in --verbose mode, all I could see was awk complaining about the
length directive.
It *is* possible that there's some kind of quoting/character escape problem which Linux
tolerates but is causing the syntax error on my home system. (It's Mac OS 10.4.1/Darwin)
Thanks,
--Mark
^ permalink raw reply
* Re: [PATCH] Fix rename/copy when dealing with temporarily broken pairs.
From: Petr Baudis @ 2005-06-13 17:58 UTC (permalink / raw)
To: Jon Seymour; +Cc: Junio C Hamano, git
In-Reply-To: <2cfc4032050613092462d3a456@mail.gmail.com>
Dear diary, on Mon, Jun 13, 2005 at 06:24:16PM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> diff --git a/epoch.c b/traversal.c
> similarity index 100%
> rename from epoch.c
> rename to traversal.c
> What tool am I meant to be using to apply the patch?
>
> I am currently using "patch -p1"
Try git-apply.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ 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