Felipe Contreras felipe.contre...@gmail.com:
Most of those old projects have a linear history,
INTERCAL didn't. There were two branches for platform ports.
But different commit/author and respective dates, and merges? Sounds
like overkill.
I felt it was important that the metadata format be
On Tue, Nov 27, 2012 at 9:36 AM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
Most of those old projects have a linear history,
INTERCAL didn't. There were two branches for platform ports.
Fine:
tag v0.1 gst-av-0.1.tar Release 0.1
tag v0.2
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
---
commit 1
directory foo-1.1
Release 1.1 of project foo
.
commit 2
directory foo-1.2
..This is an example of a byte-stuffed line.
Release 1.2 of project foo
.
commit 3
Felipe Contreras felipe.contre...@gmail.com:
I believe that log file is much more human readable. Yet I still fail
to see why would anybody want so much detail only to import tarballs.
The first time I needed such a tool (and I really should have built it then)
was during the events I wrote up
Felipe Contreras felipe.contre...@gmail.com:
The main objective of the logfile design is to make hand-crafting
these easy.
Here's another version with YAML:
Clever.
Now I have to decide if I should allow my aesthetic dislike of YAML to
prevail despite the fact that it's pretty well
Eric S. Raymond e...@thyrsus.com writes:
if commitcount 1:
do_or_die(rm `git ls-tree --name-only HEAD`)
This will fail on file names containing whitespace or glob meta
characters. Better use git rm -qr . here. You don't have to care
about the
Some days ago I reported that I was attempting to write a tool that could
(a) take a git repo and unpack it into a tarball sequence plus a metadata log,
(b) reverse that operation, packing a tarball and log sequence into a repo.
Thanks in part to advice by Andreas Schwab and in part to looking at
On 15.11.2012, at 22:28, Eric S. Raymond wrote:
Some days ago I reported that I was attempting to write a tool that could
(a) take a git repo and unpack it into a tarball sequence plus a metadata log,
(b) reverse that operation, packing a tarball and log sequence into a repo.
Ah, I could
Max Horn post...@quendi.de:
I'm still looking for a better name for it and would welcome suggestions.
Isn't gitar the kind of natural choice? ;) At least for a stand-alone tool,
not for a git subcommand.
I just renamed it git-weave. I keep talking about tarballs because I keep
thinking
10 matches
Mail list logo
