Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes: > I agree. I could have really used this while juggling all of the > parts of FSMonitor recently. And yes, it should write the updates > at the bottom in case of an abort. > > Should this take a branch pattern/regex to limit the set of branches > that are updated (or offered to be updated)? For example, if I have > an intermediate commit in the series that has 2 branch names pointing > at it, do we want to offer to update both of them or only the one > that matches some pattern related to the tip? Or is it sufficient to > just enumerate them at the bottom of the todo list and let the user > delete the lines they don't want? The latter sounds sufficient (starting from something simpler should work well in this case). > Should we actually do the update-ref's or should we write a script > that lets the user do it later? The latter would let us also write > out the commands to force update the remote refs if that would be > helpful. Aren't we writing "a script" already by implementing it as an additional "exec git update-ref" in the todo list already? I found that, combined with the idea to use the "label" Taylor mentioned, was the most brilliant part of this proposal.
