threads / announce / 13059

[ANNOUNCE] Guilt v0.30

Subject: [ANNOUNCE] Guilt v0.30

## tl;dr

2 messages between Apr 11, 2008 and Apr 11, 2008.

replies: 1people: 1as markdown or json

Josef 'Jeff' Sipek· Apr 11, 2008, 00:01 UTC · lore
Guilt v0.30 is available for download (once it mirrors out on kernel.org).

Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git.

Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/

Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git

As promissed, this version includes some interesting changes. The major one being the status file now has a new format. The motivation for this was the fact that the series file effectively duplicated functionality that git itself offered by setting arbitrary refs (e.g., refs/patches/$branch/$patch). Migration between the two formats should be rather painless. If you have no applied patches, no extra work is required. If you happen to have some patches already applied, any guilt command will tell you to run: guilt-repair --status.

Other than the status file change, there have been a number of improvements all over the place. A couple of bash-isms were removed, patchbomb no longer includes "1/1" in the subject when there's only one patch, guilt-repair is more powerful, and can be used to fix up a number of conditions (e.g., autotags left behind, status file format upgrade, etc.), autotagging no longer ignores global guilt.autotag config value.

As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.

------------ Changes since v0.29:

Adam Golebiowski (1):
      Add support for DESTDIR in guilt/Makefile.
Josef 'Jeff' Sipek (35):
      guilt: Use 'git update-ref' instead of echo
      Patch names cannot contain whitespace
      guilt: setup/teardown refs/patches/$branch/$patch on push/pop
      Remove old status format
      repair: remove patch refs
      regression: test guilt-repair
      commit: new command to permanently commit patches
      regression: guilt-commit test
      regression: fix up test 028 expected output
      Update my email address
      repair: allow status file upgrade
      guilt: check status file for being old format
      guilt: replace "echo && return 1" with die
      repair: added --autotag repair mode
      guilt: wrap `git-update-ref -d` to make ref removal cleaner
      regression: simple makefile
      fork: fix regression caused by status format change
      guilt: try to be more portable
      Replace all display related `echo` calls with a custom function
      regression: simplify command logging
      regression: try to be more portable
      guilt: ref_rename_patch takes patch names, not ref names
      regression: test for guilt-fork
      regression: 011 should test guilt-commit as well
      init: honor a global/system guilt.autotag config option
      regression: test the new init options
      autotagging: fix a tiny quirk, and document autotagging properly
      import-commit: replace be careful about * and ? in filenames
      graph: display patch names instead of hashes
      patchbomb: do not include "1/1" in the subject if there's only 1 patch
      files: use the diff-index for top-most patch
      regression: test guilt-files reading the index for the top-most applied patch
      regression: test guilt-files -v
      regression: test that supplied test numbers are valid
      Guilt v0.30
Josef 'Jeff' Sipek· Apr 11, 2008, 00:26 UTC · re: Josef 'Jeff' Sipek · lore

Guilt: Autotagging - aye or nay?

Greetings all!

I was trying to figure out what the default for Guilt's autotagging feature should be. Currently, the default is for it to be on, unless it's overridden by an already existing config setting.

For those who may not be familiar with autotagging, here's an excerpt from the guilt(7) man page:

	Autotagging is a feature that automatically creates unannotated tags
	for top, bottom, and base of the stack.
	On every push or pop operation (refresh is a pop followed by a
	push), Guilt updates the stack top (${branch}_top), stack bottom
	(${branch}_bottom), and stack base (${branch}_base) tags.
		Top: Top-most applied patch/commit
		Bottom: Bottom-most applied patch/commit
		Base: Commit on top of which the bottom most patch is applied
	Having these three tags, one can easily get the log/diff/other
	information only for commits that are (or are not!) part of the
	patch stack.

So far the few people (including myself for the past few months) I asked privately, all said that they turn the feature off.

Ideas?  Comments?  Suggestions?
Josef 'Jeff' Sipek.
-- 
I think there is a world market for maybe five computers.
		- Thomas Watson, chairman of IBM, 1943.

← back to recent threads