SubmittingPatches: final submission is To: maintainer and CC: list

In an earlier part there is:

  "re-send it with "To:" set to the maintainer [*1*] and "cc:" the list [*2*]"

for the final submission, but later we see

  "Send it to the list and cc the maintainer."

Fix the later one to match the previous.

Signed-off-by: Slavomir Vlcek <svlc@inventati.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin: move builtin retrieval to get_builtin()

There was a redundant code for a builtin command retrieval in
'handle_builtin()' and 'is_builtin()'.

Introduce a new function 'get_builtin()' and using it from
both of these places to reduce the redundancy.

Signed-off-by: Slavomir Vlcek <svlc@inventati.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5705: the file:// URL should be absolute

The test misused a URL "file://." to mean "relative to here",
which we no longer accept.

In a file:// URL, typically there is no host, and RFC1738 says that
file:///<path> should be used.

Update t5705 to use a working URL.

Reported-by: Michael Blume <blume.mike@gmail.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gittutorial: fix output of 'git status'

'git status' doesn't output leading '#'s these days.

Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add another option for receive.denyCurrentBranch

When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the user's password).

The common workaround – pushing into a temporary branch and then merging
on the other machine – is no longer necessary with this patch.

The new option is:

'updateInstead':
	Update the working tree accordingly, but refuse to do so if there
	are any uncommitted changes.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pass TIME_DATE_NOW to approxidate future-check

The approxidate functions accept an extra "now" parameter to
avoid calling time() themselves. We use this in our test
suite to make sure we have a consistent time for computing
relative dates. However, deep in the bowels of approxidate,
we also call time() to check whether possible dates are far
in the future. Let's make sure that the "now" override makes
it to that spot, too, so we can consistently test that
feature.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout $tree: do not throw away unchanged index entries

When we "git checkout $tree", we pull paths from $tree into
the index, and then check the resulting entries out to the
worktree. Our method for the first step is rather
heavy-handed, though; it clobbers the entire existing index
entry, even if the content is the same. This means we lose
our stat information, leading checkout_entry to later
rewrite the entire file with identical content.

Instead, let's see if we have the identical entry already in
the index, in which case we leave it in place. That lets
checkout_entry do the right thing. Our tests cover two
interesting cases:

  1. We make sure that a file which has no changes is not
     rewritten.

  2. We make sure that we do update a file that is unchanged
     in the index (versus $tree), but has working tree
     changes. We keep the old index entry, and
     checkout_entry is able to realize that our stat
     information is out of date.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/checkout-from-tree' into jch

* jk/checkout-from-tree:
  checkout $tree: do not throw away unchanged index entries
approxidate: allow ISO-like dates far in the future

When we are parsing approxidate strings and we find three
numbers separate by one of ":/-.", we guess that it may be a
date. We feed the numbers to match_multi_number, which
checks whether it makes sense as a date in various orderings
(e.g., dd/mm/yy or mm/dd/yy, etc).

One of the checks we do is to see whether it is a date more
than 10 days in the future. This was added in 38035cf (date
parsing: be friendlier to our European friends.,
2006-04-05), and lets us guess that if it is currently April
2014, then "10/03/2014" is probably March 10th, not October
3rd.

This has a downside, though; if you want to be overly
generous with your "--until" date specification, we may
wrongly parse "2014-12-01" as "2014-01-12" (because the
latter is an in-the-past date). If the year is a future year
(i.e., both are future dates), it gets even weirder. Due to
the vagaries of approxidate, months _after_ the current date
(no matter the year) get flipped, but ones before do not.

This patch drops the "in the future" check for dates of this
form, letting us treat them always as yyyy-mm-dd, even if
they are in the future. This does not affect the normal
dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path
only kicks in when the first number is greater than 70
(i.e., it must be a year, and cannot be either a date or a
month).

The one possible casualty is that "yyyy-dd-mm" is less
likely to be chosen over "yyyy-mm-dd". That's probably OK,
though because:

  1. The difference happens only when the date is in the
     future. Already we prefer yyyy-mm-dd for dates in the
     past.

  2. It's unclear whether anybody even uses yyyy-dd-mm
     regularly. It does not appear in lists of common date
     formats in Wikipedia[1,2].

  3. Even if (2) is wrong, it is better to prefer ISO-like
     dates, as that is consistent with what we use elsewhere
     in git.

[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
[2] http://en.wikipedia.org/wiki/Calendar_date

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tb/no-relative-file-url' into jch

* tb/no-relative-file-url:
  t5705: the file:// URL should be absolute
Merge branch 'sn/tutorial-status-output-example' into jch

* sn/tutorial-status-output-example:
  gittutorial: fix output of 'git status'
Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into jch

* jk/approxidate-avoid-y-d-m-over-future-dates:
  approxidate: allow ISO-like dates far in the future
  pass TIME_DATE_NOW to approxidate future-check
Merge branch 'rs/ref-transaction-rename' into pu

Reviews and comments?

* rs/ref-transaction-rename:
  refs.c: add an err argument to pack_refs
  refs.c: make lock_packed_refs take an err argument
  refs.c: make add_packed_ref return an error instead of calling die
  refs.c: replace the onerr argument in update_ref with a strbuf err
  refs.c: make the *_packed_refs functions static
  refs.c: make repack_without_refs static
  remote.c: use a transaction for deleting refs
  refs.c: write updates to packed refs when a transaction has more than one ref
  refs.c: move reflog updates into its own function
  refs.c: rollback the lockfile before we die() in repack_without_refs
  refs.c: update rename_ref to use a transaction
  refs.c: add transaction support for renaming a reflog
  refs.c: use a stringlist for repack_without_refs
  refs.c: use packed refs when deleting refs during a transaction
  refs.c: return error instead of dying when locking fails during transaction
  refs.c: allow passing raw git_committer_info as email to _update_reflog
Merge branch 'rs/ref-transaction-send-pack' into pu

Reviews and comments?

* rs/ref-transaction-send-pack:
  refs.c: add an err argument to create_symref
  refs.c: add an err argument to create_reflog
  t5543-atomic-push.sh: add basic tests for atomic pushes
  push.c: add an --atomic-push argument
  receive-pack.c: use a single transaction when atomic-push is negotiated
  send-pack.c: add an --atomic-push command line argument
  receive-pack.c: add protocol support to negotiate atomic-push
Merge branch 'jc/push-cert-hmac-optim' into pu

This is "we could do this if we wanted to", not "we measured and it
improves performance critical codepath".

* jc/push-cert-hmac-optim:
  receive-pack: truncate hmac early and convert only necessary bytes
  sha1_to_hex: split out "hex-format n bytes" helper and use it
Merge branch 'tr/remerge-diff' into pu

"log -p" output learns a new way to let users inspect a merge
commit by showing the differences between the automerged result
with conflicts the person who recorded the merge would have seen
and the final conflict resolution that was recorded in the merge.

* tr/remerge-diff:
  t4213: avoid "|" in sed regexp
  log --remerge-diff: show what the conflict resolution changed
  name-hash: allow dir hashing even when !ignore_case
  merge-recursive: allow storing conflict hunks in index
  merge_diff_mode: fold all merge diff variants into an enum
  combine-diff: do not pass revs->dense_combined_merges redundantly
  merge-recursive: -Xindex-only to leave worktree unchanged
  merge-recursive: internal flag to avoid touching the worktree
  merge-recursive: remove dead conditional in update_stages()
Merge branch 'mt/patch-id-stable' into pu

Teaches "git patch-id" to compute the patch ID that does not change
when the files in a single patch is reordered. As this new algorithm
is backward incompatible, the last bit to flip it to be the default
is left out of 'master' for now.

Nobody seems to be jumping up & down requesting this last step,
which makes the result somewhat backward incompatible.

* mt/patch-id-stable:
  patch-id: change default to stable
Merge branch 'jk/pack-bitmap' into pu

Hold, waiting for Karsten's replacement.

* jk/pack-bitmap:
  pack-bitmap: do not use gcc packed attribute
Merge branch 'bg/rebase-off-of-previous-branch' into pu

Teach "git rebase -" to report the concrete name of the branch
(i.e. the previous one).

But it stops short and does not do the same for "git rebase @{-1}".

* bg/rebase-off-of-previous-branch:
  git-rebase: print name of rev when using shorthand
Merge branch 'rb/merge-prepare-commit-msg-hook' into pu

Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
run during "git merge".  The log message stresses too much on one
hook, prepare-commit-msg, but it would equally apply to other hooks
like post-merge, I think.

* rb/merge-prepare-commit-msg-hook:
  merge: drop unused arg from abort_commit method signature
  merge: make prepare_to_commit responsible for write_merge_state
  t7505: ensure cleanup after hook blocks merge
  t7505: add missing &&