On Tue, Oct 30, 2012 at 7:12 PM, Sverre Rabbelier <srabbel...@gmail.com> wrote:
> On Tue, Oct 30, 2012 at 10:11 AM, Felipe Contreras
> <felipe.contre...@gmail.com> wrote:
>> When an object has already been exported (and thus is in the marks) it
>> is flagged as SHOWN, so it will not be exported again, even if this time
>> it's exported through a different ref.
>> We don't need the object to be exported again, but we want the ref
>> updated, which doesn't happen.
>> Since we can't know if a ref was exported or not, let's just assume that
>> if the commit was marked (flags & SHOWN), the user still wants the ref
>> updated.
>> So:
>>  % git branch test master
>>  % git fast-export $mark_flags master
>>  % git fast-export $mark_flags test
>> Would export 'test' properly.
>> Additionally, this fixes issues with remote helpers; now they can push
>> refs wich objects have already been exported.
> Won't this also export child (or maybe parent) branches that weren't
> mentioned? For example:
> $ git branch one
> $ echo foo > content
> $ git commit -m two
> $ git fast-export one
> $ git fast-export two
> I suspect that one of those will export both one and two. If not, this
> seems like a great solution to the fast-export problem.

Why would it? We are not changing the way objects are exported, the
only difference is what happens at the end

And if you are talking about the ref for the reset at the end, it has
to be both in the list of refs selected by the user (initially in
&revs.pending), either marked or the object already referenced by
another ref in the list selected by the user (e.g. fast-export one
two, where one^{commit} == two^{commit}, and not marked as
UNINTERESTING (e.g. ^two).


Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to