aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* [PATCH] Finish initial cut of git-pack-object/git-unpack-object pair.Junio C Hamano2005-06-26
| | | | | | | | | | | | | | | | | This finishes the initial round of git-pack-object / git-unpack-object pair. They are now good enough to be used as a transport medium: - Fix delta direction in pack-objects; the original was computing delta to create the base object from the object to be squashed, which was quite unfriendly for unpacker ;-). - Add a script to test the very basics. - Implement unpacker for both regular and deltified objects. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Add "--depth=N" parameter to git-pack-objects to limit maximum delta depthLinus Torvalds2005-06-25
| | | | It too defaults to 10. A nice round random number.
* git-pack-objects: make "--window=x" semantics more logical.Linus Torvalds2005-06-25
| | | | | | | | | | | A zero disables delta generation (like before), but we make the window be one bigger than specified, since we use one entry for the one to be tested (it used to be that "--window=1" was meaningless, since we'd have used up the single-entry window with the entry to be tested, and had no chance of actually ever finding a delta). The default window remains at 10, but now it really means "test the 10 closest objects", not "test the 9 closest objects".
* Add a "max_size" parameter to diff_delta()Linus Torvalds2005-06-25
| | | | | | | Anything that generates a delta to see if two objects are close usually isn't interested in the delta ends up being bigger than some specified size, and this allows us to stop delta generation early when that happens.
* Fix delta "sliding window" codeLinus Torvalds2005-06-25
| | | | | | | | | When Junio fixed the lack of a successful error code from try_delta(), that uncovered an off-by-one error in the caller. Also, some testing made it clear that we now find a lot more deltas, because we used to (incorrectly) break early on bogus "failure" cases.
* [PATCH] (patchlet) pack-objects.c: try_delta()Junio C Hamano2005-06-25
| | | | | | | | | Return value of try_delta is checked for negativeness, but the success path does not return anything, letting compiler warn and presumably return garbage. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Add a bit of developer documentation to pull.hJunio C Hamano2005-06-25
| | | | | | | | Describe what to implement in fetch() and fetch_ref() for pull backend writers a bit better. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] http-pull: documentation updates.Junio C Hamano2005-06-25
| | | | | | | Describe -w option. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix oversimplified optimization for add_cache_entry().Junio C Hamano2005-06-25
| | | | | | | | | | | | | | | | | | An earlier change to optimize directory-file conflict check broke what "read-tree --emu23" expects. This is fixed by this commit. (1) Introduces an explicit flag to tell add_cache_entry() not to check for conflicts and use it when reading an existing tree into an empty stage --- by definition this case can never introduce such conflicts. (2) Makes read-cache.c:has_file_name() and read-cache.c:has_dir_name() aware of the cache stages, and flag conflict only with paths in the same stage. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] git-merge-one-file-script: do not misinterpret rm failure.Junio C Hamano2005-06-25
| | | | | | | | | | | | | | | | | | When a merge adds a file DF and removes a directory there by deleting a path DF/DF, git-merge-one-file-script can be called for the removal of DF/DF when the path DF is already created by "git-read-tree -m -u". When this happens, we get confused by a failure return from 'rm -f -- "$4"' (where $4 is DF/DF); finding file DF there the "rm -f" command complains that DF is not a directory. What we want to ensure is that there is no file DF/DF in this case. Avoid getting ourselves confused by first checking if there is a file, and only then try to remove it (and check for failure from the "rm" command). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Add more tests for read-tree --emu23.Junio C Hamano2005-06-25
| | | | | | | | | | | This adds more tests for --emu23. One is to show how it can carry forward more local changes than the straightforward two-way fast forward, and another is to show the recent overeager optimization of directory/file conflict check broke things, which will be fixed in the next commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] git-rebase-script: rebase local commits to new upstream head.Junio C Hamano2005-06-25
| | | | | | | | | 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] git-cherry: find commits not merged upstream.Junio C Hamano2005-06-25
| | | | | | | | | | | 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] git-commit-script: get commit message from an existing one.Junio C Hamano2005-06-25
| | | | | | | | With -m flag specified, git-commit-script takes the commit message along with author information from an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fix date parsing for GIT raw commit timestamp format.Junio C Hamano2005-06-25
| | | | | | | | | | | | | | | | | | | | Usually all of the match_xxx routines in date.c fill tm structure assuming that the parsed string talks about local time, and parse_date routine compensates for it by adjusting the value with tz offset parsed out separately. However, this logic does not work well when we feed GIT raw commit timestamp to it, because what match_digits gets is already in GMT. A good testcase is: $ make test-date $ ./test-date 'Fri Jun 24 16:55:27 2005 -0700' '1119657327 -0700' These two timestamps represent the same time, but the second one without the fix this commit introduces gives you 7 hours off. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-unpack-objects: start parsing the actual packed dataLinus Torvalds2005-06-25
| | | | So far we just print out the type and size.
* git-pack-objects: mark the delta packing with a 'D'.Linus Torvalds2005-06-25
| | | | | | When writing a delta, we take the real type from the object we're doing the delta against, and just write a 'D' as the type of the current object.
* First cut at git-unpack-objectsLinus Torvalds2005-06-25
| | | | | | | | 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".
* git-pack-objects: fix typoLinus Torvalds2005-06-25
| | | | ("<" should be "=")
* git-pack-objects: create a packed object representation.Linus Torvalds2005-06-25
| | | | | | | | | | | | | | | 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?
* [PATCH] git-write-tree doesn't check alternate directoriesJan Harkes2005-06-25
| | | | | | | | | git-write-tree failed when referenced objects only exist in the GIT_ALTERNATE_OBJECT_DIRECTORIES path. Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git-rev-list: add option to list all objects (not just commits)Linus Torvalds2005-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you do git-rev-list --objects $(git-rev-parse HEAD^..HEAD) it now lists not only the "commit difference" between the parent of HEAD and HEAD itself (which is normally just the parent, but in the case of a merge will be all the newly merged commits), but also all the new tree and blob objects that weren't in the original. NOTE! It doesn't walk all the way to the root, so it doesn't do a full object search in the full old history. Instead, it will only look as far back in the history as it needs to resolve the commits. Thus, if the commit reverts a blob (or tree) back to a state much further back in history, we may end up listing some blobs (or trees) as "new" even though they exist further back. Regardless, the list of objects will be a superset (usually exact) list of objects needed to go from the beginning commit to ending commit. As a particularly obvious special case, git-rev-list --objects HEAD will end up listing every single object that is reachable from the HEAD commit. Side note: the objects are sorted by "recency", with commits first.
* git-rev-parse: re-organize and be more carefulLinus Torvalds2005-06-24
| | | | | | | Output default revisions as their hex SHA1 names to be consistent. Add "--verify" flag that verifies that we output a single ref and not more (and disables ref arguments).
* Add "git-patch-id" program to generate patch ID's.Linus Torvalds2005-06-23
| | | | | | | | | | 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.
* Clean up git-diff-tree 'header' generationLinus Torvalds2005-06-23
|
* git-apply: take "--apply" flag to force an apply even if we also ask for a ↵Linus Torvalds2005-06-23
| | | | | | diffstat Also, remove debugging statement about applying a fragment at an offset.
* Make "git fetch" able to fetch a named tagLinus Torvalds2005-06-23
| | | | | Use "git fetch <repo> tag <tagname>" to get the named tag and everything it points to.
* [PATCH] Fix to how --merge-order handles multiple rootsJon Seymour2005-06-22
| | | | | | | | This patch addresses the problem reported by Paul Mackerras such that --merge-order did not report the last root of a graph with merge of two independent roots. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] A test case that demonstrates a problem with merges with two roots.Jon Seymour2005-06-22
| | | | | | | | | | git-rev-list --merge-order is omitting one of the roots when displaying a merge containing two distinct roots. A subsequent patch will fix the problem. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Don't ignore reachability of tag objects in fsckLinus Torvalds2005-06-22
| | | | | | | | We used to ignore unreachable tags, which just causes problems: it makes "git prune" leave them around, but since we'll have prune everything that tag points to, the tag object really should be removed too. So remove the code that made us think tags were always reachable.
* Add "git-clone-script" thingyLinus Torvalds2005-06-22
| | | | | It's just a trivial wrapper, but it should make Jeff's kernel developer guide to git look a bit less intimidating.
* [PATCH] Fix --merge-order unit test breaks introduced by ↵Jon Seymour2005-06-22
| | | | | | | | | | | | | 6c88be169881c9223532796bd225e79afaa115e1 The sensible cleanup of the in-memory storage order of commit parents broke the --merge-order code which was dependent on the previous behaviour of parse_commit(). This patch restores the correctness --merge-order behaviour by taking account of the new behaviour of parse_commit. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Add "gitk" to the list of scripts to be installed automatically.Linus Torvalds2005-06-22
| | | | | Btw, it's fun just looking at the merged git repository itself with gitk, now that it has two "roots".
* Do a cross-project merge of Paul Mackerras' gitk visualizerLinus Torvalds2005-06-22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gitk is really quite incredibly cool, and is great for visualizing what is going on in a git repository. It's especially useful when you are looking at what has changed since a particular version, since it gracefully handles partial trees (and this also avoids the expense of looking at _all_ changes in a big project). For example, to see what changed in a merge after a "git pull", do gitk ORIG_HEAD.. to see only the new things. Or you can simply do "gitk v2.6.12.." to see what has changed since the v2.6.12 tag etc. This merge itself is pretty interesting too, since it shows off a feature of git itself that is incredibly cool: you can merge a _separate_ git project into another git project. Not only does this keep all the history of the original project, it also makes it possible to continue to merge with the original project and the union of the two projects. I don't think anybody else can do that.
| * Try to assign colors so crossing lines have different colorsPaul Mackerras2005-06-22
| | | | | | | | | | In particular try hard to give different colors to lines that cross at a corner in one of the lines.
| * Account for indentation of the checkin comments by git-rev-listPaul Mackerras2005-06-22
| | | | | | | | | | This involves adding indentation when we read a commit with git-cat-file and trimming the whitespace from the headline.
| * Use git-rev-list --header.Paul Mackerras2005-06-22
| | | | | | | | | | | | | | | | With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
| * Pass arguments through git-rev-parse.Paul Mackerras2005-06-21
| | | | | | | | | | | | This allows the user to specify ranges more flexibly; for instance the user can now do "gitk v2.6.12.." and see all the changes since 2.6.12.
| * Handle the case of a parent being listed twice in a merge.Paul Mackerras2005-06-21
| | | | | | | | | | | | | | | | This happens in the linux-2.6 tree. We draw the graph line double-thick to show that this happened. Also fix a bug where we got a bogus "No commit information available" line at the end on simple repositories like this one.
| * Draw graph lines as one continuous line where possiblePaul Mackerras2005-06-17
| | | | | | | | | | | | Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
| * Fix operation without libreadobj.so.0.0Paul Mackerras2005-06-16
| | | | | | | | Display a watch cursor when reading the commits initially
| * Restructure to do incremental drawingPaul Mackerras2005-06-16
| | | | | | | | Some speedups from not doing update so often
| * Show heads as well as tagsPaul Mackerras2005-06-10
| |
| * cope with changed git-diff-tree output formatPaul Mackerras2005-06-01
| |
| * Use git-rev-list instead of git-rev-tree.Paul Mackerras2005-05-31
| | | | | | | | | | | | Fix bug in changing font size in entry widgets. Fix bug with B1 click before anything has been drawn. Use "units" and "pages" instead of "u" and "p" for tk8.5.
| * Read tags from .git/refs/tags/* and mark commits with tagsPaul Mackerras2005-05-21
| | | | | | | | | | with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
| * Accommodate new git-diff-tree output formatPaul Mackerras2005-05-19
| | | | | | | | Add 'f' key for moving to next file
| * Handle \ No newline at end of line lines in diffPaul Mackerras2005-05-19
| | | | | | | | | | Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
| * More fixes for geometry restorationPaul Mackerras2005-05-18
| | | | | | | | | | | | | | | | | | Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
| * Error popups on error conditions rather than stderr msgsPaul Mackerras2005-05-17
| | | | | | | | | | | | | | Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-13 14:07:14 +0000