Smartgit remote prune code#

+ + * 'git cherry-pick $blob' and 'git cherry-pick $tree' are nonsense, + and a more readable error message e.g. + + * 'git count-objects' learned '-human-readable' aka '-H' option to + show various large numbers in Ki/Mi/GiB scaled as necessary. + + * 'git clone -reference' can now refer to a gitfile 'textual symlink' + that points at the real location of the repository. + + * 'git bisect' leaves the final outcome as a comment in its bisect + log file. + + * In a sparsely populated working tree, 'git checkout ' no + longer unmarks paths that match the given pathspec that were + originally ignored with '-sparse' (use -ignore-skip-worktree-bits + option to resurrect these paths out of the index if you really want + to). + + +UI, Workflows & Features + + * 'git branch -vv' learned to paint the name of the branch it + integrates with in a different color (, + which defaults to blue). + + +Updates since v1.8.2 +- + +Foreign interface + + * remote-hg helper (in contrib/) has been updated. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. ' when they mean +it before Git 2.0 comes. ', it is +important for those who are used to 'git add -u' (without pathspec) +updating the index only for paths in the current subdirectory to start +training their fingers to explicitly say 'git add -u.

Because there will be no +mechanism to make 'git add -u' behave as if 'git add -u. + +When 'git add -u' and 'git add -A', that does not specify what paths +to add on the command line is run from inside a subdirectory, these +commands will operate on the entire tree in Git 2.0 for consistency +with 'git commit -a' and other commands. If you want to live in the future early, +you can set it to 'simple' today without waiting for Git 2.0. If you are an old-timer who is used +to the 'matching' semantics, you can set it to 'matching' to keep the +traditional behaviour. There is a user preference configuration variable +'fault' to change this. In Git 2.0, the default will change to the 'simple' +semantics that pushes the current branch to the branch with the same +name, only when the current branch is set to integrate with that +remote branch. +++ -0,0 +1,409 v1.8.3 Release Notes += + +Backward compatibility notes (for Git 2.0) +- + +When 'git push ' does not say what to push, we have used the +traditional 'matching' semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). diff -git a/Documentation/RelNotes/1.8.3.txt b/Documentation/RelNotes/1.8.3.txt + + * 'git bundle' did not like a bundle created using a commit without + any message as its one of the prerequistes. + + * A few bugfixes to 'git rerere' working on corner case merge + conflicts have been applied. + + * Documentation on setting up a http server that requires + authentication only on the push but not fetch has been clarified. + + * 'git diff/log -cc' did not work well with options that ignore + whitespace changes. + + * 'git apply -whitespace=fix' was not prepared to see a line getting + longer after fixing whitespaces (e.g.

Smartgit remote prune code#

+ Later open may return file descriptor #2 for unrelated purpose, and + error reporting code may write into them. +++ -0,0 +1,25 v1.8.2.2 Release Notes += + +Fixes since v1.8.2.1 +- + + * Perl scripts like 'git-svn' closed (not redirecting to /dev/null) + the standard error stream, which is not a very smart thing to do.