Hi, This thread did not receive any updates for a long time. Could someone provide some feedback? Is this feasible? Does it make sense to add this command? If not, why? Thanks, Vitor On Tue, Sep 27, 2011 at 9:57 AM, Vitor Antunes <vitor.hda@xxxxxxxxx> wrote: > On Sat, Sep 24, 2011 at 10:19 PM, Dmitry Ivankov <divanorama@xxxxxxxxx> wrote: >> On Sun, Sep 25, 2011 at 1:37 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >>> Thanks. I must have missed the earlier discussion. What are the >>> semantics of this command and its intended purpose? >> My guess is that if fast-import is used to manage a set of "remote" >> branches, it should be able to delete branches. Then, it should >> be allowed to do non-fastforward updates too (--force). Why can't >> it just ignore branches deletion (considering --force)? > > I started by using --force, but I did not want to completely disable > these checks. The idea of the drop command is to add support to the > exceptions that require non-fastforward updates. > >> Random thoughts: >> 1. once 'drop' is executed, fast-import can't tell if the branch was >> actually deleted. And moreover any attempt to read this branch >> head becomes illegal (either it's missing in .git or fast-import is >> instructed to use a dropped branch). >> 2. 'reset' command is a bit like proposed 'drop' but it never deletes >> a branch ref. Consider following imports: >> 1) import branch topic >> 2) reset topic >> 3) import branch topic2 starting at topic (incorrect import) >> If 1-3) is done in one fast-import process, the error is reported. >> If 3) is done separately, it succeeds but the result is strange: >> topic2 isn't started from scratch but from old "erased" topic. >> So, maybe, reset should be fixed to erase branches on --force. > > I think you are not considering the possibility that checkpoints could > have been done along the way. I use them frequently to be able to > analyse branches with diff-tree. As soon as a checkpoint is done, > update-branches will issue an error (commit A is not part of branch A'). > >> One more scenario is: >> 1) import topic >> 2) reset topic >> 3) import topic >> If 1-3) go together - no error >> If 3) goes separate - no error, but non-fastforward update. >> Much more harmless, but still may look strange. > > Not exactly true if there is a checkpoint done after step 1. > > My scenario is: > > 1) import topic > 2) checkpoint > 3) diff-tree and processing > 4) exit if processing returns ok > 5) reset topic to another HEAD > 6) goto 1) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html