On 2007-09-15 23:37:21 +0100, Catalin Marinas wrote:

quoted text
> The initial implementation of hide/unhide was to preserve the patch
> position in the stack. This behaviour was really confusing for
> people since pushing a patch after the hidden one actually forced
> the pushing of the hidden patch, which isn't normally shown by
> 'series'. I decided afterwards to create a third category of patches
> - 'hidden' (the other two being applied and unapplied). This cleared
> the unpredictable behaviour when pushing since hidden patches cannot
> be pushed.

I agree that the new semantics is way saner (though I'm still not
entirely convinced that hiding patches is a good idea in the first
place). But the man pages should probably point out clearly that
hidden patches must be unapplied.

quoted text
> Karl's patch does the correct thing of raising an error if sinking
> below an unapplied patch.
>
> Regarding the reordering of the unapplied patches, at the moment you
> can (but I *don't* recommend) edit .git/patches/<branch>/unapplied.
> Maybe the 'float' and 'sink' functionality could be modified to also
> act on unapplied patches (with a --unapplied option). I don't think
> a separate command would be needed as it duplicates a lot of
> functionality from the above.

Why the extra option? Just do the right thing, since it's unambiguous
what the right thing is.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html