* Re: MinGW port updated to 1.5.2
From: Han-Wen Nienhuys @ 2007-05-27 6:26 UTC (permalink / raw)
To: Aaron Gray; +Cc: git
In-Reply-To: <004201c79fe7$f16b47b0$0200a8c0@AMD2500>
Aaron Gray escreveu:
>> Aaron Gray escreveu:
>>>> Aaron Gray escreveu:
>>>>>>> GIT_EXTERNAL_DIFF works now.
>>>>>>
>>>>>> http://lilypond.org/git/binaries/mingw/
>>>>>>
>>>>>> uploading as I speak. Untested.
>>>>>
>>>>> This installs to "C:\Program Files\Git" and is not availiable on the
>>>>> path. What is going on here please ?
>>>>
>>>> this uses the same buildscripts as before, so if it worked, it should
>>>> still work. The path should point to $PF/Git/usr/bin/ ; you might
>>>> need to
>>>> log out and log in again for the path to visible.
>>>
>>> Still not working properly.
>>>
>>> From CMD.EXE, neither 'git clone' and 'git-clone' are accessable.
>> - what is the value of the PATH variable in CMD ?
>
> Path=C:\Program
> Files\GreenBorder\;C:\windows\system32;C:\windows;C:\windows\Sys
> tem32\Wbem;C:\Program Files\ATI Technologies\ATI Control
> Panel;c:\Program Files\
> Microsoft SQL Server\90\Tools\binn\;C:\GnuWin32\bin;C:\Program
> Files\QuickTime\Q
> TSystem\;C:\Utils;C:\Program
> Files\MakeMsi\;c:\MinGW\bin;C:\MinGW\usr\bin;C:\Pro
> gram Files\Git\usr\bin;C:\Program Files\Git\usr\bin
Can you troubleshoot this for me? As you can see, you have
C:\Program Files\Git\usr\bin
in the path. That AFAIK should be enough to have git.exe run
inside CMD. Maybe I'm missing something, but that is as far as my
windows knowledge goes.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH v3] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-27 5:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.99.0705262304200.3366@xanadu.home>
On 5/26/07, Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 26 May 2007, Dana How wrote:
> > Extremely large blobs distort general-purpose git packfiles.
> > These megablobs can be either stored in separate "kept" packfiles,
> > or left as loose objects. Here we add some features to help
> > either approach.
> >
> > This patch implements the following:
> > 1. git pack-objects accepts --max-blob-size=N, with the effect that
> > only loose blobs less than N KB are written to the packfiles(s).
> > If an already packed blob violates this limit (perhaps these are
> > fast-import packs or max-blob-size was reduced), it _is_ passed
> > through if from a local pack and no loose copy exists.
>
> I'm still not convainced by this feature. Is it really necessary?
>
> Wouldn't it be better if the --max-blob-size=N was instead a
> --trailing-blob-size=N to specify which blobs are considered "naughty"
> per our previous discussion? This way there is no incoherency with
> already packed blobs larger than the treshold that you have to pass
> through.
>
> This, combined with the option to disable deltification of large blobs
> (both options can be specified with the same size), and possibly the
> pack size limit, would solve your large blob issue, shouldn't it?
Unfortunately, it doesn't.
There are at least three reasonable ways to handle large blobs:
(1) git-repack -a repacks everything. Naughty blobs get pushed to
the end as discussed (possibly dominating later split packs).
(2) Naughty blobs accumulate in separate "kept" packs.
git-repack -a only repacks nice blobs. Separate scripts,
or new options to git-repack, are needed to repack the "kept" packs.
A number of people have discussed ideas like this.
(3) Naughty blobs are kept loose.
We have 255GB compressed in our Perforce repository and
it grows by 2GB+ per week. Although I'm only considering bringing ~10%
of this into git, it would be good for me to be able to argue that
I could bring more. Every day the equivalent of ~1K+ blobs are committed.
How often should I repack the shared repository [that replaces Perforce]?
With this level of traffic I believe I should do it every night.
I've been discussing these plans with IT here since they maintain
everything else.
They would like any part of the database that is going to be reorganized
and replaced to be backed up first. If only (1) is available, and I
repack every
night, then I need to back up the entire repository every night as well.
If I use (2) or (3), then I back up just the repacked portion each night,
back up the kept packs only when they are repacked (on a slower schedule),
and/or back up the loose blobs on a similar schedule.
Besides this back up issue, I simply don't want to have to repack _all_
of such a large repository each night. With (1), nightly repacks get longer
and longer, and harder to schedule.
I think the minimum features needed to support (2) and (3) are the same:
(a) An easy way to prevent loose blobs exceeding some size limit
from migrating into "nice" packs;
(b) A way to prevent packed objects from being copied when
(i) they no longer meet the (new or reduced) size limit AND
(ii) they exist in some other safe form in the repository.
The behavior of --max-blob-size=N in this patch provides both of these
while deleting other behavior people didn't like.
You mentioned "incoherency" above;
I'm not too sure how to proceed on that.
If you have a more coherent way to provide (a) and (b) above,
please let me know.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Dana How @ 2007-05-27 4:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <20070527033429.GY28023@spearce.org>
On 5/26/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Dana How <danahow@gmail.com> wrote:
> > Shawn: When I first saw the index-loading code, my first
> > thought was that all the index tables should be
> > merged (easy since sorted) so callers only need to do one search.
>
> Yes; in fact this has been raised on the list before. The general
> idea was to create some sort of "super index" that had a list of
> all objects and which packfile they could be found in. This way the
> running process doesn't have to search multiple indexes, and the
> process doesn't have to be responsible for the merging itself.
>
> See the thing is, if you read all of every .idx file on a simple
> `git-log` operation you've already lost. The number of trees and
> blobs tends to far outweigh the number of commits and they really
> outweigh the number of commits the average user looks at in a
> `git-log` session before they abort their pager. So sorting all
> of the available .idx files before we produce even the first commit
> is a horrible thing to do.
>
> But the problem with a super index is repacking. Every time the user
> repacks their recent loose objects (or recently fetched packs) we are
> folding some packfiles together, but may be leaving others alone.
> The super index would need to account for the packfiles we aren't
> looking at or repacking. It gets complicated fast.
>
> There's also the problem of alternate ODBs; do we fold the indexes
> of our alternates into our own super index? Or does each ODB get
> its own super index and we still have to load multiple super index
> files?
Yes, the problem is that even an on-demand, "lazy" merge
is likely to require far more work than the expected number of index probes.
> In pack v4 we're likely to move the SHA-1 table from the .idx file
> into the front of the .pack file. This makes the .idx file hold
> only the offsets and the CRC checkums of each object. If we start
> making a super index, we have to duplicate the SHA-1 table twice
> (once in the .pack, again in the super index).
Hmm, hopefully the SHA-1 table can go at the _end_
since with split packs that's the only time we know the number
of objects in the pack... ;-)
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Dana How @ 2007-05-27 4:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Shawn O. Pearce, git, danahow
In-Reply-To: <alpine.LFD.0.99.0705262223540.3366@xanadu.home>
On 5/26/07, Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 26 May 2007, Dana How wrote:
> > (1) git-repack -a -d repacks everything on each call. You would need:
> > (1a) Rewrite builtin-pack-objects.c so only the object_ix hash
> > accesses the "objects" array directly, everything else
> > goes through a pointer table.
> > (1b) Sort the new pointer table by object type, in order
> > tag -> commit -> tree -> nice blob -> naughty blob.
> > The sort is stable so the order within each group is unchanged.
>
> Because commit objects are so fundamental to many graph operations they
> are already all packed together. But tree and blob objects are
> intermixed for the reason stated above.
I noticed that all the commits were together and
wondered if that was deliberate.
> The naughty blob is a really special category and I think they should be
> treated as such. Therefore I don't think the common/normal case should
> be impacted with a generic change for something that is still a special
> case.
This argument makes sense.
> In other words, I think the naughty blob could simply be recognized as
> such and be referenced in a special list instead of being written out
> initially. Then when everything is believed to be written, the special
> list can be walked to force write those naughty blob at last. No need
> to modify the current object order.
This works as long as a naughty blob can't be a delta base for a nice blob
(causing it to be pushed out early by the recursion in write_one()).
I think that's a reasonable and understandable restriction.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Shawn O. Pearce @ 2007-05-27 3:34 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, git
In-Reply-To: <56b7f5510705261031o311b89bapd730374cbc063931@mail.gmail.com>
Dana How <danahow@gmail.com> wrote:
> Shawn: When I first saw the index-loading code, my first
> thought was that all the index tables should be
> merged (easy since sorted) so callers only need to do one search.
Yes; in fact this has been raised on the list before. The general
idea was to create some sort of "super index" that had a list of
all objects and which packfile they could be found in. This way the
running process doesn't have to search multiple indexes, and the
process doesn't have to be responsible for the merging itself.
See the thing is, if you read all of every .idx file on a simple
`git-log` operation you've already lost. The number of trees and
blobs tends to far outweigh the number of commits and they really
outweigh the number of commits the average user looks at in a
`git-log` session before they abort their pager. So sorting all
of the available .idx files before we produce even the first commit
is a horrible thing to do.
But the problem with a super index is repacking. Every time the user
repacks their recent loose objects (or recently fetched packs) we are
folding some packfiles together, but may be leaving others alone.
The super index would need to account for the packfiles we aren't
looking at or repacking. It gets complicated fast.
There's also the problem of alternate ODBs; do we fold the indexes
of our alternates into our own super index? Or does each ODB get
its own super index and we still have to load multiple super index
files?
In pack v4 we're likely to move the SHA-1 table from the .idx file
into the front of the .pack file. This makes the .idx file hold
only the offsets and the CRC checkums of each object. If we start
making a super index, we have to duplicate the SHA-1 table twice
(once in the .pack, again in the super index).
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3] Prevent megablobs from gunking up git packs
From: Nicolas Pitre @ 2007-05-27 3:15 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <465887AB.1010001@gmail.com>
On Sat, 26 May 2007, Dana How wrote:
>
> Extremely large blobs distort general-purpose git packfiles.
> These megablobs can be either stored in separate "kept" packfiles,
> or left as loose objects. Here we add some features to help
> either approach.
>
> This patch implements the following:
> 1. git pack-objects accepts --max-blob-size=N, with the effect that
> only loose blobs less than N KB are written to the packfiles(s).
> If an already packed blob violates this limit (perhaps these are
> fast-import packs or max-blob-size was reduced), it _is_ passed
> through if from a local pack and no loose copy exists.
I'm still not convainced by this feature. Is it really necessary?
Wouldn't it be better if the --max-blob-size=N was instead a
--trailing-blob-size=N to specify which blobs are considered "naughty"
per our previous discussion? This way there is no incoherency with
already packed blobs larger than the treshold that you have to pass
through.
This, combined with the option to disable deltification of large blobs
(both options can be specified with the same size), and possibly the
pack size limit, would solve your large blob issue, shouldn't it?
Nicolas
^ permalink raw reply
* [PATCH] Allow contrib new-workdir to link into bare repositories
From: Shawn O. Pearce @ 2007-05-27 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Julian Phillips
On one particular system I like to keep a cluster of bare Git
repositories and spawn new-workdirs off of them. Since the bare
repositories don't have working directories associated with them
they don't have a .git/ subdirectory that hosts the repository we
are linking to.
Using a bare repository as the backing repository for a workdir
created by this script does require that the user delete core.bare
from the repository's configuration file, so that Git auto-senses
the bareness of a repository based on pathname information, and
not based on the config file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/workdir/git-new-workdir | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index 9877b98..f2a3615 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -20,17 +20,19 @@ new_workdir=$2
branch=$3
# want to make sure that what is pointed to has a .git directory ...
-test -d "$orig_git/.git" || die "\"$orig_git\" is not a git repository!"
+git_dir=$(cd "$orig_git" 2>/dev/null &&
+ git rev-parse --git-dir 2>/dev/null) ||
+ die "\"$orig_git\" is not a git repository!"
# don't link to a workdir
-if test -L "$orig_git/.git/config"
+if test -L "$git_dir/config"
then
die "\"$orig_git\" is a working directory only, please specify" \
"a complete repository."
fi
# make sure the the links use full paths
-orig_git=$(cd "$orig_git"; pwd)
+git_dir=$(cd "$git_dir"; pwd)
# create the workdir
mkdir -p "$new_workdir/.git" || die "unable to create \"$new_workdir\"!"
@@ -45,13 +47,13 @@ do
mkdir -p "$(dirname "$new_workdir/.git/$x")"
;;
esac
- ln -s "$orig_git/.git/$x" "$new_workdir/.git/$x"
+ ln -s "$git_dir/$x" "$new_workdir/.git/$x"
done
# now setup the workdir
cd "$new_workdir"
# copy the HEAD from the original repository as a default branch
-cp "$orig_git/.git/HEAD" .git/HEAD
+cp "$git_dir/HEAD" .git/HEAD
# checkout the branch (either the same as HEAD from the original repository, or
# the one that was asked for)
git checkout -f $branch
--
1.5.2.789.g8ee1
^ permalink raw reply related
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Nicolas Pitre @ 2007-05-27 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Jim Meyering, git
In-Reply-To: <7vk5uvjy0g.fsf@assigned-by-dhcp.cox.net>
On Sat, 26 May 2007, Junio C Hamano wrote:
> Once you learn to _visualize_ the ordering relationship in "X op
> Y" by relying on "op" being always < or <=, you will get the
> "number line" pop in your head whenever you see a comparision
> expression, without even having to think about it, and you "see"
> X and Y on the number line:
>
> ... -2 -1 0 1 2 ...
> ---------+---------+---------+---------+---------+---------
> true: 0 <= fcntl(...)
>
>
> ... -2 -1 0 1 2 ...
> ---------+---------+---------+---------+---------+---------
> false: (0 <= fcntl(...))
>
> What the comparison is doing comes naturally to you, without
> even having to translate it back to human language "X is larger
> (or smaller) than this constant". The ordering is right there,
> in front of your eyes, before you vocalize it.
Well... it probably depends on how your brain is wired up.
I completely agree with your reasoning. It _should_ indeed be natural
and more obvious to always put things in increasing order.
BUT it is not how my brain is connected, and after many attempts I just
cannot work efficiently with your method. It simply doesn't come out
logical for me and I have to spend an unusual amount of time on every
occasion I encounter this structure to really get it. To me it always
looks backward.
And I suspect the majority of people who just cannot train their brain
with the arguably superior representation are many, probably the
majority. It appears to be the case for Linus. It is definitely the
case for me.
Nicolas, who apologizes for his defective brain.
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Nicolas Pitre @ 2007-05-27 2:43 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <56b7f5510705261031o311b89bapd730374cbc063931@mail.gmail.com>
On Sat, 26 May 2007, Dana How wrote:
> I think there are two interesting strategies compatible
> with maximally-informative timestamps:
>
> (1) git-repack -a -d repacks everything on each call. You would need:
> (1a) Rewrite builtin-pack-objects.c so only the object_ix hash
> accesses the "objects" array directly, everything else
> goes through a pointer table.
> (1b) Sort the new pointer table by object type, in order
> tag -> commit -> tree -> nice blob -> naughty blob.
> The sort is stable so the order within each group is unchanged.
This is not a good idea in general for runtime access to the pack. If
you consider a checkout, the commit object
is looked up, then the root tree object, then each tree entry is
recursively looked up. Right now the way the objects are laid out, the
most recent commit will have all its objects contiguously found in the
pack and in the right order (that means tree and blobs mixed up). This
gets less and less true as you go back into history, but at least the
recent stuff has a really nice access pattern.
Because commit objects are so fundamental to many graph operations they
are already all packed together. But tree and blob objects are
intermixed for the reason stated above.
The naughty blob is a really special category and I think they should be
treated as such. Therefore I don't think the common/normal case should
be impacted with a generic change for something that is still a special
case.
In other words, I think the naughty blob could simply be recognized as
such and be referenced in a special list instead of being written out
initially. Then when everything is believed to be written, the special
list can be walked to force write those naughty blob at last. No need
to modify the current object order.
Nicolas
^ permalink raw reply
* Re: GIT on MinGW problem
From: Jakub Narebski @ 2007-05-26 23:47 UTC (permalink / raw)
To: git
In-Reply-To: <4658BA64.2050904@xs4all.nl>
Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
>>>> * git version reports just:
>>>>
>>>> git version -dirty
>>>>
>>>> Since git-gui parses the output of git version, but does not expect it
>>>> to be of this format, and fails with an error message that it cannot
>>>> parse the version.
>>> My biggest problem is that the makefiles of git are an unmitigated
>>> disaster, and there seems to be little interest in solving this
>>> problem. For example, my suggestion to introduce autoconf was met with
>>> derision.
>>
>> Well, I would not call it derision. But many people have had bad
>> experience with that big mess which is autoconf, so we were more than
>> reluctant to do it.
>
> autoconf is not that big a mess, but it is a macrolanguage, which does
> come with its pitfalls. Automake and libtool are the messy things,
> and I prefer to stay away from them as far as possible.
>
> The point of autoconf is to generate a hyper-portable script that
> deals with all the different flavors of shell breakage. For the user
> it simplifies compiling packages enormously, which IMO should be the
> guiding concern if you like to have users.
>
> For a pretty run-of-the-mill tool like git (dependency wise), it
> should be easy to write a working configure.in.
>
> My favorite approach is: use autoconf to generate
>
> - config.h
>
> - config.make
>
> All settings that force recompile should be in config.h, and standard
> C methods to track dependencies will take care of the recompilation
> when anything changes. The main Makefile includes config.make, and
> contains all configurable settings. The Makefile only needs to be
> edited by developers. Require GNU Make so you can write sane
> makefiles.
Actually we do have configure.ac script; ./configure (result of
"make configure") is not distributed in the tarball I think.
It generates file named not config.make, but config.mak.autogen.
By the way, the .autogen suffix is to distinguish ./configure generated file
from handmade user configureation, but I have no idea why it is config.mak
not config.make. But there is no config.h -- we do not rely on automake and
autoheader.
If you are well wersed in autoconf, feel free to improve our configure.ac
script.
> Instead, we have a Makefile that relies on an esoteric combination of
> perl and shell scripting inside Makefiles.
The idea is to be able to get reasonable defaults (depending on system of
course) without needing autoconf, and running quite long on some
platform ./configure script detection...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn and SVK mirror between two repositories
From: Vinubalaji Gopal @ 2007-05-26 23:48 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4657B49D.4060807@vilain.net>
On 5/25/07, Sam Vilain <sam@vilain.net> wrote:
> Sounds a bit simpler than I thought - check out my tutorial on this
> http://utsl.gen.nz/talks/git-svn/intro.html
I did go through that link before posting here. I don't have my svk
depotmap now and I want to skip the svk initialization again. I reread
that tutorial again to see if I missed something, but could not find
anything that I could use.
Here is how it is now - I had a project which I branched using svk.
Say the project I branched was at revision r1000. I added a lot of
changes to r1000 in my local svk branch. I committed all this changes
to my svn sandbox using smerge. At times I also updated from the trunk
using smerge. So the svn sandbox has all my local changes and the
latest from the trunk upto some point.
Now I have a different machine with no svk - I have my svn sandbox
with all my changes and changes from the trunk upto some point (say
r1500 and the trunk is now at r1650). How do I setup git to use my svn
sandbox and the svn trunk with no svk anywhere now and have the same
kind of setup?
--
Vinu
In a world without fences who needs Gates?
^ permalink raw reply
* Re: [PATCH v3] Prevent megablobs from gunking up git packs
From: Dana How @ 2007-05-26 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7vwsyvgpvf.fsf@assigned-by-dhcp.cox.net>
On 5/26/07, Junio C Hamano <junkio@cox.net> wrote:
> Dana How <danahow@gmail.com> writes:
> > diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> > @@ -371,8 +372,6 @@ static unsigned long write_object(struct sha1file *f,
> > /* no if no delta */
> > int usable_delta = !entry->delta ? 0 :
> > - /* yes if unlimited packfile */
> > - !pack_size_limit ? 1 :
> > /* no if base written to previous pack */
> > entry->delta->offset == (off_t)-1 ? 0 :
> > /* otherwise double-check written to this
> > @@ -408,7 +407,7 @@ static unsigned long write_object(struct sha1file *f,
> > buf = read_sha1_file(entry->sha1, &type, &size);
> > if (!buf)
> > die("unable to read %s", sha1_to_hex(entry->sha1));
> > - if (size != entry->size)
> > + if (size != entry->size && type == obj_type)
> > die("object %s size inconsistency (%lu vs %lu)",
> > sha1_to_hex(entry->sha1), size, entry->size);
>
> I do not quite get how these two hunks relate to the topic of
> this patch. Care to enlighten?
No problem.
When the code decides that a blob should not be written to the output file,
then I must make sure it is not used as a delta base. A large blob
that triggered the size test and _was_ a delta base could be the result
of maxblobsize decreasing or being newly specified,
both without -f/--no-object-reuse,
and we need to tolerate the user forgetting the option.
To make sure that it is not so used, I re-use the trick from maxpacksize
which ensures that a delta base is not in the previous split pack:
I set the offset field to -1. Unfortunately, I only checked for this magic
value when computing usable_delta if pack_size_limit was set. It turns
out the test doesn't need to be conditional on pack_size_limit, it works
for all cases; so since I need to do the test when maxblobsize was specified
and maxpacksize wasn't, I deleted the pack_size_limit test.
Now for the second hunk. The facts above mean we could have marked
this entry as a re-used delta, but we are unable to re-use the delta
because its delta base is not being written to this pack. So we fall into
the !to_reuse case even though the size field in the object_entry is the
size of the delta, not the object. We can detect this by the type coming
from read_sha1_file being unequal to the type set from the pack (which is
one of OBJ_{REF,OFS}_DELTA). So I disable the size matching
test in this case.
> > @@ -564,6 +563,17 @@ static off_t write_one(struct sha1file *f,
> > + /* refuse to include as many megablobs as possible */
> > + if (max_blob_size && e->size >= max_blob_size) {
> > + struct stat st;
> > + /* skip if unpacked, remotely packed, or loose anywhere */
> > + if (!e->in_pack || !e->in_pack->pack_local || find_sha1_file(e->sha1, &st)) {
> > + e->offset = (off_t)-1; /* might drop reused delta base if mbs less */
> > + written++;
> > + return offset;
> > + }
> > + }
> > +
>
> I thought that you are simply ignoring the "naughty blobs"---why
> should it be done this late in the call sequence? I haven't
> followed the existing code nor your patch closely, but I wonder
> why the filtering is simply done inside (or by the caller of)
> add_object_entry(). You would need to do sha1_object_info()
> much earlier than the current code does, though.
Recently Nicolas Pitre improved the code as follows:
(1) tree-walking etc. which calls add_object_entry.
We learn sha1, type, name(path), pack&offset, no_try_delta
during this step.
(2) NEW: sort a table of pointers to these objects by pack_offset.
(3) Now call check_object on each object, but in the order
determined in (2). We learn each object's size during
this step. This requires us to inspect each object's header
in the pack(s).
The result is that we smoothly scan through the pack(s),
instead of jumping all over the place.
If I move sha1_object_info earlier, before (2), then I undo
his optimization. This fact ultimately justifies the first two
hunks that you commented on, since it means we want
the objects to appear in the object list _before_ we can
decide not to write them, and thus we need to handle
objects not written and all their consequences
(which didn't seem too strange to me,
since you already have preferred bases).
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [PATCH/RFC] gitweb: Provide links to individual commitdiffs in difftree for merges
From: Jakub Narebski @ 2007-05-26 23:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Add to difftree / whatchanged table row with "1", "2", ... links to
'commitdiff' view for diff with n-th parent for merge commits, as a
table header. This is visible in 'commit' and 'comitdiff' views. It
is more important for 'commitdiff' view, as in 'commit' view commit
object header has 'diff' links to diff to n-th parent.
To save space links are shown as "n", where "n" is number of a parent,
and not as for example shortened (to 7 characters) sha1 of a parent
commit. To make it easier to doscover what links is for, encompassing
<th> element has 'title' attribute explaining the link.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is my proposal on how to provide links to diffs to individual
parents in the 'commitdiff' view. This is RFC: please comment if you
like the idea (or not), and what the layout should be, what this
should look like. Should we add those links only for 'commitdiff'
view, for example?
Some complications in creating layout stem from the fact that "|" is
used as separator, instead of using table border, or cell borders to
separate columns. And we use "|" because in most other places we use
only one cell (column) for the whole series of links.
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 19 +++++++++++++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 9f0822f..7908fe3 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -181,10 +181,15 @@ table.diff_tree {
font-family: monospace;
}
+table.combined.diff_tree th {
+ text-align: center;
+}
+
table.combined.diff_tree td {
padding-right: 24px;
}
+table.combined.diff_tree th.link,
table.combined.diff_tree td.link {
padding: 0px 2px;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c3921cb..999353d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2380,6 +2380,25 @@ sub git_difftree_body {
print "<table class=\"" .
(@parents > 1 ? "combined " : "") .
"diff_tree\">\n";
+
+ if (@parents > 1) { #combined diff
+ # table header for combined diff
+ print "<tr>\n" .
+ ($action eq 'commitdiff' ? "<th></th><th></th>\n"
+ : "<th></th>\n");
+ for (my $i = 0; $i < @parents; $i++) {
+ my $par = $parents[$i];
+ print "<th title=\"commitdiff to parent number " .
+ ($i+1) . ": " .
+ substr($par,0,7) . "\">" .
+ $cgi->a({-href => href(action=>"commitdiff",
+ hash=>$hash, hash_parent=>$par)},
+ $i+1) .
+ " </th>\n";
+ }
+ print "</tr>\n";
+ }
+
my $alternate = 1;
my $patchno = 0;
foreach my $line (@{$difftree}) {
--
1.5.2
^ permalink raw reply related
* Re: git-svn and SVK mirror between two repositories
From: Vinubalaji Gopal @ 2007-05-26 23:34 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46574C23.3080500@midwinter.com>
On 5/25/07, Steven Grimm <koreth@midwinter.com> wrote:
> I don't know how svk would change things, but I did something similar
> and wrote it up here:
> http://thread.gmane.org/gmane.comp.version-control.git/45060
Looks good and I am almost looking for the same thing. I just want to
get rid of svk and use only git to manage the same thing. It would be
great if you could share the commands you used to have that kind of
setup.
--
Vinu
In a world without fences who needs Gates?
^ permalink raw reply
* [PATCH] move template_dir logic to configure script.
From: Han-Wen Nienhuys @ 2007-05-26 23:07 UTC (permalink / raw)
To: git
---
config.mak.in | 2 +-
configure.ac | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 9a57840..12a541f 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -12,7 +12,7 @@ exec_prefix = @exec_prefix@
bindir = @bindir@
#gitexecdir = @libexecdir@/git-core/
datarootdir = @datarootdir@
-template_dir = @datadir@/git-core/templates/
+template_dir = @template_dir@
mandir=@mandir@
diff --git a/configure.ac b/configure.ac
index 7cfb3a0..d1622a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -323,6 +323,12 @@ GIT_PARSE_WITH(iconv))
# change being considered an inode change from the update-cache perspective.
+
+AC_SUBST(template_dir)
+if test "$template_dir" = ""; then
+ template_dir='${datadir}/git-core/templates/'
+fi
+
## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
--
1.5.0.6
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-26 23:08 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, git
In-Reply-To: <fcaeb9bf0705211122sef3abf6sb3633f09228a7e7d@mail.gmail.com>
Nguyen Thai Ngoc Duy escreveu:
>> > > warning: templates not found /usr/share/git-core/templates/
>> > >
>>
>> This should have been fixed by 2d84ffaf (currently master~1 in
>> git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
>> your build picks up the new Makefile setting that these commits
>> introduce?
>
> That commit didn't work for me because template_dir was overridden by
> config.mak.autogen
thanks for noticing this. I'm building a -2 release which should fix this.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [RFC] How to show merge commits in gitweb?
From: Jakub Narebski @ 2007-05-26 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <200705171239.24300.jnareb@gmail.com>
I have asked questions cited below (with no answer as of yet) because
I needed to have terminology right when describing merge commits diff
in gitweb.
People asked that 'commitdiff' view in gitweb used compact combined
(--cc) and not more verbose combined (-c) format for merges. The
problem lies in the fact that due to chunk simplification for `--cc'
some patches might be dropped completely from the patchset part, while
respective line is still present in the difftree/raw format part; the
difftree/raw part is the same for `-c' and for `--cc'. Because difftree
(whatchanged-like) has inner (anchor) links to respective patch (part
of patchset) there is problem what to do for lines which have no
corresponding patch (because it got simplified).
git-diff-tree(1):
[...]
--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
and '-p' options and further compresses the patch output
by omitting hunks that show differences from only one
parent, or show the same change from all but one parent
for an Octopus merge. When this optimization makes all
hunks disappear, the commit itself and the commit log
message is not shown, just like in any other "empty diff" case.
One solution is for gitweb to add fake missing patches, with the message
(in the place of patch body, or in extended diff header) that the diff
is empty: for example "Clean merge"... although empty `--cc' patch does
not need to mean clean merge, see below.
Other solution would be to change raw output format for "diff --cc",
or change difftree body output, which would need parsing patchset first.
P.S. By the way, should gitweb output `-c' diff if `--cc' patchset
output is empty, and to "show from which parent file came from" based
on `-m' output if `-c' output is empty (on tree-level / trivial
merges)?
On Thu, 17 May 2007, Jakub Narebski wrote:
> What is the definition of a trivial merge? Is it tree-level merge, for
> which git-diff -c output would be empty?
Trivial merge means that changes occured only on one branch, and we take
result from this branch; see Documentation/technical/trivial-merge.txt
Tree-level merge means that the result is taken from one of the parents.
I think that while trivial merge is tree-level merge, they do not
necessary mean the same: the result of merge using 'theirs' strategy is
tree-level merge, but not trivial merge. The same in the case of
conflicts resolved to the version from one of the parents.
"git diff -c" output is empty for tree-level merge.
> What is the definition of clean merge? Is it merge without conflicts?
> How to name merge for which git-diff --cc output is empty: simple
> merge perhaps? I think it does not need to be clean merge in the "no
> conflicts" meaning.
IMHO clean merge is a merge in which there can be file-level conflicts,
but they resolve cleanly. Clean merge is I think a merge in which
change in a chunk comes always from one of the parents (we can have non
tree-level merge only for merging two branches, not for an octopus),
but not all merges which have "git diff --cc" output empty are clean
merges.
BTW. the fact that merge resolves cleanly, without need for manual
intervention, depends in git also on what do you have in rr-cache
(recorded resolutions).
> What is the definition of evil merge? Is it merge for which merge
> commit is different from all the parents? How to name merge for which
> git-diff --cc output is non empty, then?
evil merge::
An evil merge is a merge that introduces changes that
do not appear in any parent.
But not only evil merges can have "git diff --cc" output non-empty.
Summary: merges for which "git diff -c" is empty are tree-level merges,
usually trivial merges; merges for which "git diff --cc" is empty are
simple merges, usually clean merges.
Please correct me if I'm wrong. TIA.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-26 22:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705262318190.4648@racer.site>
Johannes Schindelin escreveu:
>>> * git version reports just:
>>>
>>> git version -dirty
>>>
>>> Since git-gui parses the output of git version, but does not expect it
>>> to be of this format, and fails with an error message that it cannot
>>> parse the version.
>> My biggest problem is that the makefiles of git are an unmitigated
>> disaster, and there seems to be little interest in solving this
>> problem. For example, my suggestion to introduce autoconf was met with
>> derision.
>
> Well, I would not call it derision. But many people have had bad
> experience with that big mess which is autoconf, so we were more than
> reluctant to do it.
autoconf is not that big a mess, but it is a macrolanguage, which does
come with its pitfalls. Automake and libtool are the messy things,
and I prefer to stay away from them as far as possible.
The point of autoconf is to generate a hyper-portable script that
deals with all the different flavors of shell breakage. For the user
it simplifies compiling packages enormously, which IMO should be the
guiding concern if you like to have users.
For a pretty run-of-the-mill tool like git (dependency wise), it
should be easy to write a working configure.in.
My favorite approach is: use autoconf to generate
- config.h
- config.make
All settings that force recompile should be in config.h, and standard
C methods to track dependencies will take care of the recompilation
when anything changes. The main Makefile includes config.make, and
contains all configurable settings. The Makefile only needs to be
edited by developers. Require GNU Make so you can write sane
makefiles.
Instead, we have a Makefile that relies on an esoteric combination of
perl and shell scripting inside Makefiles.
Also, the Makefile says.
# Shell quote (do not use $(call) to accommodate ancient setups);
I think it would be better to have a clearly defined list of optional
and required dependencies with version numbers, and then stand by
that. For example, Make uses a completely autoconf/libtool based
compile process, and is easy to compile. I think it would be
reasonable to require a recent make, say 3.80, and then use its
features.
> In the meantime, we do have a configure.ac, though. In general, you do not
> have to run it, but you can if "make" does not work out of the box.
>
> I have to admit that it is unclear to me what are the problems with the
> Makefile with regards to gub. I think I will just bite the apple, and
> download that beast to try it myself.
>From what I recall, it tries to be too clever in detecting changes
of the make command line, forcing a recompile (possibly with erroneous paths)
during the
make install
I might be mistaken, though. I tried to get something up as fast as
possible.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH v3] Prevent megablobs from gunking up git packs
From: Junio C Hamano @ 2007-05-26 22:51 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <465887AB.1010001@gmail.com>
Dana How <danahow@gmail.com> writes:
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 19b0aa1..59be849 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> ...
> @@ -371,8 +372,6 @@ static unsigned long write_object(struct sha1file *f,
> pack_size_limit - write_offset : 0;
> /* no if no delta */
> int usable_delta = !entry->delta ? 0 :
> - /* yes if unlimited packfile */
> - !pack_size_limit ? 1 :
> /* no if base written to previous pack */
> entry->delta->offset == (off_t)-1 ? 0 :
> /* otherwise double-check written to this
> @@ -408,7 +407,7 @@ static unsigned long write_object(struct sha1file *f,
> buf = read_sha1_file(entry->sha1, &type, &size);
> if (!buf)
> die("unable to read %s", sha1_to_hex(entry->sha1));
> - if (size != entry->size)
> + if (size != entry->size && type == obj_type)
> die("object %s size inconsistency (%lu vs %lu)",
> sha1_to_hex(entry->sha1), size, entry->size);
> if (usable_delta) {
I do not quite get how these two hunks relate to the topic of
this patch. Care to enlighten?
> @@ -564,6 +563,17 @@ static off_t write_one(struct sha1file *f,
> return 0;
> }
>
> + /* refuse to include as many megablobs as possible */
> + if (max_blob_size && e->size >= max_blob_size) {
> + struct stat st;
> + /* skip if unpacked, remotely packed, or loose anywhere */
> + if (!e->in_pack || !e->in_pack->pack_local || find_sha1_file(e->sha1, &st)) {
> + e->offset = (off_t)-1; /* might drop reused delta base if mbs less */
> + written++;
> + return offset;
> + }
> + }
> +
> e->offset = offset;
> size = write_object(f, e, offset);
> if (!size) {
I thought that you are simply ignoring the "naughty blobs"---why
should it be done this late in the call sequence? I haven't
followed the existing code nor your patch closely, but I wonder
why the filtering is simply done inside (or by the caller of)
add_object_entry(). You would need to do sha1_object_info()
much earlier than the current code does, though.
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-26 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <7v4plzi508.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 26 May 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> In this, part of the pain is that Git tries to guess the version number
> >> by itself in a complicated way.
> >
> > Yes, I never understood that myself why it has to be so complicated. But
> > then, it did not make _my_ life hard, so I did not care.
>
> "echo "MyVersionNumber" >version && make"?
Good to know!
> > OTOH, it _is_ a nice thing to protohype the new commands as shell or perl
> > scripts. When they stabilize enough, convert them to builtins.
>
> Protohype is a nice word. Throw out a half-working stuff and
> advertise it as the best thing since sliced bread even before it
> starts to being useful ;-)
It started out as a typo. But then I liked it so much that I kept it ;-)
> > With add--interactive, I think it's better to leave it [...]
>
> I do not follow you here.
You mentioned several times that you were unsure if add--interactive was a
good idea. But I like it very much.
>
> > But remote will soon be the center of my crosshairs.
>
> I am afraid that it might be a bit premature.
>
> I've been hoping that we can make git-clone a thin wrapper
> around init/remote/fetch/checkout. For one thing, we would want
> to split the separate-remotes layout and bareness to create
> "mirror" (I called it "pure" previously, but this is really a
> mirror) layout for git-clone, among other things, and that kind
> of enhancements would need to be done inside git-remote.
Fair enough.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT on MinGW problem
From: Junio C Hamano @ 2007-05-26 22:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <Pine.LNX.4.64.0705262318190.4648@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> In this, part of the pain is that Git tries to guess the version number
>> by itself in a complicated way.
>
> Yes, I never understood that myself why it has to be so complicated. But
> then, it did not make _my_ life hard, so I did not care.
"echo "MyVersionNumber" >version && make"?
> OTOH, it _is_ a nice thing to protohype the new commands as shell or perl
> scripts. When they stabilize enough, convert them to builtins.
Protohype is a nice word. Throw out a half-working stuff and
advertise it as the best thing since sliced bread even before it
starts to being useful ;-)
> There are exactly 4 perl scripts left that I regularly use:
>
> add--interactive, cvsimport, remote and svn.
>
> I somehow have the feeling that it is not worth the effort to convert
> cvsimport and svn. With add--interactive, I think it's better to leave it
> as is before Junio goes on another "what have I done? why did I have to
> add _this_?" spree.
I do not follow you here.
> But remote will soon be the center of my crosshairs.
I am afraid that it might be a bit premature.
I've been hoping that we can make git-clone a thin wrapper
around init/remote/fetch/checkout. For one thing, we would want
to split the separate-remotes layout and bareness to create
"mirror" (I called it "pure" previously, but this is really a
mirror) layout for git-clone, among other things, and that kind
of enhancements would need to be done inside git-remote.
^ permalink raw reply
* Re: MinGW port updated to 1.5.2
From: Han-Wen Nienhuys @ 2007-05-26 22:32 UTC (permalink / raw)
To: git
In-Reply-To: <001201c79fdd$f1b7eca0$0200a8c0@AMD2500>
Aaron Gray escreveu:
>> Aaron Gray escreveu:
>>>>> GIT_EXTERNAL_DIFF works now.
>>>>
>>>> http://lilypond.org/git/binaries/mingw/
>>>>
>>>> uploading as I speak. Untested.
>>>
>>> This installs to "C:\Program Files\Git" and is not availiable on the
>>> path. What is going on here please ?
>>
>> this uses the same buildscripts as before, so if it worked, it should
>> still work. The path should point to $PF/Git/usr/bin/ ; you might need to
>> log out and log in again for the path to visible.
>
> Still not working properly.
>
> From CMD.EXE, neither 'git clone' and 'git-clone' are accessable.
- does the registry key HKLM SYSTEM\CurrentControlSet\Control\Session Manager\Environment
contain a PATH variable containing /Program Files/Git/usr/bin as an entry?
- what is the value of the PATH variable in CMD ?
- if this doens't work, please uninstall (run uninstall.exe) and rerun
the installer from the command line with the /S switch; this should generate
an install.log in $PF/Git/ . Send this to the list, or, if it's very big, send
send by private mail.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-26 22:26 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <f3a2ke$9s7$1@sea.gmane.org>
Hi,
On Sat, 26 May 2007, Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu:
> >>
> >> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> >>
> >> it should also set $PATH.
> >
> > I gave this some more testing and it turns out to be a well working
> > toolset. Thank you very much!
> >
> > There were still some issues remaining. These are the ones that should
> > be fixable easily:
> >
> > * git version reports just:
> >
> > git version -dirty
> >
> > Since git-gui parses the output of git version, but does not expect it
> > to be of this format, and fails with an error message that it cannot
> > parse the version.
>
> My biggest problem is that the makefiles of git are an unmitigated
> disaster, and there seems to be little interest in solving this
> problem. For example, my suggestion to introduce autoconf was met with
> derision.
Well, I would not call it derision. But many people have had bad
experience with that big mess which is autoconf, so we were more than
reluctant to do it.
In the meantime, we do have a configure.ac, though. In general, you do not
have to run it, but you can if "make" does not work out of the box.
I have to admit that it is unclear to me what are the problems with the
Makefile with regards to gub. I think I will just bite the apple, and
download that beast to try it myself.
> In this, part of the pain is that Git tries to guess the version number
> by itself in a complicated way.
Yes, I never understood that myself why it has to be so complicated. But
then, it did not make _my_ life hard, so I did not care.
> I thought the policy was to abandon Perl scripts for git commands?
Alas, no. We even have picked up a few since.
OTOH, it _is_ a nice thing to protohype the new commands as shell or perl
scripts. When they stabilize enough, convert them to builtins.
There are exactly 4 perl scripts left that I regularly use:
add--interactive, cvsimport, remote and svn.
I somehow have the feeling that it is not worth the effort to convert
cvsimport and svn. With add--interactive, I think it's better to leave it
as is before Junio goes on another "what have I done? why did I have to
add _this_?" spree.
But remote will soon be the center of my crosshairs.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-26 22:17 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Johannes Sixt, git
In-Reply-To: <46588DA4.5020109@xs4all.nl>
Hi,
[before answering: a big thank you, Han-Wen, for doing that work. I think
it is very valuable, especially because except Johannes Sixt, I have yet
to encounter a person wanting "naive" Windows Git, but not hiding under
the next rock when it comes to work on it.]
On Sat, 26 May 2007, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> >
> > On Fri, 25 May 2007, Johannes Sixt wrote:
> >
> >> * I personally think that the files should go into
> >>
> >> $PROGRAMFILES/Git/{bin,share,lib}
> >> instead of
> >> $PROGRAMFILES/Git/usr/{bin,share,lib}
> >
> > Agree. It is trivial, but it will help others. It might also be a good
> > idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it
> > is working, that is).
> >
> >> * git-gui and gitk don't work out of the box because they have the path
> >> to wish hardcoded. They can't be started from CMD at all. I have written
> >> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> >>
> >> @echo off
> >> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> >>
> >> But as you can see, the path is still hard-coded (but it is good enough
> >> for me for the moment).
> >
> > I'd also like to see bash, perl and wish bundled with the install (Windows
>
> Where is the info on the wish and bash port to Mingw?
I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.)
Worked out of the box:
http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz
http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
(Now, if only Python worked like that...)
There's a bash src in the Snapshot package of MinGW:
http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download
Ciao,
Dscoh
^ permalink raw reply
* Re: MinGW port updated to 1.5.2
From: Aaron Gray @ 2007-05-26 21:36 UTC (permalink / raw)
To: hanwen, git
In-Reply-To: <4658A01E.5060209@xs4all.nl>
> Aaron Gray escreveu:
>>>> GIT_EXTERNAL_DIFF works now.
>>>
>>> http://lilypond.org/git/binaries/mingw/
>>>
>>> uploading as I speak. Untested.
>>
>> This installs to "C:\Program Files\Git" and is not availiable on the
>> path. What is going on here please ?
>
> this uses the same buildscripts as before, so if it worked, it should
> still work. The path should point to $PF/Git/usr/bin/ ; you might need to
> log out and log in again for the path to visible.
Still not working properly.
>From CMD.EXE, neither 'git clone' and 'git-clone' are accessable.
>From MSYS '/usr/share/git-core/templates/' is not accessable.
$ git clone git://git.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in C:/MSYS/home/Aaron Gray/git/.git/
warning: templates not found /usr/share/git-core/templates/
Another issue is git-clone is no atomic if it fails it leaves an open file
that can only be deleted by logging off and on again.
Aaron
^ 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