Pu #1
Open
Pu #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The "rename" and "rm" commands now handle the case where the remote being changed is the default remote. If the "add" command is used to add the repo's first remote, that remote becomes the default remote. Also introduce a "default" sub-command to get or set the default remote: - "git remote default" (with no parameter) displays the current default remote. - "git remote default <remo>" checks if <remo> is a configured remote and if so changes remote.default to <remo>. These changes needed a couple of new helper functions in remote.c: - remote_get_default_name() returns default_remote_name. - remote_count() returns the number of remotes. (The test in t5528 had to be changed because now with push.default=matching a plain "git push" succeeds with "Everything up-to-date". It used to fail with "No configured push destination".) Signed-off-by: Marc Branchaud <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This makes git-clone consistent with the remote.default support implemented in git-remote. Specifically, since "git remote add" sets remote.default if it's adding the first remote to the repository, when clone itself adds the first remote it should do the same. This also makes "git clone -o" work without a special case in the code (so "git clone /some/repo" and "git clone -o origin /some/repo" produce the same result). Signed-off-by: Marc Branchaud <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Marc Branchaud <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Use "git remote default" instead of replicating its logic. The unit test checks a relative-path submodule because the submodule code is (almost) the only thing that uses get_default_remote. Signed-off-by: Marc Branchaud <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When run without "-u" or "-A" option,
$ edit subdir/x
$ create subdir/y
$ rm subdir/z
$ git add subdir/
does not notice removal of paths (e.g. subdir/z) from the working tree.
Make "git add" to pretend as if "-A" is given when there is a pathspec on
the command line. "git add" without any argument continues to be a no-op.
When resolving a conflict to remove a path, the current code tells you to
"git rm $path", but now with this patch you can say "git add $path". Of
course you can do "git add -A $path" without this patch.
In either case, the operation "git add" is about "adding the state of the
path in the working tree to the index". The state may happen to be "path
removed", not "path has an updated content".
The semantic change can be seen by a breakage in t2200, test git#15. There,
a merge has conflicts in path4 and path6 (which are removed from the
working tree), and test checks "git add path4" to resolve it must fail,
and makes sure "add -u" needs to be used. We do not have to do this
anymore.
Signed-off-by: Junio C Hamano <[email protected]>
Just spell it "struct rev_name"; it makes it more clear what is going on. Signed-off-by: Junio C Hamano <[email protected]>
In preparation for later changes, restructure the logic a little bit to separate how the code decides to use the new "tip" for naming a particular commit, and what happens based on the decision. Also re-indent and correct style of this function while we are at it. Signed-off-by: Junio C Hamano <[email protected]>
It finds three commits that has older commit timestamp than the newest commit timestamp among its ancestor in our history; all of these are a direct child of a commit that is older (i.e. the clock skew lasts for only one hop). commit gen timestamp skew gen ancestor ed19f36 2870 2006-03-04 07:29:56 +0000 (8) 2869 91a6bf4 7763987 6404 2007-09-02 06:53:47 +0000 (373) 6403 86bab96 619a644 9982 2009-10-18 19:34:56 +0000 (268948) 9981 46148dd On the other hand, the kernel history is littered with skewed chains. I counted 2239 commits that have an ancestor newer than themselves in total (they tend to cluster, but I haven't counted clusters), among 322345 commits (0.7%). For example, a 33-commit chain leading to b4e1b7e builds on top of 422e6c4 that was commited by Linus at Tue Mar 15 15:48:13 2011, but the tip commit claims to have been committed at Sun Feb 20 19:19:43 2011, which is clearly impossible. Signed-off-by: Junio C Hamano <[email protected]>
Instead of naming a rev always after a tip that is topologically closest, allow the command to use different algorithm when choosing the tip to base the name on. A new algorithm "weight" lets you use the tip that has the smallest number of commits behind it. The semantics "name-rev --algorithm=weight" would give us is closer to what people expect from "describe --contains". Note that this is fairly expensive to compute; a later change in the series will cache the weight value using notes-cache. Signed-off-by: Junio C Hamano <[email protected]>
It often happens that immediately after traversing from v1.2.3 to find out its weight, we are asked to see if another commit v1.2.0 is heavier than that. Because the commits that are reachable from v1.2.3 are painted with the SHOWN flag until the next "rev-list" traversal, we can notice that the new commit v1.2.0 is reachable from v1.2.3 without doing any traversal. We cannot learn exactly how much it weighs, but we can tell it must weigh less than v1.2.3, and that is all that the caller wants to know. In the kernel history, "git name-rev --tags 0136db5" which started this topic needs 26k calls to tip_weight_cmp(). 13k of them are comparisons between tips based on the same ref and answered without computing any weight. Among the remaining 13k, 1.8k comparisons are answered with this trivial "fast-forward" optimization. Signed-off-by: Junio C Hamano <[email protected]>
With the "weight" assigned to tip of each ref, we can give more
intuitive results from "name-rev" that is more suitable to answer
"what is the oldest tag that contains this commit?" However, this
number is very expensive to compute.
Use the notes-cache mechanism to cache this value. The result
becomes usable again.
(priming the cache from scratch)
$ rm .git/refs/notes/name-rev-weight
$ /usr/bin/time git name-rev --algorithm=weight --tags 0136db5
0136db5 tags/v3.5-rc1~83^2~81^2~76
6.06user 0.46system 0:06.54elapsed 99%CPU (0avgtext+0avgdata 1861456maxresident)k
8inputs+16outputs (0major+128576minor)pagefaults 0swaps
(with cache already primed)
$ /usr/bin/time git name-rev --algorithm=weight --tags 0136db5
0136db5 tags/v3.5-rc1~83^2~81^2~76
0.50user 0.22system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 244224maxresident)k
0inputs+0outputs (0major+16062minor)pagefaults 0swaps
(the old "shortest path" version)
$ /usr/bin/time git name-rev --tags 0136db5
0136db5 tags/v3.6-rc1~59^2~56^2~76
0.31user 0.01system 0:00.32elapsed 100%CPU (0avgtext+0avgdata 243488maxresident)k
0inputs+0outputs (0major+16000minor)pagefaults 0swaps
This version does not invalidate the cache in the presense of
modified grafts and object replacement, but in a later version we
can compute a hash of the grafts and replacement data and pass it as
the validity token to automatically invalidate the cache when these
data that affects the perceived topology change.
Signed-off-by: Junio C Hamano <[email protected]>
We are almost there... Signed-off-by: Junio C Hamano <[email protected]>
And this is the logical conclusion of the series, to allow 0136db5 in the kernel history to be described as v3.5-rc1~83^2~81^2~76, not as v3.6-rc1~59^2~56^2~76. Signed-off-by: Junio C Hamano <[email protected]>
Bold yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. Likewise, change the color of the summarized total number of known breakages from bold red to bold yellow to be less alarmist and more consistent with the above. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The old output to say "not ok - 1 messsage" was working by accident only because the test numbers are optional in TAP. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Skipped tests indicate incomplete test coverage. Whilst this is not a test failure or other error, it's still not a complete success. Other testsuite related software like automake, autotest and prove seem to use blue for skipped tests, so let's follow suit. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This will allow us to test the test framework more thoroughly without disrupting the top-level test metrics. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Re-indent to make it readable and then minimally fix the quoting.
Add 5 new full test suite runs each with a different number of passing/failing/broken/fixed tests, in order to ensure that the correct exit code and output are generated in each case. As before, these are run in a subdirectory in order to disrupt the metrics for the parent tests. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Change color of unexpectedly fixed known breakages to bold red. An unexpectedly passing test indicates that the test code is somehow broken or out of sync with the code it is testing. Either way this is an error which is potentially as bad as a failing test, and as such is no longer portrayed as a pass in the output. Signed-off-by: Adam Spiers <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Once you do $ alias glogone git log --follow there is no way to say $ glogone --no-follow ... Not that "log --follow" is all that useful, but it is cheap to support the common "you can defeat an undesirable option with a 'no-' variant of it later on the command line" pattern. Signed-off-by: Junio C Hamano <[email protected]>
If you know your history did not have renames, or if you care only about the history after a large rename that happened some time ago, "git blame --no-follow $path" is a way to tell the command not to bother about renames. When you use -C, the lines that came from the renamed file will still be found without the whole-file rename detection, so it is not all that interesting either way, though. Signed-off-by: Junio C Hamano <[email protected]>
git p4 was moved out of contrib in 1.7.11 but it git-completion didn't know about it. Add git p4 completion based on the existing SVN completion. It covers all known subcommands and options except for the -/ option for clone which doesn't use the standard -- prefix. Signed-off-by: Ryan Cumming <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Running "whatchanged --graph -m" on a simple two-head merges can fall into infinite loop. Signed-off-by: Michał Kiedrowicz <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This is a quick hack to make these functions available for the lua code. It would be way cleaner to move all of the incremental parsing bits to format-commit.[ch] and clean up the names (e.g., "struct chunk" is not nearly descriptive enough for a global). Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This adds a small module for examining parts of a commit from inside a lua interpreter. Eventually you'll be able to do grep-like filtering and --pretty formatting. The most naive presentation would be to parse the whole commit and put it in a lua table. However, instead we build upon the incremental parsing used by the --format parser, and lazily parse bits of the commit as the lua code requests them. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
With this patch, you can do:
git log --pretty=lua:'
return abbrev(hash()) .. " (" .. author().email .. ") " .. subject()
'
Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
…rectory Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '<submodule path>': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
A symbolic ref refs/heads/SYM was not correctly removed with "git branch -d SYM"; the command removed the ref pointed by SYM instead. Will merge to 'master' in the second batch after 1.8.0 ships. * rs/branch-del-symref: branch: show targets of deleted symrefs, not sha1s branch: skip commit checks when deleting symref branches branch: delete symref branch, not its target branch: factor out delete_branch_config() branch: factor out check_branch_commit()
Fixes many rfc2047 quoting issues in the output from format-patch. * js/format-2047: format-patch tests: check quoting/encoding in To: and Cc: headers format-patch: fix rfc2047 address encoding with respect to rfc822 specials format-patch: make rfc2047 encoding more strict format-patch: introduce helper function last_line_length() format-patch: do not wrap rfc2047 encoded headers too late format-patch: do not wrap non-rfc2047 headers too early utf8: fix off-by-one wrapping of text
The --graph code fell into infinite loop when asked to do what the code did not expect ;-) Anybody who worked on "--graph" wants to comment? Stalled mostly due to lack of responses. * mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
Elements of GIT_CEILING_DIRECTORIES list may not match the real pathname we obtain from getcwd(), leading the GIT_DIR discovery logic to escape the ceilings the user thought to have specified. * mh/ceiling: string_list_longest_prefix(): remove function normalize_ceiling_entry(): resolve symlinks longest_ancestor_length(): require prefix list entries to be normalized longest_ancestor_length(): take a string_list argument for prefixes longest_ancestor_length(): use string_list_split() Introduce new function real_path_if_valid() real_path_internal(): add comment explaining use of cwd Introduce new static function real_path_internal()
"git name-rev" names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the "describe --contains" even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Stalled mostly due to lack of responses. * jc/maint-name-rev: describe --contains: use "name-rev --algorithm=weight" name-rev --algorithm=weight: tests and documentation name-rev --algorithm=weight: cache the computed weight in notes name-rev --algorithm=weight: trivial optimization name-rev: --algorithm option name_rev: clarify the logic to assign a new tip-name to a commit name-rev: lose unnecessary typedef Conflicts: builtin/name-rev.c
Teaches "--no-follow" option to "git blame" to disable its whole-file rename detection. Stalled mostly due to lack of responses. * jc/blame-no-follow: blame: pay attention to --no-follow diff: accept --no-follow option
I am unhappy a bit about the possible performance implications of having to store the output in a temporary file only for a rare case of format-patch aborting. * aw/rebase-am-failure-detection: rebase: Handle cases where format-patch fails
Misapplication of a patch fixed; the ones near the tip needs to update the links to point at the html files, though. * ta/doc-cleanup: Documentation/howto: convert plain text files to asciidoc Documentation/technical: convert plain text files to asciidoc Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1 Split over-long synopsis in git-fetch-pack.txt into several lines
* mo/cvs-server-updates: cvsserver Documentation: new cvs ... -r support cvsserver: add t9402 to test branch and tag refs cvsserver: support -r and sticky tags for most operations cvsserver: Add version awareness to argsfromdir cvsserver: generalize getmeta() to recognize commit refs cvsserver: implement req_Sticky and related utilities cvsserver: add misc commit lookup, file meta data, and file listing functions cvsserver: define a tag name character escape mechanism cvsserver: cleanup extra slashes in filename arguments cvsserver: factor out git-log parsing logic
We failed to mention a file without any content change but whose permission bit was modified, or (worse yet) a new file without any content in the "git diff --stat" output. * lt/diff-stat-show-0-lines: Fix "git diff --stat" for interesting - but empty - file changes
Needs updates to the placeholder documentation. * jc/prettier-pretty-note: Documentation: decribe format-patch --notes format-patch --notes: show notes after three-dashes format-patch: append --signature after notes pretty_print_commit(): do not append notes message pretty: prepare notes message at a centralized place format_note(): simplify API pretty: remove reencode_commit_message()
An RFC to deal with a situation where .config/git is a file and we notice .config/git/config is not readable due to ENOTDIR, not ENOENT; I think a bit more refactored approach to consistently address permission errors across config, exclude and attrs is desirable. Don't we also need a check for an opposite situation where we open .config/git/config or .gitattributes for reading but they turn out to be directories? * jn/warn-on-inaccessible-loosen: config: exit on error accessing any config file doc: advertise GIT_CONFIG_NOSYSTEM config: treat user and xdg config permission problems as errors config, gitignore: failure to access with ENOTDIR is ok
Allows "cvsimport" to read per-author timezone from the author info file. * cr/cvsimport-local-zone: git-cvsimport: allow author-specific timezones
Fix to update_pre_post_images() that did not take into account the possibility that whitespace fix could shrink the preimage and change the number of lines in it. Extra set of eyeballs appreciated. * jc/apply-trailing-blank-removal: apply.c:update_pre_post_images(): the preimage can be truncated
* nd/tree-walk-enum-cleanup: tree-walk: use enum interesting instead of integer
This was split out from discarded jc/maint-push-refs-all topic. * jc/maint-fetch-tighten-refname-check: get_fetch_map(): tighten checks on dest refs
Sometimes curl_multi_timeout() function suggested a wrong timeout value when there is no file descriptors to wait on and the http transport ended up sleeping for minutes in select(2) system call. Detect this and reduce the wait timeout in such a case. * sz/maint-curl-multi-timeout: Fix potential hang in https handshake
Various codepaths checked if two encoding names are the same using ad-hoc code and some of them ended up asking iconv() to convert between "utf8" and "UTF-8". The former is not a valid way to spell the encoding name, but often people use it by mistake, and we equated them in some but not all codepaths. Introduce a new helper function to make these codepaths consistent. * jc/same-encoding: reencode_string(): introduce and use same_encoding() Conflicts: builtin/mailinfo.c
"update-ref -d --deref SYM" to delete a ref through a symbolic ref that points to it did not remove it correctly. * jh/update-ref-d-through-symref: Fix failure to delete a packed ref through a symref t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM. It is already possible to remove a symbolic ref with "update-ref -d --no-deref", but it may be a good addition for completeness. * jh/symbolic-ref-d: git symbolic-ref --delete $symref
Various minor tweaks to the test framework to paint its output lines in colors that match what they mean better. Has the "is this really blue?" issue Peff raised resolved??? * as/test-tweaks: tests: paint unexpectedly fixed known breakages in bold red tests: test the test framework more thoroughly [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up tests: refactor mechanics of testing in a sub test-lib tests: paint skipped tests in bold blue tests: test number comes first in 'not ok $count - $message' tests: paint known breakages in bold yellow
When the user does not specify what remote to interact with, we often attempt to use 'origin'. This can now be customized via a configuration variable. Expecting a reroll. "The first remote becomes the default" bit is better done as a separate step. * mb/remote-default-nn-origin: Teach get_default_remote to respect remote.default. Test that plain "git fetch" uses remote.default when on a detached HEAD. Teach clone to set remote.default. Teach "git remote" about remote.default. Teach remote.c about the remote.default configuration setting. Rename remote.c's default_remote_name static variables. Conflicts: builtin/remote.c t/t5505-remote.sh
A toy to analyze how bad the clock skews are in histories of real world projects. Stalled mostly due to lack of responses. * jc/xprm-generation: test-generation: compute generation numbers and clock skews
* nd/pretty-placeholder-with-color-option: pretty: support %>> that steal trailing spaces pretty: support truncating in %>, %< and %>< pretty: support padding placeholders, %< %> and %>< pretty: two phase conversion for non utf-8 commits utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences utf8.c: move display_mode_esc_sequence_len() for use by other functions pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s) pretty: split parsing %C into a separate function pretty: share code between format_decoration and show_decorations
Interesting exercise. When we do this for real, we probably would want to wrap a commit to make it more like an "object" with methods like "parents", etc. * jk/lua-hackery: pretty: fix up one-off format_commit_message calls Minimum compilation fixup Makefile: make "lua" a bit more configurable add a "lua" pretty format add basic lua infrastructure pretty: make some commit-parsing helpers more public Conflicts: pretty.c
Need to address the installation half if this is to be any useful. * jc/doc-default-format: [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..." Allow generating a non-default set of documentation
Duy helped to reroll this. * as/check-ignore: Documentation/check-ignore: we show the deciding match, not the first Add git-check-ignore sub-command dir.c: provide free_directory() for reclaiming dir_struct memory pathspec.c: move reusable code from builtin/add.c dir.c: refactor treat_gitlinks() dir.c: keep track of where patterns came from dir.c: refactor is_path_excluded() dir.c: refactor is_excluded() dir.c: refactor is_excluded_from_list() dir.c: rename excluded() to is_excluded() dir.c: rename excluded_from_list() to is_excluded_from_list() dir.c: rename path_excluded() to is_path_excluded() dir.c: rename cryptic 'which' variable to more consistent name
* fc/zsh-completion: completion: add new zsh completion tests: use __gitcompadd to simplify completion tests completion: add new __gitcompadd helper
* fc/completion-send-email-with-format-patch: completion: add format-patch options to send-email Conflicts: contrib/completion/git-completion.bash
ghost
assigned
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.