Andy Parkins [off-list ref] writes:
On Wednesday 2007 March 14 07:44, Theodore Tso wrote:
quoted
I agree with Junio; I think the scripts are much more readable and
easier to understand; In fact, it would be nice if the script were
preserved somewhere, perhaps as comments in the .c file.
If only there were some tool that would keep collections of files as a
snapshotted whole and allow us to browse the history of those snapshots in
some sort of connected graph, with each snapshot being given some sort of
unique ID. Then we could simply refer to that unique ID when we wanted to
tell someone about a particular historical instance.
:-)
There is a difference between having a readily greppable and
lessable copy handy to study at your own initiative, and being
able to retrieve to review only after being told.
You could argue that we can all do that with git-grep and
git-less ;-).
On Wednesday 2007 March 14 11:12, Junio C Hamano wrote:
There is a difference between having a readily greppable and
lessable copy handy to study at your own initiative, and being
able to retrieve to review only after being told.
Well I was only joking really.
You could argue that we can all do that with git-grep and
git-less ;-).
Definitely. git is so good at this sort of stuff that encouraging the
retention of commented out code is just filling up source files with junk.
In the old days, before version control, I would often have files with
#if 0
// This is how I used to do it
// ...
#endif
These days I comment it out, then after a few successful commits it gets
removed from the source file. Git makes my code cleaner and clearer as it's
not filled with obsolete junk. I am always secure in the knowledge that I
can go back and look if I want. The same is true, I think, for shell script
replaced with C code.
What will you do if in the future the C gets a feature that wasn't in the
shell code - should the shell code be updated? If you don't then the comment
is a lie, if you do then it's a maintenance nightmare.
Chuck it and be happy it's chucked. A rule for life. I should write fortune
cookies.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Hi,
On Wed, 14 Mar 2007, Junio C Hamano wrote:
Andy Parkins [off-list ref] writes:
quoted
On Wednesday 2007 March 14 07:44, Theodore Tso wrote:
quoted
I agree with Junio; I think the scripts are much more readable and
easier to understand; In fact, it would be nice if the script were
preserved somewhere, perhaps as comments in the .c file.
If only there were some tool that would keep collections of files as a
snapshotted whole and allow us to browse the history of those snapshots in
some sort of connected graph, with each snapshot being given some sort of
unique ID. Then we could simply refer to that unique ID when we wanted to
tell someone about a particular historical instance.
:-)
There is a difference between having a readily greppable and
lessable copy handy to study at your own initiative, and being
able to retrieve to review only after being told.
You could argue that we can all do that with git-grep and
git-less ;-).
Not to forget git-checkout.
But I like the idea of contrib/examples/. Why not put more stuff there,
instead of clinging onto scripts for core-git? The purpose of
contrib/examples/ is to provide easy samples, and the purpose of core-git
is _not_ to provide easy examples, but a consistent and portable set of
programs.
Als, when reading Git's scripts, I often think
- wow, what a different style from my one, and
- would locking not be a nice thing?
But I guess that now that the King Penguin spoke, I no longer have to
argue for more builtins, even if they are trivial. (Who knows, maybe we
can ship _one_ program, which is then hard linked to git-*, soon?)
Ciao,
Dscho