From: "Björn Engelmann" <BjEngelmann@gmx.de>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] tagsize < 8kb restriction
Date: Thu, 25 May 2006 13:53:35 +0200 [thread overview]
Message-ID: <44759ABF.1010209@gmx.de> (raw)
In-Reply-To: <7v1wuj6wln.fsf@assigned-by-dhcp.cox.net>
> Sorry, I forgot all about hash-objects X-<. It was a convenient
> way to try out new things such as 'gitlink'. Thanks for the
> clarification.
>
> As to unification, I am not sure if there are a lot to unify.
> Everybody starts with type, length and a LF, but after that each
> type has its own format constraints. A grand unified command
> that knows about format constraints of every type under the sun
> does not sound like a good approach. While we have only handful
> types (and I expect things will stay that way) it is not a big
> deal either way, though.
>
Oops, sorry, I forgot that "modular" in C means something else than in
the OO-World...
You are right. Probably it is best to have one tool handle each type.
Actually what I am aiming for is not the internal structure. I am more
concerned about cleaning up the user-interface. When I started learning
git I found it very annoying and inconsistent that there are commands
for creating a tag and a tree in a validated fashion, but the command
for creating blobs was named "git-hash-object -w" and also could create
all other objects without validating them at all. Also, AFAIK there is
currently no way of creating a commit object with validating.
I am well aware that all functionality neccessary already exists. I just
want to prevent people learning git in future to have the same
frustrating experience as I did.
Obviously renaming / moving code around like that would break nearly all
tools build ontop of git. Therefore I would prefer to use aliasing. If
you feel like this would introduce too many unneccessary commands, I
would instead focus on improving the documentation.
Bj
next prev parent reply other threads:[~2006-05-25 11:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-22 14:48 [PATCH 0/2] tagsize < 8kb restriction Björn Engelmann
2006-05-22 19:18 ` Junio C Hamano
[not found] ` <20060522191240.1cb8c93f.seanlkml@sympatico.ca>
2006-05-22 23:12 ` Sean
2006-05-23 0:02 ` Linus Torvalds
[not found] ` <20060523055900.0dd845fd.seanlkml@sympatico.ca>
2006-05-23 9:59 ` Sean
2006-05-23 20:40 ` Björn Engelmann
2006-05-23 23:15 ` Junio C Hamano
2006-05-24 19:16 ` Björn Engelmann
2006-05-24 19:39 ` Junio C Hamano
2006-05-25 11:53 ` Björn Engelmann [this message]
2006-05-25 20:03 ` Junio C Hamano
2006-05-23 23:49 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44759ABF.1010209@gmx.de \
--to=bjengelmann@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).