- Code used by git submodule to compute relative URL is broken and a repository that is created by doing git clone git://site.xz/repo.git/. here gets confused due to the slash-dot at the end.
Cf. $pinbox/304661 - git submodule $cmd $pathspec may want to error out when the $pathspec does not match any submodules. There must be an --unmatch-ok option to override this safety, though.
Cf. http://public-inbox.org/git/xmqqy49agx98.fsf@gitster.mtv.corp.google.com - Teach --cached and --index options to git blame. Both of these should be only valid when the positive end of the history is not given, just like the normal git blame assigns the blame to the working tree files by creating a fake commit to represent the working tree state, but the former should start from the contents in the index and the latter should create two fake commits, the tip of the history being the working tree state with its parent being the state in the index.
- [STARTED] Uniformly teach commands that use --stdin in order to take input that would have otherwise given from the command line (e.g. rev-list --stdin hence cherry-pick --stdin) that input line may be using CRLF as the line terminator. Audit the callers to strbuf_getline() (not strbuf_getwholeline()) to see if the following approach is sensible: Teach strbuf_getline() to strip the CR at the end after stripping the LF at the end of line, and update some callers of strbuf_getwholeline() that remove the line termination themselves to call the updated strbuf_getline(). If the audit goes well, this would be a good way to solve this issue for once and for all.
Cf. http://public-inbox.org/git/xmqqtws5o4lp.fsf@gitster.dls.corp.google.com - Even though fsck and receive-pack have learned to pay attention to per-class fsck.* configuration variables, the codepath for fetching history hasn't. Refactor relevant code in receive-pack and teach the same trick to fetch-pack and friends.
Cf. http://public-inbox.org/git/20160306115850.GA985@sigill.intra.peff.net - "git commit" that records the same tree as its first parent goes through without "--allow-empty" when recording a merge (which is correct), but "git commit --dry-run" does not.
Cf. http://public-inbox.org/git/CAPHyNCVJaJPzQpZGAuQY=SOXOCJyRMxYCOyjzc51oOweO8wiww@mail.gmail.com - Allow escaping glob metacharacters in .gitattributes.
Cf. http://public-inbox.org/git/1357310809-4771-1-git-send-email-pclouds@gmail.com - Maybe "check-attr" in a bare repository should read from HEAD not from the index?
Cf. $gmane/241743 - Maybe "check-ignore" in a bare repository should work in a similar way as "check-attr"?
Cf. $gmane/241709 - The caller of fsck_sha1() function expects it to check the validity of the loose object file, but the function validates something else by calling parse_object(), a wrong function for the job, and as a side effect, it gives an ambiguous error message when it finds a problem.
Cf. $gmane/285299 - Write a proposed merge summary as the log message for a non-tree-changing commit at the tip of the branch to be merged, and have "git merge --cover-at-tip" (and similarly "git pull --cover-at-tip") do the right thing. Also update git format-patch to format such a topic appropriately. Teach git am to optionally keep the cover-letter material as a non-tree-changing commit at the tip of the topic.
Cf. $gmane/277624 - git config --bool --get-regexp '.*' no does not work as expected.
Cf. $gmane/270184 - Revamp the one-byte-per-matched-pathspec array interface of ce_path_match() and report_path_error() to instead store "matched" bit in "struct pathspec".
Cf. $gmane/266005 - Tighten configuration and hook execution based on the file ownership. In addition to what we discussed, I think files named by include.path should be honored without checking the ownership.
Cf. $gmane/243628 - Maybe "git apply --fix-mta-corruption" that takes eol attributes into account to correct lossage/addition of CR at the end of line, with updates to "am"?
Cf. $gmane/257445 - Audit hits from "git grep test_might_fail t/" and tighten the expectations.
Cf. $gmane/256717 - Refine the advice message given by "git commit" while the index is still unmerged.
Cf. $gmane/256020 - There probably should exist a way to specify the width of the output used for showing the diffstat output in a more direct way than diff.statgraphwidth configuration variable?
Cf. $gmane/246981 - "git tag --contains" should not consider a tag as the anchor point to describe the commit, when it can reach another tag that can also be used to describe the commit.
Cf. $gmane/246423 - Update repository-layout documentation to describe (1) borrowing of objects done with the "objects/info/alternate" mechanism, (2) keeping the entire repository outside the working tree by having ".git" file that points at the real location, and (3) borrowing of selected parts of the repository data from another one via "git workdir add" (or "git new-workdir" in contrib/), and warn users that copying a working tree that employs any of these methods with "cp -R" would not be sufficient to get a functional copy of a repository with a working tree.
Cf. $gmane/243798 - Perhaps make tree-level merge logic aware of -Xours, -Xtheirs, etc., so that "they made irrelevant changes to a file we decided to remove" conflict will be resolved to favour our version?
Cf. $gmane/236349 - [DONE BUT NOT QUITE] Extend the upload-pack protocol to tell what symbolic ref points at which other ref by resurrecting the idea outlined in 2008.
Cf. $gmane/102039
... but not quite. There is an unfortunate line length limit in the protocol. - Checking out a branch X that does not have directory D (or worse, has a file D), while you are in the directory D, may want to fail.
Cf. $gmane/234905 - Perhaps add a --post-service-hook to the git-daemon that can be used after a service finishes? The exit status from the service process means totally different thing from what the user of service perceives because the former has to say "successfully told the requester that the request is denied", it may not be such a useful mechanism as one naïvely would expect, though.Cf. $gmane/234706
- git checkout $commit -- somedir may want to remove somedir/file that is not in $commit but is in the original index. Anybody who wants to do this needs to consider ramifications and devise transition plans.
Cf. $gmane/234935 - "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments.
Cf. $gmane/219524 - [STARTED AND THEN STALLED] Add "git pull --merge" option to explicitly override configured pull.rebase=true. Make "git pull" that does not say how to integrate fail when the result does not fast-forward, and advise the user to say --merge/--rebase explicitly or configure pull.rebase=[true|false]. An unconfigured pull.rebase and pull.rebase that is explicitly set to false would mean different things (the former will trigger the "fast-forward or die" check, the latter does the "pull = fetch + merge".
Cf. $gmane/225326 - Proofread our documentation set, and update to reduce newbie confusion around "remote", "remote-tracking branch", use of the verb "to track", and "upstream".
Cf. $gmane/230786. - Teach "--first-parent" to "git rebase" to deal better with a history with (possibly evil) merges from side branches.
Cf. $gmane/198516 - More fixes to bring sanity to "git diff --no-index", some discussed in the thread are definitely worthwhile, while some others are not.
Cf. $gmane/200769 - [DONE] "git diff --no-index $directory $file" perhaps should DWIM to be "git diff --no-index $directory $directory/$file"?
- The name sanitization code may be overly conservative.
Cf. $gmane/200823 - The behaviour of "git filter-branch" around annotated tag may be under-documented to cause misunderstanding on the user's part, or it could be simply buggy.
Cf. $gmane/212353 - Annotating a pair of commit objects and trigger interesting behaviour when they both appear in the history.
Cf. $gmane/212570 - The return value from getenv(3) may be volatile across calls.
Cf. $gmane/212660 - Support VPATH build
Cf. $gmane/212744 - Build on "custom comment char" to make it "custom comment prefix string", e.g. "## ".
Cf. $gmane/213802 - Serving "git archive" over smart-http.
Cf. $gmane/213243 - [STARTED] "git fetch --deepen"?
Cf. $gmane/213180 $gmane/212950 - Improve "git remote -v" output to show where these URLs come from?
Cf. $gmane/213806 - Perhaps add a robust "shell portability check" mode for test scripts?
Cf. $gmane/214709 - Perhaps treat failures to write to a hook process that did not consume its input as success?
Cf. $gmane/213548 - "git submodule foreach --untracked"
Cf. $gmane/214860 - Perhaps concatenate young and small packs into one as a cheap repack?
Cf. $gmane/215288 - Align the logic format-patch decides to omit S-o-b to that is used by cherry-pick and commit.
Cf. $gmane/216026 - Allow installation filemode to be tweaked.
Cf. $gmane/215119 - [Done] "git log --cc" without other diff format specifiers like --raw should imply "--cc -p".
Cf. $gmane/215470 - Possible merge-recursive corner case bug?
Cf. $gmane/216117 - Complete smart HTTP protocol documentation?
Cf. $gmane/216262 - Perhaps include an artificial HEAD to a bundle when HEAD is not specified from the command line?
Cf. $gmane/216401 - Restructure the revision parsing loop in bundle.c:create_bundle() to remove duplicates correctly, e.g. "git bundle create t.bundle master heads/master"
Cf. $gmane/225837 - Discuss and decide if we want to choose between the "mode word" UI (e.g. "git submodule add") and the "mode option" UI (e.g. "git tag --delete") and standardise on one; if it turns out to be a good idea, devise the migration plan to break the backward-compatibility.
Cf. $gmane/231478 - Introduce threading to checkout codepath, possibly helping Windows folks.
Cf. $gmane/235874 - Remove or reduce the need to maintain list of suffixes and languages used for gitweb highlighting.
Cf. $gmane/241806
Leftover Bits
Some leftover bits, in no particular order. Some are low-hanging fruits that we know what needs to happen. Others are hard in that we do not know what the right solutions are, or if the problem even exists in the first place (i.e. the suggested change may be something we do not want). Many of them are tricky and need careful examination of ramifications and possible fallout from the changes.
Subscribe to:
Posts (Atom)