user/sven/git.git/builtin-pack-objects.c, branch v1.6.5.4

pack-objects: split implications of --all-progress from progress activation

2009-11-24T05:33:09Z

Currently the --all-progress flag is used to use force progress display during the writing object phase even if output goes to stdout which is primarily the case during a push operation. This has the unfortunate side effect of forcing progress display even if stderr is not a terminal. Let's introduce the --all-progress-implied argument which has the same intent except for actually forcing the activation of any progress display. With this, progress display will be automatically inhibited whenever stderr is not a terminal, or full progress display will be included otherwise. This should let people use 'git push' within a cron job without filling their logs with useless percentage displays. Signed-off-by: Nicolas Pitre Tested-by: Jeff King Signed-off-by: Junio C Hamano

pack-objects: remove SP at the end of usage string

2009-09-19T02:48:48Z

These spaces immediately before the end of lines are unnecessary. While at it, instead of using a single string literal with backslashes at end of each line, split the lines into individual string literals and tell the compiler to concatenate them. Signed-off-by: Thiago Farina Signed-off-by: Junio C Hamano

Merge branch 'np/maint-1.6.3-deepen'

2009-09-07T22:23:50Z

* np/maint-1.6.3-deepen: pack-objects: free preferred base memory after usage make shallow repository deepening more network efficient

pack-objects: free preferred base memory after usage

2009-09-06T05:27:08Z

When adding objects for preferred delta base, the content from tree objects leading to given paths is kept in a cache. This has the potential to grow significantly, especially with large directories as the whole tree object content is loaded in memory, even if in practice the number of those objects is limited to the 256 cache entries plus the $window root tree objects. Still, that can't hurt freeing that up after object enumeration is done, and before more memory is needed for delta search. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

builtin-pack-objects.c: avoid vla

2009-09-01T14:55:56Z

This is one of only two places that we use C99 variable length array on the stack, which some older compilers apparently are not happy with. Signed-off-by: Junio C Hamano

Style fixes, add a space after if/for/while.

2009-09-01T06:26:28Z

The majority of code in core git appears to use a single space after if/for/while. This is an attempt to bring more code to this standard. These are entirely cosmetic changes. Signed-off-by: Brian Gianforcaro Signed-off-by: Junio C Hamano

Merge branch 'cc/replace'

2009-08-22T01:47:53Z

* cc/replace: t6050: check pushing something based on a replaced commit Documentation: add documentation for "git replace" Add git-replace to .gitignore builtin-replace: use "usage_msg_opt" to give better error messages parse-options: add new function "usage_msg_opt" builtin-replace: teach "git replace" to actually replace Add new "git replace" command environment: add global variable to disable replacement mktag: call "check_sha1_signature" with the replacement sha1 replace_object: add a test case object: call "check_sha1_signature" with the replacement sha1 sha1_file: add a "read_sha1_file_repl" function replace_object: add mechanism to replace objects found in "refs/replace/" refs: add a "for_each_replace_ref" function

don't let the delta cache grow unbounded in 'git repack'

2009-08-06T03:14:54Z

I have 4GB of RAM on my system which should, in theory, be quite enough to repack a 600 MB repository. However the unbounded delta cache size always pushes it into swap, at which point everything virtually comes to a halt. So unbounded caches are never a good idea. A default of 256MB should be a good compromize between memory usage and speed where medium sized repositories are still likely to fit in the cache with a reasonable memory usage, and larger repositories are going to take quite some time to repack already anyway. While at it, clarify the associated config variable documentation entries a bit. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Merge branch 'js/maint-graft-unhide-true-parents'

2009-07-25T07:45:03Z

* js/maint-graft-unhide-true-parents: git repack: keep commits hidden by a graft Add a test showing that 'git repack' throws away grafted-away parents Conflicts: git-repack.sh

git repack: keep commits hidden by a graft

2009-07-24T16:10:16Z

When you have grafts that pretend that a given commit has different parents than the ones recorded in the commit object, it is dangerous to let 'git repack' remove those hidden parents, as you can easily remove the graft and end up with a broken repository. So let's play it safe and keep those parent objects and everything that is reachable by them, in addition to the grafted parents. As this behavior can only be triggered by git pack-objects, and as that command handles duplicate parents gracefully, we do not bother to cull duplicated parents that may result by using both true and grafted parents. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano