66abce05dd · matheusbsbs/matheus-bagliano

@@ -1,39 +1,97 @@

1 Git v1.6.6 Release Notes

2 ========================

3

4 -In this release, "git fsck" defaults to "git fsck --full" and checks

5 -packfiles, and because of this it will take much longer to complete

6 -than before. If you prefer a quicker check only on loose objects (the

7 -old default), you can say "git fsck --no-full". This has been

8 -supported by 1.5.4 and newer versions of git, so it is safe to write

9 -it in your script even if you use slightly older git on some of your

10 -machines.

4 +Notes on behaviour change

5 +-------------------------

6 +

7 + * In this release, "git fsck" defaults to "git fsck --full" and

8 + checks packfiles, and because of this it will take much longer to

9 + complete than before. If you prefer a quicker check only on loose

10 + objects (the old default), you can say "git fsck --no-full". This

11 + has been supported by 1.5.4 and newer versions of git, so it is

12 + safe to write it in your script even if you use slightly older git

13 + on some of your machines.

14 +

15 +Preparing yourselves for compatibility issues in 1.7.0

16 +------------------------------------------------------

17 +

18 +In git 1.7.0, which is planned to be the release after 1.6.6, there will

19 +be a handful of behaviour changes that will break backward compatibility.

20 +

21 +These changes were discussed long time ago and existing behaviours have

22 +been identified as more problematic to the userbase than keeping them for

23 +the sake of backward compatibility.

24 +

25 +When necessary, transition strategy for existing users has been designed

26 +not to force them running around setting configuration variables and

27 +updating their scripts in order to keep the traditional behaviour on the

28 +day their sysadmin decides to install the new version of git. When we

29 +switched from "git-foo" to "git foo" in 1.6.0, even though the change had

30 +been advertised and the transition guide had been provided for a very long

31 +time, the users procrastinated during the entire transtion period, and

32 +ended up panicking on the day their sysadmins updated their git.

33 +

34 +For changes decided to be in 1.7.0, we have been much louder to strongly

35 +discourage such procrastination. If you have been using recent versions

36 +of git, you would have already seen warnings issued when you exercised

37 +features whose behaviour will change, with the instruction on how to keep

38 +the existing behaviour if you choose to. You hopefully should be well

39 +prepared already.

40 +

41 +Of course, we have also given "this and that will change in 1.7.0; prepare

42 +yourselves" warnings in the release notes and announcement messages.

43 +Let's see how well users will fare this time.

44 +

45 + * "git push" into a branch that is currently checked out (i.e. pointed by

46 + HEAD in a repository that is not bare) will be refused by default.

47 +

48 + Similarly, "git push $there :$killed" to delete the branch $killed

49 + in a remote repository $there, when $killed branch is the current

50 + branch pointed at by its HEAD, will be refused by default.

51 +

52 + Setting the configuration variables receive.denyCurrentBranch and

53 + receive.denyDeleteCurrent to 'ignore' in the receiving repository

54 + can be used to override these safety features. Versions of git

55 + since 1.6.2 have issued a loud warning when you tried to do them

56 + without setting the configuration, so repositories of people who

57 + still need to be able to perform such a push should already been

58 + future proofed.

59 +

60 + Please refer to:

61 +

62 + http://git.or.cz/gitwiki/GitFaq#non-bare

63 + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

64 +

65 + for more details on the reason why this change is needed and the

66 + transition process that already took place so far.

67 +

68 + * "git send-email" will not make deep threads by default when sending a

69 + patch series with more than two messages. All messages will be sent as

70 + a reply to the first message, i.e. cover letter. It has been possible

71 + to configure send-email to do this by setting sendemail.chainreplyto

72 + configuration variable to false. The only thing the new release will

73 + do is to change the default when you haven't configured that variable.

74 +

75 + * "git status" will not be "git commit --dry-run". This change does not

76 + affect you if you run the command without pathspec.

77 +

78 + Nobody sane found the current behaviour of "git status Makefile" useful

79 + nor meaningful, and it confused users. "git commit --dry-run" has been

80 + provided as a way to get the current behaviour of this command since

81 + 1.6.5.

82 +

83 + * "git diff" traditionally treated various "ignore whitespace" options

84 + only as a way to filter the patch output. "git diff --exit-code -b"

85 + exited with non-zero status even if all changes were about changing the

86 + ammount of whitespace and nothing else. and "git diff -b" showed the

87 + "diff --git" header line for such a change without patch text.

88 +

89 + In 1.7.0, the "ignore whitespaces" will affect the semantics of the

90 + diff operation itself. A change that does not affect anything but

91 + whitespaces will be reported with zero exit status when run with

92 + --exit-code, and there will not be "diff --git" header for such a

93 + change.

94

12 -In git 1.7.0, which is planned to be the release after 1.6.6, "git

13 -push" into a branch that is currently checked out will be refused by

14 -default.

15 -

16 -You can choose what should happen upon such a push by setting the

17 -configuration variable receive.denyCurrentBranch in the receiving

18 -repository.

19 -

20 -Also, "git push $there :$killed" to delete the branch $killed in a remote

21 -repository $there, when $killed branch is the current branch pointed at by

22 -its HEAD, will be refused by default.

23 -

24 -You can choose what should happen upon such a push by setting the

25 -configuration variable receive.denyDeleteCurrent in the receiving

26 -repository.

27 -

28 -To ease the transition plan, the receiving repository of such a

29 -push running this release will issue a big warning when the

30 -configuration variable is missing. Please refer to:

31 -

32 - http://git.or.cz/gitwiki/GitFaq#non-bare

33 - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

34 -

35 -for more details on the reason why this change is needed and the

36 -transition plan.

95

96 Updates since v1.6.5

97 --------------------

@@ -76,6 +134,12 @@ Updates since v1.6.5

134 * "git diff" learned --submodule option to show a list of one-line logs

135 instead of differences between the commit object names.

136

137 + * "git fetch" learned --all and --multiple options, to run fetch from

138 + many repositories, and --prune option to remove remote tracking

139 + branches that went stale. These make "git remote update" and "git

140 + remote prune" less necessary (there is no plan to remove "remote

141 + update" nor "remote prune", though).

142 +

143 * "git fsck" by default checks the packfiles (i.e. "--full" is the

144 default); you can turn it off with "git fsck --no-full".

145

@@ -88,6 +152,9 @@ Updates since v1.6.5

152

153 * "git log --decorate" shows the location of HEAD as well.

154

155 + * "git log" and "git rev-list" learned to take revs and pathspecs from

156 + the standard input with the new "--stdin" option.

157 +

158 * "--pretty=format" option to "log" family of commands learned:

159

160 . to wrap text with the "%w()" specifier.

@@ -125,5 +192,5 @@ release, unless otherwise noted.

192 ---

193 exec >/var/tmp/1

194 echo O=$(git describe master)

128 -O=v1.6.5.3-337-gf341feb

195 +O=v1.6.6-rc0-62-g7fc9d15

196 git shortlog --no-merges $O..master --not maint

Update draft release notes to 1.6.6 before merging topics for -rc1