Junio C Hamano writes:
>> And thinking about the names again, I have a feeling that
>> updateInstead and mergeInstead are both probably misnomer.
>
> Let me take this part back. After all, I do not think I would
> design the mechanism to implement an alternative logic that decides
> when it is s
Junio C Hamano writes:
>> I agree that a new value "mergeInstead" or something should be
>> invented when/if different workflows want a looser semantics.
>> People would rely not only on "being able to push when clean" but
>> also on "being safely prevented from pushing when not" (and that is
>>
Junio C Hamano writes:
> Thanks for an explanation why the updateInstead mode must require a
> pristine working tree (and the index). I *now* agree why such a
> mode would be useful, *after* reading it. I did not understand why
> *after* reading only the patch, the documentation updates and the
Johannes Schindelin writes:
> Thanks for mentioning this. I would like to ask not to loosen this later.
> Let me try to explain in more detail than before why I think it would make
> *my* life hard if it ever were loosened.
> ...
> And now when I try to push, Git complains that the working direct
Hi Junio,
On Thu, 13 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Thu, 13 Nov 2014, Johannes Schindelin wrote:
> >
> >> Due to that experience, the documentation also states pretty clearly that
> >> `updateInstead` succeeds only in updating the current branch if the
>
Johannes Schindelin writes:
> On Thu, 13 Nov 2014, Johannes Schindelin wrote:
>
>> Due to that experience, the documentation also states pretty clearly that
>> `updateInstead` succeeds only in updating the current branch if the
>> working directory is clean.
>
> To clarify why `updateInstead` is
Johannes Schindelin writes:
> On Thu, 13 Nov 2014, Johannes Schindelin wrote:
>
>> Due to that experience, the documentation also states pretty clearly that
>> `updateInstead` succeeds only in updating the current branch if the
>> working directory is clean.
>
> To clarify why `updateInstead` is
Hi Junio,
On Thu, 13 Nov 2014, Johannes Schindelin wrote:
> Due to that experience, the documentation also states pretty clearly that
> `updateInstead` succeeds only in updating the current branch if the
> working directory is clean.
To clarify why `updateInstead` is stricter than the `merge` sc
Hi Junio,
On Wed, 12 Nov 2014, Junio C Hamano wrote:
> Instead of running "update-index --refresh; read-tree -m -u", using
> "reset --keep" may be a better implementation of what you are trying to
> do here.
I do not think that `reset --keep` is what I want. I really want to update
only if the w
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 10 Nov 2014, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > Dying when "update-index --refresh" signals a difference is an
>> > attempt to mimic #1, but it is in line with the spirit of the reason
>> > why a user would want to use u
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Dying when "update-index --refresh" signals a difference is an
> > attempt to mimic #1, but it is in line with the spirit of the reason
> > why a user would want to use updateInstead, I think. The situation
> >
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> By the way, if the expected use case of updateInstead is what I
> >> outlined in the previous message, would it make more sense not to
> >> fail with "update-index --refresh" failure (i.e. the working tree
Junio C Hamano writes:
> Dying when "update-index --refresh" signals a difference is an
> attempt to mimic #1, but it is in line with the spirit of the reason
> why a user would want to use updateInstead, I think. The situation
> is more like the person who pushed into your repository from
> sid
Johannes Schindelin writes:
>> By the way, if the expected use case of updateInstead is what I
>> outlined in the previous message, would it make more sense not to
>> fail with "update-index --refresh" failure (i.e. the working tree
>> files have no changes since the index)?
>>
>> Thinking about
Hi Jens,
On Sun, 9 Nov 2014, Jens Lehmann wrote:
> Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
> > Johannes Schindelin writes:
> >
> > > Signed-off-by: Johannes Schindelin
> > > ---
> > > builtin/receive-pack.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff -
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Signed-off-by: Johannes Schindelin
> > ---
> > builtin/receive-pack.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > inde
Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
Johannes Schindelin writes:
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive
Johannes Schindelin writes:
> They are not affected by the update anyway.
>
> Signed-off-by: Johannes Schindelin
> ---
> builtin/receive-pack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index be4172f..4ba51df 10064
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index be4172f..4ba51df 100644
--- a/builtin/receive-pack.c
+++ b/builtin/r
19 matches
Mail list logo
