What's cooking in git.git (Apr 2012, #02; Wed, 4)

What's cooking in git.git (Apr 2012, #02; Wed, 4)

[Junio C Hamano]

What's cooking in git.git (Apr 2012, #02; Wed, 4)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.

With a couple of last-minute fixes to gitk breakage, 1.7.10-rc4 is out,
and hopefully we can do the real 1.7.10 by the end of the week.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* jc/index-v4 (2012-04-04) 10 commits
 - update-index: upgrade/downgrade on-disk index version
 - read-cache.c: write prefix-compressed names in the index
 - read-cache.c: read prefix-compressed names in index on-disk version v4
 - read-cache.c: move code to copy incore to ondisk cache to a helper function
 - read-cache.c: move code to copy ondisk to incore cache to a helper function
 - read-cache.c: report the header version we do not understand
 - read-cache.c: make create_from_disk() report number of bytes it consumed
 - read-cache.c: allow unaligned mapping of the index file
 - cache.h: hide on-disk index details
 - varint: make it available outside the context of pack
 (this branch is tangled with jc/split-blob.)

* jk/add-p-skip-conflicts (2012-04-04) 3 commits
 - fixup from rctay
 - snap
 - add -p: skip conflicted paths

--------------------------------------------------
[Graduated to "master"]

* pt/gitk (2012-04-02) 2 commits
 + gitk: fix setting font display with new tabbed dialog layout.
 + gitk: fix tabbed preferences construction when using tcl 8.4

Pat spotted and fixed a few bugs in the latest gitk updates; we may need
these in 1.7.10 so testing on various platforms is very much appreciated.

--------------------------------------------------
[Stalled]

* lp/maint-diff-three-dash-with-graph (2012-03-20) 3 commits
 - t4202: add test for "log --graph --stat -p" separator lines
 - log --graph: fix break in graph lines
 - log --graph --stat: three-dash separator should come after graph lines

The combination of two options "log --graph --stat" was an obscure corner
case nobody cared about, and did not correctly show the ancestry graph
lines.

I've split the original patch into three pieces, one for fixes to two
different issues and a test.  Also the test is adjusted so that the series
can be back-merged to older codebase that did not have 7f81463 (Use
correct grammar in diffstat summary line, 2012-02-01) that first appeared
in v1.7.9.2

With a review from Zbigniew, I would expect that this would be rerolled
again.

* cn/apply-fix-ws-can-lengthen-lines (2012-03-11) 1 commit
 . apply: reallocate the postimage buffer when needed

Attempts to address an ancient bug that dates back to the addition
of an oddball "tab-in-indent" whitespace breakage class that wants
to have longer lines than the original when fixing things up.

Needs more work; results in double-frees.

* nd/columns (2012-03-13) 12 commits
 - column: support grouping entries
 - column: support "denser" mode
 - ls-files: support --column
 - tag: add --column
 - column: support piping stdout to external git-column process
 - status: add --column
 - branch: add --column
 - help: reuse print_columns() for help -a
 - column: add dense layout support
 - column: add columnar layout
 - Stop starting pager recursively
 - Add column layout skeleton and git-column

Rerolled again.  Modulo minor nits, looked nicer than the previous round.

* nd/threaded-index-pack (2012-03-11) 2 commits
 - index-pack: support multithreaded delta resolving
 - index-pack: split second pass obj handling into own function

Another reroll after a bugreport on pthread usage discovered by Ramsey,
but it seems the topic is cooking between Ramsay and Duy out of tree.
Waiting for resolution.

* jh/apply-free-patch (2012-03-28) 7 commits
 - apply.c: WIP ownership audit
 - apply: free unused fragments for submodule patch
 - apply: free patch->result
 - apply: release memory for fn_table
 - apply: free patch->{def,old,new}_name fields
 - apply: rename free_patch() to free_patch_list()
 - apply: do not leak patches and fragments

Valgrind reports quite a lot of discarded memory inside apply.  I started
auditing the memory ownership rules in the command, and am almost done.

Will defer til 1.7.10.

* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
 - fixup! 15eaaf4
 - git-svn, perl/Git.pm: extend Git::prompt helper for querying users
 - perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS

The bottom one has been replaced with a rewrite based on comments
from Ævar. The second one needs more work, both in perl/Git.pm and
prompt.c, to give precedence to tty over SSH_ASKPASS when terminal
is available.

* jc/split-blob (2012-04-03) 7 commits
 - chunked-object: streaming checkout
 - chunked-object: fallback checkout codepaths
 - bulk-checkin: support chunked-object encoding
 - bulk-checkin: allow the same data to be multiply hashed
 - new representation types in the packstream
 - packfile: use varint functions
 - varint: make it available outside the context of pack
 (this branch is tangled with jc/index-v4.)

Not ready.

I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.

Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat dissapointed that the original patch series
that was sent almost two months ago still remains here without much
comments and updates from the developer community. I even made the
interface to the logic that decides where to split chunks easily
replaceable, and I deliberately made the logic in the original patch
extremely stupid to entice others, especially the "bup" fanboys, to
come up with a better logic, thinking that giving people an easy
target to shoot for, they may be encouraged to help out. The plan is
not working :-(.

--------------------------------------------------
[Cooking]

* bw/spawn-via-shell-path (2012-04-03) 1 commit
 - Use SHELL_PATH from build system in run_command.c:prepare_shell_cmd

"sh" on the user's PATH may be utterly broken on some systems;
consistently use SHELL_PATH even from inside run-command API.

* jc/commit-unedited-template (2012-04-03) 5 commits
 - Documentation/git-commit: rephrase the "initial-ness" of templates
 - git-commit.txt: clarify -t requires editing message
 - commit: rephrase the error when user did not touch templated log message
 - commit: do not trigger bogus "has templated message edited" check
 - t7501: test the right kind of breakage

When "git commit --template F" errors out because the user did not touch
the message, it claimed that it aborts due to "empty message", which was
utterly wrong.

* jc/push-upstream-sanity (2012-04-03) 2 commits
 - [fixup] remove misguided "try to see if URLs are the same"
 - push: detect nonsense "upstream" check more carefully

"git push $there" without refspec, when the current branch is set to push
to a remote different from $there, used to push to $there using the
upstream information to a remote unreleated to $there.

This is necessary if we were to switch the push.default to 'current'.

* jk/http-backend-keep-committer-ident-env (2012-03-30) 1 commit
 - http-backend: respect existing GIT_COMMITTER_* variables

The smart-http backend used to always override GIT_COMMITTER_* variables
with REMOTE_USER and REMOTE_ADDR.

* mk/gitweb-diff-hl (2012-04-04) 8 commits
 - gitweb: Refinement highlightning in combined diffs
 - gitweb: Highlight interesting parts of diff
 - gitweb: Push formatting diff lines to print_diff_chunk()
 - gitweb: Use print_diff_chunk() for both side-by-side and inline diffs
 - gitweb: Extract print_sidebyside_diff_lines()
 - gitweb: Pass esc_html_hl_regions() options to esc_html()
 - gitweb: esc_html_hl_regions(): Don't create empty <span> elements
 - gitweb: Use descriptive names in esc_html_hl_regions()

* it/fetch-pack-many-refs (2012-04-02) 5 commits
 - remote-curl: main test case for the OS command line overflow
 - fetch-pack: test cases for the new --stdin option
 - fixup? no longer need flex argv[]
 - remote-curl: send the refs to fetch-pack on stdin
 - fetch-pack: new --stdin option to read refs from stdin

Will squash the fix-up one and then requeue.

* jn/debian-customizes-default-editor (2012-03-31) 3 commits
 - fixup? do not hide the "usual" default from readers
 - var doc: advertise current DEFAULT_PAGER and DEFAULT_EDITOR settings
 - var doc: default editor and pager are configurable at build time

Haven't heard anything back for the fix-up suggestion, but otherwise
looked sane.

* rs/commit-list-sort-in-batch (2012-04-02) 3 commits
 - revision: insert unsorted, then sort in prepare_revision_walk()
 - commit: use mergesort() in commit_list_sort_by_date()
 - add mergesort() for linked lists

* hv/submodule-recurse-push (2012-03-30) 3 commits
 - push: teach --recurse-submodules the on-demand option
 - Refactor submodule push check to use string list instead of integer
 - Teach revision walking machinery to walk multiple times sequencially

* dg/subtree (2012-03-25) 112 commits
 - Add 'contrib/subtree/' from commit '2e63f75b8f49abe220ef55ec4e978e7a3b8dc351'
 - Add Subtree Test Makefile
 - Build Subtree
 - Use Project Config Files
 - Remove Unneeded Files
 - ...

A test merge of the 'subtree'.

* jk/branch-quiet (2012-03-26) 2 commits
 - teach "git branch" a --quiet option
 - checkout: suppress tracking message with "-q"

Even with "-q"uiet option, "checkout" used to report setting up tracking.
Also "branch" learns "-q"uiet option to squelch informational message.

* jk/run-command-eacces (2012-04-03) 1 commit
 - run-command: treat inaccessible directories as ENOENT

When PATH contains an unreadable directory, alias expansion code did not
kick in, and failed with an error that said "git-subcmd" was not found.

* jb/am-include (2012-03-28) 1 commit
 - am: support --include option

* jc/am-report-3way (2012-03-28) 1 commit
 - am -3: list the paths that needed 3-way fallback

* rs/combine-diff-zero-context-at-the-beginning (2012-03-25) 1 commit
 - combine-diff: fix loop index underflow

Fixes an age old corner case bug in combine diff (only triggered with -U0
and the hunk at the beginning of the file needs to be shown).

* sl/autoconf (2012-03-26) 3 commits
 - configure: be more idiomatic
 - configure: avoid some code repetitions thanks to m4_{push,pop}def
 - configure: move definitions of private m4 macros before AC_INIT invocation

Updates our configure.ac to follow a better "autoconf" style.

* wk/gitweb-snapshot-use-if-modified-since (2012-03-30) 3 commits
 - gitweb: add If-Modified-Since handling to git_snapshot().
 - gitweb: refactor If-Modified-Since handling
 - gitweb: add `status` headers to git_feed() responses.

Makes 'snapshot' request to "gitweb" honor If-Modified-Since: header,
based on the commit date.

* jk/diff-no-rename-empty (2012-03-23) 4 commits
 - merge-recursive: don't detect renames of empty files
 - teach diffcore-rename to optionally ignore empty content
 - make is_empty_blob_sha1 available everywhere
 - drop casts from users EMPTY_TREE_SHA1_BIN

Forbids rename detection logic from matching two empty files as renames
during merge-recursive to prevent mismerges.

* th/difftool-diffall (2012-04-04) 8 commits
 - difftool: print list of valid tools with '--tool-help'
 - difftool: teach difftool to handle directory diffs
 - difftool: eliminate setup_environment function
 - difftool: stop appending '.exe' to git
 - difftool: remove explicit change of PATH
 - difftool: exit(0) when usage is printed
 - difftool: add '--no-gui' option
 - difftool: parse options using Getopt::Long

Rolls the two-directory-diff logic from diffall script (in contrib/) into
"git difftool" framework. 

* jc/maint-clean-nested-worktree-in-subdir (2012-03-15) 2 commits
  (merged to 'next' on 2012-03-20 at fb5485e)
 + clean: preserve nested git worktree in subdirectories
 + remove_dir_recursively(): Add flag for skipping removal of toplevel dir
 (this branch is tangled with jh/notes-merge-in-git-dir-worktree.)

"git clean -d -f" (not "-d -f -f") is supposed to protect nested working
trees of independent git repositories that exist in the current project
working tree from getting removed, but the protection applied only to such
working trees that are at the top-level of the current project by mistake.

Not urgent.

* ct/advise-push-default (2012-03-26) 2 commits
  (merged to 'next' on 2012-03-28 at 62764ae)
 + clean up struct ref's nonfastforward field
 + push: Provide situational hints for non-fast-forward errors

Breaks down the cases in which "git push" fails due to non-ff into three
categories, and gives separate advise messages.  This should be a good
change regardless of mm/push-default-switch-warning topic.

* nl/rebase-i-cheat-sheet (2012-03-20) 1 commit
  (merged to 'next' on 2012-03-20 at 3092a2b)
 + rebase -i: remind that the lines are top-to-bottom

Not urgent.

* da/difftool-test (2012-03-19) 1 commit
  (merged to 'next' on 2012-03-20 at 0ada7d4)
 + t7800: Test difftool passing arguments to diff

Makes sure "difftool" options can be given in any order.

* jh/notes-merge-in-git-dir-worktree (2012-03-15) 4 commits
  (merged to 'next' on 2012-03-20 at 0c1b1de)
 + notes-merge: Don't remove .git/NOTES_MERGE_WORKTREE; it may be the user's cwd
 + notes-merge: use opendir/readdir instead of using read_directory()
 + t3310: illustrate failure to "notes merge --commit" inside $GIT_DIR/
 + remove_dir_recursively(): Add flag for skipping removal of toplevel dir
 (this branch is tangled with jc/maint-clean-nested-worktree-in-subdir.)

Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/.  When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.

Not urgent.

* jn/diffstat-tests (2012-03-13) 7 commits
  (merged to 'next' on 2012-03-20 at 8791b2f)
 + diffstat summary line varies by locale: miscellany
 + test: use numstat instead of diffstat in binary-diff test
 + test: use --numstat instead of --stat in "git stash show" tests
 + test: test cherry-pick functionality and output separately
 + test: modernize funny-names test style
 + test: use numstat instead of diffstat in funny-names test
 + test: use test_i18ncmp when checking --stat output

Some tests checked the "diff --stat" output when they do not have to,
which unnecessarily made things harder to verify under GETTEXT_POISON.

Not urgent.

* tr/maint-word-diff-regex-sticky (2012-03-14) 3 commits
  (merged to 'next' on 2012-03-20 at b3f67cd)
 + diff: tweak a _copy_ of diff_options with word-diff
 + diff: refactor the word-diff setup from builtin_diff_cmd
 + t4034: diff.*.wordregex should not be "sticky" in --word-diff

The regexp configured with wordregex was incorrectly reused across
files.
Not urgent.

* zj/test-cred-helper-nicer-prove (2012-03-15) 2 commits
  (merged to 'next' on 2012-03-20 at b675ec1)
 + t0303: resurrect commit message as test documentation
 + t0303: immediately bail out w/o GIT_TEST_CREDENTIAL_HELPER

Minor improvement to t0303.
Not urgent.

* jc/commit-hook-authorship (2012-03-11) 3 commits
  (merged to 'next' on 2012-03-12 at 05ca7f8)
 + commit: pass author/committer info to hooks
 + t7503: does pre-commit-hook learn authorship?
 + ident.c: add split_ident_line() to parse formatted ident line
 (this branch is tangled with jc/run-hook-env-1.)

"git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do so
when the end user overrode the authorship via the "GIT_AUTHOR_NAME"
environment variable.  This is a simpler of the two approaches.

Will defer til 1.7.10.

* jc/run-hook-env-1 (2012-03-11) 3 commits
 - run_hook(): enhance the interface to pass arbitrary environment
 + t7503: does pre-commit-hook learn authorship?
 + ident.c: add split_ident_line() to parse formatted ident line
 (this branch is tangled with jc/commit-hook-authorship.)

Not urgent.

Updates run_hook() API to be much less specific to "commit".  It would
only be useful if people start doing more interesting things with hooks.

* jc/diff-algo-cleanup (2012-02-19) 2 commits
  (merged to 'next' on 2012-03-15 at cca0032)
 + xdiff: PATIENCE/HISTOGRAM are not independent option bits
 + xdiff: remove XDL_PATCH_* macros

Resurrects the preparatory clean-up patches from another topic that was
discarded, as this would give a saner foundation to build on diff.algo
configuration option series.

Not urgent.

* rs/unpack-trees-leakfix (2012-03-06) 1 commit
  (merged to 'next' on 2012-03-07 at 69a69cd)
 + unpack-trees: plug minor memory leak

Will defer til 1.7.10.

* mm/push-default-switch-warning (2012-03-09) 1 commit
  (merged to 'next' on 2012-03-28 at 074b16b)
 + push: start warning upcoming default change for push.default

Not urgent.

This resurrects an ancient patch I wrote during a discussion we had in the
1.6.3-1.6.4 era.  This should probably come after ct/advise-push-default
topic and at that point the advise messages need to be rephrased, taking
the future default change into account.

* jc/fmt-merge-msg-people (2012-03-13) 1 commit
 - fmt-merge-msg: show those involved in a merged series

The "fmt-merge-msg" command learns to list the primary contributors
involved in the side topic you are merging.

Will defer til 1.7.10.

* nl/http-proxy-more (2012-03-15) 5 commits
  (merged to 'next' on 2012-03-20 at c004001)
 + http: rename HTTP_REAUTH to HTTP_AUTH_RETRY
 + http: Avoid limit of retrying request only twice
 + http: handle proxy authentication failure (error 407)
 + http: handle proxy proactive authentication
 + http: try http_proxy env var when http.proxy config option is not set

The code to talk to http proxies learn to use the same credential
API used to talk to the final http destinations.

Will defer til 1.7.10.

* nd/stream-more (2012-03-07) 7 commits
  (merged to 'next' on 2012-03-07 at 7325922)
 + update-server-info: respect core.bigfilethreshold
 + fsck: use streaming API for writing lost-found blobs
 + show: use streaming API for showing blobs
 + parse_object: avoid putting whole blob in core
 + cat-file: use streaming API to print blobs
 + Add more large blob test cases
 + streaming: make streaming-write-entry to be more reusable

Use API to read blob data in smaller chunks in more places to
reduce the memory footprint.  In general, looked fairly good.

Will defer til 1.7.10.

--------------------------------------------------
[Discarded]

* tb/maint-remove-irrelevant-i18n-test (2012-03-06) 1 commit
  (merged to 'next' on 2012-03-07 at 23f2dd1)
 + t0204: remove a test that checks undefined behaviour

I tentatively parked this in 'next' but later reverted the merge.

* dg/test-from-elsewhere (2012-03-04) 2 commits
 . Support out-of-tree Valgrind tests
 . Allow overriding GIT_BUILD_DIR

No immediate need; dropped.

Re: What's cooking in git.git (Apr 2012, #02; Wed, 4)

[Jeff King]

On Wed, Apr 04, 2012 at 04:26:39PM -0700, Junio C Hamano wrote:

> * jc/push-upstream-sanity (2012-04-03) 2 commits
>  - [fixup] remove misguided "try to see if URLs are the same"
>  - push: detect nonsense "upstream" check more carefully
> 
> "git push $there" without refspec, when the current branch is set to push
> to a remote different from $there, used to push to $there using the
> upstream information to a remote unreleated to $there.

The patch produced by squashing those together looks good to me.  Though
it might be worth getting input from people who use "upstream" (whether
it becomes the default or not) by re-posting the final patch under a
more obvious subject.

> This is necessary if we were to switch the push.default to 'current'.

I assume you meant "upstream" here.

-Peff

[PATCH] push: error out when the "upstream" semantics does not make sense

[Junio C Hamano]

The user can say "git push" without specifying any refspec.  When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.

However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:

 - The current branch does not have branch.$name.remote configured.  By
   definition, "git push" that does not name where to push to will not
   know where to push to.  The user may explicitly say "git push $there",
   but again, by definition, no branch at repository $there is set to
   integrate with the current branch in this case and we wouldn't know
   which remote branch to update.

 - The current branch does have branch.$name.remote configured, but it
   does not specify branch.$name.merge that names what branch at the
   remote this branch integrates with. "git push" knows where to push in
   this case (or the user may explicitly say "git push $remote" to tell us
   where to push), but we do not know which remote branch to update.

 - The current branch does have its remote and upstream branch configured,
   but the user said "git push $there", where $there is not the remote
   named by "branch.$name.remote".  By definition, no branch at repository
   $there is set to integrate with the current branch in this case, and
   this push is not meant to update any branch at the remote repository
   $there.

The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Jeff King <peff@peff.net> writes:

> The patch produced by squashing those together looks good to me.  Though
> it might be worth getting input from people who use "upstream" (whether
> it becomes the default or not) by re-posting the final patch under a
> more obvious subject.

One obvious glitch that used to make "upstream" an unsuitable default for
beginners is down. Any others?

 builtin/push.c          |   25 +++++++++++++++-------
 t/t5528-push-default.sh |   54 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+), 8 deletions(-)
 create mode 100755 t/t5528-push-default.sh

diff --git a/builtin/push.c b/builtin/push.c
index d315475..765b19c 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -65,6 +65,16 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }
 
+static int push_url_of_remote(struct remote *remote, const char ***url_p)
+{
+	if (remote->pushurl_nr) {
+		*url_p = remote->pushurl;
+		return remote->pushurl_nr;
+	}
+	*url_p = remote->url;
+	return remote->url_nr;
+}
+
 static void setup_push_upstream(struct remote *remote)
 {
 	struct strbuf refspec = STRBUF_INIT;
@@ -76,7 +86,7 @@ static void setup_push_upstream(struct remote *remote)
 		    "\n"
 		    "    git push %s HEAD:<name-of-remote-branch>\n"),
 		    remote->name);
-	if (!branch->merge_nr || !branch->merge)
+	if (!branch->merge_nr || !branch->merge || !branch->remote_name)
 		die(_("The current branch %s has no upstream branch.\n"
 		    "To push the current branch and set the remote as upstream, use\n"
 		    "\n"
@@ -87,6 +97,11 @@ static void setup_push_upstream(struct remote *remote)
 	if (branch->merge_nr != 1)
 		die(_("The current branch %s has multiple upstream branches, "
 		    "refusing to push."), branch->name);
+	if (strcmp(branch->remote_name, remote->name))
+		die(_("You are pushing to remote '%s', which is not the "
+		      "upstream of your\ncurrent branch '%s'.\n"),
+		    remote->name, branch->name);
+
 	strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src);
 	add_refspec(refspec.buf);
 }
@@ -196,13 +211,7 @@ static int do_push(const char *repo, int flags)
 			setup_default_push_refspecs(remote);
 	}
 	errs = 0;
-	if (remote->pushurl_nr) {
-		url = remote->pushurl;
-		url_nr = remote->pushurl_nr;
-	} else {
-		url = remote->url;
-		url_nr = remote->url_nr;
-	}
+	url_nr = push_url_of_remote(remote, &url);
 	if (url_nr) {
 		for (i = 0; i < url_nr; i++) {
 			struct transport *transport =
diff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh
new file mode 100755
index 0000000..c334c51
--- /dev/null
+++ b/t/t5528-push-default.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='check various push.default settings'
+. ./test-lib.sh
+
+test_expect_success 'setup bare remotes' '
+	git init --bare repo1 &&
+	git remote add parent1 repo1 &&
+	git init --bare repo2 &&
+	git remote add parent2 repo2 &&
+	test_commit one &&
+	git push parent1 HEAD &&
+	git push parent2 HEAD
+'
+
+test_expect_success '"upstream" pushes to configured upstream' '
+	git checkout master &&
+	test_config branch.master.remote parent1 &&
+	test_config branch.master.merge refs/heads/foo &&
+	test_config push.default upstream &&
+	test_commit two &&
+	git push &&
+	echo two >expect &&
+	git --git-dir=repo1 log -1 --format=%s foo >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success '"upstream" does not push on unconfigured remote' '
+	git checkout master &&
+	test_unconfig branch.master.remote &&
+	test_config push.default upstream &&
+	test_commit three &&
+	test_must_fail git push
+'
+
+test_expect_success '"upstream" does not push on unconfigured branch' '
+	git checkout master &&
+	test_config branch.master.remote parent1 &&
+	test_unconfig branch.master.merge &&
+	test_config push.default upstream
+	test_commit four &&
+	test_must_fail git push
+'
+
+test_expect_success '"upstream" does not push when remotes do not match' '
+	git checkout master &&
+	test_config branch.master.remote parent1 &&
+	test_config branch.master.merge refs/heads/foo &&
+	test_config push.default upstream &&
+	test_commit five &&
+	test_must_fail git push parent2
+'
+
+test_done
-- 
1.7.10.rc4.54.g1d5dd3

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Jonathan Nieder]

Junio C Hamano wrote:

> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -65,6 +65,16 @@ static void set_refspecs(const char **refs, int nr)
[...]
> @@ -87,6 +97,11 @@ static void setup_push_upstream(struct remote *remote)
>  	if (branch->merge_nr != 1)
>  		die(_("The current branch %s has multiple upstream branches, "
>  		    "refusing to push."), branch->name);
> +	if (strcmp(branch->remote_name, remote->name))
> +		die(_("You are pushing to remote '%s', which is not the "
> +		      "upstream of your\ncurrent branch '%s'.\n"),
> +		    remote->name, branch->name);
> +

I worry that a beginner seeing this message would think it means that
when "master" is set up to track origin/master that there is no way to
push that branch to any other repository.

Maybe something like

		die(_(
"You are pushing to remote '%s', which is not the upstream of your\n"
"current branch '%s', without specifying a refspec.\n"),
		    remote->name, branch->name);

would be harder to misunderstand.

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> I worry that a beginner seeing this message would think it means that
> when "master" is set up to track origin/master that there is no way to
> push that branch to any other repository.
>
> Maybe something like
>
> 		die(_(
> "You are pushing to remote '%s', which is not the upstream of your\n"
> "current branch '%s', without specifying a refspec.\n"),
> 		    remote->name, branch->name);
>
> would be harder to misunderstand.

Perhaps.  Do we need to rephrase it without using the word 'refspec'
(e.g. "without telling me what to push"), or there is no point avoiding
jargon because other jargons (i.e. 'remote' and 'upstream') already appear
in the sentence?

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Jonathan Nieder]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Maybe something like
>>
>> 		die(_(
>> "You are pushing to remote '%s', which is not the upstream of your\n"
>> "current branch '%s', without specifying a refspec.\n"),
>> 		    remote->name, branch->name);
>>
>> would be harder to misunderstand.
>
> Perhaps.  Do we need to rephrase it without using the word 'refspec'
> (e.g. "without telling me what to push"), or there is no point avoiding
> jargon because other jargons (i.e. 'remote' and 'upstream') already appear
> in the sentence?

"without telling me what to push" sounds good.

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I worry that a beginner seeing this message would think it means that
>> when "master" is set up to track origin/master that there is no way to
>> push that branch to any other repository.
>>
>> Maybe something like
>>
>> 		die(_(
>> "You are pushing to remote '%s', which is not the upstream of your\n"
>> "current branch '%s', without specifying a refspec.\n"),
>> 		    remote->name, branch->name);
>>
>> would be harder to misunderstand.
>
> Perhaps.  Do we need to rephrase it without using the word 'refspec'
> (e.g. "without telling me what to push"), or there is no point avoiding
> jargon because other jargons (i.e. 'remote' and 'upstream') already appear
> in the sentence?

How about phrasing it this way?

Note that the short-looking first line (in the context) and the second
line (updated) of the message are very much on purpose, to give '%s'
enough room to expand without overflowing the usual terminal width.

 builtin/push.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/push.c b/builtin/push.c
index 765b19c..7a20036 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -99,7 +99,9 @@ static void setup_push_upstream(struct remote *remote)
 		    "refusing to push."), branch->name);
 	if (strcmp(branch->remote_name, remote->name))
 		die(_("You are pushing to remote '%s', which is not the "
-		      "upstream of your\ncurrent branch '%s'.\n"),
+		      "upstream of your\ncurrent branch '%s',\n"
+		      "without telling me to push which local branch to\n"
+		      " update which remote branch with."),
 		    remote->name, branch->name);
 
 	strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src);

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Jonathan Nieder]

Junio C Hamano wrote:

> How about phrasing it this way?
[
	fatal: You are pushing to remote '%s', which is not the upstream of your
	current branch '%s',
	without telling me to push which local branch to
	 update which remote branch with.
]

I think some words got jumbled a little.  But in that spirit, maybe
here's a start:

	fatal: You are pushing to remote 'somethinglong',
	which is not the upstream of your current branch 'something/very/long',
	without telling me which local branches to use to update which
	remote branches.

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

>  		die(_("You are pushing to remote '%s', which is not the "
> -		      "upstream of your\ncurrent branch '%s'.\n"),
> +		      "upstream of your\ncurrent branch '%s',\n"
> +		      "without telling me to push which local branch to\n"
> +		      " update which remote branch with."),

Sounds overly complex sentence to me. "without telling me what to push"
sounded good enough without being long, so I prefered it.

I like accompanying these messages with the way out for the user, so
perhaps we can add stg like

"To push the current branch to this remote, run:

  git push <remote> <branch>

"

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>  		die(_("You are pushing to remote '%s', which is not the "
>> -		      "upstream of your\ncurrent branch '%s'.\n"),
>> +		      "upstream of your\ncurrent branch '%s',\n"
>> +		      "without telling me to push which local branch to\n"
>> +		      " update which remote branch with."),
>
> Sounds overly complex sentence to me. "without telling me what to push"
> sounded good enough without being long, so I prefered it.

You are right; it is overly complex.

After sending the updated patch, I rewrote it again to:

    You are pushing to remote '%s', which is not the upstream of
    your current branch '%s', without telling me what to push
    to update which remote branch.

The point of Jonathan's 'refspec' and this attempt to rephrase it without
using a jargon is to make sure that the user realizes that both ends can
be specified.

> I like accompanying these messages with the way out for the user, so
> perhaps we can add stg like
>
> "To push the current branch to this remote, run:
>
>   git push <remote> <branch>
>
> "

I am afraid that the above advice is a lot worse than leaving it unsaid.

We are in no position to assume that the user wanted the "current"
semantics when we issue this message.  Otherwise, we would be better off
switching the default semantics to "current", not "upstream".  But the
working assumption in this series is that "upstream" is an improvement
over "current", no?

Re: [PATCH] push: error out when the "upstream" semantics does not make sense

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

>> "To push the current branch to this remote, run:
>>
>>   git push <remote> <branch>
>>
>> "
>
> I am afraid that the above advice is a lot worse than leaving it unsaid.
>
> We are in no position to assume that the user wanted the "current"
> semantics when we issue this message.  Otherwise, we would be better off
> switching the default semantics to "current", not "upstream".  But the
> working assumption in this series is that "upstream" is an improvement
> over "current", no?

I'm not sure. I do support "upstream", but I also think that in many
(most?) cases, the user will want to set "upstream" to point to the
branch with the same name. If there is any confusion between "current"
and "upstream", then avoiding situations where they do something
different is not stupid. This is already what we do when there is no
upstream configured at all:

  $ git push origin
  fatal: The current branch master has no upstream branch.
  To push the current branch and set the remote as upstream, use
  
      git push --set-upstream origin master

OTOH, if the user sees this message, he already has several remotes
configured, and we can probably expect him not to be a total newbie.
Then suggesting

  "git push --set-upstream %s %s:<remote-branch-name>", remote->name, branch->name

would make sense.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/