* Re: Git and Amazon S3
From: Tay Ray Chuan @ 2010-02-02 15:01 UTC (permalink / raw)
To: Aneurin Price; +Cc: Marc Weber, git
In-Reply-To: <501db8661002020556k2f65add2rf06b289f2c9cbcac@mail.gmail.com>
Hi,
On Tue, Feb 2, 2010 at 9:56 PM, Aneurin Price <aneurin.price@gmail.com> wrote:
> Does anyone have any remarks about these options? Is there a better option - how
> difficult would it be to add native support to git? Are there any other options
> for more git-friendly remote storage at a comparable price? Or maybe I should
> just give up, spend more and get a Linode; then I'd have the flexibility to do
> whatever I want with it.
being a backup, I believe you can just sync your .git folder one-way,
with your local copy being the authoritative one, and the S3 one just
following it.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: How can I create a commit without a parent?
From: Jakub Narebski @ 2010-02-02 15:02 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-5383E3.00002602022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> SLSIA. git commit-tree insists on having at least one parent commit at
> the command line. From reverse-engineering it seems like I could do it
> by setting .git/HEAD to 'ref: refs/heads/some-nonexistent-branch' but
> mucking with HEAD directly like that feels kinda scary.
You have git-symbolic-ref to set HEAD directly (don't forget to remove
index).
Or you can set up / initialize separate (new) repository, create
commit there and then pull this new repository into current one.
P.S. Creating new root (parentless) commit isn't something that you do
on purpose, usually.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git am fails to add new files
From: Thomas Koch @ 2010-02-02 15:07 UTC (permalink / raw)
To: git
Hi,
I'm using GIT on Debian unstable (1.6.6.1). When applying patches I created
with git format-patch and applying them afterwards with git am, this fails
with every patch that adds a new file.
Is there any option I forgot to give to git am? Or is this a bug.
Best regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: [PATCH] resolve-undo.c: silence compiler complaints by casting void * to char *
From: Brandon Casey @ 2010-02-02 15:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7vr5p4favs.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thanks for catching this.
>>
>> In this particular case, I however suspect that it would be cleaner to
>> declare that the first parameter to resolve_undo_read() is a "char *"
>> (or even "const char *"), as we are dealing with NUL delimited list of
>> octal numbers and character strings.
>
> It would look like this.
This works for me.
Thanks,
-brandon
^ permalink raw reply
* Re: What does git reset do?
From: Jakub Narebski @ 2010-02-02 15:30 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-A2A2DE.23475601022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> The docs say that git-reset:
>
> "Sets the current head to the specified commit..."
>
> So I tried this:
>
>
> [ron@mickey:~/devel/gittest]$ git branch
> * br1
> master
> [ron@mickey:~/devel/gittest]$ git reset --soft master
>
>
> ...expecting HEAD to now point to master. But it doesn't:
First, 'current head' is what HEAD points to, which means 'br1'
branch.
Second, "git reset --soft master" sets 'br1' branch to _commit_
'master' (commit referenced by 'master' branch).
>
>
> [ron@mickey:~/devel/gittest]$ git branch
> * br1
> master
> [ron@mickey:~/devel/gittest]$ more .git/HEAD
> ref: refs/heads/br1
>
>
> So... what does git reset do?
Let's assume that we have the following situation:
/-* <-- branch_A
/
*---*---*---*---*---* <-- branch_B <--- HEAD
1. $ git checkout branch_A
sets HEAD to branch_A, and sets index and working directory:
/-* <-- branch_A <--- HEAD
/
*---*---*---*---*---* <-- branch_B
2. $ git reset --hard HEAD
sets current branch to commit pointer by branch_A (--soft, --mixed,
--hard), and sets index (--hard and --mixed) and working directory
(--hard):
/---------- branch_B <--- HEAD
v
/-* <-- branch_A
/
*---*---*---*---*---*
..................................................
Let's assume that we have the following situation:
*---*---*---a---b---c <-- branch_A <--- HEAD
^
|
v1.0 (tag)
3. $ git checkout v1.0
detaches HEAD:
/-b---c <-- branch_A
/
*---*---*---a <--- HEAD
^
|
v1.0 (tag)
4. $ git reset --hard v1.0
rewinds current branch:
/-b---c
/
*---*---*---a <-- branch_A <--- HEAD
^
|
v1.0 (tag)
Note that commit 'c' might be referenced only by ORIG_HEAD, HEAD@{1}
(reflog for HEAD), and branch_A@{1} (reflog for branch_A); if it is
the case commits 'b' and 'c' would get garbage-collected and removed
eventually.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: A git-mv question
From: Jakub Narebski @ 2010-02-02 15:32 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-09EE6C.16083801022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> If I do a git-mv *and* edit the file all in one commit, does that get
> recorded in a way that allows git to track the change through the
> changed file name? In other words, if I do just a git-mv (without
> changing the file) git can track that by observing that two differently
> named objects in two different commit trees contain the same blob. But
> if the file is edited then the blobs will be different. Is git smart
> enough to distinguish a git-mv and edit from, say, the equivalent git-rm
> and git-add? If so, how does it do it?
Git does not distinguish between git-mv and equivalent git-rm+git-add;
it employs heuristic similarity based (based on how contents of files
is similar to each other) rename detection.
Also worth noting is that git does consider only endpoints for rename
detection in diff and in merge; it does not check history if there
were clean rename / rename + edit.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Correct spelling of 'REUC' extension
From: Shawn O. Pearce @ 2010-02-02 15:33 UTC (permalink / raw)
To: Junio C Hamano, git
The new dircache extension CACHE_EXT_RESOLVE_UNDO, whose value is
0x52455543, is actually the ASCII sequence 'REUC', not the ASCII
sequence 'REUN'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I missed the patch that added this to C Git, so I got a bit
surprised when an unresolved index started crashing inside of JGit.
JGit is trying to do the right thing by ignoring the extension,
since its name is all uppercase, but its still getting confused
and barfing at the end of the file. While trying to track it down
I started scratching my head wondering what this 'REUC' extension
was, and where it came from... only to find out its not actually
documented in the sources, because the comment is wrong.
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 309b77a..f1f789b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -26,7 +26,7 @@ static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int reall
#define CACHE_EXT(s) ( (s[0]<<24)|(s[1]<<16)|(s[2]<<8)|(s[3]) )
#define CACHE_EXT_TREE 0x54524545 /* "TREE" */
-#define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUN" */
+#define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUC" */
struct index_state the_index;
--
1.7.0.rc0.170.g7207c
--
Shawn.
^ permalink raw reply related
* Fix signal handler
From: Markus Elfring @ 2010-02-02 16:14 UTC (permalink / raw)
To: git
Hello,
The function "early_output" that is set as a signal handler by the
function "setup_early_output" contains a simple looking instruction.
http://git.kernel.org/?p=git/git.git;a=blob;f=builtin-log.c;h=8d16832f7e9483f7903009459a72efc39e267c98;hb=HEAD#l173
A global variable gets a function pointer assigned.
http://git.kernel.org/?p=git/git.git;a=blob;f=revision.h;h=a14deefc252bd641fba5e16f7859b4a985a72578;hb=HEAD#l138
I find that this approach does not fit to standard rules because the
data type "sig_atomic_t" is the only type that can be safely used for
global write access in signal handlers.
https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers
Would you like to change any details in the design of your software
because of this issue to avoid undefined behaviour?
Regards,
Markus
^ permalink raw reply
* Re: Git and Amazon S3
From: Jay Soffian @ 2010-02-02 16:34 UTC (permalink / raw)
To: Aneurin Price; +Cc: git
In-Reply-To: <501db8661002020556k2f65add2rf06b289f2c9cbcac@mail.gmail.com>
On Tue, Feb 2, 2010 at 8:56 AM, Aneurin Price <aneurin.price@gmail.com> wrote:
> It looks like the cheapest option from a pure storage and data-transfer point of
> view would be S3, so I'm looking at the best way to use it with git. So far, the
> options I've found are either using jgit, which I've never used but appears to
> have a native S3 transport, or using one of the FUSE options to mount S3 as a
> filesystem.
>
> Does anyone have any remarks about these options? Is there a better option -
I guess it might exceed your costs, but you could use a small EC2
instance backed by an EBS volume. The instance would have git
installed.
When you need to push, fire up the instance, push to git running on
that instance, then shutdown the instance and snapshot the EBS volume
to S3.
Hmm, maybe that's over-engineered. :-)
j.
^ permalink raw reply
* Re: How can I create a commit without a parent?
From: Jay Soffian @ 2010-02-02 16:40 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-5383E3.00002602022010@news.gmane.org>
On Tue, Feb 2, 2010 at 3:00 AM, Ron Garret <ron1@flownet.com> wrote:
> SLSIA. git commit-tree insists on having at least one parent commit at
> the command line. From reverse-engineering it seems like I could do it
> by setting .git/HEAD to 'ref: refs/heads/some-nonexistent-branch' but
> mucking with HEAD directly like that feels kinda scary.
I guess you're looking to do it with plumbing, but with porcelain the
way I'd do it is:
$ git init foo
$ git init bar
$ cd bar
$ git commit --allow-empty -m "empty bar root commit"
$ cd ../foo
$ git commit --allow-empty -m "empty foo root commit"
$ git fetch ../bar master:bar
j.
^ permalink raw reply
* Suggestions for improvement when dealing with remote branch shuffling
From: Yann Dirson @ 2010-02-02 17:11 UTC (permalink / raw)
To: GIT list
* it looks like "git remote prune" on any remote may be a good candidate to be
included in "git gc" (although probably only for the candidate refs seeing their
last reflog entry removed)
* when a remote had a "foo/bar" ref in the past, still available locally as
"remotes/origin/foo/bar" because the user did not think about running "remote
prune origin", and a new remote branch named "foo" appears, fetch refuses to
update the local "remotes/origin/foo" ref, but does not give the reason to the
user. OTOH, another user reported fetch suggesting running "remote prune origin"
- but he may have had a slightly different history of fetch runs (seen in
1.6.5.1 msys). Probably this message should also be issued in the 1st case.
^ permalink raw reply
* Question about git rebase --onto
From: Pascal Obry @ 2010-02-02 17:49 UTC (permalink / raw)
To: git list
It seems to me that:
$ git co topic
$ git rebase --onto master topic~2 topic
Used to do the job and rebase the topic branch as expected. Today when I
tried with 1.7.0.rc1.10.gb8bb after the rebase above I was left on a
detached head.
Is my recollection wrong? Has this been changed recently?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Question about git rebase --onto
From: Junio C Hamano @ 2010-02-02 18:11 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4B6865A9.60603@obry.net>
Pascal Obry <pascal@obry.net> writes:
> It seems to me that:
>
> $ git co topic
> $ git rebase --onto master topic~2 topic
>
> Used to do the job and rebase the topic branch as expected. Today when I
> tried with 1.7.0.rc1.10.gb8bb after the rebase above I was left on a
> detached head.
>
> Is my recollection wrong? Has this been changed recently?
Either a recent bug or a user error, I think, as we didn't intend to
change. My quick manual test didn't show such a bug but rebase is one
of the areas that acquired new code recently.
Possible user errors I can think of are:
- If 'topic' is not a local branch, the result will be on a detached
HEAD, as you are starting from a detached HEAD (i.e. 'topic' could be a
tag);
- Until you resolved and said "rebase --continue" (or --skip) to allow it
to conclude the rebase when the operation conflicted, you would be on a
detached HEAD.
^ permalink raw reply
* Re: [PATCH] Correct spelling of 'REUC' extension
From: Junio C Hamano @ 2010-02-02 18:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100202153328.GB9687@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The new dircache extension CACHE_EXT_RESOLVE_UNDO, whose value is
> 0x52455543, is actually the ASCII sequence 'REUC', not the ASCII
> sequence 'REUN'.
Thanks; applied.
It was originally meant to be "resolve undo conflicts" but the symbolic
name got too long with the last word.
^ permalink raw reply
* Re: Question about git rebase --onto
From: Junio C Hamano @ 2010-02-02 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pascal, git list
In-Reply-To: <7v636f7biw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Possible user errors I can think of are:
>
> - If 'topic' is not a local branch, the result will be on a detached
> HEAD, as you are starting from a detached HEAD (i.e. 'topic' could be a
> tag);
>
> - Until you resolved and said "rebase --continue" (or --skip) to allow it
> to conclude the rebase when the operation conflicted, you would be on a
> detached HEAD.
Just to clarify, these things are _not_ errors at all. What I meant by
"user error" was to notice that the HEAD is detached in these cases (which
is not an error) and panicking (which is). Both of these are normal
procedures and sane states.
^ permalink raw reply
* Re: Question about git rebase --onto
From: Pascal Obry @ 2010-02-02 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v636f7biw.fsf@alter.siamese.dyndns.org>
Junio,
> Possible user errors I can think of are:
>
> - If 'topic' is not a local branch, the result will be on a detached
> HEAD, as you are starting from a detached HEAD (i.e. 'topic' could be a
> tag);
I'm not on this case.
> - Until you resolved and said "rebase --continue" (or --skip) to allow it
> to conclude the rebase when the operation conflicted, you would be on a
> detached HEAD.
I'm not in this case either.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Completion of error handling
From: Nicolas Pitre @ 2010-02-02 18:26 UTC (permalink / raw)
To: Markus Elfring; +Cc: git
In-Reply-To: <4B68249F.6070004@web.de>
On Tue, 2 Feb 2010, Markus Elfring wrote:
> Hello,
>
> I would like to point out that some checks for return codes are missing in the source files.
>
> Examples:
> Would you like to add more error handling for return values from "pthread_mutex_init" like in the function "start_threads" and from "fprintf" in the function "output_header_lines"?
What is the likelihood for those function calls to actually fail?
Nicolas
^ permalink raw reply
* Re: Completion of error handling
From: Markus Elfring @ 2010-02-02 18:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1002021324290.1681@xanadu.home>
> What is the likelihood for those function calls to actually fail?
Do you know the probability for failed memory allocations?
Would you like to care for error codes from all Pthread function calls?
Regards,
Markus
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: J. Bruce Fields @ 2010-02-02 19:19 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-1E906F.17124201022010@news.gmane.org>
On Mon, Feb 01, 2010 at 05:12:42PM -0800, Ron Garret wrote:
> In article <7vk4uwmp95.fsf@alter.siamese.dyndns.org>,
> Junio C Hamano <gitster@pobox.com> wrote:
>
> > Ron Garret <ron1@flownet.com> writes:
> >
> > > The manual specifically contradicts you, so either you are wrong or the
> > > manual is wrong.
> >
> > In case you haven't noticed, Pasky is one of the old timers and he knows a
> > thing or two about the git's world model.
>
> My intent was not to diss Pasky, it was just to point out a disconnect
> between what he was saying and what the manual says. It's quite
> possible that the manual is wrong or out of date or just misleading.
> But it says what it says.
>
> > And I do not see a contradiction in what the manual describes and "a
> > branch is a named pointer to a commit" (although "named" can probably be
> > omitted as "unnamed pointer" is not useful at the UI level).
>
> But that's not what the manual says. The manual says, "When we need to
> be precise, we will use the word "branch" to mean a line of
> development..." Those are the first words in the section entitled
> "Understanding history: What is a branch?" It certainly appears to the
> untrained eye that that is intended to be the definition of a branch.
My memory is that I'd seen the word "branch" used for both meanings (a
linear piece of history, and a ref under ref/heads/), so figured we
needed terms for both.
But then I didn't really use that distinction anywhere. On a quick skim
the only instance I can see of the first sense is in
http://kernel.org/pub/software/scm/git-core/docs/user-manual.html#counting-commits-on-a-branch,
which could probably be reworded.
It still may be worth acknowledging the confusion; e.g., something like:
In the above diagram, "A", "B", and "master" are all references
to a point in history. We call all three "branches".
Informally, the word "branch" is sometimes also used to the
entire line of development leading up to one of these points,
or, more generally, to any individual line of development. But
when speaking about git, a "branch" (or "branch head") will
always be a reference to a point in history, and in particular a
reference which may be advanced to new commits by future
development.
Eh, I don't know if that's helpful; maybe that section could just be
deleted. Or replaced by a more general discusion of the ref/ namespace.
--b.
^ permalink raw reply
* cat: .git/rebase-merge/head-name: No such file or directory
From: Erik Faye-Lund @ 2010-02-02 19:20 UTC (permalink / raw)
To: Git Mailing List, msysGit
I just applied an interactive rebase to one of my repos, and got a
pretty confusing error message:
$ git rebase -i HEAD~4
<edit, rebasing ticked forward to the end>
rm: cannot unlink `/c/Users/kusma/Documents/My
Dropbox/src/gb-asm/.git/rebase-merge/done': Permission denied
rm: cannot remove directory `/c/Users/kusma/Documents/My
Dropbox/src/gb-asm/.git/rebase-merge': Directory not empty
cat: .git/rebase-merge/head-name: No such file or directory
$ git diff
cat: .git/rebase-merge/head-name: No such file or directory
$ git status
# On branch asm-test
nothing to commit (working directory clean)
cat: .git/rebase-merge/head-name: No such file or directory
$
Now, I figure that rm failed due to my virus scanner kicking in, so
that's no mystery. And there is a commit in msys AFAIK that makes
unlink retry on failures. So I expect the issue to go away in future
versions. However, I'm not entirely sure what to do to repair my repo,
though.
Any ideas?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: cat: .git/rebase-merge/head-name: No such file or directory
From: Erik Faye-Lund @ 2010-02-02 19:25 UTC (permalink / raw)
To: Git Mailing List, msysGit
In-Reply-To: <40aa078e1002021120u1a692301q1c4f6a952d4df5a3@mail.gmail.com>
On Tue, Feb 2, 2010 at 8:20 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> I just applied an interactive rebase to one of my repos, and got a
> pretty confusing error message:
>
> $ git rebase -i HEAD~4
> <edit, rebasing ticked forward to the end>
> rm: cannot unlink `/c/Users/kusma/Documents/My
> Dropbox/src/gb-asm/.git/rebase-merge/done': Permission denied
> rm: cannot remove directory `/c/Users/kusma/Documents/My
> Dropbox/src/gb-asm/.git/rebase-merge': Directory not empty
> cat: .git/rebase-merge/head-name: No such file or directory
> $ git diff
> cat: .git/rebase-merge/head-name: No such file or directory
> $ git status
> # On branch asm-test
> nothing to commit (working directory clean)
> cat: .git/rebase-merge/head-name: No such file or directory
> $
>
> Now, I figure that rm failed due to my virus scanner kicking in, so
> that's no mystery. And there is a commit in msys AFAIK that makes
> unlink retry on failures. So I expect the issue to go away in future
> versions. However, I'm not entirely sure what to do to repair my repo,
> though.
>
OK, it turns out these "cat: .git/rebase-merge/head-name: No such file
or directory"-errors are caused by the bash-completion that I
foolishly removed in an attempt to reduce noise. "git show-branch"
shows the correct branch for me.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Completion of error handling
From: Nicolas Pitre @ 2010-02-02 19:27 UTC (permalink / raw)
To: Markus Elfring; +Cc: git
In-Reply-To: <4B6873AC.4030303@web.de>
On Tue, 2 Feb 2010, Markus Elfring wrote:
>
> > What is the likelihood for those function calls to actually fail?
>
> Do you know the probability for failed memory allocations?
>
> Would you like to care for error codes from all Pthread function calls?
Not necessarily. At least on Linux, most of those functions simply
cannot fail. There is just no dynamic memory allocation involved. All
other errors are normally due to bad code.
Nicolas
^ permalink raw reply
* Re: Completion of error handling
From: Markus Elfring @ 2010-02-02 19:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1002021424550.1681@xanadu.home>
> At least on Linux, most of those functions simply cannot fail.
Would you like to support software environments that work without a
famous out-of-memory killer?
> There is just no dynamic memory allocation involved.
>
I find this opinion strange.
> All other errors are normally due to bad code.
>
I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?
Regards,
Markus
^ permalink raw reply
* Re: Git and Amazon S3
From: Petr Baudis @ 2010-02-02 19:44 UTC (permalink / raw)
To: Aneurin Price; +Cc: git
In-Reply-To: <501db8661002020556k2f65add2rf06b289f2c9cbcac@mail.gmail.com>
On Tue, Feb 02, 2010 at 01:56:41PM +0000, Aneurin Price wrote:
> Does anyone have any remarks about these options? Is there a better option - how
> difficult would it be to add native support to git?
I'm not really familiar with Amazon S3 _or_ the current transport
code, but by cursory examination of both, it seems that it would be
fairly easy to add support for another transfer. And it might be even
better idea to actually just add generic support to invoke an external
helper to perform all the heavy lifting.
Basically, all the abstraction is already pre-cooked in the form of
rsync protocol support. I would just cut'n'paste that and replace rsync
magic with simple calls to external helper along some sensible simple
API, then code up an easy wrapper for S3 there. Or just add S3 API
support directly to core Git - it doesn't seem to be licence-encumbered.
Should take just a couple of hours including debugging, if you just
copy the existing rsync support functions.
Another idea might be to actually use the rsync protocol support
itself. ;-) There seems to be some sort of commercial rsync-S3 interface,
though I can't tell from their terribly strange pricing policy how
expensive it is to use it in practice.
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: Completion of error handling
From: Avery Pennarun @ 2010-02-02 19:49 UTC (permalink / raw)
To: Markus Elfring; +Cc: Nicolas Pitre, git
In-Reply-To: <4B688042.8090400@web.de>
On Tue, Feb 2, 2010 at 2:42 PM, Markus Elfring <Markus.Elfring@web.de> wrote:
> Nicolas wrote:
>> At least on Linux, most of those functions simply cannot fail.
>
> Would you like to support software environments that work without a
> famous out-of-memory killer?
In many cases on Linux systems, you don't get the OOM notification
anyway until you try to *use* the memory, not at allocation time. So
even checking the results of malloc() won't always save you (although
*not* checking can make problems even worse).
However, for functions that can't allocate memory at all, it's extra
pointless to worry about.
>> There is just no dynamic memory allocation involved.
>
> I find this opinion strange.
This isn't an opinion; because it's open source, you can actually look
at the source code and find out that many system calls don't do memory
allocation at all.
Avery
^ 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