* Re: Question - .git subdirectories
@ 2019-10-31 23:01 10% ` Jonathan Nieder
0 siblings, 0 replies; 45+ results
From: Jonathan Nieder @ 2019-10-31 23:01 UTC (permalink / raw)
To: Arkadij Chistyj; +Cc: git, brian m. carlson
Hi Arkadij,
Arkadij Chistyj wrote:
> I just want that git
> treats my .git/ subdirs as plain dirs with any other names.
[...]
> It's very simple functionality but I can't find any simple and right solution.
> I just want to know is this possible or not? If not possible, then why?
To add to what brian wrote:
This is one of many things that Git doesn't track:
- empty directories
- full permissions for files it's tracking
- owner, group, other attributes
- resource fork on filesystems that support multiple forks
Git was initially designed to handle source code. Later, people have
started to use it for tracking other kinds of documents, which has been
nice. In general, when push comes to shove, the project has prioritized
making it work well for tracking source code and other documents.
Sometimes people find other uses for Git (deployment tool! home
directory tracker! configuration management system!). It can be
fun[1]. :) Ultimately, though, it's useful to keep the main goals of
Git in mind.
Sometimes people want to track a Git repository in another repository
as a source of test data for tests they include with their code. For
this use, using a "git fast-export" stream or other method for
generating a repository at test time can work better, or, if one
really must use a repo-in-repo, using a bare repository. Brian did a
good job of describing why.
Thanks and hope that helps,
Jonathan
[1] https://public-inbox.org/git/?q=ugfwiini
^ permalink raw reply [relevance 10%]
* Re: Using a different index and HEAD
@ 2010-11-21 15:16 14% ` Tomas Carnecky
0 siblings, 0 replies; 45+ results
From: Tomas Carnecky @ 2010-11-21 15:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Enrico Weigelt, git
On 11/13/10 6:25 PM, Jakub Narebski wrote:
> Enrico Weigelt<weigelt@metux.de> writes:
>
>> I'm currently thinking about an IDE toolkit entirely based on git,
>> which eg. versions every single file save operation (so, IOW: an
>> separately versioned workdir) automatically and later allows to
>> rebase/rework this to tell what really gets committed to the
>> actual working branch. For this multiple indices and refs/HEAD
>> pointers would be very helpful.
> UGFWIWNI (Using Git For What It Was Not Intended) ;-) ?
I haven't seen anyone UGFWIINI for in a long time. Either that or my
perception of 'not intended for' has changed. Maybe we should make a
second round of the contest and see what use cases people came up with
since the first UGFWIINI round (it's been almost two years). I'd
certainly be interested :)
tom
^ permalink raw reply [relevance 14%]
* Re: How do you best store structured data in git repositories?
@ 2009-12-04 0:14 10% ` David Aguilar
0 siblings, 0 replies; 45+ results
From: David Aguilar @ 2009-12-04 0:14 UTC (permalink / raw)
To: Avery Pennarun; +Cc: sebastianspublicaddress, git
On Wed, Dec 02, 2009 at 04:17:10PM -0500, Avery Pennarun wrote:
> On Wed, Dec 2, 2009 at 4:08 PM, Sebastian Setzer
> <sebastianspublicaddress@googlemail.com> wrote:
> > Do you store everything in a single file and configure git to use
> > special diff- and merge-tools?
> > Do you use XML for this purpose?
>
> XML is terrible for most data storage purposes. Data exchange, maybe,
> but IMHO the best thing you can do when you get XML data is to put it
> in some other format ASAP.
I agree 100%.
JSON's not too bad for data structures and is known to
be friendly to XML expats.
http://json.org/
> That said, however, you should still try to make your files as stable
> as possible, because:
>
> - If your program outputs the data in random order, it's just being
> sloppy anyway
>
> - 'git diff' doesn't work usefully otherwise (for examining the data
> and debugging)
If you were using Python + simplejson then using something
like the sort_keys=True flag would ensure that your data
is stable as the dictionaries keys will always appear in a
deterministic order.
Since I mentioned JSON and git in the same email then I might as
well also mention an old UGFWIINI candidate:
http://www.ordecon.com/2009/04/22/is-git-more-than-just-a-version-control-system/
Lastly, BERT might not be a good choice for storing inside
of a git repository, but it is a nice format for representing
data structures:
http://github.com/blog/531-introducing-bert-and-bert-rpc
We've been using git for tracking changes to a large set of
JSON files at $dayjob and it's worked out pretty well.
I'd suggest that you try to break your data up into multiple
files if possible. As someone else mentioned, it's often
easier to diff and merge stuff if you structure things in a
merge-friendly way.
One feature that we've implemented is file referencing
where data can "#include" another data file. That is
the kind of thing that can make things easier on you if
you foresee having a lot of common data that can be
shared amongst the various different files.
--
David
^ permalink raw reply [relevance 10%]
* Re: Continue git clone after interruption
2009-08-19 15:19 0% ` Jakub Narebski
@ 2009-08-19 19:04 0% ` Nicolas Pitre
0 siblings, 0 replies; 45+ results
From: Nicolas Pitre @ 2009-08-19 19:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git
On Wed, 19 Aug 2009, Jakub Narebski wrote:
> There are 114937 objects in this packfile, including 56249 objects
> used as base (can be deltified or not). git-verify-pack -v shows
> that all objects have total size-in-packfile of 33 MB (which agrees
> with packfile size of 33 MB), with 17 MB size-in-packfile taken by
> deltaified objects, and 16 MB taken by base objects.
>
> git verify-pack -v |
> grep -v "^chain" |
> grep -v "objects/pack/pack-" > verify-pack.out
>
> sum=0; bsum=0; dsum=0;
> while read sha1 type size packsize off depth base; do
> echo "$sha1" >> verify-pack.sha1.out
> sum=$(( $sum + $packsize ))
> if [ -n "$base" ]; then
> echo "$sha1" >> verify-pack.delta.out
> dsum=$(( $dsum + $packsize ))
> else
> echo "$sha1" >> verify-pack.base.out
> bsum=$(( $bsum + $packsize ))
> fi
> done < verify-pack.out
> echo "sum=$sum; bsum=$bsum; dsum=$dsum"
Your object classification is misleading. Because an object has no
base, that doesn't mean it is necessarily a base itself. You'd have to
store $base into a separate file and then sort it and remove duplicates
to know the actual number of base objects. What you have right now is
strictly delta objects and non-delta objects. And base objects can
themselves be delta objects already of course.
Also... my git repo after 'git gc --aggressive' contains a pack which
size is 22 MB. Your script tells me:
sum=22930254; bsum=14142012; dsum=8788242
and:
29558 verify-pack.base.out
82043 verify-pack.delta.out
111601 verify-pack.out
111601 verify-pack.sha1.out
meaning that I have 111601 total objects, of which 29558 are non-deltas
occupying 14 MB and 82043 are deltas occupying 8 MB. That certainly
shows how deltas are space efficient. And with a minor modification to
your script, I know that 44985 objects are actually used as a delta
base. So, on average, each base is responsible for nearly 2 deltas.
> >>>> (BTW what happens if this pack is larger than file size limit for
> >>>> given filesystem?).
> [...]
>
> >> If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
> >> FAT is often used on SSD, on USB drive. Although if you have 2 GB
> >> packfile, you are doing something wrong, or UGFWIINI (Using Git For
> >> What It Is Not Intended).
> >
> > Hopefully you're not performing a 'git clone' off of a FAT filesystem.
> > For physical transport you may repack with the appropriate switches.
>
> Not off a FAT filesystem, but into a FAT filesystem.
That's what I meant, sorry. My point still stands.
> > The front of the pack is the critical point. If you get enough to
> > create the top commit then further transfers can be done incrementally
> > with only the deltas between each commits.
>
> How? You have some objects that can be used as base; how to tell
> git-daemon that we have them (but not theirs prerequisites), and how
> to generate incrementals?
Just the same as when you perform a fetch to update your local copy of a
remote branch: you tell the remote about the commit you have and the one
you want, and git-repack will create delta objects for the commit you
want against similar objects from the commit you already have, and skip
those objects from the commit you want that are already included in the
commit you have.
> >> A question about pack protocol negotiation. If clients presents some
> >> objects as "have", server can and does assume that client has all
> >> prerequisites for such objects, e.g. for tree objects that it has
> >> all objects for files and directories inside tree; for commit it means
> >> all ancestors and all objects in snapshot (have top tree, and its
> >> prerequisites). Do I understand this correctly?
> >
> > That works only for commits.
>
> Hmmmm... how do you intent for "prefetch top objects restartable-y first"
> to work, then?
See my latest reply to dscho (you were in CC already).
> >> BTW. because of compression it might be more difficult to resume
> >> archive creation in the middle, I think...
> >
> > Why so? the tar+gzip format is streamable.
>
> gzip format uses sliding window in compression. "cat a b | gzip"
> is different from "cat <(gzip a) <(gzip b)".
>
> But that doesn't matter. If we are interrupted in the middle, we can
> uncompress what we have to check how far did we get, and tell server
> to send the rest; this way server wouldn't have to even generate
> (but not send) what we get as partial transfer.
You got it.
> P.S. What do you think about 'bundle' capability extension mentioned
> in a side sub-thread?
I don't like it. Reason is that it forces the server to be (somewhat)
stateful by having to keep track of those bundles and cycle them, and it
doubles the disk usage by having one copy of the repository in the form
of the original pack(s) and another copy as a bundle.
Of course, the idea of having a cron job generating a bundle and
offering it for download through HTTP or the like is fine if people are
OK with that, and that requires zero modifications to git. But I don't
think that is a solution that scales.
If you think about git.kernel.org which has maybe hundreds of
repositories where the big majority of them are actually forks of Linus'
own repository, then having all those forks reference Linus' repository
is a big disk space saver (and IO too as the referenced repository is
likely to remain cached in memory). Having a bundle ready for each of
them will simply kill that space advantage, unless they all share the
same bundle.
Now sharing that common bundle could be done of course, but that makes
things yet more complex while still wasting IO because some requests
will hit the common pack and some others will hit the bundle, making
less efficient usage of the disk cache on the server.
Yet, that bundle would probably not contain the latest revision if it is
only periodically updated, even less so if it is shared between multiple
repositories as outlined above. And what people with slow/unreliable
network links are probably most interested in is the latest revision and
maybe a few older revisions, but probably not the whole repository as
that is simply too long to wait for. Hence having a big bundle is not
flexible either with regards to the actual data transfer size.
Hence having a restartable git-archive service to create the top
revision with the ability to cheaply (in terms of network bandwidth)
deepen the history afterwards is probably the most straight forward way
to achieve that. The server needs no be aware of separate bundles, etc.
And the shared object store still works as usual with the same cached IO
whether the data is needed for a traditional fetch or a "git archive"
operation.
Why "git archive"? Because its content is well defined. So if you give
it a commit SHA1 you will always get the same stream of bytes (after
decompression) since the way git sort files is strictly defined. It is
therefore easy to tell a remote "git archive" instance that we want the
content for commit xyz but that we already got n files already, and that
the last file we've got has m bytes. There is simply no confusion about
what we've got already, unlike with a partial pack which might need
yet-to-be-received objects in order to make sense of what has been
already received. The server simply has to skip that many files and
resume the transfer at that point, independently of the compression or
even the archive format.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: Continue git clone after interruption
2009-08-18 21:32 0% ` Nicolas Pitre
@ 2009-08-19 15:19 0% ` Jakub Narebski
2009-08-19 19:04 0% ` Nicolas Pitre
0 siblings, 1 reply; 45+ results
From: Jakub Narebski @ 2009-08-19 15:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Jakub Narebski wrote:
>
>> You can probably get number and size taken by delta and non-delta (base)
>> objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
>> nor contrib/stats/packinfo.pl did help me arrive at this data.
>
> Documentation for verify-pack says:
>
> |When specifying the -v option the format used is:
> |
> | SHA1 type size size-in-pack-file offset-in-packfile
> |
> |for objects that are not deltified in the pack, and
> |
> | SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
> |
> |for objects that are deltified.
>
> So a simple script should be able to give you the answer.
Thanks.
There are 114937 objects in this packfile, including 56249 objects
used as base (can be deltified or not). git-verify-pack -v shows
that all objects have total size-in-packfile of 33 MB (which agrees
with packfile size of 33 MB), with 17 MB size-in-packfile taken by
deltaified objects, and 16 MB taken by base objects.
git verify-pack -v |
grep -v "^chain" |
grep -v "objects/pack/pack-" > verify-pack.out
sum=0; bsum=0; dsum=0;
while read sha1 type size packsize off depth base; do
echo "$sha1" >> verify-pack.sha1.out
sum=$(( $sum + $packsize ))
if [ -n "$base" ]; then
echo "$sha1" >> verify-pack.delta.out
dsum=$(( $dsum + $packsize ))
else
echo "$sha1" >> verify-pack.base.out
bsum=$(( $bsum + $packsize ))
fi
done < verify-pack.out
echo "sum=$sum; bsum=$bsum; dsum=$dsum"
>>>> (BTW what happens if this pack is larger than file size limit for
>>>> given filesystem?).
[...]
>> If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
>> FAT is often used on SSD, on USB drive. Although if you have 2 GB
>> packfile, you are doing something wrong, or UGFWIINI (Using Git For
>> What It Is Not Intended).
>
> Hopefully you're not performing a 'git clone' off of a FAT filesystem.
> For physical transport you may repack with the appropriate switches.
Not off a FAT filesystem, but into a FAT filesystem.
[...]
>>> I think it is better to "prime" the repository with the content of the
>>> top commit in the most straight forward manner using git-archive which
>>> has the potential to be fully restartable at any point with little
>>> complexity on the server side.
>>
>> But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
>
> The front of the pack is the critical point. If you get enough to
> create the top commit then further transfers can be done incrementally
> with only the deltas between each commits.
How? You have some objects that can be used as base; how to tell
git-daemon that we have them (but not theirs prerequisites), and how
to generate incrementals?
>> A question about pack protocol negotiation. If clients presents some
>> objects as "have", server can and does assume that client has all
>> prerequisites for such objects, e.g. for tree objects that it has
>> all objects for files and directories inside tree; for commit it means
>> all ancestors and all objects in snapshot (have top tree, and its
>> prerequisites). Do I understand this correctly?
>
> That works only for commits.
Hmmmm... how do you intent for "prefetch top objects restartable-y first"
to work, then?
>> BTW. because of compression it might be more difficult to resume
>> archive creation in the middle, I think...
>
> Why so? the tar+gzip format is streamable.
gzip format uses sliding window in compression. "cat a b | gzip"
is different from "cat <(gzip a) <(gzip b)".
But that doesn't matter. If we are interrupted in the middle, we can
uncompress what we have to check how far did we get, and tell server
to send the rest; this way server wouldn't have to even generate
(but not send) what we get as partial transfer.
P.S. What do you think about 'bundle' capability extension mentioned
in a side sub-thread?
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 0%]
* Re: Continue git clone after interruption
2009-08-18 21:02 9% ` Jakub Narebski
@ 2009-08-18 21:32 0% ` Nicolas Pitre
2009-08-19 15:19 0% ` Jakub Narebski
0 siblings, 1 reply; 45+ results
From: Nicolas Pitre @ 2009-08-18 21:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git
On Tue, 18 Aug 2009, Jakub Narebski wrote:
> You can probably get number and size taken by delta and non-delta (base)
> objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
> nor contrib/stats/packinfo.pl did help me arrive at this data.
Documentation for verify-pack says:
|When specifying the -v option the format used is:
|
| SHA1 type size size-in-pack-file offset-in-packfile
|
|for objects that are not deltified in the pack, and
|
| SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
|
|for objects that are deltified.
So a simple script should be able to give you the answer.
> >> (BTW what happens if this pack is larger than file size limit for
> >> given filesystem?).
> >
> > We currently fail. Seems that no one ever had a problem with that so
> > far. We'd have to split the pack stream into multiple packs on the
> > receiving end. But frankly, if you have a repository large enough to
> > bust your filesystem's file size limit then maybe you should seriously
> > reconsider your choice of development environment.
>
> Do we fail gracefully (with an error message), or does git crash then?
If the filesystem is imposing the limit, it will likely return an error
on the write() call and we'll die(). If the machine has a too small
off_t for the received pack then we also die("pack too large for current
definition of off_t").
> If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
> FAT is often used on SSD, on USB drive. Although if you have 2 GB
> packfile, you are doing something wrong, or UGFWIINI (Using Git For
> What It Is Not Intended).
Hopefully you're not performing a 'git clone' off of a FAT filesystem.
For physical transport you may repack with the appropriate switches.
> >> If it fails, client ask first for first half of of
> >> repository (half as in bisect, but it is server that has to calculate
> >> it). If it downloads, it will ask server for the rest of repository.
> >> If it fails, it would reduce size in half again, and ask about 1/4 of
> >> repository in packfile first.
> >
> > Problem people with slow links have won't be helped at all with this.
> > What if the network connection gets broken only after 49% of the
> > transfer and that took 3 hours to download? You'll attempt a 25% size
> > transfer which would take 1.5 hour despite the fact that you already
> > spent that much time downloading that first 1/4 of the repository
> > already. And yet what if you're unlucky and now the network craps on
> > you after 23% of that second attempt?
>
> A modification then.
>
> First try ordinary clone. If it fails because network is unreliable,
> check how much we did download, and ask server for packfile of slightly
> smaller size; this means that we are asking server for approximate pack
> size limit, not for bisect-like partitioning revision list.
If the download didn't reach past the critical point (75 MB in my linux
repo example) then you cannot validate the received data and you've
wasted that much bandwidth.
> > I think it is better to "prime" the repository with the content of the
> > top commit in the most straight forward manner using git-archive which
> > has the potential to be fully restartable at any point with little
> > complexity on the server side.
>
> But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
The front of the pack is the critical point. If you get enough to
create the top commit then further transfers can be done incrementally
with only the deltas between each commits.
> A question about pack protocol negotiation. If clients presents some
> objects as "have", server can and does assume that client has all
> prerequisites for such objects, e.g. for tree objects that it has
> all objects for files and directories inside tree; for commit it means
> all ancestors and all objects in snapshot (have top tree, and its
> prerequisites). Do I understand this correctly?
That works only for commits.
> If we have partial packfile which crashed during downloading, can we
> extract from it some full objects (including blobs)? Can we pass
> tree and blob objects as "have" to server, and is it taken into account?
No.
> Perhaps instead of separate step of resumable-downloading of top commit
> objects (in snapshot), we can pass to server what we did download in
> full?
See above.
> BTW. because of compression it might be more difficult to resume
> archive creation in the middle, I think...
Why so? the tar+gzip format is streamable.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: Continue git clone after interruption
@ 2009-08-18 21:02 9% ` Jakub Narebski
2009-08-18 21:32 0% ` Nicolas Pitre
0 siblings, 1 reply; 45+ results
From: Jakub Narebski @ 2009-08-18 21:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Jakub Narebski wrote:
>> Nicolas Pitre <nico@cam.org> writes:
>>> That won't buy you much. You should realize that a pack is made of:
>>>
>>> 1) Commit objects. Yes they're all put together at the front of the pack,
>>> but they roughly are the equivalent of:
>>>
>>> git log --pretty=raw | gzip | wc -c
>>>
>>> For the Linux repo as of now that is around 32 MB.
>>
>> For my clone of Git repository this gives 3.8 MB
>>
>>> 2) Tree and blob objects. Those are the bulk of the content for the top
>>> commit. [...] You can estimate the size of this data with:
>>>
>>> git archive --format=tar HEAD | gzip | wc -c
>>>
>>> On the same Linux repo this is currently 75 MB.
>>
>> On the same Git repository this gives 2.5 MB
>
> Interesting to see that the commit history is larger than the latest
> source tree. Probably that would be the same with the Linux kernel as
> well if all versions since the beginning with adequate commit logs were
> included in the repo.
Note that having reflog and/or patch management interface like StGit,
and frequently reworking commits (e.g. using rebase) means more commit
objects in repository.
Also Git repository has 3 independent branches: 'man', 'html' and 'todo',
from whose branches objects are not included in "git archive HEAD".
>
>>> 3) Delta objects. Those are making the rest of the pack, plus a couple
>>> tree/blob objects that were not found in the top commit and are
>>> different enough from any object in that top commit not to be
>>> represented as deltas. Still, the majority of objects for all the
>>> remaining commits are delta objects.
>>
>> You forgot that delta chains are bound by pack.depth limit, which
>> defaults to 50. You would have then additional full objects.
>
> Sure, but that's probably not significant. the delta chain depth is
> limited, but not the width. A given base object can have unlimited
> delta "children", and so on at each depth level.
You can probably get number and size taken by delta and non-delta (base)
objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
nor contrib/stats/packinfo.pl did help me arrive at this data.
>> The single packfile for this (just gc'ed) Git repository is 37 MB.
>> Much more than 3.8 MB + 2.5 MB = 6.3 MB.
>
> What I'm saying is that most of that 37 MB - 6.3 MB = 31 MB is likely to
> be occupied by deltas.
True.
>> [cut]
>>
>> There is another way which we can go to implement resumable clone.
>> Let's git first try to clone whole repository (single pack; BTW what
>> happens if this pack is larger than file size limit for given
>> filesystem?).
>
> We currently fail. Seems that no one ever had a problem with that so
> far. We'd have to split the pack stream into multiple packs on the
> receiving end. But frankly, if you have a repository large enough to
> bust your filesystem's file size limit then maybe you should seriously
> reconsider your choice of development environment.
Do we fail gracefully (with an error message), or does git crash then?
If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
FAT is often used on SSD, on USB drive. Although if you have 2 GB
packfile, you are doing something wrong, or UGFWIINI (Using Git For
What It Is Not Intended).
>> If it fails, client ask first for first half of of
>> repository (half as in bisect, but it is server that has to calculate
>> it). If it downloads, it will ask server for the rest of repository.
>> If it fails, it would reduce size in half again, and ask about 1/4 of
>> repository in packfile first.
>
> Problem people with slow links have won't be helped at all with this.
> What if the network connection gets broken only after 49% of the
> transfer and that took 3 hours to download? You'll attempt a 25% size
> transfer which would take 1.5 hour despite the fact that you already
> spent that much time downloading that first 1/4 of the repository
> already. And yet what if you're unlucky and now the network craps on
> you after 23% of that second attempt?
A modification then.
First try ordinary clone. If it fails because network is unreliable,
check how much we did download, and ask server for packfile of slightly
smaller size; this means that we are asking server for approximate pack
size limit, not for bisect-like partitioning revision list.
> I think it is better to "prime" the repository with the content of the
> top commit in the most straight forward manner using git-archive which
> has the potential to be fully restartable at any point with little
> complexity on the server side.
But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
A question about pack protocol negotiation. If clients presents some
objects as "have", server can and does assume that client has all
prerequisites for such objects, e.g. for tree objects that it has
all objects for files and directories inside tree; for commit it means
all ancestors and all objects in snapshot (have top tree, and its
prerequisites). Do I understand this correctly?
If we have partial packfile which crashed during downloading, can we
extract from it some full objects (including blobs)? Can we pass
tree and blob objects as "have" to server, and is it taken into account?
Perhaps instead of separate step of resumable-downloading of top commit
objects (in snapshot), we can pass to server what we did download in
full?
BTW. because of compression it might be more difficult to resume
archive creation in the middle, I think...
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 9%]
* Git User's Survey 2009 partial summary, part 2 - from first 10
@ 2009-08-17 10:24 4% Jakub Narebski
0 siblings, 0 replies; 45+ results
From: Jakub Narebski @ 2009-08-17 10:24 UTC (permalink / raw)
To: git
Git User's Survey 2009 partial summary, part 2 - git difficulty,
proficiency, uses, install, OS, editors.
It more than a month since Git User's Suvey 2009 was started (it was
started on 15 July 2009), which is a half of planned duration time of
the survey.
So I think this is time for second part partial summary of Git User's
Survey 2009. The previous part can be found at
http://thread.gmane.org/gmane.comp.version-control.git/124599
Subject: Git User's Survey 2009 partial summary, part 1 -
- announcing survey, participation
Message-Id: <200907312246.12134.jnareb@gmail.com>
You can see summary of Git User's Survey 2009 responses (and make your
own analysis) at the following URL:
http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
http://tinyurl.com/GitSurvey2009Analyze
After the survey ends (or earlier, if it is requested) the raw data
would be published on GitSurvey2009 page on Git Wiki in CSV and XLS
formats (like for GitSurvey2008).
We have currently (at the time I have checked this) around 3089
responses, as compared to 3236 individual responses (including 21
responses in 'test' channel) for survey in 2008, 683 individual
responses in 2007, and around 117 responses in 2006.
Below there is analysis of few questions from this survey; note that
results might do not add to 100% because of replies during using live
analysis tool, and the rounding.
3) Have you found Git easy to learn?
4) Have you found Git easy to use?
(Choice - Single answer)
================================================
Answer | to learn [%] | to use [%]
------------------------------------------------
Very easy | 4% | 9%
Easy | 20% | 36%
Reasonably easy | 55% | 45%
Hard | 19% | 8%
Very hard | 2% | 1%
------------------------------------------------
Total respondents | 2942 | 2959
================================================
As you can see the myth that Git is hard to learn was busted ;-) Not.
When analyzing this data you should take into account that somebody
considering or finding Git to hard to learn wouldn't be probably Git
user, and thus wouldn't fill this survey. So because it is
*Git User's* Survey we should consider that results can be skewed
towards lower value (easier).
What's interesting is comparing (percentage) results for questions
3. and 4.; how hard is git to learn versus how hard is to use. It
seems like Git is reasonably easy to learn, and reasonably easy to
easy to use. So it looks like Git just have somewhat steep learning
curve, and the difficulty to learn pays in being more powerful to
use.
6) Rate your own proficiency with Git:
(Choice - Single answer)
You can think of it as 1-5 numerical grade of your proficiency in Git.
================================================
Proficiency | resp [%] | resp [n]
------------------------------------------------
1. novice | 4% | 114
2. casual, needs advice | 17% | 520
3. everyday use | 38% | 1138
4. can offer advice | 34% | 1020
5. know it very well | 6% | 192
--------------------------+---------------------
Total respondents | 2984
Skipped this question | 105
================================================
As you can see most responders know Git enough for everyday use, or
can even offer some Git advice. If we treat possible answers as a
proficiency grade, the average proficiency is around 3.2.
Either Git users don't stay novices long, or survey announcement(s)
didn't reach novice users.
This data could be useful later to be able to check how it differs
git usage for novices and for gurus (what commands they run, what
features they use at different levels of proficiency).
7) I use Git for (check all that apply):
(Choice - Multiple answers)
Note that above choices are neither orthogonal nor exclusive. One
might want to check multiple answers even for a single repository.
============================================
Answer | resp [%] | resp [n]
--------------------------------------------
work projects | 79% | 2366
unpaid projects | 80% | 2391
............................................
work and unpaid | 66% | 1960
only work | 14% | 407
only unpaid | 15% | 432
not answered | 6% | 190
--------------------------------------------
proprietary projects | 37% | 1108
OSS development | 69% | 2054
private code | 77% | 2315
--------------------------------------------
code (programming) | 87% | 2591
web app | 43% | 1274
configuration files | 34% | 1010
personal data | 33% | 972
documents | 32% | 956
static website | 29% | 881
--------------------------------------------
frontend to other SCM | 32% | 971
sharing data or sync | 22% | 645
backup | 24% | 722
backend for web app | 9% | 263
............................................
--------------------------------------------
other | 3% | 84
============================================
Total respondents | 2989
Skipped this question | 104
============================================
The answers in the table above are in slightly different order than in
original, i.e. in the survey. Analysis of correlations was done here
only for work / unpaid part of answer (see table above).
This question joins together (to reduce number of questions in the
survey) few separate issues:
* Whether one use Git for work, or for unpaid projects: this survey
results shows that the amount of paid and unpaid projects are about
the same, and that most of people (most of responders) us Git for
both work (paid) and free (unpaid) projects.
* The question of openess / license: whether one uses Git for
proprietary projects or for FLOSS (Free/Libre/Open Source
Software), or perhaps for private code (not covered by license).
Here OSS development and private code/data dominates over using Git
for proprietary code, with around twice as much answers. This may
be caused by the fact that Git is / feels more suited to opensource
(like) development (proprietary code can use proprietary SCM), but
it might be that announcement didn't make it to people using Git
for proprietary works.
* Whether one uses Git for code (for something it was created for),
or for other things like documents etc. Here code dominates,
having around twice as many replies as the next in turn, 'web app'
(which is also code, but a special case, and not only code).
* next is UGFWIINI part: using Git for what it was not intended.
Well, except perhaps using Git as frontend or fat-client for other
SCM (e.g. git-svn for Subversion). Using Git for other SCM
dominates with 32%, next are using Git for sharing, and for backup
(both with around 23% of responses).
* The "other (please specify)" is not yet analyzed (nor even began
analysis so far).
8) How do/did you obtain Git (install and/or upgrade)?
(Choice - Multiple answers)
Explanation: binary package covers pre-compiled binary (e.g. from rpm
or deb binary packages); source package covers things like deb-src and
SRPMS/*.src.rpm; source script is meant to cover installation in
source-based distributions, like 'emerge' in Gentoo.
Automatic update (apt, yum, etc.) in most cases means binary package
install; unless one uses source-based distribution like Gentoo, CRUX,
or SourceMage, where automatic update means using source package (or
source script).
The option named "preinstalled / sysadmin job" means that either you
didn't need to install git because it was preinstalled (and you didn't
upgrade); or that you have to ask system administrator to have git
installed or upgraded.
Note that this question is multiple choices question because one can
install Git in different ways on different machines or on different
operating systems.
==================================================
Answer | resp [%] | resp [n]
--------------------------------------------------
binary package | 71% | 2118
source package or script | 24% | 704
source tarball | 20% | 588
pull from repository | 18% | 527
preinstalled / sysadmin job | 6% | 185
other - please specify | 4% | 123
----------------------------+---------------------
Total respondents | 2975
Skipped this question | 118
==================================================
Most people (71%) use ready binary packages, which was kind of
expected; that is the easiest way.
9) On which operating system(s) do you use Git?
(Choice - Multiple answers)
On Unix-based operating system you can get the name of operation
system by running 'uname'.
============================================================
Operating system | resp [%] | resp [n]
------------------------------------------------------------
Linux | 88% | 2623
MacOS X (Darwin) | 44% | 1304
MS Windows/Cygwin | 9% | 279
MS Windows/msysGit (MINGW) | 21% | 625
*BSD (FreeBSD, OpenBSD, NetBSD, etc.) | 7% | 213
OpenSolaris | 3% | 101
other Unix | 2% | 60
Other, please specify | 2% | 46
......................................|..........|..........
MS Windows (any) | 27% | 820
--------------------------------------+---------------------
Total respondents | 2991
Respondents who skipped this question | 102
============================================================
Most common used operating system is Linux, next is MacOS X, and then
MS Windows (on MS Window dominates msysGit version). This is quite
understandable, as Git was created on Linux and for Linux, and it
works best there.
The "other" answer include Solaris, AIX, HP-UX (other Unix), GNU/Linux
(Linux), Debian, NixOS (Linux distributions), none (?); iPod, OpenVMS,
QNX, Hurd and "my toaster" (?). And some commentaries and
clarifications.
10) What do you use to edit contents under version control with Git?
What kind of editor, IDE or RAD you use working with Git?
(Choice - Multiple answers)
* "simple text editor" option includes editors such as pico, nano,
joe, Notepad,
* "programmers editor" option includes editors such as Emacs/XEmacs,
Vim, TextMate, SciTE (syntax highlighting, autoindentation,
integration with other programmers tools, etc.)
* "IDE (Integrated Development Environment) and RAD (Rapid Application
Development)" option includes tools such as Eclipse, NetBeans IDE,
IntelliJ IDE, MS Visual Studio, KDevelop, Anjuta, Xcode,
Code::Blocks but also tools such as Quanta+, BlueFish or Screem (for
editing HTML, CSS, PHP etc.), and Kile or LEd for LaTeX.
* "WYSIWYG tools" option includes word processors such as MS Office or
OpenOffice.org, but also tools such as Adobe Acrobat (for PDF) or
GIMP (for images), or WYSIWYG DTP tools such as QuarkXPress,
PageMaker or Scribus, or WYSIWYG HTML editors such as FrontPage,
Dreamweaver or KompoZer.
============================================================
Answer | resp [%] | resp [n]
------------------------------------------------------------
simple text editor | 25% | 752
programmers editor | 88% | 2641
IDE or RAD | 32% | 960
WYSIWYG tool | 5% | 159
other kind - please specify | 3% | 95
--------------------------------------+---------------------
Total respondents | 2985
Respondents who skipped this question | 108
============================================================
Most popular kind of tool is programmer's editor with very strong 88%
lead. Next in turn are IDE or RAD with 32%, followed by simple text
editor, with 25%. The WYSIWYG tools are last, with very small 5% of
replies; also people who use WYSIWYG tools also use other kind of
tools to edit (presumably to edit commit message at least).
>From browsing through "other tool" responses it seem like there should
be included 'web interface' among possible tools (written as: wiki
frontend, GitHub editor, <textarea>). Other responses include Xournal
(note taking application for graphic tablet, using stylus), Tinderbox
(also note taking application), Git GUI tool: GitX (?), custom
git-aware CMS (probably also 'web interface'), scripts and oneliners,
command line and 'On occasion, Unix text manipulation tools'. Also
there is "audio editors" answer (which probably should fall under
"WYSIWYG tool)...
Many answers in 'other tool' falls in one of ready categories; perhaps
they are clarification?
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply [relevance 4%]
* Re: How is git used as other than the project's version control?
@ 2009-04-28 1:44 10% ` Jeff King
0 siblings, 0 replies; 45+ results
From: Jeff King @ 2009-04-28 1:44 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
On Mon, Apr 27, 2009 at 06:55:38PM -0400, John Dlugosz wrote:
> I'm interested in finding out how people use git "on the side", when it
> is not the project's actual version control system.
Thomas already mentioned using "git diff" separate from a git
repository; I find that "git diff --color-words" is much nicer than
"wdiff", which does something similar (though I rarely use it outside of
a repo only because I put _everything_ into git :) ).
One of the nice things about git (and other distributed VCS's) is that
creating a repo is very lightweight. If I am going to write a patch for
some other software, the first thing I'll do after untarring it is "git
init; git add .; git commit -m import". So it kind of blurs the concept
of "what is the project's actual version control system" as you wrote
above. If you consider the project to be my patch, it _is_ the VCS. Even
though upstream may not be using it.
And of course, if I am going to do multiple patches, then I may convert
and track upstream's history via git.
If you are looking for exotic uses of git, you may be interested in
Dscho's "Using Git For What It Is Not Intended" contest:
http://search.gmane.org/?query=UGFWIINI
-Peff
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (8 preceding siblings ...)
2009-03-27 15:08 21% ` Jakub Narebski
@ 2009-04-22 10:52 10% ` Pieter de Bie
9 siblings, 0 replies; 45+ results
From: Pieter de Bie @ 2009-04-22 10:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On 17 feb 2009, at 16:47, Johannes Schindelin wrote:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of
> ideas
> how to
>
> Use Git For What It Is Not Indended
I would like to submit
http://www.ordecon.com/2009/04/22/is-git-more-than-just-a-version-control-system/
for the next round :)
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-27 15:08 21% ` Jakub Narebski
@ 2009-03-28 7:42 20% ` Jeff King
0 siblings, 0 replies; 45+ results
From: Jeff King @ 2009-03-28 7:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git
On Fri, Mar 27, 2009 at 08:08:04AM -0700, Jakub Narebski wrote:
> Not exactly UGFWIINI yet, but:
>
> "Music collaboration via git?"
> http://www.37signals.com/svn/posts/1655-music-collaboration-via-git
> (sharing LilyPond source files for music notation).
I do something similar, though I am usually not writing in lilypond but
rather in ABC or human-readable chord charts with accompanying lyrics.
However, my band-mates are not git-literate, so I usually end up pulling
their versions directly from email into the working tree, and then
committing to git myself.
For added UGFWIINI, I also keep multitrack recording projects in the
same repo. Live single tracks are kept as pristine "source", and then
are mixed down (with filters and effects added) into a final product.
It's even driven by make. ;)
However, the source files are annoyingly large to work with in git, so I
keep them outside of the repo as immutable source and refer to them by
unique name. Only the ways in which they are filtered or combined are in
the repo.
-Peff
^ permalink raw reply [relevance 20%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (7 preceding siblings ...)
2009-03-11 10:27 21% ` Jakub Narebski
@ 2009-03-27 15:08 21% ` Jakub Narebski
2009-03-28 7:42 20% ` Jeff King
2009-04-22 10:52 10% ` Pieter de Bie
9 siblings, 1 reply; 45+ results
From: Jakub Narebski @ 2009-03-27 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
>
> As most of you probably did not find my blog yet, this may come as a
> surprise to you, but it will not be the only surprise in this email.
[...]
Not exactly UGFWIINI yet, but:
"Music collaboration via git?"
http://www.37signals.com/svn/posts/1655-music-collaboration-via-git
(sharing LilyPond source files for music notation).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [relevance 21%]
* Re: First round of UGFWIINI results
2009-03-11 10:27 21% ` Jakub Narebski
@ 2009-03-11 12:09 10% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-11 12:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Hi,
On Wed, 11 Mar 2009, Jakub Narebski wrote:
> P.S. When there would be next round of UGFWIINI contest?
Whenever I collected ten new participants... You are helping ;-)
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (6 preceding siblings ...)
2009-03-03 15:09 10% ` Reece Dunn
@ 2009-03-11 10:27 21% ` Jakub Narebski
2009-03-11 12:09 10% ` Johannes Schindelin
2009-03-27 15:08 21% ` Jakub Narebski
2009-04-22 10:52 10% ` Pieter de Bie
9 siblings, 1 reply; 45+ results
From: Jakub Narebski @ 2009-03-11 10:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
[...]
> Number 2:
>
> At the GitTogether, Sam Vilain presented his idea to use Git as a DB backend:
>
> http://utsl.gen.nz/talks/git-db
>
> Just think about it: committing by "INSERT INTO"!
And something very similar: "Using Git as a versioned data store
in Python" by John Wiegley (similar to 'shelve' which uses database)
http://www.newartisans.com/2008/05/using-git-as-a-versioned-data-store-in-python.html
http://github.com/jwiegley/git-issues/
And similar solution for Ruby
http://github.com/georgi/git_store
by the way of GitHub Blog:
http://github.com/blog/374-git-as-a-data-store-in-python-and-ruby
P.S. When there would be next round of UGFWIINI contest?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [relevance 21%]
* Re: First round of UGFWIINI results
2009-03-07 0:56 9% ` Jakub Narebski
@ 2009-03-07 2:40 10% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-07 2:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Hi,
On Fri, 6 Mar 2009, Jakub Narebski wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Dear fans of Git,
> > >
> > > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > > how to
> > >
> > > Use Git For What It Is Not Indended
> > >
> > > As most of you probably did not find my blog yet, this may come as a
> > > surprise to you, but it will not be the only surprise in this email.
> [...]
>
> > Another candidate for UGFWIINI contest: Gitorial. Here is explanation
>
> > And similar thing: Homoiconic. Here is explanation
>
> And here is yet another UGFWINII candidate: Flashbake.
Thanks. Accepted.
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 10:30 20% ` Jakub Narebski
2009-03-03 11:20 10% ` Johannes Schindelin
@ 2009-03-07 0:56 9% ` Jakub Narebski
2009-03-07 2:40 10% ` Johannes Schindelin
1 sibling, 1 reply; 45+ results
From: Jakub Narebski @ 2009-03-07 0:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Dear fans of Git,
> >
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
> >
> > As most of you probably did not find my blog yet, this may come as a
> > surprise to you, but it will not be the only surprise in this email.
[...]
> Another candidate for UGFWIINI contest: Gitorial. Here is explanation
> And similar thing: Homoiconic. Here is explanation
And here is yet another UGFWINII candidate: Flashbake.
Here is explanation:
Flashbake is a set of Python scripts that check your hot files for
changes every 15 minutes, and checks in any changed files to a local
git repository. Flashbake records any changes made since the last
check, annotating them with the current timezone on the
system-clock, the weather in that timezone as fetched from Google,
and the last three headlines with your by-line under them in your
blog's RSS feed (I've been characterizing this as "Where am I,
what's it like there, and what am I thinking about?"). It also
records your computer's uptime.
It is intendend illuminate the creative process in a way that often
reveals the hidden stories behind the books we care about.
References:
===========
[1] "Flashbake: Free version-control for writers using git"
by Cory Doctorow describes insporation for Flashbake
http://www.boingboing.net/2009/02/13/flashbake-free-versi.html
http://craphound.com/?p=2171
[2] "Cory Doctorow on Lifestreaming Contextual Snapshots Using New
Tool Flashbake" by Mark Krynsky
http://lifestreamblog.com/cory-doctorow-on-lifestreaming-contextual-snapshots-using-new-tool-flashbake/
[3] Flashbake announcement on its author blog
http://thecommandline.net/2009/02/13/flashbake/
[3] Flashbake home page
http://bitbucketlabs.net/flashbake/
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [relevance 9%]
* Re: First round of UGFWIINI results
2009-03-03 17:34 10% ` Jeff King
@ 2009-03-03 17:49 10% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Reece Dunn, git
Hi,
On Tue, 3 Mar 2009, Jeff King wrote:
> On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:
>
> > I am interested in reading Reece's short stories, though.
>
> I can only hope that they're git-themed (Linus fan-fiction?).
No, that is an intended purpose of Git. To worship Linus.
Thus, it would not qualify.
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 16:26 10% ` Sverre Rabbelier
@ 2009-03-03 17:36 10% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 17:36 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Reece Dunn, git
Hi,
On Tue, 3 Mar 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:
> > Are you also in the contest, with your blog as one of the contenders?
>
> I remember Dscho saying anything mentioned in the announcement does
> not count, but upon later inspection of the original post I cannot
> find it...?
I thought so, too, but from the git log it does not seem like it. Of
course, I sneakily rewrote history from time to time (so it should be
in git log -g, but that computer is at home) ;-)
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 17:27 10% ` Johannes Schindelin
2009-03-03 17:31 10% ` Reece Dunn
@ 2009-03-03 17:34 10% ` Jeff King
2009-03-03 17:49 10% ` Johannes Schindelin
1 sibling, 1 reply; 45+ results
From: Jeff King @ 2009-03-03 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:
> I am interested in reading Reece's short stories, though.
I can only hope that they're git-themed (Linus fan-fiction?).
-Peff
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 17:27 10% ` Johannes Schindelin
@ 2009-03-03 17:31 10% ` Reece Dunn
2009-03-03 17:34 10% ` Jeff King
1 sibling, 0 replies; 45+ results
From: Reece Dunn @ 2009-03-03 17:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
2009/3/3 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Tue, 3 Mar 2009, Jeff King wrote:
>
>> On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
>>
>> > > Does using Git to track edits when proofreading a html/text document
>> > > (short story, novel, ...) count?
>> >
>> > I'll count it, but I want (read-only) access to the repository as a proof
>> > that you actually use Git that way ;-)
>>
>> Is it really that unusual? I've been keeping academic papers in git for
>> years (and CVS before that -- blech), and I'm sure I'm not alone.
>
> Count me in.
>
> I am interested in reading Reece's short stories, though.
I am not writing them (at the moment :)). I am just using git to
proofread stories by other people.
- Reece
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 16:04 10% ` Junio C Hamano
2009-03-03 16:26 10% ` Sverre Rabbelier
@ 2009-03-03 17:28 10% ` Johannes Schindelin
1 sibling, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Reece Dunn, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 872 bytes --]
Hi,
On Tue, 3 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 3 Mar 2009, Reece Dunn wrote:
> >
> >> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >> > Dear fans of Git,
> >> >
> >> > a while ago I announced the UGFWIINI contest, a glorious battle of
> >> > ideas how to
> >> >
> >> > Use Git For What It Is Not Indended
> >>
> >> Does using Git to track edits when proofreading a html/text document
> >> (short story, novel, ...) count?
> >
> > I'll count it, but I want (read-only) access to the repository as a
> > proof that you actually use Git that way ;-)
>
> Are you also in the contest, with your blog as one of the contenders?
As I am the jury, I decided to pretend that I have some decency left by
not putting my own Git crim^Wuses into the contest...
;-)
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 16:15 10% ` Jeff King
@ 2009-03-03 17:27 10% ` Johannes Schindelin
2009-03-03 17:31 10% ` Reece Dunn
2009-03-03 17:34 10% ` Jeff King
0 siblings, 2 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 17:27 UTC (permalink / raw)
To: Jeff King; +Cc: Reece Dunn, git
Hi,
On Tue, 3 Mar 2009, Jeff King wrote:
> On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
>
> > > Does using Git to track edits when proofreading a html/text document
> > > (short story, novel, ...) count?
> >
> > I'll count it, but I want (read-only) access to the repository as a proof
> > that you actually use Git that way ;-)
>
> Is it really that unusual? I've been keeping academic papers in git for
> years (and CVS before that -- blech), and I'm sure I'm not alone.
Count me in.
I am interested in reading Reece's short stories, though.
> Of course I'm writing in LaTeX, which is arguably a programming
> language. ;)
>
> BTW, --color-words is indispensable when dealing with things that aren't
> line-oriented.
Guess three times why I wrote --color-words...
You guessed it. Academic papers written in LaTeX.
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 16:04 10% ` Junio C Hamano
@ 2009-03-03 16:26 10% ` Sverre Rabbelier
2009-03-03 17:36 10% ` Johannes Schindelin
2009-03-03 17:28 10% ` Johannes Schindelin
1 sibling, 1 reply; 45+ results
From: Sverre Rabbelier @ 2009-03-03 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Reece Dunn, git
Heya,
On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:
> Are you also in the contest, with your blog as one of the contenders?
I remember Dscho saying anything mentioned in the announcement does
not count, but upon later inspection of the original post I cannot
find it...?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 15:59 10% ` Johannes Schindelin
2009-03-03 16:04 10% ` Junio C Hamano
@ 2009-03-03 16:15 10% ` Jeff King
2009-03-03 17:27 10% ` Johannes Schindelin
1 sibling, 1 reply; 45+ results
From: Jeff King @ 2009-03-03 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
> > Does using Git to track edits when proofreading a html/text document
> > (short story, novel, ...) count?
>
> I'll count it, but I want (read-only) access to the repository as a proof
> that you actually use Git that way ;-)
Is it really that unusual? I've been keeping academic papers in git for
years (and CVS before that -- blech), and I'm sure I'm not alone. Of
course I'm writing in LaTeX, which is arguably a programming language. ;)
BTW, --color-words is indispensable when dealing with things that aren't
line-oriented.
-Peff
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 15:59 10% ` Johannes Schindelin
@ 2009-03-03 16:04 10% ` Junio C Hamano
2009-03-03 16:26 10% ` Sverre Rabbelier
2009-03-03 17:28 10% ` Johannes Schindelin
2009-03-03 16:15 10% ` Jeff King
1 sibling, 2 replies; 45+ results
From: Junio C Hamano @ 2009-03-03 16:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 3 Mar 2009, Reece Dunn wrote:
>
>> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > Dear fans of Git,
>> >
>> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
>> > how to
>> >
>> > Use Git For What It Is Not Indended
>>
>> Does using Git to track edits when proofreading a html/text document
>> (short story, novel, ...) count?
>
> I'll count it, but I want (read-only) access to the repository as a proof
> that you actually use Git that way ;-)
Are you also in the contest, with your blog as one of the contenders?
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 15:09 10% ` Reece Dunn
@ 2009-03-03 15:59 10% ` Johannes Schindelin
2009-03-03 16:04 10% ` Junio C Hamano
2009-03-03 16:15 10% ` Jeff King
0 siblings, 2 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 15:59 UTC (permalink / raw)
To: Reece Dunn; +Cc: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 507 bytes --]
Hi,
On Tue, 3 Mar 2009, Reece Dunn wrote:
> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Dear fans of Git,
> >
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
>
> Does using Git to track edits when proofreading a html/text document
> (short story, novel, ...) count?
I'll count it, but I want (read-only) access to the repository as a proof
that you actually use Git that way ;-)
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (5 preceding siblings ...)
2009-03-03 10:30 20% ` Jakub Narebski
@ 2009-03-03 15:09 10% ` Reece Dunn
2009-03-03 15:59 10% ` Johannes Schindelin
2009-03-11 10:27 21% ` Jakub Narebski
` (2 subsequent siblings)
9 siblings, 1 reply; 45+ results
From: Reece Dunn @ 2009-03-03 15:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
Does using Git to track edits when proofreading a html/text document
(short story, novel, ...) count?
This is similar to the ODF <-> Git entry. Now all that needs to happen
is to replace the ZIP format with a git repository and create a plugin
for an ODF reader that makes git calls when doing the content tracking
checks.
- Reece
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-03-03 10:30 20% ` Jakub Narebski
@ 2009-03-03 11:20 10% ` Johannes Schindelin
2009-03-07 0:56 9% ` Jakub Narebski
1 sibling, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-03-03 11:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Hi,
On Tue, 3 Mar 2009, Jakub Narebski wrote:
> Another candidate for UGFWIINI contest: Gitorial. Here is explanation
>
> ...this presentation was captured in the Git revision control
> system. Every commit has a commit message that explains the 'next
> slide' of the presentation. People can then view diffs between
> commits to quickly see what changed.
>
> Well, it uses GitHub, not only Git, but...
>
> http://github.com/blog/367-clojure-gitorial
> http://larrytheliquid.com/2009/03/02/presenting-clojure-with-a-gitorial
>
> ........................................................................
>
> And similar thing: Homoiconic. Here is explanation
>
> Homoiconic is an experiment in publishing code and words about code
> on a small scale.
>
> When I write, I will add files to the homoiconic git repository,
> organized by date. Code will be included in the posts and also in
> the folder with the posts that discuss them, so it's easy to
> download what you like. You can even download the entire thing as an
> archive if you want.
>
> http://github.com/raganwald/homoiconic
Definitely. Both are registered for the next round.
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (4 preceding siblings ...)
2009-02-19 10:32 10% ` Peter Krefting
@ 2009-03-03 10:30 20% ` Jakub Narebski
2009-03-03 11:20 10% ` Johannes Schindelin
2009-03-07 0:56 9% ` Jakub Narebski
2009-03-03 15:09 10% ` Reece Dunn
` (3 subsequent siblings)
9 siblings, 2 replies; 45+ results
From: Jakub Narebski @ 2009-03-03 10:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
>
> As most of you probably did not find my blog yet, this may come as a
> surprise to you, but it will not be the only surprise in this email.
Errr... URL (of a blog), please?
Another candidate for UGFWIINI contest: Gitorial. Here is explanation
...this presentation was captured in the Git revision control
system. Every commit has a commit message that explains the 'next
slide' of the presentation. People can then view diffs between
commits to quickly see what changed.
Well, it uses GitHub, not only Git, but...
http://github.com/blog/367-clojure-gitorial
http://larrytheliquid.com/2009/03/02/presenting-clojure-with-a-gitorial
........................................................................
And similar thing: Homoiconic. Here is explanation
Homoiconic is an experiment in publishing code and words about code
on a small scale.
When I write, I will add files to the homoiconic git repository,
organized by date. Code will be included in the posts and also in
the folder with the posts that discuss them, so it's easy to
download what you like. You can even download the entire thing as an
archive if you want.
http://github.com/raganwald/homoiconic
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [relevance 20%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (3 preceding siblings ...)
2009-02-17 18:34 10% ` Sergio Callegari
@ 2009-02-19 10:32 10% ` Peter Krefting
2009-03-03 10:30 20% ` Jakub Narebski
` (4 subsequent siblings)
9 siblings, 0 replies; 45+ results
From: Peter Krefting @ 2009-02-19 10:32 UTC (permalink / raw)
To: Git Mailing List
Johannes Schindelin:
> Number 10:
> Sergio Callegari describes how to manage opendocument (openoffice.org) files
Which is very nice, it saved me several megabytes of disk space :-)
> Git was clearly intended to track source code stored as small ASCII
> files; otherwise, 'git diff' would not be such an integral part of
> Git.
Still, I have "git diff" working fine for OpenOffice Writer documents
here, using "oodiff" that I found somewhere I cannot remember...
Now, if only OpenOffice could be told not to store the documents as zip
files, but rather as a directory, I wouldn't have to fool Git using the
rezipper. Or perhaps one should implement support in Git to store zip
files expanded (and just create the .zip on checkout)?
Then one could even merge conflicts between concurrent edits.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 23:49 10% ` Johannes Schindelin
@ 2009-02-17 23:51 10% ` Sverre Rabbelier
0 siblings, 0 replies; 45+ results
From: Sverre Rabbelier @ 2009-02-17 23:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Wed, Feb 18, 2009 at 00:49, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Heh, do you actually use it?
Yup, at times when I need to work with an svn repository but cannot be
bothered to rev up git-svn for it :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 17:39 9% ` martin f krafft
2009-02-17 18:04 10% ` Mike Hommey
@ 2009-02-17 23:51 10% ` Johannes Schindelin
1 sibling, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-02-17 23:51 UTC (permalink / raw)
To: martin f krafft; +Cc: git
Hi,
On Tue, 17 Feb 2009, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2009.02.17.1747 +0100]:
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
> >
> > As most of you probably did not find my blog yet, this may come as a
> > surprise to you, but it will not be the only surprise in this email.
>
> A shame that I didn't see the contest start. I would have had
> a number of cases to add using Git
>
> - to track your ~ (cf. http://vcs-home.madduck.net)
> - to track /etc (cf. http://kitenet.net/~joey/code/etckeeper/)
> - as the backend for a service like snapshot.debian.net
> - as a mail store and complete replacement of IMAP
>
> anyway, enter me for round 2!!
Sure!
But I deem the first two being trumped by the large media...
If you could point me to the IMAP thing, I'd be interested personally, as
I use Git to track all my mails in maildir format.
Ciao,
Dscho
> > This is also related to Martin Krafft's idea to sort of replace the
> > Debian packaging management by using Git, but...
>
> I had this idea? Well, maybe something related: vcs-pkg.org, which
> is about using distributed VCS for distro package maintenance.
Yes, that's what I meant.
> Anyway, thanks Johannes for the fun! :)
You're very welcome!
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 17:29 10% ` Sverre Rabbelier
@ 2009-02-17 23:49 10% ` Johannes Schindelin
2009-02-17 23:51 10% ` Sverre Rabbelier
0 siblings, 1 reply; 45+ results
From: Johannes Schindelin @ 2009-02-17 23:49 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
Hi,
On Tue, 17 Feb 2009, Sverre Rabbelier wrote:
> On Tue, Feb 17, 2009 at 17:47, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > I managed to collect 10 candidates already, and since I did all the hard
> > work of collating them, I took the liberty of ordering them into a very
> > subjective order of ugfwiininess (pronounced "You-gah-wee-knee-ness").
>
> How about using git to do a temporary 'svn stash'?
> If you have changes in your svn working copy that you cannot commit
> just yet, but you want to check out an earlier revision for whatever
> reason, the current only solution in svn to that is to have a second
> working copy. But no longer!
> $ cd path/to/svn/repo
> $ git init && git add . && git commit -m "save svn state"
> $ svn revert -R *
> $ svn update -r 42
> $ # do whatever you need to do here
> $ git reset --hard && rm .git
>
> Does that qualify? ;)
Heh, do you actually use it?
Ciao,
Dscho
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
` (2 preceding siblings ...)
2009-02-17 18:00 10% ` Michael J Gruber
@ 2009-02-17 18:34 10% ` Sergio Callegari
2009-02-19 10:32 10% ` Peter Krefting
` (5 subsequent siblings)
9 siblings, 0 replies; 45+ results
From: Sergio Callegari @ 2009-02-17 18:34 UTC (permalink / raw)
To: git
I've been feeling a bit ugfwiinic all the afternoon and I couldn't realize why,
but then I finally saw your post and I understood!
But Dscho, now I am sure that you missed that "git diff -odf" at the very core
of git functionality that certainly Linus implemented on day one and that surely
got lost due to an unfortunate SHA clash!
Ciao
Sergio
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 17:39 9% ` martin f krafft
@ 2009-02-17 18:04 10% ` Mike Hommey
2009-02-17 23:51 10% ` Johannes Schindelin
1 sibling, 0 replies; 45+ results
From: Mike Hommey @ 2009-02-17 18:04 UTC (permalink / raw)
To: git
On Tue, Feb 17, 2009 at 06:39:57PM +0100, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2009.02.17.1747 +0100]:
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
> >
> > As most of you probably did not find my blog yet, this may come as a
> > surprise to you, but it will not be the only surprise in this email.
>
> A shame that I didn't see the contest start. I would have had
> a number of cases to add using Git
>
> - to track your ~ (cf. http://vcs-home.madduck.net)
> - to track /etc (cf. http://kitenet.net/~joey/code/etckeeper/)
> - as the backend for a service like snapshot.debian.net
Speaking of which I've done some initial testing a while ago
(http://glandium.org/blog/?p=182) and done some archive-wide testing
recently for which I still have to gather data and post about.
I also have some other use of git at work that I still have to post
about.
Cheers,
Mike
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
2009-02-17 17:29 10% ` Sverre Rabbelier
2009-02-17 17:39 9% ` martin f krafft
@ 2009-02-17 18:00 10% ` Michael J Gruber
2009-02-17 18:34 10% ` Sergio Callegari
` (6 subsequent siblings)
9 siblings, 0 replies; 45+ results
From: Michael J Gruber @ 2009-02-17 18:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
To those wondering what happened to Dscho lately:
In Germany, there is this special time of the year called
Fasching/Karneval/Fasenacht/... (carneval) where even the most serious
patch bashers may turn into funny pals ;)
To Dscho:
Great work, I hope you'll go on past Ash Wednesday!
I'll work on my entry for the next contest, but the Top Ten are hard to
beat...
Michael
^ permalink raw reply [relevance 10%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
2009-02-17 17:29 10% ` Sverre Rabbelier
@ 2009-02-17 17:39 9% ` martin f krafft
2009-02-17 18:04 10% ` Mike Hommey
2009-02-17 23:51 10% ` Johannes Schindelin
2009-02-17 18:00 10% ` Michael J Gruber
` (7 subsequent siblings)
9 siblings, 2 replies; 45+ results
From: martin f krafft @ 2009-02-17 17:39 UTC (permalink / raw)
To: Johannes Schindelin, git
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2009.02.17.1747 +0100]:
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
>
> As most of you probably did not find my blog yet, this may come as a
> surprise to you, but it will not be the only surprise in this email.
A shame that I didn't see the contest start. I would have had
a number of cases to add using Git
- to track your ~ (cf. http://vcs-home.madduck.net)
- to track /etc (cf. http://kitenet.net/~joey/code/etckeeper/)
- as the backend for a service like snapshot.debian.net
- as a mail store and complete replacement of IMAP
anyway, enter me for round 2!!
> Avery Pennarun explains his endeavor of tracking windows with
> git... "If I get a virus, I can 'git revert' it."
> http://alumnit.ca/~apenwarr/log/?m=200901#21
>
> Sverre remarks: "It even beats the way we use Git to track the
> MSys installation in msysgit.git..."
>
> This is also related to Martin Krafft's idea to sort of replace
> the Debian packaging management by using Git, but...
I had this idea? Well, maybe something related: vcs-pkg.org, which
is about using distributed VCS for distro package maintenance. More
Debian-specific is my goal to replace source packages with services
that build straight from trees identified by Git tags, which I've
written a bit about here:
http://madduck.net/blog/2005.08.11:rcs-uploads/
This is up high on my list of todos, so expect more on this topic
soon.
Anyway, thanks Johannes for the fun! :)
--
martin | http://madduck.net/ | http://two.sentenc.es/
"wenn elephanten tanzen leidet das gras."
-- die vogelpredigt
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 9%]
* Re: First round of UGFWIINI results
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
@ 2009-02-17 17:29 10% ` Sverre Rabbelier
2009-02-17 23:49 10% ` Johannes Schindelin
2009-02-17 17:39 9% ` martin f krafft
` (8 subsequent siblings)
9 siblings, 1 reply; 45+ results
From: Sverre Rabbelier @ 2009-02-17 17:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Heya,
On Tue, Feb 17, 2009 at 17:47, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I managed to collect 10 candidates already, and since I did all the hard
> work of collating them, I took the liberty of ordering them into a very
> subjective order of ugfwiininess (pronounced "You-gah-wee-knee-ness").
How about using git to do a temporary 'svn stash'?
If you have changes in your svn working copy that you cannot commit
just yet, but you want to check out an earlier revision for whatever
reason, the current only solution in svn to that is to have a second
working copy. But no longer!
$ cd path/to/svn/repo
$ git init && git add . && git commit -m "save svn state"
$ svn revert -R *
$ svn update -r 42
$ # do whatever you need to do here
$ git reset --hard && rm .git
Does that qualify? ;)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 10%]
* First round of UGFWIINI results
@ 2009-02-17 16:47 19% Johannes Schindelin
2009-02-17 17:29 10% ` Sverre Rabbelier
` (9 more replies)
0 siblings, 10 replies; 45+ results
From: Johannes Schindelin @ 2009-02-17 16:47 UTC (permalink / raw)
To: git
Dear fans of Git,
a while ago I announced the UGFWIINI contest, a glorious battle of ideas
how to
Use Git For What It Is Not Indended
As most of you probably did not find my blog yet, this may come as a
surprise to you, but it will not be the only surprise in this email.
I managed to collect 10 candidates already, and since I did all the hard
work of collating them, I took the liberty of ordering them into a very
subjective order of ugfwiininess (pronounced "You-gah-wee-knee-ness").
Please assist me while reading this mail by hitting your desk alternating
between your two index fingers, increasing the frequency from 2 to 4 hertz
throughout the mail.
Ready? Okay.
Number 10:
Sergio Callegari describes how to manage opendocument (openoffice.org) files
in git in
http://kerneltrap.org/mailarchive/git/2008/9/15/3305014
While this might strike some of you as pretty lame, in my opinion it is still
something Git was not intended for: Never mind the title "stupid content
tracker", Git was clearly intended to track source code stored as small ASCII
files; otherwise, 'git diff' would not be such an integral part of Git.
Number 9:
Tim Ansell talked about managing large media with Git at the GitTogether:
http://www.thousandparsec.net/~tim/media+git.pdf
This falls into the same category as number 10, but in addition it strains
the assumption of Git that you can easily fit the contents of a file into
memory, as well as the assumption that it is pretty easy (and meaningful)
to make a diff from two versions of a file.
Number 8:
Avery Pennarun explains his endeavor of tracking windows with git...
"If I get a virus, I can 'git revert' it."
http://alumnit.ca/~apenwarr/log/?m=200901#21
Sverre remarks: "It even beats the way we use Git to track the MSys
installation in msysgit.git..."
This is also related to Martin Krafft's idea to sort of replace the Debian
packaging management by using Git, but...
Number 7:
... actually does something like that: James Tucker implemented a port manager
based on Git:
http://github.com/raggi/source_ports
Number 6:
Dieter Plaetinck synchronizes Firefox profiles using Git:
http://dieter.plaetinck.be/rethinking_the_backup_paradigm_a_higher-level_approach
Now, this even strains the definition of "content"...
Number 5:
David Abrahams archiving a large number of files (and detecting duplicates)
uses Git partly for something it _can_ do, but certainly was not intended to
do: identify duplicates.
http://kerneltrap.org/mailarchive/git/2009/1/27/4827304
While the content-addressable filesystem has to deal with duplicates in the
_time_ dimension very well (not many files are supposed to change from one
revision to the next one, so most of the files _are_ duplicated), dealing
with it in the _space_ dimension is not the purpose of Git, as can be seen
by the lack of tool support for it (also keep in mind the absence of git-cp).
Number 4:
Josef Wolf asks in <20090131123336.GA1702@raven.wolf.lan> (with a fully
valid Mail-Followup-To header) "How to move subdirectories from one svn
repos to another."
"I would like to move a complete subdirectory with all its history from
one svn repository to another."
Now, the ugfwiininess of this entry is definitely increased dramatically
by Josef being inclined to go to Git _and back to Subversion_ again :-)
(Imagine a cheeky smirk on the face of your host.)
Number 3:
Jan Krueger's Git cookbook uses a Git repository as a backend of a content
management system:
http://repo.zoidberg.org/w/git-articledb.git
http://gitrecipes.de/
This is related to the way my own blog works, but he was first. Credit
where credit is due.
Number 2:
At the GitTogether, Sam Vilain presented his idea to use Git as a DB backend:
http://utsl.gen.nz/talks/git-db
Just think about it: committing by "INSERT INTO"!
And now, ladies and gentlemen, please brace yourself for...
Number 1:
Scott Chacon's iGitHub: Running a git-daemon on an iPhone
http://github.com/schacon/igithub/
This is so awesome as to defeat any attempt to describe it.
I hope you enjoyed the show, and see you again next time, on
Using Git For What It Is Not Intended
(Now play your favorite jingle.)
^ permalink raw reply [relevance 19%]
* Re: [PATCH] rev-list: estimate number of bisection step left
@ 2009-02-17 15:39 11% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-02-17 15:39 UTC (permalink / raw)
To: John Tapsell; +Cc: Christian Couder, Junio C Hamano, git, Ingo Molnar
Hi,
On Tue, 17 Feb 2009, John Tapsell wrote:
> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Tue, 17 Feb 2009, John Tapsell wrote:
> >
> >> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Tue, 17 Feb 2009, Christian Couder wrote:
> >> >
> >> >> +static int estimate_bisect_steps(int all)
> >> >> +{
> >> >> + int log2 = 0;
> >> >> + int left = (all >> 1) - 1;
> >> >> +
> >> >> + if (left <= 0)
> >> >> + return 0;
> >> >> +
> >> >> + do {
> >> >> + left = left >> 1;
> >> >> + log2++;
> >> >> + } while (left);
> >> >> +
> >> >> + return log2;
> >> >> +}
> >> >
> >> > How about this instead, calling it from cmd_rev_list directly?
> >> >
> >> > static int log2(int n)
> >> > {
> >> > int log2;
> >> >
> >> > for (log2 = 0; n > 1; log2++)
> >> > n >>= 1;
> >> >
> >> > return log2;
> >> > }
> >>
> >> This would work, if you want a non-iterative solution
> >>
> >> unsigned int log2_integer_approximate(unsigned int n){
> >> *((float*)&n) = (float)n;
> >> return ((n & (~((1<<23) - 1))) >> 23) - 127;
> >> }
> >
> > That assumes that your floats are IEEE floats, right?
>
> Yeah. Is it a bad assumption? Does git run on any system in which they
> aren't?
Only when you are porting Git to embedded devices.
Don't moan: there exists a git-daemon for iPhone. Oh, wait! /me
scribbles that down for the UGFWIINI contest.
Ciao,
Dscho
^ permalink raw reply [relevance 11%]
* Re: UGFWIINI
2009-02-03 5:57 10% UGFWIINI Kris Shannon
@ 2009-02-03 6:26 10% ` Boyd Stephen Smith Jr.
0 siblings, 0 replies; 45+ results
From: Boyd Stephen Smith Jr. @ 2009-02-03 6:26 UTC (permalink / raw)
To: Kris Shannon; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Monday 02 February 2009 23:57:15 Kris Shannon wrote:
> 2009/2/2 Sverre Rabbelier <srabbelier@gmail.com>:
> > UGFWIINI.
>
> Second time I've seen this acronym recently, and
> I can't seem to work out the proper expansion.
I got: Using Git For What It Is Not Intended (to do); I've never seen it
spelled out.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 10%]
* Re: UGFWIINI
@ 2009-02-03 5:57 10% Kris Shannon
2009-02-03 6:26 10% ` UGFWIINI Boyd Stephen Smith Jr.
0 siblings, 1 reply; 45+ results
From: Kris Shannon @ 2009-02-03 5:57 UTC (permalink / raw)
To: Git Mailing List
2009/2/2 Sverre Rabbelier <srabbelier@gmail.com>:
> Omg, this is so totally insane that I've been laughing the entire time
> while reading the post, and then for a minute after that :P. Johannes,
> I think we have a new contender for the UGFWIINI contest.
Second time I've seen this acronym recently, and while I can work out the
meaning from the context I can't seem to work out the proper expansion.
* GMail search of the mailing list didn't work :( *
^ permalink raw reply [relevance 10%]
* Re: git monthly links: 2009-01
2009-02-01 18:50 11% ` Sverre Rabbelier
@ 2009-02-01 23:26 0% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-02-01 23:26 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Felipe Contreras, git list
Hi,
On Sun, 1 Feb 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Feb 1, 2009 at 18:01, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Tracking an entire Windows system inside Git
> > Avery Pennarun explains his endeavor of tracking windows with git...
> > "If I get a virus, I can 'git revert' it."
> > http://alumnit.ca/~apenwarr/log/?m=200901#21
>
> Omg, this is so totally insane that I've been laughing the entire time
> while reading the post, and then for a minute after that :P. Johannes,
> I think we have a new contender for the UGFWIINI contest.
Indeed. It even beats the way we use Git to track the MSys installation
in msysgit.git...
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* Re: git monthly links: 2009-01
@ 2009-02-01 18:50 11% ` Sverre Rabbelier
2009-02-01 23:26 0% ` Johannes Schindelin
0 siblings, 1 reply; 45+ results
From: Sverre Rabbelier @ 2009-02-01 18:50 UTC (permalink / raw)
To: Felipe Contreras, Johannes Schindelin; +Cc: git list
Heya,
On Sun, Feb 1, 2009 at 18:01, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Tracking an entire Windows system inside Git
> Avery Pennarun explains his endeavor of tracking windows with git...
> "If I get a virus, I can 'git revert' it."
> http://alumnit.ca/~apenwarr/log/?m=200901#21
Omg, this is so totally insane that I've been laughing the entire time
while reading the post, and then for a minute after that :P. Johannes,
I think we have a new contender for the UGFWIINI contest.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 11%]
* Re: "malloc failed"
@ 2009-01-27 18:02 11% ` Johannes Schindelin
0 siblings, 0 replies; 45+ results
From: Johannes Schindelin @ 2009-01-27 18:02 UTC (permalink / raw)
To: David Abrahams; +Cc: git
Hi,
On Tue, 27 Jan 2009, David Abrahams wrote:
> I've been abusing Git for a purpose it wasn't intended to serve:
> archiving a large number of files with many duplicates and
> near-duplicates.
Hah! My first UGFWIINI contender! Unfortunately, I listed that purpose
explicitely already...
> Every once in a while, when trying to do something really big, it tells
> me "malloc failed" and bails out (I think it's during "git add" but
> because of the way I issued the commands I can't tell: it could have
> been a commit or a gc). This is on a 64-bit linux machine with 8G of
> ram and plenty of swap space, so I'm surprised.
Yes, I am surprised, too. I would expect that some kind of arbitrary
user-specifiable limit hit you. Haven't had time to look at the code,
though.
Ciao,
Dscho
^ permalink raw reply [relevance 11%]
Results 1-45 of 45 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-01-27 15:04 "malloc failed" David Abrahams
2009-01-27 18:02 11% ` Johannes Schindelin
2009-02-01 17:01 git monthly links: 2009-01 Felipe Contreras
2009-02-01 18:50 11% ` Sverre Rabbelier
2009-02-01 23:26 0% ` Johannes Schindelin
2009-02-03 5:57 10% UGFWIINI Kris Shannon
2009-02-03 6:26 10% ` UGFWIINI Boyd Stephen Smith Jr.
2009-02-17 5:09 [PATCH] rev-list: estimate number of bisection step left Christian Couder
2009-02-17 14:44 ` Johannes Schindelin
2009-02-17 15:11 ` John Tapsell
2009-02-17 15:31 ` Johannes Schindelin
2009-02-17 15:36 ` John Tapsell
2009-02-17 15:39 11% ` Johannes Schindelin
2009-02-17 16:47 19% First round of UGFWIINI results Johannes Schindelin
2009-02-17 17:29 10% ` Sverre Rabbelier
2009-02-17 23:49 10% ` Johannes Schindelin
2009-02-17 23:51 10% ` Sverre Rabbelier
2009-02-17 17:39 9% ` martin f krafft
2009-02-17 18:04 10% ` Mike Hommey
2009-02-17 23:51 10% ` Johannes Schindelin
2009-02-17 18:00 10% ` Michael J Gruber
2009-02-17 18:34 10% ` Sergio Callegari
2009-02-19 10:32 10% ` Peter Krefting
2009-03-03 10:30 20% ` Jakub Narebski
2009-03-03 11:20 10% ` Johannes Schindelin
2009-03-07 0:56 9% ` Jakub Narebski
2009-03-07 2:40 10% ` Johannes Schindelin
2009-03-03 15:09 10% ` Reece Dunn
2009-03-03 15:59 10% ` Johannes Schindelin
2009-03-03 16:04 10% ` Junio C Hamano
2009-03-03 16:26 10% ` Sverre Rabbelier
2009-03-03 17:36 10% ` Johannes Schindelin
2009-03-03 17:28 10% ` Johannes Schindelin
2009-03-03 16:15 10% ` Jeff King
2009-03-03 17:27 10% ` Johannes Schindelin
2009-03-03 17:31 10% ` Reece Dunn
2009-03-03 17:34 10% ` Jeff King
2009-03-03 17:49 10% ` Johannes Schindelin
2009-03-11 10:27 21% ` Jakub Narebski
2009-03-11 12:09 10% ` Johannes Schindelin
2009-03-27 15:08 21% ` Jakub Narebski
2009-03-28 7:42 20% ` Jeff King
2009-04-22 10:52 10% ` Pieter de Bie
2009-04-27 22:55 How is git used as other than the project's version control? John Dlugosz
2009-04-28 1:44 10% ` Jeff King
2009-08-17 10:24 4% Git User's Survey 2009 partial summary, part 2 - from first 10 Jakub Narebski
2009-08-17 11:42 Continue git clone after interruption Tomasz Kontusz
2009-08-18 18:45 ` Jakub Narebski
2009-08-18 20:01 ` Nicolas Pitre
2009-08-18 21:02 9% ` Jakub Narebski
2009-08-18 21:32 0% ` Nicolas Pitre
2009-08-19 15:19 0% ` Jakub Narebski
2009-08-19 19:04 0% ` Nicolas Pitre
2009-12-02 21:08 How do you best store structured data in git repositories? Sebastian Setzer
2009-12-02 21:17 ` Avery Pennarun
2009-12-04 0:14 10% ` David Aguilar
2010-11-13 15:29 Using a different index and HEAD Enrico Weigelt
2010-11-13 17:25 ` Jakub Narebski
2010-11-21 15:16 14% ` Tomas Carnecky
2019-10-29 12:26 Question - .git subdirectories Arkadij Chistyj
2019-10-31 23:01 10% ` Jonathan Nieder
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).