Skip to main content

Browse the archive

swh:1:snp:bb8853bfef8fcf2b1d37fd6404912c7606c98e48
sort by:
Revision Author Date Message Commit Date
5c553ea Junio C Hamano 07 February 2007, 22:31:21 UTC GIT v1.5.0-rc4 Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 22:31:46 UTC
81f915e Junio C Hamano 07 February 2007, 22:30:47 UTC Documentation: Add gfi to the main command list. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 22:30:47 UTC
abd4e22 Linus Torvalds 07 February 2007, 19:49:56 UTC Fix "git log -z" behaviour For commit messages, we should really put the "line_termination" when we output the character in between different commits, *not* between the commit and the diff. The diff goes hand-in-hand with the commit, it shouldn't be separated from it with the termination character. So this: - uses the termination character for true inter-commit spacing - uses a regular newline between the commit log and the diff We had it the other way around. For the normal case where the termination character is '\n', this obviously doesn't change anything at all, since we just switched two identical characters around. So it's very safe - it doesn't change any normal usage, but it definitely fixes "git log -z". By fixing "git log -z", you can now also do insane things like git log -p -z | grep -z "some patch expression" | tr '\0' '\n' | less -S and you will see only those commits that have the "some patch expression" in their commit message _or_ their patches. (This is slightly different from 'git log -S"some patch expression"', since the latter requires the expression to literally *change* in the patch, while the "git log -p -z | grep .." approach will see it if it's just an unchanged _part_ of the patch context) Of course, if you actually do something like the above, you're probably insane, but hey, it works! Try the above command line for a demonstration (of course, you need to change the "some patch expression" to be something relevant). The old behaviour of "git log -p -z" was useless (and got things completely wrong for log entries without patches). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 19:58:07 UTC
a4f7112 Junio C Hamano 07 February 2007, 18:56:38 UTC git-add -i: update removed path correctly. Earlier, when a path that was removed from the working tree was chosen for update subcommand, you got an error like this: error: git-resolve.sh: does not exist and --remove not passed fatal: Unable to process file git-resolve.sh Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 18:56:38 UTC
fa1b4d2 Junio C Hamano 07 February 2007, 18:42:08 UTC t4200: skip gc-rerere test on systems with non GNU date. Quite nonstandard "date -d @11111111 +%s" does not even fail on OpenBSD but gives the current date in "seconds since epoch" format, which is useless for the purpose of this test. We want to make sure that this returns exactly the same input before proceeding. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 18:43:56 UTC
ecea1ed Junio C Hamano 07 February 2007, 17:47:49 UTC Merge branch 'ml/gitk' (early part) * 'ml/gitk' (early part): gitk: Use show-ref instead of ls-remote Make gitk work reasonably well on Cygwin. gitk - remove trailing whitespace from a few lines. 07 February 2007, 17:47:49 UTC
40db58b Johannes Schindelin 07 February 2007, 11:38:21 UTC fast-import: Fix compile warnings Not on all platforms are size_t and unsigned long equivalent. Since I do not know how portable %z is, I play safe, and just cast the respective variables to unsigned long. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 17:28:23 UTC
fcee5a1 Junio C Hamano 07 February 2007, 17:18:57 UTC for-each-reflog: fix case for empty log directory When we remove the last reflog in a directory, opendir() would succeed and we would iterate over its dirents, expecting retval to be initialized to zero and setting it to non-zero only upon seeing an error. If the directory is empty, oops!, we do not have anybody that touches retval. The problem is because we initialize retval to errno even on success from opendir(), which would leave the errno unmolested. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 17:18:57 UTC
302da67 Junio C Hamano 07 February 2007, 16:39:16 UTC Merge branch 'master' of git://repo.or.cz/git/fastimport * 'master' of git://repo.or.cz/git/fastimport: Add a Tips and Tricks section to fast-import's manual. Don't crash fast-import if the marks cannot be exported. Dump all refs and marks during a checkpoint in fast-import. Teach fast-import how to sit quietly in the corner. Teach fast-import how to clear the internal branch content. Minor timestamp related documentation corrections for fast-import. 07 February 2007, 16:39:16 UTC
099c783 Junio C Hamano 07 February 2007, 10:10:56 UTC git-clone --reference: work well with pack-ref'ed reference repository Earlier we only used loose refs to anchor already existing objects. When cloning from a repository that forked relatively long time ago from the reference repository, this made the want/have exchange by fetch-pack to do unnecessary work. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 10:10:56 UTC
bdd9f42 Shawn O. Pearce 07 February 2007, 08:49:08 UTC Add a Tips and Tricks section to fast-import's manual. There has been some informative lessons learned in the gfi user community, and these really should be written down and documented for future generations of frontend developers. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 08:49:08 UTC
563b43e Alex Riesen 05 February 2007, 13:04:09 UTC Avoid ActiveState Perl IO in t800[12] Use sed instead, it comes with cygwin and there is almost no chance of someone installing a sed with default CRLF lineendings by accident. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 08:35:15 UTC
451fd65 Michael 05 February 2007, 13:27:32 UTC Documentation: add KMail in SubmittingPatches Signed-off-by: Michael <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 08:33:38 UTC
22c9f7e Shawn O. Pearce 07 February 2007, 07:46:35 UTC Don't crash fast-import if the marks cannot be exported. Apparently fast-import used to die a horrible death if we were unable to open the marks file for output. This is slightly less than ideal, especially now that we dump the marks as part of the `checkpoint` command. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 07:46:35 UTC
820b931 Shawn O. Pearce 07 February 2007, 07:42:44 UTC Dump all refs and marks during a checkpoint in fast-import. If the frontend asks us to checkpoint (via the explicit checkpoint command) its probably because they are afraid the current import will crash/fail/whatever and want to make sure they can pickup from the last checkpoint. To do that sort of recovery, we will need the current tip of every branch and tag available at the next startup. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 07:42:44 UTC
c499d76 Shawn O. Pearce 07 February 2007, 07:19:31 UTC Teach fast-import how to sit quietly in the corner. Often users will be running fast-import from within a larger frontend process, and this may be a frequent periodic tool such as a future edition of `git-svn fetch`. We don't want to bombard users with our large stats output if they won't be interested in it, so `--quiet` is now an option to make gfi be more silent. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 07:19:31 UTC
825769a Shawn O. Pearce 07 February 2007, 07:03:03 UTC Teach fast-import how to clear the internal branch content. Some frontends may not be able to (easily) keep track of which files are included in the branch, and which aren't. Performing this tracking can be tedious and error prone for the frontend to do, especially if its foreign data source cannot supply the changed path list on a per-commit basis. fast-import now allows a frontend to request that a branch's tree be wiped clean (reset to the empty tree) at the start of a commit, allowing the frontend to feed in all paths which belong on the branch. This is ideal for a tar-file importer frontend, for example, as the frontend just needs to reformat the tar data stream into a gfi data stream, which may be something a few Perl regexps can take care of. :) Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 07:03:03 UTC
9b92c82 Shawn O. Pearce 07 February 2007, 05:51:58 UTC Minor timestamp related documentation corrections for fast-import. As discussed on the mailing list, the documentation used here was not quite accurate. Improve upon it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 February 2007, 05:51:58 UTC
6506e15 Junio C Hamano 07 February 2007, 05:27:09 UTC Remove git-merge-recur This was useful when the current recursive was in development, and the original Python version was still called git-merge-recursive. Now the synonym has served us well, it is time to move on. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 05:33:20 UTC
740afd9 Junio C Hamano 07 February 2007, 05:25:33 UTC Add deprecation notices. Schedule git-diff-stages and git-resolve to be removed by 1.5.1 Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 05:25:33 UTC
41dc7e0 Junio C Hamano 07 February 2007, 03:33:22 UTC Merge branch 'master' of git://repo.or.cz/git/fastimport * 'master' of git://repo.or.cz/git/fastimport: (81 commits) S_IFLNK != 0140000 Don't do non-fastforward updates in fast-import. Support RFC 2822 date parsing in fast-import. Minor fast-import documentation corrections. Remove unnecessary null pointer checks in fast-import. Correct fast-import timezone documentation. Correct minor style issue in fast-import. Correct compiler warnings in fast-import. Remove --branch-log from fast-import. Initial draft of fast-import documentation. Don't support shell-quoted refnames in fast-import. Reduce memory usage of fast-import. Include checkpoint command in the BNF. Accept 'inline' file data in fast-import commit structure. Reduce value duplication in t9300-fast-import. Create test case for fast-import. Support delimited data regions in fast-import. Remove unnecessary options from fast-import. Use fixed-size integers when writing out the index in fast-import. Always use struct pack_header for pack header in fast-import. ... 07 February 2007, 03:33:22 UTC
a7fd83b Junio C Hamano 07 February 2007, 00:33:16 UTC Remove contrib/colordiff This has completely been superseded by built-in --color option. Signed-off-by: Junio C Hamano <junkio@cox.net> 07 February 2007, 00:33:16 UTC
0b2958a Horst H. von Brand 06 February 2007, 19:08:55 UTC Call make always with CFLAGS in git.spec If not, the binaries get built once with the correct CFLAGS, and then again with the ones in the Makefile when installing Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 22:09:03 UTC
4ef40cd Uwe Kleine-König 06 February 2007, 17:28:32 UTC add replay and log to the usage string of git-bisect Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 21:58:03 UTC
9981b6d Junio C Hamano 06 February 2007, 20:46:11 UTC S_IFLNK != 0140000 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 21:08:30 UTC
7073e69 Shawn O. Pearce 06 February 2007, 21:08:06 UTC Don't do non-fastforward updates in fast-import. If fast-import is being used to update an existing branch of a repository, the user may not want to lose commits if another process updates the same ref at the same time. For example, the user might be using fast-import to make just one or two commits against a live branch. We now perform a fast-forward check during the ref updating process. If updating a branch would cause commits in that branch to be lost, we skip over it and display the new SHA1 to standard error. This new default behavior can be overridden with `--force`, like git-push and git-fetch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 21:08:06 UTC
63e0c8b Shawn O. Pearce 06 February 2007, 19:58:30 UTC Support RFC 2822 date parsing in fast-import. Since some frontends may be working with source material where the dates are only readily available as RFC 2822 strings, it is more friendly if fast-import exposes Git's parse_date() function to handle the conversion. This way the frontend doesn't need to perform the parsing itself. The new --date-format option to fast-import can be used by a frontend to select which format it will supply date strings in. The default is the standard `raw` Git format, which fast-import has always supported. Format rfc2822 can be used to activate the parse_date() function instead. Because fast-import could also be useful for creating new, current commits, the format `now` is also supported to generate the current system timestamp. The implementation of `now` is a trivial call to datestamp(), but is actually a whole whopping 3 lines so that fast-import can verify the frontend really meant `now`. As part of this change I have added validation of the `raw` date format. Prior to this change fast-import would accept anything in a `committer` command, even if it was seriously malformed. Now fast-import requires the '> ' near the end of the string and verifies the timestamp is formatted properly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 19:58:30 UTC
ef94edb Shawn O. Pearce 06 February 2007, 17:35:02 UTC Minor fast-import documentation corrections. Corrected a couple of header markup lines which were shorter than the actual header, and made the `data` commands two formats into a named list, which matches how we document the two formats of the `M` command within a commit. Also tried to simplify the language about our decimal integer format; Linus pointed out I was probably being too specific at the cost of reduced readability. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 17:35:02 UTC
e7d06a4 Shawn O. Pearce 06 February 2007, 17:05:51 UTC Remove unnecessary null pointer checks in fast-import. There is no need to check for a NULL pointer before invoking free(), the runtime library automatically performs this check anyway and does nothing if a NULL pointer is supplied. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 17:05:51 UTC
c74ba3d Shawn O. Pearce 06 February 2007, 16:59:11 UTC Correct fast-import timezone documentation. Andy Parkins and Linus Torvalds both noticed that the description of the timezone was incorrect. Its not expressed in minutes. Its more like "hhmm", where "hh" is the number of hours and "mm" is the number of minutes shifted from GMT/UTC. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 16:59:11 UTC
e68989a Junio C Hamano 06 February 2007, 09:52:04 UTC annotate: fix for cvsserver. git-cvsserver does not want the boundary commits shown any differently. Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 09:52:04 UTC
c8f80d4 Junio C Hamano 06 February 2007, 09:09:32 UTC gitweb: fix mismatched parenthesis An earlier commit 04179418 broke gitweb. Badly. Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 09:09:32 UTC
d46ae3f Junio C Hamano 06 February 2007, 07:01:14 UTC git-push: allow globbing wildcard refspec. This allows you to set up mothership-satellite configuration more symmetrically and naturally by allowing the globbing wildcard refspec for git-push. On your satellite machine: [remote "mothership"] url = mothership:project.git fetch = refs/heads/*:refs/remotes/mothership/* push = refs/heads/*:refs/remotes/satellite/* You would say "git fetch mothership" to update your tracking branches under mothership/ to keep track of the progress on the mothership side, and when you are done working on the satellite machine, you would "git push mothership" to update their tracking branches under satellite/. Corresponding configuration on the mothership machine can be used to make "git fetch satellite" update its tracking branch under satellite/. on the mothership. Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 08:46:56 UTC
e5b1444 Shawn O. Pearce 06 February 2007, 05:43:59 UTC Correct minor style issue in fast-import. Junio noticed that I was using a different style in fast-import for returned pointers than the rest of Git. Before merging this code into the main git.git tree I'd like to make it consistent, as this style variation was not intentional. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 05:43:59 UTC
10e8d68 Shawn O. Pearce 06 February 2007, 05:26:49 UTC Correct compiler warnings in fast-import. Junio noticed these warnings/errors in fast-import when compiling with `-Werror -ansi -pedantic`. A few changes are to reduce compiler warnings, while one (in cmd_merge) is a bug fix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 05:26:49 UTC
0b868e0 Shawn O. Pearce 06 February 2007, 05:15:37 UTC Remove --branch-log from fast-import. The --branch-log option and its associated code hasn't been used in several months, as its not really very useful for debugging fast-import or a frontend. I don't plan on supporting it in this state long-term, so I'm killing it now before it gets distributed to a wider audience. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 05:15:37 UTC
88293c6 Shawn O. Pearce 05 February 2007, 04:52:08 UTC bash: Complete git-remote subcommands. Completing the 3 core subcommands to git-remote, along with the names of remotes for 'show' and 'prune' (which take only existing remotes) is handy. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 03:09:40 UTC
c5650b0 Shawn O. Pearce 05 February 2007, 04:52:02 UTC bash: Support git-rebase -m continuation completion. Apparently `git-rebase -m` uses a metadata directory within .git (.git/.dotest-merge) rather than .dotest used by git-am (and git-rebase without the -m option). This caused the completion code to not offer --continue, --skip or --abort when working within a `git-rebase -m` session. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 03:09:40 UTC
6e411d2 Shawn O. Pearce 06 February 2007, 02:09:25 UTC Initial draft of fast-import documentation. This is a first pass at the manpage for git-fast-import. I have tried to cover the input format in extreme detail, creating a reference which is more detailed than the BNF grammar appearing in the header of fast-import.c. I have also covered some details about gfi's performance and memory utilization, as well as the average learning curve required to create a gfi frontend application (as it is far lower than it might appear on first glance). The documentation still lacks real example input streams, which may turn out to be difficult to format in asciidoc due to the blank lines which carry meaning within the format. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 02:09:25 UTC
6c3aac1 Shawn O. Pearce 06 February 2007, 01:30:37 UTC Don't support shell-quoted refnames in fast-import. The current implementation of shell-style quoted refnames and SHA-1 expressions within fast-import contains a bad memory leak. We leak the unquoted strings used by the `from` and `merge` commands, maybe others. Its also just muddling up the docs. Since Git refnames cannot contain LF, and that is our delimiter for the end of the refname, and we accept any other character as-is, there is no reason for these strings to support quoting, except to be nice to frontends. But frontends shouldn't be expecting to use funny refs in Git, and its just as simple to never quote them as it is to always pass them through the same quoting filter as pathnames. So frontends should never quote refs, or ref expressions. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 February 2007, 01:30:37 UTC
0f57a31 Junio C Hamano 30 January 2007, 05:53:28 UTC gitk: Use show-ref instead of ls-remote It used to be ls-remote on self was the only easy way to grab the ref information. Now we have show-ref which does not involve fork and IPC, so use it. Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 01:14:15 UTC
3468e71 Mark Levedahl 01 February 2007, 13:46:38 UTC Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> 06 February 2007, 01:14:15 UTC
32364b3 Mark Levedahl 01 February 2007, 13:44:46 UTC gitk - remove trailing whitespace from a few lines. Signed-off-by: Mark Levedahl <mdl123@verizon.net> 06 February 2007, 01:14:14 UTC
8188e73 Junio C Hamano 06 February 2007, 00:53:12 UTC Fix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGS The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS. Not that it matters right now, since we do not compile XS Perl extensions which wanted non GNU subset of ALL_CFLAGS for compilation, but we should make things consistent. Signed-off-by: Junio C Hamano <junkio@cox.net> 06 February 2007, 00:56:13 UTC
35ce862 Linus Torvalds 24 January 2007, 19:21:10 UTC pager: Work around window resizing bug in 'less' If you resize the terminal while less is waiting for input, less will exit entirely without even showing the output. This is very noticeable if you do something like "git diff" on a big and cold-cache tree and git takes a few seconds to think, and then you resize the window while it's preparing. Boom. No output AT ALL. The way to reproduce the problem is to do some pager operation that takes a while in git, and resizing the window while git is thinking about the output. Try git diff --stat v2.6.12.. in the kernel tree to do something where it takes a while for git to start outputting information. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 23:42:36 UTC
b6f5da1 Junio C Hamano 02 February 2007, 07:30:03 UTC Teach git-remote add to fetch and track This adds three options to 'git-remote add'. * -f (or --fetch) option tells it to also run the initial "git fetch" using the newly created remote shorthand. * -t (or --track) option tells it not to use the default wildcard to track all branches. * -m (or --master) option tells it to make the remote/$name/HEAD point at a remote tracking branch other than master. For example, with this I can say: $ git remote add -f -t master -t quick-start -m master \ jbf-um git://linux-nfs.org/~bfields/git.git/ to (1) create remote.jbf-um.url; (2) track master and quick-start branches (and no other); the two -t options create these two lines: fetch = +refs/heads/master:refs/remotes/jbf-um/master fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start (3) set up remotes/jbf-um/HEAD to point at jbf-um/master so that later I can say "git log jbf-um" Or I could do $ git remote add -t 'ap/*' andy /home/andy/git.git to make Andy's topic branches kept track of under refs/remotes/andy/ap/. Other possible improvements I considered but haven't implemented (hint, hint) are: * reject wildcard letters other than a trailing '*' to the -t parameter; * make -m optional and when the first -t parameter does not have the trailing '*' default to that value (so the above example does not need to say "-m master"); * if -m is not given, and -t parameter ends with '*' (i.e. the above defaulting did not tell us where to point HEAD at), and if we did the fetch with -f, check if 'master' was fetched and make HEAD point at it. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 23:41:59 UTC
06e75a7 Junio C Hamano 05 February 2007, 23:04:01 UTC blame: document --contents option Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 23:04:01 UTC
005f85d Junio C Hamano 05 February 2007, 05:49:05 UTC Use pretend_sha1_file() in git-blame and git-merge-recursive. git-merge-recursive wants an null tree as the fake merge base while producing the merge result tree. The null tree does not have to be written out in the object store as it won't be part of the result, and it is a prime example for using the new pretend_sha1_file() function. git-blame needs to register an arbitrary data to in-core index while annotating a working tree file (or standard input), but git-blame is a read-only application and the user of it could even lack the privilege to write into the object store; it is another good example for pretend_sha1_file(). Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:55:11 UTC
d66b37b Junio C Hamano 05 February 2007, 05:42:38 UTC Add pretend_sha1_file() interface. The new interface allows an application to temporarily hash a small number of objects and pretend that they are available in the object store without actually writing them. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:55:11 UTC
1cfe773 Junio C Hamano 30 January 2007, 09:11:08 UTC git-blame: no rev means start from the working tree file. Warning: this changes the semantics. This makes "git blame" without any positive rev to start digging from the working tree copy, which is made into a fake commit whose sole parent is the HEAD. It also adds --contents <file> option to pretend as if the working tree copy has the contents of the named file. You can use '-' to make the command read from the standard input. If you want the command to start annotating from the HEAD commit, you need to explicitly give HEAD parameter. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:55:11 UTC
28389d4 David Kågedal 05 February 2007, 22:22:28 UTC git-blame: an Emacs minor mode to view file with git-blame output. Here's another version of git-blame.el that automatically tries to create a sensible list of colors to use for both light and dark backgrounds. Plus a few minor fixes. To use: 1) Load into emacs: M-x load-file RET git-blame.el RET 2) Open a git-controlled file 3) Blame: M-x git-blame-mode Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:22:28 UTC
ca28370 Simon 'corecode' Schubert 01 February 2007, 10:43:39 UTC Allow forcing of a parent commit, even if the parent is not a direct one. This can be used to compress multiple changesets into one, for example like git cvsexportcommit -P cvshead mybranch without having to do so in git first. Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:10:01 UTC
4c55068 Junio C Hamano 05 February 2007, 22:03:27 UTC bisect: it needs to be done in a working tree. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:03:27 UTC
6d9ba67 Johannes Schindelin 23 January 2007, 12:30:20 UTC Commands requiring a work tree must not run in GIT_DIR This patch helps when you accidentally run something like git-clean in the git directory instead of the work tree. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 22:02:16 UTC
98d47d4 Stelian Pop 12 January 2007, 21:57:03 UTC Add hg-to-git conversion utility. hg-to-git.py is able to convert a Mercurial repository into a git one, and preserves the branches in the process (unlike tailor) hg-to-git.py can probably be greatly improved (it's a rather crude combination of shell and python) but it does already work quite well for me. Features: - supports incremental conversion (for keeping a git repo in sync with a hg one) - supports hg branches - converts hg tags Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:52:45 UTC
3fb6245 Aneesh Kumar K.V 30 January 2007, 07:56:50 UTC blameview: Support browsable functionality to blameview. Double clicking on the row execs a new blameview with commit hash as argument. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
0417941 Yasushi SHOJI 30 January 2007, 10:23:38 UTC gitweb: Convert project name to UTF-8 If the repository directory name is in non-ascii, $project needs to be converted from perl internal to utf-8 because it will be used as title, page path, and snapshot filename. use to_utf8() to do the conversion. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
b2e69f6 Shawn O. Pearce 05 February 2007, 20:44:37 UTC bash: Support git-bisect and its subcommands. We now offer completion support for git-bisect's subcommands, as well as ref name completion on the good/bad/reset subcommands. This should make interacting with git-bisect slightly easier on the fingers. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
1b71eb3 Shawn O. Pearce 05 February 2007, 20:44:32 UTC bash: Support --add completion to git-config. We've recently added --add as an argument to git-config, but I missed putting it into the earlier round of git-config updates within the bash completion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
e459415 Shawn O. Pearce 05 February 2007, 20:44:30 UTC bash: Hide git-resolve, its deprecated. Don't offer resolve as a possible subcommand completion. If you read the top of the script, there is a big warning about how it will go away soon in the near future. People should not be using it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
b26c874 Shawn O. Pearce 05 February 2007, 20:44:28 UTC bash: Offer --prune completion for git-gc. I'm lazy. I don't want to type out --prune if bash can do it for me with --<tab>. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
983591c Shawn O. Pearce 05 February 2007, 20:44:24 UTC bash: Hide diff-stages from completion. Apparently nobody really makes use of git-diff-stages, as nobody has complained that it is not supported by the git-diff frontend. Since its likely this will go away in the future, we should not offer it as a possible subcommand completion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
d8a9fea Shawn O. Pearce 05 February 2007, 20:44:22 UTC bash: Support completion on git-cherry. I just realized I did not support ref name completion for git-cherry. This tool is just too useful to contributors who submit patches upstream by email; completion support for it is very handy. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:49:00 UTC
ea81fcc Shawn O. Pearce 05 February 2007, 20:21:06 UTC Show an example of deleting commits with git-rebase. This particular use of git-rebase to remove a single commit or a range of commits from the history of a branch recently came up on the mailing list. Documenting the example should help other users arrive at the same solution on their own. It also was not obvious to the newcomer that git-rebase is able to accept any commit for --onto <newbase> and <upstream>. We should at least minimally document this, as much of the language in git-rebase's manpage refers to 'branch' rather than 'committish'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:48:59 UTC
69057cf Andy Parkins 05 February 2007, 19:58:47 UTC git-for-each-ref doesn't return "the bit after $GIT_DIR/refs" The documentation for git-for-each-ref said that the refname variable would return "the part after $GIT_DIR/refs/", which isn't true. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:48:59 UTC
133f081 Junio C Hamano 05 February 2007, 01:30:58 UTC t9200: Work around HFS+ issues. We at least know that the test as written has a problem in an environment where "touch '$p'; ls | fgrep '$p'" fails, and have a clear understand why it fails. This tests if the filesystem has that particular issue we know "git add" has a problem with, and skips the test in such an environment. This way, we might catch issues "git add" might have in other environments. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 21:38:02 UTC
10831c5 Shawn O. Pearce 05 February 2007, 21:34:56 UTC Reduce memory usage of fast-import. Some structs are allocated rather frequently, but were using integer types which were far larger than required to actually store their full value range. As packfiles are limited to 4 GiB we don't need more than 32 bits to store the offset of an object within that packfile, an `unsigned long` on a 64 bit system is likely a 64 bit unsigned value. Saving 4 bytes per object on a 64 bit system can add up fast on any sizable import. As atom strings are strictly single components in a path name these are probably limited to just 255 bytes by the underlying OS. Going to that short of a string is probably too restrictive, but certainly `unsigned int` is far too large for their lengths. `unsigned short` is a reasonable limit. Modes within a tree really only need two bytes to store their whole value; using `unsigned int` here is vast overkill. Saving 4 bytes per file entry in an active branch can add up quickly on a project with a large number of files. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 05 February 2007, 21:34:56 UTC
8c1f22d Shawn O. Pearce 05 February 2007, 21:05:11 UTC Include checkpoint command in the BNF. This command isn't encouraged (as its slow) but it does exist and is accepted, so it still should be covered in the BNF. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 05 February 2007, 21:05:11 UTC
798123a Junio C Hamano 05 February 2007, 01:50:14 UTC Rename get_ident() to fmt_ident() and make it available to outside This makes the functionality of ident.c::get_ident() available to other callers. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 01:50:14 UTC
11dbe9e Gerrit Pape 03 February 2007, 22:38:59 UTC git-archimport: initial import needs empty directory git-archimport should better refuse to start an initial import if the current directory is not empty. (http://bugs.debian.org/400508) Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 01:05:16 UTC
756373d Junio C Hamano 04 February 2007, 00:23:38 UTC Revert "Allow branch.*.merge to talk about remote tracking branches." This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9. Back when I committed this, it seemed to be a good idea. People who always use remote tracking branches can optionally use the local name they happen to use to specify what to merge, which meant that I did not have to teach them why we use the name at the remote side every time they are confused. But allowing it seems to break other people's scripts. The real solution is not to allow more ways to express the same thing, but to educate people to use the right syntax. Signed-off-by: Junio C Hamano <junkio@cox.net> 05 February 2007, 00:58:30 UTC
d1f289c Junio C Hamano 05 February 2007, 00:54:47 UTC Merge branch 'np/dreflog' * np/dreflog: show-branch -g: default to the current branch. Let git-checkout always drop any detached head Enable HEAD@{...} and make it independent from the current branch scan reflogs independently from refs add reflog when moving HEAD to a new branch create_symref(): do not assume pathname from git_path() persists long enough add logref support to git-symbolic-ref move create_symref() past log_ref_write() add reflog entries for HEAD when detached enable separate reflog for HEAD lock_ref_sha1_basic(): remember the original name of a ref when resolving it make reflog filename independent from struct ref_lock 05 February 2007, 00:54:47 UTC
6e2e1cf Robin Rosenberg 04 February 2007, 16:16:39 UTC Why is it bad to rewind a branch that has already been pushed out? Mention git-revert as an alternative to git-reset to revert changes. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 19:43:45 UTC
1f7d1a5 Junio C Hamano 04 February 2007, 11:25:12 UTC git-clone --reference: saner handling of borrowed symrefs. When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 11:28:15 UTC
ec80489 Shawn O. Pearce 04 February 2007, 07:38:47 UTC bash: Support internal revlist options better. format-patch/log/whatchanged all take --not and --all as options to the internal revlist process. So these should be supported as possible completions. gitk takes anything rev-list/log/whatchanged takes, so we should use complete_revlist to handle its options. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
b339177 Shawn O. Pearce 04 February 2007, 07:38:43 UTC bash: Support unique completion when possible. Because our use of -o nospace prevents bash from adding a trailing space when a completion is unique and has been fully completed, we need to perform this addition on our own. This (large) change converts all existing uses of compgen to our wrapper __gitcomp which attempts to handle this by tacking a trailing space onto the end of each offered option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
78d4d6a Shawn O. Pearce 04 February 2007, 07:38:37 UTC bash: Support unique completion on git-config. In many cases we know a completion will be unique, but we've disabled bash's automatic space addition (-o nospace) so we need to do it ourselves when necessary. This change adds additional support for new configuration options added in 1.5.0, as well as some extended completion support for the color.* family of options. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
a925c6f Shawn O. Pearce 04 February 2007, 07:38:30 UTC bash: Classify more commends out of completion. Most of these commands are not ones you want to invoke from the command line on a frequent basis, or have been renamed in 1.5.0 to more friendly versions, but the old names are being left behind to support existing scripts in the wild. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
72e5e98 Shawn O. Pearce 04 February 2007, 07:38:27 UTC bash: Add space after unique command name is completed. Because we use the nospace option for our completion function for the main 'git' wrapper bash won't automatically add a space after a unique completion has been made by the user. This has been pointed out in the past by Linus Torvalds as an undesired behavior. I agree. We have to use the nospace option to ensure path completion for a command such as `git show` works properly, but that breaks the common case of getting the space for a unique completion. So now we set IFS=$'\n' (linefeed) and add a trailing space to every possible completion option. This causes bash to insert the space when the completion is unique. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
8435b54 Shawn O. Pearce 04 February 2007, 07:38:23 UTC bash: Complete long options to git-add. The new --interactive mode of git-add can be very useful, so users will probably want to have completion for it. Likewise the new git-add--interactive executable is actually a plumbing command. Its invoked by `git add --interactive` and is not intended to be invoked directly by the user. Therefore we should hide it from the list of available Git commands. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
2e3a430 Shawn O. Pearce 04 February 2007, 07:38:21 UTC bash: Classify cat-file and reflog as plumbing. Now that git-show is capable of displaying any file content from any revision and is the approved Porcelain-ish level method of doing so, cat-file should no longer be classified as a user-level utility by the bash completion package. I'm also classifying the new git-reflog command as plumbing for the time being as there are no subcommands which are really useful to the end-user. git-gc already invokes `git reflog expire --all`, which makes it rather unnecessary for the user to invoke it directly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
9f4cc6f Shawn O. Pearce 04 February 2007, 07:38:17 UTC bash: Remove short option completions for branch/checkout/diff. The short options (-l, -f, -d) for git-branch are rather silly to include in the completion generation as these options must be fully typed out by the user and most users already know what the options are anyway, so including them in the suggested completions does not offer huge value. (The same goes for git-checkout and git-diff.) Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 08:18:41 UTC
632ac9f Junio C Hamano 04 February 2007, 07:31:47 UTC show-branch -g: default to the current branch. Now we have a separate reflog on HEAD, show-branch -g without an explicit parameter defaults to the current branch, or HEAD when it is detached from branches. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 07:34:22 UTC
dc9195a Nicolas Pitre 04 February 2007, 02:50:39 UTC Let git-checkout always drop any detached head We used to refuse leaving a detached HEAD when it wasn't matching an existing ref so not to lose any commit that might have been performed while not on any branch (unless -f was provided). But this protection was completely bogus since it was still possible to move to HEAD^ while still remaining detached but losing the last commit anyway if there was one. Now that we have a proper reflog for HEAD it is best to simply remove that bogus (and admitedly annoying) protection and simply display the last HEAD position instead. If one wants to recover a lost detached state then it can be retrieved from the HEAD reflog. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 07:06:27 UTC
f2eba66 Nicolas Pitre 04 February 2007, 02:49:16 UTC Enable HEAD@{...} and make it independent from the current branch Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 07:06:27 UTC
d77ee72 Junio C Hamano 04 February 2007, 06:14:40 UTC Merge branch 'master' into np/dreflog This is to resolve conflicts early in preparation for possible inclusion of "reflog on detached HEAD" series by Nico, as having it in 1.5.0 would really help us remove confusion between detached and attached states. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 07:05:34 UTC
8d0fc48 Shawn O. Pearce 04 February 2007, 05:45:47 UTC Default GIT_MERGE_VERBOSITY to 5 during tests. Its really nice to be able to run a test with -v and automatically see the "debugging" dump from merge-recursive, especially if we are actually trying to debug merge-recursive. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 06:04:34 UTC
183d797 Shawn O. Pearce 04 February 2007, 05:45:54 UTC Keep untracked files not involved in a merge. My earlier fix (8371234e) to delete renamed tracked files from the working directory also caused merge-recursive to delete untracked files that were in the working directory. The problem here is merge-recursive is deleting the working directory file without regard for which branch it was associated with. What we really want to do during a merge is to only delete files that were renamed by the branch we are merging into the current branch, and that are still tracked by the current branch. These files definitely don't belong in the working directory anymore. Anything else is either a merge conflict (already handled in other parts of the code) or a file that is untracked by the current branch and thus is not even participating in the merge. Its this latter class that must be left alone. For this fix to work we are now assuming that the first non-base argument passed to git-merge-recursive always corresponds to the working directory. This is already true for all in-tree callers of merge-recursive. This assumption is also supported by the long time usage message of "<base> ... -- <head> <remote>", where "<head>" is implied to be HEAD, which is generally assumed to be the current tree-ish. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 06:04:28 UTC
3dff537 Pavel Roskin 04 February 2007, 04:49:16 UTC Assorted typo fixes Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 05:49:54 UTC
0f39087 Shawn O. Pearce 04 February 2007, 04:02:59 UTC Cleanup subcommand documentation for git-remote. Jakub Narebski pointed out the positional notation in git-remote's documentation was very confusing, especially now that we have 3 supported subcommands. Instead of referring to subcommands by position, refer to them by name. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 05:49:49 UTC
9673a0b Pavel Roskin 04 February 2007, 03:01:04 UTC git-config --rename-section could rename wrong section The "git-config --rename-section" implementation would match sections that are substrings of the section name to be renamed. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 05:35:22 UTC
3b0f5e8 Junio C Hamano 03 February 2007, 20:37:54 UTC combine-diff: special case --unified=0 Even when --unified=0 is given, the main loop to show the combined textual diff needs to handle a line that is unchanged but has lines that were deleted relative to a parent before it (because that is where the lost lines hang). However, such a line should not be emitted in the final output. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 00:31:11 UTC
a9d1836 Junio C Hamano 03 February 2007, 06:40:49 UTC Why is it bad to rewind a branch that has already been pushed out? I was reading the tutorial and noticed that we say this: Also, don't use "git reset" on a publicly-visible branch that other developers pull from, as git will be confused by history that disappears in this way. I do not think this is a good explanation. For example, if we do this: (1) I build a series and push it out. ---o---o---o---j (2) Alice clones from me, and builds two commits on top of it. ---o---o---o---j---a---a (3) I rewind one and build a few, and push them out. ---o---o---o...j \ h---h---h---h (4) Alice pulls from me again: ---o---o---o---j---a---a---* \ / h---h---h---h Contrary to the description, git will happily have Alice merge between the two branches, and never gets confused. Maybe I did not want to have 'j' because it was an incomplete solution to some problem, and Alice may have fixed it up with her changes, while I abandoned that approach I started with 'j', and worked on something completely unrelated in the four 'h' commits. In such a case, the merge Alice would make would be very sensible, and after she makes the merge if I pull from her, the world will be perfect. I started something with 'j' and dropped the ball, Alice picked it up and perfected it while I went on to work on something else with 'h'. This would be a perfect example of distributed parallel collaboration. There is nothing confused about it. The case the rewinding becomes problematic is if the work done in 'h' tries to solve the same problem as 'j' tried to solve in a different way. Then the merge forced on Alice would make her pick between my previous attempt with her fixups (j+a) and my second attempt (h). If 'a' commits were to fix up what 'j' started, presumably Alice already studied and knows enough about the problem so she should be able to make an informed decision to pick between what 'j+a' and 'h' do. A lot worse case is if Alice's work is not at all related to what 'j' wanted to do (she did not mean to pick up from where I left off -- she just wanted to work on something different). Then she would not be familiar enough with what 'j' and 'h' tried to achieve, and I'd be forcing her to pick between the two. Of course if she can make the right decision, then again that is a perfect example of distributed collaboration, but that does not change the fact that I'd be forcing her to clean up my mess. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 February 2007, 00:30:52 UTC
23913dc Junio C Hamano 20 January 2007, 01:12:11 UTC honor GIT_REFLOG_ACTION in git-commit This allows git-cherry-pick and git-revert to properly identify themselves in the resulting reflog entries. Earlier they were recorded as what git-commit has done. Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 23:17:49 UTC
5f856dd Junio C Hamano 19 January 2007, 19:51:29 UTC fix reflog entries for "git-branch" Even when -l is not given from the command line, the repository may have the configuration variable core.logallrefupdates set, or an old-timer might have done ": >.git/logs/refs/heads/new" before running "git branch new". In these cases, the code gave an uninitialized msg[] from the stack to be written out as the reflog message. This also passes a different message when '-f' option is used. Saying "git branch -f branch some-commit" is a moral equilvalent of doing "git-reset some-commit" while on the branch. Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 20:54:49 UTC
eb8381c Nicolas Pitre 03 February 2007, 18:25:43 UTC scan reflogs independently from refs Currently, the search for all reflogs depends on the existence of corresponding refs under the .git/refs/ directory. Let's scan the .git/logs/ directory directly instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 19:57:18 UTC
505739f Junio C Hamano 03 February 2007, 07:17:34 UTC core-tutorial: http reference link fix Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 07:17:34 UTC
bf3478d Junio C Hamano 03 February 2007, 06:55:07 UTC Tutorial-2: Adjust git-status output to recent reality. Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 06:55:07 UTC
953202a Junio C Hamano 03 February 2007, 06:19:17 UTC Tutorial: fix asciidoc formatting of "git add" section. Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 06:19:17 UTC
3cf8b46 Shawn O. Pearce 02 February 2007, 08:00:03 UTC Don't leak file descriptors from unavailable pack files. If open_packed_git failed it may have been because the packfile actually exists and is readable, but some sort of verification did not pass. In this case open_packed_git left pack_fd filled in, as the file descriptor is valid. We don't want to leak the file descriptor, nor do we want to allow someone in the future to use this packed_git. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 03 February 2007, 05:33:18 UTC
back to top