* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Petr Baudis @ 2006-10-18 1:57 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660610171448h53de5e40wf55f19d6458127ef@mail.gmail.com>
Dear diary, on Tue, Oct 17, 2006 at 11:48:51PM CEST, I got a letter
where Christian MICHON <christian.michon@gmail.com> said that...
> I'd like particularly to know if a git-explorer type of plugin makes
> sense for (g)vim and would like in this case be part of the team
> developping it... using git of course :)
See also
http://news.gmane.org/find-root.php?message_id=<20051124093322.GA3899@mail.yhbt.net>
Personally, I'd say "just use tig". :-)
If you insist on living instide vim, that particular script comes from
the age before git-show and git-cat-file -p so it would probably make
sense to move the bulk of the functionality there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)
From: Petr Baudis @ 2006-10-18 1:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eh40e1$9g1$1@sea.gmane.org>
Dear diary, on Wed, Oct 18, 2006 at 03:36:36AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > BTW, I'm thinking about implementing some plugin functionality for
> > gitweb
>
> Features support is kind of plugin system for gitweb. But certainly we could
> split gitweb into modules.
>
> > so that you can add your own views, so that git-browser can
> > integrate to it more reasonably. (Currently it has completely different
> > UI and you have to patch gitweb in order to get the proper links at
> > proper places.) Sure, git-browser might get fully integrated to gitweb
> > later but that needs to be done sensitively so that people are not
> > scared by the horrible javascript blobs, etc.; currently git-browser is
> > very experimental, and adding it would be quite intrusive.
>
> I was thinking about adding using JavaScript, in shortlog (and perhaps
> shortlog-extended, i.e. with date and author) views one extra "diagram"
> column, with width set using JavaScript generated embedded style, and use
> only part of git-browser that generates diagram to draw it there.
Shortlog is paginated and that's not very practical for diagrams, I
think - you need to gradually extend it instead in that case. But yes,
keeping the _visual_ difference of git-browser and gitweb as small as
possible has been the main reason for me to think about integrating it
more tightly.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 1:46 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng, git
In-Reply-To: <vpqejt76vgz.fsf@ecrins.imag.fr>
Dear diary, on Tue, Oct 17, 2006 at 01:19:08PM CEST, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> 2) a bound branch. It's not _very_ different from a normal branch, but
> mostly "commit" behaves differently:
> - it commits both on the local and the remote branch (equivalent to
> "commit" + "push", but in a transactional way).
> - it refuses to commit if you're out of date with the branch you're
> bound to.
> (this is "heavy checkout")
It isn't very nice because it enforces the update-before-commit
workflow, which was complaint of many CVS users and I can remember it
being one of the selling points of the distributed VCSes in 2001 or so,
although it is not so emphasized lately. (I understand that this is
something optional in Bazaar.)
BTW, merge commits aren't bad. They reflect what really happenned,
explicitly record the merge resolution taken, if there was any, and
protect you from accidentally losing or damaging [any portion of] your
changes. And they aren't cluttery either since we hide them from
non-graphical history listings by default.
Still, I can recognize that in some scenarios, people might find it
useful, and I can remember some people asking for it in the past. So I
couldn't resist and implemented it in Cogito as cg-commit --push. Pushed
out now. Took me about 5 minutes implementing it and 10 minutes documenting
it. ;-)
P.S.: A general note for bleeding-edge Cogito users, I've rewritten the
local changes handling so that we always do three-way merge now instead
of that braindead patches diffing/applying, but it's not completely
stable yet, some testcases still fail. So be a bit careful when
updating/uncommitting/switching/... with uncommitted changes in the
working tree.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-18 1:44 UTC (permalink / raw)
To: Jakub Narebski
Cc: Aaron Bentley, Petr Baudis, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git, Matthieu Moy
In-Reply-To: <200610180328.31234.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:
>
> Isn't it easier to review than "bundle", aka. mega-patch?
There are even more important reasons to prefer a series of
micro-commits over a mega-patch than just ease of merging.
In the cairo project, I've often reviewed a single patch and said:
"This all looks like perfectly good code and I'd be happy to
have it all in the tree. But please rebuild this as a series
of independent patches (perhaps along the lines of a, b, c,
...)"
I do that not just to make the history "look nice" but because code
history is something we _use_ a lot and separate commits for separate
actions just make the history so much more usable.
We have great tools like bisect to identify commits that introduce
bugs. I know that I'd be delighted to see bisect comes back pointing
at some minimal commit as causing a bug, (which would make finding the
bug so much easier).
But it's also been my experience that the largest commits are also the
most likely to be the things returned by bisect. Big commits really do
introduce bugs more frequently than small commits.
Finally, if someone had gone through the useful work to create small,
independent changes, (and likely finding and fixing bugs in the
process), what a horrible shame it would be to throw away that work
and merge it as a single patch, (welcome to the pain of CVS branch
merging).
Now, I do admit that it is often useful to take the overall view of a
patch series being submitted. This is often the case when a patch
series is in some sub-module of the code for which I don't have as
much direct involvement. In cases like that I will often do review
only of the diff between the tips of the mainline and the branch of
interest, (or if I trust the maintainer enough, perhaps just the
diffstat between the two). But I'm still very glad that what lands in
the history is the series of independent changes, and not one mega
commit.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Sergey Vlasov, git
In-Reply-To: <7vr6x6ip5d.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> >> On Tue, 17 Oct 2006, Sergey Vlasov wrote:
> >> >
> >> > Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
> >>
> >> Ah bummer. Then this is most likely the cause. And here's a simple
> >> fix (Junio please confirm):
> >
> > Why do you use "unsigned long" in the first place?
> >
> > For some structure like this, it sounds positively wrong. Pack-files
> > should be architecture-neutral, which means that they shouldn't depend on
> > word-size, and they should be in some neutral byte-order.
>
> This is an in-core structure if I am not mistaken, and is never
> written out in the resulting pack file. The program is reading
> from .pack and building .idx that corresponds to it. I agree
> that it is ugly, but I do not hink using neutral byte-order in
> this part of the processing buys us anything in this particular
> case.
Exact.
> > In contrast, the new union introduced in "next" is just horrid. There's
> > not even any way to know which member to use, except apparently that it
> > expects that a SHA1 is never zero in the last 12 bytes. Which is probably
> > true, but still - that's some ugly stuff.
>
> Again I agree with the ugliness objection, and I raised the
> "expecting no collision" issue which Nico refuted later. The
> code is probably safe (not just safe in practice but safe in
> theory as well), although that would not change the fact that it
> is ugly X-<.
The problem is that I just don't see what you find "ugly" in the thing.
Maybe it is just a matter of few missing comments?
Please let me walk you through bits of the code. I hope you'll
understand better why it is like it is after that.
In parse_pack_objects() you can read this:
/*
* First pass:
* - find locations of all objects;
* - calculate SHA1 of all non-delta objects;
* - remember base SHA1 for all deltas.
*/
So we reads through the whole pack to find where objects are located.
This information is stored in the objects[] array for all objects.
Entries for that array are:
struct object_entry
{
unsigned long offset;
enum object_type type;
enum object_type real_type;
unsigned char sha1[20];
};
ON that first pass only the offset and type can be determined for all
objects. The sha1 can be determined for non delta objects only.
There is a second array, deltas[], to record information about deltas as
they are found:
struct delta_entry
{
struct object_entry *obj;
union delta_base base;
};
The "obj" member points to the entry in the objects[] array for given
delta entry. And the "base" member, as you may guess, is a reference to
the base object for that delta.
So here we are with that dreaded union.
Now why isn't it a second struct object_entry pointer instead? Because
one kind of delta allows for its base object to appear later in the pack
and all we've got for identifying that base object is a sha1 reference
since we cannot predict where the base object will be. With the other
object type we _could_ find out about the location of the base object
right away. But that would mean adding a special case for those objects
through a different code path unnecessarily. Instead, the base offset
is treated just like a very special sha1 value and the same array is
used. So maybe the comment that says "remember base SHA1 for all
deltas" could be adjusted to mention "base sha1 or offset" to be exact.
Now what next:
/* Sort deltas by base SHA1/offset for fast searching */
qsort(deltas, nr_deltas, sizeof(struct delta_entry),
compare_delta_entry);
This comment, though, is extremely accurate. We sort delta entries "for
fast searching". There is no other use for the union blob. To avoid
the union there could have been two separate delta arrays: one for
OBJ_REF_DELTA and another for OBJ_OFS_DELTA. Then two
compare_delta_entry functions whould have been needed instead of only
one. But because we only use the union blob for searching given another
such union blob for target, we actually don't care if the union content
is a sha1 or an offset, and we don't care if that offset is 32-bit,
64-bit, little endian or big endian. All that we care about is that the
delta entries are sorted according to that union blob for fast binary
search. That is really all there is about it and therefore a single
qsort() does the trick.
Next:
/*
* Second pass:
* - for all non-delta objects, look if it is used as a base for
* deltas;
* - if used as a base, uncompress the object and apply all deltas,
* recursively checking if the resulting object is used as a base
* for some more deltas.
*/
Here we want to fill out the blanks in the objects[] array for delta
objects. It is of course much more efficient to start from a given base
object, inflate it, and use it successively on all delta objects that
depend on it. And let's do it recursively if the delta is also a
base object itself while at it.
So how does the dreaded union comes into play? It is simple. For each
non-delta objects, we create two union blobs. One with the sha1 member,
the other with the offset member. Those blobs are used as the key to
search for a range of deltas that have that non-delta object for base.
This has the possibility to find two ranges: one for deltas with base as
sha1, and the other range for deltas with offsets as sha1. Once the
delta ranges are known, the deltas are applied on that base object, the
resulting object's sha1 is computed and
the whole thing is repeated for those resulting objects as potential
base objects for more deltas.
Junio mentioned the possibility for collision between a union value that
should be treated as a sha1 and a union value that should be treated as
a delta base offset. Although such a collision is extremely improbable,
it is still possible and if so the wrong delta type could be applied on
top of the wrong base object. To avoid this issue, a test is made on
the delta type before it is replayed. So if the search key
was created using the sha1 union member, we make sure that it is used
with OBJ_REF_DELTA objects only. And ditto for the search key created
with the offset union member. This way there just can not be any
mistake even if there happens to be a collision in the base object
reference namespace.
Finally, the objects[] array is completely populated with objects sha1
and offsets. The dreaded union is completely forgotten (the deltas array
is actually freed). And only then the pack index is written out to
disk.
> Nico, could we have an un-uglied version please?
I'm really sorry to say that I don't know how I could make it less
"ugly". To me it is beautiful and efficient as is and I don't see why
it needs to be done another way. If you still think otherwise then your
guidance would be highly appreciated.
Nicolas
^ permalink raw reply
* Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)
From: Jakub Narebski @ 2006-10-18 1:36 UTC (permalink / raw)
To: git
In-Reply-To: <20061018001455.GI20017@pasky.or.cz>
Petr Baudis wrote:
> BTW, I'm thinking about implementing some plugin functionality for
> gitweb
Features support is kind of plugin system for gitweb. But certainly we could
split gitweb into modules.
> so that you can add your own views, so that git-browser can
> integrate to it more reasonably. (Currently it has completely different
> UI and you have to patch gitweb in order to get the proper links at
> proper places.) Sure, git-browser might get fully integrated to gitweb
> later but that needs to be done sensitively so that people are not
> scared by the horrible javascript blobs, etc.; currently git-browser is
> very experimental, and adding it would be quite intrusive.
I was thinking about adding using JavaScript, in shortlog (and perhaps
shortlog-extended, i.e. with date and author) views one extra "diagram"
column, with width set using JavaScript generated embedded style, and use
only part of git-browser that generates diagram to draw it there.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-18 1:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610171959070.1971@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> So let me summarize:
>
> - the union is a hash.
>
> - the hash is either an offset value or a sha1 digest.
>
> - this hash is used for fast object lookup _only_.
>
> - it does sort differently on big vs little endian machines.
>
> - but we don't care at all because
>
> - it is a private algorithmic thing that doesn't "bleed" into any
> _real_ data structure, and
>
> - it doesn't have any influence on the format of the end result.
>
> - it is only a runtime abstraction and nothing else.
>
> - It never gets into the pack nor the pack index themselves.
>
> Do you still have issues with that?
The part you pointed out to me about "accidental collision"
still bothers me somewhat.
Right now we do not produce ref-delta and ofs-delta in the same
stream, but if somebody did so then it would mean a disaster to
have an accidental collision of an 8-byte offset value plus
12-byte traiing NUL and another base object whose object name
happens to match that pattern.
I am actually Ok if we say the code assumes one stream has only
ref-delta or ofs-delta and never both.
But then I suspect the first pass of parse_pack_objects() should
make sure that assumption holds true for the pack being
inspected and barf if it is not. Also the second pass do not
have to run two find_delta_childs() calls per delta object
because by that time we know which kind would never appear in
the packfile.
By the way can we call that find_delta_children() pretty please?
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 1:28 UTC (permalink / raw)
To: Aaron Bentley
Cc: Matthieu Moy, bazaar-ng, Linus Torvalds, Andreas Ericsson,
Petr Baudis, git
In-Reply-To: <45357596.8050702@utoronto.ca>
Aaron Bentley wrote:
> Petr Baudis wrote:
>>
>> Another aspect of this is that Git (Linus ;) is very focused on getting
>> the history right, nice and clean (though it does not _mandate_ it and
>> you can just wildly do one commit after another; it just provides tools
>> to easily do it).
>
> Yes, rebasing is very uncommon in the bzr community. We would rather
> evaluate the complete change than walk through its history. (Bundles
> only show the changes you made, not the changes you merged from the
> mainline.)
>
> In an earlier form, bundles contained a patch for every revision, and
> people *hated* reading them. So there's definitely a cultural
> difference there.
Take for example
"[PATCH 0/6] ref deletion and D/F conflict avoidance with packed-refs."
http://thread.gmane.org/gmane.comp.version-control.git/28150/focus=28154
> This series cleans up the area that was affected by the recent
> addition of "packed-refs". Christian Couder and Jeff King CC'ed
> since they seem to be touching in the general vicinity of the
> code these patches touch.
>
> [1/6] ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
> [2/6] refs: minor restructuring of cached refs data.
> [3/6] lock_ref_sha1(): do not sometimes error() and sometimes die().
> [4/6] lock_ref_sha1(): check D/F conflict with packed ref when creating.
> [5/6] delete_ref(): delete packed ref
> [6/6] git-branch: remove D/F check done by hand.
>
> I opted for removing from the packed-ref file when a ref that is
> packed is deleted.
Isn't it easier to review than "bundle", aka. mega-patch?
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-18 1:25 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45357CC3.4040507@utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]
On Tue, 17 Oct 2006 21:00:51 -0400, Aaron Bentley wrote:
> Jakub Narebski wrote:
> > Well, that is another example while generation number is/can be global,
> > any numbering of branches must be local-only.
>
> No. The numbering always follows the leftmost parent. So each revision
> has a permanent (but non-unique) number.
Aaron, thanks for carrying this thread along and helping to bridge
some communication gaps. For example, when I saw your original two two
diagrams I was totally mystified how you were claiming that appending
a couple of nodes and edges to a DAG could change the "order" of the
DAG.
I think I understand what you're describing with the leftmost-parent
ordering now. But it's definitely an ordering that I would describe as
local-only. That is, the ordering has meaning only with respect to a
particular linearization of the DAG and that linearization is
different from one repository to the next.
> > ...but that means that revision numers are totally, absolutely useless.
> > Unless by some miracle of engineering, or adding namespace, they can be
> > made unchangeable.
>
> No, because no one pulls unless they're trying to maintain a mirror of
> the other branch, or else they decide to throw their local history away.
If in practice, nobody does the mirroring "pull" operation then how
are the numbers useful? For example, given your examples above, if
I'm understanding the concepts and terminology correctly, then if A
and B both "merge" from each other (and don't "pull") then they will
each end up with identical DAGs for the revision history but totally
distinct numbers. Correct?
So in that situation the numbers will not help A and B determine that
they have identical history or even identical working trees. So what
good are the numbers?
I can see that the numbers would have applicability with reference to
a single repository, (or equivalently a mirror of that repository),
but no utility as soon as there is any distributed development
happening.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 1:11 UTC (permalink / raw)
To: Matthieu Moy
Cc: Sean, Jakub Narebski, Aaron Bentley, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <vpqbqob5euu.fsf@ecrins.imag.fr>
Dear diary, on Tue, Oct 17, 2006 at 02:03:21PM CEST, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> I have one repository, say, $repo.
>
> In it, I have one branch "$repo/bzr.dev" which is an exact mirror of
> http://bazaar-vcs.org's branch.
>
> I also have branches for patches (occasional in my case) that I'll
> send to upstream. Say $repo/feature1, $repo/feature2, ...
>
> If, by mistake, I start hacking on bzr.dev itself, I'll be warned at
> commit time, create a branch, and commit in this new branch. I believe
> git manages this in a different way, allowing you to commit in this
> branch, and creating the branch next time you pull. But you know this
> better than I ;-), I never got time to give a real try to git.
In fact, in Git the branch is actually created at the moment you clone.
For simplicity sake, let's say you cloned just a single branch, not the
whole repository (or imagine a repository with a single branch). Then,
in your local repository, two branches will be created: 'origin' and
'master'. The origin branch is considered readonly (though Git does
not enforce it) and only mirrors the branch in the remote repository.
The master branch is the branch you do your work on, and it corresponds
to the contents of your working tree.
Thus, when you are "updating" your repository (we also call that
"pull"), what happens is that new commits are _fetched_ from the remote
repository to your 'origin' branch and then the 'origin' branch is
_merged_ to the 'master' branch. (You can even separate those two steps
and do them manually. So you can e.g. periodically fetch but just check
diffs with your master branch and never actually merge, or whatever.)
If you never do any local commits on the repository, every time you
merge the 'master' branch is ancestor of the 'origin' branch and only
so-called fast-forward merge happens - the 'master' branch is updated to
point at the same commit as the 'origin' branch.
If you _did_ do some local commits, a real merge of the two branches
happens and a new merge commit tying the current master and origin
history together is recorded on the merge branch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 1:05 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Sean, Jakub Narebski, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <20061018005700.GM20017@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petr Baudis wrote:
> Dear diary, on Wed, Oct 18, 2006 at 02:50:54AM CEST, I got a letter
> where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
>> Petr Baudis wrote:
>>
>>> Ok, one last question - do you do most of the work locally, fetching
>>> bits of data as you need, or remotely, only taking input/producing
>>> output over the network (the pserver model)?
>> Personally, I do not do remote commits over slow links. At home, I use
>> a single machine, and mirror my repository to a public machine using
>> rsync. At work, I store my repository on an NFS server, and push my
>> repository to a public machine using rsync.
>
> I meant the work of the commands (bzr log and such), not your personal
> workflow. :-) Sorry for being unclear.
When using the native network protocol, work can happen remotely. (But
the native protocol is quite new, and support for "smart" operations is
currently limited.) When using the dumb protocols, data is fetched from
the remote system and processed locally. Light checkouts are not
recommended when the server is on a slow link, but heavyweight checkouts
are quite suitable in that situation.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNX3j0F+nu1YWqI0RAtRcAJ0fEZam6H3hs3YHY/dEYEhk3A73BQCdENHY
s9+KZTfqnDJg8mHNmC2C/Ok=
=Nqcn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 1:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610180246.18758.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>> Linus Torvalds wrote:
>>> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>>>> Excuse me? What does that "throws away your local commit ordering" mean?
>>>> Say this is the ordering in branch A:
>>>>
>>>> a
>>>> |
>>>> b
>>>> |
>>>> c
>>>>
>>>> Say this is the ordering in branch B:
>>>>
>>>> a
>>>> |
>>>> b
>>>> |\
>>>> d c
>>>> |/
>>>> e
>>>>
>>>> When A pulls B, it gets the same ordering as B has. If B did not have e
>>>> and c, the pull would fail.
>>> Sure. But that doesn't throw away any local commit ordering. The original
>>> order (a->b->c) is still very much there.
>> After the pull, it's no longer the mainline ordering for the branch. c
>> is represented a revision that was merged into the branch, while d is
>> represented as a commit on the mainline of the branch.
>
> Well, that is another example while generation number is/can be global,
> any numbering of branches must be local-only.
No. The numbering always follows the leftmost parent. So each revision
has a permanent (but non-unique) number.
> That doesn't matter...
It has significant UI impact.
>> and the revision numbers can change.
>
> ...but that means that revision numers are totally, absolutely useless.
> Unless by some miracle of engineering, or adding namespace, they can be
> made unchangeable.
No, because no one pulls unless they're trying to maintain a mirror of
the other branch, or else they decide to throw their local history away.
>> Nobody is forced to use your local view.
>
> But if you record "fast-forward merge", you force all people pulling
> from your repository to have this purely local and without any significant
> information "I have fetched then" marker.
Even if I agreed that the revision was meaningless, the cost of such a
revision is miniscule.
>>> In other words, the empty merge is totally semantically empty even in the
>>> bazaar world. Why does it exist?
>> It exists because it is useful. Because it makes the behavior of bzr
>> merge uniform. Because in some workflows, commits show that a person
>> has signed off on a change.
>
> Signing off the fact of fetching changes? For true merge you are signing
> off the fact that there were no conflicts, or you sign off your conflict
> resolution.
You sign off on the contents of the revision you fetched. You say "I
have reviewed this revision, and approved it."
>> It's not something special-- it's just another commit, like regular
>> commits, and merge commits. It would be harder to forbid than it is to
>> permit.
>
> Actualy the check is very easy.
Agreed. It's just that not checking is easier still.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXzD0F+nu1YWqI0RAiGvAJsEbPNNlqZ7QCH7EE39YABqEm/BtwCaAxIo
NHqG4NVZpvymTUlCLYyCqKM=
=YUdC
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-18 0:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171959070.1971@xanadu.home>
On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> >
> > .. and it sorts _differently_ on a big-endian vs little-endian thing,
> > doesn't it?
>
> Sure. But who cares? The sorting is just there to 1) perform binary
> searches on the list of deltas based from a given object, and 2) find a
> list of all deltas with the same base object.
_I_ care.
The new code is messy. It's fragile, and already showed one very
fundamental bug which depended on architectures.
These things matter. We have had very few bugs in git, and one of the
reasons is (I believe) that we haven't had ad-hoc code. I get _very_
nervous when you mix up SHA1 names with somethign totally different
without even a flag to say which one it is. That's just nasty. The fact
that the code then behaves (and behave_d_) differently on different
architectures is just a sign of the problem.
"Who cares?" is not a good question to ask for a SCM.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:57 UTC (permalink / raw)
To: Aaron Bentley
Cc: Matthieu Moy, Sean, Jakub Narebski, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <45357A6E.3050603@utoronto.ca>
Dear diary, on Wed, Oct 18, 2006 at 02:50:54AM CEST, I got a letter
where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> Petr Baudis wrote:
>
> > Ok, one last question - do you do most of the work locally, fetching
> > bits of data as you need, or remotely, only taking input/producing
> > output over the network (the pserver model)?
>
> Personally, I do not do remote commits over slow links. At home, I use
> a single machine, and mirror my repository to a public machine using
> rsync. At work, I store my repository on an NFS server, and push my
> repository to a public machine using rsync.
I meant the work of the commands (bzr log and such), not your personal
workflow. :-) Sorry for being unclear.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 0:50 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Sean, Jakub Narebski, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <20061018004209.GL20017@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petr Baudis wrote:
> Ok, one last question - do you do most of the work locally, fetching
> bits of data as you need, or remotely, only taking input/producing
> output over the network (the pserver model)?
Personally, I do not do remote commits over slow links. At home, I use
a single machine, and mirror my repository to a public machine using
rsync. At work, I store my repository on an NFS server, and push my
repository to a public machine using rsync.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNXpu0F+nu1YWqI0RAjPTAJ4w9YOM5XLpnIP9jYywtfMr+LZLvACfdycA
/TYAGUVGweR5+cPtDVAIBq4=
=rsNR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 0:48 UTC (permalink / raw)
To: Aaron Bentley
Cc: Petr Baudis, Matthieu Moy, Sean, Linus Torvalds, bazaar-ng, git
In-Reply-To: <4535778D.40006@utoronto.ca>
Aaron Bentley wrote:
> Petr Baudis wrote:
>>> this only makes sense if
>>> you have a fast access to the repository (otherwise, you consider your
>>> local repository as a cache, and you're ready to pay the disk space
>>> price to save your bandwidth). In this case, it's often in your
>>> filesystem (local or NFS).
>>
>> So how is the light checkout actually implemented? Do you grab the
>> complete new snapshot each time the remote repository is updated?
>
> No, the lightweight checkouts store very little. They have
> - a copy of tree shape (filenames, paths, sha1 sums) from the last
> commit.
> - a copy of tree shape for the current working directory
> - a map from stat values to sha-1 hashes
Ah. So in git terminology it stores index and working directory
(and perhaps the name of branch).
--
Jakub Narebski
Poland
^ permalink raw reply
* Make the ftplugin right wrt gitdir
From: Pierre Habouzit @ 2006-10-18 0:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <11611319762395-git-send-email-madcoder@debian.org>
sorry for the mess, I'm a bit tired :)
Here is a third patch to fix the plugin to find the git-dir properly.
Also add a nice shortcut to quit that buffer.
^ permalink raw reply
* [PATCH] be more robust wrt the git-dir.
From: Pierre Habouzit @ 2006-10-18 0:47 UTC (permalink / raw)
To: Jeff King; +Cc: git, Pierre Habouzit
In-Reply-To: <11611324463754-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
contrib/vim/ftplugin/gitcommit.vim | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/contrib/vim/ftplugin/gitcommit.vim b/contrib/vim/ftplugin/gitcommit.vim
index a9cb946..e958fb1 100644
--- a/contrib/vim/ftplugin/gitcommit.vim
+++ b/contrib/vim/ftplugin/gitcommit.vim
@@ -52,9 +52,17 @@ function! Git_diff_windows(vertsplit, au
rightbelow new
endif
silent! setlocal ft=diff previewwindow bufhidden=delete nobackup noswf nobuflisted nowrap buftype=nofile
- exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . "\n1Gdd"
- exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . " \| git apply --stat\no\<esc>1GddO\<esc>"
+ let gitDir = system('git rev-parse --git-dir 2>/dev/null')
+ let gitDir = substitute(gitDir, '.git\n', '', '')
+ let wd = getcwd()
+ if gitDir != ''
+ exe 'cd '.gitDir
+ endif
+ exe 'normal :r!LANG=C git diff HEAD -- ' . list_of_files . "\n1Gdd"
+ exe 'normal :r!LANG=C git diff HEAD -- ' . list_of_files . " \| git apply --stat\no\<esc>1GddO\<esc>"
+ exe 'cd '.wd
setlocal nomodifiable
+ noremap <buffer> q :bw<cr>
if a:auto
redraw!
wincmd p
--
1.4.2.3
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 0:46 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45357411.20500@utoronto.ca>
Aaron Bentley wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 17 Oct 2006, Aaron Bentley wrote:
> >>> Excuse me? What does that "throws away your local commit ordering" mean?
> >> Say this is the ordering in branch A:
> >>
> >> a
> >> |
> >> b
> >> |
> >> c
> >>
> >> Say this is the ordering in branch B:
> >>
> >> a
> >> |
> >> b
> >> |\
> >> d c
> >> |/
> >> e
> >>
> >> When A pulls B, it gets the same ordering as B has. If B did not have e
> >> and c, the pull would fail.
> >
> > Sure. But that doesn't throw away any local commit ordering. The original
> > order (a->b->c) is still very much there.
>
> After the pull, it's no longer the mainline ordering for the branch. c
> is represented a revision that was merged into the branch, while d is
> represented as a commit on the mainline of the branch.
Well, that is another example while generation number is/can be global,
any numbering of branches must be local-only.
> > The fact that there was a branch
> > off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't
> > take away anything from the original local commit ordering.
>
> It means the the order that revisions are shown in log commands changes,
That doesn't matter...
> and the revision numbers can change.
...but that means that revision numers are totally, absolutely useless.
Unless by some miracle of engineering, or adding namespace, they can be
made unchangeable.
> > But that's a totally specious "record". It has no meaning in a distributed
> > SCM. There is absolutely zero semantic information in it.
>
> It records the committer, the date, the commit message, the parent
> revisions.
All totally empty information. What should be commit message? I have
fetched changes from remote repository? You can remove one of parents
(the one of pointing to before fast-forward "merge") without changing
reachability.
---------
/ \
*--*---x---*---*---y---*
> > The fact that you _locally_ want to remember where you were is a total
> > non-issue for a true distributed system. You shouldn't force everybody
> > else to see your local view - since it has no relevance to them, and
> > doesn't add any information.
>
> Nobody is forced to use your local view.
But if you record "fast-forward merge", you force all people pulling
from your repository to have this purely local and without any significant
information "I have fetched then" marker.
> > In other words, the empty merge is totally semantically empty even in the
> > bazaar world. Why does it exist?
>
> It exists because it is useful. Because it makes the behavior of bzr
> merge uniform. Because in some workflows, commits show that a person
> has signed off on a change.
Signing off the fact of fetching changes? For true merge you are signing
off the fact that there were no conflicts, or you sign off your conflict
resolution.
> It's not something special-- it's just another commit, like regular
> commits, and merge commits. It would be harder to forbid than it is to
> permit.
Actualy the check is very easy. And you have to do similar check when
fetchin/pushing to ensure that you don't clobber your changes.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:42 UTC (permalink / raw)
To: Aaron Bentley
Cc: Matthieu Moy, Sean, Jakub Narebski, Linus Torvalds, bazaar-ng,
git
In-Reply-To: <4535778D.40006@utoronto.ca>
Dear diary, on Wed, Oct 18, 2006 at 02:38:37AM CEST, I got a letter
where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> Petr Baudis wrote:
> >> this only makes sense if
> >> you have a fast access to the repository (otherwise, you consider your
> >> local repository as a cache, and you're ready to pay the disk space
> >> price to save your bandwidth). In this case, it's often in your
> >> filesystem (local or NFS).
> >
> > So how is the light checkout actually implemented? Do you grab the
> > complete new snapshot each time the remote repository is updated?
>
> No, the lightweight checkouts store very little. They have
> - a copy of tree shape (filenames, paths, sha1 sums) from the last
> commit.
> - a copy of tree shape for the current working directory
> - a map from stat values to sha-1 hashes
I see, I guess that means "the index file and tree objects for the last
commit" in git-speak. Thanks.
> > Do all
> > the (at least read-only, like "log" and "diff", perhaps "status")
> > commands work on such a light checkout?
>
> Yes. And if you check out from a read-write branch, all write commands,
> work, too.
Ok, one last question - do you do most of the work locally, fetching
bits of data as you need, or remotely, only taking input/producing
output over the network (the pserver model)?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Pierre Habouzit @ 2006-10-18 0:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <11611319761977-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
Le mer 18 octobre 2006 02:39, Pierre Habouzit a écrit :
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
damn, sorry, that's still not the good one :|
/me feels very tired.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Pierre Habouzit @ 2006-10-18 0:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Pierre Habouzit
In-Reply-To: <11611319762395-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
contrib/vim/README | 10 +++++
contrib/vim/ftplugin/gitcommit.vim | 75 ++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/contrib/vim/README b/contrib/vim/README
index 9e7881f..e5ca9ae 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -6,3 +6,13 @@ To syntax highlight git's commit message
$ cat >>$HOME/.vimrc <<'EOF'
autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
EOF
+
+To use the fancy split-view with the currently commited diff, you need to:
+ 1. Copy ftplugin/gitcommit.vim to vim's ftplugin directory:
+ $ mkdir -p $HOME/.vim/ftplugin
+ $ cp ftplugin/gitcommit.vim $HOME/.vim/ftplugin
+ 2. Auto-detect the editing of git commit files (see above).
+ 3. You can configure the diff to spawn automatically by setting:
+ let git_diff_spawn_mode = 1 (or 2) for an horiz (resp. vert) split.
+ else you have the bindings ,gd or ,ghd to spawn an horiz split with
+ the diff, and ,gvd for the same with a vertical diff.
diff --git a/contrib/vim/ftplugin/gitcommit.vim b/contrib/vim/ftplugin/gitcommit.vim
new file mode 100644
index 0000000..a9cb946
--- /dev/null
+++ b/contrib/vim/ftplugin/gitcommit.vim
@@ -0,0 +1,75 @@
+if exists("b:did_ftplugin")
+ finish
+endif
+
+let b:did_ftplugin = 1
+
+setlocal tw=74
+setlocal nowarn nowb
+
+"{{{ function Git_diff_windows
+
+function! Git_diff_windows(vertsplit, auto)
+ let i = 0
+ let list_of_files = ''
+
+ " drop everything until '# (will commit)' and the next empty line
+ while i <= line('$')
+ let line = getline(i)
+ if line =~ '^#\s*(will commit)$'
+ let i = i + 2
+ break
+ endif
+
+ let i = i + 1
+ endwhile
+
+ " read file names until we have EOF or an empty line
+ while i <= line('$')
+ let line = getline(i)
+ if line =~ '^#\s*[a-z ]*:.*->.*$'
+ let file = substitute(line, '\v^#[^:]*:.*->\s*(.*)\s*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*->.*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ elseif line =~ '^#\s*[a-z ]*:'
+ let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ elseif line =~ '^#\s*$'
+ break
+ endif
+
+ let i = i + 1
+ endwhile
+
+ if list_of_files == ""
+ return
+ endif
+
+ if a:vertsplit
+ rightbelow vnew
+ else
+ rightbelow new
+ endif
+ silent! setlocal ft=diff previewwindow bufhidden=delete nobackup noswf nobuflisted nowrap buftype=nofile
+ exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . "\n1Gdd"
+ exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . " \| git apply --stat\no\<esc>1GddO\<esc>"
+ setlocal nomodifiable
+ if a:auto
+ redraw!
+ wincmd p
+ redraw!
+ endif
+endfunction
+
+"}}}
+
+noremap <buffer> ,gd :call Git_diff_windows(0, 0)<cr>
+noremap <buffer> ,ghd :call Git_diff_windows(0, 0)<cr>
+noremap <buffer> ,gvd :call Git_diff_windows(1, 0)<cr>
+
+if g:git_diff_spawn_mode == 1
+ call Git_diff_windows(0, 1)
+elseif g:git_diff_spawn_mode == 2
+ call Git_diff_windows(1, 1)
+endif
--
1.4.2.3
^ permalink raw reply related
* contrib/vim patches, replace the previous set
From: Pierre Habouzit @ 2006-10-18 0:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vodsbmlkr.fsf@assigned-by-dhcp.cox.net>
here is a brand new set of patches, the same update on the syntax
file, and an enhanced ftplugin that is very configureable.
Those two patches replace the two previous ones.
^ permalink raw reply
* [PATCH] be more vim-ish, and also syntax hilight Signed-off-by lines.
From: Pierre Habouzit @ 2006-10-18 0:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Pierre Habouzit
In-Reply-To: <1161131976193-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
contrib/vim/syntax/gitcommit.vim | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
index a9de09f..d0c6e5d 100644
--- a/contrib/vim/syntax/gitcommit.vim
+++ b/contrib/vim/syntax/gitcommit.vim
@@ -1,3 +1,14 @@
+" Vim syntax file
+" Language: git commit message
+
+" Quit when a (custom) syntax file was already loaded
+if exists("b:current_syntax")
+ finish
+endif
+
+syn region gitSignedOff start=/^Signed-off-by:/ end=/$/ contains=gitAuthor,gitEmail
+syn region gitAuthor contained start=/\s/ end=/$/
+
syn region gitLine start=/^#/ end=/$/
syn region gitCommit start=/^# Updated but not checked in:$/ end=/^#$/ contains=gitHead,gitCommitFile
syn region gitHead contained start=/^# (.*)/ end=/^#$/
@@ -8,6 +19,9 @@ syn match gitCommitFile contained /^#\t.
syn match gitChangedFile contained /^#\t.*/hs=s+2
syn match gitUntrackedFile contained /^#\t.*/hs=s+2
+hi def link gitSignedOff Keyword
+hi def link gitAuthor Normal
+
hi def link gitLine Comment
hi def link gitCommit Comment
hi def link gitChanged Comment
@@ -16,3 +30,7 @@ hi def link gitUntracked Comment
hi def link gitCommitFile Type
hi def link gitChangedFile Constant
hi def link gitUntrackedFile Constant
+
+let b:current_syntax = "git"
+
+" vim: ts=8 sw=2
--
1.4.2.3
^ permalink raw reply related
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 0:39 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Matthieu Moy
In-Reply-To: <45357596.8050702@utoronto.ca>
Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> Petr Baudis wrote:
> > Another aspect of this is that Git (Linus ;) is very focused on getting
> > the history right, nice and clean (though it does not _mandate_ it and
> > you can just wildly do one commit after another; it just provides tools
> > to easily do it).
>
> Yes, rebasing is very uncommon in the bzr community. We would rather
> evaluate the complete change than walk through its history. (Bundles
> only show the changes you made, not the changes you merged from the
> mainline.)
>
> In an earlier form, bundles contained a patch for every revision, and
> people *hated* reading them. So there's definitely a cultural
> difference there.
BTW, I think what describes the Git's (kernel's) stance very nicely is
what I call the Al Viro's "homework problem":
http://lkml.org/lkml/2005/4/7/176
If I understand you right, the bzr approach is what's described as "the
dumbest kind" there? (No offense meant!)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ 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