Re: [Gnu-arch-users] how do I protect against this user error

[Robert Anderson]

--- Original Message ---
From: Tom Lord <address@hidden>
To: address@hidden
CC: address@hidden
Subject: Re: [Gnu-arch-users] how do I protect against this user
error

>
>    > From: "Robert Anderson" <address@hidden>
>
>    > Something I do all the time and then get irritated fixing
it, is
>    > update or replay into a tree that has local changes that I
don't
>    > want mixed in with the applied patches.
>
>    > What I really wanted to do was either to undo the local
changes,
>    > then bring in the merges and commit them, or I wanted to
commit
>    > the local changes, then do the update.
>
>    > One answer is "have more discipline before issuing
commands" but
>    > hey, that apparently isn't going to happen without a brain
>    > transplant, so I want to guard against this in an
automated way.
>
>    > Seems like what I want is an analog of tree-lint that kicks me
>    > out of the update or replay if the tree state isn't clean wrt
>    > local changes.
>
>    > Anyone else have this itch?
>
>#!/bin/sh
>set -e
>tla what-changed --diffs [...]
>tla udpate [...]
>
>?

On the one hand, sure.

On the other hand, if I can't remember to run what-changed, I
don't think I should expect to remember to run whatever this
script is called rather than update or star-merge.  If I were to
think "oh yeah, let's make sure this tree is clean, so let's
issue clean-update or clean-merge" I'd just issue what-changed. 
The reality is that I forget to even think about it, and do "tla
update."


But mostly, I'm also hinting at something larger.  If we have
commit hooks for automating things on archive state change,
doesn't it make sense to have hooks for automating things on tree
state change?

Bob