- 30 6月, 2005 4 次提交
-
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
Like git-receive-pack, this is only partway done.
-
由 Linus Torvalds 提交于
It's not working yet, but it's at the point where I want to be able to track my changes. The theory of operation is that this is the "remote" side of a "git push". It can tell us what references the remote side has, receives out reference update commands and a pack-file, and can execute the unpacking command.
-
由 Junio C Hamano 提交于
Given a list of <pack>.idx files, this command validates the index file and the corresponding .pack file for consistency. This patch also uses the same validation mechanism in fsck-cache when the --full flag is used. During normal operation, sha1_file.c verifies that a given .idx file matches the .pack file by comparing the SHA1 checksum stored in .idx file and .pack file as a minimum sanity check. We may further want to check the pack signature and version when we map the pack, but that would be a separate patch. Earlier, errors to map a pack file was not flagged fatal but led to a random fatal error later. This version explicitly die()s when such an error is detected. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 29 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This makes it match the new delta encoding, and admittedly makes the code easier to follow. This also updates the PACK file version to 2, since this (and the delta encoding change in the previous commit) are incompatible with the old format.
-
- 28 6月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Packed delta files created by git-pack-objects seems to be the way to go, and existing "delta" object handling code has exposed the object representation details to too many places. Remove it while we refactor code to come up with a proper interface in sha1_file.c. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 27 6月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
We want to be able to check their integrity later, and putting the sha1-sum of the contents at the end is a good thing. The writing routines are generic, so we could try to re-use them for the index file, instead of having the same logic duplicated. Update unpack-objects to know about the extra 20 bytes at the end of the index.
-
由 Ryan Anderson 提交于
This will scan 2 or more object repositories and look for common objects, check if they are hardlinked, and replace one with a hardlink to the other if not. This version warns when skipping files because of size differences, and handle more than 2 repositories automatically. Signed-off-by: NRyan Anderson <ryan@michonline.com> Cheered-on-by: NJeff Garzik <jgarzik@pobox.com> Acked-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 6月, 2005 4 次提交
-
-
由 Junio C Hamano 提交于
Using git-cherry, forward port local commits missing from the new upstream head. This also depends on "-m" flag support in git-commit-script. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Junio C Hamano 提交于
The git-cherry command helps the git-rebase script by finding commits that have not been merged upstream. Commits already included in upstream are prefixed with '-' (meaning "drop from my local pull"), while commits missing from upstream are prefixed with '+' (meaning "add to the updated upstream"). Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
So far it just reads the header and generates the list of objects. It also sorts them by the order they are written in the pack file, since that ends up being the same order we got them originally, and is thus "most recent first".
-
由 Linus Torvalds 提交于
This is kind of like a tar-ball for a set of objects, ready to be shipped off to another end. Alternatively, you could use is as a packed representation of the object database directly, if you changed "read_sha1_file()" to read these kinds of packs. The latter is partiularly useful to generate a "packed history", ie you could pack up your old history efficiently, but still have it available (at a performance hit, of course). I haven't actually written an unpacker yet, so the end result has not been verified in any way yet. I obviously always write bug-free code, so it just has to work, no?
-
- 24 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with whitespace and line numbers ignored. As such, it's "reasonably stable", but at the same time also reasonably unique, ie two patches that have the same "patch ID" are almost guaranteed to be the same thing. IOW, you can use this thing to look for likely duplicate commits.
-
- 23 6月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
It's just a trivial wrapper, but it should make Jeff's kernel developer guide to git look a bit less intimidating.
-
由 Linus Torvalds 提交于
Btw, it's fun just looking at the merged git repository itself with gitk, now that it has two "roots".
-
- 22 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
It is careful by default and refuses to overwrite old info, but if you want to force everything to be re-read, use the "-f" flag. Some day I'll make it take individual filenames too. Right now it's all-or-nothing.
-
- 15 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Fix permissions, and add trivial "reset" and "add" scripts. The "reset" script just resets the index back to head, while the "add" script is just a crutch for people used to do "cvs add".
-
- 14 6月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
It's a simple helper that depending on the arguments will either use git-diff-files, git-diff-cache or git-diff-tree.
-
由 Linus Torvalds 提交于
It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
-
- 10 6月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
The diff-* brothers acquired a sibling, git-diff-stages. With an unmerged index file, you specify two stage numbers and it shows the differences between them. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 08 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This gets the "cvs2git" program from the old git-tools archive, and adds a nice script around it that makes it much easier to use. With this, you should be able to import a CVS archive using just a simple git cvsimport <cvsroot> <module> and you're done. At least it worked for my one single test. NOTE!! This may need tweaking. It currently expects (and verifies) that cvsps version 2.1 is installed, but you can't actually set any of the cvsps parameters, like the time fuzz.
-
- 07 6月, 2005 3 次提交
-
-
由 Daniel Barkalow 提交于
This patch adds code to read a hash out of a specified file under {GIT_DIR}/refs/, and to write such files atomically and optionally with an compare and lock. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
Needed for the bignum stuff used by merge-order.
-
This patch linearises the GIT commit history graph into merge order which is defined by invariants specified in Documentation/git-rev-list.txt. The linearisation produced by this patch is superior in an objective sense to that produced by the existing git-rev-list implementation in that the linearisation produced is guaranteed to have the minimum number of discontinuities, where a discontinuity is defined as an adjacent pair of commits in the output list which are not related in a direct child-parent relationship. With this patch a graph like this: a4 --- | \ \ | b4 | |/ | | a3 | | | | | a2 | | | | c3 | | | | | c2 | b3 | | | /| | b2 | | | c1 | | / | b1 a1 | | | a0 | | / root Sorts like this: = a4 | c3 | c2 | c1 ^ b4 | b3 | b2 | b1 ^ a3 | a2 | a1 | a0 = root Instead of this: = a4 | c3 ^ b4 | a3 ^ c2 ^ b3 ^ a2 ^ b2 ^ c1 ^ a1 ^ b1 ^ a0 = root A test script, t/t6000-rev-list.sh, includes a test which demonstrates that the linearisation produced by --merge-order has less discontinuities than the linearisation produced by git-rev-list without the --merge-order flag specified. To see this, do the following: cd t ./t6000-rev-list.sh cd trash cat actual-default-order cat actual-merge-order The existing behaviour of git-rev-list is preserved, by default. To obtain the modified behaviour, specify --merge-order or --merge-order --show-breaks on the command line. This version of the patch has been tested on the git repository and also on the linux-2.6 repository and has reasonable performance on both - ~50-100% slower than the original algorithm. This version of the patch has incorporated a functional equivalent of the Linus' output limiting algorithm into the merge-order algorithm itself. This operates per the notes associated with Linus' commit 337cb3fb. This version has incorporated Linus' feedback regarding proposed changes to rev-list.c. (see: [PATCH] Factor out filtering in rev-list.c) This version has improved the way sort_first_epoch marks commits as uninteresting. For more details about this change, refer to Documentation/git-rev-list.txt and http://blackcubes.dyndns.org/epoch/. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 06 6月, 2005 3 次提交
-
-
由 Linus Torvalds 提交于
Bad Linus.
-
由 Linus Torvalds 提交于
The merge stuff will want it soon, and we don't want to duplicate all the work..
-
由 Junio C Hamano 提交于
In preparation for 1.0 release, this makes the command names consistent with others in git-*-pull family. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 05 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Somebody finally came through - Jeff Garzik gets a gold star for writing a shortlog script for git, so that I can do nice release announcments again. I added name translations from the current kernel history (and git, for that matter). Hopefully it won't grow at nearly the same rate the BK equivalent did, since 99% of the time git records the full name already. Usage: just do git-rev-list --pretty HEAD ^LAST_HEAD | git-shortlog or, in fact, use any of the other tools (git-diff-tree, git-whatchanged etc) that use the default "pretty" commit format.
-
- 02 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
The "git" script is just shorthand: "git xyz <args>" will just execute "git-xyz-script <args>", which is useful for people used to the CVS naming convention. So "git log" will run the new git-log-script, which is just a wrapper around the new pretty-printing git-rev-list. Cheesy.
-
- 31 5月, 2005 3 次提交
-
-
由 Junio C Hamano 提交于
A new diffcore filter diffcore-order is introduced. This takes a text file each of whose line is a shell glob pattern. Patches that match a glob pattern on an earlier line in the file are output before patches that match a later line, and patches that do not match any glob pattern are output last. A typical orderfile for git project probably should look like this: README Makefile Documentation *.h *.c Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
This is meant to make raw git not hugely less usable than something like raw CVS. I want to make a 1.0 release of the plumbing, and the actual commit part was just too intimidating.
-
由 Junio C Hamano 提交于
A new diffcore transformation, diffcore-break.c, is introduced. When the -B flag is given, a patch that represents a complete rewrite is broken into a deletion followed by a creation. This makes it easier to review such a complete rewrite patch. The -B flag takes the same syntax as the -M and -C flags to specify the minimum amount of non-source material the resulting file needs to have to be considered a complete rewrite, and defaults to 99% if not specified. As the new test t4008-diff-break-rewrite.sh demonstrates, if a file is a complete rewrite, it is broken into a delete/create pair, which can further be subjected to the usual rename detection if -M or -C is used. For example, if file0 gets completely rewritten to make it as if it were rather based on file1 which itself disappeared, the following happens: The original change looks like this: file0 --> file0' (quite different from file0) file1 --> /dev/null After diffcore-break runs, it would become this: file0 --> /dev/null /dev/null --> file0' file1 --> /dev/null Then diffcore-rename matches them up: file1 --> file0' The internal score values are finer grained now. Earlier maximum of 10000 has been raised to 60000; there is no user visible changes but there is no reason to waste available bits. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 25 5月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
The second round similarity estimator simply used the size of the xdelta itself to estimate the extent of damage. This patch keeps that logic to detect big insertions to terminate the check early, but otherwise looks at the generated delta in order to estimate the extent of edit more accurately. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 24 5月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
This applies git patches (and old-style unified diffs) in the index, rather than doing it in the working directory. That allows for a lot more flexibility, and means that if a patch fails, we aren't going to mess up the working directory. NOTE! This is just the first cut at it, and right now it only parses the incoming patch, it doesn't actually apply it yet.
-
- 23 5月, 2005 4 次提交
-
-
由 Linus Torvalds 提交于
Thomas Glanzmann points out that it doesn't work well with different clients accessing the repository over NFS - they have different views on what the "device" for the filesystem is. Of course, other filesystems may not even have stable inode numbers. But we don't care. At least for now.
-
由 Thomas Glanzmann 提交于
Signed-off-by: NThomas Glanzmann <sithglan@stud.uni-erlangen.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
This allows you to just fetch stuff first, inspect it, and then resolve the merge separately if everything looks good.
-
由 Junio C Hamano 提交于
This moves the path selection logic from individual programs to a new diffcore transformer (diff-tree still needs to have its own for performance reasons). Also the header printing code in diff-tree was tweaked not to produce anything when pickaxe is in effect and there is nothing interesting to report. An interesting example is the following in the GIT archive itself: $ git-whatchanged -p -C -S'or something in a real script' Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 5月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
(Or, if somebody disagrees, we should have a "make distclean").
-
由 Junio C Hamano 提交于
This steals the "pickaxe" feature from JIT and make it available to the bare Plumbing layer. From the command line, the user gives a string he is intersted in. Using the diff-core infrastructure previously introduced, it filters the differences to limit the output only to the diffs between <src> and <dst> where the string appears only in one but not in the other. For example: $ ./git-rev-list HEAD | ./git-diff-tree -Sdiff-tree-helper --stdin -M would show the diffs that touch the string "diff-tree-helper". In real software-archaeologist application, you would typically look for a few to several lines of code and see where that code came from. The "pickaxe" module runs after "rename/copy detection" module, so it even crosses the file rename boundary, as the above example demonstrates. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-