* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-05 5:25 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <20051005031642.GD1393@trixie.casa.cgf.cx>
Christopher Faylor wrote:
> That's a relief. Btw, AFAIK, strerror is working correctly under
> Cygwin also.
Now if we can only figure out why gitk is messed up...
-hpa
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Linus Torvalds @ 2005-10-05 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5mk7pv6.fsf@assigned-by-dhcp.cox.net>
On Tue, 4 Oct 2005, Junio C Hamano wrote:
>
> * I will be placing this in the proposed updates branch.
> Hopefully this would alleviate the complaints from people who
> find the "no fuzz" policy of git-apply is too strict.
This should definitely be enabled by a switch only.
For example, I use git-applypatch _only_ through git-applymbox. Ie
non-interactively. I definitely do _not_ want it to try random other trees
unless I tell it to, especially when applying a series of 175 patches in
one go.
Linus
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Christopher Faylor @ 2005-10-05 3:16 UTC (permalink / raw)
To: H. Peter Anvin, Alex Riesen, Git Mailing List
In-Reply-To: <434299DB.7020805@zytor.com>
On Tue, Oct 04, 2005 at 08:03:55AM -0700, H. Peter Anvin wrote:
>Alex Riesen wrote:
>>
>>I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove
>>the
>>target and returns an error (probably EPERM, but I have reasons not to
>>trust
>>strerror on that thing).
>>The repository was on FAT.
>>Taking "rename(2)" from cygwin's libiberty solved this (they unlink if
>>link(2)
>>returns EEXIST).
>>
>>PS: Does broken rename(2) qualify a system "not worthy to support"?
>
>I just tried this with Cygwin 1.5.18-1 and didn't have any such
>problems. I tried it on NTFS, FAT and Samba, using WinXP.
That's a relief. Btw, AFAIK, strerror is working correctly under
Cygwin also.
--
Christopher Faylor spammer? -> aaaspam@sourceware.org
Cygwin Co-Project Leader aaaspam@duffek.com
TimeSys, Inc.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Christopher Faylor @ 2005-10-05 3:15 UTC (permalink / raw)
To: H. Peter Anvin, Alex Riesen, Git Mailing List
In-Reply-To: <43428C65.3040205@zytor.com>
On Tue, Oct 04, 2005 at 07:06:29AM -0700, H. Peter Anvin wrote:
>Alex Riesen wrote:
>>
>>I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove
>>the
>>target and returns an error (probably EPERM, but I have reasons not to
>>trust
>>strerror on that thing).
>>The repository was on FAT.
>>Taking "rename(2)" from cygwin's libiberty solved this (they unlink if
>>link(2)
>>returns EEXIST).
>>
>>PS: Does broken rename(2) qualify a system "not worthy to support"?
>
>In this case a better way would be to just add -liberty to all link
>lines if necessary, but I would expect the core cygwin code to do this.
AFAIK, cygwin has a working rename(). Many packages rely on it.
If rename() is not working then a bug report with a test case would be
appreciated.
--
Christopher Faylor spammer? -> aaaspam@sourceware.org
Cygwin Co-Project Leader aaaspam@duffek.com
TimeSys, Inc.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-05 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0fx9c1c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>>If you have an ssh connection, you're writing over a pipe to the ssh
>>process, and your local buffer is that pipe, which is PIPE_BUF size.
>
> I vaguely recall there was an interesting regression in recent
> kernel history when the implementation of the pipe buffer was
> changed, with which, writing the same amount of data with
> different number of writes made things behave differently and
> making the worst case buffer size less than traditional 4K.
>
> I wonder if we are going to be bitten by that one...
>
The definition of PIPE_BUF is that a write to a pipe of no more than
PIPE_BUF bytes will either succeed immediately or block; it will not be
broken up into multiple writes (with potential interlace problems.) It
says *nothing* about what happens with multiple writes.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-05 2:38 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Chandler, git
In-Reply-To: <20051004210706.GA16161@kroah.com>
Greg KH wrote:
> On Mon, Oct 03, 2005 at 02:08:36PM -0700, H. Peter Anvin wrote:
>
>>I believe in the medium-to-long term a plugin architecture for merging
>>is imperative. It's not even different media types, but some *files*
>>have specific merging policies. Think, for example, of pci.ids in the
>>Linux kernel tree.
>
> You mean the file that is now removed from the kernel tree? Sure,
> that's a good merge policy :)
>
*Plonk*... well, the point was that even text files can be structured so
that application-specific merge rules can be made to apply. ChangeLogs
are another good example.
-hpa
^ permalink raw reply
* [PATCH] Fall back to three-way merge when applying a patch.
From: Junio C Hamano @ 2005-10-05 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
After git-apply fails, attempt to find a base tree that the patch
cleanly applies to, and do a three-way merge using that base tree into
the current index.
When the fall-back merge fails, the working tree can be resolved the
same way as you would normally hand resolve a conflicting merge.
When making commit, use .dotest/final-commit as the log message
template. Or you could just choose to 'git-checkout-index -f -a'
to revert the failed merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I will be placing this in the proposed updates branch.
Hopefully this would alleviate the complaints from people who
find the "no fuzz" policy of git-apply is too strict.
The change is helped if the patch sender uses the updated
git-format-patch that records which tree the patch is
supposed to cleanly apply to, but that is not strictly
necessary; it tries to find a tree that patch applies to from
the recent commits itself.
git-applypatch.sh | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 61 insertions(+), 1 deletions(-)
applies-to: 9eec9ff9326032bca405a12a265918725edf4ac7
fb533c6562481dfbc4719f740aa0d85e2a45700c
diff --git a/git-applypatch.sh b/git-applypatch.sh
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -105,7 +105,67 @@ git-apply --index "$PATCHFILE" || {
# Here if we know which revision the patch applies to,
# we create a temporary working tree and index, apply the
# patch, and attempt 3-way merge with the resulting tree.
- exit 1
+
+ O_OBJECT=`cd "$GIT_OBJECT_DIRECTORY" && pwd`
+ rm -fr .patch-merge-*
+
+ (
+ N=10
+
+ # if the patch records the base tree...
+ sed -ne '
+ /^diff /q
+ /^applies-to: \([0-9a-f]*\)$/{
+ s//\1/p
+ q
+ }
+ ' "$PATCHFILE"
+
+ # or hoping the patch is against our recent commits...
+ git-rev-list --max-count=$N HEAD
+
+ # or hoping the patch is against known tags...
+ git-ls-remote --tags .
+ ) |
+ while read base junk
+ do
+ # Try it if we have it as a tree.
+ git-cat-file tree "$base" >/dev/null 2>&1 || continue
+
+ rm -fr .patch-merge-tmp-* &&
+ mkdir .patch-merge-tmp-dir || break
+ (
+ cd .patch-merge-tmp-dir &&
+ GIT_INDEX_FILE=../.patch-merge-tmp-index &&
+ GIT_OBJECT_DIRECTORY="$O_OBJECT" &&
+ export GIT_INDEX_FILE GIT_OBJECT_DIRECTORY &&
+ git-read-tree "$base" &&
+ git-apply --index &&
+ mv ../.patch-merge-tmp-index ../.patch-merge-index &&
+ echo "$base" >../.patch-merge-base
+ ) <"$PATCHFILE" 2>/dev/null && break
+ done
+
+ test -f .patch-merge-index &&
+ his_tree=$(GIT_INDEX_FILE=.patch-merge-index git-write-tree) &&
+ orig_tree=$(cat .patch-merge-base) &&
+ rm -fr .patch-merge-* || exit 1
+
+ echo Falling back to patching base and 3-way merge using $orig_tree...
+
+ # This is not so wrong. Depending on which base we picked,
+ # orig_tree may be wildly different from ours, but his_tree
+ # has the same set of wildly different changes in parts the
+ # patch did not touch, so resolve ends up cancelling them,
+ # saying that we reverted all those changes.
+
+ if git-merge-resolve $orig_tree -- HEAD $his_tree
+ then
+ echo Done.
+ else
+ echo Failed to merge in the changes.
+ exit 1
+ fi
}
if test -x "$GIT_DIR"/hooks/pre-applypatch
---
0.99.8.GIT
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Linus Torvalds @ 2005-10-05 0:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vu0fx9c1c.fsf@assigned-by-dhcp.cox.net>
On Tue, 4 Oct 2005, Junio C Hamano wrote:
>
> I vaguely recall there was an interesting regression in recent
> kernel history when the implementation of the pipe buffer was
> changed, with which, writing the same amount of data with
> different number of writes made things behave differently and
> making the worst case buffer size less than traditional 4K.
Just for performance reasons, I ended up doing merging anyway, so in fact
regardless of how you write the current pipe buffer size is up to 16
pages.
I think you can safely assume that pretty much any file descriptor you use
has at least 1kB of buffer. Even 4kB is likely a "safe assumption", and in
reality, most of them end up having even more.
With something like ssh, you probably end up having even deeper ones,
since you end up having the local pty or socket to ssh, and then ssh has
the TCP buffer to the network..
Linus
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-04 22:38 UTC (permalink / raw)
To: cel; +Cc: git
In-Reply-To: <4342F9A4.1090600@citi.umich.edu>
Chuck Lever <cel@citi.umich.edu> writes:
> two quick notes:
>
> 1. git-update-ref has no documentation (i don't have time to sit down
> and construct it, otherwise i'd post a patch).
Thanks; neither git-symbolic-ref. I'll write them up.
> 2. what is your thinking about including the cache abstraction layer
> after 1.0 ? i think it would help the libification effort.
I haven't had a chance to look at the code Smurf is working on,
but I suspect that your cache abstraction work would interact
badly with it if done independently and made into mainline
first, and would end up requiring some parts of libification to
be redone.
From: Matthias Urlichs <smurf@smurf.noris.de>
Date: Mon, 03 Oct 2005 22:48:54 +0200
Message-ID: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>
I have started work on doing this "the right way"
(as per earlier discussion).
Current status: There's a toplevel "struct git_env", an associated "struct
git_objdb", and (thread-safe and globals-free) library code to read
sha1-identified object (meta)data, including packs and all.
http://netz.smurf.noris.de/git/git.git#libize
Next on my TODO list: introduce a "struct git_obj" which represents
exactly one sha1 and the metadata associated with it, rename the
accessor functions to be more consistent, add SWIG interface code and
Python testcases, submit to everybody's scrutinity.
After that, the task can hopefully be parallelized.
Definitely a post-1.0 job; the job is too big, and shipping 1.0 with a
partial library that doesn't do much that's useful does not make sense.
So if you have energy and inclination, I'd like to see you take
a look at the smurf tree, and if you can work with him and add
cache abstraction as part of the libification that would be the
ideal approach. Then hopefully nobody has to do work twice.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-04 22:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4342AF4B.7020806@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> If you have an ssh connection, you're writing over a pipe to the ssh
> process, and your local buffer is that pipe, which is PIPE_BUF size.
I vaguely recall there was an interesting regression in recent
kernel history when the implementation of the pipe buffer was
changed, with which, writing the same amount of data with
different number of writes made things behave differently and
making the worst case buffer size less than traditional 4K.
I wonder if we are going to be bitten by that one...
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Chuck Lever @ 2005-10-04 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 7260 bytes --]
two quick notes:
1. git-update-ref has no documentation (i don't have time to sit down
and construct it, otherwise i'd post a patch).
2. what is your thinking about including the cache abstraction layer
after 1.0 ? i think it would help the libification effort.
Junio C Hamano wrote:
> As I mentioned in teh 0.99.8 announcement, let's start aiming
> for 1.0, really this time. From now on, brown paper bags,
> bugfixes, portability fixes, usability enhancements including
> documentation updates take precedence over any new features.
> One exception area is probably merge strategy modules -- they
> are like adding new device drivers or adding new filesystem, and
> can come in anytime as long as they do not touch the coreish.
>
>
> The GIT To-Do File
> ==================
>
> The latest copy of this document is found at
>
> http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
>
>
> Tool Renames Plan
> =================
>
> - In 0.99.8, we still install the backward compatible symbolic
> links in $(bindir). These will however be removed before 1.0
> happens.
>
> git-ssh-push and git-ssh-pull pair is not going away within
> this timeframe, if ever. Each of these old-name commands
> continues to invoke its old-name counterpart on the other
> end.
>
>
> What to expect after 0.99.8
> ===========================
>
> This is written in a form of to-do list for me, so if I say
> "accept patch", it means I do not currently plan to do that
> myself. People interested in seeing it materialize please take
> a hint.
>
>
> Documentation
> -------------
>
> * Accept patches from people who actually have done CVS
> migration and update the cvs-migration documentation.
> Link the documentation from the main git.txt page.
>
> * Talk about using rsync just once at the beginning when
> initializing a remote repository so that local packs do not
> need to be expanded. I personally do not think we need tool
> support for this (but see below about optimized cloning).
>
> * Maybe update tutorial with a toy project that involves two or
> three developers..
>
> * Update tutorial to cover setting up repository hooks to do
> common tasks.
>
> * Accept patches to finish missing docs.
>
> * Accept patches to talk about "Whoops, it broke. What's
> next?".
>
> * Accept patches to make formatted tables in asciidoc to work
> well in both html and man pages (see git-diff(1)).
>
>
> Technical (heavier)
> -------------------
>
> * We might want to optimize cloning with GIT native transport
> not to explode the pack, and store it in objects/pack instead.
> We would need a tool to generate an idx file out of a pack
> file for this. Also this itself may turn out to be a bad
> idea, making the set of packs in repositories everybody has
> different from each other.
>
> * Git daemon, when deployed at kernel.org, might turn out to be
> quite a burden, since it needs to generate customized packs
> every time a new request comes in. It may be worthwhile to
> precompute some packs for popular sets of heads downloaders
> have and serve that, even if that could give more than the
> client asks for in some cases. We will know about this soon
> enough.
>
> * Libification. There are many places "run once" mentality is
> ingrained in the management of basic data structures, which
> need to be fixed.
>
> * Maybe a pack optimizer.
>
> * Maybe an Emacs VC backend.
>
> * 'git split-projects'? This requires updated 'git-rev-list' to
> skip irrelevant commits.
> Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
>
> * Look at libified GNU diff CVS seems to use, or libxdiff.
>
>
> Technical (milder)
> ------------------
>
> * Encourage concrete proposals to commit log message templates
> we discussed some time ago.
>
> * Accept patches to cause "read-tree -u" delete a directory when
> it makes it empty.
>
> * Perhaps accept patches to introduce the concept of "patch flow
> expressed as ref mappings" Josef has been advocating about.
>
> * Perhaps accept patches to do undo/redo.
>
> * Perhaps accept patch to optionally allow '--fuzz' in
> 'git-apply'.
>
> * Allow 'git apply' to accept GNU diff 2.7 output that forgets
> to say '\No newline' if both input ends with incomplete
> lines.
>
> * Maybe grok PGP signed text/plain in applymbox as well.
>
> * Perhaps a tool to revert a single file to pre-modification
> state? People with BK background know this operation as
> 'clean'. 'git checkout [-f] ent [path...]' was suggested by
> Matthias Urlichs which sounds a natural extention to what the
> command currently does.
>
> * Enhance "git repack" to not always use --all; this would be
> handy if the repository contains wagging heads like "pu" in
> git.git repository.
>
> * Internally split the project into non-doc and doc parts; add
> an extra root for the doc part and merge from it; move the
> internal doc source to a separate repository, like the +Meta
> repository; experiment if this results in a reasonable
> workflow, and document it in howto form if it does.
>
> * Make rebase restartable; instead of skipping what cannot be
> automatically forward ported, leave the conflicts in the work
> tree, have the user resolve it, and then restart from where it
> left off.
>
> * Output full path in the "git-rev-list --objects" output, not
> just the basename, and see the improved clustering results in
> better packing [Tried, but did not work out well].
>
> * Updated git-changes-script Jeff Garzik needs [Inquiry for
> external spec sent out with a quick hack. Will know if that
> is what he needs soon enough].
>
>
> Technical (trivial)
> -------------------
>
> * short SHA1 naming is not enforcing uniqueness. Should fix.
>
> * 'git repack' can be DOSed. Should fix.
>
> * Stop installing the old-name symlinks [POSTPONED].
>
> * 'git merge-projects'?
>
> * 'git lost-and-found'? Link dangling commits found by
> fsck-objects under $GIT_DIR/refs/lost-found/. Then
> show-branch or gitk can be used to find any lost commit. [A
> feeler patch sent out. Very underwhelming response X-<.]
>
> Do not name it /lost+found/; that would probably confuse
> things that mistake it a mount point (not our code but
> somebody else's).
>
> * Add simple globbing rules to git-show-branch so that I can
> say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
> ko-rc are in refs/tags/).
>
> * We would want test scripts for the relative directory path
> stuff Linus has been working on. So far, the following
> commands should be usable with relative directory paths:
>
> git-update-index
> git-ls-files
> git-diff-files
> git-diff-index
> git-diff-tree
> git-rev-list
> git-rev-parse
>
> * In a freashly created empty repository, `git fetch foo:bar`
> works OK, but `git checkout bar` afterwards does not (missing
> `.git/HEAD`).
>
> \f
> Local Variables:
> mode: text
> End:
>
> -
> 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
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* cvsimport using proxy?
From: Junio C Hamano @ 2005-10-04 21:42 UTC (permalink / raw)
To: Matthias Urlichs, Martin Langhoff, Sven Verdoolaege; +Cc: git
I was going to try cvsimport over the firewall --
CVSROOT=':pserver;proxy=firewall;proxyport=3128:anoncvs@anoncvs.postgresql.org:/projects/cvsroot' cvs co -c
works fine, but it does not appear to me that cvsimport knows
about the proxied connection. Is anybody savvy and helpful
enough to look into adding this?
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Greg KH @ 2005-10-04 21:07 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alan Chandler, git
In-Reply-To: <43419DD4.5040508@zytor.com>
On Mon, Oct 03, 2005 at 02:08:36PM -0700, H. Peter Anvin wrote:
>
> I believe in the medium-to-long term a plugin architecture for merging
> is imperative. It's not even different media types, but some *files*
> have specific merging policies. Think, for example, of pci.ids in the
> Linux kernel tree.
You mean the file that is now removed from the kernel tree? Sure,
that's a good merge policy :)
greg k-h
^ permalink raw reply
* Re: [PATCH] Return error when not checking out an entry due to dirtiness.
From: Horst von Brand @ 2005-10-04 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0fxhno8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Without -f flag, 'git-checkout-index foo.c' issued an error message
> when foo.c already existed in the working tree and did not match index.
> However it did not return an error from the underlying checkout_entry()
> function and resulted in a successful exit(0).
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * I've made sure that the existing scripts do not use
> checkout-index without -f in a way that could be affected by
> this change. However, third-party scripts may be affected by
> this. Cogito and StGIT should be OK -- they either run
> checkout with -f, do not check the error return when it does
> not use -f, or runs checkout without -f in an empty working
> tree.
>
> checkout-index.c | 11 ++++++++---
> entry.c | 2 +-
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> 5a166f6a9d1b7ca2de673139fbfc4112b1b2e308
> diff --git a/checkout-index.c b/checkout-index.c
> --- a/checkout-index.c
> +++ b/checkout-index.c
> @@ -63,15 +63,20 @@ static int checkout_file(const char *nam
>
> static int checkout_all(void)
> {
> - int i;
> + int i, errs;
>
> - for (i = 0; i < active_nr ; i++) {
> + for (errs = i = 0; i < active_nr ; i++) {
This is ugly. Why not just:
errs = 0;
for (i = 0; i < active_nr ; i++) {
(errs is in no way the variable controlled by the for).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-04 18:53 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200510041108.36202.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Tuesday 04 October 2005 07:57, Junio C Hamano wrote:
>> I do not understand this comment.
>
> I talk about configuration per remote repository vs. configuration per
> local head, and a consistent user interface regarding these.
>
> Cogito is using configuration per head: If there is a remote fetch mapping,
> this is stored in branches/<headname>. There is no new shortcut to
> remember, because every file in branches corresponds to a local head.
Thanks. This is "lightbulb" moment for me. I did not realize
branches/ files are "per head configuration" -- I just thought
they are arbitrary tokens, and by convention it can only slurp
into the branch with the same name as the file. I even thought
about mentioning the possibility to enhance the current
url://to/repo#rembranch
to
url://to/repo#rembranch1:localbranch1,rembranch2:localbranch2,...
but I am glad I didn't -- localbranch cannot be anything other
than the filename because by definition the file is to describe
the local branch of the same name, and describing more than one
localbranch does not make sense. OTOH,
url://to/repo#rembranch1,rembranch2,...
may make sense now --- you are telling this local branch pulls
(and makes Octopus) from multiple remote branches.
Anyway, I think I understand what you meant to say now.
> I still think it is wrong to use one head name of a repository as the
> default for the repository's name.
I think this is about branches/ file: "One head name of the
local repository is used as a shorthand to name the remote
repository described by the file, inside the local repository".
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-04 17:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.63.0510041213460.23242@iabervon.org>
Daniel Barkalow wrote:
>
> I actually mean UNIX (a.k.a. PF_LOCAL) sockets; git-ssh-fetch is connected
> to ssh via sockets from "socketpair()". Looks like you can set the buffer
> size with a socket option here, too, but I doubt ssh will try setting
> socket options on standard in and out, and git-ssh-fetch leaves them at
> their defaults. I'm not clear where the defaults for these come from in
> general.
>
Well, git-ssh-fetch could set both SO_SNDBUF and SO_RCVBUF if it cared.
For portability, it would be a good thing to explicitly set the buffer
size rather than just blindly assume it can hold a specific amount of data.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-04 16:41 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.04.14.18.59.102722@smurf.noris.de>
On Tue, 4 Oct 2005, Matthias Urlichs wrote:
> Hi, Daniel Barkalow wrote:
>
> > I'd guess that UNIX sockets have a
> > similar capacity (although I'm not going to look it up tonight).
>
> You can set TCP options to change the buffer sizes.
>
> I would however assume that *nobody* sets both the send and receive
> buffers such that their cumulative size is <4k, so 99 object IDs
> at 41 bytes definitely should be OK.
I actually mean UNIX (a.k.a. PF_LOCAL) sockets; git-ssh-fetch is connected
to ssh via sockets from "socketpair()". Looks like you can set the buffer
size with a socket option here, too, but I doubt ssh will try setting
socket options on standard in and out, and git-ssh-fetch leaves them at
their defaults. I'm not clear where the defaults for these come from in
general.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-04 16:35 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20051004154640.GC4682@kiste.smurf.noris.de>
Matthias Urlichs wrote:
>
> Actually, it isn't -- if you have a ssh connection, you don't have
> access to the raw TCP socket.
>
If you have an ssh connection, you're writing over a pipe to the ssh
process, and your local buffer is that pipe, which is PIPE_BUF size.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Matthias Urlichs @ 2005-10-04 15:46 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <434296F1.5030006@zytor.com>
Hi,
H. Peter Anvin:
> >I would however assume that *nobody* sets both the send and receive
> >buffers such that their cumulative size is <4k, so 99 object IDs
> >at 41 bytes definitely should be OK.
>
> For TCP, I think we should simply get our own (or set) packet buffer
> size and conform to it. Problem solved...
Actually, it isn't -- if you have a ssh connection, you don't have
access to the raw TCP socket.
Just limit the number of objects in flight to 20 or so.
Problem also solved. ;-)
--
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
- -
He hated to set precedents; those who did so were sometimes promoted, more
frequently they joined their ancestors.
-- Robert A. Heinlein
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-04 15:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com>
Alex Riesen wrote:
>
> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the
> target and returns an error (probably EPERM, but I have reasons not to trust
> strerror on that thing).
> The repository was on FAT.
> Taking "rename(2)" from cygwin's libiberty solved this (they unlink if link(2)
> returns EEXIST).
>
> PS: Does broken rename(2) qualify a system "not worthy to support"?
I just tried this with Cygwin 1.5.18-1 and didn't have any such
problems. I tried it on NTFS, FAT and Samba, using WinXP.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-04 14:51 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.04.14.18.59.102722@smurf.noris.de>
Matthias Urlichs wrote:
> Hi, Daniel Barkalow wrote:
>
>>I'd guess that UNIX sockets have a
>>similar capacity (although I'm not going to look it up tonight).
>
> You can set TCP options to change the buffer sizes.
>
> I would however assume that *nobody* sets both the send and receive
> buffers such that their cumulative size is <4k, so 99 object IDs
> at 41 bytes definitely should be OK.
>
For TCP, I think we should simply get our own (or set) packet buffer
size and conform to it. Problem solved...
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Matthias Urlichs @ 2005-10-04 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0510040321170.23242@iabervon.org>
Hi, Daniel Barkalow wrote:
> I'd guess that UNIX sockets have a
> similar capacity (although I'm not going to look it up tonight).
You can set TCP options to change the buffer sizes.
I would however assume that *nobody* sets both the send and receive
buffers such that their cumulative size is <4k, so 99 object IDs
at 41 bytes definitely should be OK.
--
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
- -
I was going to include an ethnic slur in here, but I couldn't figure out how
to get you into this file.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-04 14:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com>
Alex Riesen wrote:
>
> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the
> target and returns an error (probably EPERM, but I have reasons not to trust
> strerror on that thing).
> The repository was on FAT.
> Taking "rename(2)" from cygwin's libiberty solved this (they unlink if link(2)
> returns EEXIST).
>
> PS: Does broken rename(2) qualify a system "not worthy to support"?
In this case a better way would be to just add -liberty to all link
lines if necessary, but I would expect the core cygwin code to do this.
-hpa
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Alex Riesen @ 2005-10-04 13:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <81b0412b0510040531m441ca759k6d1f3fbf0cd248ce@mail.gmail.com>
On 10/4/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 9/29/05, H. Peter Anvin <hpa@zytor.com> wrote:
> > I have made a first cut at a git port to Cygwin. It looks like the
> > "git-diff-tree -p" problem has been resolved independently, or at least
> > I can't reproduce it on a fresh Cygwin install (running on XP Home), but
> > I have added support for running without the IPv6 and the getaddrinfo() API.
> >
> > There are still funnies. In particular, Cygwin and Samba handle
> > symlinks differently, so you can't trivially share a repository via
> > Samba. Linus' "symbolic refs" changes should eventually take care of that.
>
> I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the
> target and returns an error (probably EPERM, but I have reasons not to trust
> strerror on that thing).
> The repository was on FAT.
> Taking "rename(2)" from cygwin's libiberty solved this (they unlink if link(2)
> returns EEXIST).
I think I have to clarify: I copied the function (like in strcasestr
case) into compat/
^ permalink raw reply
* Re: [COGITO] cg-status in an empty repo spits out git-diff-index usage info
From: Elfyn McBratney @ 2005-10-04 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list
In-Reply-To: <7vpsqp905i.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]
On Sat, Oct 01, 2005 at 12:17:13 -0700, Junio C Hamano wrote:
> Elfyn McBratney <beu@gentoo.org> writes:
>
> > which I'm guessing isn't expected behaviour ;) `git status` does the
> > same, FWIW.
>
> Yes, I noticed 'git status' did it that some time ago, and I
> thought "gee, that was ugly". But then I imagined what any
> other realist maintainer would have said if I reported it as a
> bug.
>
> Lbh xabj lbh'ir whfg perngrq lbhe ercb naq vg vf rzcgl.
> Jung qvq lbh rkcrpg sebz 'fgnghf' bhgchg? Jub pnerf! Naq
> ubj bsgra jbhyq lbh rkcrpg gb eha 'tvg fgnghf' va n arjyl
> perngrq ercbfvgbel sebz abj ba, abj lbh xabj jung lbh jbhyq
> frr? Trg hfrq gb vg.
>
> But I fixed it anyway, exactly a month ago.
>
>
> -
> 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
>
Hehe - cool, thanks. :)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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