Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15
DORMANTno replies

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

From: Nicolas Sebrecht <hidden>
Date: 2016-06-15 22:46:58

The 18/06/09, Junio C Hamano wrote:
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help