On Wed, Nov 19, 2014 at 11:27:59AM +0900, Mike Hommey wrote:
> On Tue, Nov 18, 2014 at 06:21:22PM -0800, Jonathan Nieder wrote:
>> IIRC then 'M 04' wants a tree object, not a commit object, so
>> you'd have to do
>>
>> ls ""
>> M 04 ""
>
> That's what I'm planning to try ; Woul
On Tue, Nov 18, 2014 at 06:21:22PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
>
> > So, in the end, I was able to do everything with what's currently
> > provided by git fast-import, but one thing would probably make life
> > easier for me: being able to initialize a commit tree from a com
Mike Hommey wrote:
> So, in the end, I was able to do everything with what's currently
> provided by git fast-import, but one thing would probably make life
> easier for me: being able to initialize a commit tree from a commit
> that's not one of the direct parents.
IIRC then 'M 04' wants a t
On Tue, Nov 18, 2014 at 12:11:47PM +0900, Mike Hommey wrote:
> Oh, so `ls ` would print out what is? That would
> definitely help, although with the trick above, I probably wouldn't
> actually need it anymore.
So, in the end, I was able to do everything with what's currently
provided by git fast-
On Mon, Nov 17, 2014 at 07:27:41PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
>
> > And while I'm here, it's sad that one needs to emit a dummy cat-blob or
> > ls command to wait for a checkpoint to be finished
>
> That's a good point. (Though relying on checkpoints to read back
> inform
Mike Hommey wrote:
> And while I'm here, it's sad that one needs to emit a dummy cat-blob or
> ls command to wait for a checkpoint to be finished
That's a good point. (Though relying on checkpoints to read back
information is an ugly trick, so if we can get other commands to
provide the informat
On Mon, Nov 17, 2014 at 06:53:59PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
>
> > BTW, if it so happens that all the operations that were done end up
> > creating objects that already existed for some reason, checkpoint
> > doesn't do anything, which is fine for the pack and tags, but no
On Mon, Nov 17, 2014 at 06:51:31PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
> > On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:
>
> >> How did you get that "Not a blob" message?
> >
> > When trying to *create* a tree with a commit in it, so instead of giving
> > the mark
Mike Hommey wrote:
> BTW, if it so happens that all the operations that were done end up
> creating objects that already existed for some reason, checkpoint
> doesn't do anything, which is fine for the pack and tags, but not
> necessarily so for export-marks.
Does something like this help?
Do yo
Mike Hommey wrote:
> On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:
>> How did you get that "Not a blob" message?
>
> When trying to *create* a tree with a commit in it, so instead of giving
> the mark for a blob to a filemodify command, giving a mark for a commit.
> That is what
On Tue, Nov 18, 2014 at 11:21:37AM +0900, Mike Hommey wrote:
> On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:
> > Hi,
> >
> > For some reason, I need to know the sha1 corresponding to some marks
> > I'm putting in a fast-import stream. Unfortunately, this does not appear
> > to be po
On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
>
> > - fast-import's `ls` command documentation about its output format
> > mentions that the output may contain commits, so I tried the trick of
> > creating a tree with commits, but fast-import then fails
On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:
> Hi,
>
> For some reason, I need to know the sha1 corresponding to some marks
> I'm putting in a fast-import stream. Unfortunately, this does not appear
> to be possible.
> - I'd rather not require a checkpoint to export marks each time
Mike Hommey wrote:
> - fast-import's `ls` command documentation about its output format
> mentions that the output may contain commits, so I tried the trick of
> creating a tree with commits, but fast-import then fails with:
> fatal: Not a blob (actually a commit)
> which I totally under
Hi,
For some reason, I need to know the sha1 corresponding to some marks
I'm putting in a fast-import stream. Unfortunately, this does not appear
to be possible.
- I'd rather not require a checkpoint to export marks each time I need
such a sha1, and I'd rather not do that work that requires them
15 matches
Mail list logo
