All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH 0/8] git-repack --max-pack-size
Date: Tue, 1 May 2007 10:36:57 +0100	[thread overview]
Message-ID: <200705011037.03213.andyparkins@gmail.com> (raw)
In-Reply-To: <7virbc7vue.fsf@assigned-by-dhcp.cox.net>

On Tuesday 2007 May 01, Junio C Hamano wrote:

> But I was not talking about changing describe output because of
> the above argument.  What I was wondering was that it might be a
> good idea to loosen the promise of never rewinding 'next'.  It
> might be easier to view the history of 'next' during development
> for each cycle, if it started afresh after a feature release.

This is an interesting philosophy-of-version-control question.  If two 
identical trees fall in the forest and there is no one there to diff them, 
was a release made? :-)

It's been my experience that failed attempts and dead-end branches are often 
of equal value to the successful branches.  It's very handy when someone 
asks "why can't we do it like this", to be able to answer "look at revision 
xyz onwards".  Even just for your own reference, I've often looked back on 
abandoned paths and thought "that wasn't as bad as I thought, I just need to 
fix it here and here" - if I'd discarded that work it would be gone forever.

It's certainly true in academia, a large part of my doctoral thesis was 
about "things that don't work" :-)  Documenting failure is as important as 
documenting success.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

  reply	other threads:[~2007-05-01  9:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30 23:16 [PATCH 0/8] git-repack --max-pack-size Dana How
2007-05-01  3:20 ` Junio C Hamano
2007-05-01  4:37   ` Shawn O. Pearce
2007-05-01  8:26   ` Andy Parkins
2007-05-01  9:10     ` Junio C Hamano
2007-05-01  9:36       ` Andy Parkins [this message]
2007-05-01 14:46       ` Nicolas Pitre
2007-05-01 17:11         ` Junio C Hamano
2007-05-01 17:17           ` Nicolas Pitre
2007-05-01 17:42           ` Johannes Schindelin
2007-05-01 19:07             ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2007-04-08 23:17 Dana How
2007-04-09  2:33 ` Nicolas Pitre
2007-04-09 18:54   ` Dana How
2007-04-09 19:43 ` Dana How

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=200705011037.03213.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.