- 15 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Junio C Hamano <junkio@cox.net> writes: > > I think the output from merge-recursive can be categorized into 5 > verbosity levels: > > 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict" > (outermost) > > 2. "Auto-merged successfully" (outermost) > > 3. The first "Merging X with Y". > > 4. outermost "Merging:\ntitle1\ntitle2". > > 5. outermost "found N common ancestors\nancestor1\nancestor2\n..." > and anything from inner merge. > > I would prefer the default verbosity level to be 2 (that is, show > both 1 and 2). and this change makes it so. I think level 3 is probably pointless as its only one line of output above level 2, but I can see how some users may want to view it but not view the slightly more verbose output of level 4. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 1月, 2007 1 次提交
-
-
由 Nicolas Pitre 提交于
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If we have a 64 bit address space we can easily afford to commit a larger amount of virtual address space to pack file access. So on these platforms we should increase the default settings of core.packedGit{Limit,WindowSize} to something that will better handle very large projects. Thanks to Andy Whitcroft for pointing out that we can safely increase these defaults on such systems. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 1月, 2007 1 次提交
-
-
由 Brian Gernhardt 提交于
Added color.branch and color.branch.<slot> to configuration list. Style copied from color.status and meanings derived from the code. Moved the color meanings from color.diff.<slot> to color.branch.<slot> since the latter comes first alphabetically. Added --color and --no-color to git-branch's usage and documentation. Signed-off-by: NBrian Gernhardt <benji@silverinsanity.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 31 12月, 2006 2 次提交
-
-
由 Shawn O. Pearce 提交于
Corrected minor typos and documented the new k/m/g suffix for core.packedGitWindowSize and core.packedGitLimit. [jc: with a minor markup fix.] Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 12月, 2006 2 次提交
-
-
由 Shawn O. Pearce 提交于
This finally turns on the sliding window behavior for packfile data access by mapping limited size windows and chaining them under the packed_git->windows list. We consider a given byte offset to be within the window only if there would be at least 20 bytes (one hash worth of data) accessible after the requested offset. This range selection relates to the contract that use_pack() makes with its callers, allowing them to access one hash or one object header without needing to call use_pack() for every byte of data obtained. In the worst case scenario we will map the same page of data twice into memory: once at the end of one window and once again at the start of the next window. This duplicate page mapping will happen only when an object header or a delta base reference is spanned over the end of a window and is always limited to just one page of duplication, as no sane operating system will ever have a page size smaller than a hash. I am assuming that the possible wasted page of virtual address space is going to perform faster than the alternatives, which would be to copy the object header or ref delta into a temporary buffer prior to parsing, or to check the window range on every byte during header parsing. We may decide to revisit this decision in the future since this is just a gut instinct decision and has not actually been proven out by experimental testing. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Rather than hardcoding the maximum number of bytes which can be mmapped from pack files we should make this value configurable, allowing the end user to increase or decrease this limit on a per-repository basis depending on the size of the repository and the capabilities of their operating system. In general users should not need to manually tune such a low-level setting within the core code, but being able to artifically limit the number of bytes which we can mmap at once from pack files will make it easier to craft test cases for the new mmap sliding window implementation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
It is plausible for somebody to want to view the commit log in a different encoding from i18n.commitencoding -- the project's policy may be UTF-8 and the user may be using a commit message hook to run iconv to conform to that policy (and either not have i18n.commitencoding to default to UTF-8 or have it explicitly set to UTF-8). Even then, Latin-1 may be more convenient for the usual pager and the terminal the user uses. The new variable i18n.logoutputencoding is used in preference to i18n.commitencoding to decide what encoding to recode the log output in when git-log and friends formats the commit log message. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 12月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Two configuration to control the expiration of rerere records are introduced and documented. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 12月, 2006 1 次提交
-
-
由 Aneesh Kumar K.V 提交于
Update config.txt with example with respect to branch config variable. This give a better idea regarding how branch names are expected. Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 12月, 2006 2 次提交
-
-
由 Shawn O. Pearce 提交于
Now that 'git add' is considered a first-class UI for 'update-index' and that the 'git add' documentation states "Even modified files must be added to the set of changes about to be committed" we should make the output of 'git status' align with that documentation and common usage. So now we see a status output such as: # Added but not yet committed: # (will commit) # # new file: x # # Changed but not added: # (use "git add file1 file2" to include for commit) # # modified: x # # Untracked files: # (use "git add" on files to include for commit) # # y which just reads better in the context of using 'git add' to manipulate a commit (and not a checkin, whatever the heck that is). We also now support 'color.status.added' as an alias for the existing 'color.status.updated', as this alias more closely aligns with the current output and documentation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
New and experienced Git users alike are finding out too late that they forgot to enable reflogs in the current repository, and cannot use the information stored within it to recover from an incorrectly entered command such as `git reset --hard HEAD^^^` when they really meant HEAD^^ (aka HEAD~2). So enable reflogs by default in all future versions of Git, unless the user specifically disables it with: [core] logAllRefUpdates = false in their .git/config or ~/.gitconfig. We only enable reflogs in repositories that have a working directory associated with them, as shared/bare repositories do not have an easy means to prune away old log entries, or may fail logging entirely if the user's gecos information is not valid during a push. This heuristic was suggested on the mailing list by Junio. Documentation was also updated to indicate the new default behavior. We probably should start to teach usuing the reflog to recover from mistakes in some of the tutorial material, as new users are likely to make a few along the way and will feel better knowing they can recover from them quickly and easily, without fsck-objects' lost+found features. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 12月, 2006 1 次提交
-
-
由 Andy Parkins 提交于
While adding colour to the branch command it was pointed out that a config option like "branch.color" conflicts with the pre-existing "branch.something" namespace used for specifying default merge urls and branches. The suggested solution was to flip the order of the components to "color.branch", which I did for colourising branch. This patch does the same thing for - git-log (color.diff) - git-status (color.status) - git-diff (color.diff) - pager (color.pager) I haven't removed the old config options; but they should probably be deprecated and eventually removed to prevent future namespace collisions. I've done this deprecation by changing the documentation for the config file to match the new names; and adding the "color.XXX" options to contrib/completion/git-completion.bash. Unfortunately git-svn reads "diff.color" and "pager.color"; which I don't like to change unilaterally. Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 12月, 2006 1 次提交
-
-
由 Josef Weidendorfer 提交于
This patch clarifies the meaning of the branch.*.merge option. Previously, if branch.*.merge was specified but did not match any ref, the message "No changes." was not really helpful regarding the misconfiguration. This patch adds a warning for this. Signed-off-by: NJosef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 11月, 2006 1 次提交
-
-
由 Peter Baumann 提交于
This allows one to see a root commit as a diff in commands like git-log, git-show and git-whatchanged. Signed-off-by: NPeter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 11月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
Since keeping a pushed pack or exploding it into loose objects should be a local repository decision this teaches receive-pack to decide if it should call unpack-objects or index-pack --stdin --fix-thin based on the setting of receive.unpackLimit and the number of objects contained in the received pack. If the number of objects (hdr_entries) in the received pack is below the value of receive.unpackLimit (which is 5000 by default) then we unpack-objects as we have in the past. If the hdr_entries >= receive.unpackLimit then we call index-pack and ask it to include our pid and hostname in the .keep file to make it easier to identify why a given pack has been kept in the repository. Currently this leaves every received pack as a kept pack. We really don't want that as received packs will tend to be small. Instead we want to delete the .keep file automatically after all refs have been updated. That is being left as room for future improvement. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 10月, 2006 1 次提交
-
-
由 Santi Béjar 提交于
Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 10月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
When configuration variable `repack.UseDeltaBaseOffset` is set for the repository, the command passes `--delta-base-offset` option to `git-pack-objects`; this typically results in slightly smaller packs, but the generated packs are incompatible with versions of git older than (and including) v1.4.3. We will make it default to true sometime in the future, but not for a while. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 08 10月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
It used to mean "create log file for any ref that is updated", but now it creates new log files only for branch heads. The old behaviour made this configuration less useful than otherwise it would be; automatically creating log file for tags is almost always not useful. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 9月, 2006 1 次提交
-
-
由 Sasha Khapyorsky 提交于
If http.noEPSV config variable is defined and true, or if GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using of EPSV ftp command (PASV will be used instead). This is helpful with some "poor" ftp servers which does not support EPSV mode. Signed-off-by: NSasha Khapyorsky <sashak@voltaire.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 9月, 2006 2 次提交
-
-
由 Santi Béjar 提交于
If in branch "foo" and this in config: [branch "foo"] merge=bar "git fetch": fetch from the default repository and program the "bar" branch to be merged with pull. Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Santi Béjar 提交于
If in branch "foo" and this in config: [branch "foo"] remote=bar "git fetch" = "git fetch bar" "git pull" = "git pull bar" Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 9月, 2006 1 次提交
-
-
由 Johannes Schindelin 提交于
[jc: with a fix to config handling in t5400 test, which took annoyingly long to diagnose.] Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 9月, 2006 1 次提交
-
-
由 Jeff King 提交于
Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 8月, 2006 1 次提交
-
-
由 Jonas Fonseca 提交于
Combine option descriptions in git-init-db(1). Reflect the changes to additionally allow all users to read the created git repository. Signed-off-by: NJonas Fonseca <fonseca@diku.dk> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 8月, 2006 1 次提交
-
-
由 Jeff King 提交于
There isn't and never was such a macro; all uses are typos. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 8月, 2006 1 次提交
-
-
由 Matthias Lederhofer 提交于
enable/disable colored output when the pager is in use Signed-off-by: NMatthias Lederhofer <matled@gmx.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 7月, 2006 2 次提交
-
-
由 Jeff King 提交于
For some repositories, deltas simply don't make sense. One can disable them for git-repack by adding --window, but git-push insists on making the deltas which can be very CPU-intensive for little benefit. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Willy Tarreau 提交于
By default, git-tar-tree(1) sets file and directories modes to 0666 or 0777. While this is both useful and acceptable for projects such as the Linux Kernel, it might be excessive for other projects. With this variable, it becomes possible to tell git-tar-tree(1) to apply a specific umask to the modes above. The special value "user" indicates that the user's current umask will be used. This should be enough for most projects, as it will lead to the same permissions as git-checkout(1) would use. The default value remains 0, which means world read-write. Signed-off-by: NWilly Tarreau <w@1wt.eu> Acked-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 7月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
The pack-file format is slightly different from the traditional git object format, in that it has a much denser binary header encoding. The traditional format uses an ASCII string with type and length information, which is somewhat wasteful. A new object format starts with uncompressed binary header followed by compressed payload -- this will allow us later to copy the payload straight to packfiles. Obviously they cannot be read by older versions of git, so for now new object files are created with the traditional format. core.legacyheaders configuration item, when set to false makes the code write in new format for people to experiment with. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 08 7月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
diff.renames is mentioned several times in the documentation, but to my surprise it didn't do anything before this patch. Also add the --no-renames option to override this from the command-line. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 7月, 2006 1 次提交
-
-
由 Joachim Berdal Haga 提交于
I didn't notice earlier that two colons are required for the asciidoc entry. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 7月, 2006 1 次提交
-
-
由 Joachim B Haga 提交于
With the change in default, "git add ." on kernel dir is about twice as fast as before, with only minimal (0.5%) change in object size. The speed difference is even more noticeable when committing large files, which is now up to 8 times faster. The configurability is through setting core.compression = [-1..9] which maps to the zlib constants; -1 is the default, 0 is no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no) Acked-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 08 6月, 2006 3 次提交
-
-
由 Petr Baudis 提交于
Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Francis Daly 提交于
Nothing major. Signed-off-by: NFrancis Daly <francis@daoine.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Petr Baudis 提交于
This patch ports and modifies appropriately the git aliases documentation from my patch, shall it rest in peace. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-