Skip to content
This repository was archived by the owner on Nov 9, 2017. It is now read-only.

Merge with git 1.9.2 #157

Closed
wants to merge 113 commits into from
Closed

Merge with git 1.9.2 #157

wants to merge 113 commits into from

Conversation

kasal
Copy link
Member

@kasal kasal commented Apr 10, 2014

Hello,
I tried to build msysgit 1.9.2 and it seemed to be very easy. I did "git merge v1.9.2" and there was one trivial merge conflict. The test suite is ok until 7407. There was a fail in 7407, but it did not reproduce on subsequent runs. But while I was at it, I noticed that part of @dscho's workaround there is not (no longer?) necessary.

(The only CR problem seems to come from running echo from within git; I guess it runs cmd.exe echo, not sh echo.)

Back to original subject: what is the right way to create v1.9.2.msysgit?

I also tried git rebase -i --autosquash --onto v1.9.2 v1.9.0
I took ages and created script that contained ~5800 commits; does that make sense?
Or should the rebase be called with --preserve-merges?

I'll be grateful for any explanations, though I suspect this may not be the best place for this discussion.
Stepan

peff and others added 30 commits January 28, 2014 11:59
We explicitly check for and handle the case that the
incoming "path" variable is NULL, but before doing so we
call strchrnul on it, leading to a potential segfault.

We can fix this simply by moving the strchrnul call down; as
a bonus, we can tighten the scope on the associated
variable.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
When we see config like:

  [include]
  path

the expand_user_path helper notices that the config value is
empty, but we then dereference NULL while printing the error
message (glibc will helpfully print "(null)" for us here,
but we cannot rely on that).

  $ git -c include.path rev-parse
  error: Could not expand include path '(null)'
  fatal: unable to parse command-line config

Instead of tweaking our message, let's actually use
config_error_nonbool to match other config variables that
expect a value:

  $ git -c include.path rev-parse
  error: Missing value for 'include.path'
  fatal: unable to parse command-line config

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
The --prefix, --default, and --resolve-git-dir options to
git-rev-parse require an argument, but when given no argument,
the code uses the NULL read from argv[argc] without checking,
leading to a segfault.

Instead, check first and die() with an error message.

Signed-off-by: David Sharp <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Moving to some other directory and letting the remainder of the test
pieces to expect that they start there is a bad practice.  The test
that contains chdir itself may fail (or by mistake skipped via the
GIT_SKIP_TESTS mechanism) in which case the remainder may operate on
files in unexpected places.

Signed-off-by: Junio C Hamano <[email protected]>
Lasse Makholm noticed that running "git check-attr" from a place
totally unrelated to $GIT_DIR and $GIT_WORK_TREE does not give
expected results.  I think it is because the command does not say it
wants to call setup_work_tree().

We still need to support use cases where only a bare repository is
involved, so unconditionally requiring a working tree would not work
well.  Instead, make a call only in a non-bare repository.

We may want to see if we want to do a similar fix in the opposite
direction to check-ignore.  The command unconditionally requires a
working tree, but it should be usable in a bare repository just like
check-attr attempts to be.

Signed-off-by: Junio C Hamano <[email protected]>
We set the default apache port for each of the httpd tests
to the 4-digit test number of the test script. We want these
to remain unique so that the tests do not conflict with each
other when run in parallel.

Instead of doing it manually in each test script, let's just
set it from the test name at run time. This is simpler, and
is one less thing to be updated when test scripts are
renamed (e.g., when being re-rolled or when conflicting
after being merged with another topic).

Incidentally, this fixes a case where t5537 and t5538 used
the same port number (5537), and could conflict with each
other when run in parallel.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Make clear which one is for dumb protocol, which one is for smart from
their file name.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
It's introduced in 1bd8c8f (git-upload-pack: Support the multi_ack
protocol - 2005-10-28) but probably better documented in the commit
message of 78affc4 (Add multi_ack_detailed capability to
fetch-pack/upload-pack - 2009-10-30).

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
…ocol.txt

pack-protocol.txt explains in detail how multi_ack_detailed works and
what's the difference between no multi_ack, multi_ack and
multi_ack_detailed. No need to repeat here.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
See 3e63b21 (upload-pack: Implement no-done capability - 2011-03-14)
and 761ecf0 (fetch-pack: Implement no-done capability - 2011-03-14)
for more information.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
In smart http, upload-pack adds new shallow lines at the beginning of
each rpc response. Only shallow lines from the first rpc call are
useful. After that they are thrown away. It's designed this way
because upload-pack is stateless and has no idea when its shallow
lines are helpful or not.

So after refs are negotiated with multi_ack_detailed and the server
thinks it learned enough, it sends "ACK obj-id ready", terminates the
rpc call and waits for the final rpc round. The client sends "done".
The server sends another response, which also has shallow lines at
the beginning, and the last "ACK obj-id" line.

When no-done is active, the last round is cut out, the server sends
"ACK obj-id ready" and "ACK obj-id" in the same rpc
response. fetch-pack is updated to recognize this and not send
"done". However it still tries to consume shallow lines, which are
never sent.

Update the code, make sure to skip consuming shallow lines when
no-done is enabled.

Reported-by: Jeff King <[email protected]>
Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
start_httpd is supposed to be at the beginning of the test file, not
the middle of it. The "test_seq" line in "no shallow lines.." test is
updated to compensate missing refs that are there in t5537, but not in
the new t5539.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
The GIT_EXTERNAL_DIFF calling code attempts to reuse existing worktree
files for the worktree side of diffs, for performance reasons.
However, that code also tries to do the same with submodules.  This
results in calls to $GIT_EXTERNAL_DIFF where the old-file is a file of
the form "Submodule commit $sha1", but the new-file is a directory in
the worktree.

Fix it by never reusing a worktree "file" in the submodule case.

Reported-by: Grégory Pakosz <[email protected]>
Signed-off-by: Thomas Rast <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Refreshing index requires work tree.  So we have two options: always
set up work tree (and refuse to reset if failing to do so), or make
refreshing index optional.

As refreshing index is not the main task, it makes more sense to make
it optional. This allows us to still work in a bare repository to update
what is in the index.

Reported-by: Patrick Palka <[email protected]>
Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Modern versions of "git submodule" use .git-files to setup the
submodule directory.  When run in a "git submodule"-created
repository "git difftool --dir-diff" dies with the following
error:

	$ git difftool -d HEAD~
	fatal: This operation must be run in a work tree
	diff --raw --no-abbrev -z HEAD~: command returned error: 128

core.worktree is relative to the .git directory but the logic
in find_worktree() does not account for it.

Use `git rev-parse --show-toplevel` to find the worktree so that
the dir-diff feature works inside a submodule.

Reported-by: Gábor Lipták <[email protected]>
Helped-by: Jens Lehmann <[email protected]>
Helped-by: John Keeping <[email protected]>
Signed-off-by: David Aguilar <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
When t4212 was originally added by 9dbe7c3 (pretty: handle
broken commit headers gracefully, 2013-04-17), it tested our
handling of commits with broken ident lines in which the
timestamps could not be parsed. It does so using a bogus line
like "Name <email>-<> 1234 -0000", because that simulates an
error that was seen in the wild.

Later, 03818a4 (split_ident: parse timestamp from end of
line, 2013-10-14) made our parser smart enough to actually
find the timestamp on such a line, and t4212 was adjusted to
match. While it's nice that we handle this real-world case,
this meant that we were not actually testing the
bogus-timestamp case anymore.

This patch adds a test with a totally incomprehensible
timestamp to make sure we are testing the code path.

Note that the behavior is slightly different between regular log
output and "--format=%ad". In the former case, we produce a
sentinel value and in the latter, we produce an empty
string. While at first this seems unnecessarily
inconsistent, it matches the original behavior given by
9dbe7c3.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
When we check commit objects, we complain if commit->date is
ULONG_MAX, which is an indication that we saw integer
overflow when parsing it. However, we do not do any check at
all for author lines, which also contain a timestamp.

Let's actually check the timestamps on each ident line
with strtoul. This catches both author and committer lines,
and we can get rid of the now-redundant commit->date check.

Note that like the existing check, we compare only against
ULONG_MAX. Now that we are calling strtoul at the site of
the check, we could be slightly more careful and also check
that errno is set to ERANGE. However, this will make further
refactoring in future patches a little harder, and it
doesn't really matter in practice.

For 32-bit systems, one would have to create a commit at the
exact wrong second in 2038. But by the time we get close to
that, all systems will hopefully have moved to 64-bit (and
if they haven't, they have a real problem one second later).

For 64-bit systems, by the time we get close to ULONG_MAX,
all systems will hopefully have been consumed in the fiery
wrath of our expanding Sun.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
When we check whether a timestamp has overflowed, we check
only against ULONG_MAX, meaning that strtoul has overflowed.
However, we also feed these timestamps to system functions
like gmtime, which expect a time_t. On many systems, time_t
is actually smaller than "unsigned long" (e.g., because it
is signed), and we would overflow when using these
functions.  We don't know the actual size or signedness of
time_t, but we can easily check for truncation with a simple
assignment.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
If an ident line has a ridiculous date value like (2^64)+1,
we currently just pass ULONG_MAX along to the date code,
which can produce nonsensical dates.

On systems with a signed long time_t (e.g., 64-bit glibc
systems), this actually doesn't end up too bad. The
ULONG_MAX is converted to -1, we apply the timezone field to
that, and the result ends up somewhere between Dec 31, 1969
and Jan 1, 1970.

However, there is still a few good reasons to detect the
overflow explicitly:

  1. On systems where "unsigned long" is smaller than
     time_t, we get a nonsensical date in the future.

  2. Even where it would produce "Dec 31, 1969", it's easier
     to recognize "midnight Jan 1" as a consistent sentinel
     value for "we could not parse this".

  3.  Values which do not overflow strtoul but do overflow a
      signed time_t produce nonsensical values in the past.
      For example, on a 64-bit system with a signed long
      time_t, a timestamp of 18446744073000000000 produces a
      date in 1947.

We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.

However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting in a segfault. Let's catch this
case and just format t=0.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
The remote we push can be defined either by
remote.pushdefault or by branch.*.pushremote for the current
branch. The order in which they appear in the config file
should not matter to precedence (which should be to prefer
the branch-specific config).

The current code parses the config linearly and uses a
single string to store both values, overwriting any
previous value. Thus, config like:

  [branch "master"]
  pushremote = foo
  [remote]
  pushdefault = bar

erroneously ends up pushing to "bar" from the master branch.

We can fix this by storing both values and resolving the
correct value after all config is read.

Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Sometimes when working with a large repository it can be useful to try
out a merge and only check out conflicting files to disk (for example as
a speed optimization on a server).  Until v1.7.7-rc1~28^2~20
(merge-recursive: When we detect we can skip an update, actually skip
it, 2011-08-11), it was possible to do so with the following idiom:

	# Prepare a temporary index and empty work tree.
	GIT_INDEX_FILE="$PWD/tmp-$$-index" &&
	export GIT_INDEX_FILE &&
	GIT_WORK_TREE="$PWD/tmp-$$-work" &&
	export GIT_WORK_TREE &&
	mkdir "$GIT_WORK_TREE" &&

	# Convince the index that our side is on disk.
	git read-tree -i -m $ours &&
	git update-index --ignore-missing --refresh &&

	# Merge their side into our side.
	bases=$(git merge-base --all $ours $theirs) &&
	git merge-recursive $bases -- $ours $theirs &&
	tree=$(git write-tree)

Nowadays, that still works and the exit status is the same, but
merge-recursive produces a diagnostic if "our" side renamed a file:

	error: addinfo_cache failed for path 'dst'

Add a test to document this regression.

Signed-off-by: Brad King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Move lstat ENOENT handling from refresh_index to refresh_cache_ent and
activate it with a new CE_MATCH_IGNORE_MISSING option.  This will allow
other call paths into refresh_cache_ent to use the feature.

Signed-off-by: Brad King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Convert the make_cache_entry boolean 'refresh' argument to a more
general 'refresh_options' argument.  Pass the value through to the
underlying refresh_cache_ent call.  Add option CE_MATCH_REFRESH to
enable stat refresh.  Update call sites to use the new signature.

Signed-off-by: Brad King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Teach add_cacheinfo to tell make_cache_entry to skip refreshing stat
information when a file is missing from the work tree.  We do not want
the index to be stat-dirty after the merge but also do not want to fail
when a file happens to be missing.

This fixes the 'merge-recursive w/ empty work tree - ours has rename'
case in t3030-merge-recursive.

Suggested-by: Elijah Newren <[email protected]>
Signed-off-by: Brad King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
This helps reduce the number of match_pathspec_depth() call sites and
show how match_pathspec_depth() is used.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
This helps reduce the number of match_pathspec_depth() call sites and
show how m_p_d() is used. And it usage is:

 - match against an index entry (ce_path_match or match_pathspec_depth
   in ls-files)

 - match against a dir_entry from read_directory (dir_path_match and
   match_pathspec_depth in clean.c, which will be converted later)

 - resolve-undo (rerere.c and ls-files.c)

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
A long time ago, for some reason I was not happy with
match_pathspec(). I created a better version, match_pathspec_depth()
that was suppose to replace match_pathspec()
eventually. match_pathspec() has finally been gone since 6 months
ago. Use the shorter name for match_pathspec_depth().

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Currently we do support matching pathspec "foo/" against directory
"foo". That is because match_pathspec() has no way to tell "foo" is a
directory and matching "foo/" against _file_ "foo" is wrong.

The callers can now tell match_pathspec if "foo" is a directory, we
could make an exception for this case. Code is not executed though
because no callers pass the flag yet.

Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
gitster and others added 22 commits April 3, 2014 13:39
* jk/shallow-update-fix:
  shallow: verify shallow file after taking lock
  shallow: automatically clean up shallow tempfiles
  shallow: use stat_validity to check for up-to-date file
* rr/doc-merge-strategies:
  Documentation/merge-strategies: avoid hyphenated commands
* us/printf-not-echo:
  test-lib.sh: do not "echo" caller-supplied strings
  rebase -i: do not "echo" random user-supplied strings
* nd/index-pack-error-message:
  index-pack: report error using the correct variable
* jk/lib-terminal-lazy:
  t/lib-terminal: make TTY a lazy prerequisite
* mh/remove-subtree-long-pathname-fix:
  entry.c: fix possible buffer overflow in remove_subtree()
  checkout_entry(): use the strbuf throughout the function
* jk/mv-submodules-fix:
  mv: prevent mismatched data when ignoring errors.
  builtin/mv: fix out of bounds write

Conflicts:
	t/t7001-mv.sh
Signed-off-by: Junio C Hamano <[email protected]>
* bp/commit-p-editor:
  run-command: mark run_hook_with_custom_index as deprecated
  merge hook tests: fix and update tests
  merge: fix GIT_EDITOR override for commit hook
  commit: fix patch hunk editing with "commit -p -m"
  test patch hunk editing with "commit -p -m"
  merge hook tests: use 'test_must_fail' instead of '!'
  merge hook tests: fix missing '&&' in test
* mm/status-porcelain-format-i18n-fix:
  status: disable translation when --porcelain is used
Signed-off-by: Thomas Ackermann <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
* commit '5df05146d5cb94628a3dfc53063c802ee1152cec':
  doc/http-backend: missing accent grave in literal mark-up
* jc/fix-diff-no-index-diff-opt-parse:
  diff-no-index: correctly diagnose error return from diff_opt_parse()
* jk/commit-dates-parsing-fix:
  t4212: loosen far-in-future test for AIX
  date: recognize bogus FreeBSD gmtime output
* mh/update-ref-batch-create-fix:
  update-ref: fail create operation over stdin if ref already exists
* cn/fetch-prune-overlapping-destination:
  fetch: handle overlaping refspecs on --prune
  fetch: add a failing test for prunning with overlapping refspecs
* jl/nor-or-nand-and:
  code and test: fix misuses of "nor"
  comments: fix misuses of "nor"
  contrib: fix misuses of "nor"
  Documentation: fix misuses of "nor"
The second maintenance release for Git 1.9; contains all the fixes
that are scheduled to appear in Git 2.0.

Signed-off-by: Junio C Hamano <[email protected]>
@dscho
Copy link
Member

dscho commented Apr 10, 2014

The process is unfortunately slightly more involved because we want to keep our topic branches in shape for (eventual, hopefully) contribution upstream.

For that purpose, we use the script /share/msysGit/merging-rebase.sh.

I am in the process of doing that and I already got three merge conflicts: one with the hidden .git directory support, one with stricter transport checking and one with support for dynamic linking to the CRT via MSVC...

@kasal
Copy link
Member Author

kasal commented Apr 10, 2014

Interesting, thank you for the answer.
I'm closing this, creating separate PR for the fix commits.

@kasal kasal closed this Apr 10, 2014
@buildhive
Copy link

MSysGit - the development behind Git for Windows » git #185 SUCCESS
This pull request looks good
(what's this?)

@dscho
Copy link
Member

dscho commented Apr 10, 2014

Aargh. I made a mistake: I called merging-rebase.sh without arguments (it defaults to junio/next, not to "the latest tag pushed by junio")...

@t-b
Copy link

t-b commented Apr 11, 2014

@kasal In https://github.com/msysgit/msysgit/wiki/How-and-when-does-Git-for-Windows-get-released I documented the steps needed to switch to a newer upstream tag.

@kasal
Copy link
Member Author

kasal commented Apr 11, 2014

Wow! @t-b thanks. The test suite now runs really quickly, with all processor cores working on 100%.

@kasal
Copy link
Member Author

kasal commented Apr 11, 2014

@t-b 20 minutes instead of hours, Wow!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.