Karthik Nayak <karthik.188@xxxxxxxxx> writes: >> so after (true) seeking that does not have the SET_PREFIX flag on, >> wouldn't our iterator-advance run through the end since it no longer >> is aware of where to stop? >> > > That's also right and that is indeed the intention. We're trying to make > the actions more intentional. > > So if a user sets a 'prefix' for the iterator, all previous state of the > iterator is reset. So, the same function for seeking an iterator should > also have the same side-effect of resetting the previous state. Perhaps we have different definition of "previous state" in mind? So let's imagine an iterator is walking over all branches (i.e. the prefix is set to refs/heads/, to allow it to stop once it steps outside refs/heads/ and moves over to refs/imerge). It starts iterating and I see branches whose name sorts early in alphabetical order. I tell it to seek to refs/heads/master and keep iterating. Wouldn't it be a lot more natural if it still stops iterating after it finishes showing the last branch, iow, a ref in refs/heads/ hierarchy? In other words, I am not sure why ... > There could be a usecase where we add support for keeping the prefix, > while also seeking the iterator. That would be an explicit change ... that is the optional and unimplemented feature, not the other way around. Is it just the ease of implementation?
