* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-19 9:50 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl8owfqj.fsf@lola.quinscape.zz>
Hi,
On Tue, 19 Jun 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Don't just throw away backwards compatibility, only because it does
> > not fit your wishes.
>
> There is no backwards compatibility involved here _at_ _all_.
I was not talking about Git here. The specification for SMTP is not going
to change just because you want it. There are still mail servers out there
which speak 7-bit, and the standard requires you to cope with them.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestions for documentation
From: Johannes Schindelin @ 2007-06-19 9:47 UTC (permalink / raw)
To: Claudio Scordino; +Cc: git
In-Reply-To: <467786B1.5000009@gmail.com>
Hi,
On Tue, 19 Jun 2007, Claudio Scordino wrote:
> 1) As my previous question shown, how to clone from a specified port is not
> currently documented. You should just add a sentence saying that the command
> is
>
> git clone git://server:port/path/
I thought this was quite standard with other protocol? I.e.
http://host:port/path is what I do all the time.
Having said that, this should be relatively easy? Want to give it a try?
> 2) Maybe it is better to highlight that after a push on a remote
> repository, the user has to do a checkout on that repository (people
> from the CVS and SVN worlds get easily confused, otherwise).
That has been discussed on and off, and I think that you are not using a
valid workflow here. If you are pushing into another repo, _by definition_
you do not have a work tree to resolve conflicts with.
Thus, you should rather do something like "push upstream
master:refs/heads/push" on the pushing side, and "merge push" on the other
side.
It is a common behaviour by former CVS users (I did the same!), but it is
fixable.
> Moreover (and I did not fully understood why) if I just use "git
> checkout" without the -f option, I cannot see the changes that have been
> pushed from the cloned repository.
Same reason. This is not a valid workflow. You kind of changed the tip of
the branch in the pushed-to repo behind its back. The only way to make
this work that I am aware of is "git read-tree -m -u HEAD", but as I
stated before, you probably want to change the way you're working.
Hth,
Dscho
^ permalink raw reply
* Re: builtin-fetch code with messy history
From: Johannes Schindelin @ 2007-06-19 9:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706190255430.4740@iabervon.org>
Hi,
On Tue, 19 Jun 2007, Daniel Barkalow wrote:
> In my branch at: git://iabervon.org/~barkalow/git builtin-fetch
>
> I have a bunch of not-for-merging history leading up to a C version of
> fetch which passes all of the tests except that:
>
> * it might be fetching too much with --depth.
That should be fixable. (If I get more time this week than I expect, I'll
do it myself.)
> * bundle isn't implemented.
That's an easy one.
> * when a branch config file section refers to a branches/* remote, the
> merge setting is used (if one is given), even though this isn't useful
> either way.
Maybe this is the right time to cut off branches/* and remotes/*?
> * branch.<name>.merge is treated like the source side of a refspec
> (although it cannot be a wildcard), and it fetched refs are marked for
> merging if they name the same ref, even if they are not character-wise
> identical to the source side of the refspec used to fetch them.
>
> I've got more work to do on it (such as actually using my parser for
> parsing the refspecs and making the logic less convoluted), but I
> thought I'd report my progress.
Thank you very much!
Dscho
^ permalink raw reply
* Re: [PATCH] make dist: include configure script in tarball
From: Johannes Schindelin @ 2007-06-19 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v1wg8y8ja.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Mon, 18 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 19 Jun 2007, Jakub Narebski wrote:
> >
> >> Matthias Lederhofer wrote:
> >>
> >> > +dist: git.spec git-archive configure
> >>
> >> Ack. This way you don't need autoconf to ./configure install.
> >
> > ... but you force our good maintainer to have it installed...
>
> Which is fine by me.
Good. That was the kind of Ack I was waiting for.
> I was wondering why this wish did not surface much earlier myself.
When I was trying to be lazy, and ran configure myself on some machine
(sorry, don't remember which one, might well be a MinGW setup), it did not
work. So I did not push for it.
> Not that I'd use "./configure" myself nor help debugging the
> autoconf-generated shell scripts ;-).
I fully understand.
Ciao,
Dscho
^ permalink raw reply
* Re: Versioning file system
From: Martin Langhoff @ 2007-06-19 9:09 UTC (permalink / raw)
To: Kyle Moffett
Cc: Bryan Henderson, Jack Stone, Andrew Morton, alan, H. Peter Anvin,
linux-fsdevel, LKML Kernel, Al Viro, git
In-Reply-To: <6E9A6F9E-8948-40F2-9129-1F1491D49D83@mac.com>
On 6/19/07, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> What I think would be particularly interesting in this domain is
> something similar in concept to GIT, except in a file-system:
perhaps stating the blindingly obvious, but there was an early
implementation of a FUSE-based gitfs --
http://www.sfgoth.com/~mitch/linux/gitfs/
cheers,
martin
^ permalink raw reply
* Re: The --no-commit blues
From: Sergio @ 2007-06-19 8:52 UTC (permalink / raw)
To: git
In-Reply-To: <200706180806.26255.goofyheadedpunk@gmail.com>
Brian L. Troutwine <goofyheadedpunk <at> gmail.com> writes:
>
> I've got two branches, one which I commit to quite frequently and another only
> periodically, call them inward and outward. Inward is where I do my work,
> outward tracks an SVN repository. I'd like to merge inward to outward without
> committing the merge so that I may provide a commit message appropriate for
> checking in to the SVN repo.
>
> `git merge --no-commit inward' from branch outward, I thought, should do it.
> Performing a `git status' and a `git log' directly afterward seem to indicate
> that the merge was committed. `git commit' insists the branch is now up to
> date.
>
If you want the "whole" set of changes from inward to appear in outward as a
/single/ commit with an appropriate commit message, probably you want to use
also the --squash option of git merge.
Otherwise, git will preserve the "structuring" of the history in many commits.
This means that:
- if outward does not need any real merge (because it only needs to be advanced
to a newer status and not to join some changes of its own with changes from
inward), git merge will make a "fast-forward". In other words, you will see
outward becoming up to date without the need of any merge-commit at all. BTW
that is why --no-commit appears to have no effect in this case: there wouldn't
be any merge commit in any case.
- if outward needs a real merge, then git merge will set up everything up to the
point of making the merge commit. Then, depending on the presence of the
--no-commit option it will or will not make the actual commit.
> Am I going about this the wrong way? What does --no-commit mean, if I am?
>
> (Also, I asked this on #git earlier. If anyone happens to idle there, pardon
> me for re-posting this so quickly. I've got terrible lag this morning, enough
> to time out frequently.)
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Junio C Hamano @ 2007-06-19 8:39 UTC (permalink / raw)
To: Theodore Tso; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20070619071916.GC9177@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> Actually, the bigger missing gap is merges. Suppose in the
> development branch, you rename a whole bunch of files. (For example,
> foo_super.c got moved to foo/super.c, foo_inode.c got moved to
> foo/inode.c, etc.)
>
> Now suppose there are fixes made in the stable branch, in the original
> foo_super.c and foo_inode.c files. Ideally you would want to be able
> to pull those changes into the development branch, where the files
> have new names, and have the changes be applied to foo/super.c and
> foo/inode.c in the development branch.
That happens already with merge-recursive code, which has been
the default since late November 2005 (v0.99.9k and later should
have it).
What does _not_ happen is if foo_fixes.c was _created_ in the
stable branch. A merge that tries to forward port such a fix
would not move the foo_fixes.c to foo/fixes.c.
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Martin Langhoff @ 2007-06-19 8:31 UTC (permalink / raw)
To: Theodore Tso; +Cc: Git Mailing List
In-Reply-To: <20070619071916.GC9177@thunk.org>
On 6/19/07, Theodore Tso <tytso@mit.edu> wrote:
> Actually, the bigger missing gap is merges. Suppose in the
> development branch, you rename a whole bunch of files. (For example,
> foo_super.c got moved to foo/super.c, foo_inode.c got moved to
> foo/inode.c, etc.)
I thought that the "recursive" strategy covered this - though I don't
work on a tree that merges across branches with renames, so my
experience is _very_ limited.
>From Documentation/merge-strategies.txt:
Additionally this can detect and handle merges involving
renames. This is the default merge strategy when
pulling or merging one branch.
cheers
m
^ permalink raw reply
* Re: Versioning file system
From: Bron Gondwana @ 2007-06-19 7:58 UTC (permalink / raw)
To: Kyle Moffett
Cc: Bryan Henderson, Jack Stone, Andrew Morton, alan, H. Peter Anvin,
linux-fsdevel, LKML Kernel, Al Viro, git
In-Reply-To: <6E9A6F9E-8948-40F2-9129-1F1491D49D83@mac.com>
On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all. I've been doing versioning of the types I
>> described for years with user space code and I don't remember feeling that
>> I compromised in order not to involve the kernel.
>
> What I think would be particularly interesting in this domain is something
> similar in concept to GIT, except in a file-system:
I've written a couple of user-space things very much like this - one
being a purely database (blobs in database, yeah I know) system for
managing medical data, where signatures and auditability were the most
important part of the system. Performance really wasn't a
consideration.
The other one is my current job, FastMail - we have a virtual filesystem
which uses files stored by sha1 on ordainary filesystems for data
storage and a database for metadata (filename to sha1 mappings, mtime,
mimetype, directory structure, etc).
Multiple machine distribution is handled by a daemon on each machine
which can be asked to make sure the file gets sent out to every machine
that matches the prefix and will only return success once it's written
to at least one other machine. Database replication is a different
beast.
It can work, but there's one big pain at the file level: no mmap.
If you don't want to support mmap it can work reasonably happily, though
you may want to keep your sha1 (or other digest) state as well as the
final digest so you can cheaply calculate the digest for a small append
without walking the entire file. You may also want to keep state
checkpoints every so often along a big file so that truncates don't cost
too much to recalculate.
Luckily in a userspace VFS that's only accessed via FTP and DAV we can
support a limited set of operations (basically create, append, read,
delete) You don't get that luxury for a general purpose filesystem, and
that's the problem. There will always be particular usage patterns
(especially something that mmaps or seeks and touches all over the place
like a loopback mounted filesystem or a database file) that just dodn't
work for file-level sha1s.
It does have some lovely properties though. I'd enjoy working in an
envionment that didn't look much like POSIX but had the strong
guarantees and auditability that addressing by sha1 buys you.
Bron.
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-19 7:44 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706190156110.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 18 Jun 2007, David Kastrup wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > David Kastrup wrote:
>> >
>> >> what is the point in quoting file names and their characters in
>> >> git-diff's output?
>> >
>> > 7-bit email.
>>
>> I think it can be reasonably safely assumed that people using 8-bit
>> characters in file names will not refrain from using them in the files
>> themselves: [...]
>
> However, please realise that chances are very good that none of these
> 8-bit unclean things show in the diff.
Puh-leaze. So you prefer a behavior which makes it harder to notice
problems, on the chance that it may sometimes work by accident?
If you want to process diffs, you need an 8-bit clean (and
space-preserving) channel, period. This is the task of mail
encapsulation, not of the diff utility.
> Besides, the proper fix would probably involve making
> none-8-bit-clean diffs binary diffs (for FORMAT_EMAIL only, of
> course).
This is so utterly absurd for people working on non-English documents
that I get the expression you are pulling people's legs considering
your Email address.
>> So I don't see what quoting such characters in file names is
>> supposed to buy with regard to diff output in 7-bit email.
>
> But isn't that obvious? Even if the diffs are not 7-bit clean, which
> I consider as an error, quoting the file names is already half what
> is required.
What is required is a reliable mail channel, and there are a lot of
tools for that, from uuencode to various MIME standards and
encapsulation methods. The right tool for the right job. Everything
else is a mistake because it makes life harder for everyone, not just
those using mail, for no good purpose.
> Don't just throw away backwards compatibility, only because it does
> not fit your wishes.
There is no backwards compatibility involved here _at_ _all_. No
current tool can process the quoted mess, not even humans (random
octal escape sequences are not more readable than characters, or we
never would have progressed beyond ASCII).
So you are not talking about backward compatibility, but rather
gratuitous forward _incompatibility_, and nobody is better off by the
latter. There is no point in making life harder for people using
non-ASCII characters when there is absolutely no benefit whatsoever
involved for those restricting themselves to ASCII characters.
--
David Kastrup
^ permalink raw reply
* [ANNOUNCE] tig 0.8
From: Jonas Fonseca @ 2007-06-19 7:57 UTC (permalink / raw)
To: git
Hello,
A new version of tig has been released. It mainly contains bugfixes,
most importantly for regressions in the pager mode.
Get the tarball at http://jonas.nitro.dk/tig/releases/
or pull it from git://repo.or.cz/tig.git
The shortlog for this release:
Jakub Narebski (3):
Remove PDF version of manual from being build and installed
Include documentation sources for rpmbuild with '--without docs'
Refresh VERSION file when building distribution tarball in "make dist"
James Bowes (1):
Allow CFLAGS to be overridden while preserving VERSION
Jeffrey C. Ollie (1):
Supply explicit permission bits to 'install'
Jonas Fonseca (14):
tig-0.7.git
Fix typo the INSTALL file
Make dist rule more robust using '&&'; create .tar.gz.md5 file
Merge branch 'jn/rpm-updates'
Fix string_copy macro to use sizeof(src) for the source buffer
Fix use of the status view from subdirectories
Fix wrong uses of string_copy() with pointer instead of buffer
read_properties: use size_t instead of int for callback
Grab path to the git directory; use it when listing untracked files
Only emit one "Not a git repository" error message
Add TODO about using non-blocking I/O for incremental view loading
Fix (another) integer type mismatch on 64-bit systems
Fix pager mode regressions
tig-0.8
Steven Grimm (1):
Fix integer type mismatch on 64-bit systems
--
Jonas Fonseca
^ permalink raw reply
* Re: Versioning file system
From: Jack Stone @ 2007-06-19 7:49 UTC (permalink / raw)
To: Kyle Moffett
Cc: Bryan Henderson, akpm, alan, hpa, linux-fsdevel, linux-kernel,
viro, git
In-Reply-To: <6E9A6F9E-8948-40F2-9129-1F1491D49D83@mac.com>
Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all. I've been doing versioning of the types
>> I described for years with user space code and I don't remember
>> feeling that I compromised in order not to involve the kernel.
>>
>> Of course, if you want to do it with snapshots and COW, you'll have to
>> ask where in the kernel to put that, but that's not a file versioning
>> question; it's the larger snapshot question.
>
> What I think would be particularly interesting in this domain is
> something similar in concept to GIT, except in a file-system:
> 1) Redundancy is easy, you just ensure that you have at least "N"
> distributed copies of each object, where "N" is some function of the
> object itself.
> 2) Network replication is easy, you look up objects based on the SHA-1
> stored in the parent directory entry and cache them where needed (IE:
> make the "N" function above dynamic based on frequency of access on a
> given computer).
> 3) Snapshots are easy and cheap; an RO snapshot is a tag and an RW
> snapshot is a branch. These can be easily converted between.
> 4) Compression is easy; you can compress objects based on any
> arbitrary configurable criteria and the filesystem will record whether
> or not an object is compressed. You can also compress differently when
> archiving objects to secondary storage.
> 5) Streaming fsck-like verification is easy; ensure the hash name
> field matches the actual hash of the object.
> 6) Fsck is easy since rollback is trivial, you can always revert to an
> older tree to boot and start up services before attempting resurrection
> of lost objects and trees in the background.
> 7) Multiple-drive or multiple-host storage pools are easy: Think the
> git "alternates" file.
> 8) Network filesystem load-balancing is easy; SHA-1s are essentially
> random so you can just assign SHA-1 prefixes to different systems for
> data storage and your data is automatically split up.
>
>
> Other issues:
>
> Q. How do you deal with block allocation?
> A. Same way other filesystems deal with block allocation.
> Reference-counting gets tricky, especially across a network, but it's
> easy to play it safe with simple cross-network refcount-journalling.
> Since the _only_ thing that needs journalling is the refcounts and
> block-free data, you need at most a megabyte or two of journal. If in
> doubt, it's easy to play it safe and keep an extra refcount around for
> an in-the-background consistency check later on. When networked-gitfs
> systems crash, you just assume they still have all the refcounts they
> had at the moment they died, and compare notes when they start back up
> again. If a node has a cached copy of data on its local disk then it
> can just nonatomically increment the refcount for that object in its own
> RAM (ordered with respect to disk-flushes, of course) and tell its peers
> at some point. A node should probably cache most of its working set on
> local disk for efficiency; it's trivially verified against updates from
> other nodes and provides an easy way to keep refcounts for such data.
> If a node increments the refcount on such data and dies before getting
> that info out to its peers, then when it starts up again its peers will
> just be told that it has a "new" node with insufficient replication and
> they will clone it out again properly. For networked
> refcount-increments you can do one of 2 things: (1) Tell at least X many
> peers and wait for them to sync the update out to disk, or (2) Get the
> object from any peer (at least one of whom hopefully has it in RAM) and
> save it to local disk with an increased refcount.
>
> Q. How do you actually delete things?
> A. Just replace all the to-be-erased tree and commit objects before a
> specified point with "History erased" objects with their SHA-1's
> magically set to that of the erased objects. If you want you may delete
> only the "tree" objects and leave the commits intact. If you delete a
> whole linear segment of history then you can just use a single "History
> erased" commit object with its parent pointed to the object before the
> erased segment. Probably needs some form of back-reference storage to
> make it efficient; not sure how expensive that would be. This would
> allow making a bunch of snapshots and purging them logarithmically based
> on passage of time. For instance, you might have snapshots of every 5
> minutes for the last hour, every 30 minutes for the last day, every 4
> hours for the last week, every day for the last month, once per week for
> the last year, once per month for the last 5 years, and once per year
> beyond that.
>
> That's pretty impressive data-recovery resolution, and it accounts for
> only 200 unique commits after it's been running for 10 years.
>
> Q. How do you archive data?
> A. Same as deleting, except instead of a "History erased" object you
> would use a "History archived" object with a little bit of string data
> to indicate which volume it's stored on (and where on the volume). When
> you stick that volume into the system you could easily tell the kernel
> to use it as an alternate for the given storage group.
>
> Q. What enforces data integrity?
> A. Ensure that a new tree object and its associated sub objects are on
> disk before you delete the old one. Doesn't need any actual full syncs
> at all, just barriers. If you replace the tree object before write-out
> is complete then just skip writing the old one and write the new one in
> its place.
>
> Q. What consists of a "commit"?
> A. Anything the administrator wants to define it as. Useful algorithms
> include: "Once per x Mbyte of page dirtying", "Once per 5 min", "Only
> when sync() or fsync() are called", "Only when gitfs-commit is called".
> You could even combine them: "Every x Mbyte of page dirtying or every 5
> minutes, whichever is shorter (or longer, depending on admin
> requirements)". There would also be appropriate syscalls to trigger
> appropriate git-like behavior. Network-accessible gitfs would want to
> have mechanisms to trigger commits based on activity on other systems
> (needs more thought).
>
> Q. How do you access old versions?
> A. Mount another instance of the filesystem with an SHA-1 ID, a
> tag-name, or a branch-name in a special mount option. Should be user
> accessible with some restrictions (needs more thought).
>
> Q. How do you deal with conflicts on networked filesystems.
> A. Once again, however the administrator wants to deal with them. Options:
> 1) Forcibly create a new branch for the conflicted tree.
> 2) Attempt to merge changes using the standard git-merge semantics
> 3) Merge independent changes to different files and pick one for
> changes to the same file
> 4) Your Algorithm Here(TM). GIT makes it easy to extend
> conflict-resolution.
>
> Q. How do you deal with little scattered changes in big (or sparse) files?
> A. Two questions, two answers: For sparse files, git would need
> extending to understand (and hash) the nature of the sparse-ness. For
> big files, you should be able to introduce a "compound-file" datatype
> and configure git to deal with specific X-Mbyte chunks of it
> independently. This might not be a bad idea for native git as well.
> Would need system-specific configuration.
>
> Q. How do you prevent massive data consumption by spurious tiny changes
> A. You have a few options:
> 1) Configure your commit algorithm as above to not commit so often
> 2) Configure a stepped commit-discard algorithm as described above
> in the "How do you delete things" question
> 3) Archive unused data to secondary storage more often
>
> Q. What about all the unanswered questions?
> A. These are all the ones I could think of off the top of my head but
> there are at least a hundred more. I'm pretty sure these are some of
> the most significant ones.
>
> Q. That's a great idea and I'll implement it right away!
> A. Yay! (but that's not a question :-D) Good luck and happy hacking.
>
> Q. That's a stupid idea and would never ever work!
> A. Thanks for your useful input! (but that's not a question either) I'm
> sure anybody who takes up a project like this will consider such opinions.
>
> Q. *flamage*
> A. I'm glad you have such strong opinions, feel free to to continue to
> spam my /dev/null device (and that's also not a question).
>
> All opinions and comments welcomed.
>
> Cheers,
> Kyle Moffett
>
>
It sounds brilliant and I'd love to have a got at implementing it but I
don't know enough (yet :-D) about how git works, a little research is
called for I think.
Jack
^ permalink raw reply
* Suggestions for documentation
From: Claudio Scordino @ 2007-06-19 7:33 UTC (permalink / raw)
To: git
Hi,
I just want to suggest to put some missing information in the git manpages.
1) As my previous question shown, how to clone from a specified port is not
currently documented. You should just add a sentence saying that the command is
git clone git://server:port/path/
2) Maybe it is better to highlight that after a push on a remote repository, the
user has to do a checkout on that repository (people from the CVS and SVN worlds
get easily confused, otherwise).
Moreover (and I did not fully understood why) if I just use "git checkout"
without the -f option, I cannot see the changes that have been pushed from the
cloned repository.
Regards,
Claudio
^ permalink raw reply
* Re: blame follows renames, but log doesn't
From: Theodore Tso @ 2007-06-19 7:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90706181810p716f914al4d9abba5bfe7eb5@mail.gmail.com>
On Tue, Jun 19, 2007 at 01:10:28PM +1200, Martin Langhoff wrote:
>
> when I show git to newbies or demo it to people using other SCMs, and
> we get to the rename part of the conversation, I discuss and show how
> GIT's approach is significantly better than explicit recording of
> renames.
>
> One great example is git-blame -- actually more spectacular with the
> recent git gui blame improvements. But git-log still doesn't do it.
Actually, the bigger missing gap is merges. Suppose in the
development branch, you rename a whole bunch of files. (For example,
foo_super.c got moved to foo/super.c, foo_inode.c got moved to
foo/inode.c, etc.)
Now suppose there are fixes made in the stable branch, in the original
foo_super.c and foo_inode.c files. Ideally you would want to be able
to pull those changes into the development branch, where the files
have new names, and have the changes be applied to foo/super.c and
foo/inode.c in the development branch.
I was recently talking to someone who is still using BitKeeper, and he
cited this scenario as one of the reasons why his project is still
using BK; he'd like to move to git, but this is a critical piece of
functionality for him.
- Ted
^ permalink raw reply
* Re: GIT_DIR question
From: Matthias Lederhofer @ 2007-06-19 7:15 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0706181243x64241585rfb64ca48323dea1e@mail.gmail.com>
Yakov Lerner <iler.ml@gmail.com> wrote:
> Does your patch allow to use absolute filenames and being cwd
> outside of working dir ? I like to use absolute filenames (sometimes.
> Most modern VSCes allow absolute pathnames).
Nope, that's not possible (yet). I can't think of an easy way to do
this right now..
^ permalink raw reply
* builtin-fetch code with messy history
From: Daniel Barkalow @ 2007-06-19 7:12 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In my branch at: git://iabervon.org/~barkalow/git builtin-fetch
I have a bunch of not-for-merging history leading up to a C version of
fetch which passes all of the tests except that:
* it might be fetching too much with --depth.
* bundle isn't implemented.
* when a branch config file section refers to a branches/* remote, the
merge setting is used (if one is given), even though this isn't useful
either way.
* branch.<name>.merge is treated like the source side of a refspec
(although it cannot be a wildcard), and it fetched refs are marked for
merging if they name the same ref, even if they are not character-wise
identical to the source side of the refspec used to fetch them.
I've got more work to do on it (such as actually using my parser for
parsing the refspecs and making the logic less convoluted), but I thought
I'd report my progress.
I'll give a sign-off to anyone who extracts patches that can be applied,
if anybody wants to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 2/3] 'git-svndump'
From: Sergey Yanovich @ 2007-06-19 6:54 UTC (permalink / raw)
To: git, normalperson, J.Sixt, masterdriverz; +Cc: Sergey Yanovich
In-Reply-To: <cff8d32813e43d9e1c75ad50824d95dbcd6f669c.1182235491.git.ynvich@gmail.com>
A git tool to keep a subversion mirror
git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
will work only when it is the sole method of committing to the
Subversion repository.
It is designed to export a linear git branch. However, thanks to the way
'git' handles source code, 'git-svndump' seems to work in other
conditions. For example, when branches are switched or merged.
git-svndump provides a solution when you need to export your source code
in Subversion format (who would need this with git :), but do not want
to have all the shackles that 'git-svn init' puts on your repository.
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
Documentation/git-svndump.txt | 97 ++++++++++++++++++++++++++++++++++++++++
Makefile | 1 +
git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++++
git-svndump-sync.sh | 98 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 281 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-svndump.txt
create mode 100755 git-svndump-init.sh
create mode 100755 git-svndump-sync.sh
diff --git a/Documentation/git-svndump.txt b/Documentation/git-svndump.txt
new file mode 100644
index 0000000..11e7e79
--- /dev/null
+++ b/Documentation/git-svndump.txt
@@ -0,0 +1,97 @@
+git-svndump(1)
+==========
+
+NAME
+----
+git-svndump - Exporting from git to a single Subversion branch
+
+SYNOPSIS
+--------
+'git-svndump' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
+will work only when it is the sole method of committing to the
+Subversion repository.
+
+It is designed to export a linear git branch. However, thanks to the way
+'git' handles source code, 'git-svndump' seems to work in other
+conditions. For example, when branches are switched or merged.
+
+git-svndump provides a solution when you need to export your source code
+in Subversion format (who would need this with git :), but do not want
+to have all the shackles that 'git-svn init' puts on your repository.
+
+COMMANDS
+--------
+--
+
+'init'::
+ Initialize an existing git repository with additional
+ metadata directories for git-svndump. The Subversion URL
+ must be specified as the first non-optional command-line
+ argument. 'git' tree-ish that correspond to the HEAD of
+ that Subversion URL may be specified as the second optional
+ command-line argument.
+
+-f;;
+ git-svndump normally declines to reinitialize the same git
+ repository. With the '-f' option that behavior is overridden.
+
+'sync'::
+ Commit git revisions to the Subversion repository. If a git
+ <tree-ish> is specified as an optional command-line argument,
+ than all commits between the last 'sync' and that <tree-ish> are
+ send. If the argument is omitted, the HEAD of the active branch
+ is used.
+
+--
+
+BASIC EXAMPLE
+--------------
+
+Contributing to a Subversion repository:
+
+------------------------------------------------------------------------
+# Create your git repository, do some work and commit your changes
+# You are working on a computer A (git.foo.org)
+# Prepare your git repository for export (you are in the top dir)
+ git-svndump-init -A .auth http://svn.foo.org/project
+# Commit the whole branch:
+ git-svndump-sync
+# Now you go a different computer B
+# Clone a git repo:
+ git clone git.foo.org:/path/to/project.git
+# Enter the newly cloned directory:
+ cd project
+# Immediately prepare the new repository for export
+ git-svndump-init -A .auth http://svn.foo.org/project HEAD
+# Do some work and commit both locally and to A:
+ git commit ...
+ git push
+# Commit the new work:
+ git-svndump-sync
+# Now you return to the computer A
+# Reinit your repository for export!
+ git-svndump-init -f -A .auth http://svn.foo.org/project HEAD
+------------------------------------------------------------------------
+
+BUGS
+----
+
+The HEAD of the Subversion repository is not tracked. If your
+git-svndump repository goes out-of-sync with the Subversion mirror,
+the latter will most probably be corrupted.
+
+SEE ALSO
+--------
+gitlink:git-svn[1]
+
+Author
+------
+Written by Sergey Yanovich <ynvich@gmail.com>.
+
+Documentation
+-------------
+Written by Sergey Yanovich <ynvich@gmail.com>.
diff --git a/Makefile b/Makefile
index c09dfaf..ecf2803 100644
--- a/Makefile
+++ b/Makefile
@@ -211,6 +211,7 @@ SCRIPT_SH = \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
+ git-svndump-init.sh git-svndump-sync.sh \
git-lost-found.sh git-quiltimport.sh git-submodule.sh
SCRIPT_PERL = \
diff --git a/git-svndump-init.sh b/git-svndump-init.sh
new file mode 100755
index 0000000..4cf61b8
--- /dev/null
+++ b/git-svndump-init.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-init [-f] subversion-url [<commit>]
+ subversion-url -- URL of the subversion repository to which you want
+ to dump the current git repository
+ <commit> -- git <commit> that correspond to the latest revision
+ in the subversion repository
+OPTIONS
+ -f
+ do not stop, if the git repository is already initialized.
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test x$1 = x ; then
+ usage
+fi
+
+if test x$1 = x-f; then
+ shift
+ rm -rf $GIT_DIR/svndump
+fi
+
+if test -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: This git repository is already initialized
+ exit 1
+fi
+
+mkdir $GIT_DIR/svndump
+if test ! -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: Failed to create $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`svn info $1 >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-init: error: While quering $1
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+if test $rev -eq 0 ; then
+ mkdir -p $GIT_DIR/svndump/import && cd $GIT_DIR/svndump/import &&
+ svn import . $1 -m "Initial import by git-svndump"
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: error: Failed to init $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+ fi
+ rmdir $GIT_DIR/svndump/import
+fi
+
+echo "$1" > $GIT_DIR/svndump/url
+
+if test x$2 != x ; then
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $2`
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: warning: Bad commit $2 ignored"
+ else
+ echo $commit >> $GIT_DIR/svndump/last
+ fi
+fi
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
new file mode 100755
index 0000000..602af72
--- /dev/null
+++ b/git-svndump-sync.sh
@@ -0,0 +1,98 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-sync [<commit>]
+ <commit> -- git <commit> that correspond to the latest revision
+ to be dumped to the subversion repository
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test ! -d $GIT_DIR/svndump ; then
+ echo "git-svndump-sync: error: This git repository is not initialized"
+ echo " Run git-svndump-init first"
+ exit 1
+fi
+
+if test ! -f $GIT_DIR/svndump/url ; then
+ echo "git-svndump-sync: error: Cannot read url"
+ exit 1
+fi
+
+url=`cat $GIT_DIR/svndump/url`
+rev=`svn info $url >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-sync: error: While quering $url
+ rm -rf $GIT_DIR/svndump/error.log
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $url"
+ exit 1
+fi
+
+if test x$1 = x ; then
+ commit=HEAD
+else
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $1`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: error: Bad commit '$1'"
+ exit 1
+ fi
+fi
+
+start=""
+last=0000000000000000000000000000000000000000
+if test -f $GIT_DIR/svndump/last ; then
+ last=`cat $GIT_DIR/svndump/last`
+ start=^`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $last`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: warning: Ignoring bad commit '$last'"
+ start=""
+ last=0000000000000000000000000000000000000000
+ fi
+fi
+
+while true ; do
+
+list=`GIT_DIR=$GIT_DIR git-rev-list --topo-order $commit $start | tail -n 8`
+
+if test -z "$list" ; then
+ exit 0
+fi
+
+diffs=""
+for c in $list ; do
+ diffs="$c $diffs"
+done
+
+for c in $diffs ; do
+ GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ if test $? -ne 0 ; then
+ exit $?
+ fi
+ echo "$c" > $GIT_DIR/svndump/last
+ last=$c
+ let rev++
+done
+
+start=^$last
+
+done
--
1.5.2.1
^ permalink raw reply related
* [PATCH 3/3] Fix large-scale exports by 'git-svndump'
From: Sergey Yanovich @ 2007-06-19 6:54 UTC (permalink / raw)
To: git, normalperson, J.Sixt, masterdriverz; +Cc: Sergey Yanovich
In-Reply-To: <cff8d32813e43d9e1c75ad50824d95dbcd6f669c.1182235491.git.ynvich@gmail.com>
This is an empty patch. It is generated only to preserve headers
([PATCH x/y] ...) for two previous patches. May/should be ignored.
Thanks to Johannes Sixt <J.Sixt@eudaptics.com> for comments.
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svndump-sync.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
index 602af72..b3e47f9 100755
--- a/git-svndump-sync.sh
+++ b/git-svndump-sync.sh
@@ -96,3 +96,4 @@ done
start=^$last
done
+
--
1.5.2.1
^ permalink raw reply related
* [PATCH 1/3] Accept root <tree-ish> in 'git-svn commit-diff'
From: Sergey Yanovich @ 2007-06-19 6:54 UTC (permalink / raw)
To: git, normalperson, J.Sixt, masterdriverz; +Cc: Sergey Yanovich
In-Reply-To: <11821688443683-git-send-email-ynvich@gmail.com>
Experiments with Subversion (my version is 1.4.2) show that it is
not necessary to call 'svn import' before the first commit. Contrarily
to the Subversion documentation, first commit may be done even when
Subversion repository is at revision 0.
This allow export the whole git branch to a Subversion repo using only
'git-svn commit-diff'. Before this patch, however, 'git-svn' had
no means to operate on root commits.
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svn.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..8ad291b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2572,7 +2572,12 @@ sub generate_diff {
}
push @diff_tree, '--find-copies-harder' if $_find_copies_harder;
push @diff_tree, "-l$_rename_limit" if defined $_rename_limit;
- push @diff_tree, $tree_a, $tree_b;
+ if ($tree_a eq '0000000000000000000000000000000000000000') {
+ push @diff_tree, '--root';
+ } else {
+ push @diff_tree, $tree_a;
+ }
+ push @diff_tree, $tree_b;
my ($diff_fh, $ctx) = command_output_pipe(@diff_tree);
local $/ = "\0";
my $state = 'meta';
@@ -2606,6 +2611,8 @@ sub generate_diff {
}
$x->{file_b} = $_;
$state = 'meta';
+ } elsif ($state eq 'meta' && $_ eq $tree_b &&
+ $tree_a eq '0000000000000000000000000000000000000000') {
} else {
croak "Error parsing $_\n";
}
--
1.5.2.1
^ permalink raw reply related
* git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-19 6:50 UTC (permalink / raw)
To: git, normalperson, J.Sixt
A set of patches updated with comments from this list follows.
Thanks for your time.
^ permalink raw reply
* Re: merging git-p4 into git/fastimport.git (second try)
From: Simon Hausmann @ 2007-06-19 6:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070618230018.GA6143@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Tuesday 19 June 2007 01:00:18 Shawn O. Pearce wrote:
> Simon Hausmann <simon@lst.de> wrote:
> > after reworking most of the really short commit logs and adding the
> > missing SOB lines I'd like to ask for consideration of merging git-p4 as
> > part of contrib/fastimport/ from
> >
> > git://repo.or.cz/fast-export.git git-p4
>
> Most of the commits look pretty good. The effort you have put into
> cleaning them up shows.
>
> However, many of the oneline descriptions from Han-Wen Nienhuys
> are still really short and not very descriptive. They won't look
> very good in Junio's "What's in git.git". A few of yours are
> also pretty long winded for a typical oneline in git.git, but I'd
> rather have a descriptive-but-long oneline anytime over a short
> and undescriptive one.
Why not just leave out the entire lot of git-p4 logs in "What's in git.git"
this one time? I'm not sure of how much value it is at this point anyway. I'm
just interested in preserving the history to ease debugging.
> So I'm seriously considering merging this at this point. I'm heading
> out to dinner and will look at it more again when I get back, but
> I think we should just bite the bullet and bring it into core Git.
There's also another option that might help to keep the logs clean for future
plain "git log" usage and that is to prepend a "git-p4:" prefix to most of
the logs. That makes "git-p4: Documentation cleanups" look better I think and
it's really easy to do.
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Newbie using git -- need a little help
From: J. Bruce Fields @ 2007-06-19 4:10 UTC (permalink / raw)
To: Robert Smith; +Cc: git
In-Reply-To: <42118.74778.qm@web57410.mail.re1.yahoo.com>
On Sun, Jun 17, 2007 at 11:55:52AM -0700, Robert Smith wrote:
> I've read over the documentation (the full manual) numerous times and
> must admit it's slightly overwhelming.
...
> I have both a desktop computer, a laptop, and a server where I host my
> git repository. The goal for having this public repository is for me
> to be able to program on my desktop, then push the changes to the
> server, and then continue development on, say, my laptop later on
> grabbing the newer tree.
Others answered your question, I think, so I was just trying to figure
out how to make that bit of the manual more helpful. Do you think
something like this would have saved you any time?
--b.
(Feedback like "I tried to figure out how to do X by reading Y, and
couldn't" is much appreciated, by the way--thanks.)
---
Documentation/user-manual.txt | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e9da591..caa23c7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1772,7 +1772,7 @@ repository, but it works just as well in the other direction.
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
-commands that accepts repository URLs as arguments will also accept a
+commands that accept repository URLs as arguments will also accept a
local directory name:
-------------------------------------------------
@@ -1780,6 +1780,15 @@ $ git clone /path/to/repository
$ git pull /path/to/other/repository
-------------------------------------------------
+or an ssh url:
+
+-------------------------------------------------
+$ git clone ssh://yourhost/~you/repository
+-------------------------------------------------
+
+For projects with few developers, or for synchronizing a few private
+repositories, this may be all you need.
+
However, the more common way to do this is to maintain a separate public
repository (usually on a different host) for others to pull changes
from. This is usually more convenient, and allows you to cleanly
@@ -1802,6 +1811,8 @@ like this:
| they push V
their public repo <------------------- their repo
+We explain how to do this in the following sections.
+
[[setting-up-a-public-repository]]
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1913,6 +1924,12 @@ proceeding the branch name by a plus sign:
$ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
+Note that the target of a "push" is normally a
+<<def_bare_repository,bare>> repository. You can also push to a
+repository that has a checked-out working tree, but the working tree
+will not be updated by the push. This may lead to unexpected results if
+the branch you push to is the currently checked-out branch.
+
As with git-fetch, you may also set up configuration options to
save typing; so, for example, after
--
1.5.2.2.238.g7cbf2f2
^ permalink raw reply related
* Re: Versioning file system
From: Kyle Moffett @ 2007-06-19 3:10 UTC (permalink / raw)
To: Bryan Henderson
Cc: Jack Stone, Andrew Morton, alan, H. Peter Anvin, linux-fsdevel,
LKML Kernel, Al Viro, git
In-Reply-To: <OF7FA807A1.64C0D5AF-ON882572FE.0061B34C-882572FE.00628322@us.ibm.com>
On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>> The question remains is where to implement versioning: directly in
>> individual filesystems or in the vfs code so all filesystems can
>> use it?
>
> Or not in the kernel at all. I've been doing versioning of the
> types I described for years with user space code and I don't
> remember feeling that I compromised in order not to involve the
> kernel.
>
> Of course, if you want to do it with snapshots and COW, you'll have
> to ask where in the kernel to put that, but that's not a file
> versioning question; it's the larger snapshot question.
What I think would be particularly interesting in this domain is
something similar in concept to GIT, except in a file-system:
1) Redundancy is easy, you just ensure that you have at least "N"
distributed copies of each object, where "N" is some function of the
object itself.
2) Network replication is easy, you look up objects based on the
SHA-1 stored in the parent directory entry and cache them where
needed (IE: make the "N" function above dynamic based on frequency of
access on a given computer).
3) Snapshots are easy and cheap; an RO snapshot is a tag and an RW
snapshot is a branch. These can be easily converted between.
4) Compression is easy; you can compress objects based on any
arbitrary configurable criteria and the filesystem will record
whether or not an object is compressed. You can also compress
differently when archiving objects to secondary storage.
5) Streaming fsck-like verification is easy; ensure the hash name
field matches the actual hash of the object.
6) Fsck is easy since rollback is trivial, you can always revert
to an older tree to boot and start up services before attempting
resurrection of lost objects and trees in the background.
7) Multiple-drive or multiple-host storage pools are easy: Think
the git "alternates" file.
8) Network filesystem load-balancing is easy; SHA-1s are
essentially random so you can just assign SHA-1 prefixes to different
systems for data storage and your data is automatically split up.
Other issues:
Q. How do you deal with block allocation?
A. Same way other filesystems deal with block allocation. Reference-
counting gets tricky, especially across a network, but it's easy to
play it safe with simple cross-network refcount-journalling. Since
the _only_ thing that needs journalling is the refcounts and block-
free data, you need at most a megabyte or two of journal. If in
doubt, it's easy to play it safe and keep an extra refcount around
for an in-the-background consistency check later on. When networked-
gitfs systems crash, you just assume they still have all the
refcounts they had at the moment they died, and compare notes when
they start back up again. If a node has a cached copy of data on its
local disk then it can just nonatomically increment the refcount for
that object in its own RAM (ordered with respect to disk-flushes, of
course) and tell its peers at some point. A node should probably
cache most of its working set on local disk for efficiency; it's
trivially verified against updates from other nodes and provides an
easy way to keep refcounts for such data. If a node increments the
refcount on such data and dies before getting that info out to its
peers, then when it starts up again its peers will just be told that
it has a "new" node with insufficient replication and they will clone
it out again properly. For networked refcount-increments you can do
one of 2 things: (1) Tell at least X many peers and wait for them to
sync the update out to disk, or (2) Get the object from any peer (at
least one of whom hopefully has it in RAM) and save it to local disk
with an increased refcount.
Q. How do you actually delete things?
A. Just replace all the to-be-erased tree and commit objects before a
specified point with "History erased" objects with their SHA-1's
magically set to that of the erased objects. If you want you may
delete only the "tree" objects and leave the commits intact. If you
delete a whole linear segment of history then you can just use a
single "History erased" commit object with its parent pointed to the
object before the erased segment. Probably needs some form of back-
reference storage to make it efficient; not sure how expensive that
would be. This would allow making a bunch of snapshots and purging
them logarithmically based on passage of time. For instance, you
might have snapshots of every 5 minutes for the last hour, every 30
minutes for the last day, every 4 hours for the last week, every day
for the last month, once per week for the last year, once per month
for the last 5 years, and once per year beyond that.
That's pretty impressive data-recovery resolution, and it accounts
for only 200 unique commits after it's been running for 10 years.
Q. How do you archive data?
A. Same as deleting, except instead of a "History erased" object you
would use a "History archived" object with a little bit of string
data to indicate which volume it's stored on (and where on the
volume). When you stick that volume into the system you could easily
tell the kernel to use it as an alternate for the given storage group.
Q. What enforces data integrity?
A. Ensure that a new tree object and its associated sub objects are
on disk before you delete the old one. Doesn't need any actual full
syncs at all, just barriers. If you replace the tree object before
write-out is complete then just skip writing the old one and write
the new one in its place.
Q. What consists of a "commit"?
A. Anything the administrator wants to define it as. Useful
algorithms include: "Once per x Mbyte of page dirtying", "Once per 5
min", "Only when sync() or fsync() are called", "Only when gitfs-
commit is called". You could even combine them: "Every x Mbyte of
page dirtying or every 5 minutes, whichever is shorter (or longer,
depending on admin requirements)". There would also be appropriate
syscalls to trigger appropriate git-like behavior. Network-
accessible gitfs would want to have mechanisms to trigger commits
based on activity on other systems (needs more thought).
Q. How do you access old versions?
A. Mount another instance of the filesystem with an SHA-1 ID, a tag-
name, or a branch-name in a special mount option. Should be user
accessible with some restrictions (needs more thought).
Q. How do you deal with conflicts on networked filesystems.
A. Once again, however the administrator wants to deal with them.
Options:
1) Forcibly create a new branch for the conflicted tree.
2) Attempt to merge changes using the standard git-merge semantics
3) Merge independent changes to different files and pick one for
changes to the same file
4) Your Algorithm Here(TM). GIT makes it easy to extend
conflict-resolution.
Q. How do you deal with little scattered changes in big (or sparse)
files?
A. Two questions, two answers: For sparse files, git would need
extending to understand (and hash) the nature of the sparse-ness.
For big files, you should be able to introduce a "compound-file"
datatype and configure git to deal with specific X-Mbyte chunks of it
independently. This might not be a bad idea for native git as well.
Would need system-specific configuration.
Q. How do you prevent massive data consumption by spurious tiny changes
A. You have a few options:
1) Configure your commit algorithm as above to not commit so often
2) Configure a stepped commit-discard algorithm as described
above in the "How do you delete things" question
3) Archive unused data to secondary storage more often
Q. What about all the unanswered questions?
A. These are all the ones I could think of off the top of my head but
there are at least a hundred more. I'm pretty sure these are some of
the most significant ones.
Q. That's a great idea and I'll implement it right away!
A. Yay! (but that's not a question :-D) Good luck and happy hacking.
Q. That's a stupid idea and would never ever work!
A. Thanks for your useful input! (but that's not a question either)
I'm sure anybody who takes up a project like this will consider such
opinions.
Q. *flamage*
A. I'm glad you have such strong opinions, feel free to to continue
to spam my /dev/null device (and that's also not a question).
All opinions and comments welcomed.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH] make dist: include configure script in tarball
From: Junio C Hamano @ 2007-06-19 2:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0706190203111.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 19 Jun 2007, Jakub Narebski wrote:
>
>> Matthias Lederhofer wrote:
>>
>> > +dist: git.spec git-archive configure
>>
>> Ack. This way you don't need autoconf to ./configure install.
>
> ... but you force our good maintainer to have it installed...
Which is fine by me. I was wondering why this wish did not
surface much earlier myself.
Not that I'd use "./configure" myself nor help debugging the
autoconf-generated shell scripts ;-).
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-19 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Jakub Narebski
In-Reply-To: <7v645kyba8.fsf@assigned-by-dhcp.pobox.com>
On Mon, Jun 18, 2007 at 06:37:35PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Another possibility, though, is to say:
>
> core.some\0where\0core.over\0\0core.the\0core.rainbow\0
How do you denote empty values then?
[section]
key=
key
this are two very different statements atm (e.g. the one is false and
the other one is true).
I still think using two different delimiters is the simplest choice.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ 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