On Mon, May 27, 2019 at 4:27 PM Elijah Newren wrote:
> That sounds good...though it's taking my short patch and just about
> amounts to completely rewriting it. Would you like to take it over
> including authorship, and just add either a "Original-patch-by:" or
> "Based-on-patch-by:" for me in th
On Mon, May 27, 2019 at 2:12 PM Elijah Newren wrote:
> On Fri, May 24, 2019 at 4:10 PM Eric Rannaud wrote:
> >
> > With this patch, we keep track of whether a particular branch or tag has
> > been changed by this fast-import process since our last checkpoint (or
>
(The patch is identical to v3 but I've tried to clarify the commit
message and added the missing sign-off.)
On Fri, May 24, 2019 at 4:10 PM Eric Rannaud wrote:
>
> At a checkpoint, fast-import resets all branches and tags on disk to the
> OID that we have in memory. If --force is n
rocess 2 will be overwritten:
1> $ git fast-import --force
1> reset refs/heads/master
1> from $A
1> checkpoint
2> $ git branch -f refs/heads/master $B
1> reset refs/heads/master
1> from $C
1> checkpoint
and maste
On Wed, May 15, 2019 at 5:36 PM Elijah Newren wrote:
> with during the fast-import process. However, the whole reason for
> your patch is because checkpoints are in use *and* people are updating
> the repo during the fast-import process, so this area that was likely
> overlooked in the past now i
On Tue, May 14, 2019 at 10:30 PM Junio C Hamano wrote:
>
> "Eric Rannaud" writes:
>
> > We now keep track of whether branches and tags have been changed by this
> > fast-import process since our last checkpoint (or startup). At the next
> > checkpoint, only
At a checkpoint, fast-import resets all branches and tags on disk to the
OID that we have in memory. If --force is not given, only branch resets
that result in fast forwards with respect to the state on disk are
allowed.
With this approach, even for refs that fast-import has not been
commanded to
At a checkpoint, fast-import resets all branches and tags on disk to the
OID that we have in memory. If --force is not given, only branch resets
that result in fast forwards with respect to the state on disk are
allowed.
With this approach, even for refs that fast-import has not been
commanded to
At a checkpoint, fast-import resets all branches and tags on disk to the
OID that we have in memory. If --force is not given, only branch resets
that result in fast forwards with respect to the state on disk are
allowed.
With this approach, even for refs that fast-import has not been
commanded to
On Thu, Jul 19, 2018 at 3:26 PM, SZEDER Gábor wrote:
> But how do some of these messages end up on the test script's stderr,
> why don't we get them from all five tests, and why do they come from
> different file/line locations?
Thanks for the detailed explanation.
Signed-off-by: Eric Rannaud
On Thu, Sep 28, 2017 at 8:51 PM, Junio C Hamano wrote:
> I think that your patch the last round that feeds fd#8 in the
> foreground (i.e. fully trusting that the caller is sensibly giving
> input that produces no output) is already a good place to stop.
>
> Your patch this round that feeds fd#8 in
updated". This wasn't always true
without this patch.
This fix unconditionally calls dump_{branches,tags,marks}() for all
checkpoint commands. dump_branches() and dump_tags() are cheap to call
in the case of a no-op.
Add tests to t9300 that observe the (non-packfiles) effects of
checkpo
On Thu, Sep 28, 2017 at 5:59 AM, Adam Dinwoodie wrote:
> On Wed, Sep 27, 2017 at 10:07:41PM -0700, Eric Rannaud wrote:
>>
>> Also adding the necessary PIPE prereq, as pointed out by Ramsay Jones.
>
> Cygwin doesn't have the PIPE prereq; I've just confirmed that
On Thu, Sep 28, 2017 at 3:35 AM, Junio C Hamano wrote:
> "Eric Rannaud" writes:
>
>> +# The commands in input_file should not produce any output on the file
>> +# descriptor set with --cat-blob-fd (or stdout if unspecified).
>
> Thanks for documenting this. Swa
On Wed, Sep 27, 2017 at 11:02 PM, Junio C Hamano wrote:
> Eric Rannaud writes:
>
>> Doesn't fast-import get a copy of 8 (open for both reading and
>> writing), as a child process, and exec 8>&- only closes the copy of
>> the file descriptor in the parent shel
updated". This wasn't always true
without this patch.
This fix unconditionally calls dump_{branches,tags,marks}() for all
checkpoint commands. dump_branches() and dump_tags() are cheap to call
in the case of a no-op.
Add tests to t9300 that observe the (non-packfiles) effects of
checkpo
On Wed, Sep 27, 2017 at 8:48 PM, Junio C Hamano wrote:
>> + cat $input_file >&8
>
> It probably is a good idea to quote "$input_file" in case other
> people later use a full path to the file or something; for now this
> is OK.
Right.
> fd#8 at this point does not have a reader; unless the c
updated". This wasn't always true
without this patch.
This fix unconditionally calls dump_{branches,tags,marks}() for all
checkpoint commands. dump_branches() and dump_tags() are cheap to call
in the case of a no-op.
Add tests to t9300 that observe the (non-packfiles) effects of
checkpo
updated". This wasn't always true
without this patch.
This fix unconditionally calls dump_{branches,tags,marks}() for all
checkpoint commands. dump_branches() and dump_tags() are cheap to call
in the case of a no-op.
Add tests to t9300 that observe the (non-packfiles) effects of
checkpo
database.
This fix unconditionally calls dump_{branches,tags,marks}() for all
checkpoint commands. dump_branches() and dump_tags() are cheap to call
in the case of a no-op.
Signed-off-by: Eric Rannaud
---
fast-import.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
On Tue, May 16, 2017 at 10:14 AM, Kevin Daudt wrote:
>> A transparent optimization that tries execve() then falls back to the
>> user's shell sounds like a good idea.
>
> It does not really work that way. Git runs in a separate process that
> does not have access to your current shell. That's why
On Tue, May 16, 2017 at 9:59 AM, Eric Rannaud wrote:
> When I use "git rebase --exec " I'm basically writing a "foreach
> commit in range { }" in my shell. Same idea with git bisect run.
>
> A transparent optimization that tries execve() then falls back to
On Tue, May 16, 2017 at 9:47 AM, Jeff King wrote:
>> I think we want to behave consistently for shell builtins and for
>> exported functions --- they are different sides of the same problem,
>> and behaving differently between the two feels confusing.
>
> Yes, I think ideally we'd handle it all tr
On Tue, May 16, 2017 at 9:18 AM, Jeff King wrote:
> On Tue, May 16, 2017 at 12:23:02PM +0200, Johannes Schindelin wrote:
>> It would appear to me that you used a side effect of an implementation
>> detail: that `git rebase -i` was implemented entirely as a shell script.
>
> I don't think that's tr
On Mon, May 15, 2017 at 8:53 PM, Jeff King wrote:
>> > So I suspect if you added an extraneous semi-colon, your case would work
>> > again (and that would confirm for us that this is indeed the problem).
>>
>> Wow, that's a brilliant analysis.
>
> If it's right. :) It's all theory at this point.
>
Hi all,
It used to be possible to run a sequence like:
foo() { echo X; }
export -f foo
git rebase --exec foo HEAD~10
Since upgrading to 2.13.0, I had to update my scripts to run:
git rebase --exec "bash -c foo" HEAD~10
I'm not sure if this was an intended change. Bisecting with the
fol
26 matches
Mail list logo
