Junio C Hamano gits...@pobox.com 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
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 working
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`
Johannes Schindelin johannes.schinde...@gmx.de 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
Hi Junio,
On Thu, 13 Nov 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de 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.
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Jens,
On Sun, 9 Nov 2014, Jens Lehmann wrote:
Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1
Johannes Schindelin johannes.schinde...@gmx.de 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)?
Junio C Hamano gits...@pobox.com 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
Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
Johannes Schindelin johannes.schinde...@gmx.de writes:
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
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
---
Johannes Schindelin johannes.schinde...@gmx.de writes:
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c
18 matches
Mail list logo
