msysgit 2.1.0 #231
msysgit 2.1.0 #231
Conversation
* maint-1.9: annotate: use argv_array
During "git rebase --merge", a conflicted patch could not be skipped with "--skip" if the next one also conflicted. * bc/fix-rebase-merge-skip: rebase--merge: fix --skip with two conflicts in a row
A handful of code paths had to read the commit object more than once when showing header fields that are usually not parsed. The internal data structure to keep track of the contents of the commit object has been updated to reduce the need for this double-reading, and to allow the caller find the length of the object. * jk/commit-buffer-length: reuse cached commit buffer when parsing signatures commit: record buffer length in cache commit: convert commit->buffer to a slab commit-slab: provide a static initializer use get_commit_buffer everywhere convert logmsg_reencode to get_commit_buffer use get_commit_buffer to avoid duplicate code use get_cached_commit_buffer where appropriate provide helpers to access the commit buffer provide a helper to set the commit buffer provide a helper to free commit buffer sequencer: use logmsg_reencode in get_message logmsg_reencode: return const buffer do not create "struct commit" with xcalloc commit: push commit_index update into alloc_commit_node alloc: include any-object allocations in alloc_report replace dangerous uses of strbuf_attach commit_tree: take a pointer/len pair rather than a const strbuf
Code to avoid adding the same alternate object store twice was subtly broken for a long time, but nobody seems to have noticed. * rs/fix-alt-odb-path-comparison: sha1_file: avoid overrunning alternate object base string
"%G" (nothing after G) is an invalid pretty format specifier, but the parser did not notice it as garbage. * jk/pretty-G-format-fixes: move "%G" format test from t7510 to t6006 pretty: avoid reading past end-of-string with "%G" t7510: check %G* pretty-format output t7510: test a commit signed by an unknown key t7510: use consistent &&-chains in loop t7510: stop referring to master in later tests
"git clone -b brefs/tags/bar" would have mistakenly thought we were following a single tag, even though it was a name of the branch, because it incorrectly used strstr(). * jc/fix-clone-single-starting-at-a-tag: builtin/clone.c: detect a clone starting at a tag correctly
Signed-off-by: Junio C Hamano <[email protected]>
An experiment to use two files (the base file and incremental changes relative to it) to represent the index to reduce I/O cost of rewriting a large index when only small part of the working tree changes. * nd/split-index: (32 commits) t1700: new tests for split-index mode t2104: make sure split index mode is off for the version test read-cache: force split index mode with GIT_TEST_SPLIT_INDEX read-tree: note about dropping split-index mode or index version read-tree: force split-index mode off on --index-output rev-parse: add --shared-index-path to get shared index path update-index --split-index: do not split if $GIT_DIR is read only update-index: new options to enable/disable split index mode split-index: strip pathname of on-disk replaced entries split-index: do not invalidate cache-tree at read time split-index: the reading part split-index: the writing part read-cache: mark updated entries for split index read-cache: save deleted entries in split index read-cache: mark new entries for split index read-cache: split-index mode read-cache: save index SHA-1 after reading entry.c: update cache_changed if refresh_cache is set in checkout_entry() cache-tree: mark istate->cache_changed on prime_cache_tree() cache-tree: mark istate->cache_changed on cache tree update ...
* tb/crlf-tests: t0027: combinations of core.autocrlf, core.eol and text t0025: rename the test files
Teach "git replace" an "--edit" mode. * cc/replace-edit: replace: use argv_array in export_object avoid double close of descriptors handed to run_command replace: replace spaces with tabs in indentation
Teach "git replace --edit" mode a "--raw" option to allow editing the bare-metal representation data of objects. * jk/replace-edit-raw: replace: add a --raw mode for --edit
* ep/submodule-code-cleanup: submodule.c: use the ARRAY_SIZE macro
* jk/strip-suffix: prepare_packed_git_one: refactor duplicate-pack check verify-pack: use strbuf_strip_suffix strbuf: implement strbuf_strip_suffix index-pack: use strip_suffix to avoid magic numbers use strip_suffix instead of ends_with in simple cases replace has_extension with ends_with implement ends_with via strip_suffix add strip_suffix function sha1_file: replace PATH_MAX buffer with strbuf in prepare_packed_git_one()
Merging changes into a file that ends in an incomplete line made the last line into a complete one, even when the other branch did not change anything around the end of file. * mk/merge-incomplete-files: git-merge-file: do not add LF at EOF while applying unrelated change t6023-merge-file.sh: fix and mark as broken invalid tests
"filter-branch" left an empty single-parent commit that results when all parents of a merge commit gets mapped to the same commit, even under "--prune-empty". * cb/filter-branch-prune-empty-degenerate-merges: filter-branch: eliminate duplicate mapped parents
* kb/path-max-must-go: cache.h: rename cache_def_free to cache_def_clear
* mg/fix-log-mergetag-color: log: correctly identify mergetag signature verification status
The "--show-signature" option did not pay much attention to "--graph". * zk/log-graph-showsig: log: fix indentation for --graph --show-signature
* jl/test-lint-scripts: t/Makefile: always test all lint targets when running tests t/Makefile: check helper scripts for non-portable shell commands too
* po/error-message-style: doc: give some guidelines for error messages
One more to an already graduated topic. * jk/skip-prefix: tag: use skip_prefix instead of magic numbers
* rs/code-cleaning: fsck: simplify fsck_commit_buffer() by using commit_list_count() commit: use commit_list_append() instead of duplicating its code merge: simplify merge_trivial() by using commit_list_append() use strbuf_addch for adding single characters use strbuf_addbuf for adding strbufs
An ancient rewrite passed a wrong pointer to a curl library function in a rarely used code path. * ah/fix-http-push: http-push.c: make CURLOPT_IOCTLDATA a usable pointer
Signed-off-by: Junio C Hamano <[email protected]>
* maint: Git 2.0.2 annotate: use argv_array
There is no fchmod() on native Windows platforms (MinGW and MSVC), and the equivalent Win32 API (SetFileInformationByHandle) requires Windows Vista. Use chmod() instead. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Both refs.c and fsck.c have their own private copies of the is_branch function. Delete the is_branch function from fsck.c and make the version in refs.c public. Signed-off-by: Ronnie Sahlberg <[email protected]> Reviewed-by: Jonathan Nieder <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When the `--fork-point` argument was added to `git rebase`, we changed
the value of $upstream to be the fork point instead of the point from
which we want to rebase. When $orig_head..$upstream is empty this does
not change the behaviour, but when there are new changes in the upstream
we are no longer checking if any of them are patch-identical with
changes in $upstream..$orig_head.
Fix this by introducing a new variable to hold the fork point and using
this to restrict the range as an extra (negative) revision argument so
that the set of desired revisions becomes (in fork-point mode):
git rev-list --cherry-pick --right-only \
$upstream...$orig_head ^$fork_point
This allows us to correctly handle the scenario where we have the
following topology:
C --- D --- E <- dev
/
B <- master@{1}
/
o --- B' --- C* --- D* <- master
where:
- B' is a fixed-up version of B that is not patch-identical with B;
- C* and D* are patch-identical to C and D respectively and conflict
textually if applied in the wrong order;
- E depends textually on D.
The correct result of `git rebase master dev` is that B is identified as
the fork-point of dev and master, so that C, D, E are the commits that
need to be replayed onto master; but C and D are patch-identical with C*
and D* and so can be dropped, so that the end result is:
o --- B' --- C* --- D* --- E <- dev
If the fork-point is not identified, then picking B onto a branch
containing B' results in a conflict and if the patch-identical commits
are not correctly identified then picking C onto a branch containing D
(or equivalently D*) results in a conflict.
This change allows us to handle both of these cases, where previously we
either identified the fork-point (with `--fork-point`) but not the
patch-identical commits *or* (with `--no-fork-point`) identified the
patch-identical commits but not the fact that master had been rewritten.
Reported-by: Ted Felix <[email protected]>
Signed-off-by: John Keeping <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Add support for configuring default sort ordering for git tags. Command line option will override this configured value, using the exact same syntax. Cc: Jeff King <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Pretty much one year ago (94b410b, Jul 12 2013, .mailmap: Map email addresses to names) I cleaned up the output of `git shortlog -sne` of git.git by writing a .mailmap file fot the git.git project. During the year Jens, Kazuki and Trần contributed to git.git using different names, but the same email address; unify them. Signed-off-by: Stefan Beller <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This will allow us to work around the push issues pointed out in msysgit#101. Signed-off-by: Johannes Schindelin <[email protected]>
Revert "test: fix t7001 cp to use POSIX options"
…nto thicket-1.8.5.2
Signed-off-by: Johannes Schindelin <[email protected]>
|
Is there anything special to consider when building a new release? It looks like GitHub will just let me upload the installers ([Portable]Git and msysGit-netinstall, built from [1]). Or do we want to wait for mingwGitDevEnv? [1] https://github.com/kblees/msysgit/tree/Git-2.1.0-preview20140816 |
|
MSysGit - the development behind Git for Windows » git #247 FAILURE |
|
I don't think waiting for mingwGitDevEnv makes sense as it still has some way to go and you're basically ready for release. |
Nope, the steps are outlined in https://github.com/msysgit/msysgit/wiki/How-and-when-does-Git-for-Windows-get-released. But you say
so this means interested parties must reestablish symlink support?
Well I'm actually in favour of pushing mingwGitDevEnv into and out of the door. We are currently two major releases behind and this creates some momentum which we should exploit. Updating master and creating a new release from it are two different things though. |
I agree. There are a couple of things that need to be done (and I am guilty to be sidetracked by a move and professional issues, as well as overspending on my Windows Azure account, essentially killing my VM for three weeks). I guess the most important things would be:
Once we have that, we can start addressing the test failures (if any are left) and make concrete plans to switch over, and retire Thoughts? |
|
Well, my plans about mingwGitDevEnv were / are like
|
It is up and running, and yes, it should not run out of credits again. You should be able to log in with the credentials I sent you.
Ah, I understand what you want to do now. For starters, I thought it might be easier to have one installer for both, and offer Git for Windows via an "update site" for In the long run, I am a total fan of the idea to move the |
While it maybe would be easier for us to implement, I believe it would be more confusing for the Git for Windows user if we had such a "combined" installer. With all the confusion we had with msysgit vs. Git for Windows, I want to separate them as clearly as possible. |
One effect of checking the remote helper status is that SPI exit codes no longer bubble up to the porcelain layer - so we shouldn't test for this. Signed-off-by: Karsten Blees <[email protected]>
|
MSysGit - the development behind Git for Windows » git #248 SUCCESS |
|
A few comments from my side:
@dscho Do you give public access to the jenkins in the VM? |
Seems that I did all that, except for the 'upload' and 'mail' part. The buildhive failure was in t5801, so it won't affect the installers I built this morning.
I wouldn't call it 'reestablish', but basically, yes. I was contempt with the assertion in PR #172 that the patch series wouldn't affect users that don't use symlinks, but this is unfortunately not the case. The patch series adds a lot of unnecessary clutter and quite a few obvious bugs. Just to give an example: creating a hardlink now silently overwrites existing files, instead of failing with EEXISTS. There's no reason given why this is necessary or why it is related to symlinks.
On the other hand, releasing 2.x with mingwGitDevEnv creates a lot of pressure, and trying to rush things is prone to errors. The first 2.x release will sure see a lot of hits, and releasing a broken version due to a 'not quite ready' build environment will not exactly inspire confidence in Git...perhaps its smarter to switch to mingwGitDevEnv "When Its Done", preferably in a point-release? Anyways...I'm ready to upload if you change your mind. |
I like it!
Once it is secured, yes. I did not manage to do that yet (I failed to make it accessible via HTTPS only), but @sschuberth is helping me. Once that is done, I will be glad to make it publicly viewable, and of course you will have your account.
Sorry, I missed that! @frogonwheels are you reading this?
I like the former, but not so much the latter. The more we focus on getting stuff done before switching, the less likely we will be able to spend any effort on the switch altogether. And the current development environment just screeches with problems (see e.g. the SSH speed that was just fixed, and that would have been addressed by the switch, but now we put work into upgrading SSH and then into fixing git svn, all distractions!). |
That's a good point of course...I think there's a bit of MSYS-Unicode work for me, too :-) |
|
Hi, yes, I've just picked up on this.
Damn. This is obviously disturbing, I really believed that I had it pretty stable. I'd seen some fixes especially wrt to long names. I initially had done one change that moved away from a static buffer and it was put aside as not being relevant to the patchset, so I didn't follow on carefully enough with that. I guess I'll have to try again with this and address issues like this hardlink problem (and tbh, I really didn't mess around with hardlinks, so maybe I could just fail with hardlink attempts). |
I'll rebuild and address the test failures. I spent a lot of time getting the tests to go through. One big problem is the issue with dangling symlinks not supported by msys (in Are the long-path support breakages addressed by the tests? Is there a test the shows this issue with creating hard-links? I don't even have a clue where this happens, or why it happens. |
|
Ok, so WRT to symlinks and 'don't break anything' I'm starting by cherry-picking the first 3 commits that add the symlink feature and checking out the resultant breakages in the tests. The first I find is a t0000-basic, and it appears it's the fault of the test. it uses |
|
Right - I've found the problem; it's that for some reason which I'm yet to find out, with the new branch core.symlinks is now behaving with default to true (which is the normal default for git elsewhere). With that enabled, it screws over all the faking that status does to pretend that the filesystem says symlink when it's really not. Sooo, I made a change for the test to set a global config of core.symlinks=false, and to allow for me to set it to true. This causes a few problems, seeing as the system config is disabled, and the HOME directory is the trash directory where the default If somebody could give me steps to reproduce the hardlink problem, I'll fix that (and add a test for it). With the core.symlinks thing out of the way, there doesn't appear to be any issues with status and long filenames, again unless there's something I'm missing. |
Rebasing merge to Git v2.1.0
Rebasing merge to Git v2.1.0
Rebasing merge to Git v2.1.0
I just did a merging-rebase to the newly released v2.1.0. The test suite ran without failures. And with all the Unicode patches out of the way (thanks to Stepan), the history looks really neat and simple.
Notable changes to current master:
Here's what I did to the rebase script to get there: