On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano gits...@pobox.com wrote:
When branch.*.push configuration variable is defined for the current
branch, a lazy-typing git push (and git push there) will push
the commit at the tip of the current branch to the destination and
update the branch named
Johan Herland jo...@herland.net writes:
+static void setup_per_branch_push(struct branch *branch)
+{
+ struct strbuf refspec = STRBUF_INIT;
+
+ strbuf_addf(refspec, %s:%s,
+ branch-name, branch-push_name);
+ add_refspec(refspec.buf);
This goes back to
Junio C Hamano wrote:
@@ -194,7 +203,14 @@ static int is_workflow_triagular(struct remote *remote)
static void setup_default_push_refspecs(struct remote *remote)
{
struct branch *branch = branch_get(NULL);
- int triangular = is_workflow_triagular(remote);
+ int
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
@@ -194,7 +203,14 @@ static int is_workflow_triagular(struct remote *remote)
static void setup_default_push_refspecs(struct remote *remote)
{
struct branch *branch = branch_get(NULL);
- int triangular =
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if branch.master.push is explicitly
set to update next. I do not see any issue in
On Mon, Jun 24, 2013 at 4:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if branch.master.push is
Johan Herland jo...@herland.net writes:
I haven't yet dug deep enough to figure out an obvious failure mode
(and I probably should not have sent this email until I'd found one),
but I wonder if we'd be better off forcing the $remote and $remote_ref
configuration for a given branch to appear
Junio C Hamano wrote:
If the user said git push without an explicit request to push to
ram, and if branch.master.pushremote was not set to ram, and
still the command git push pushed the branch to ram, then I
would understand what you are worried about, but otherwise I do not
see how what you
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
If the user said git push without an explicit request to push to
ram, and if branch.master.pushremote was not set to ram, and
still the command git push pushed the branch to ram, then I
would understand what you are
Junio C Hamano wrote:
If you do not set anywhere (like branch.master.pushremote or
remote.pushdefault) to push to ram, and if you did not say git
push ram but just said git push, we will not push to ram
(otherwise it is broken). So if the push is going to ram, the
user must have asked us to
Ramkumar Ramachandra artag...@gmail.com writes:
I'm not saying that we need to differentiate between configuration
variables and CLI options; what I _am_ saying is that we need to think
twice about moving a CLI option to a configuration variable, precisely
because we do not differentiate
Junio C Hamano wrote:
With remote.pushdefault, I think the ship has long sailed.
What's wrong with the early feedback approach I suggested?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
When branch.*.push configuration variable is defined for the current
branch, a lazy-typing git push (and git push there) will push
the commit at the tip of the current branch to the destination and
update the branch named by that variable.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
14 matches
Mail list logo
