* Re: master has some toys
From: Junio C Hamano @ 2005-11-17 11:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511170236r28572db9i84dc271700ded79a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> As it turned out, not the git.c is guilty, but the missing
> NO_MMAP=YesPlease in Cygwin section. I had it for a long time and
> accidentally removed by the recent pull. BTW, I couldn't find nowhere
> on original branch. Was it never submitted?
Neither 'git-whatchanged Makefile' nor 'git-whatchanged
-SNO_MMAP Makefile' reports such on my end. Do we need one?
Johannes said he tests on Cygwin as well, and I am sure there
are others with Cygin on the list. Help us out here please?
^ permalink raw reply
* Re: [PATCH 0/4] reworking git-rebase
From: Junio C Hamano @ 2005-11-17 10:57 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20051117103027.GR8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> Will the reworked rebase still support this use or is there
> a better way to do this ?
I think it is reasonable to assume that you would not usually
want to muck with commits that cleanly replay. Further, you
would do that kind of irregular replaying (e.g. not replaying
all of them, or skipping some of them) only after one of the
commit fails to cleanly replay, and you would not mind (rather,
you would be happy) to keep the commits that have been already
cleanly replayed, and would start playing games like dropping
patches after the one that fails.
If the above is a reasonable assumption, then, the answer is
yes. And if not, you can always resort to manual
"git-format-patch -k", followed by file editing, followed by
"git am -k -3", to reorder patches. Although at that point you
should either be looking at StGIT or doing a just plain merge.
When "git am" first fails, all the rest of patches are kept in
.dotest/. And after fixing up the failed one in your working
tree, you can restart it with interactive flag, like this: "git
am -i -3 --resolved". It lets you tell it skip one patch, or
not apply any of the rest. [Side note: it might be a good idea
to make --resolved imply --interactive].
Quite often, the reason why a rebased patch does not apply is
because an equivalent patch (or a set of patches whose
cumulative effect is the same as one of your patches) has been
thrown in to the new "master". "git cherry" is too dumb (IOW,
git-patch-id is too strict) to notice such cases. "git am -3"
first tries to do git-apply, and when it fails (and it will fail
if your working tree already has what the patch would do), it
falls back to 3-way merge by picking up the pre-image blob ids
recorded in the patch. When seeing an already applied patch,
this 3-way merge often results in the same tree as you started.
When "git am" notices the situation, it throws away that patch
(it says "already applied") automatically.
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-17 10:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511160837000.13959@g5.osdl.org>
Hi Linus
2005/11/16, Linus Torvalds <torvalds@osdl.org>:
>
>
> First off, "rsync://" will never do what you want. It uses rsync
> (surprised surprise) to grab the objects, so since it has no clue what the
> objects are, it has no choice but to just grab them all.
>
yes that was a bad example, actually I've tried several protocol
including git protocol.
> The fact that _some_ of the linux-mips repositories are based on mine
> makes me suspect that all their 2.6-based ones are rooted like mine is,
> but that may or may not be true.
>
hmm, don't think "linux mips" repository is rooted like yours. It
seems that it has been imported from mips cvs repository which
contains linux-mips history since 1995.
> Just try your above command line with "git://" instead.
>
> (NOTE! Doing a full clone like the above is pretty expensive with git for
> the server side, so it might take a while before it starts feeding you
> stuff if it is under heavy load)
>
well I've already tried that but have renounced after waiting more
than 4 hours ! I don't know if the server was under heavy load or if
git protocol needs a lots of resources but it seems useless to setup a
git dameon on it...
> If you want to get rid of other branches, do:
Sorry, I forget to tell that I have already tried what you suggested
at first (except that I did not do a 'git repack -a -d') but it didn't
work out (and that the reason why I tried the "kill father object"
thing). Since I forgot the repack thing, I retried again, and it did
last more than 4 hours to cpmplete all git commands. After that I run
gitk --all to check that all old branch's objects have been removed
but I can see all of them.
I plan to take look at git code to understand how object removal is
done, but until this do you have any ideas why this fails ?
Thanks
--
Franck
^ permalink raw reply
* Re: master has some toys
From: Alex Riesen @ 2005-11-17 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy83ny450.fsf@assigned-by-dhcp.cox.net>
On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
> > cygwin is completely broken. Still debugging, but it looks like the
> > old "windows can't unlink/rename open files" problem.
>
> Ouch. Sorry, and thanks for reporting.
As it turned out, not the git.c is guilty, but the missing
NO_MMAP=YesPlease in Cygwin section. I had it for a long time and
accidentally removed by the recent pull. BTW, I couldn't find nowhere
on original branch. Was it never submitted?
> Ideally I should get a cygwin environment myself, but for that
> first I need to procure Windows box. Or does cygwin run on
> Wine, and if so is cygwin running on Wine a good enough
> approximation of the real thing?
I don't know. One should try real hard to create as much junk as there is.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Junio C Hamano @ 2005-11-17 10:33 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051117021014.GC3968@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Assuming --vernum does work, is there a reasonable/portable way to
> compare two hex values like 070801?
I would assume that it is always 6 lowercase hexdigits %06x when
supported, or showing nothing to stdout for ancient ones.
A horrible but probably portable way would be:
case `(echo 070801; curl-config --vernum) 2>/dev/null |
sort -r | sed -ne 2p` in
070801)
echo Happy ;;
*)
echo Sad ;;
esac
The obvious one is unfortunately not very portable:
if test 070801 \< `curl-config --vernum`
then
echo "Happy"
else
echo "Sad"
fi
This would work if your test is bash/dash-builtin. The
following do not seem to know about '<' '>' string comparison:
GNU /usr/bin/test from coreutils (version 5.2.1)
OpenBSD shell builtin
Solaris /usr/bin/test
^ permalink raw reply
* Re: [PATCH 0/4] reworking git-rebase
From: Sven Verdoolaege @ 2005-11-17 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe4lfpxm.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 15, 2005 at 03:32:05PM -0800, Junio C Hamano wrote:
> It notes that fact, and goes ahead to apply D and E, and at the
> very end tells you to deal with C by hand. Even if you somehow
> managed to replay C on top of the result, you would now end up
> with ...-B-...-U-A-D-E-C.
Actually this is sometimes useful when rewriting history.
Suppose you cherry-pick two changes that touch the same piece
of code and combine them into a single change and then rebase
all your changes on top of this combined change.
The two cherry-picked changes will not apply and end up and
at the end of the chain where you can simply discard them.
Will the reworked rebase still support this use or is there
a better way to do this ?
skimo
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-17 10:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511170029xac34cdbtddf74eb766281b3c@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> cygwin is completely broken. Still debugging, but it looks like the
> old "windows can't unlink/rename open files" problem.
Ouch. Sorry, and thanks for reporting.
Ideally I should get a cygwin environment myself, but for that
first I need to procure Windows box. Or does cygwin run on
Wine, and if so is cygwin running on Wine a good enough
approximation of the real thing?
^ permalink raw reply
* Re: [PATCH] archimport improvements
From: Martin Langhoff @ 2005-11-17 9:26 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051112092336.GA16218@Muzzle>
Eric,
I've merged and pushed out to
http://locke.catalyst.net.nz/git/git-martinlanghoff.git/#tojunio
[PATCH 1/5] remove shellquote usage for tags
[PATCH 2/5] archimport: don't die on merge-base failure
[PATCH 3/5] Disambiguate the term 'branch' in Arch vs git
[PATCH 1/2] archimport: allow for old style branch and public tag names
That last one had a small edit to rebase it to the top of the head --
will probably have a small conflict for you on the usage line and
getopts() line.
What is pending is...
* [PATCH 4/5] Overhaul of changeset application
I am testing it right now. Finding it rather slow on an idle linux
workstation with fast IDE disks, no X.org loaded and 1GB or RAM.
iowait is pegged at 90%. Wonder what will happen on a system with slow
disk access. tla/baz are unusable under any OS where the fs stack is
not _that_ polished (OSX and friends).
The early versions of the import also used $TLA for all ops, and I was
forced to change it to get my repos transformed in a reasonable time.
Can you send me a patch that makes it optional, so users can choose
fast or correct? I don't want to force glacial imports on anyone,
specially me. Testing an import of a reasonably sized repo must be a
quick operation or I won't do it ;-) And I do work on OSX too.
On the other hand, I might just implement renamed directories tracking
separately, specially if someone can point me to a public repo with
some interesting cases of renamed directories.
These patches seem to hang from 4/5 so will need rebasing after a
reworked. The first one seems to be 3 or 4 patches in one. It'd be
good to break it up.
* [ PATCH 5/5] -D <depth> option to recurse into merged branches
* Re: [PATCH 5/5] -D <depth> option to recurse into merged branches
* [PATCH 2/2] archimport: sync_to_ps() messages for tracking tla methods
If you want to see the repos I'm testing with, register
arch-eduforge@catalyst.net.nz--2004
http://nzvle.eduforge.org/arch-mirror/ and try:
~/local/git/git-archimport.perl -v \
arch-eduforge@catalyst.net.nz--2004/moodle-org--moodle \
arch-eduforge@catalyst.net.nz--2004/moodle--local \
arch-eduforge@catalyst.net.nz--2004/moodle--local-forum-types \
arch-eduforge@catalyst.net.nz--2004/moodle--local-lock-content \
arch-eduforge@catalyst.net.nz--2004/moodle--nmit \
arch-eduforge@catalyst.net.nz--2004/moodle--topnz
cheers,
martin
^ permalink raw reply
* Re: master has some toys
From: Alex Riesen @ 2005-11-17 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jb83w8m.fsf_-_@assigned-by-dhcp.cox.net>
On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
> Along with the git wrapper fixes and git-apply bugfix (it did
cygwin is completely broken. Still debugging, but it looks like the
old "windows can't unlink/rename open files" problem.
^ permalink raw reply
* Re: git-pack-redundant returns the most containing pack
From: Alex Riesen @ 2005-11-17 7:45 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <437BBF5D.5040105@etek.chalmers.se>
On 11/17/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:
> > ...which very confusing: "git-repack -a -d" leaves the repository with
> > exactly the same packs as before, by creating a super-pack, and then
> > happily removing it, because pack-redundant returns the newly created
> > pack!
> >
> > So, even if it is logically correct, it's hardly useful in practice.
>
> That's bad. Your new pack should contain some objects not present in
> the older packfiles and thus it shouldn't be removed, unless there
> were no new objects to pack.
there weren't: "ls .git/objects" showed only pack/ and info/
> If no new objects were packed, the sum of the old packs might be smaller
> than the new superpack, or the old packs could contain unreachable objects,
> which makes git-pack-redundant unable to detect that they should be removed.
that _could_ be the case. I run git-fsck-objects --full in that
repository and saw some unreferenced tags.
> Could you try updating to the latest snapshot? There was a bug in a
> list handling function which was fixed recently, perhaps your problem
> is related.
will try, but I didn't realize yesterday that it might be a good idea
to keep the old repository around. The lot of packs was automatically
created by incremental repacking after every pull. Sorry...
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Fredrik Kuivinen @ 2005-11-17 7:08 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Linus Torvalds, Alex Riesen, junkio
In-Reply-To: <437BA6A6.8080900@etek.chalmers.se>
On Wed, Nov 16, 2005 at 10:37:42PM +0100, Lukas Sandström wrote:
> Linus Torvalds wrote:
> >
> > On Tue, 15 Nov 2005, Alex Riesen wrote:
> >
> >>Sorry, it doesn't. The code loops here:
> >>
> >>401 /* find the permutations which contain all missing objects */
> >>402 perm_all = perm = get_all_permutations(non_unique);
> >
> >
> > Looks like the whole thing is exponential.
> >
> Slightly less, but not far from.
> > A good way to do sane pack handling is to keep a _sorted_ list of all
> > objects each pack has. At that point it becomes much easier to see which
> > objects only exist in one particular pack.
> >
> git-pack-redundant already does this.
> > The sorting itself is O(nlogn), and the "does this pack have any unique
> > objects" (or "is this pack a superset of all other packs") question should
> > then be O(n).
> >
> Ah, but the question is: "Does this set of packs contain a superset of
> all objects available in packfiles?" The answer to the question for a
> certain set is indeed O(n), but the number of sets which have to be tested
> are ~ O(e**n). (Where n is the number of non-unique packs.)
>
If haven't looked closely at neither the packing nor the pack
redundant code, but the problem looks very similar to Minimum Set
Cover (see http://www.nada.kth.se/~viggo/wwwcompendium/node146.html
for more information), which is NP-hard. So, if Minimum Set Cover is
the problem we are trying to solve we can't hope to find a polynomial
time algorithm. However, there is a quite simple greedy approximation
algorithm in [1] which is referenced from the URL above.
- Fredrik
[1]: Johnson, D. S. (1974), "Approximation algorithms for
combinatorial problems", J. Comput. System Sci. 9, 256-278.
^ permalink raw reply
* [ANNOUNCE] GIT 0.99.9j aka 1.0rc3
From: Junio C Hamano @ 2005-11-17 6:36 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 0.99.9j aka 1.0rc3 is found at usual places.
Notable change since 1.0rc2 are:
- RPM packages has been split a bit differently [H. Peter
Anvin]. Simon Richter asked me not to muck with debian
packaging, so I take that Simon volunteered to update things
to match what happened to RPM side.
- On platforms and filesystems that can handle symlinks, you
can now force symbolic refs by configuration item
core.symrefsonly [Johannes Schindelin].
- http-fetch is less leaky [Petr Baudis, Nick Hengeveld].
- fsck-objects and refs tracking uses much less memory [Sergey
Vlasov].
- git wrapper is rewritten in C [Andreas Ericsson].
- diff piped to patch inside a single repository is made binary
safe [me]
There was a discussion to always use symrefs for .git/HEAD; this
will _not_ happen before 1.0. It breaks too many exiting tools
without giving them enough advance notice.
The proposed updates branch has a couple of topics I consider
1.0 material.
- git-log --since="two weeks ago", without using GNU date [Linus]
- git-rebase to use "diff-piped-to-patch" [me]
- git-branch -f to forcibly reset branch head [me]
Here is the shortlog.
Alecs King:
Documentation/git-log.txt: trivial typo fix.
Andreas Ericsson:
git-daemon: --inetd implies --syslog
C implementation of the 'git' program, take two.
Update git(7) man-page for the C wrapper.
git --help COMMAND brings up the git-COMMAND man-page.
daemon.c: fix arg parsing bugs
H. Peter Anvin:
git-core-foo -> git-foo, except the core package
Johannes Schindelin:
Add config variable core.symrefsonly
Fix tests with new git in C
Give python a chance to find "backported" modules
Jonas Fonseca:
Fix git(1) link to git-index-pack
Junio C Hamano:
Documentation: do not blindly run 'cat' .git/HEAD, or echo into it.
diff: make default rename detection limit configurable.
sha1_file.c::add_packed_git(): fix type mismatch.
git wrapper: basic fixes.
git-apply: fail if a patch cannot be applied.
git-am: --resolved.
apply: allow-binary-replacement.
diff: --full-index
tests: binary diff application.
Kevin Geiss:
git-cvsexportcommit.perl: Fix usage() output.
git-cvsexportcommit.perl: use getopts to get binary flags
git-cvsexportcommit.perl: exit with non-0 status if patch fails.
git-cvsexportcommit.perl: fix typos in output
Linus Torvalds:
Disallow empty pattern in "git grep"
Lukas Sandström:
Fix llist_sorted_difference_inplace in git-pack-redundant
Pavel Roskin:
symref support for import scripts
Petr Baudis:
Fix bunch of fd leaks in http-fetch
Sergey Vlasov:
git-fsck-objects: Free tree entries after use
Rework object refs tracking to reduce memory usage
^ permalink raw reply
* Re: [PATCH] git-commit: Having $GIT_COMMITTER_NAME implies -s
From: H. Peter Anvin @ 2005-11-17 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vbr0j3nku.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I am not so sure about this. A Signed-off-by line used in the
> kernel and git projects has a specific meaning; you've read
> SubmittingPatches in either projects, have'nt you?
>
> I do work on a machine from which I make commits to both git
> project and my day-job work project. I do not necessarily want
> to add Signed-off-by line in commits I make for the latter.
>
More importantly, it's vital that a Signed-off-by: line is always added
with explicit awareness of the signer.
-hpa
^ permalink raw reply
* Re: [PATCH] git-commit: Having $GIT_COMMITTER_NAME implies -s
From: Junio C Hamano @ 2005-11-17 4:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051116233829.0B3C55BA81@nox.op5.se>
I am not so sure about this. A Signed-off-by line used in the
kernel and git projects has a specific meaning; you've read
SubmittingPatches in either projects, have'nt you?
I do work on a machine from which I make commits to both git
project and my day-job work project. I do not necessarily want
to add Signed-off-by line in commits I make for the latter.
^ permalink raw reply
* Re: [RFC] git email submissions
From: H. Peter Anvin @ 2005-11-17 2:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jeff Garzik, Git Mailing List
In-Reply-To: <46a038f90511161638l61d8a8bjbfbeaa92041298f7@mail.gmail.com>
Martin Langhoff wrote:
> On 11/17/05, Jeff Garzik <jgarzik@pobox.com> wrote:
>
>>For people without _any_ hosting, it would be nice to give them a method
>>to submit some git changes via email.
>
>
> I'm sure SF.net will host GIT projects sooner or later. I'm planning
> on offering support on Eduforge.org as soon as I have some free time.
What would be *totally awesome* is if SF.net would also automatically
use "git cvsimport" to track the CVS-based projects thereon...
-hpa
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Nick Hengeveld @ 2005-11-17 2:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5l03whv.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 16, 2005 at 05:15:40PM -0800, Junio C Hamano wrote:
> > Is it worth trying to figure this out in the Makefile instead, using eg.
> > curl-config --vernum?
>
> If we can do that reliably, that would be very nice for the
> users. Might be worth a try.
Well, it looks as though the --vernum option was added prior to 7.8.1,
so if it doesn't work it's safe to assume that curl is too old - more
than ~4.5 years old in this case.
Assuming --vernum does work, is there a reasonable/portable way to
compare two hex values like 070801?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: Randal L. Schwartz @ 2005-11-17 1:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511170013470.9284@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Besides, the character is there, so why not use it? ;-)
It reminds me of when people typed "l" instead of "1" because typewriters
didn't have a "1".
In that manner, it's just plain wrong.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* master has some toys
From: Junio C Hamano @ 2005-11-17 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vr79g8mys.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Incidentally, for the last couple of days, I was working on
> adding a very limited binary file diff support to "diff piped to
> apply" pattern, and the result has been posted as "reworked
> rebase" patches. It is very limited in the sense that the diff
> output does not attempt to be useful if the patch consumer does
> not have both pre- and post-image blob, but for the use of
> StGIT's internal patch replaying purposes that is not a concern,
> so you might be interested in taking a look.
Along with the git wrapper fixes and git-apply bugfix (it did
not fail when it saw unapplicable binary patches), and
cvsexportcommit fixes from Kevin Geiss, I have the "limited
binary patch support" on the master branch. The reworked rebase
is still in proposed updates branch.
I'll be offline for a couple of hours chaffering my wife.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Junio C Hamano @ 2005-11-17 1:15 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051117004621.GB3968@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> On Thu, Nov 17, 2005 at 12:25:06AM +0100, Johannes Schindelin wrote:
>
>> #if LIBCURL_VERSION_NUM < 0x070801
>> #error http-push needs curl >= 7.8.1 (because of CURLOPT_HTTPGET)
>> #endif
>
> Is it worth trying to figure this out in the Makefile instead, using eg.
> curl-config --vernum?
If we can do that reliably, that would be very nice for the
users. Might be worth a try.
^ permalink raw reply
* Re: [Question] info/grafts file.
From: Ryan Anderson @ 2005-11-17 0:57 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Junio C Hamano, git
In-Reply-To: <20051115000349.GA32136@hpsvcnb.fc.hp.com>
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]
Carl Baldwin wrote:
> This is fine, I just needed to know.
>
> How hard is it to, in a generic way, take a grafts file and reconstruct
> commits to include the parents in the graft file in the actual tree? I
> am wondering because I couldn't, after much work, get git-svnimport to
> find my merges correctly. So, I am needing to hand-graft some merges in
> to make things right. Any suggestions? I could try to figure something
> out if I can find some time. I'm good with graph traversals and such.
It's actually pretty easy. I wrote a rough (and not quite safe) tool to
do this a week or so ago.
http://marc.theaimsgroup.com/?l=git&m=113131673606637&w=2
I will try and clean it up a bit and submit it for inclusion in contrib/
sometime this coming weekend, but you should be able to use it to solve
this problem.
It's pretty straightforward, honestly. (And I'm pretty sure it could be
faster if I did things slightly differently.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Nick Hengeveld @ 2005-11-17 0:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andrew Wozniak, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511170023040.9284@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 17, 2005 at 12:25:06AM +0100, Johannes Schindelin wrote:
> It was 7.8.1. I checked. You might want to add this somewhere:
>
> #if LIBCURL_VERSION_NUM < 0x070801
> #error http-push needs curl >= 7.8.1 (because of CURLOPT_HTTPGET)
> #endif
Is it worth trying to figure this out in the Makefile instead, using eg.
curl-config --vernum?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [RFC] git email submissions
From: Martin Langhoff @ 2005-11-17 0:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <437B4472.1080401@pobox.com>
On 11/17/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> For people without _any_ hosting, it would be nice to give them a method
> to submit some git changes via email.
I'm sure SF.net will host GIT projects sooner or later. I'm planning
on offering support on Eduforge.org as soon as I have some free time.
cheers,
martin
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Lukas Sandström @ 2005-11-16 23:59 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, Linus Torvalds, Alex Riesen, junkio
In-Reply-To: <437BA6A6.8080900@etek.chalmers.se>
Lukas Sandström wrote:
> Linus Torvalds wrote:
>
>>On Tue, 15 Nov 2005, Alex Riesen wrote:
>>
>>
>>>Sorry, it doesn't. The code loops here:
>>>
>>>401 /* find the permutations which contain all missing objects */
>>>402 perm_all = perm = get_all_permutations(non_unique);
>>
>>
>>Looks like the whole thing is exponential.
>>
>
> Slightly less, but not far from.
>
After doing some maths; actually it is very exponential. 2**n - 1 to be precise.
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Matthias Urlichs @ 2005-11-16 23:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511151227300.21902@wbgn013.biozentrum.uni-wuerzburg.de>
Hi, Johannes Schindelin wrote:
> It would be cool to have something like git-cvs-daemon, which simulates a
> CVS server.
read-only would not be that difficult. You'd have to cache CVS version
numbers for individual files and decide on a branch ordering, but those
are basically non-problems.
Don't even *think* about committing.
--
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
- -
Conscience is what hurts when everything else feels so good.
^ permalink raw reply
* [PATCH] git-commit: Having $GIT_COMMITTER_NAME implies -s
From: Andreas Ericsson @ 2005-11-16 23:38 UTC (permalink / raw)
To: git
I've been trying, in vain, to tell my colleagues to use the -s flag.
With this patch I can at least fix up their .profile's myself.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
git-commit.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
applies-to: a2fe76123d6f5b835d3312a70a02ed4d07e25f8e
d32c78570e25a9718721937b1ee9051e950ad1fd
diff --git a/git-commit.sh b/git-commit.sh
index 41955e8..ff9502c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -134,8 +134,7 @@ then
cat "$GIT_DIR/MERGE_MSG"
fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG
-case "$signoff" in
-t)
+if [ "$signoff" = t -o "$GIT_COMMITTER_NAME" ]; then
{
echo
git-var GIT_COMMITTER_IDENT | sed -e '
@@ -143,8 +142,7 @@ t)
s/^/Signed-off-by: /
'
} >>"$GIT_DIR"/COMMIT_EDITMSG
- ;;
-esac
+fi
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
echo "#"
---
0.99.9.GIT
^ 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