[PATCH] Re: rebase -i: auto-squash commits

From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Date: Jun 18, 2009, 11:18 UTC
Message-ID: <20090618111855.GB12924@vidovic>
In-Reply-To: <7vk53aymuz.fsf@alter.siamese.dyndns.org>

The 18/06/09, Junio C Hamano wrote:

Show 17 quoted lines

> I also often use "magic" commit log message in other occasions.  The most
> important is "[DONTMERGE]" prefix to somebody else's commit I queue to
> 'pu' (or leave unmerged even to 'pu'---just keeping on a topic branch).  I
> accept a patch with "am" and then "amend" after review when I find that it
> needs more work.  One day I am hoping to write a pre-merge hook that
> forbids commits marked with such magic to come into 'next' and down.
> 
> The point?
> 
> Earlier somebody objected to a command that changes behaviour based on
> what is in the commit log message, but for the private commits the patch
> under discussion deals with and the ones I mark with "[DONTMERGE]", the
> commit log message _is_ the right place to leave a mark for commands to
> take notice and act differently.
> 
> Of course we _could_ use notes for that, but that won't play well with
> rebasing I suppose ...

Not for now; you're right. But what I see here is all about commit/branch metadata to make our like with workflows easier.

What about implementing a true metadata feature into Git? There are a lot of nice possible functionalities around metadata.

Fast, stupid and superficial thoughts on that:
- have metadata to make git to act differently and/or for information
  purpose;
- let the user create its own metadata for his own purpose;
- let the user have hooks script where appropriate.

-- 
Nicolas Sebrecht