git, branch v1.6.5.6

Git 1.6.5.6

2009-12-10T23:42:30Z

Signed-off-by: Junio C Hamano

Fix archive format with -- on the command line

2009-12-10T23:29:05Z

Giving --format from the command line, or using output file extention to DWIM the output format, with a pathspec that is disambiguated with an explicit double-dash on the command line, e.g. git archive -o file --format=zip HEAD -- path git archive -o file.zip HEAD -- path didn't work correctly. This was because the code reordered (when one was given) or added (when the format was inferred) a --format argument at the end, effectively making it to "archive HEAD -- path --format=zip", i.e. an extra pathspec that is unlikely to match anything. The command line argument list should always be "options, revs and then paths", and we should set a good example by inserting the --format at the beginning instead. Reported-by: Ilari Liusvaara Signed-off-by: Junio C Hamano

Remove post-upload-hook

2009-12-10T20:21:40Z

This hook runs after "git fetch" in the repository the objects are fetched from as the user who fetched, and has security implications. Signed-off-by: Junio C Hamano

Merge branch 'mm/maint-merge-ff-error-message-fix' into maint

2009-12-09T06:42:23Z

* mm/maint-merge-ff-error-message-fix: builtin-merge: show user-friendly error messages for fast-forward too. merge-recursive: make the error-message generation an extern function Conflicts: merge-recursive.c

Merge branch 'jn/maint-pull-rebase-error-message' into maint

2009-12-09T06:39:20Z

* jn/maint-pull-rebase-error-message: pull: clarify advice for the unconfigured error case

Merge branch 'jk/maint-add-p-delete-fix' into maint

2009-12-09T06:37:50Z

* jk/maint-add-p-delete-fix: add-interactive: fix deletion of non-empty files

add-interactive: fix deletion of non-empty files

2009-12-08T07:52:46Z

Commit 24ab81a fixed the deletion of empty files, but broke deletion of non-empty files. The approach it took was to factor out the "deleted" line from the patch header into its own hunk, the same way we do for mode changes. However, unlike mode changes, we only showed the special "delete this file" hunk if there were no other hunks. Otherwise, the user would annoyingly be presented with _two_ hunks: one for deleting the file and one for deleting the content. This meant that in the non-empty case, we forgot about the deleted line entirely, and we submitted a bogus patch to git-apply (with "/dev/null" as the destination file, but not marked as a deletion). Instead, this patch combines the file deletion hunk and the content deletion hunk (if there is one) into a single deletion hunk which is either staged or not. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Git 1.6.5.5

2009-12-05T19:08:35Z

Signed-off-by: Junio C Hamano

Fix diff -B/--dirstat miscounting of newly added contents

2009-12-05T18:54:17Z

What used to happen is that diffcore_count_changes() simply ignored any hashes in the destination that didn't match hashes in the source. EXCEPT if the source hash didn't exist at all, in which case it would count _one_ destination hash that happened to have the "next" hash value. As a consequence, newly added material was often undercounted, making output from --dirstat and "complete rewrite" detection used by -B unrelialble. This changes it so that: - whenever it bypasses a destination hash (because it doesn't match a source), it counts the bytes associated with that as "literal added" - at the end (once we have used up all the source hashes), we do the same thing with the remaining destination hashes. - when hashes do match, and we use the difference in counts as a value, we also use up that destination hash entry (the 'd++'). Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

reset: improve worktree safety valves

2009-12-05T18:28:20Z

The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano