Jonathan Nieder jrnie...@gmail.com writes:
Now suppose my relay has some downtime. That's fine --- I can still
maintain the mirror by running the same commands on another machine.
But when the old relay comes back up, push --lockref will fail and
pu and next in my mirror are not updated any
Am 15.07.2013 05:50, schrieb Junio C Hamano:
... or also with your --lockref is default
$ git push origin +master
... rejected due to stale expectation
$ git fetch
You just have updated the lockref base, so if you did, without doing
anything else,
$
Am 14.07.2013 22:59, schrieb Johannes Sixt:
... I wonder how Junio's last
example with push.default=simple can work today:
$ git pull --rebase # not a merge
$ git push
because it is not a fast-forward.
*blush* I was mostly asleep and and totally off the rails when I wrote
this
On Sat, Jul 13, 2013 at 01:08:09PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push
Johannes Sixt j...@kdbg.org writes:
All you have been saying is that you find your
git push --lockref there topic
is more useful than my
git push --lockref there +topic
You are trading crystal clear semantics to save users ONE character to
type. IMO, it's a bad deal.
Think how
Am 14.07.2013 21:17, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
I actually think that by implying allow-no-ff in --lockref, you are
hurting users who have configured a push refspec without a + prefix:
They suddenly do not get the push denied when it is not a fast-forward
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref on a per ref basis address your
concerns?
I realize
Jonathan Nieder wrote:
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref on a per ref basis address
Am 14.07.2013 22:34, schrieb Jonathan Nieder:
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref on
Johannes Sixt j...@kdbg.org writes:
Am 14.07.2013 21:17, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
I actually think that by implying allow-no-ff in --lockref, you are
hurting users who have configured a push refspec without a + prefix:
They suddenly do not get the push
Jonathan Nieder jrnie...@gmail.com writes:
(4) gitk @{u}@{1}..@{u}; # Is the change good?
(5a) git pull --rebase; git push; # Yes, put my change on top of it
(5b) git push --force; # No, my change is better!
So far so good. But what if yet another change is made upstream
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Then I will use
(5c) git push --force
which means not to use this new lockref trick that looks at my
remote-tracking branch and instead to just force the ref update.
I am not sure I follow. Do other contributors
Am 12.07.2013 23:19, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
We have three independent options that the user can choose in any
combination:
o --force given or not;
o --lockref semantics enabled or not;
o refspec with or without +;
and these two orthogonal
Johannes Sixt j...@kdbg.org writes:
I am suggesting that +refspec would *not* override the match/mismatch
safety, but --force would.
OK.
I earlier did not read from your message that you wanted to change
+refspec to mean allow non-ff push, so the two entries in your
table:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push to succeed,
you know that the push replaces not just _any_ ancestor
Am 13.07.2013 22:08, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push to succeed,
you know
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
[remote ko]
url =
Johannes Sixt j...@kdbg.org writes:
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
Am 12.07.2013 19:40, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
Johannes Sixt j...@kdbg.org writes:
We have three independent options that the user can choose in any
combination:
o --force given or not;
o --lockref semantics enabled or not;
o refspec with or without +;
and these two orthogonal preconditions of the push
o push is fast-forward
Am 10.07.2013 01:08, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
I _think_ I am OK if we introduced --allow-no-ff that means the
current --force (i.e. rewinding is OK), that does not defeat the
--lockref safety. That is the intended application (you know that
push does
Johannes Sixt j...@kdbg.org writes:
Or perhaps you were implicitly assuming that --lockref would
automatically mean I know I am rewinding, so as soon as I say
--lockref, I mean --allow-no-ff, and I did not realize that.
That's what I mean, sort of. Because of your 4 cases of a ref update, I
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
[remote ko]
url = kernel.org:/pub/scm/git/git.git
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-push.txt | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index f7dfe48..e7c8bd6 100644
--- a/Documentation/git-push.txt
+++
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean it, dude, and not I
mean it sometimes. It would make sense if this sentence were This is
At 12:53 -0700 09 Jul 2013, Junio C Hamano gits...@pobox.com wrote:
+This is meant to make `--force` safer to use. Imagine that you have
+to rebase what you have already published. You will have to
+`--force` the push to replace the history you originally published
+with the rebased history.
On 07/09/2013 09:53 PM, Junio C Hamano wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-push.txt | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index f7dfe48..e7c8bd6 100644
Johannes Sixt j...@kdbg.org writes:
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean it, dude, and not I
mean it sometimes. It would
Aaron Schrab aa...@schrab.com writes:
How does this behave if --force is not used?
Both the usual must fast-forward safety and the ref should not
have moved safety apply.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Michael Haggerty mhag...@alum.mit.edu writes:
bikeshed
The name --lockref is OK, but for me it's less a question of
locking, because as far as the user is concerned the push is an atomic
operation so there is no sense of a lock that is being held for a
finite period of time.
Yeah, I think
Am 09.07.2013 22:37, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean
On 13-07-09 04:37 PM, Junio C Hamano wrote:
Johannes Sixt j...@kdbg.org writes:
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean it,
Johannes Sixt j...@kdbg.org writes:
No. --force means I know what I am doing, no safety needed, thank you.
I sympathize the desire to keep a big red button to override
everything, but it is still not clear how these two independent
safety should work together and should possibly seletively be
Junio C Hamano gits...@pobox.com writes:
I _think_ I am OK if we introduced --allow-no-ff that means the
current --force (i.e. rewinding is OK), that does not defeat the
--lockref safety. That is the intended application (you know that
push does not fast-forward because you rebased, but you
34 matches
Mail list logo
