aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Documentation: revise top of git man pageJ. Bruce Fields2006-04-02
| | | | | | | | | | | | | | | | | | | | I'm afraid I'll be accused of trying to suck all the jokes and the personality out of the git documentation. I'm not! Really! That said, "man git" is one of the first things a new user is likely try, and it seems a little cruel to start off with a somewhat obscure joke about the architecture of git. So instead I'm trying for a relatively straightforward description of what git does, and what features distinguish it from other systems, together with immediate links to introductory documentation. I also did some minor reorganization in an attempt to clarify the classification of commands. And revised a bit for conciseness (as is obvious from the diffstat--hopefully I didn't cut anything important). Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix sparse warnings about non-ANSI function prototypesRene Scharfe2006-04-02
| | | | | Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix sparse warnings about usage of 0 instead of NULLRene Scharfe2006-04-02
| | | | | Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove useless pointer updateRene Scharfe2006-04-02
| | | | | | | | buf is not used afterwards. The compiler optimized the dead store out anyway, but let's clean the source, too. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* contrib/git-svn: documentation updatesEric Wong2006-04-01
| | | | | | | | | | | | | | contrib/git-svn/git-svn.txt: added git-repo-config key names for options fixed quoting of "git-svn-HEAD" in the manpage use preformatted text for examples contrib/git-svn/Makefile: add target to generate HTML: http://git-svn.yhbt.net/git-svn.html Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* contrib/git-svn: accept configuration via repo-configEric Wong2006-04-01
| | | | | | | | repo-config keys are any of the long option names minus the '-' characters Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision: --max-age alone does not need limit_list() anymore.Junio C Hamano2006-04-01
| | | | | | This makes git log --since=7.days to be streamable. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision: simplify argument parsing.Junio C Hamano2006-04-01
| | | | | | | This just moves code around to consolidate the part that sets revs->limited to one place based on various flags. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision: --topo-order and --unpackedJunio C Hamano2006-04-01
| | | | | | | Now, using --unpacked without limit_list() does not make much sense, but this is parallel to the earlier --max-age fix. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision: Fix --topo-order and --max-age with reachability limiting.Linus Torvalds2006-04-01
| | | | | | | | | | | | | | | | | | | | | | | What ends up not working very well at all is the combination of "--topo-order" and the output filter in get_revision. It will return NULL when we see the first commit out of date-order, even if we have other commits coming. So we really should do the "past the date order" thing in get_revision() only if we have _not_ done it already in limit_list(). Something like this. The easiest way to test this is with just gitk --since=3.days.ago on the kernel tree. Without this patch, it tends to be pretty obviously broken. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make path-limiting be incremental when possible.Linus Torvalds2006-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes git-rev-list able to do path-limiting without having to parse all of history before it starts showing the results. This makes things like "git log -- pathname" much more pleasant to use. This is actually a pretty small patch, and the biggest part of it is purely cleanups (turning the "goto next" statements into "continue"), but it's conceptually a lot bigger than it looks. What it does is that if you do a path-limited revision list, and you do _not_ ask for pseudo-parenthood information, it won't do all the path-limiting up-front, but instead do it incrementally in "get_revision()". This is an absolutely huge deal for anything like "git log -- <pathname>", but also for some things that we don't do yet - like the "find where things changed" logic I've described elsewhere, where we want to find the previous revision that changed a file. The reason I put "RFC" in the subject line is that while I've validated it various ways, like doing git-rev-list HEAD -- drivers/char/ | md5sum before-and-after on the kernel archive, it's "git-rev-list" after all. In other words, it's that really really subtle and complex central piece of software. So while I think this is important and should go in asap, I also think it should get lots of testing and eyeballs looking at the code. Btw, don't even bother testing this with the git archive. git itself is so small that parsing the whole revision history for it takes about a second even with path limiting. The thing that _really_ shows this off is doing git log drivers/ on the kernel archive, or even better, on the _historic_ kernel archive. With this change, the response is instantaneous (although seeking to the end of the result will obviously take as long as it ever did). Before this change, the command would think about the result for tens of seconds - or even minutes, in the case of the bigger old kernel archive - before starting to output the results. NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses the "--parents" flag to actually generate a pseudo-history of the resulting commits won't actually see the improvement in interactivity, since that forces git-rev-list to do the whole-history thing after all. MAYBE we can fix that too at some point, but I won't promise anything. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Move "--parent" parsing into generic revision.c library codeLinus Torvalds2006-03-31
| | | | | | | | | Not only do we do it in both rev-list.c and git.c, the revision walking code will soon want to know whether we should rewrite parenthood information or not. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Makefile: many programs now depend on xdiff/lib.a having been built.Junio C Hamano2006-03-31
| | | | | | | The dependency was not properly updated when we added this library, breaking parallel build with $(MAKE) -j. Signed-off-by: Junio C Hamano <junkio@cox.net>
* rev-list --boundary: fix re-injecting boundary commits.Junio C Hamano2006-03-30
| | | | | | | | | | | | | | | | | | | | Marco reported that $ git rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d misses these two boundary commits. c649657501bada28794a30102d9c13cc28ca0e5e eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4 Indeed, we can see that gitk shows these two commits at the bottom, because the --boundary code failed to output them. The code did not check to avoid pushing the same uninteresting commit twice to the result list. I am not sure why this fixes the reported problem, but this seems to fix it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge git://git.kernel.org/pub/scm/gitk/gitkJunio C Hamano2006-03-30
|\ | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/gitk/gitk: gitk: Better workaround for arrows on diagonal line segments gitk: Allow top panes to scroll horizontally with mouse button 2 gitk: Prevent parent link from overwriting commit headline gitk: Show diffs for boundary commits gitk: Use the new --boundary flag to git-rev-list
| * gitk: Better workaround for arrows on diagonal line segmentsPaul Mackerras2006-03-31
| | | | | | | | | | | | | | | | | | | | | | Instead of adding extra padding to create a vertical line segment at the lower end of a line that has an arrow, this now just draws a very short vertical line segment at the lower end. This alternative workaround for the Tk8.4 behaviour (not drawing arrows on diagonal line segments) doesn't have the problem of making the graph very wide when people do a lot of merges in a row (hi Junio :). Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Allow top panes to scroll horizontally with mouse button 2Paul Mackerras2006-03-31
| | | | | | | | Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Prevent parent link from overwriting commit headlinePaul Mackerras2006-03-31
| | | | | | | | | | | | | | | | | | | | When I made drawlineseg responsible for drawing the link to the first child rather than drawparentlinks, that meant that the right-most X value computed by drawparentlinks didn't include those first-child links, and thus the first-child link could go over the top of the commit headline. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Show diffs for boundary commitsPaul Mackerras2006-03-30
| | | | | | | | | | | | | | | | | | With this we run git-diff-tree on a commit even if we think it has no parents, either because it really has no parents or because it is a boundary commit. This means that gitk shows the diff for a boundary commit when it is selected. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Use the new --boundary flag to git-rev-listPaul Mackerras2006-03-30
| | | | | | | | | | | | | | | | With this, we can show the boundary (open-circle) commits immediately after their last child, which looks much better than putting all the boundary commits at the bottom of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
* | contrib/git-svn: force GIT_DIR to an absolute pathEric Wong2006-03-30
| | | | | | | | | | | | | | We chdir internally, so we need a consistent GIT_DIR variable. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-clone: exit early if repo isn't specifiedYasushi SHOJI2006-03-30
| | | | | | | | | | | | | | | | | | | | | | git-clone without a repo isn't useful at all. print message and get out asap. This patch also move the variable 'local' to where other variables are initialized. Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Make git-clone to take long double-dashed origin option (--origin)Yasushi SHOJI2006-03-30
| | | | | | | | | | | | | | | | | | | | | | git-clone currently take option '-o' to specify origin. this patch makes git-clone to take double-dashed option '--origin' and other abbreviations in addtion to the current single-dashed option. [jc: with minor fixups] Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | tree/diff header cleanup.Junio C Hamano2006-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce tree-walk.[ch] and move "struct tree_desc" and associated functions from various places. Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and move it to cache.h. This macro returns the canonicalized st_mode value in the host byte order for files, symlinks and directories -- to be compared with a tree_desc entry. create_ce_mode(mode) in cache.h is similar but is intended to be used for index entries (so it does not work for directories) and returns the value in the network byte order. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | assume unchanged git: diff-index fix.Junio C Hamano2006-03-29
| | | | | | | | | | | | | | | | | | | | When the executable bit is untrustworthy and when we are comparing the tree with the working tree, we tried to reuse the mode bits recorded in the index incorrectly (the computation was bogus on little endian architectures). Just use mode from index when it is a regular file. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | revision.c "..B" syntax: constness fixJunio C Hamano2006-03-29
| | | | | | | | | | | | | | The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B) has constness gotcha GCC complains. Fix it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | revision arguments: ..B means HEAD..B, just like A.. means A..HEADJunio C Hamano2006-03-29
| | | | | | | | | | | | | | | | For consistency reasons, we should probably allow that to be written as just "..branch", the same way we can write "branch.." to mean "everything in HEAD but not in "branch". Signed-off-by: Junio C Hamano <junkio@cox.net>
* | rev-list --boundaryJunio C Hamano2006-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new --boundary flag, the output from rev-list includes the UNINTERESING commits at the boundary, which are usually not shown. Their object names are prefixed with '-'. For example, with this graph: C side / A---B---D master You would get something like this: $ git rev-list --boundary --header --parents side..master D B tree D^{tree} parent B ... log message for commit D here ... \0-B A tree B^{tree} parent A ... log message for commit B here ... \0 Signed-off-by: Junio C Hamano <junkio@cox.net>
* | rev-list: memory usage reduction.Junio C Hamano2006-03-28
| | | | | | | | | | | | | | | | | | | | We do not need to track object refs, neither we need to save commit unless we are doing verbose header. A lot of traversal happens inside prepare_revision_walk() these days so setting things up before calling that function is necessary. Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Linus Torvalds <torvalds@osdl.org>
* | rev-list --no-merges: argument parsing fix.Junio C Hamano2006-03-28
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | xdiff: Show function names in hunk headers.Mark Wooding2006-03-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The speed of the built-in diff generator is nice; but the function names shown by `diff -p' are /really/ nice. And I hate having to choose. So, we hack xdiff to find the function names and print them. xdiff has grown a flag to say whether to dig up the function names. The builtin_diff function passes this flag unconditionally. I suppose it could parse GIT_DIFF_OPTS, but it doesn't at the moment. I've also reintroduced the `function name' into the test suite, from which it was removed in commit 3ce8f089. The function names are parsed by a particularly stupid algorithm at the moment: it just tries to find a line in the `old' file, from before the start of the hunk, whose first character looks plausible. Still, it's most definitely a start. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Add ALL_LDFLAGS to the git target.Jason Riedy2006-03-27
| | | | | | | | | | | | | | | | | | | | For some reason, I need ALL_LDFLAGS in the git target only on AIX. Once it builds, only one test "fails" on AIX 5.1 with 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some odd tool problem in the tester + my setup and not a real bug. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | GIT 1.3.0 rc1v1.3.0-rc1Junio C Hamano2006-03-27
| | | | | | | | | | | | | | | | | | | | | | | | All of the things that were not in the "master" branch were either cooked long enough in "next" without causing problems (e.g. insanely fast rename detector or true built-in diff) or isolated in a specific subsystem (e.g. tar-tree and svnimport). So I am clearing the deck to prepare for a 1.3.0. Remaining wrinkles, if any, will be ironed in the "master" branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch ak/svnJunio C Hamano2006-03-27
|\ \
| * | git-svnimport: if a limit is specified, respect itAnand Kumria2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | git-svnimport will import the same revision over and over again if a limit (-l <rev>) has been specified. Instead if that revision has already been processed, exit with an up-to-date message. Signed-off-by: Anand Kumria <wildfire@progsoc.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'lt/diffgen' into nextJunio C Hamano2006-03-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | * lt/diffgen: add clean and ignore rules for xdiff/ Remove dependency on a file named "-lz"
| * | | add clean and ignore rules for xdiff/Junio C Hamano2006-03-26
| | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | Remove dependency on a file named "-lz"Johannes Schindelin2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By changing the dependency "$(LIB_H)" to "$(LIBS)", at least one version of make thought that a file named "-lz" would be needed. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | Merge branch 'master' into nextJunio C Hamano2006-03-26
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master: Optionally do not list empty directories in git-ls-files --others Document git-rebase behavior on conflicts. Fix error handling for nonexistent names
| * | | | Optionally do not list empty directories in git-ls-files --othersPetr Baudis2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without the --directory flag, git-ls-files wouldn't ever list directories, producing no output for empty directories, which is good since they cannot be added and they bear no content, even untracked one (if Git ever starts tracking directories on their own, this should obviously change since the content notion will change). With the --directory flag however, git-ls-files would list even empty directories. This may be good in some situations but sometimes you want to prevent that. This patch adds a --no-empty-directory option which makes git-ls-files omit empty directories. Signed-off-by: Petr Baudis <pasky@suse.cz>
| * | | | Document git-rebase behavior on conflicts.J. Bruce Fields2006-03-26
| | | | |
| * | | | Fix error handling for nonexistent namesLinus Torvalds2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When passing in a pathname pattern without the "--" separator on the command line, we verify that the pathnames in question exist. However, there were two bugs in that verification: - git-rev-parse would only check the first pathname, and silently allow any invalid subsequent pathname, whether it existed or not (which defeats the purpose of the check, and is also inconsistent with what git-rev-list actually does) - git-rev-list (and "git log" etc) would check each filename, but if the check failed, it would print the error using the first one, i.e.: [torvalds@g5 git]$ git log Makefile bad-file fatal: 'Makefile': No such file or directory instead of saying that it's 'bad-file' that doesn't exist. This fixes both bugs. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | | | Merge branch 'jc/thin' into nextJunio C Hamano2006-03-26
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/thin: git-push: make --thin pack transfer the default. gitk: Fix two bugs reported by users gitk: Improve appearance of first child links gitk: Make downward-pointing arrows end in vertical line segment gitk: Don't change cursor at end of layout if find in progress gitk: Make commitdata an array rather than a list gitk: Fix display of diff lines beginning with --- or +++ [PATCH] gitk: Make error_popup react to Return gitk: Fix a bug in drawing the selected line as a thick line gitk: Further speedups gitk: Various speed improvements gitk: Fix Update menu item gitk: Fix clicks on arrows on line ends gitk: New improved gitk contrib/git-svn: stabilize memory usage for big fetches
| * | | | | git-push: make --thin pack transfer the default.Junio C Hamano2006-03-26
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | Just in case it has problems, you can say "git push --no-thin". Signed-off-by: Junio C Hamano <junkio@cox.net>
| | | | |
| | \ \ \
| *-. \ \ \ Merge branches 'jc/clone' and 'jc/name'Junio C Hamano2006-03-26
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/clone: git-clone: typofix. clone: record the remote primary branch with remotes/$origin/HEAD revamp git-clone (take #2). revamp git-clone. fetch,parse-remote,fmt-merge-msg: refs/remotes/* support * jc/name: sha1_name: make core.warnambiguousrefs the default. sha1_name: warning ambiguous refs. get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
| * \ \ \ \ \ Merge branch 'jc/merge'Junio C Hamano2006-03-26
| |\ \ \ \ \ \ | | |_|_|_|/ / | |/| | | | | | | | | | | | | | | | | | | * jc/merge: git-merge knows some strategies want to skip trivial merges
| * | | | | | Merge git://git.kernel.org/pub/scm/gitk/gitkJunio C Hamano2006-03-26
| |\ \ \ \ \ \ | | | |_|_|_|/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/gitk/gitk: gitk: Fix two bugs reported by users gitk: Improve appearance of first child links gitk: Make downward-pointing arrows end in vertical line segment gitk: Don't change cursor at end of layout if find in progress gitk: Make commitdata an array rather than a list gitk: Fix display of diff lines beginning with --- or +++ [PATCH] gitk: Make error_popup react to Return gitk: Fix a bug in drawing the selected line as a thick line gitk: Further speedups gitk: Various speed improvements gitk: Fix Update menu item gitk: Fix clicks on arrows on line ends gitk: New improved gitk
| | * | | | | gitk: Fix two bugs reported by usersPaul Mackerras2006-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first was a simple typo where I put $yc instead of [yc $row]. The second was that I broke the logic for keeping up with fast movement through the commits, e.g. when you select a commit and then press down-arrow and let it autorepeat. That got broken when I changed the merge diff display to use git-diff-tree --cc. Signed-off-by: Paul Mackerras <paulus@samba.org>
| | * | | | | gitk: Improve appearance of first child linksPaul Mackerras2006-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
| | * | | | | gitk: Make downward-pointing arrows end in vertical line segmentPaul Mackerras2006-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems Tk 8.4 can't draw arrows on diagonal line segments. This adds code to the optimizer to make the last bit of a line go vertically before being terminated with an arrow pointing downwards, so that it will be drawn correctly by Tk 8.4. Signed-off-by: Paul Mackerras <paulus@samba.org>
generated by cgit v1.2.1 (git 2.18.0) at 2024-09-27 13:23:31 +0000