On Thu, Oct 25, 2012 at 9:18 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Show me a single remote helper that manually stores SHA-1's and I
>> might believe you, but I doubt that, marks are too convenient.
>
> Oh dear lord. Why are you arguing? Explain how coming to a consensus
> on
On Thu, Oct 25, 2012 at 9:50 AM, Sverre Rabbelier wrote:
> On Thu, Oct 25, 2012 at 12:48 AM, Jonathan Nieder wrote:
>> Sverre Rabbelier wrote:
>>
>>> I know there was a reason why using UNINTERESTING didn't work
>>> (otherwise we could've used that to start with, instead of needing
>>> Junio's wh
On Thu, Oct 25, 2012 at 12:48 AM, Jonathan Nieder wrote:
> Sverre Rabbelier wrote:
>
>> I know there was a reason why using UNINTERESTING didn't work
>> (otherwise we could've used that to start with, instead of needing
>> Junio's whence solution). I think all refs ended up being marked as
>> UNIN
Sverre Rabbelier wrote:
> I know there was a reason why using UNINTERESTING didn't work
> (otherwise we could've used that to start with, instead of needing
> Junio's whence solution). I think all refs ended up being marked as
> UNINTERESTING or somesuch.
True. Is it be possible to check UNINTER
On Thu, Oct 25, 2012 at 12:34 AM, Jonathan Nieder wrote:
> If I remember right, '^foo1' is (whence == REV_CMD_REV) with (flags ==
> UNINTERESTING). That's why sequencer.c checks for unadorned revs like
> this:
>
> if (opts->revs->cmdline.nr == 1 &&
> opts->revs->cmdline.rev->w
Sverre Rabbelier wrote:
> That's weird, we have this bit:
>
> + if (elem->whence != REV_CMD_REV && elem->whence !=
> REV_CMD_RIGHT)
> + continue;
>
> If I understand correctly that should cause it to only output revs
> (e.g. 'foo1') and the rhs side of a have..want
Felipe Contreras wrote:
> Show me a single remote helper that manually stores SHA-1's and I
> might believe you, but I doubt that, marks are too convenient.
Oh dear lord. Why are you arguing? Explain how coming to a consensus
on this will help accomplish something useful, and then I can explain
On Wed, Oct 24, 2012 at 11:19 PM, Felipe Contreras
wrote:
> Oh really? This is with your patches:
>
> % git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
> reset refs/heads/foo1
> from :21
>
> reset refs/heads/foo3
> from :21
>
> reset refs/heads/foo3
> from :21
>
> reset refs/h
On Thu, Oct 25, 2012 at 7:53 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> All right, so I run this and get this:
>>
>> % git fast-export master..master
>> reset refs/heads/master
>> from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
>>
>> As an user of fast-export, what do I do with that n
On Thu, Oct 25, 2012 at 8:07 AM, Sverre Rabbelier wrote:
> On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
> wrote:
>> This works just fine. Go ahead, apply my patch, and run it, the second
>> branch gets updated.
>
> Yes, but as you said:
>
>> That is already the case, my patch will cause thi
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
wrote:
> This works just fine. Go ahead, apply my patch, and run it, the second
> branch gets updated.
Yes, but as you said:
> That is already the case, my patch will cause this to generate the same
> output:
> % git fast-export --{im,ex}port-m
Felipe Contreras wrote:
> All right, so I run this and get this:
>
> % git fast-export master..master
> reset refs/heads/master
> from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
>
> As an user of fast-export, what do I do with that now?
You passed "master.." on the command line, indicating that you
On Thu, Oct 25, 2012 at 7:39 AM, Sverre Rabbelier wrote:
> On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder wrote:
>> The testcase is imho correct and does not need changing. So yes, I
>> don't want your help changing it. I don't suspect you will be using
>> "git fast-export $(git rev-parse ma
On Thu, Oct 25, 2012 at 7:28 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> I don't need help, I am helping you, I was asked to take a look at
>> this patch series. If you don't want my help, then by all means, keep
>> this series rotting, it has being doing so for the past year without
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder wrote:
> The testcase is imho correct and does not need changing. So yes, I
> don't want your help changing it. I don't suspect you will be using
> "git fast-export $(git rev-parse master)..master". It is safe and
> good to add additional testca
Felipe Contreras wrote:
> I don't need help, I am helping you, I was asked to take a look at
> this patch series. If you don't want my help, then by all means, keep
> this series rotting, it has being doing so for the past year without
> anybody complaining.
Ah, so _that_ (namely getting Sverre's
On Thu, Oct 25, 2012 at 6:27 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Again, if you don't have marks, I don't see what you expect to be
>> exported with 'master..master', even with marks, I don't see what you
>> expect.
>
> And that's fine. Unless you were trying to do some work
On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Wed, 24 Oct 2012, Felipe Contreras wrote:
>
>> 2) master..master shouldn't export anything
>
> The underlying issue -- as explained in the thread -- is when you want to
> update master to a commit that another ref already po
Felipe Contreras wrote:
> Again, if you don't have marks, I don't see what you expect to be
> exported with 'master..master', even with marks, I don't see what you
> expect.
And that's fine. Unless you were trying to do some work and this lack
of understanding got in the way.
In that case, with
On Wed, Oct 24, 2012 at 9:11 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Does it mean that? I don't think so, but let's assume that's the case.
>>
>> We don't have all those commits; without the marks we have nothing. Or
>> what exactly do you mean by 'we'?
>
> Not everyone uses mark
Hi,
On Wed, 24 Oct 2012, Felipe Contreras wrote:
> 2) master..master shouldn't export anything
The underlying issue -- as explained in the thread -- is when you want to
update master to a commit that another ref already points to. In that case
no commits need to exported, but the ref needs to be
Felipe Contreras wrote:
> Does it mean that? I don't think so, but let's assume that's the case.
>
> We don't have all those commits; without the marks we have nothing. Or
> what exactly do you mean by 'we'?
Not everyone uses marks.
Ciao,
Jonathan
--
To unsubscribe from this list: send the line
On Wed, Oct 24, 2012 at 8:08 PM, Jonathan Nieder wrote:
> Hi Felipe,
>
> Felipe Contreras wrote:
>
>> This test is completely wrong.
>>
>> 1) Where are the marks file?
>> 2) master..master shouldn't export anything
>
> Why shouldn't master..master export anything? It means "update the
> master re
Hi Felipe,
Felipe Contreras wrote:
> This test is completely wrong.
>
> 1) Where are the marks file?
> 2) master..master shouldn't export anything
Why shouldn't master..master export anything? It means "update the
master ref; we already have all commits up to and including master^0".
The under
Hi,
Joined late to the party :)
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier wrote:
> This happens only when the corresponding commits are not exported in
> the current fast-export run. This can happen either when the relevant
> commit is already marked, or when the commit is explicitly mar
25 matches
Mail list logo
